Source: http://docplayer.es/2063966-Servicio-de-proyeccion-de-material-docente-basado-en-raspberry-pi.html
Timestamp: 2016-10-26 17:52:59+00:00

Document:
⭐Servicio de proyección de material docente basado en Raspberry Pi
Servicio de proyección de material docente basado en Raspberry Pi
Download "Servicio de proyección de material docente basado en Raspberry Pi"
Esteban Cruz Miranda
1 Estudios de Grado en Ingeniería de Tecnologías de Telecomunicación Trabajo Fin de Grado Servicio de proyección de material docente basado en Raspberry Pi Autor Juan Ramón Gutiérrez Martínez Director Jorge Navarro Ortiz Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación Granada, 7 de julio de 20142 Servicio de proyección de material docente basado en Raspberry Pi Realizado por: Juan Ramón Gutiérrez Martínez Dirigido por: Jorge Navarro Ortiz Departamento: Teoría de la Señal, Telemática y Comunicaciones Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación Granada, 7 de julio de 20143 4 Servicio de proyección de material docente basado en Raspberry Pi Juan Ramón Gutiérrez Martínez Palabras clave: Raspberry Pi, docencia, material docente, proyección, exposición, diapositivas. Resumen: Ante la nueva forma de enseña en la que es necesaria la utilización de material en forma de diapositivas, se hace tedioso tener que transportar con el portátil en todo momento, además de la incomodidad de tener que estar conectado mediante el cable VGA. Ante esta cuestión surge este proyecto cuyo objetivo es poder hacer uso de los proyectores en las aulas docentes sin necesidad de tener un equipo conectado a través de un cable VGA. Para ello se conectará un PC del tamaño de una tarjeta de crédito (Raspberry Pi) a través del interfaz HDMI del proyector, de forma que el profesor pueda navegar a través de sus transparencias u otros materiales docentes desde cualquier equipo conectado a la red WiFi de la UGR, esto es, sin necesidad de estar conectado a través de un cable VGA. De esta manera, se mejora la usabilidad del servicio de proyección y también la movilidad del docente por el aula, ya que podría utilizar el portátil desde cualquier lugar del aula. Para ello, se ha de diseñar un servidor con autenticación de usuarios para el almacenaje del material docente, así como integrar los diferentes protocolos que sean necesarios para que la Raspberry Pi visualice dicho material a través del proyector y pueda ser controlada a través de los dispositivos inalámbricos mencionados. III5 6 Projection service of docent material based on Raspberry Pi Juan Ramón Gutiérrez Martínez Keywords: Raspberry Pi, teaching, teaching material, projection, exposition, slides. Abstract: In the new and predominant way of teaching that currently exists, which is necessary for almost any class, the using of docent material in form of transparencies or slides shown by teachers to students. A number of problems arise in the using of this teaching method when performing that work, of which no one has noticed, or at least nobody has not given importance or never has not anybody stopped to think carefully a global solution for all these. For instance, it becomes tedious for the professor, or student, having to carry his personal computers at all times to can display such material. In addition, on the other hand, is much the inconvenience of having to have the computer continuously connected by a cable. Something that greatly reduced or eliminated in some cases, the possibility of mobility of professors for classroom teaching. The market has been studied and all possible solutions which have been implemented, or could be nowadays or in the no far future, and it is has not found any solution which is good enough, to satisfy all needs of professor and solvent the problems set forth above in turn. And with some of these issues, the idea for this project arises, whose main objective is to make use of projectors present in teaching classrooms without having a computer connected to them via a cable constantly, either VGA or HDMI. To the implement, it is connected a PC with reduce dimensions, a size of a credit card more o less, but also with high performance in relation to this (Raspberry Pi), through the HDMI interface of projector. Thus it is intended that the professor can navigate through your slides or other teaching materials thanks to a client application and from any device connected to the Wi-Fi network of the UGR, namely, without necessity of being connected by a cable. In this manner, the usability of the service projection that is currently used is improved, as well as the mobility of professors is also enhanced in V7 the teaching classroom, as in this case, since there is no need to connect the computer with the cable, could also use any kind of device such as your smartphone, tablet or even the laptop itself but in this case, from anywhere in the classroom. Something that also improve the interconnection of devices and unify all existing technologies which we are working all the time. For the final implementation of this project, it is has designed an authentication server with a great database to differentiate the access of different users, to the files server where all teaching material which be used in the future will be stored. As well as, they are had to integrate the different protocols which are necessary for the server which are installed in the Raspberry Pi can to display such teaching material through the HDMI interface of projector, and that it can be controlled through the aforementioned wireless devices. VI8 Yo, Juan Ramón Gutiérrez Martínez, alumno de la titulación Grado en Ingeniería de Tecnologías de Telecomunicación de la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicaciones de la Universidad de Granada, con DNI J, autorizo la ubicación de la siguiente copia de mi Trabajo Fin de Grado en la biblioteca del centro y/o departamento para que pueda ser consultada libremente por las personas que lo deseen. Fdo: Juan Ramón Gutiérrez Martínez Granada a 7 de julio de 2014 VII9 10 D. Jorge Navarro Ortiz, profesor del área de Telemática del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, como director del siguiente Trabajo Fin de Grado de D. Juan Ramón Gutiérrez Martínez. Informa: que el presente trabajo, titulado: Servicio de proyección de material docente basado en Raspberry Pi Ha sido realizado y redactado bajo mi supervisión por el mencionado alumno, y con esta fecha autorizo la defensa de dicho trabajo ante el tribunal que corresponda. Y para que conste, expido y firmo el presente informe. Fdo: Jorge Navarro Ortiz Granada a 7 de julio de 2014 IX11 12 Agradecimientos Ha sido un largo camino hasta llegar a este punto. Más de una persona me advirtió de la dificultad que esto supondría, y no les faltaban razón. Pero a día de hoy, no me arrepiento en absoluto de lo decidido en aquel momento. Este proyecto representa un momento que todo estudiante, que disfruta con lo que ha estado estudiando a lo largo de estos años de universidad, espera ansiadamente. La culminación de una etapa importante de mi vida, la realización de un sueño, y la confirmación de las expectativas que todos los que me han apoyado tenían sobre mí. Me siento orgulloso con el resultado de este proyecto, y esto se lo debo a Jorge, mi tutor, gracias a la idea que en su día me dio, he tenido la oportunidad de terminar esta etapa con algo que me gusta y me apasiona. Además, he de agradecer todos los consejos que me ha brindado a lo largo de toda esta etapa. Por supuesto, debo agradecer a mis padres, y en general a mi familia, su apoyo incondicional y su total confianza en mí desde el primer momento que tomé la decisión. Porque saben perfectamente de la dificultad que esto ha supuesto y de todos los obstáculos que he tenido que superar. Tampoco puedo olvidar a los profesores que han sabido transmitirme sus conocimientos de esta profesión. Ni tampoco, a todos los compañeros que he tenido en estos años, por los buenos momentos, tanto en clase como fuera de esta, y en especial a los 6 con los he compartido interrail. Y por su puesto a Miriam. Gracias a todos XI13 14 Índice general 1. Introducción y referencias bibliográficas Contexto Evolución de los métodos docentes Tecnología en las aulas Motivación Estudio del estado del arte Proyectores inalámbricos Pizarra interactiva y Tablet Monitor Apple TV y AirPlay Wireless Display y Miracast Chromecast Resumen Objetivos y alcance del proyecto Estructura de la memoria Principales referencias utilizadas Planificación y estimación de costes Recursos Humanos Hardware Software Fases de desarrollo Revisión del estado del arte Especificación de los requisitos XIII15 ÍNDICE GENERAL Diseño Implementación Evaluación y pruebas Documentación Estimación de costos Recursos humanos Herramientas Presupuesto Análisis de objetivos y metodología Descripción global Especificación de requisitos Requisitos funcionales Requisitos no funcionales Requisitos de la interfaz de usuario Metodología Valoración de objetivos Diseño y resolución del trabajo Diseño Diseño global Diseño previo Estudio de las posibles implementaciones Diseño final Diseño de los servidores Servidor WEB Servidor RPi Diseño de la aplicación cliente Diseño del protocolo Implementacion Servidor SFTP Servidor LDAP XIV16 ÍNDICE GENERAL Servidor RADIUS Servidor HTTP index.php registrar.php inicio.php applet.php cambiarpassword.php cerrarserion.php Servidor RPi Cliente RPi Evaluación y pruebas Análisis del tráfico Entorno web Entorno de la aplicación cliente Escenario típico de aplicación Conclusiones y líneas futuras Resultados Líneas de trabajo futuras Valoración personal Anexos 87 A. Manual de usuario 89 A.1. Interfaz web A.2. Aplicación cliente A.3. Servidor RPi B. Manual de instalación 99 B.1. Raspberry Pi B.2. Servidor VSFTPD B.3. Servidor OpenLDAP XV17 ÍNDICE GENERAL B.4. Servidor FreeRADIUS B.5. Servidor Apache B.6. Servidor RPi Bibliografía final 113 XVI18 Índice de figuras 1.1. Estructura de funcionamiento de sesión multimedia estándar con ipad [26] Diagrama de Gantt con la planificación temporal Coste monetario asociado a cada fase del proyecto Diagrama de flujo de datos de alto nivel Diseño previo Diseño global de la implementación Uso de servidores HTTP Diseño general de funcionamiento Interfaz web de usuario Elementos del servidor WEB Diagrama de estados del ServidorRPi Diagrama de estados del ClienteRPi Intercambio de mensajes ClienteRPi-ServidorRPi Fichero de configuración grupos.ldif Fichero de configuración profesor.ldif Interfaz portada Interfaz página principal Escenario de aplicación del ejemplo Captura de Wireshark del establecimiento de la conexión Captura de Wireshark del mensaje Alert XVII19 ÍNDICE DE FIGURAS XVIII 5.4. Captura de Wireshark de la autenticación de usuario Captura de Wireshark del protocolo RADIUS Captura de Wireshark de la conexión FTP Captura de Wireshark del intercambio de mensajes en la conexión Captura de Wireshark del intercambio de mensajes en una petición Captura de Wireshark del intercambio de mensajes en el cierre de la conexión Captura de Wireshark del seguimiento del stream TCP Escenario típico de aplicación Interfaz del servidor RPi Captura de Wireshark del inicio de una conexión en un entorno de aplicación real Captura de Wireshark de autenticación de usuario en un entorno de aplicación real Captura de Wireshark de una conexión FTP en un entorno de aplicación real Debug del servidor RPi en un entorno de aplicación real Contenido del fichero log del servidor RPi en un entorno de aplicación real A.1. Portada A.2. Portada para los alumnos A.3. Página principal A.4. Ejemplo de notificación en la portada A.5. Página para crear una nueva cuenta A.6. Ejemplo de notificación en la página para crea una nueva cuenta 93 A.7. Página de configuración para cambiar de contraseña A.8. Página principal con opciones desplegadas A.9. Página de selección de lugar de proyección A.10.Página con la aplicación cliente para un documento PDF.. 95 A.11.Página con la aplicación cliente para una imagen A.12.Menú archivo de la aplicación cliente para un documento PDF 9620 ÍNDICE DE FIGURAS A.13.Menú ver de la aplicación cliente para un documento PDF.. 97 A.14.Menú ver de la aplicación cliente para una imagen A.15.Página con la aplicación cliente para un documento PDF.. 98 A.16.Página con la aplicación cliente para un documento PDF.. 98 B.1. Ejemplo del panel de configuración B.2. Ejemplo del panel de configuración B.3. Ejemplo del panel de configuración B.4. Interfaz de configuración del servidor OpenLDAP B.5. Resultado de añadir nuevas entradas a la base de datos B.6. Resultado de realizar una búsqueda en la base de datos B.7. Comprobración del correcto funcionamiento del servidor Free- RADIUS XIX21 22 Índice de tablas 1.1. Evolución de Powert Point Comparación de las soluciones existentes Planificación temporal del proyecto Coste monetario personal del proyecto Coste monetario material del proyecto Presupuesto total XXI23 24 Capítulo 1 Introducción y referencias bibliográficas 1.1. Contexto El auge en las últimas décadas en el uso de la tecnología es una realidad. Actualmente, las tecnologías de la información y la comunicación (TICs) están sufriendo un desarrollo vertiginoso, algo que afecta prácticamente a todos los campos de nuestra sociedad, y la educación no es una excepción. Las tecnologías son cada vez más utilizadas en los nuevos métodos docentes, por parte sobre todo, de las universidades [1]. Lejos de ser ajenos a todo este cambio, los métodos de aprendizaje y de enseñanza se han visto modificados conforme a la evolución que se produce cada día en la tecnología de una forma notable. Las TICs se han convertido en algo muy arraigado en los centros educativos. Su uso ha fomentado cambios cualitativos en la forma de enseñanza, especialmente en cuanto a la presentación de los contenidos por medios audiovisuales Evolución de los métodos docentes En el comienzo de la enseñanza, el único recurso en el que podía apoyarse un docente, y por tanto el único utilizado por éste era la pizarra y los libros de texto que los alumnos debían comprar. Y así fue hasta la invención del proyector de retroalimentación, el cual se ha estado utilizando hasta hace bien poco en muchas de las clases. Este equipo utilizaba la luz para proyectar una única imagen sobre una pared generalmente blanca. Se utilizaban por entonces transparencias de acetato, una buena solución cuando el docente 125 1.1. Contexto necesitaba apoyarse de un dibujo o representación, ya que no sería necesario tenerlo que hacer entero desde cero en una pizarra. Posteriormente llegó la famosa era TIC, la nueva era tecnológica en la que aún vivimos. Aparecieron entonces los primeros ordenadores personales. Y esto a su vez trajo consigo un nuevo método, evolución del anterior y basado en éste: las presentaciones de diapositivas, que hacían uso del programa creado en 1987 para Macintosh, PowerPoint de Microsoft Office [2], que hoy en día todo el mundo conoce. Aunque en su primera versión solamente permitía la creación de diapositivas en blanco y negro que podían imprimirse para su posterior proyección, a partir de la década de 1990, el programa PowerPoint se impuso progresivamente como el soporte privilegiado en el universo de la docencia profesional en muchas de las universidades más importantes de América, y años posteriores, de Europa. Los docentes universitarios comprendieron enseguida el interés en el uso de este programa, ya que este método suponía una nueva forma de dar clase que presentaba gran cantidad de ventajas. Por ejemplo, sirve como alternancia de medios que facilitan la atención de los alumnos, facilita la presentación de los contenidos y conceptos de los temas a tratar, permite volver sobre temas tratados y repetir la presentación de ciertos aspectos cuando no son suficientemente asimilados por los alumnos, permiten señalar directamente sobre las transparencias para incidir en ciertos contenidos o atraer la atención, y por último, ahorran tiempo en la exposición. Por todo esto, tuvo una alta y rápida aceptación entre todo el público en general [3][4]. Tal fue la aceptación y el apoyo de este método que, a día de hoy, es muy habitual el uso de recursos informáticos por parte de los docentes de una forma cada vez superior y, como ya se sabe, ha sufrido una grandísima evolución a lo largo de estos últimos años. En concreto, según los últimos estudios, el 90 % de los profesores de universidad son partidarios del uso de PowerPoint en las clases teóricas [1]. Esto se debe gracias, entre otras cosas, a la evolución de las prestaciones de los programas de presentaciones, como en el caso de PowerPoint (véase la Tabla 1.1). Además, en base a estas evoluciones, hoy en día también se pueden encontrar infinidad de diversos tipos de proyectores, con una cantidad de prestaciones que eran impensables hasta hace muy poco tiempo. En la Tabla 1.1 se puede observar cómo el programa ha ido evolucionando en función de las nuevas necesidades que han ido surgiendo a lo largo del tiempo. Se ve notoriamente el aumento exponencial, en la última década, del aumento de las funcionalidades, quedando sin mencionar además la versión de 2013, donde aún se han seguido aumentando las mismas, y probablemente se seguirá haciendo en versiones futuras. 226 1. Introducción y referencias bibliográficas Tabla 1.1: Evolución de Powert Point 327 1.1. Contexto Y no sólo hay que pensar en el ámbito docente, sino que el gran auge que ha sufrido este método de presentación se debe también a la gran utilización del mismo por parte de las empresas, en sus continuas reuniones cada vez más frecuentes. Tal es la necesidad del uso de estas herramientas día a día por parte tanto de alumnos como de profesores, o de las empresas, que en la actualidad Microsoft ya ha lanzado su paquete Office no sólo para PC, sino también para los nuevos smartphones, tabletas o incluso ordenadores con otros sistemas operativos diferentes al suyo propio. Este hecho es bastante indicativo de cómo se encuentra la situación actual en este mercado. Ésto permite hacerse una idea de la constante evolución que ha sufrido en este ámbito el tema de la enseñanza, reuniones de empresas o conferencias. Somos una de las unidades más rentables de Microsoft, generamos el 48 % de los beneficios de la venta de programas, explicaba Robert Gaskins, uno de los inventores de PowerPoint [6] Tecnología en las aulas Como afirma Natalia (2008): Las tecnologías de la información y las comunicaciones aportan al mundo educativo un complemento o mejora a las enseñanzas tradicionales proporcionando numerosas nuevas opciones [7]. En la nueva era tecnológica es impensable que en una empresa no haya una sala de reuniones con proyector, o que un profesor no pueda dar una clase con diapositivas. Esto se debe a la utilidad y facilidad que proporciona trabajar con ellos. Pero no solo hay que limitarse a esto. El uso de la tecnología en las aulas docentes ha evolucionado mucho en la última década. El uso del proyector no es el único recurso empleado para la práctica docente, aunque sí el más utilizado. Tiempo atrás se comenzaron diversas campañas para la implantación de ordenadores en las aulas de primaria, y posteriormente en secundaria. Lo que se conoce como Escuela TIC 2.0 [10]. También se empezaron a implantar las primeras pizarras digitales interactivas, que consisten en un ordenador conectado a un vídeo proyector, que muestra la imagen de dicho ordenador. Y desde la superficie de la pizarra es posible controlar el ordenador mediante un bolígrafo especial. De forma que se puede escribir, dibujar, señalar, etcétera. Aunque este método no ha tenido todo el éxito esperado y que no ha sido altamente aceptado. Según un estudio de la Universidad de Salamanca (2009) la pizarra digital interactiva se convertiría en el recurso docente más utilizado al cabo de pocos años, y un gran número de aulas docentes contarían con 428 1. Introducción y referencias bibliográficas una de estas pizarras [11]. Pero finalmente, parece que no ha sido así. El caso más reciente sobre la tecnología en las aulas es el reparto de ordenadores portátiles para los alumnos de últimos cursos de primaria. Se ha llegado incluso a repartir tabletas PC según apuntaba Rosa J. en el diario El Mundo el 6 de agosto de Hecho que da una idea de la época en la que nos encontramos. Toda esta evolución se debe a que la tecnología cambia continuamente, y se quiere aprovechar este efecto para facilitar en cualquier medida todo el trabajo posible. Por parte de los alumnos resulta más sencillo seguir una clase o una explicación cuando tiene una referencia visual. Y por parte del docente también es más sencillo seguir con la explicación si éste tiene una referencia visual en la apoyarse. Las TICs son cambiantes, siguen el ritmo de la continua evolución y avances tecnológicos. Y es un hecho que falta aún mucho camino por recorrer en el ámbito de la educación. Como por ejemplo, las aulas de tele enseñanza, que permiten que el profesor esté ubicado en cualquier sitio remoto dotado de videoconferencia. El sistema de audio de ambiente permite participar a cualquier alumno [7] Motivación Llegados a este punto ha quedado claro que el uso de la tecnología, y en especial del proyector, es necesario hoy en día para la docencia y para otras actividades. No hay trabajo sin reunión, y no hay reunión sin presentación apuntaba Franck (2011) [6]. Pero... cómo se puede mejorar algo que está en continua evolución y que tiene detrás grandes empresas que se encargan de las mejoras? En este punto se han de tener en cuenta varios aspectos. En el sistema actual de proyección de material docente es condición necesaria que el portátil esté conectado en todo momento al proyector mediante un cable con conector VGA. Ese cable molesto y que no permite al docente disponer de la movilidad que le gustaría para dar su clase. Ya que, es necesario estar cerca del portátil para poder cambiar de diapositiva. Hecho que provoca que la clase pierda dinamismo, y consecuentemente sea mucho más rígida en movimientos que las explicaciones en la pizarra. En ese sentido, existe la posibilidad de comprar un mando inalámbrico para trabajar con libertad de movimiento. Pero esto supone un gasto para el docente que él no tiene porqué asumir, así como tener que llevarlo siempre consigo. Por otro lado, un inconveniente que también presenta el método actual 529 1.2. Motivación es la necesidad de transportar constantemente el ordenador personal para poder proyectar el material utilizado. Una solución simple a este inconveniente es dejar un PC siempre conectado al proyector y únicamente llevar los archivos en una memoria externa, como un lápiz o una tarjeta de memoria. Pero esta solución supone un gasto grande añadido al presupuesto de la instalación del sistema, además de que es necesario llevar siempre dicho dispositivo de almacenamiento actualizado para cada vez que se quiera utilizar. Y, evidentemente, es más fácil perder u olvidar dicho dispositivo que el ordenador personal. A todo esto se añade una clara tendencia a la creación de los nuevos dispositivos cada vez de menores dimensiones, como la nueva generación de portátiles ultrabook. Lo que está provocando la pérdida o reducción de las posibles conexiones en estos dispositivos. Esto, además del auge en las nuevas tecnologías portátiles como tabletas o móviles, provoca que los nuevos dispositivos tecnológicos no puedan conectarse a los proyectores normales, los habitualmente instalados en las clases, mediante un conector VGA convencional. En su lugar, son necesarios adaptadores a partir de una entrada USB o HDMI, con el inconveniente añadido de tener que comprarlo y tener que llevarlo siempre. Otra opción sería el uso de proyectores con conexión inalámbrica, generalmente Wi-Fi, pero esta es una solución más cara en términos presupuestarios en comparación con un proyector normal. No sería una diferencia excesiva si se tratase de un único proyector, pero sí lo es cuando se trata de un número considerable. Sin ir más lejos, para la propia universidad supondría una inversión económica muy grande cambiar los proyectores de todas sus clases. Por tanto, es motivante buscar una solución que trate de proporcionar la comodidad que supone no tener que depender de cables y conexiones con el proyector. Algo que, a su vez, facilitaría el movimiento del docente en el aula. Además, no debería ser necesario transportar el portátil, sino que sería interesante la posibilidad de poder utilizar cualquier dispositivo electrónico del momento, tal como una tableta o el teléfono móvil que siempre llevamos encima. Y por último, pero no menos importante, una solución lo más económica posible. De esta forma, por un lado existe un campo que está en continua evolución y una tecnología que se utiliza diariamente, como es el método de enseñanza actual o la forma de realizar exposiciones. Y por otro lado se presentan los inconvenientes y problemática asociados, además de las posibles mejoras que se han recopilado. De todas estas ideas surge el tema de este proyecto. Un campo que vivimos diariamente y que nos es muy familiar, con el objetivo de implantar una serie de mejoras sobre el sistema actual pensando que en un futuro no muy lejano pueda llegar a ser una solución real para los problemas anteriormente planteados. 630 1. Introducción y referencias bibliográficas De esta manera, la solución final que se plantee podrá implantarse en las aulas docentes de la propia universidad, algo que es una motivación extra muy especial, para cualquier alumno que realice un trabajo fin de grado de estas características Estudio del estado del arte El objetivo de las tecnologías de la información y comunicación es facilitar nuestra calidad de vida. Cada día se ven avances tecnológicos, estamos totalmente conectados y hemos superado la revolución digital para entrar de lleno en la era tecnología. En la sección 1.1 se ha visto cómo se ha trasladado esto a la educación y los nuevos problemas que se han generado. En esta sección se hará un estudio de algunas de las soluciones existentes, totales o parciales, sobre el ámbito de la tecnología usada y aplicada a los nuevos métodos docentes Proyectores inalámbricos Sin duda alguna el proyector es la solución actual más utilizada por parte de cualquier docente, en especial, de una universidad. Es la forma habitual de trabajo hoy en día aun con los inconvenientes que se han visto anteriormente, en especial la movilidad del docente y la necesidad de conexión mediante un cable. Alguno de estos inconvenientes puede resolverse con los proyectores existentes en estos momentos. En la actualidad existen variedad de tipos de proyectores donde elegir, con diferentes características. En este sentido se pueden diferenciar dos grandes grupos: los proyectores que precisan de conexión física mediante un cable para poder mostrar la imagen, y los que por el contrario, se pueden utilizar de forma inalámbrica. El primer tipo de proyector es el actualmente implantado, y ya se ha comentado la problemática asociada en la seccion anterior. El segundo tipo de proyector es el que interesa en este ámbito. Este tipo de proyectores utilizan tecnología Wi-Fi o Bluetooth para la conexión y comunicación con el ordenador proveedor de imágenes. Esta solución es claramente mejor que los proyectores normales ya que, al utilizar las conexiones inalámbricas no se limita la movilidad del docente sino que se puede utilizar y proyectar la imagen de un ordenador desde cualquier parte de la clase. Por otro lado, también se soluciona el nuevo problema que está surgiendo sobre la pérdida de conexiones, VGA entre otras, en los portátiles actuales de 731 1.3. Estudio del estado del arte nueva generación. En este caso solo sería necesaria una conexión USB donde conectar un dispositivo que trabaja de antena para la transmisión de datos entre ordenador y proyector (solo en algunos casos, depende del producto y del fabricante). Conexión que está presente en prácticamente la totalidad de los portátiles. Tantas son las ventajas que presentan estos proyectores que su evolución y utilización está en presente auge. Las principales empresas del sector como Sony, Panasonic o Mitsubishi ofrecen muchas prestaciones y posibilidades que mejoran el sistema actual utilizado [13][14][15]. Tal está siendo dicha evolución que Sony, una de las principales empresas presentes en el mercado actual, diseñan sus productos en función del sector al que está destinado; escuelas, universidades o empresas entre otros, como así se puede ver en sus propios artículos [16]. Aunque por otra parte, estos proyectores hoy en día son poco comunes. Es raro encontrar un proyector de estas características en un aula normal de universidad. Aunque sí puede ser una solución más habitual para una sala de reuniones de una empresa. Pero por lo general, este tipo de proyectores suelen ser más caros que los proyectores normales. El principal problema de esta solución puesto que las alternativas más económicas sitúan el valor mínimo de un proyector de estas características en los 1000e según las principales página de ventas. Por tanto, la implementación de esta solución supondría un gasto muy elevado en la adquisición de dichos proyectores. Además de tener que sustituir los proyectores presentes en las aulas de la universidad actualmente. Algo que no resulta necesario puesto que se puede encontrar una solución más económica a ésta y donde se puedan reutilizar los proyectores actualmente instalados. En este punto se podría utilizar un adaptador mediante el cual se permita conexión inalámbrica al proyector. Uno de los ejemplos es el dispositivo ofrecido por Ipevo [17]. Pero dicho dispositivo sigue sin ser lo suficiente económico, por lo que el problema de esta solución, aunque menor que los proyectores con Wi-Fi, sigue siendo el precio Pizarra interactiva y Tablet Monitor Se ha visto en la sección en qué consistía y cuál era la principal función de la pizarra digital interactiva. Por lo general, es un accesorio que se suele adherir a una superficie rígida para convertirla en una pizarra interactiva. Así, la única diferencia entre esto y el caso anterior es la interactividad con la pizarra, pero esto no soluciona los problemas mencionados. La ventaja ofrecida no es del interés de este estudio. 832 1. Introducción y referencias bibliográficas Para encontrar ventajas que puedan ser de utilidad para el caso que concierne es necesario un segundo elemento, una tableta monitor. Este dispositivo se conecta al ordenador sin cables (por ejemplo a través de Bluetooth) y en algunos casos hasta permite que varios usuarios actúen simultáneamente en trabajos en equipo, lo que permitiría interacción entre alumnos y profesor. El término Tablet Monitor identifica al periférico desde el que se realiza el control del ordenador y las anotaciones manuscritas. Es un monitor especial (combinación de monitor y tableta) diferente a una tableta convencional, una Tablet-PC. En este caso el ordenador se conecta a un proyector y la imagen de la pantalla es proyectada en la pizarra y visualizada en la tableta monitor [19]. Este dispositivo tiene la ventaja de que se puede trasladar a cualquier lugar, uno de los principales inconvenientes mencionados. Y no se limita sólo al aula, sino que se pueden realizar clases y conferencias a distancia en tiempo real a través de Internet, permitiéndose la conexión entre la tableta monitor y el ordenador conectado al proyector. Se presentan múltiples ventajas en el trabajo cooperativo entre las pizarras interactivas y las tablets monitor. Esta solución mejoraría el problema de la movilidad. Pero presenta un grave problema esta solución. Al igual que el caso anterior, el precio de este producto es muy elevado. Una pizarra interactiva supera los 1000e según la web informativa pizarrasinteractivas.com/ [20], siendo éstas las de menor precio y por tanto las de menores prestaciones. A lo que hay que añadirle el precio de una tableta monitor para cada profesor que vaya a impartir clase con este método docente como mínimo. Sumando todo el gasto supone un muy elevado inconveniente. Además de ser totalmente innecesario para una entidad que necesite instalar muchos sistemas de este tipo, por ejemplo la universidad. La inversión sería de una pizarra interactiva por cada clase, y una tableta monitor por cada profesor. Y la mejora introducida no deja de ser únicamente la movilidad del docente. Por lo que se debe descartar esta opción como posible solución final. Es una única mejora para una elevada inversión presupuestaria Apple TV y AirPlay Apple TV [21] es un receptor digital multimedia diseñado, fabricado y distribuido por Apple [22]. El dispositivo está diseñado para reproducir contenido multimedia digital desde itunes Store, YouTube e icloud entre otros, en una televisión de alta definición. Pero Apple TV no sólo se limita al contenido almacenado en estos sitios, sino que puede utilizarse el contenido 933 1.3. Estudio del estado del arte multimedia de un ordenador Mac OS X o Windows con itunes. Éste es un dispositivo diseñado principalmente para el ocio que puede ser utilizado en casa para uso personal del contenido multimedia. Pero Apple TV no solo se limita al contenido multimedia presente en la red. Gracias a la tecnología AirPlay [24] de Apple, se puede ver todo el contenido almacenado en un Mac o cualquier dispositivo ios. De forma que puede ser utilizado para proyectar imágenes, vídeos, o presentaciones digitales, que es lo importante en este caso de estudio y además es posible hacerlo desde portátil, tableta o smartphone. Apple TV es pequeño y compacto, potente por la gran cantidad de posibilidades que ofrece y de fácil configuración para cualquier persona. Algo que encajaría en cualquier sitio, y que puede ser usado en términos profesionales, como es el caso que nos concierne, la docencia. En este sentido, se puede colocar este dispositivo conectado a un proyector mediante el adaptador HDMI, y proyectar el material que se desee desde cualquier dispositivo. De hecho, ya se ha realizado un estudio del uso de este dispositivo en este ámbito por la Universidad Rovira i Virgili (URV), Aumentando la interacción en el aula ordinaria mediante el ipad y demás dispositivos de m-learning (2014) [25]. En él se ha empezado a utilizar dicha tecnología junto con ipads de forma que todo el mundo puede ver lo que se está viendo en un ipad concreto, lo que ayuda a seguir la clase sin distracciones. La arquitectura básica de funcionamiento que se ha implantado puede verse en la siguiente imagen (Figura 1.1). Esta arquitectura es la propuesta por GoClass [26], una plataforma de enseñanza que se basa en el uso de dispositivos móviles comunes para realizar cualquier tipo de tarea. De esta forma se permite conexión total entre alumnos y profesor, tanto fuera como dentro de clase. GoClass propone un nuevo tipo de enseñanza basado en la nube y los nuevos dispositivos portátiles. De forma que se puedan utilizar dispositivos móviles, PC y pantallas de proyección para conectar a los estudiantes unos a otros, así como al profesor y consecuentemente lo que este está proyectando. Aunque este método aún no es muy extendido tiene posibilidades para un futuro. Esta solución al contrario que soluciones anteriores, no solo mejoraría la movilidad del docente, sino que gracias a la tecnología AirPlay se produce la uniformidad de las tecnologías, pudiendo utilizar para la presentación el portátil, tableta o móvil. Pero esto no son todo ventajas, también tiene un inconveniente bastante importante. Es absolutamente necesario que el dispositivo tenga instalado un sistema operativo ios para poder hacer uso de la tecnología AirPlay. Dispositivos que únicamente son distribuidos por la misma compañía que el dispositivo principal, Apple. 1034 1. Introducción y referencias bibliográficas Figura 1.1: Estructura de funcionamiento de sesión multimedia estándar con ipad [26] 1135 1.3. Estudio del estado del arte Esto quiere decir que los profesores tendrán que tener portátil, tableta o móvil de la compañía Apple, algo que no es del agrado de todos ellos. Hecho que descarta totalmente esta solución, aunque el dispositivo presente un precio asequible (según la página oficial 112e)[21]. La solución finalmente adoptada no debe suponer ningún gasto o inconveniente adicional para ningún docente, puesto que se trata de mejorar lo actual sin que esto conlleve un cambio importante en él Wireless Display y Miracast Como alternativa a la tecnología propuesta por Apple (Apartado 1.3.3), se puede encontrar Wireless Display [28]. Un dispositivo cuya función es básicamente la misma que Apple TV. Wireless Display trata de compartir contenido desde cualquier teléfono inteligente, tableta o PC hasta una televisión HD sin necesidad de cables. Sus características y funciones son prácticamente iguales a las del caso anterior, pero hay una diferencia más que notable. Apple TV corresponde a un único dispositivo y que funciona únicamente con otros dispositivos Apple. En cambio existen gran cantidad de dispositivos pueden ser utilizados en este caso. Lo que elimina la necesidad de tener en posesión un dispositivo Apple. Estos dispositivos utilizan la tecnología Miracast [30]. Miracast es un estándar creado por la Alianza Wi-Fi y que consiste fundamentalmente en una red peer-to-peer utilizada para enviar screencast de forma inalámbrica formando conexiones Wi-Fi Direct de forma similar a como lo hace Bluetooth. De este modo, permite la distribución inalámbrica de la imagen desde o hacia ordenadores, tabletas, teléfonos móviles y otros dispositivos conectados. Tanto el dispositivo emisor como el receptor deben soportar la tecnología Miracast para funcionar, uno de los principales inconvenientes de la actualidad. Según se publicó en algunas páginas de noticias relacionadas con este ámbito todos los dispositivos con Android 4.2 o superior tienen soporte para Miracast, aunque también explican que el rendimiento en la práctica no es tan bueno como el que teóricamente se espera. Según se ha podido leer en Miracast no ha triunfado como se le esperaba. Pocos fabricantes han adoptado el estándar, y los que lo han hecho no funcionan lo bien que se desearía. Un serio inconveniente de compatibilidad que dificulta el estudio de este sistema como posible solución. 1236 1. Introducción y referencias bibliográficas Chromecast Dentro este mismo ámbito cabe destacar Chromecast [32], que es el principal competidor de Apple TV, por nombre y sobre todo por precio, en torno al 70 % más económico que el anterior (35e según la página web oficial). En cuanto a las características, parecido a los dispositivos comentados anteriormente. Aunque existen varias diferencias que hacen de este dispositivo una mejor solución a las anteriores. En primer lugar es compatible con todas las versiones de los sistemas operativos más utilizados del momento a partir de Android 2.3, ios 6.0, Windows 7, Mac OS 10.7 y por supuesto Chrome OS. Pero este dispositivo, al igual que el resto de los anteriores, también presenta varios inconvenientes. Éstos son unos dispositivos relativamente recientes, y con un margen de crecimiento y mejora aún por concretar, por lo que lo ideal sería esperar antes de adquirirlos. Para una persona normal no supone un gran gasto adquirir uno para ocio personal, pero para la universidad supone una inversión grande, por lo que se ha realizar un estudio en profundidad antes de realizar la compra. Además, al contrario que los anteriores, no permite screen mirroring por lo que no se puede ver la imagen de la pantalla de nuestro dispositivo. Simplemente se puede seleccionar el contenido y reproducirlo. Llegando así a otro de sus inconvenientes, es necesario tener el contenido almacenado en el dispositivo para poder reproducirlo. Algo que intenta solución este proyecto Resumen Finalmente, la Tabla 1.2 muestra un esquema-resumen de todos los productos o métodos actuales vistos en este capítulo como posibles soluciones al problema planteado en el capítulo anterior. Como se puede ver, en todas las soluciones propuestas en la actualidad, salvo Apple TV, es necesario tener el documento a mostrar guardado en el propio dispositivo, o descargarlo justo antes de mostrarlo. La solución que se propone en este proyecto pretende eliminar este inconveniente para que en todo momento el docente pueda utilizar el dispositivo que mejor le convenga a la hora de dar clase; ordenador, tableta o móvil, sin necesidad de llevar la presentación preparada y guardada en dicho dispositivo. Además se ve en la tabla que el inconveniente que más veces aparece es el precio del dispositivo o de la instalación. La solución final debe tener un precio total suficientemente bajo como para que se convierta en una solución real por la que puedan optar las empresas o la propia universidad. 1337 1.3. Estudio del estado del arte Solución Ventajas Inconvenientes Proyectores inalámbricos Movilidad Conexión de diferentes dispositivos Precio Desperdicio de los proyectores actuales Pizarra interactiva Movilidad Interacción con la pizarra Precio por unidad Necesidad de una Tablet Monitor por docente Apple TV Movilidad Conexión de diferentes dispositivos Almacenamiento centralizado (icloud) Precio Necesidad de un dispositivo ios Dispositivos Miracast Movilidad Económico Conexión de diferentes dispositivos Screen mirroring Necesidad de un dispositivo compatible con Miracast Aún en desarrollo Chromecast Movilidad Solución más barata Compatibilidad con la mayoría de S.O. actuales Sin screen mirroring Aún en desarrollo Sin almacenamiento centralizado Tabla 2.1 Comparación de las soluciones existentes Tabla 1.2: Comparación de las soluciones existentes 14 838 1. Introducción y referencias bibliográficas 1.4. Objetivos y alcance del proyecto En este apartado se exponen brevemente, a modo de introducción, los principales objetivos del proyecto. Detallándose posteriormente en profundidad los mismos en el Capítulo 3. El principal objetivo del presente proyecto consiste en solventar los problemas descritos anteriormente. Para ello la solución final debe facilitar la movilidad del docente por toda el aula de enseñanza. Además deberá ser fácilmente portable de forma que en un futuro se permita el uso de diferentes tipos de dispositivos electrónicos para proyectar e interactuar con el material docente. Además, se busca centralizar el almacenamiento de los materiales didácticos para así evitar su transporte al aula. Se realizará en este sentido un servicio en el que cada usuario tenga una cuenta donde poder guardar los archivos que pretende utilizar. Y posteriormente, con esa misma cuenta poder mostrarlos en el proyector que él mismo decida, mediante el uso de una plataforma web. Dicha plataforma es soportada por todo tipo de dispositivos, lo que consigue unificar esta tecnología para que cualquier dispositivo de los anteriormente mencionados pueda ser utilizado de forma indistinta por el docente para proyectar su material. Para el cumplimiento de estos objetivos, se especificarán una serie de requisitos (véase la sección 3.2) que la solución final debe cumplir. En este ámbito se podrán distinguir requisitos funcionales, y no funcionales como seguridad, rendimiento y usabilidad entre otros. Este proyecto se ha pensado y realizado con vista a un futuro cercano, donde se pueda llevar a cabo el montaje del producto final, de forma rápida y sencilla, por parte de cualquier persona o entidad que lo desee. Además se dejará la puerta abierta para las futuras mejoras que se puedan implantar Estructura de la memoria La presente memoria del proyecto está formada por ocho capítulos. A continuación se realiza una breve descripción de cada uno de ellos: Capítulo 1. Introducción y referencias bibliográficas. Este capítulo establece el contexto donde se sitúa el presente proyecto, trata los motivos fundamentales que han suscitado la creación del mismo, se muestran las soluciones que existen actualmente al problema y se exponen los principales objetivos a cumplir por éste. Capítulo 2. Planificación y estimación de costes. Se describe el presupuesto del proyecto y la evolución temporal estimada para su 1539 1.6. Principales referencias utilizadas realización. Capítulo 3. Análisis de objetivos y metodología. Se describen los objetos que el proyecto quiere alcanzar y requisitos tanto funcionales como no funcionales que debe cumplir el producto resultante. Capítulo 4. Diseño y resolución del trabajo. Se describe el diseño realizado para la solución del problema planteado. Esto incluye tanto el diseño general, como el diseño de los distintos elementos que constituyen el producto. Además, se describen los pasos seguidos y cómo ha sido la realización la implementación del anterior diseño. Capítulo 5. Evaluación y pruebas. Se definen los posibles entonces de utilización del producto y se evalúa el resultado en cada uno de ellos. Capítulo 6. Conclusiones y vías futuras. Se muestran las conclusiones obtenidas en función de los resultados anteriores y se expone una posible línea de mejora para posibles trabajos futuros. Posteriormente se encuentran anexos a este documento un manual de usuario con las funciones básicas del producto y la forma correcta de utilización, así como un manual de instalación para quien quiera desplegar la solución propuesta. Y finalmente se muestran todas las referencias bibliográficas que se han consultado para realizar este proyecto Principales referencias utilizadas En este apartado se exponen las principales fuentes consultadas para la realización de este proyecto, mostrándose la totalidad de ellas en la bibliografía. 16 E. Upton and G. Halfacree, Raspberry Pi. Madrid: Anaya Multimedia, G. Carter, LDAP System Administration. Sebastopol, CA: O Reilly, Y. Fernández Hansen, A. A. Ramos Varón and J. García Morán, AAA - RADIUS x: Sistemas Basados En La Autenticación En Windows y Linus-GNU: Seguridad Máxima. Madrid: Ra-Ma, S. McCracken, Curso de programación Web con HTML5, CSS, JavaScript, PHP 5.6 y MySQL pp. 1148, 2011.40 1. Introducción y referencias bibliográficas Manual oficial de PHP disponible en: es/index.php Documentación oficial de Java disponible en: com/javase/7/docs/api/ 1741 42 Capítulo 2 Planificación y estimación de costes 2.1. Recursos Humanos D. Jorge Navarro Ortiz, profesor del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, en calidad de tutor del proyecto. Juan Ramón Gutiérrez Martínez, alumno de la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación Hardware Ordenador personal con: Servidor Web (Apache) [36] Servidor FTP (VSFTP) [37] Servidor RADIUS (FreeRADIUS) [38] Base de datos (LDAP) [39] Raspberry Pi [40] Proyector con entrada HDMI 1943 2.2. Fases de desarrollo Nombre 2014, MI oct 2013 I nov 2013 I dic 2013 ene 2014 Ifeb 2014 I mar 2014 I abr 2014 ImaY2014 Ijun 2014 Revisión del estado del arte 20d Análísis de objetivos y }5d especificación de requisitos 30d Diseño l 60d Implementación I 30d Evaluación y prueba I 195d Documentación Figura 2.1: Diagrama de Gantt con la planificación temporal Concepto Comienzo Fin Duración Revisión del estado del arte 01/10/13 28/10/13 20 Análisis de objetivos y requisitos 01/11/13 21/11/13 15 Diseño 25/11/13 03/01/14 30 Implementación 11/02/14 05/05/14 60 Evaluación y pruebas 06/05/14 16/06/14 30 Documentación 01/10/13 30/06/ Software Tabla 2.1: Planificación temporal del proyecto Sistema operativo GNU/Linux Ubuntu para el ordenador personal [41] Sistema operativo GNU/Linux Raspbian Debian Wheezy para la Raspbeery Pi [42] Java versión 8.5 [43] Lenguaje de programación PHP versión [44] Entorno de desarrollo Netbeans 8.0 [45] Visor de archivos PDF MuPDF [46] 2.2. Fases de desarrollo La distribución temporal de las distintas fases del proyecto se puede ver en el diagrama de Gantt de la Figura 2.1 y en la Tabla Revisión del estado del arte Se hace un repaso de las soluciones existentes hasta el momento, totales o parciales, sobre el mismo ámbito de aplicación del problema a resolver con 2044 2. Planificación y estimación de costes el objetivo de sentar una base que justifique la realización de este proyecto Especificación de los requisitos Se analiza el problema en pos de una correcta especificación de requisitos, funcionalidades y restricciones que delimitan el posterior diseño de una solución en función de unas especificaciones y medidas de seguridad de una solución Diseño Se ha de adoptar justificadamente una solución previamente especificada y se procede a su diseño atendiendo en todo momento a los requisitos previamente definidos sobre prestaciones y seguridad Implementación Se ha de implementar el diseño anterior atendiendo a los lenguajes de programación y características escogidas. Realizando un rediseño de alguna característica una vez comenzada la implementación si fuese oportuno Evaluación y pruebas Tras la comprobación y puesta a punto, se procede a la evaluación de la solución, contrastando su funcionamiento y resultados, si procede, con otras soluciones vistas durante la revisión del estado del arte Documentación La redacción de la documentación es una tarea que se ha de llevar a cabo de forma paralela al resto del proyecto Estimación de costos La duración total estimada para la realización del proyecto es de 160 días aproximadamente, sí en la planificación anterior (Figura 2.1) no se tienen en cuenta fines de semana ni días festivos, así como tampoco se contará el periodo de exámenes. Una jornada laboral normal dura 8 horas, pero teniendo en cuenta que el proyecto no es lo único en lo que se ha trabajo se reducirá a 2145 2.3. Estimación de costos Concepto Coste/Tiempo Cantidad Total Trabajo individual 15 e/hora 640 horas e Tutorías 40 e/hora 15 horas 600 e Total: Tabla 2.2: Coste monetario personal del proyecto e la mitad el número de horas de una jornada para un cálculo más realista. Lo que hace un total de 640 horas de trabajo. Con respecto al tutor del proyecto, se estiman unas 10 tutorías de aproximadamente 1 hora y media de duración cada una. Por tanto, el número total de horas consideradas para el completo desarrollo del proyecto asciende a un total de: 655 horas. El precio de cada hora del proyecto se ha calcula de acuerdo a los honorarios de un Ingeniero Técnico de Telecomunicación. Según la Junta General del Colegio Oficial de Ingenieros de Telecomunicación (COIT) [47] los honorarios de un Ingeniero de Telecomunicación, son libres y responden al libre acuerdo entre el profesional y el cliente. Dada esta situación, los honorarios deben definirse en función de una serie de factores: costes del ingeniero, desplazamientos, volumen de la actividad, etcétera. Teniendo en cuenta estos elementos se han definidos unos honorarios de 15 e/hora. Y con respecto a los honorarios del tutor (Dr. Ingeniero de Telecomunicación), se han fijado a 40e/hora Recursos humanos En la Figura 2.1 y Tabla 2.1 puede verse el coste temporal de las diferentes partes del trabajo. En la Tabla 2.2 se detalla el coste asociado a los recursos humanos. Por lo que los gastos de personal con el I.V.A. son e. Y con estos datos de la Tabla 2.1 y Tabla 2.2, se obtiene la Figura 2.2, que refleja el coste monetario asociado a cada una de las fases del proyecto, siendo el coste asociado restante el equivalente a la finalización de la documentación y las horas de tutorías Herramientas Para la implementación se han empleado herramientas software gratuitas siempre que ha sido posible para minimizar el coste del proyecto. En la 2246 2. Planificación y estimación de costes 4000 Coste ( ) Revisión del Estado del Arte Especificación de los Requisitos Diseño Implementación Evaluación y Pruebas Coste ( ) Figura 2.2: Coste monetario asociado a cada fase del proyecto Tabla 2.3 se recoge el coste monetario de los recursos software y hardware en proporción al tiempo empleado en la realización del proyecto (9 meses). Aclarar que el monitor ha sido empleado en las fases de implementación y evaluación para facilitar el trabajo Presupuesto Por último, la Tabla 2.4 resume el presupuesto total del proyecto. 2347 2.4. Presupuesto Recurso Coste unitario Cantidad Total Ordenador personal 800 e 36 meses 200 e Raspbery Pi 50 e 36 meses 12,5 e Proyector 200 e 120 meses 15 e Monitor con entrada HDMI 150 e 96 meses 14 e Conexión ADSL 40 e/mes e Sistemas operativos 0 e - 0 e Entorno de desarrollo (Netbeans) 0 e - 0 e Software complementarios 0 e - 0 e Paquetes de ofimática 0 e - 0 e Tabla 2.3: Coste monetario material del proyecto Total: 601,5 e Concepto Cantidad Recursos humanos 1 desarrollador x 160 días x 5 horas/día x 15 e/hora e 1 tutor x 10 días x 1,5 horas/día x 40 e/hora 600 e Recursos materiales Raspbery Pi 12,5 e Proyector 15 e Monitor con entrada HDMI 14 e Conexión ADSL 360 e Sistemas operativos 0 e Entorno de desarrollo (Netbeans) 0 e Software complementarios 0 e Paquetes de ofimática 0 e Tabla 2.4: Presupuesto total Total: ,5 e 2448 Capítulo 3 Análisis de objetivos y metodología En la sección 1.4 se describieron brevemente los objetivos y el alcance del proyecto. En este capítulo se hará un análisis con mayor profundidad de los objetivos del proyecto mediante un análisis de los requisitos generales que se precisan. En primer lugar se describe un análisis general de la situación y se exponen los principales objetivos que se han previsto al inicio de este proyecto. En segundo lugar se desarrollan en mayor detalle los principales requisitos que se consideran imprescindibles para el desarrollo del proyecto, de forma que se cumplan los objetivos anteriormente descritos. Y finalmente se realiza un estudio de la metodología seguida para la realización del proyecto y una valoración final sobre los objetivos alcanzados Descripción global La especificación de objetivos y requisitos es uno de los temas importantes que se han de tratar desde el comienzo de un proyecto. Un punto fundamental de este proyecto es que el producto salga finalmente al mercado con relativo éxito, y para ello ha de cumplir una serie de requisitos específicos. En este apartado se hará una descripción general de la situación. Perspectiva El objetivo final del proyecto es la creación de un sistema de proyección de material docente basado en Raspberry Pi. Así, el esquema resultante consiste en una aplicación cliente desde la cual el docente pueda manejar de forma transparente dicho material. Para ello se utilizará un 2549 3.1. Descripción global servidor instalado en una Raspberry Pi conectada al proyector mediante la interfaz HDMI, de forma que finalmente se permita la movilidad del docente por el aula, así como la utilización de cualquier dispositivo para dicho fin. Raspberry Pi Raspberry Pi [40] es un ordenador de placa reducida de muy bajo costo, a un precio muy asequible [49], desarrollado por la Fundación Raspberry Pi, con el objetivo de estimular la enseñanza de ciencias de la computación en las escuelas. El diseño incluye un potente procesador central 700 MHz y 512 MB de memoria RAM. El diseño no incluye un disco duro ni unidad de estado sólido, ya que usa una tarjeta SD para el almacenamiento permanente; tampoco incluye fuente de alimentación ni carcasa. Además tiene unas dimensiones suficientemente pequeñas como para colocar en cualquier lugar y transportar sin ningún tipo de problema [50]. Este sistema empotrado o embebido puede soportar diferentes sistemas operativos y lenguajes de programación. Esto convierte a Raspberry Pi en una herramienta muy versátil que aporta grande ventajas al diseño e implementación de este proyecto. Principales objetivos previstos Como se ha venido describiendo, la solución finalmente implementada debe solucionar todos o la gran mayoría de los problemas planteados en el Capítulo 1 sobre el actual método docente utilizado en las universidades. De esta forma se pueden diferenciar una serie de objetivos que ha de cumplir el proyecto para que la solución implementada sea la idónea: 26 Se deben eliminar las conexiones mediante cable. De forma que la conexión inalámbrica permita la movilidad del docente por toda el aula de enseñanza mientras éste imparte su clase. Debe ser fácilmente portable a diferentes tecnologías y sistemas operativos de forma que en un futuro se pueda utilizar en diversos entornos diferentes. Debe existir un sistema de gestión del material centralizado de forma que no sea necesario llevar el material guardado en los dispositivos para que éste sea proyectado.50 3. Análisis de objetivos y metodología Debe ser una solución de fácil instalación y transporte, de forma que el sistema pueda ser instalado un una clase y se pueda cambiar a otra de forma sencilla. Por supuesto debe ser muy económico, tanto como para que pueda ser instalado sin asumir un gasto considerable. Como se puede intuir, simplemente gracias a utilizar una Raspberry Pi como base de nuestro sistema se van a poder cumplir la mayoría de estos objetivos. Objetivos secundarios previstos Estos objetivos secundarios corresponden a objetivos que no son obligatorios para la realización del proyecto, pero que sí añaden características interesantes a la funcionalidad final. Estos objetivos, al no ser obligatorios, sólo se intentarán cumplir al terminar los objetivos principales y si el tiempo lo permite. Son los siguientes: El material docente debe ser en formato PDF como mínimo. Así, es un objetivo secundario ampliar dicha funcionalidad posteriormente a otros formatos de imágenes o documentos. El sistema de seguridad y autenticación de usuarios se debe adaptar al sistema utilizado por la Universidad de Granada. De esta forma se facilitará la tarea de la posterior implantación en las aulas. El sistema inicial cuenta con una única Raspberry Pi. Se debe incorporar una base de datos adicional a la base de datos de los usuarios de forma que ésta contenga la información de las localizaciones de los proyectores. Así se podrá elegir en qué aula mostrar el material cuando existan varios sistemas instalados. Debe unificar las tecnologías actuales, de forma que sea indiferente el uso de ordenador, tableta o smartphone para proyectar el material. Debe incorporar un sistema que permita mostrar y visualizar en el proyector la imagen de la pantalla del dispositivos utilizado. Estos objetivos son de gran complejidad y suponen una inversión de tiempo tal que no se puede asegurar su cumplimiento, de ahí que sean objetivos secundarios. 2751 3.2. Especificación de requisitos 3.2. Especificación de requisitos Esta sección describe los requisitos equivalentes a la implementación con el nivel de detalle suficiente que permita diseñar un producto final que cumpla con los objetivos previstos de la sección anterior. La sección está dividida a su vez en tres subsecciones, atendiendo a los requisitos funcionales, no funcionales y de las interfaces de usuario Requisitos funcionales Para la definición de los requisitos funcionales, se ha optado por un diagrama de flujo de datos sencillo de nivel superior. El diagrama de nivel superior define un nivel de abstracción más bajo que las relaciones del sistema con el exterior. Para este caso, esto se traduce en las entradas y salidas del mismo. Como se aprecia en la Figura 3.1, se requieren tres entradas los datos de usuario, el archivo que se quiere mostrar y la localización del proyector (dirección IP de la Raspberry en concreto) y ofrece una única salida: muestra dicho archivo por el proyector seleccionado. El cliente necesita las tres entradas para poder establecer la conexión inicial con el servidor. Una vez que la conexión está establecida y se muestra el material, simplemente se mandan peticiones del tipo cliente-servidor donde cada petición corresponde con un acción que se pueda realizar sobre el material mostrado (e.g. avanzar a la siguiente página). El servidor estará constantemente escuchando peticiones del cliente, y además, sólo será capaz de servir a un cliente cada vez. Sólo se puede mostrar un documento en el proyector Requisitos no funcionales En este proyecto, quizá los requisitos no funcionales son los más restrictivos y los más importantes a cumplir de cara al usuario final del producto. Sofware y compatibilidad 28 En la implementación se utilizarán los lenguajes de programación Java y PHP, de modo que el código sea de fácil comprensión para facilitar la incorporación de nuevas mejoras en un futuro. Además, de esta forma se consigue que sea fácilmente portable a diferentes dispositivos y sistemas operativos para conseguir finalmente que se pueda utilizar en cualquier dispositivo en un futuro.52 Requisitos funcionales Para la definición de los requisitos funcionales, se ha optado por un diagrama de flujo de 3. Análisis de objetivos y metodología datos sencillo de nivel superior. El diagrama de nivel superior define un nivel de abstracción más bajo que las relaciones del sistema con el exterior. Para este caso, esto se traduce en las entradas y salidas del mismo. Como se aprecia en la Figura 4.1, se requieren tres entradas los datos de usuario, el archivo que se quiere mostrar y la localización del proyector (dirección IP de la Raspberry en concreto) y ofrece una única salida: muestra dicho archivo por el proyector seleccionado. Datos de usuario Documento Localización Cliente petición respuesta Servidor Documento en el proyector Figura Figura 3.1: 4.1. Diagrama de flujo de de datos datos de alto denivel alto nivel El cliente necesita las tres entradas para poder establecer la conexión inicial con el servidor. Una vez que la conexión está establecida y se muestra el material, simplemente se mandan peticiones del tipo cliente-servidor donde cada petición corresponde con un acción que se pueda realizar sobre el material mostrado (e.g. avanzar a la siguiente página). 4 2953 3.2. Especificación de requisitos Seguridad Uno de los requisitos más importantes. Cada usuario debe tener su cuenta propia, de forma que solo él pueda utilizar su material docente y nadie más pueda verlo. Así, de esta forma, toda comunicación que se produzca debe ir cifrada. Rendimiento La implementación final no puede ser lenta en cuanto a velocidad de reacción frente a las órdenes mandadas por el docente, es decir, debe tener un buen rendimiento. Disponibilidad y operatividad El producto final debe tener un alto porcentaje de disponibilidad para que el docente no tenga ningún imprevisto a la hora de realizar su trabajo. Gestión de fallos y estabilidad El sistema final debe ser estable frente a cualquier suceso. Tendrá un sistema de control y recuperación frente a fallos, de forma que no afecte al comportamiento de cara al usuario final. Se incorporará además un completo registro de los mensajes de fallos, advertencias, o información que se produzcan. Interoperabilidad No sólo debe existir interoperabilidad a la hora de usar uno u otro dispositivo por parte del docente, sino que además debe de ser indiferente el tipo de proyector utilizado. Todas las combinaciones posibles de dispositivo y proyector deben funcionar correctamente. Portabilidad Según el requisito anterior, se podría cambiar el producto de una clase a otra y debe funcionar perfectamente. Por tanto, se ha de realizar de forma que sea portable y de fácil transporte (pequeñas dimensiones, poco peso, etcétera). Interfaz y usabilidad 3054 3. Análisis de objetivos y metodología Costo Se independizará la interfaz de usuario del resto de la implementación de forma que el usuario no necesite saber nada del funcionamiento del producto para poder usarlo. El producto final debe tener un costo de implementación bajo, de forma que el precio final de cara al público sea muy pequeño en comparación a las funcionalidades que ofrece. Extensibilidad El producto final quedará con código abierto y perfectamente documentado para que cualquier persona que quiera pueda seguir mejorando y utilizando el producto, siempre y cuando sea para no comercial, y se pida antes el permiso de las autoridades pertinentes Requisitos de la interfaz de usuario En este apartado se describen las interfaces diseñadas para que el usuario utilice la aplicación. Se pueden distinguir dos interfaces, la correspondiente al servidor colocado en la Raspberry Pi y la interfaz del cliente. En este sentido la interfaz del servidor se minimiza considerablemente puesto que el usuario solo debe lanzar el servidor mediante la línea de comandos y este queda activo hasta que el usuario vuelve a apagarlo. Por tanto, la interfaz se reduce a la línea de comandos donde se muestran los principales mensajes de los principales sucesos. En lo que respecta a la interfaz que el usuario final utilizará debe de ser: Intuitiva: que el usuario sepa cómo y dónde realizar cada acción. Fácil de usar: que cualquier usuario que no conozca el producto aprenda de forma rápida. Recuperación frente a errores: que la interfaz esté siempre operativa. En este aspecto, se han de diferenciar entre otras dos interfaces en la aplicación correspondiente al cliente. Entre ellas se diferencia una correspondiente al entorno web desde donde se administrará la cuenta de usuario, así como el material docente. Y otra interfaz que es la correspondiente al manejador de ficheros, es decir, la interfaz utilizada para mandar las órdenes utilizadas para controlar el documento que se está mostrando en el servidor de la Raspberry Pi. Aunque esta interfaz estará integrada también en el 3155 3.3. Metodología entorno web, para facilitar la tarea y aumentar así la compatibilidad de los dispositivos. Interfaz Web Esta interfaz corresponde con una sencilla e intuitiva página web, donde cada usuario puede ver sus archivos guardados en el servidor de ficheros central, así como borrar, descargar, o guardar nuevos archivos entre otras acciones. Esta interfaz no es uno de los puntos fuertes del producto, aunque se podrá ir mejorando con el tiempo, por lo que su desarrollo e implementación no debe llevar mucho tiempo. Además desde dicha interfaz se debe de poder comenzar la conexión con el servidor situado en la Raspberry Pi seleccionada (según la clase en la que se encuentre), de forma que se abra el documento, se muestre por el proyector y se abra en el entorno web la interfaz de la aplicación. Interfaz de la aplicación En este ámbito, se denominará aplicación a la ventana que se utiliza para mandar las órdenes al servidor que se encuentra en la Raspberry Pi, e.g. avanzar una página. De esta forma dicha interfaz permite controlar lo mostrado por el proyector. Esta interfaz tendrá la forma de una ventana como cualquier otro programa, con diferentes pestañas para organizar de forma intuitiva las órdenes según diferentes grupos. Los grupos estarán constituidos en función de lo que realicen (buscar, avanzar a una página determinada, cerrar, etcétera). Se incluyen además dos botones principales para avanzar y retroceder las páginas una a una, ya que esta es la acción que más veces se utilizará por parte del usuario final Metodología En este apartado se mostrarán los diferentes pasos o etapas que se han seguido para la realización de este proyecto. En primer lugar se hace un repaso de las soluciones existentes hasta el momento, totales o parciales, sobre el mismo ámbito de aplicación del problema a resolver con el objetivo de sentar una base que justifique la realización de este proyecto. Se estudian de esta forma las ventajas e inconvenientes de cada una de ellas, de modo que se pueda diseñar finalmente una solución que cubra un conjunto de algunas de las principales ventajas de todas ellas. 3256 3. Análisis de objetivos y metodología En segundo lugar se han de especificar claramente cuáles son los principales objetivos que se desean lograr a la finalización del proyecto, con la intención de tener presente en todo momento cual es el objetivo final y cuál será el mejor camino para llegar a él. Además, también se especifican una serie de objetivo de tipo secundario. Objetivos que se deben tener en cuenta mientras se realiza la implementación de producto final, pero que no son de igual importancia que los objetivos principales. Estos objetivos equivaldrán generalmente a requisitos adicionales que se pueden añadir al producto final para aumentar sus funcionalidades o facilitar las posibles vías futuras que puedan existir, y que requieran de un grado de complejidad mayor o de un tiempo de implementación demasiado excesivo. Después se analizan problema y objetivos en pos de elaborar una correcta y completa especificación de los requisitos necesarios para cumplir con todos los objetivos que se deben cumplir, funcionalidades que se deben implementar y restricciones que delimitarán el posterior diseño. Una vez se tienen claros cuales son los objetivos y requisitos que se deben cumplir comienza el proceso de diseño. Se realiza en primer lugar un diseño inicial con las ideas básicas que compondrán el primer esquema de implementación y por consiguiente la solución final. De esta forma dicho primer diseño debe cumplir los objetivos y requisitos además de servir como base para futuros diseños e implementaciones, siendo de esta forma y a grandes rasgos la idea básica de la solución elegida. Con este primer diseño presente, se estudian los diversos métodos o formas de trabajo sobre los que se implementarán las ideas básicas. Se seleccionan los que se consideren oportunos en ese momento. Y por último se realiza un segundo diseño, el cual será más específico y contendrá con mayor nivel de detalle las soluciones optadas para cada parte que compone el diseño inicial. Comienza en estos momentos una etapa de implementación y rediseño constante de la solución. Siempre siguiendo esta síntesis. Implementación de lo diseñado en primer lugar y rediseño de la solución en caso de ser necesario por diversos motivos como problemas a la hora de realizar el primer diseño, obtención de una mejor solución para una parte del diseño, tecnologías obsoletas o nuevas tecnologías que no te habían tenido en cuenta, entre otros. Una vez que se termina por completo la implementación comienza la etapa de evaluación y pruebas donde se deben de identificar los posibles errores de implementación o funcionamiento y, por supuesto, solucionarlos. Esta última parte puede dar lugar a un nuevo rediseño e implementación en función de la gravedad y el tipo de error. Por último se han de estudiar los resultados obtenidos en el proceso anterior, analizando con visión crítica el funcionamiento y el cumplimiento tanto 3357 3.4. Valoración de objetivos de los objetivos previstos, como de los requisitos que se establecieron para la solución final. Obteniendo finalmente una visión global de las posibles vías de implementación futuras, para posibles mejoras, o soluciones de fallos que no se han logrado solucionar Valoración de objetivos En este apartado se realizará una valoración crítica sobre los objetivos finales que se han cumplido con la finalización del proyecto. Aunque esta valoración será muy breve puesto que en el Capítulo 6 se analizan en mayor profundidad los resultados y conclusiones obtenidos en este proyecto. Por lo general, se puede decir que la finalización de este proyecto ha sido muy gratificante y satisfactoria para mí en cuanto a la consecución de todos los objetivos principales que se marcaron al inicio del mismo. Además también se ha logrado alguno de los objetivos secundarios con lo que finalmente se facilita la tarea de instalación esencialmente en el ámbito de la Universidad de Granada, una gran ventaja de cara a futuras implementaciones y vías de desarrollo. 3458 Capítulo 4 Diseño y resolución del trabajo En este capítulo se pretende mostrar la realización de todo el trabajo realizado hasta la consecución del proyecto final. El capítulo se estructura en dos secciones claramente diferenciadas. Por un lado se detallará el proceso de diseño que se ha realizado de la solución final atendiendo a las diferentes partes que componen el mismo (Sección 4.1). Y por otro se detallará la implementación final realiza a partir de dicho diseño (Sección 4.2) Diseño En esta sección se establecerá el diseño realizado de la solución final atendiendo a las diferentes etapas del proyecto. En primer lugar y con un mayor nivel de abstracción se mostrará el diseño de la arquitectura de forma que quede definido el comportamiento global del sistema y se muestren todas las posibles soluciones posibles que se planteaban al inicio de este proyecto. Posteriormente se profundizará en su estructura a través de los diferentes diagramas atendiendo a su vez al esquema general y las subdivisiones que este pueda tener Diseño global Diseño previo En este primer apartado se muestra el primer diseño que se realizó al inicio del proyecto, diseño que se realizó previamente a cualquier investigación o búsqueda de solución. Este es un diseño que sirve para comprender la utilidad 3559 4.1. Diseño Servidor SFTP Usuario Servidor WEB Servidor RPi Proyector Figura 4.1: Diseño previo final del proyecto y a partir del cual se puede comenzar a pensar en las posibles soluciones que se podrían implementar. Dicho diseño se puede ver en la Figura 4.1. Tal y como se ha especificado en el Capítulo 3, uno de los objetivos del proyecto es que se pueda extender a diferentes plataformas con facilidad en un futuro, de forma que cualquier dispositivo pueda hacer uso de él. Por esta razón se ha elegido implementar el servidor web. Un servidor al que cualquier dispositivo accederá sin problemas de compatibilidad. Además, uno de los objetivos fundamentales es el almacenamiento centralizado del material docente. Por esta razón se implementa el servidor FTP que se muestra en la Figura 4.1. Y por último, se ha de implementar un tercer servidor, situado éste en una Raspberry Pi, también descrita anteriormente, que será el encargado de manejar el material a proyectar. Una vez queda definido de forma clara este diseño básico es fácil ver como existen multitud de posibles implementaciones diferentes para esta solución. Así como también se pueden introducir algunas mejoras. En primer lugar, y para cumplir con un requisito secundario pero importante de cara a vías futuras, se añade un servidor RADIUS como servidor autenticación y un servidor LDAP como gestor de base de datos de usuarios. La razón de utilizar este tipo de servidor es porque la autenticación utilizada por los servicios de Internet ofrecidos por la Universidad de Granada se basa fundamentalmente en un servidor RADIUS centralizado y una base de datos LDAP para el control de todos los usuarios pertenecientes a la institución [51]. De esta forma, se consigue mayor facilidad para la implantación del sistema en las aulas docentes. Por esta razón, el diseño inicial se ve modificado añadiendo estos dos nuevos servidores, obteniendo finalmente como diseño básico la Figura 4.2 Por otro lado, cumpliendo con las especificaciones del Capítulo 3, la seguridad es un punto fundamental en la implementación. En este sentido, se 3660 4. Diseño y resolución del trabajo Servidor LDAP Servidor RADIUS Servidor SFTP Usuario Servidor WEB Servidor RPi Proyector Figura 4.2: Diseño global de la implementación ha de cuidar la comunicación entre servidores y entre usuario y servidor. Por esta razón, se decide también desde el primer momento utilizar, en lugar de un servidor FTP, un servidor SFTP. Aumentando de esta forma la seguridad de nuestro sistema. Además, también se configurará el servidor web de forma que utilice HTTPS en lugar de HTTP. Otra medida que aumentará dicha seguridad Estudio de las posibles implementaciones Una vez se tiene claro cuál será el diseño final de la solución, se debe empezar a buscar las posibles soluciones, estudiar todas sus ventajas e inconvenientes, y elegir la mejor solución comparando unas con otras. La primera elección que se debe hacer es la situación donde se instalarán todos los servidores. Evidentemente, el servidor instalado en la Raspberry Pi queda al margen de esta decisión. La solución más fácil y cómoda para esto es utilizar un ordenador personal con sistema operativo Linux [41] donde se instalarán todos los servidores de forma fácil y rápida. El sistema operativo elegido es Linux ya que en estos sistemas la instalación, configuración y programación de los servidores es más cómoda. Además se pueden aprovechar los conocimientos ya adquiridos a lo largo del grado sobre el uso de la consola. Hay que aclarar que esta decisión está pensada para el proceso de realización de este proyecto. Para casos futuros en los que se realice la implementación del proyecto en la universidad por ejemplo, los servidores deberán ser instalados en una máquina de mayor potencia que pueda soportar todo el tráfico de datos que éstos generarán. En especial, el diseño se ha realizado de forma que se puedan utilizar los servidores actuales de los que dispone la universidad de forma que la implementación de este proyecto no requiera 3761 4.1. Diseño Figura 4.3: Uso de servidores HTTP grandes modificaciones y resulte sencilla de realizar. Con esta información se comienza con la toma de decisiones en lo que al diseño respecta: Servidor WEB Para el caso del servidor web la elección es bastante simple. Existen diversos servidor HTTP que son livianos, pero el servidor Apache [36] es el más utilizado debido a la facilidad de instalación, las extensas posibilidades de configuración y los módulos de seguridad que dispone. Apache se ha convertido en el servidor web más utilizado entre el resto de opciones, tal y como se puede ver en la Figura 4.3 obtenida de un estudio de INTECO (Instituto Nacional de Tecnologías de la Comunicación)[52] [53]. Servidor FTP 38 Para la elección del servidor FTP hay que tener varias consideraciones en cuenta; debe ser compatible con Linux, debe poder implementar SFTP para proporcionar seguridad a las comunicaciones y además debe ser de fácil configuración y manipulación. Ante esto se ha elegido usar el servidor VSFTPD [37]. Este servidor no es la única opción válida, Filezilla [54] y OpenSSH [55] son dos ejemplos de las diferentes posibilidades que existe de forma62 4. Diseño y resolución del trabajo gratuita actualmente. Se ha elegido utilizar VSFTPD porque es un servidor altamente configurable y muy utilizado en los entornos Linux. Servidor RADIUS + base de datos En este caso, las opciones están algo limitadas. La base de datos debe ser LDAP, puesto que es la utilizada en el modelo de autenticación de la universidad, como se ha descrito anteriormente. Así, el servidor utilizado es OpenLDAP [39]. Para el caso del servidor RADIUS se utilizará un servidor gratuito, compatible con el entorno Linux y que permita utilizar la base de datos tipo LDAP anterior para la autenticación. En este caso el servidor RADIUS más utilizado habitualmente y cuyos módulos permiten autenticación mediante LDAP es FreeRADIUS [38], por lo que es el servidor que se utilizará en este caso. Servidor RPi Este servidor corresponde al situado en la Raspberry Pi. Dicho servidor será el encargado de obtener, mostrar y manejar el material que utilizará el docente. El diseño de este servidor está condicionado por la Raspberry Pi. La distribución elegida para instalar es de tipo Linux por compatibilidad y facilidad de configuración. Pero no se puede elegir un Linux cualquiera, ya que Raspberry Pi tiene una arquitectura y hardware específicos. En su web oficial [40] se pueden encontrar diferentes tipos de distribuciones adaptadas a diferentes necesidades, las cuales están optimizadas y preparadas exclusivamente para ser instaladas en Raspberry Pi [42]. Entre ellas se pueden distinguir: RASPBIAN Debian Wheezy [56] OPENELEC An XBMC Media Centre [57] PIDORA Fredora Remix [58] RASPBMC An XBMC Media Centre [59] ARCH LINUX A lighweight Linux distribution [60] RISC OS A non-linux distribution [61] Para el caso que nos interesa, las apropiadas son RASPBIAN, PIDORA y ARCH LINUX, ya que son entornos Linux. De las tres, la elegida es RASPBIAN, un sistema muy parecido al entorno Debian. La razón por la que se escogió esta distribución es porque es la más usada por la 3963 4.1. Diseño comunidad y para la que mayor número de programas existen es estos momentos. Todo resulta más fácil de instalar e implementar cuando las librerías y el código fuente ya están incluidos en la distribución. Por tanto, el diseño del servidor finalmente estará condicionado por esta distribución, de modo que hay que tener en cuenta el rendimiento que puede tener y el software que es compatible. El diseño de este servidor marcará además en algunos aspectos el diseño de la aplicación cliente con la que el usuario final se conectará a dicho servidor. Esto se debe a que cliente y servidor deben establecer conexión e intercambiar mensajes de forma que ambos deben ser compatibles. Teniendo estos aspectos en cuenta, muchas son las propuestas iniciales a la hora de realizar el diseño de este servidor, aunque sólo tres adquieren un mayor peso. Se puede utilizar un segundo servidor web al que se redireccionaría desde el servidor web anterior, de forma que se manejaría el archivo en este nuevo entorno web. Así, la aplicación cliente se reduce a una página o interfaz web. Se puede utilizar un servidor con socket utilizando lenguajes de programación C o Java (los más comunes). En este caso, la aplicación cliente debe estar también implementada en dicho lenguaje de programación. Se puede utilizar un servidor con socket pero utilizando en este caso PHP como lenguaje de programación. De esta forma se podría realizar la conexión socket desde la propia interfaz web y mandar Y enviar las órdenes a través de esta. Finalmente la solución por la que se ha optado es la utilización de una aplicación cliente y un servidor con socket implementado con Java. En el proceso de implementación se han probado todas y cada una de estas tres posibles soluciones y en todas ellas se ha llegado una encrucijada difícil de resolver (librerías o implementaciones que no se han logrado que funcionasen, entro otros). En este sentido la solución elegida es la que más fácil resultó y la que finalmente se ha logrado implementar. Dentro de este mismo punto se ha de elegir también el software que se utilizará para mostrar el material docente. Existen gran cantidad de visores de ficheros en formato PDF, pero se necesita encontrar uno que sea lo más liviano posible, que se pueda abrir desde línea de comandos (esto simplifica su ejecución desde un programa servidor) y que sea fácilmente usable desde ésta o en su defecto mediante el teclado. Para este caso también se han barajado numerosas opciones. Las tres que más en profundidad se han estudiado son: 4064 4. Diseño y resolución del trabajo FBIDA [62] Green [63] MuPDF [46] El primero de ellos, fue la primera opción utilizada pero finalmente no resultó ser tan potente y bueno como en un principio parecía. El control del archivo PDF que se estaba mostrando no funcionaba bien y surgían ciertos problemas cuando se realizaban las primeras pruebas. Con el segundo software ocurrió algo parecido. En este caso, se debe a problemas de compatibilidad por la antigüedad del software. Finalmente la opción utilizada es MuPDF, un visor de PDF ligero, que puede ser utilizado mediante consola y que permite la total manipulación del fichero desde el teclado. Además con este software también se pueden mostrar imágenes, no sólo documentos en formato PDF, lo que ayuda a incrementar las funcionalidades del proyecto Diseño final Una vez que se han elegido las implementaciones que se van a realizar en cada una de las partes que componen el diseño de la Figura 4.2, se puede establecer un diseño con mayor nivel de detalle que ayude a comprender el final funcionamiento y a establecer los pasos para la implementación posterior. En la Figura 4.4 se puede ver el diseño final de la solución. En la imagen se muestra con un grado de detalle mayor al anterior el funcionamiento que tendrá la solución implantada. Se puede ver cómo será la comunicación entre servidores, los datos necesarios en cada momento y cuáles serán los diferentes pasos que se realizarán hasta conseguir finalmente que se muestre el material docente en el proyector. En esta imagen, las figuras cuadradas corresponden a los servidores o aplicaciones y las figuras con forma de rombo a los datos necesarios que se utilizan en dichos servidores o aplicaciones. El proceso mostrado en la Figura 5.4 es el siguiente. Inicialmente se utilizan los datos de usuario (usuario y contraseña) para poder entrar al entorno web. Antes de poder acceder a él, el servidor HTTP establece conexión con el servidor RADIUS, al cual le manda los datos del usuario introducidos. El servidor RADIUS a su vez establece una nueva conexión con el servidor LDAP. Dicho servidor será el encargado de comprobar la veracidad de los datos introducidos comparándolos con los datos almacenados en la base de datos. En caso de ser datos incorrectos el proceso vuelve al inicio. Si los datos son correctos el usuario tiene permiso para entrar en el entorno web. En este 4165 4.1. Diseño Inicio Usuario Contraseña Servidor HTTP Servidor RADIUS Servidor LDAP DB Organizar archivos Entorno WEB Si Comprobar datos No Proyección DB Servidor VSFTPD Usuario Contraseña Archivo Localización Proyector (IP RPi) Aplicación Cliente Petición/Respuesta Servidor RPi Figura 4.4: Diseño general de funcionamiento punto se pueden diferenciar dos acciones. Una correspondiente al manejador de ficheros. La otra acción es la correspondiente a mostrar un fichero en el proyector. En el primer caso son necesarios los datos de usuario y el nombre del archivo para poder acceder al servidor de ficheros. Y una vez establecida la conexión se podrá borrar, renombrar o ver los ficheros guardados, así como añadir nuevos. Con respecto a la acción correspondiente a mostrar el fichero en el proyector se debe hacer uso en este caso de la aplicación cliente implementada. Dicha aplicación necesita como datos de entrada los datos de usuario, el fichero que se quiere mostrar y la dirección IP del servidor RPi, es decir, la localización del proyector que se va a utilizar. Desde la aplicación cliente se establecerá una conexión mediante socket con el servidor situado en la Raspberry Pi, el cual necesitará también los datos de usuario y el fichero que se quiere mostrar. Finalmente, una vez que el documento es proyectado, se produce una comunicación continua de petición-respuesta con el envío de las órdenes utilizadas para manejar las proyecciones Diseño de los servidores En este apartado, se profundizará en el diseño de los diferentes servidores. Para el caso de los servidores VSFTPD, FreeRADIUS y LDAP se ampliará la información en la sección 4.2 puesto que no necesitan ser diseñados, sino simplemente configurados. 4266 4. Diseño y resolución del trabajo Figura 4.5: Interfaz web de usuario Servidor WEB Para el caso del servidor web se ha utilizado lenguaje HTML para el diseño web y PHP para lograr un entorno web dinámico. El entorno debe ser muy intuitivo y sencillo de utilizar por el usuario. Por esta razón la interfaz que el usuario final ve cuando accede a dicho servidor es una única página de inicio en la que se mostrarán los ficheros almacenados en el servidor de ficheros. Desde dicha página de podrá subir un nuevo archivo, borrar un archivo existente, renombrar o descargar un archivo. Todo esto gracias a la programación dinámica de PHP. Además desde dicho entorno también se podrá acceder a la aplicación cliente implementada para establecer la conexión con el servidor situado en la Raspberry Pi y mostrar el material docente. Un ejemplo de esta interfaz se puede ver en la Figura 4.5. Para mayor información acerca de las utilidades y el funcionamiento, ver el Anexo A. Manual de usuario. Para que todo esto sea posible, se han diseñado diferentes ficheros PHP que ayudan a la realización de todas estas tareas. En la Figura 4.6 pueden verse las relaciones entre dichos ficheros. Index Es la página inicial que aparecerá al entrar en el servidor WEB. En ella se puede acceder al entorno web de usuario o una nueva página desde la cual se puede crear una nueva cuenta de usuario. Contiene la 4367 4.1. Diseño Página con la aplicación cliente Página de incio Cambiar contraseña Index Registrar nuevo usuario Cerrar sesión Figura 4.6: Elementos del servidor WEB función: autenticarusuario() Función que comprueba la veracidad de los datos introducidos por el usuario antes de redirigir a la página de inicio. Registrar usuario Página utilizada para crea una nueva cuenta de usuario. Contiene las funciones: registrarnuevousuario() Función que crea una nueva cuenta de usuario en el sistema global. nuevousuarioldap() Función utilizada para introducir una nueva entrada en la base de datos LDAP. comprobardatos() Método auxiliar al anterior, comprueba que el usuario no exista. registrousuarioldap() También método auxiliar al anterior, realiza la creación de la nueva entrada. nuevousuarioftp() Crea una nueva cuenta de usuario en el servidor VSFTPD. Página de inicio 44 Página principal del entorno web donde el usuario puede realizar todas las acciones correspondientes con el servidor de ficheros, así como acceder a la aplicación cliente. Esta página contiene los métodos:68 4. Diseño y resolución del trabajo conexionuevousuarioftp() Establece una conexión con el servidor de ficheros VSFTPD. verarchivos() Obtiene la lista de ficheros del usuario con sus características a partir de una conexión al servidor ya realizada. subirarchivo() Guarda un nuevo fichero en el servidor de ficheros. Requiere de una conexión al servidor de ficheros ya realizada. eliminararchivo() Elimina un archivo del servidor de ficheros. Requiere de una conexión al servidor ya realizada. renombrararchivos() Cambia el nombre de un archivo existente en el servidor de ficheros. Requiere de una conexión al servidor ya realizada. Página aplicación cliente Esta página contiene los datos necesarios para lanzar la aplicación cliente en el entorno web. Como la aplicación esta implementada en lenguaje Java y se está trabajando en un entorno HTML la aplicación lanzada es un Applet (la forma que tiene Java de diseñar aplicaciones web). La web primero pide la selección del aula donde se quiere mostrar el material. Esta selección está en formato texto y se debe pasar posteriormente a IPv4. Además, se hará una distinción según se trate de un documento en formato PDF o de una imagen. Esto se debe a que la interfaz utilizada en cada caso será diferente. Aunque la única diferencia reside en la cantidad de acciones que se podrán realizar. Contiene el método: obtenerip() Función para obtener la IP de una determinada localización (generalmente una habitación o aula), a partir de un pequeño fichero donde se almacena dicha información. Cambiar contraseña Permite cambiar la contraseña de la cuenta que utiliza un determinado usuario. Contiene los métodos: cambiarpassword() Función para cambiar la contraseña de una cuenta de usuario en el sistema global. cambiarpasswordldap() Cambia la contraseña de una entrada en la base de datos LDAP. 4569 4.1. Diseño comprobardatos() Método auxiliar al anterior utilizado para comprobar que la entrada exista. cambiarpassword FTP() Cambia la contraseña de la cuenta del usuario en el servidor VSFTPD. Cerrar sesión Destruye todos los datos de sesión que se han estado utilizando en el entorno web y se redirecciona al inicio. Si no se realiza este proceso puede que al volver a abrir la página en el mismo navegador redireccione a la página principal sin necesidad de tener que introducir los datos de usuario Servidor RPi Este servidor, como se ha dicho anteriormente, se implementará con el lenguaje de programación Java y será el encargado de realizar las acciones sobre el documento que se mostrará en el proyector. Su funcionamiento consiste básicamente en el establecimiento de conexiones con los clientes. Una vez que se establece una conexión, recibe los datos de usuario y los datos del fichero. Posteriormente se conecta al servidor de ficheros para obtener el archivo y guardarlo de forma temporal en la Raspberry Pi. En este momento comienza el período donde se puede manejar el documento. Y finalmente cuando se quiere cerrar la conexión, se borra el fichero temporal de la Raspberry Pi y se cierran todas las conexiones existentes con el cliente, quedando de nuevo escuchando el puerto a la espera de un nuevo cliente. Esto se verá de forma más clara en la Figura 4.7 donde se muestra el diagrama de estados del servidor. En este el diagrama de estados se puede ver como el servidor está en constante ejecución. La única forma de parar el servidor es de forma manual por el usuario haciendo uso del método cerrarservidor(). Atributos 46 puerto Variable introducida con el usuario desde línea de comandos. Indica el número de puerto en el que comenzará el servidor a escuchar. Su valor por defecto se establece a IP ftp server Variable introducida con el usuario desde línea de comandos. Indica la dirección IP del servidor de ficheros VSFTPD. Valor por defecto70 4. Diseño y resolución del trabajo Error conexión Inciar conexión Inicio Esperando cliente Estado inicial Abrir puerto Reinicio servidor Cierre cliente Recepción mensaje incorrecto Recepción datos usuario Estado error Recepción datos archivo Estado identificado Estado archivo preparado Recepción mensaje incorrecto Petición abrir Estado archivo abierto Recepción mensaje incorrecto Petición Petición cerrar Estado final Figura 4.7: Diagrama de estados del ServidorRPi 4771 4.1. Diseño Métodos socketconexion Variable con la información referente la información del socket. canalsalida Variable utilizada para mandar datos por el buffer de salida desde el servidor. canalentrada Variable para recibir datos en el buffer de entrada del servidor. teclado Variable de la clase Robot proporcionada por Java, la cual es utilizada para simular las pulsaciones de teclas en la máquina donde corre el servidor, es decir, en la Raspberry Pi. cerrar Variable utilizada cuando se quiere cerrar por completo el servidor. 48 abrirservidor() Inicia el servidor en el puerto indicado. nuevocliente() Espera la conexión con un nuevo cliente. cerrarconexion() Cierra la conexión actual con el cliente. cerrarservidor() Cierra por completo el servidor. reiniciarservidor() Reinicia el servidor. servidortocliente() Envía un mensaje al cliente. guardarlog() Guarda un mensaje en el fichero de logs. errorsolicitud() Maneja un error producido en la recepción de una solicitud/mensaje. manejarerrordescargar() Maneja el error que se produce cuando se descargar un archivo del servidor de ficheros. errorconexionftp() Maneja el error producido cuando no se ha podido establecer una conexión al servidor de ficheros. errorloginftp() Maneja el error producido durante el login con el servidor de ficheros. errorobtenerarchivoftp() Maneja el error producido en la descargar del fichero. errorinternodescargar() Maneja un error interno no reconocible por el servidor. abrirarchivo() Abre un archivo en el escritorio de la máquina donde se está ejecutando el servidor. accionpdf() Decide que acción realizar sobre el documento pdf en función de la orden que llega desde el cliente.72 4. Diseño y resolución del trabajo cambiarpaginapdf() Cambiar la página que se está visualizando de un archivo pdf. buscarpalabrapdf() Busca una palabra en el fichero pdf que se está utilizando. accionimg() Decide que acción realizar sobre la imagen en función de la orden que llega desde el cliente. borrararchivotemporal() Borra el fichero que se había descargado anteriormente para mostrar Diseño de la aplicación cliente La aplicación cliente debe estar implementada con el lenguaje de programación Java. Además, como se ha dicho en anteriores apartados de este capítulo, ha de ser una aplicación Applet. En este sentido, se han creado dos clases, una que contendrá la interfaz gráfica del usuario, el Applet, y otra que contendrá los métodos utilizados por el cliente. La primera clase tiene como único propósito la creación de una interfaz gráfica sencilla para el usuario, a partir de la cual se creará un objeto de la clase ClienteRPi. Y dicho objeto será el que se encargue de toda la comunicación con el servidor. En este sentido, la clase ClienteRPi se encarga de establecer la conexión con el servidor RPi, de enviar los datos de usuario, enviar los datos del fichero que se quiere mostrar y enviar finalmente una petición para mostrar dicho fichero. A partir de este instante la conexión ya está establecida por completo sin errores y el documento es mostrado en el proyector. Por tanto, a partir de este momento los mensajes intercambiados corresponden a las peticiones del cliente (e.g. avanzar página) y respuestas del servidor. El diagrama de estados de la Figura 4.8 ayuda a comprender su funcionamiento. La clase ClienteRPi viene descrita por: Atributos servidor Variable que contiene la dirección IP del servidor RPi. puerto Variable que indica el puerto el que conectará al servidor RPi. usuario Variable que contiene el nombre de usuario del cliente que está utilizando la aplicación. puerto Variable que indica la contraseña de usuario del cliente que está utilizando la aplicación. 4973 4.1. Diseño Inicio Inciar conexión Error Conectado Envío datos usuario Error Espera confirmación datos usuario Envío datos archivo Error Espera confirmación datos archivo Envío petición abrir Envío peticiones Error Espera respuesta OK Espera mandar petición Recibida petición cerrar Error Fin Figura 4.8: Diagrama de estados del ClienteRPi 5074 4. Diseño y resolución del trabajo Métodos archivo Variable que contiene el nombre del archivo que se quiere mostrar en el proyector. socketconexion Variable con la información referente la información del socket. canalsalida Variable utilizada para mandar datos por el buffer de salida desde el cliente al servidor. canalentrada Variable para recibir datos en el buffer de entrada desde el servidor al cliente. abrircliente() Inicia una nueva conexión con el servidor en el puerto indicado. cerrarcliente() Cierra la conexión actual con el servidor y termina la ejecución de la aplicación cliente. clientetoservidor() Envía un mensaje al servidor RPi. esperandoservidor() Espera hasta que recibe un mensaje procedente del servidor RPi Diseño del protocolo En este apartado se describirá el protocolo diseñado para la comunicación entre servidor y cliente RPi, de forma que esta información pueda servir de documentación para entender mejor el comportamiento del sistema y ayudar a la elaboración futura de modificaciones en el código. En la Figura 4.9 se muestra un esquema con el intercambio de mensaje común entre cliente y servidor. En dicho esquema, el servidor está inicialmente escuchando en el puerto 8888, y al cerrar la conexión con el último mensaje recibido BYE por parte del cliente, vuelve a escuchar en el mismo puerto. Evidentemente, en este esquema no se han tenido en cuenta los posibles fallos durante el proceso. Se ha mostrado una visión general del correcto funcionamiento. En caso de fallo el mensaje enviado al cliente por parte del servidor tiene la estructura ERROR! + breve descripción del error. Con esta estructura fundamental de los mensajes y la ayuda de los diagramas de estados mostrados anteriormente (Figura 4.7 y Figura 4.8) es fácil entender el funcionamiento básico de la aplicación cliente-servidor diseñada. Con estas tres imágenes se puede ver cuál es el comportamiento global del sistema y cómo cliente y servidor avanzan a través de los distintos estados en función de los mensajes que se van enviando en cada momento. 5175 4.1. Diseño Cliente Servidor Conexión en el socket 8888 OK USER + datos de usuario +OK WELCOME SFTP + datos de archivo +OK Archivo preparado ABRIR +OK Abierto Petición +OK CERRAR BYE BYE Figura 4.9: Intercambio de mensajes ClienteRPi-ServidorRPi 5276 4. Diseño y resolución del trabajo El primer mensaje que debe mandar el cliente hacia el servidor sigue la siguiente estructura; USER + usuario + password, donde usuario y password son los datos de la cuenta del cliente. Los datos deben ir separados por un espacio. Cuando el servidor recibe dicho mensaje guarda los datos y responde con un mensaje +OK WELCOME. El segundo mensaje que se debe mandar sigue la siguiente estructura; FTP + archivo, donde archivo corresponde al nombre del fichero que se quiere mostrar en el proyector Cuando el servidor recibe este dato, inicia el proceso de obtención del archivo mediante una conexión SSL al servidor de ficheros, y una vez finalizado responde con un mensaje +OK Archivo preparado. En tercer lugar, el cliente manda la petición de abrir el archivo mediante el mensaje ABRIR. En este momento el servidor abre y muestra el fichero en el proyector, responde con un mensaje +OK Abierto y se inicia en estos momentos el proceso de petición respuesta para manejar el documento. Los pasos descritos anteriormente no pueden variar, siguen obligatoriamente esta estructura. Cualquier variación en uno de estos mensajes provoca un fallo en el servidor y el consiguiente cierre de la conexión con el cliente. A partir de este momento las peticiones son libres, es decir, las peticiones variarán en función del tipo de acción que se quiera realizar. Así se pueden diferenciar: - AVANZAR Para avanzar página - RETROCEDER Para retroceder página - PAGINA Para avanzar a una página concreta - COMPLETA Para mostrar en pantalla completa - ANCHO Para ajustar la imagen al ancho de la pantalla - ALTO Para ajustar la imagen al alto de la pantalla - GIRAR DERECHA Para girar la imagen a la derecha - GIRAR IZQUIERDA Para girar la imagen a la izquierda - ZOOM MAS Para aumentar el zoom - ZOOM MENOS Para disminuir el zoom - MOVER ARRIBA Para mover hacia arriba - MOVER ABAJO Para mover hacia arriba - MOVER DERECHA Para mover hacia la derecha - MOVER IZQUIERDA Para mover hacia la izquierda - BUSCAR PARALBA Para buscar una palabra - BUSCAR SIGUIENTE Para buscar siguiente palabra - BUSCAR ANTERIOR Para buscar palabra anterior 5377 4.2. Implementacion - ACTUALIZAR Para actualizar la imagen - REDIMENSIONAR Para redimensionar la imagen - CERRAR Para cerrar la imagen En todos los casos anteriores, cuando el servidor recibe cualquiera de estos mensajes, realiza en primer lugar la acción correspondiente, y confirma su realización posteriormente con un mensajes +OK. Aunque existe una salvedad, el caso de recibir un mensaje CERRAR. Cuando el servidor recibe este mensaje comienza el proceso de cierre de la conexión. En este proceso el servidor cierra el archivo, borra el archivo temporal, y manda un mensaje de vuelta al cliente BYE. El cliente al recibir esta petición confirma con otro mensajes BYE. Cuando este segundo mensaje llega al servidor, éste cierre la conexión con el cliente y vuelve a escuchar de nuevo en el puerto para establecer una nueva conexión con otro cliente Implementacion En esta sección se procede a detallar la implementación del sistema de acuerdo a los criterios de diseño presentados en la sección anterior (Sección 4.1. El presente capítulo se estructura a las diferentes secciones que componen la arquitectura del proyecto Servidor SFTP Como se vio en la sección anterior, el servidor seleccionado para funcionar como servidor de ficheros es VSFTPD. Para realizar la instalación e implementar la correcta configuración se utiliza la documentación facilitada en su propia página web, desde donde también se puede descargar dicho servidor [37]. Adjunto a este documento, en el Anexo B. Manual de instalación, se puede encontrar el manual de instalación donde se detallan y describen los pasos a seguir para la correcta configuración del servidor. Este apartado se ceñirá por tanto a explicar en menor nivel de detalle cómo se ha llevado a cabo la configuración de dicho servidor. Una vez que el servidor está instalado el servidor se cambiar la configuración del mismo mediante el fichero /etc/vsftpd.conf. En este caso se realizan algunas configuraciones básicas con permitir el uso de usuarios locales y utilizar un fichero para el enjaulado de usuarios, es decir, para que sólo los usuarios que se encuentran dentro de dicho fichero puedan utilizar el servidor. Este fichero es /etc/vsftpd.chroot list. 54 El siguiente paso es la creación de usuarios. La forma de crear usuario78 4. Diseño y resolución del trabajo también se describe en la documentación adjunta por lo que tampoco se detallara la explicación. Se ha de crear una carpeta donde el usuario tendrá sus ficheros guardados. También se creará una shell virtual o fantasma de modo que los usuarios no puedan conectarse a una sesión del sistema operativo, sino que solo puedan conectarse a la carpeta de usuario. Finalmente se procede a la creación de la nueva cuenta de usuario en la shell virtual y en la carpeta anteriormente creada. Por último se añade el usuario a la lista de usuarios enjaulados y se reinicia el servidor. Un aspecto importante del servidor es la seguridad. Se debe implementar el servidor de forma que utilice una capa de transporte segura para las comunicaciones [64]. El protocolo FTP, aunque muy práctico, no codifica los datos ni siquiera de las credenciales del usuario. El hecho de que alguien pudiera capturar un paquete en la ruta sería muy grave para la seguridad del sistema. Por tanto, la solución es utilizar un protocolo seguro, en concreto SFTP. Así, se configura el servidor VSFTPD para que trabaje de forma que la conexión esté cifrada. En primer lugar hay que generar un certificado. Dicho certificado se puede generar fácilmente utilizando OpenSSL [65]. Y en segundo lugar se ha de volver a cambiar la configuración del servidor de forma que se habilite el soporte para SSL en sus distintas versiones (TLS, SSLv2 y SSLv3) [66][67][68] y se añade la ruta hacia el certificado creado anteriormente Servidor LDAP El servidor LDAP será el encardado de la gestión de la base de datos de usuarios. Al igual que en apartado anterior, en la página web oficial de OpenLdap [39] se puede descargar este servidor. Además, también se puede encontrar gran cantidad de información relevante a la configuración de este servidor. Puesto que en el manual de instalación se detallan los pasos a seguir para configurar completamente este servidor, este apartado se centrará en explicar a grandes rasgos como se ha realiza su configuración. LDAP es un servidor al que se añaden o modifican las entradas mediante un tipo de ficheros específicos, únicamente usados ente servidor. Se trata de los ficheros.ldif. En este sentido se debe añadir en primer lugar la descripción de los grupos de usuarios. Estos grupos marcarán una serie de características comunes a un grupo de usuario. El fichero utilizado para ello es: En cuanto al fichero que se utiliza para la adición de nuevas entradas (usuarios) en la base de datos es el siguiente: 5579 Error! No se encuentra el origen de la referencia.. Error! No se encuentra el origen de 4.2. la Implementacion referencia. Error! No se encuentra el origen de la referencia.. Error! No se encuentra el origen de la referencia. dn: ou=profesores, dc=ugr, dc=es objectclass: top objectclass: dn: ou=profesores, organizationalunit dc=ugr, dc=es objectclass: top ou: profesores objectclass: organizationalunit description: ou: profesores Profesores description: Profesores dn: ou=alumnos, dc=ugr, dc=es dn: ou=alumnos, dc=ugr, dc=es objectclass: top objectclass: top objectclass: organizationalunit ou: ou: alumnos description: Alumnos Figura 6.1. Fichero de configuración grupos.ldif Figura 6.1. Fichero de configuración grupos.ldif En cuanto al fichero que se utiliza para la adición de nuevas entradas (usuarios) en la Figura 4.10: Fichero de configuración grupos.ldif En cuanto base al de fichero datos es que el siguiente: se utiliza para la adición de nuevas entradas (usuarios) en la base de datos es el siguiente: dn: cn=nick ou=profesores, dc=ugr, dc=es objectclass: top dn: cn=nick objectclass: ou=profesores, organizationalperson dc=ugr, dc=es objectclass: sn: nombre_completo top ou: Nick objectclass: organizationalperson userpassword: password sn: nombre_completo description: Profesor ou: Nick Figura 6.2. Fichero de configuración profesor.ldif userpassword: password Figura Donde description: nick 4.11: corresponde Fichero con Profesor la cuenta de configuración de usuario del correo profesor.ldif electrónico de la Universidad de Granada, y password se cifra mediante usando una función hash de PHP antes de añadir la información Figura 6.2. a Fichero la base de de configuración datos. profesor.ldif Donde nick corresponde con la cuenta de usuario del correo electrónico de la Universidad de Granada, y password se cifra mediante usando una función hash de PHP antes de añadir la información a la base de datos. Donde nick 6.3. corresponde Servidor RADIUS con la cuenta de usuario del correo electrónico de la Universidad de Granada, y password se cifra mediante usando una función hash de PHP Para habilitar la base de datos y que ésta sea de utilidad, se ha de configurar un servidor antes de RADIUS. añadir Como la información se vio en el a capítulo la base 5, de se utilizará datos. para ello FreeRADIUS Error! No se encuentra el origen de la referencia.. De nuevo en su página web se puede obtener el 6.3. Servidor software de forma RADIUS gratuita, así como diversa información para la configuración de este servidor Servidor RADIUS Para habilitar En este la caso base se de ha datos de configurar y que el ésta servidor sea de para utilidad, que utilice se la ha base de configurar de datos LDAP un servidor RADIUS. anterior Como como se vio si de en su el propia capítulo base de 5, datos se utilizará de usuarios para se tratase. ello FreeRADIUS Al igual que en Error! los No se anteriores casos, en el manual de instalación se detallará esta información. encuentra el origen de la referencia.. De nuevo en su página web se puede obtener el software de forma gratuita, así como diversa información para la configuración de este servidor. Para habilitar la base de datos y que ésta sea de utilidad, se ha de configurar un servidor RADIUS. Como se vio en la sección anterior (Sección 4.1), se utilizará para ello FreeRADIUS [38]. De nuevo en su página web se puede obtener el software de forma gratuita, así como diversa información para la configuración de este servidor. En este caso se ha de configurar el servidor para que utilice la base de datos LDAP anterior como si de su propia base de datos de usuarios se tratase. Al igual que en los anteriores casos, en el manual de instalación se detallará esta información. En este caso se ha de configurar el servidor para que utilice la base de datos LDAP anterior como si de su propia base de datos de usuarios se tratase. Al igual que en los anteriores casos, en el manual de instalación se detallará esta información. Para la correcta configuración, como se va a hacer uso de la base de datos LDAP basta con configurar el servidor para que pueda utilizarla. Se debe instalar para ello el módulo freeradius-ldap. Una vez que la base de datos está completamente configurada, en la configuración de FreeRADIUS se habilita el módulo previamente instalado. Y se configura además que la autenticación en dicho servidor será servida por defecto por LDAP en lugar de por los ficheros de configuración propios. De esta forma se consigue integrar 5680 4. Diseño y resolución del trabajo Figura 4.12: Interfaz portada completamente LDAP en FreeRADIUS Servidor HTTP Tal y como se ha descrito en la fase de diseño, la implementación del entorno web, en lo que a diseño y apariencia se refiere, es muy sencilla, aunque por otra parte adquiere mayor relevancia la programación dinámica del mismo con PHP. Por ello, en primer lugar se debe realizar la instalación tanto del servidor web Apache como del lenguaje PHP y sus módulos asociados a dicho servidor Apache. Además será necesario instalar también los paquetes php-radius y php-ldap para poder manejar tanto el servidor RADIUS como la base de datos desde el entorno PHP. Con PHP se puede conseguir realizar multitud de tareas gracias a sus numerosas clases [76]. En los siguientes apartados se detallará la implementación de los diferentes ficheros que constituyen el conjunto del servidor web y se demostrará la afirmación anterior index.php Es página corresponde con la interfaz de portada de este servidor web. Esta portada es muy sencilla y minimalista. Se asemeja en cierto sentido a las interfaces utilizadas por la Universidad de Granada para acceder al correo electrónico propio. En la Figura 4.12 se muestra como es dicha interfaz. Este fichero es además el encargado de la autenticación del usurario y la creación de la sesión del mismo que será utilizada durante la navegación por 5781 4.2. Implementacion el servidor. Esto se puede llevar a cabo gracias a la clase radius de PHP. El proceso seguido es el siguiente: 1 // Se crea un identificador para la autenticacion Radius 2 $radius = radius_auth_open (); 3 4 // Se establecen las variables correspondientes al servidor RADIUS 5 $radius_host = localhost ; 6 $radius_puerto = 1812; 7 $radius_secret = testing123 ; 8 9 // Se especifica el Servidor RADIUS 10 radius_add_server ( $radius, $radius_host, $radius_puerto, $radius_secret, 5, 3)) // Se especifica el tipo de solicitud RADIUS 13 radius_create_request ( $radius, RADIUS_ACCESS_REQUEST )) // Se establece el usuario y contrasena 16 radius_put_attr ( $radius, RADIUS_USER_NAME, $usuario ); 17 radius_put_attr ( $radius, RADIUS_USER_PASSWORD, $password ); // Se obtiene la respuesta a la solicitud anterior 20 switch ( radius_send_request ( $radius )) { 21 case RADIUS_ACCESS_ACCEPT : 22 // Todo ha ido bien. Se establece sesion 23 session_start (); 24 $_SESSION [ usuario ] = $usuario ; // ID usuario 25 $_SESSION [ password ] = $password ; // Contrasena 26 $_SESSION [ ftp_server_ip ] = localhost ; // IP del servidor FTP 27 // Redireccion a la pagina de inicio de usuario 28 header ( Location : inicio. php ); 29 break ; 30 default : 31 // Algo no ha ido bien 32 return $error = 6; 33 } Este código es una versión resumida de cómo se ha llevado a cabo la implementación de la autenticación con el servidor RADIUS. Por supuesto sólo se muestra cuando el funcionamiento es correcto, pero también se tienen presentes todos los errores o fallos que se puedan producir, de forma que se actúa de consecuentemente a estos registrar.php Este fichero es el utilizado para añadir un nuevo usuario al sistema global del proyecto. Esta página sigue el mismo diseño que la página de portada (index). Pero en este caso se pide como datos a introducir el nombre del usuario, el correo electrónico referente a la Universidad de Granada y una contraseña. Dicha contraseña además debe ser de al menos 8 caracteres, y tener un mínimo de un número y una letra. Con esto se trata de aumentar la seguridad del sistema. 5882 4. Diseño y resolución del trabajo Una vez que se introducen los datos se utilizan las funciones expuestas en la sección anterior (Sección 4.1 para crear la nueva cuenta de usuario. En este caso se diferencian los servidores LDAP y VSFTPD. Para el primer caso se pueden utilizar las funciones que proporciona la clase LDAP de PHP. Un breve resumen de esto se muestra a continuación. 1 // Variables del servidor LDAP 2 $ldaphost = " ldap :// localhost "; // servidor LDAP 3 $ldapport = 389; // puerto del servidor LDAP 4 $ldaprdn = cn= admin, dc=ugr, dc=es ; // ldap rdn or dn 5 $ldappass = admin ; // contrasena 6 7 // Se realiza la conexion 8 $ldapconn = ldap_connect ( $ldaphost, $ldapport ); 9 10 // Se establecen algunas opciones necesarias 11 ldap_set_option ( $ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3); 12 ldap_set_option ( $ldapconn, LDAP_OPT_REFERRALS, 0); // Se enlaza la conexion 15 $r = ldap_bind ( $ldapconn, $ldaprdn, $ldappass ); // Para comprobar los datos 18 $sr = ldap_search ( $ldapconn, "dc=ugr,dc=es", "(cn= $ )"); // Para agregar los datos ( $info contiene la informacion ) 21 $r = ldap_add ( $ldapconn, $dn, $info ); En lo que respecta al servidor VSFTPD la creación de la nueva cuenta es diferente. Será necesario en este caso ejecutar desde PHP comandos de la terminal de Linux para poder crear una nueva cuenta de usuario. La clase ftp de PHP solo permite manejar ficheros, en ningún caso se permite variar algo correspondiente a las cuentas de usuario. Será necesario por tanto añadir permisos al usuario del servidor Apache para que se puedan ejecutar dichos comandos inicio.php Este fichero corresponde con la página principal del servidor web. Ésta página es la que el usuario deberá utilizar para realizar cualquier tipo de acción (e.g. lanzar la aplicación cliente o subir un archivo al servidor de ficheros). La interfaz de esta página se puede ver en la Figura Esta interfaz es algo más compleja puesto que muestra los archivos que el usuario tiene guardados en el servidor de ficheros. El diseño de la interfaz y la forma de utilizarla se describe en el Anexo A, donde se incluye un manual de usuario. En él se describe cómo utilizar todo el proyecto. En lo que respecta al funcionamiento de esta página es simple. Cada vez 5983 4.2. Implementacion Figura 4.13: Interfaz página principal que se requiere realizar una acción (subir archivo, borrar archivo, etcétera), al pulsar el botón que permite realizar dicha acción, se actualiza la página de tal forma que se captura la acción. Es decir, se utiliza un form para enviar datos pero hacia la misma página web en la que se encuentra. De esta forma se pueden realizar dichas acciones de manera instantánea. Cada vez que se actualiza o se entra por primera vez en la página se comprueba en primer lugar si hay una sesión de usuario iniciada y en caso contrario se redirige a la página index. Si la hay, se comprueba además si hay que subir un archivo, borrarlo o renombrar y en caso contrario simplemente se muestran los archivos guardados en el servidor de ficheros. En el caso de que se deba realizar alguna de las acciones anteriores, ésta se realiza, se muestra una notificación y finalmente se muestran los archivos guardados. Para la implementación de esta página se hace uso evidentemente de las funciones de la clase ftp que proporciona PHP. Por supuesto será necesario establecer una conexión segura desde el servidor web hasta el servidor ftp. Para ello se utiliza una función especial de PHP para establecer dicha conexión. Un breve resumen de la implementación es el siguiente: 1 // Establecer una conexion segura al servidor FTP 2 $ftp_puerto = 21; 3 $conn_id = ftp_ssl_connect ( $_SESSION [ ftp_server_ip ], $ftp_puerto ); 4 5 // Iniciar una sesion con nombre de usuario y contrasena 6 $login_result = ftp_login ( $conn_id, $_SESSION [ usuario ], $_SESSION [ password ]); 7 8 // Para guardar un archivo 9 ftp_put ( $conn_id, $nuevo_archivo, $nombre_temporal, FTP_BINARY ); 6084 4. Diseño y resolución del trabajo // Para borrar un archivo 12 ftp_delete ( $conn_id, $archivo ); // Para renombrar un archivo 15 ftp_rename ( $conn_id, $archivo, $nuevo_nombre ) // Para obtener los archivos 18 $lista = ftp_nlist ( $conn_id, ""); // Se cierra la conexion FTP en cualquier caso 21 ftp_close ( $conn_id ); Al igual que en casos anterior, éste es simplemente un breve resumen de las principales funciones que PHP tiene para poder actuar sobre ftp. En esta página también se manejan errores y existe además un sistema de notificaciones en función de estos applet.php Esta página es la utilizada para mostrar la interfaz Java del cliente. Desde dicha interfaz se establecerá la conexión y se mandarán las peticiones al servidor situado en la Raspberry Pi. Esta página simplemente selecciona el tipo de interfaz a mostrar en función del tipo de documento (PDF o imagen), y la aplicación cliente se encarga del resto. La forma para lanzar la aplicación es la siguiente: 1 <div align =" middle "> 2 < applet code =" applet. JApplet " archive =" applet. jar " width =" 400 " height =" 300 "> 3 <PARAM NAME =" servidor " VALUE =" <? php echo $IP_ServidorRPI ;? >" / > 4 <PARAM NAME =" usuario " VALUE =" <? php echo $_SESSION [ usuario ];? >" /> 5 <PARAM NAME =" password " VALUE =" <? php echo $_SESSION [ password ];?>" /> 6 <PARAM NAME =" archivo " VALUE =" <? php echo $archivo ;? >" / > 7 </ applet > 8 </div > cambiarpassword.php Esta página es prácticamente igual que la página para registrar un nuevo usuario con la salvedad de que solo será necesario introducir la nueva contraseña. Esta página pide una nueva contraseña que sea al menos de 8 caracteres, y que contenga mínimo un número y una letra, igual que anteriormente. La implementación realiza sigue la misma estructura que la página registrar.php con la diferencia de que solo será necesario en este caso actualiza 6185 4.2. Implementacion la contraseña de una cuenta ya existente en lugar de crearla completamente, por lo que el proceso de implementación es muy similar cerrarserion.php Esta página es la última por la que pasa el usuario antes de terminar una sesión con el servidor web. Esta página no tiene interfaz, simplemente es un documento programado mediante lenguaje PHP que se ejecuta en el servidor web y que al terminar su ejecución, es decir, al cerrar la sesión de usuario complemente, redirige al usuario a la página de portada del servidor (index). Adicionalmente a todo esto, el servidor HTTP debe cumplir también con unos requisitos de seguridad necesarios para la realización del proyecto. Por ello en primer lugar se rechaza cualquier intento de conexión a cualquier parte del servidor que no sea la página de portada cuando no existe una sesión de usuario iniciada. Como la sesión de usuario sólo se inicia cuando se realiza una correcta autenticación, de esta forma se evita que cualquier usuario pueda ver el contenido del servidor web sin tener cuenta de acceso. Por otro lado, cualquiera puede crear una nueva cuenta en el sistema, algo que puede llegar a ser un inconveniente. Pero esto ya se ha tenido en cuenta y no se ha solucionado porque se sale fuera de los límites del proyecto. Teniendo en cuenta que en un futuro las cuentas utilizas serán las correspondientes a la Universidad de Granada, no será necesario perfeccionar el sistema de las cuentas de los usuarios. Por último pero no menos importante, se ha configurado el servidor HTTP como servidor HTTPS de forma que toda la comunicación vaya bajo la capa SSL. De esta forma toda la información relevante a los usuarios quedará siempre protegida. Para realizar esta implementación se ha generado un certificado y se ha firmado el entorno web creado para este proyecto Servidor RPi Este servidor corresponde al situado en la Raspberry Pi. En la sección anterior (Sección 4.1 ya se ha descrito su diseño, el diagrama de estados correspondiente y el formato de los mensajes del protocolo de comunicación entre este servidor y la aplicación cliente. En este apartado por tanto, se profundizará en el proceso de implementación y funcionamiento de dicho servidor. El servidor se ha implementado como una única clase Java, de forma que es lanzado por el usuario mediante la línea de comandos de la terminal de Linux. La forma de ejecutar el servidor es java ServidorRPi [opciones] [parámetros], donde las opciones equivalen únicamente a -x. Si el servidor 6286 4. Diseño y resolución del trabajo se ejecuta con esta opción activada, se inicia en modo debug y por consiguiente se muestran en pantalla todos los mensajes intercambiados entre cliente y servidor, así como otras notificaciones o errores. En cuanto a los parámetros se pueden distinguir -p y -h. Con el primero se puede seleccionar el puerto que el servidor abrirá para iniciar la comunicación. Con el segundo se selecciona la dirección IP del servidor de ficheros, es decir, el servidor VSFTPD. Si estos parámetros no se especifican al inicio, el servidor utiliza el puerto 8888 y la dirección IP por defecto. En caso de que estos parámetros sí sean indicados, pero no tengan la sintaxis correcta, la ejecución se cancela sin llegar a iniciar el servidor y se muestra en pantalla un mensaje de ayuda explicando cómo se ha de lanzar el servidor. Un ejemplo de esto es: > java S e r v i d o r RPi x p 8854 h Una vez que el servidor se ejecuta correctamente, atendiendo a la Figura 4.7, su ejecución comienza con la apertura del puerto y la posterior escucha esperando un nuevo cliente. 1 // Se abre el servidor en el puerto indicado 2 socketespera = new ServerSocket ( puerto ); 3 4 // Cada nuevo cliente se debe cambiar al estado inicial 5 estado = estadoinicial ; 6 7 // Se inicia la conexion y se espera un nuevo cliente 8 socketconexion = socketespera. accept (); Esta última acción deja el servidor en modo espera o escucha y únicamente se acepta la conexión cuando se recibe una petición de conexión por parte de un cliente. Una vez que se acepta la conexión con el cliente se han de abrir los flujos de envío y recepción de mensajes, es decir, los buffers que se utilizarán para el intercambio de mensajes. 1 // Se abren los flujos de envio / recepcion de mensajes : 2 canalsalida = new PrintWriter ( socketconexion. getoutputstream (), true ); 3 canalentrada = new BufferedReader ( new InputStreamReader ( socketconexion. getinputstream ())); Siguiendo con la implementación del servidor, una vez que se establece la comunicación cliente servidor, el servidor entra en un bucle en el que lee constantemente las peticiones recibidas por parte del cliente y actúa en consecuencia a cada una de ellas. Si se produce un error en la recepción de la petición (generalmente por problemas en los canales de entrada o salida) se maneja el error con la función manejarerrorsolicitud(). Esta función actúa en consecuencia al error obtenido (generalmente con un reinicio de la conexión con el cliente). 6387 4.2. Implementacion De este bucle sólo se puede salir estableciendo el valor de la variable cerrar = false. Una vez que se sale del bucle se cierran todas las conexiones y finalmente se cierra por completo el servidor. Dentro del bucle se implementa un switch principal en el que se determina el estado del servidor. Atendiendo al diagrama de la Figura 4.7 se han establecido tantas variables finales como estados componen el servidor. De esta forma cada vez que ocurre un evento determinado esta variable actualiza su valor en función del estado en el que se encuentre el servidor. La razón de esta implementación es porque en cada estado se puede recibir un tipo de mensajes diferente a los demás estados, de esta forma es más sencillo y eficiente manejar los mensajes leídos al inicio del bucle. Siempre que se inicia una nueva conexión con un cliente estado = estadoinicial. En este estado el mensaje que se puede recibir es USER. Si se recibe dicho mensaje se guardan los datos referentes al usuario y se actualiza estado = estadoidentificado. En caso de recibir cualquier otro mensaje se produce un error en la comunicación del protocolo y estado = estadoerror. Esta acción es equivalente a todos los estados que componen el servidor cuando se recibe un mensaje incorrecto. En este segundo estado, el mensaje que se debe recibir es FTP. Cuando se recibe el servidor se prepara para la obtención del fichero desde el servidor VSFTPD. Para ello se obtiene en primer lugar la extensión del archivo que se quiere mostrar, es decir, el tipo de archivo (PDF, JPG o PNG). Con esta extensión se crea la ruta que tendrá el fichero temporal utilizado, es decir, donde se guardará. Y por último se obtiene el fichero desde el servidor FTP. Para la obtención del fichero, surgió un inconveniente adicional, Java no tiene implementada una clase que permita conexión mediante FTP. Ante esto la opción más sencilla es reutilizar el código que PHP de implementaciones anteriores. Por la implementación del entorno web se sabe que se puede establecer una conexión segura al servidor de ficheros sin ningún tipo de problema mediante PHP. Por tanto, la solución adquirida en este punto equivale a la creación de un fichero PHP que se utiliza únicamente para descargar el archivo indicado. Este fichero será lanzado desde la aplicación Java, la cual le pasará todos los parámetros necesarios. 1 // Obtener la extension del archivo para completar la 2 // ruta donde se guardara el fichero 3 extension = ftp_archivo. substring ( ftp_archivo. length () -3); 4 5 // Se anade la extension al path 6 path = "/ home / pi/ Servidor / archivotemporal." + extension ; 7 8 int Npalabras = campos. length -1; // Variable auxilizar para el fichero descargar. php 9 10 // Comando para ejecutar el fichero que descarga el archivo temporal por 6488 4. Diseño y resolución del trabajo SFTP 11 String comando = " php -f descargar. php " + IP_ftp_server + " " + ftp_usuario + " " + ftp_password + " " + Npalabras + " " + ftp_archivo + " " + path + " " + debug ; // Ejecutar el comando 14 Process p = Runtime. getruntime (). exec ( comando ); Éste es el proceso para obtener el archivo, a continuación se describirá la implementación de descargar.php de forma que se facilite la compresión de la solución optada. descargar.php Este fichero es utilizado para descargar un archivo mediante el establecimiento de una conexión SSL hacia un servidor FTP, con unos datos de usuario y un destino de descarga. Su fundamento es igual al utilizado en el servidor HTTP. El fichero necesita como datos de entrada, y este mismo orden; dirección IP del servidor de ficheros, nombre de usuario, contraseña, número de palabras que componen el fichero que se va a descargar, nombre de dicho fichero, la ruta donde se guardará el archivo y por último una variable auxiliar utilizada para activar el modo debug. Un breve resumen de la implementación de este fichero es la siguiente: 1 // Establecer una conexion al servidor FTP 2 $conn_id = ftp_ssl_connect ( $ftp_ip_server, $ftp_puerto ); 3 4 // Iniciar una sesion con nombre de usuario y contrasena 5 $login_result = ftp_login ( $conn_id, $ftp_usuario, $ftp_password ); 6 7 // Obtener el archivo 8 ftp_get ( $conn_id, $path, $archivo, FTP_BINARY ) 9 10 // Se ciera la conexion FTP en cualquier caso 11 ftp_close ( $conn_id ); // Finalmente se obtiene la salida del error 14 // 0 -> no hay error 15 // 1 -> parametros incorrectos 16 // 2 -> error de conexion 17 // 3 -> error de autenticacion 18 // 4 -> error de descarga 19 echo $error ; Como se puede ver, el fichero termina devolviendo una variable error de salida, la cual será cero cuando el proceso haya transcurrido de forma correcta y contendrá un tipo de error en caso contrario. Este error se maneja fuera del este fichero. Se utiliza la función implementada en el servidor Java 6589 4.2. Implementacion manejarerrordescargar(), a la que hay que pasarle como parámetro el error resultante. Si todo ha ido correctamente el servidor avanza estado = estadoarchivo- Preparado. En este estado se puede recibir la petición ABRIR. Para abrir el archivo se utiliza la clase Desktop que proporciona Java. Con esta clase se puede abrir cualquier documento o archivo en el entorno de escritorio de la máquina que ejecuta el servidor. Hay que tener en cuenta en este caso que el programa usado para abrir los archivos es el que esté establecido por defecto en el equipo para cada tipo de extensión. Por lo que se debe establecer por defecto el visor de PDF, MuPDF, en la Raspberry Pi. 1 // Abrir el fichero 2 Desktop. getdesktop (). open ( new File ( ruta )); Una vez que se ejecuta este comando, se espera un tiempo de 2 segundos (ya que la acción de abrir el documento no es instantánea) y se lanza una acción para poner en pantalla completa el documento. En este paso el servidor ya ha avanzado a estado = estadoarchivoabierto. Y en este estado sólo se aceptan las peticiones que han sido definidas con anterioridad en el servidor, en caso contrario se produce un error en el protocolo diseñado. Los mensajes que aquí se pueden recibir se han descrito en la Sección Las funciones accionpdf y accionimg son las utilizadas para ejecutar las ordenes correspondiente a las peticiones recibidas desde el cliente. Estas funciones se usan según si el archivo mostrado es un documento PDF o una imagen. Ambas funciones tienen el mismo funcionamiento salvo que cambian la forma de ejecutar las órdenes recibidas. Estas funciones están constituidas por un switch donde se decide, en función del mensaje recibido, el código que se ejecuta en cada caso. Para ejecutar las órdenes se hace uso de la clase Robot también proporcionada por java. Esta clase permite simular el teclado de la máquina donde está corriendo el servidor. De esta forma, aprovechando que el software utilizado puede ser controlado mediante teclado, todas las acciones corresponden a pulsaciones de teclas. Así un ejemplo de ejecución de la orden COMPLE- TA es: 1 case " COMPLETA ": 2 // Ver en pantalla completa 3 teclado. keypress ( KeyEvent. VK_F ); 4 teclado. keyrelease ( KeyEvent. VK_F ); 5 break ; Finalmente, cuando el servidor recibe una petición CERRAR avanza estado = estadofinal. En este estado se utilizan las funciones borrararchi- 6690 4. Diseño y resolución del trabajo votemporal(), cerrarconexion() y nuevocliente(). De forma que se borra el archivo que se ha estado utilizando, se cierra toda conexión existente con el cliente y finalmente vuelve a escuchar en el puerto hasta que llegue un nuevo cliente. Por último, cabe destacar además que toda la implementación tiene un completo sistema de debug y log de forma que se pueda estudiar de forma sencilla qué está ocurriendo en cada momento en el servidor, y en caso de fallo, determinar dónde se encuentra y solucionarlo lo antes posible Cliente RPi Esta aplicación corresponde a la aplicación que debe ejecutar el cliente para conectarse al servidor RPi y en definitiva hacer uso del proyecto. En este caso, como la aplicación cliente consta de interfaz gráfica (applet), se implementan dos clases diferentes. Una correspondiente a la interfaz gráfica y otra correspondiente al ClienteRPi propiamente dicho. La primera clase, correspondiente al applet, se implementa como un JApplet. En ella se implementarán los botones y selecciones que permitirán la total manipulación del documento que se está mostrando en el proyecto. En este sentido se han diseñado dos interfaces diferentes en función del tipo de documento (PDF o imagen). El funcionamiento de ambos es el mismo, lo único que varía en este caso es el número de opciones del que dispone la interfaz. Por tanto, esta clase es muy sencilla, simplemente debe crear un objeto de la clase ClienteRPi y pasarle como entrada los parámetros procedentes del entorno web (dirección IP del servidor donde se va a mostrar, usuario, contraseña y archivo que se quiere mostrar). 1 // Se inicia el cliente 2 if (( servidor!= null ) && ( usuario!= null ) && ( password!= null ) && ( archivo!= null ) { 3 cliente = new Cliente ( servidor, puerto, usuario, password, archivo ); 4 } El cliente ejecuta por sí solo los mensajes obligatorios que el protocolo requiere a su inicio, como se vio en la Sección El último mensaje corresponde a ABRIR, por lo que una vez que se establece la conexión con el servidor y se muestra el archivo en el proyector es cuando se puede usar la interfaz de la aplicación cliente. Al realizar una petición desde la interfaz del applet, esta clase hace uso del objeto cliente creado anteriormente para enviar un mensaje con la petición deseada (la lista de posibles mensajes/peticiones se describió en la Sección 4.1.4) al servidor. Por otro lado, la implementación de la clase ClienteRPi debe seguir la 6791 4.2. Implementacion estructura de estados descrita en la Sección 4.1.3, por lo que al enviar un mensaje al servidor RPi siempre debe esperar una respuesta de éste. En primer lugar cuando se inicia el cliente se debe realizar la conexión con el servidor RPi: 1 // Inicio de la conexion con el servidor 2 socketconexion = new Socket ( servidor, puerto ); 3 4 // Apertura de los canales de envio / recepcion de mensajes : 5 canalsalida = new PrintWriter ( socketconexion. getoutputstream (), true ); 6 canalentrada = new BufferedReader ( new InputStreamReader ( socketconexion. getinputstream ())); Una vez que la conexión está establecida comienza el envío de los mensajes iniciales del protocolo: 1 // Mandar datos de usuario al servidor 2 clientetoservidor (" USER " + usuario + " " + password, 3 " Mandando datos de usuario "); 4 5 // Espera a recibir la respuesta del servidor 6 esperandoservidor (); 7 8 // Mandar peticion para descargar y preparar el archivo 9 clientetoservidor (" FTP " + archivo, " Mandando datos de archivo "); // Espera a recibir la respuesta del servidor 12 esperandoservidor (); // Mandar peticion para abrir archivo PDF 15 clientetoservidor (" ABRIR ", " Mandando peticion para abrir "); // Espera a recibir la respuesta del servidor 18 esperandoservidor (); Nuevamente, esto es sólo una breve descripción de la implementación realizada. La función clientetoservidor() es la encargada de mandar los mensajes hacia el servidor RPi. Existen dos versiones en función del número de parámetros que se le pasen. Si sólo es uno, únicamente envía el mensaje al servidor. Si se trata de dos parámetros, el segundo corresponde a la información que se quiere mostrar por pantalla en la ventana del cliente, es decir, es un parámetro utilizado para debug. La función esperandoservidor() es la utilizada para esperar a recibir el mensaje de respuesta del servidor. Esta función maneja la respuesta recibida en función de si ha ido todo correcto o se ha producido un error. En caso de error grave se cierra la conexión y se finaliza con la aplicación cliente mediante la función cerrarcliente(). Estas dos funciones (clientetoservidor() y esperandoservidor()) son las utilizadas por la clase de la interfaz para enviar peticiones y recibir las respuestas. Un ejemplo de su utilización es el siguiente: 6892 4. Diseño y resolución del trabajo 1 private void BotonAvanzarActionPerformed ( java. awt. event. ActionEvent evt ) { 2 // Mandar peticion de avanzar pagina 3 cliente. clientetoservidor (" AVANZAR "); 4 cliente. esperandoservidor (); 5 } Finalmente hay que añadir que, para dar mayor información acerca de la implementación tanto del Servidor RPi como de la aplicación Cliente RPi, se adjuntan a este documento los ficheros Java con la implementación, así como la documentación htdoc. Con esto se pretende permitir una mayor comprensión de la implementación realizada, además de facilitar a futuros usuarios que puedan modificar y mejorar la implementación. 6993 94 Capítulo 5 Evaluación y pruebas La fase de evaluación y prueba de la implementación ha estado muy presente a lo largo de toda la realización del proyecto, puesto que ha sido un trabajo constante. Se han estado probando diferentes configuraciones y soluciones hasta llegar a la solución final y para ello ha sido necesario un periodo de pruebas muy largo. No obstante, en este capítulo se hará un estudio y evaluación de los resultados obtenidos con la implementación final de este proyecto. En primer lugar, se hará una evaluación global haciendo uso de la herramienta Wireshark [83], mediante la cual se analizarán cuidadosamente los mensajes producidos en las comunicaciones. Después, se analizará el correcto funcionamiento en uno de los escenarios típicos de aplicación. Este escenario simulará el uso real del sistema en el ámbito de la docencia Análisis del tráfico Mediante el analizador de protocolos Wireshark se puede analizar el correcto funcionamiento del sistema ante distintas situaciones. En primer lugar, se analizará el establecimiento de una conexión al servidor HTTPS. Y en segundo lugar, se revisará el protocolo creado para la comunicación cliente servidor descrito en la Sección El escenario utilizado para el análisis consiste en un ordenador personal, donde se encuentran configurados el conjunto de servidores utilizados en este proyecto (OpenLDAP, FreeRADIUS, Apache, y VSFTPD), conectado mediante una red punto a punto con la Raspberry Pi. De forma que la dirección IP /24 corresponde con el equipo y la /24 a la Raspberry Pi (véase la Figura 5.1). 7195 5.1. Análisis del tráfico Figura 5.1: Escenario de aplicación del ejemplo Figura 5.2: Captura de Wireshark del establecimiento de la conexión Entorno web Para este caso se ha realizado una captura del tráfico global mientras se navegaba sobre el entorno web. Como se puede ver en la Figura 5.2 lo primero que se realiza es la conexión mediante TLS versión 1.2. En la imagen se puede observar el intercambio de mensajes hasta llegar a la correcta conexión con el servidor web. El mensaje número 6 corresponde con una alerta que se muestra al usuario en el navegador sobre el certificado. Esta alerta se produce porque la entidad certificadora que emite el certificado es desconocida. Esto es de esperar puesto que se trata de un servidor HTTP autofirmado y por tanto el certificado no ha sido creado por una entidad certificadora reconocida Si se profundiza en este mensaje se pueden obtener los datos correspondientes a dicho certificado, como puede observarse en la Figura 5.3. El siguiente paso es la autenticación del usuario. Para ello se realiza una conexión entre servidor HTTP y servidor RADIUS, y éste a su vez al servidor LDAP. Los mensajes correspondientes a la autenticación se muestran en la Figura Si se observa la imagen, se pueden ver los mensajes intercambiados, tan- Mostrar más
Departamento de Informática TRABAJO FIN DE GRADO APLICACIÓN MÓVIL PARA FOMENTAR LA SEGURIDAD VIAL EN ADOLESCENTES Y JÓVENES Autor: Tutor: Cotutor: Roberto Esteban Santiago Javier García Guzmán Alberto Más detalles Proyecto Fin de Carrera. Sistema de Monitorización de la infraestructura CCTV en la UC3M con Zabbix
Proyecto Fin de Carrera Sistema de Monitorización de la con Zabbix Alumno: Emilio Manuel González Pérez Tutor: Juan Manuel Canelada Oset Septiembre de 2010 A todos los que han hecho esto posible. AGRADECIMIENTOS Más detalles DESARROLLO DE UN SISTEMA DE RESERVAS DE SALAS VIRTUALES
UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITÉCNICA SUPERIOR PROYECTO FIN DE CARRERA DESARROLLO DE UN SISTEMA DE RESERVAS DE SALAS VIRTUALES AUTOR: Marta Hurtado Nieto TUTOR: Rafael Calzada Pradas Octubre Más detalles UNIVERSIDAD CATÓLICA DE CUENCA
UNIVERSIDAD AUTÓNOMA DE MADRID ESCUELA POLITÉCNICA SUPERIOR TRABAJO FIN DE GRADO Gestión de documentos en entornos colaborativos mediante un cliente Android (SITI_4/1314) Ignacio del Pozo Martínez Febrero Más detalles PROYECTO DE FIN DE CARRERA
PROYECTO DE FIN DE CARRERA TÍTULO DEL PFC: Adaptación de metodologías de Ingeniería de software orientadas a objeto al mantenimiento evolutivo de aplicaciones. Aplicación a un caso práctico. TITULACIÓN: Más detalles TRABAJO FIN DE GRADO GRADO EN INGENIERÍA DE TECNOLOGÍAS ESPECÍFICAS DE. Aplicación Android de Acceso a los Contenidos de Moodle
E.T.S.I. TELECOMUNICACIÓN TRABAJO FIN DE GRADO GRADO EN INGENIERÍA DE TECNOLOGÍAS ESPECÍFICAS DE TELECOMUNICACIÓN MENCIÓN EN INGENIERÍA DE SISTEMAS DE TELECOMUNICACIÓN Aplicación Android de Acceso a los Más detalles UNIVERSIDAD REY JUAN CARLOS
UNIVERSIDAD REY JUAN CARLOS GRADO EN INGENIERÍA DE SISTEMAS DE TELECOMUNICACIÓN Curso Acadámico 2014/2015 Trabajo Fin de Grado SISTEMA DE SEGUIMIENTO DE PARÁMETROS DE DESARROLLO DE PROYECTOS SOFTWARE Autor Más detalles ANÁLISIS, DISEÑO Y DESARROLLO DE UN CRM PARA UNA PYME
Departamento de Teoría de la Señal y Comunicaciones PROYECTO FIN DE CARRERA ANÁLISIS, DISEÑO Y DESARROLLO DE UN CRM PARA UNA PYME Autor: Daniel Torbellino Rubio Tutor: Matilde Sánchez Fernández Leganés, Más detalles IMPLANTACIÓN DE UN PORTLET AGENDA COMO HERRAMIENTA COLABORATIVA
UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN PROYECTO FIN DE CARRERA IMPLANTACIÓN DE UN PORTLET AGENDA COMO HERRAMIENTA COLABORATIVA Más detalles TRABAJO FIN DE GRADO. Aplicación para la gestión de proyectos ágiles con Scrum
TRABAJO FIN DE GRADO Título Aplicación para la gestión de proyectos ágiles con Scrum Autor/es Jesús María Eraso Lerena Director/es Jesús María Aransay Azofra Facultad Facultad de Ciencias, Estudios Agroalimentarios Más detalles UNIVERSIDAD DE OVIEDO TRABAJO FIN DE MÁSTER
UNIVERSIDAD DE OVIEDO ESCUELA INGENIERÍA INFORMÁTICA TRABAJO FIN DE MÁSTER Sistema de monitorización y programación de Backups Director: Dr. Agustín Cernuda Del Río Autor: Faustino Alonso Posada 2 Máster Más detalles ESCUELA DE INGENIERÍA EN SISTEMAS
i ESCUELA DE INGENIERÍA EN SISTEMAS Tema: IMPLEMENTACIÓN DE UN GESTOR DE SEMINARIOS EN LÍNEA PARA LA AUTO CAPACITACIÓN DE LOS ESTUDIANTES DE LA PUCESA EN EL AÑO 2011. Disertación de Grado Previa a la Obtención Más detalles CREACIÓN DE UNA PLATAFORMA DE DESARROLLO DE APLICACIONES PARA ANDROID
PROYECTO FIN DE CARRERA CREACIÓN DE UNA PLATAFORMA DE DESARROLLO DE APLICACIONES PARA ANDROID AUTOR: JOSÉ MIGUEL REYES IBARRECHE Madrid, Septiembre de 2010 Autorizada la entrega del proyecto del alumno/a: Más detalles Grado en Ingeniería Informática. Trabajo Final de Grado
Grado en Ingeniería Informática Trabajo Final de Grado Gestión de entorno de virtualización para la creación automática de máquinas virtuales Autor: Santiago CONESA BONO Tutor académico: Carlos Antonio Más detalles Trabajo fin de grado
GRADO EN INGENIERÍA INFORMÁTICA Integración de datos en una aplicación Web y Web Autor: Alberto Verza Salomón Tutora: Ana María Iglesias Maqueda Escuela Politécnica Superior Universidad Carlos III de Madrid Más detalles SISTEMA DE GESTION Y CONSULTA DOCUMENTAL BASADO EN ETIQUETADO INT TELIGENTE
Proyecto Fin de Carrera SISTEMA DE GESTION Y CONSU ULTA DOCUMENTAL BASADO EN ETIQU UETADO INTELIGENTE (DOCUMENT MANAGEMENT SYSTEM BASED ON SMART LABELING CONSULTATION) Para acceder al Titulo dee INGENIERO Más detalles SISTEMAS Y ENTORNOS DE PAGO PARA LA ADQUISICIÓN DE CONTENIDOS Y SERVICIOS ELECTRÓNICOS EN RED
Universidad de Murcia Departamento de Ingeniería de la Información y las Comunicaciones SISTEMAS Y ENTORNOS DE PAGO PARA LA ADQUISICIÓN DE CONTENIDOS Y SERVICIOS ELECTRÓNICOS EN RED Tesis Doctoral Antonio Más detalles ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN TESIS DOCTORAL
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN TESIS DOCTORAL PROPUESTA DE UNA ARQUITECTURA SOFTWARE BASADA EN SERVICIOS PARA LA IMPLEMENTACIÓN DE REPOSITORIOS Más detalles Sistema para la publicación y difusión de noticias
Sistema para la publicación y difusión de noticias Departamento de Arquitectura y Tecnología de los Computadores Proyectos Informáticos Ángel Daniel Sanjuán Espejo David Armenteros Escabias Tutores: José Más detalles TRABAJO FIN DE GRADO
UNIVERSIDAD AUTONOMA DE MADRID ESCUELA POLITECNICA SUPERIOR Grado en Ingeniería de Tecnologías y Servicios de Telecomunicación TRABAJO FIN DE GRADO Desarrollo de un sistema de medida de recogida de Datos Más detalles TRABAJO FIN DE GRADO. Web Application for Device Cloud Explorer
TRABAJO FIN DE GRADO Título Web Application for Device Cloud Explorer Autor/es Alejandro Vaquero Blanco Director/es Juan José Olarte Larrea Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Más detalles Autorizada la entrega del proyecto del alumno: Edgard Lucas López EL DIRECTOR DEL PROYECTO. Víctor Martínez Díaz. Fdo.:... Fecha:.../.../...
Autorizada la entrega del proyecto del alumno: Edgard Lucas López EL DIRECTOR DEL PROYECTO Víctor Martínez Díaz Fdo.:... Fecha:.../.../... Vº Bº del Coordinador de Proyectos Eduardo Alcalde Lancharro Fdo.:... Más detalles DESARROLLO DE APLICACIONES PARA DISPOSITIVOS MÓVILES SOBRE LA PLATAFORMA ANDROID DE GOOGLE
UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITÉCNICA SUPERIOR INGENIERÍA EN INFORMÁTICA PROYECTO FIN DE CARRERA DESARROLLO DE APLICACIONES PARA DISPOSITIVOS MÓVILES SOBRE LA PLATAFORMA ANDROID DE GOOGLE Más detalles Autorizada la entrega del proyecto del alumno: Carlos Cifuentes Fernández EL DIRECTOR DEL PROYECTO. David Contreras Bárcena
Autorizada la entrega del proyecto del alumno: EL DIRECTOR DEL PROYECTO David Contreras Bárcena Fdo.:. Fecha: / / Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.:. Fecha: / / UNIVERSIDAD Más detalles DESARROLLO WEB CON DRUPAL PARA UNA TIENDA DE INSTRUMENTOS MÚSICALES
DESARROLLO WEB CON DRUPAL PARA UNA TIENDA DE INSTRUMENTOS MÚSICALES MASTER INTERNACIONAL EN SOFTWARE LIBRE ADMINISTRACIÓN DE WEB Y DE COMERCIO ELECTRÓNICO EN ENTORNOS DE SOFTWARE LIBRE AUTOR: Mikel Ruiz Más detalles Creación de un portal web para un Centro Educativo
Año del Centenario de Machu Picchu para el Mundo Carrera Profesional de Computación e Informática Creación de un portal web para un Centro Educativo TRABAJO TEÓRICO PRÁCTICO Presentado por: ZAMUDIO ROMO, Más detalles Universidad de Jaén. Escuela Politécnica Superior de Jaén. Departamento de Informática
Universidad de Jaén Escuela Politécnica Superior de Jaén Departamento de Informática D. Luis Martínez López y Dª Macarena Espinilla Estévez, tutores del Proyecto Fin de Carrera titulado: Sistema M-Learning Más detalles UNIVERSIDAD REY JUAN CARLOS

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución