instituto politÉcnico nacional...m. en c. blanca alicia rico jiménez d. en c. miguel félix mata...

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA EN INGENIERÍA Y TECNOLOGÍAS AVANZADAS

UPIITA

Trabajo Terminal:

GUÍA MUSEOGRÁFICA MULTIMEDIA

Que para obtener el título de: “Ingeniero en Telemática”

Presentan:

Enríquez Olguín Aarón Rafael Juárez García José Alberto

Asesores:

M. en C. Blanca Alicia Rico Jiménez

D. en C. Miguel Felix Mata Rivera

México D.F. Mayo del 2010

INSTITUTO POLITÉCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA EN INGENIERÍA Y TECNOLOGÍAS AVANZADAS

UPIITA

Trabajo Terminal:

GUÍA MUSEOGRÁFICA MULTIMEDIA

Que para obtener el titulo de: “Ingeniero en Telemática”

Presentan:

Enríquez Olguín Aarón Rafael Juárez García José Alberto

Presidente Secretario

_____________________ ______________________

M. en C. Carlos Hernández Nava M. en C. Cyntia Enriquez Ortiz

Vocales

_____________________ ______________________

M. en C. Blanca Alicia Rico Jiménez D. en C. Miguel Félix Mata Rivera

ÍNDICE DE TABLAS

Página

Tabla 1.1 Características del Sistema de Navegación Guiada 6

Tabla 2.1 Estándares y Características 15

Tabla 2.2 Versiones del estándar 802.11 16

Tabla 2.3 Alcances en las diversas tecnologías y velocidades 17

Tabla 3.1 Casos de Uso de la Preparación de la Exposición 21

Tabla 3.2 Casos de Uso de la Aplicación Administrativa 22

Tabla 3.3 Casos de Uso de la Aplicación Móvil 24

Tabla 3.4 Casos de Uso del Servidor 24

Tabla 3.5 Descripción de la relación Sala 40

Tabla 3.6 Descripción de la relación Objeto 40

Tabla 3.7 Descripción de la relación Contenido 40

Tabla 3.8 Descripción de la relación Video 40

Tabla 3.9 Descripción de la relación Audio 41

Tabla 3.10 Descripción de la relación Imagen 41

Tabla 3.11 Descripción de la relación Administrador 41

Tabla 3.12 Comparación entre Lenguajes de Programación utilizados en aplicaciones de Escritorio

43

Tabla 3.13 Comparación entre herramientas para dibujar gráficos 44

Tabla 3.14 Comparación entre IDE’s para la aplicación móvil 45

Tabla 3.15 Comparación entre Lenguajes de programación utilizados en aplicaciones para iPhone® o iPod Touch®

45

Tabla 3.16 Características de Programabilidad 46

Tabla 3.17 Compatibilidad con estándares 47

Tabla 3.18 Integración e interoperabilidad 47

Tabla 3.19 Características administrativas 47

Tabla 3.20 Características del punto de acceso 50

Tabla 3.21 Características del Switch 53

Tabla 4.1 Datos cargados en la base de datos 57

Tabla 4.2 Características del Servidor 58

Tabla 4.3. Procedimiento para dibujar el piso de una sala

71

Tabla 4.4. Texturas y salas virtualizadas 73

Tabla 5.1.Resultados de las pruebas de conectividad y concurrencia

91

ÍNDICE DE FIGURAS

Página

Figura 2.1. Arquitectura de acuerdo con Mac Inc. de una comunicación utilizando HTTP Live Streaming

11

Figura 2.2. Archivo de Índice 12

Figura 2.3. Lista de flujos de respaldo 13

Figura 2.4.Red Wi-Fi Ad-Hoc 16

Figura 2.5.Red Wi-Fi de infraestructura 16

Figura 3.1. Diagrama de los módulos del sistema 19

Figura 3.2. Diagrama de Casos de Uso de la Preparación de la Exposición 21

Figura 3.3. Diagrama de Casos de Uso de la Aplicación Administrativa 22

Figura 3.4. Diagrama de Casos de Uso de la Aplicación Móvil 23

Figura 3.5. Diagrama de Casos de Uso del Servidor 24

Figura 3.6. Diagrama de Clases del Sistema 25

Figura 3.7. Diagrama de Secuencia de la Aplicación Móvil 26

Figura 3.8. Diagrama de Secuencia de la Aplicación Administrativa 27

Figura 3.9. Diagrama de Secuencia del papel del Programador 28

Figura 3.10. Diagrama de Actividades de la Aplicación Administrativa 29

Figura 3.11. Diagrama de Actividades de la Aplicación Móvil interactuando con el servidor

30

Figura 3.12. Diagrama de Estados de la Aplicación Móvil 31

Figura 3.13. Diagrama de Estados de la Aplicación Administrativa 32

Figura 3.14. Diagrama de Colaboración de la Aplicación Móvil 33

Figura 3.15. Diagrama de Colaboración de la Aplicación Administrativa 34

Figura 3.16. Diagrama de Colaboración del papel del Programador 34

Figura 3.17. Diagrama de Paquetes del sistema GMM 35

Figura 3.18. Diagrama Entidad Relación 38

Figura 3.19. Modelo Relacional 39

Figura 3.20. Área donde se instalará la red inalámbrica 49

Figura 3.21. Patrón de radiación de una antena dipolo 51

Figura 3.22. Canales de radio del estándar 802.11 51

Figura 3.23. Disposición de los puntos de acceso 52

Figura 3.24. Conexión de los puntos de acceso 53

Figura 4.1. Sentencias SQL para el ingreso de los registros en la tablas Sala y Obra

56

Figura 4.2. Organización de la Información dentro del Servidor 57

Figura 4.3. Configuración de las librerías FFmpeg

58

Figura 4.4. Codificación de videos utilizando las librerías FFmpeg 58

Figura 4.5. Código para generar el archivo binario del segmentador de archivos

58

Figura 4.6. Código utilizado para ejecutar el segmentador de archivo 58

Figura 4 .7. Formato del archivo de índices 59

Figura 4.8. Archivos creados por la aplicación Administrativa para la implementación del protocolo HTTP live streaming

59

Figura 4.9. Código para permitir la descarga de los archivos segmentados en el servidor

59

Figura 4.10. Servidor Darwin Streaming 60

Figura 4.11. Código que permite la conversión de formato mp3 a formato .aac

60

Figura 4.12. Código utilizado para la codificación del archivo 60

Figura 4.13. Código que permite crear el archivo con extensión mp4. 61

Figura 4.14. Archivo XML que muestra la información de los contenidos multimedia asociados a una obra

62

Figura 4.15. Archivo general de videos 62

Figura 4.16. Autenticación de Usuarios. 63

Figura 4.17. Proceso de registro de usuario(s) por primera vez 64

Figura 4.18. Menú Principal de la Aplicación Administrativa. 64

Figura 4.19. Consulta de contenidos multimedia asociados a una obra.

65

Figura 4.20. Asociar nuevo contenido multimedia a una obra en exposición 66

Figura 4.21. Actualización de Contenido Multimedia 68

Figura 4.22. Administración de usuarios

69

Figura 4.23. Textura de los muros en la sala Egipcia 71

Figura 4.24. Vista preliminar de la sala Egipcia 72

Figura 4.25. Creación de un objeto de tipo EAGLView en ObjectiveC 72

Figura 4.26. Plantilla de imágenes a descomponer 74

Figura 4.27. Código del método para dibujar una obra 74

Figura 4.28. Presentación de las obras en sala 74

Figura 4.29. Vista inicial y vistas de navegación en sala 75

Figura 4.30. Elementos de la vista de navegación en sala 76

Figura 4.31. Código para configurar e inicializar los acelerómetros 76

Figura 4.32. Uso de un filtro para obtener los valores de los acelerómetros 77

Figura 4.33. Programación de los eventos de la pantalla táctil 78

Figura 4.34. Diagrama de flujo de la recuperación de información 79

Figura 4.35. Vista para la búsqueda de contenidos 80

Figura 4.36. Mensaje de validación de red y obra 80

Figura 4.37. Vista de contenidos encontrados por obra 81

Figura 4.38. Reproducción de contenido de acuerdo con su tipo 82

Figura 4.39. Anverso y reverso de la ficha en la vista de imágenes 82

Figura 4.40. Vista de contenidos multimedia por tipo 83

Figura 4.41. Menú de ítems de navegación en la aplicación móvil 83

Figura 4.42. Vistas de la barra de ítems 84

Figura 4.43. Diagrama de flujo para el escenario de uso de la aplicación móvil 84

Figura 4.44. AppStore en iTunes® 85

Figura 4.45. Menú de configuración de GMM en Ajustes 85

Figura 4.46. Pantalla inicial de GMM 86

Figura 5.1. Intensidad de la señal detectada por el software a dos metros de distancia del punto de acceso

87

Figura 5.2. Gráfica que muestra la relación de la potencia de la señal [dBm] en el tiempo a dos metros de distancia

88

Figura 5.3. Intensidad de la señal detectada por el software a cuatro metros de distancia del punto de acceso

88

Figura 5.4. Gráfica que muestra la relación de la Potencia de la señal [dBm] en el tiempo a cuatro metros de distancia

89

Figura 5.5. Intensidad de la señal detectada por el software a siete metros de distancia del punto de acceso

89

Figura 5.6. Gráfica que muestra la relación de la Potencia de la señal [dBm] en el tiempo a siete metros de distancia

89

Figura 5.7.Reproducción de un video en iPhones®

90

ÍNDICE GENERAL

Página

RESUMEN 1

ABSTRACT 1

RESUMÉ 1

INTRODUCCIÓN 2

OBJETIVO GENERAL 3

OBJETIVOS PARTICULARES 3

ALCANCES 4

CAPÍTULO I – Planteamiento del Problema

1.1 – Definición del Problema 5

1.2 – Antecedentes 5

1.3 – Solución Propuesta 6

CAPÍTULO II – Marco Teoríco

2.1 – Aplicaciones para Móviles 8

2.2 – Dibujos por Computadora 9

2.2.1 - Realidad Virtual 9

2.3 – Aplicaciones de Escritorio 10

2.4 – Live Streaming. 10

2.4.1 – Tipos de Sesión 12

2.4.2 – Protección del Contenido 12

2.4.3 – Flujos Alternos 13

2.4.4 – Protección contra Fallos 13

2.5 – Red Inalámbrica 13

2.5.1 – Beneficios de las Redes Inalámbricas 14

2.5.2 – Funcionamiento General 14

2.5.3 – Tipos de Estándares para las Redes Inalámbricas 14

2.5.4 – Estándar IEEE 802.11 15

2.5.5 – Topología de Red 16

2.5.6 – Velocidades de transmisión de datos Wi-Fi 17

2.5.7 – Mecanismos de Seguridad para Wi-Fi 18

CAPÍTULO III – Diseño del Sistema

3.1 – Arquitectura del Sistema 19

3.2 – Análisis de los Requerimientos del Sistema 20

3.2.1 – Diagramas de Casos de Uso 20

3.2.2 – Diagramas de Clases 25

3.2.3 – Diagramas de Secuencia 26

3.2.4 – Diagramas de Actividades 28

3.2.5 – Diagramas de Estados 31

3.2.6 – Diagramas de Colaboración 33

3.2.7 – Diagrama de Paquetes 35

3.3 – Análisis de la Base de Datos 36

3.3.1 – Diseño Conceptual 37

3.3.2 – Diseño Lógico 38

3.3.3 – Diccionario de Datos 40

3.4 – Herramientas a Utilizar.

41

3.4.1 – Aplicación Administrativa

42

3.4.2 – Aplicación Móvil

43

3.4.3 – Sistema Gestor de Base de Datos

46

3.5 – Análisis y Diseño de la Red Inalámbrica

47

3.5.1 – Capacidad de la Red

48

3.5.2 – Designación del Área 48

3.5.3 – Evaluación física del sitio 49

3.5.4 – Selección del Estándar y hardware para el punto de acceso 50

3.5.5 – Arquitectura de red y disposición de los puntos de acceso 52

3.5.5 – Propuesta del Modelo de Propagación 53

CAPÍTULO IV – Desarrollo y Puesta en Marcha

4.1 – Aplicación Administrativa 55

4.1.1 – Creación de la Base de Datos 55

4.1.2 – Poblar Base de Datos 56

4.1.3 – Configuración del Servidor 57

4.1.4 – Protocolo HTTP Live Streaming para archivos de Video 57

4.1.5 – Protocolo HTTP Live Streaming para archivos de Audio 60

4.1.6 – Creación de los Archivos XML 61

4.1.7 – Funcionamiento de la Aplicación Administrativa 63

4.2 – Aplicación Móvil 69

4.2.1 – Temática de las salas y el contenido referente 69

4.2.2 – Virtualización del recinto 70

4.2.2.1 – Uso de texturas para piso y paredes 70

4.2.2.2 – Dibujo de obras en sala 73

4.2.3 – Navegación entre salas 75

4.2.4 – Navegación en sala con controles del iPhone® 76

4.2.4.1 – Uso de los eventos de los acelerómetros 76

4.2.4.2 – Uso de los eventos de la pantalla táctil 77

4.2.5 – Consulta de contenidos multimedia 78

4.2.5.1 – Búsqueda de contenidos por obra 78

4.2.5.2 – Recuperación y lectura del archivo XML de obra 81

4.2.5.3 – Carga y construcción de la vista de contenidos 81

4.2.5.4 – Reproducción de contenidos 82

4.2.5.5 – Consulta de contenidos por tipo 83

4.2.6 – Programación de las vistas y menús de acceso 83

4.2.7 – Uso y configuración de la aplicación 84


5.1 – Pruebas de la Red Inalámbrica 87

5.2 – Pruebas de conectividad y concurrencia del sistema

90

CONCLUSIONES 92

TRABAJO A FUTURO 93

BIBLIOGRAFÍA 94

GLOSARIO 97

1 | P á g i n a

RESUMEN

Se llevará a la práctica un sistema que permita poner al alcance de un usuario contenido multimedia (audio, imágenes y/o video) referente a uno o varios objetos* sujetos de una exposición. Antes del inicio de su recorrido el visitante deberá transferir la aplicación en su teléfono móvil iPhone® o en su iPod Touch®, misma que le servirá para poder visualizar de manera virtual en la pantalla las instalaciones del recinto; la aplicación además mostrará los objetos que se exhiben permitiendo acceder a la información multimedia referente a éstos. Para ello, la aplicación deberá de hacer la petición de acceso al contenido de un servidor con el cual se comunicará a través de una red inalámbrica dedicada para este propósito que cubra todo el recinto. El contenido multimedia se reproducirá en el teléfono sin que tenga que almacenarse, ahorrando espacio en disco. El contenido será administrado desde un servidor mediante una aplicación de escritorio pensada para ser usada por las autoridades responsables de la exposición.

ABSTRACT

A system is implemented to make available to a user multimedia content (audio, images or video) related to one or several objects of an exhibition. At the start of the tour, visitors must download the mobile application on their mobile phone iPhone® or on their iPod Touch®, it displays, on the screen, the virtualized campus facilities, the application also shows the objects on display allowing access to media information concerning them. For this, the application shall make the request for access to content from a server which communicates via a dedicated wireless network for this purpose that covers the entire building. The multimedia content is played back on the phone without having to be stored, saving disk space. The content is managed from a server via a desktop application designed to be used by the authorities responsible for the exhibition.

RESUMÉ

Un système est mis en œuvre pour mettre { la disposition des utilisateurs des contenus multimédia (audio, images ou vidéo) liés à un ou plusieurs objets d'une exposition. Au début de la tournée, les visiteurs devront télécharger l'application mobile sur leur téléphone mobile iPhone® ou sur leur iPod Touch®, elle affiche sur l'écran, les installations du campus virtuel, l’application indique également les objets sur l'écran permettant l'accès à l'information des médias à leur sujet. Pour cela, l’application doit en faire la demande pour l'accès au contenu { partir d'un serveur qui se communique via un réseau sans fil dédié à cet effet, qui couvre l'ensemble du bâtiment. Le contenu multimédia est lu sur le téléphone sans avoir à être stocké, économisant l'espace du disque. Ces contenus sont gérés à partir d'un serveur via une application de bureau conçue pour être utilisée par les autorités responsables de l'exposition.

2 | P á g i n a

INTRODUCCIÓN Hoy en día las telecomunicaciones se han vuelto parte fundamental de nuestras vidas, han cambiado la forma en la que el ser humano trabaja y se relaciona con su entorno a lo largo de los últimos 40 años. Con la revolución de la informática este cambio se vio más acentuado permitiendo que gran cantidad de información pasara de una persona hacia otra de manera sencilla y rápida. Intercambiar información a través de medios electrónicos nunca ha sido más sencillo que actualmente gracias al extensivo uso de la multimedia, que integra audio, imágenes y video. Es por eso que soluciones orientadas al uso de este tipo de tecnología han aparecido no sólo en internet a nivel de computadoras sino también en dispositivos portátiles que pueden ejecutar aplicaciones individuales que les permiten a su vez hacer uso de los recursos multimedia más utilizados hoy en día. Además de todo lo anterior, existe actualmente una tendencia revolucionaria en la forma en la que el ser humano interactúa con los dispositivos electrónicos que utiliza. Se puede decir que los años del mouse y el teclado están contados pues cada vez son más ampliamente utilizados otros dispositivos de entrada y salida de información, como es el caso de las pantallas táctiles en los teléfonos móviles de muchos usuarios de este servicio, sin mencionar características como conexión inalámbrica (por ejemplo, Bluetooth o WiFi), o funciones como la cámara de fotos y video. Es todo este abanico de posibilidades lo que ha permitido que un gran número de aplicaciones sean desarrolladas para dispositivos portátiles como teléfonos o PDAs, y las aplicaciones son variadas; las más comunes van desde los juegos de video a aplicaciones de oficina. Sin embargo una nueva tendencia se está popularizando alrededor del mundo, y consiste precisamente en utilizar las capacidades los dispositivos portátiles en pro del intercambio de información, para educar y entretener. En este sentido el siguiente trabajo propone una solución telemática para intercambiar contenido multimedia administrado desde el servidor de un museo o galería directamente a los celulares de los visitantes. En el presente documento se describe la información acerca de las plataformas de desarrollo utilizadas, el análisis teórico, la selección de herramientas, el desarrollo y las pruebas del funcionamiento del sistema desarrollado

3 | P á g i n a

OBJETIVO GENERAL

Crear un sistema telemático[1] que permita poner a disposición de un visitante, a través de una aplicación descargable a su teléfono celular iPhone® o a su iPod Touch®, contenido multimedia referente a objetos que formen parte de una exposición (e.g. muestra fotográfica, museo, zoológico, etc).

OBJETIVOS PARTICULARES

Diseñar y programar una aplicación para celulares modelo iPhone®, o iPod Touch® como alternativa, que muestre de manera virtual el espacio de exposición de las salas de un museo u otro recinto con los objetos que ahí se exhiben.

Diseñar y poner a funcionar un servidor de contenidos multimedia que deberá

dar servicio a las peticiones que se hagan por parte de los visitantes a través de la aplicación en sus móviles.

Crear una aplicación de escritorio que permita administrar el contenido

referente a las obras de la exposición. Será diseñada para que tales contenidos sean actualizados por el personal del recinto.

Finalmente, realizar la implementación de la red inalámbrica que se necesitará

para dar cobertura a un determinado número de visitantes en un recinto en particular.

4 | P á g i n a

ALCANCES El proyecto Guía Museográfica Multimedia (GMM) pretende ser una moderna alternativa tecnológica a los actuales sistemas de guías que se utilizan en museos y galerías; no pretende sustituirlos sino operar conjuntamente con ellos. La puesta en operación del sistema propuesto necesita ir de la mano del proceso de preparación y montaje de una exposición pues cada recinto es diferente así como la disposición de sus obras; por lo que la implementación y la virtualización del área del recorrido es particular para cada exhibición. Entonces un desarrollador se deberá de acompañar del curador encargado de la preparación de la exhibición con el fin de lograr una virtualización lo más cercana posible en similitud a las instalaciones reales. Es por eso que es aconsejable utilizar el sistema GMM en exposiciones estáticas o permanentes, en las cuales no varían las obras que se exponen. La puesta en macha del proyecto GMM además considera que la media de los visitantes posean un teléfono celular iPhone®. Este no es el caso de nuestro país donde la clase media y baja constituyen una parte importante de las audiencias de museos y galerías, sin embargo alternativas como la adquisición de dispositivos iPod Touch® por parte de los museos pudiera llegarse a considerar, para así dotar a los visitantes que no cuenten con uno de estos dispositivos. Finalmente es muy importante que el museo sea responsable de poder mantener bajo control el número de visitantes a los cuales da el servicio, pues no puede comprometer la capacidad de la red para proveer contenido a todos los usuarios en un momento dado.

5 | P á g i n a

CAPÍTULO I - Planteamiento del Problema

1.1 – Definición del Problema

Al visitar un museo, una galería de arte o un zoológico, por ejemplo, pocas son las opciones para conocer a profundidad y verdaderamente apreciar lo que en estos lugares podemos admirar. Sólo algunos recintos ofrecen servicios de visitas guiadas, por las cuales suele pagarse un monto extra, o por medio de audioguías. Este tipo de servicios han probado ser muy populares entre los visitantes sin embargo presentan algunas deficiencias que pueden ser superadas. Las audioguías que son usadas hoy en día[2], son dispositivos manuales que el visitante debe portar a lo largo de todo su recorrido, teniendo que seleccionar un número que identifica el objeto de la exposición del cual se quiere saber más, posteriormente se reproducirá la información deseada con la ventaja de que puede ser repetido cuantas veces se quiera y en múltiples idiomas. En el funcionamiento de estos dispositivos, descrito anteriormente, se pudieron identificar diversos puntos débiles. Primeramente, debido a su construcción, estos dispositivos tienden a ser muy aparatosos y difíciles de cargar pues necesitan de una batería recargable que dure al menos lo que tome al visitante hacer el recorrido. Además de esto, las audioguías actuales necesitan de una memoria interna que les permita contener toda la información disponible, misma que a veces puede verse comprometida si esta memoria no es lo suficientemente grande. Por otro lado cuando se requiere modificar la información de los objetos en exposición, la memoria de cada audioguía deberá de ser actualizada también, sin mencionar que este proceso se deberá de repetir para cada dispositivo. Aunado a esto, la utilidad final de las audioguías tiende a ser muy limitada pues la cantidad de información que el visitante puede asimilar, hacia el final de su recorrido, resulta ser un porcentaje muy pequeño del total de la información ofrecida. Todo esto sin mencionar que las audioguías usadas en los museos no presentan ningún beneficio para aquellas personas con problemas del sentido del oído. 1.2 – Antecedentes

Otro antecedente a la problemática, además de las audioguías que ya se describieron en el apartado anterior, es el “Sistema para navegación guiada en espacios reales con soporte de información contextual para dispositivos móviles”[3]. En este sistema se muestra un recorrido virtual a través de videos para poder localizar algún departamento o a alguna persona dentro de las instalaciones de la UPIITA.

6 | P á g i n a

En la tabla 1.1 se muestran las características generales que componen a dicho sistema. Sin embargo la metodología de solución tiene un enfoque distinto a lo que con la Guía Museográfica Multimedia se hará.

Sistema de Navegación

Guiada

Dispositivo Móvil PDA’s Virtualización Despliegue de videos Conexión entre el equipo móvil y el servidor

WiFi

Tipo de información que se pude descargar del servidor

Videos

Tabla 1.1 – Características del: Sistema para navegación guiada en espacios reales con soporte de información contextual para dispositivos móviles

1.3 – Solución Propuesta

De acuerdo con el problema planteado se pondrá en funcionamiento un sistema que, mediante una aplicación para un teléfono móvil de modelo iPhone® o un iPod Touch®, compatibles dado que tienen el mismo sistema operativo (iPhoneOS 3.0) y los controles que necesitamos, permita navegar a través de un espacio virtual con el fin de mostrar contenido multimedia referente a los objetos pertenecientes a una exposición de manera interactiva. Se eligió este modelo de teléfono en particular debido al tamaño y resolución de su pantalla, sus controles que utilizan acelerómetros y su capacidad de procesar gráficos, mismos que serán utilizados para el desarrollo de la aplicación móvil. Pocos son los teléfonos que actualmente se encuentra en el mercado y que ofrecen tales características, sin mencionar que este modelo ha probado ser muy popular. El sistema estará conformado por una aplicación gráfica. Ésta hará uso de recursos y bibliotecas gráficas para mostrar una representación virtual del espacio de exposición con los contenidos que en ella se encuentren. A su vez, también gestionará una serie de contenidos referentes al objeto deseado, que pueden ser videos, audio e imágenes; así, se enriquecerá la forma en la que trabajan las actuales guías. Todo lo anterior explotando las características del modelo de teléfono escogido y sustituyendo los dispositivos (audioguías) que ya se usan y que tienen una limitada capacidad de manejo de la información, tanto como la necesidad de ser recargadas tras una prolongada utilización. La ventaja principal de la aplicación para el móvil es crear una interfaz que el usuario comience a utilizar al iniciar su recorrido, pues cada visitante estará ya familiarizado con los controles de su propio teléfono, aunado al exhaustivo uso de gráficos haciendo la aplicación muy llamativa. El funcionamiento de esta aplicación consiste primeramente en la transferencia de la misma, en el teléfono celular iPhone® o en el reproductor iPod Touch® del usuario previo a su visita. Durante el recorrido, y de la misma forma como se hace actualmente con las

7 | P á g i n a

audioguías se deberá teclear el número asignado al objeto de exposición para acceder al contenido referente a éste, mismo que se mostrará en el recorrido virtual; el contenido también podrá ser accedido mediante una búsqueda en la aplicación móvil y ser consultado en cualquier momento de la visita. La aplicación que se pretende realizar mostrará en pantalla una representación virtual del lugar a visitar y, mediante los controles propios del teléfono móvil se podrá navegar a través de ella, pudiendo repetir el recorrido si así se quiere sin tener que volver a visitar físicamente una sala determinada. Por otro lado el sistema contará con un servidor de medios que mediante comunicación WiFi permita intercambiar el contenido multimedia con el móvil. En este servidor se deberán almacenar dichos contenidos, así como gestionar mediante una base de datos cuáles de ellos estarán disponibles para un determinado objeto de la exposición. Todo esto se manejará mediante una aplicación de escritorio que permita gestionar esta base de datos con el fin de ingresar o actualizar los contenidos existentes. Esta será una de las ventajas en cuanto a las audioguías existentes pues la información será actualizada por una entidad del centro de exposición sin la necesidad de terceros para el soporte técnico de este tipo. Estando dentro del área de cobertura y al hacerse la petición de contenido de un objeto determinado la aplicación hará una petición al servidor, mismo que enviará una lista de los contenidos disponibles de vuelta a la aplicación móvil. Posteriormente, al seleccionar un contenido en particular se hará nuevamente una petición al servidor para poder mostrarlo sin tener que almacenarlo en la memoria del teléfono.

8 | P á g i n a

CAPÍTULO II - Marco Teórico

En este capítulo se revisará la teoría relativa a los componentes que conforman el sistema, tales como aplicación móvil, aplicación de escritorio, dibujos por computadora, live streaming y conceptos generales de las redes inalámbricas. 2.1 – Aplicaciones para Móviles

Los dispositivos portátiles efectúan un conjunto de funciones que van desde un simple organizador personal hasta aquellas que corresponden al procesamiento de una computadora. Estos dispositivos son diseñados para facilitar la movilidad de los usuarios, por ello, se diseñan de tamaño compacto, con baterías de alta eficiencia y de peso ligero. El desarrollo de nuevas aplicaciones en las que intervienen los dispositivos móviles se ha vuelto indispensable para ciertos sectores de la población. La tendencia de los desarrolladores de software apunta hacia el empleo de estos dispositivos principalmente por su movilidad y la necesidad de tener a la mano la capacidad de obtener información del entorno en el que se desenvuelven. Toda esta tendencia se ve beneficiada por las características de hardware que ofrecen los distintos distribuidores. La capacidad de los dispositivos móviles está en constante crecimiento, ofreciendo mejores herramientas para poder implementar aplicaciones que cubran necesidades de los usuarios actuales. Sin duda una de las aplicaciones más populares por los usuarios de este tipo de dispositivos son las que se refieren a la reproducción de audio y video. A continuación se muestra un panorama general para la programación en el iPhone® ya que será el dispositivo con que se realice la virtualización del recinto. El sistema operativo del iPhone® es, en esencia, el mismo que usan las Mac’s desde hace casi diez años. Este fue desarrollado por NeXT, empresa que también desarrolló un framework de programación orientado a objetos conocido como Cocoa, la base sobre la que se construye cualquier aplicación nativa para el iPhone® o para el iPod Touch®. Cocoa es una API escrita en un dialecto especial de C llamado Objective-C. En particular, cuando desarrollamos para el iPhone® o iPod Touch®, usamos Cocoa Touch. Donde la diferencia básica radica en la forma en la que el usuario invoca comandos. Ejemplo: en Cocoa Touch usamos un teclado virtual y nuestros dedos directamente sobre la pantalla. Por encima de la API se encuentran las herramientas que forman parte del entorno de desarrollo de la plataforma[4].

http://en.wikipedia.org/wiki/NeXT

http://en.wikipedia.org/wiki/Application_programming_interface

http://en.wikipedia.org/wiki/C_%28programming_language%29

9 | P á g i n a

2.2 – Dibujo por Computadora

La tecnología ofrece herramientas que permiten representar figuras y formas acercándose cada vez más la realidad. Estas herramientas se pueden dividir básicamente en programas de dibujo en dos dimensiones (2D) y modeladores en tres dimensiones (3D). Las herramientas de dibujo en 2D se basan en entidades geométricas vectoriales como puntos, líneas, arcos y polígonos, con las que se puede operar a través de una interfaz gráfica[5]. Los modeladores en 3D añaden superficies y sólidos. El usuario puede asociar a cada entidad una serie de propiedades como color, capa, estilo de línea, nombre, definición geométrica, etc., que permiten manejar la información de forma lógica. Además pueden asociarse a las entidades o conjuntos de éstas otro tipo de propiedades como material, texturas, etc. Los modeladores en 3D pueden, además, producir pre visualizaciones del producto, este es el caso de OPENGL el cual consiste en más de 250 funciones diferentes que pueden usarse para dibujar escenas tridimensionales complejas a partir de primitivas geométricas simples, tales como puntos, líneas y triángulos. Fue desarrollado originalmente por Silicon Graphics Inc. (SGI) en 1992 y se usa ampliamente en Dibujo Asistido por Computadora, realidad virtual, desarrollo de videojuegos[6]. OPENGL tiene dos propósitos esenciales:

Ocultar la complejidad de la interfaz con las diferentes tarjetas gráficas, presentando al programador una API única y uniforme.

Ocultar las diferentes capacidades de las diversas plataformas hardware, requiriendo que todas las implementaciones soporten la funcionalidad completa de OPENGL (utilizando emulación software si fuese necesario).

2.2.1 – Realidad Virtual Se podría definir como un sistema informático que genera representaciones de la realidad, que de hecho no son más que ilusiones ya que se trata de una realidad perceptiva sin ningún soporte físico y que únicamente se da en el interior de los ordenadores[7]. La simulación que hace la realidad virtual se puede referir a escenas virtuales, creando un mundo virtual que sólo existe en el ordenador de lugares u objetos que existen en la realidad. También permite capturar la voluntad implícita del usuario en sus movimientos naturales proyectándolos en el mundo virtual que estamos generando. La realidad virtual puede ser de dos tipos: inmersiva y no inmersiva. Los métodos inmersivos de realidad virtual con frecuencia se ligan a un ambiente tridimensional creado por computadora el cual se manipula a través de cascos, guantes u otros dispositivos que capturan la posición y rotación de diferentes partes del cuerpo humano. La realidad virtual

http://es.wikipedia.org/wiki/Punto_%28geometr%C3%ADa%29

http://es.wikipedia.org/wiki/L%C3%ADneas

http://es.wikipedia.org/wiki/Arco_%28geometr%C3%ADa%29

http://es.wikipedia.org/wiki/Pol%C3%ADgonos

http://es.wikipedia.org/wiki/Interfaz

http://es.wikipedia.org/wiki/Silicon_Graphics

http://es.wikipedia.org/wiki/Silicon_Graphics

http://es.wikipedia.org/wiki/1992

http://es.wikipedia.org/wiki/Dise%C3%B1o_asistido_por_computador

http://es.wikipedia.org/wiki/Realidad_virtual

http://es.wikipedia.org/wiki/Desarrollo_de_videojuegos

http://es.wikipedia.org/wiki/Tarjeta_gr%C3%A1fica

10 | P á g i n a

no inmersiva utiliza medios como el que actualmente nos ofrece Internet en el cual podemos interactuar en tiempo real con diferentes personas en espacios y ambientes que en realidad no existen sin la necesidad de dispositivos adicionales a la computadora. Este último es el tipo de realidad virtual que se creará en el iPhone® o iPod Touch® para la aplicación móvil. La realidad virtual no inmersiva ofrece un nuevo mundo a través de una ventana de escritorio. Este enfoque no inmersivo tiene varias ventajas sobre el enfoque inmersivo como: bajo costo y fácil y rápida aceptación de los usurarios. Los dispositivos inmersivos son de alto costo y generalmente el usurario prefiere manipular el ambiente virtual por medio de dispositivos familiares como son el teclado y el ratón. 2.3 – Aplicaciones de Escritorio

Desde un enfoque empresarial, una aplicación de escritorio es una interfaz entre un formulario informático diseñado específicamente para cubrir con las necesidades del negocio y la información que tiene hacia el interior de la empresa, como pueden ser sistemas administrativos, inventarios, facturación, productos, etcétera. La información puede ser de dominio público, lo que significa que cualquier persona pueda consultarla e interactuar con ella, o restringida en la que sólo ciertas personas accedan a través de un nombre de usuario y contraseña[8]. 2.4 – Protocolo HTTP Live Streaming

Se ha elegido la tecnología de streaming para este proyecto ya que es utilizada para aligerar la descarga y ejecución de audio y vídeo en la web, permite escuchar y visualizar los archivos mientras se están descargando. El streaming funciona, primeramente en nuestro ordenador (el cliente) que se conecta con el servidor y éste le empieza a mandar un determinado archivo. El cliente comienza a recibir el archivo y construye un buffer donde empieza a guardar la información. Cuando se ha llenado el buffer con una pequeña parte del archivo, el cliente lo empieza a mostrar y a la vez continúa con la descarga. El sistema está sincronizado para que el archivo se pueda ver mientras que el archivo se descarga, de modo que la descarga termine antes que la visualización. Si en algún momento la conexión sufre descensos de velocidad se utiliza la información que hay en el buffer. Si la comunicación se corta demasiado tiempo, el buffer se vacía y la ejecución el archivo se cortaría también hasta que se restaurase la señal. Existen varios protocolos que permiten realizar esta transferencia desde el servidor y hasta el cliente. En particular para las transmisiones en vivo para el iPhone® se utiliza el protocolo HTTP Live Streaming. Este consiste en hacer llevar los fragmentos de video o audio por medio del protocolo HTTP ya existente.

11 | P á g i n a

HTTP Live Streaming permite enviar audio y video pregrabado o en vivo a un iPhone® u otros dispositivos, tales como una computadora de escritorio o un servidor web ordinario. No es necesario hacer uso de un servidor con funciones especializadas que generalmente resultan difíciles de mantener y que suelen ser caros.

Figura 2.1. Arquitectura de acuerdo con Mac Inc. de una comunicación utilizando HTTP Live Streaming[9]

En la figura 2.1 se describe una configuración básica para una comunicación basada en el protocolo HTTP Live Streaming. Conceptualmente, este protocolo consiste en tres partes: un componente servidor, un componente de distribución y el software del cliente. El componente del servidor es responsable de tomar flujos de entrada de multimedia, codificarlos digitalmente, encapsularlos y prepararlos para su distribución. Posteriormente, el componente de distribución consiste de servidores web estándares. Éstos son responsables de aceptar las solicitudes del cliente y entregar la multimedia y los recursos asociados al cliente. Finalmente, el software del cliente es responsable de determinar la multimedia adecuada a solicitar, descargando estos recursos, y posteriormente rensamblándolos de tal manera que puedan ser presentados de manera continua. El flujo de entrada puede ser en vivo o pregrabado, en el caso de la GMM (Guía Multimedia Museográfica) serás archivos ya pregrabados. Estos archivos deberán de estar codificados en un flujo de transporte de MPEG3 para los archivos de audio y MPEG4 para los videos que luego serán segmentados y almacenados como una serie de archivos con extensión .ts; esto se logrará utilizando un software segmentador de flujo. Este segmentador también crea un archivo de índice que contiene la lista de los nombres de los fragmentos de multimedia. El URL de este archivo es luego accedido por los clientes quienes a través de éste accederán a los archivos indexados secuencialmente.

12 | P á g i n a

Figura 2.2. Archivo de Índice

2.4.1 – Tipos de Sesión

Existen dos tipos de sesiones para la transferencia de audio y video por medio de la red. Una se refiere a la transferencia en vivo, donde nuevos archivos de medios son creados e incluidos en el archivo de indexado. En las sesiones de video bajo demanda (VOD) se hacen archivos de medios que duran el total de la transmisión. El archivo de indexado es estático y contiene una lista completa de los archivos creados desde el inicio de la presentación. Lo que provee al cliente el acceso completo al programa en toda su duración. Siendo esta la opción más viable para el tipo de aplicación que se desarrollará. 2.4.2 – Protección del Contenido

Los archivos multimedia contenidos en un flujo pueden ser encriptados individualmente. De ser así se agregan las referencias a la clave en el archivo de indexado para que el cliente pueda descifrarlo. Cuando un archivo que contiene la clase se enlista en el archivo de indexado, éste contiene una secuencia de número que se ocupa para descifrar los archivos de medios subsecuentes. Actualmente HTTP Live Streaming soporta encriptación AES-128 con claves de 16 octetos. Este formato de la clase es un arreglo empaquetado de estos 16 octetos en formato binario.

13 | P á g i n a

2.4.3 – Flujos Alternos

Los archivos de indexado pueden hacer referencia a flujos alternos de contenido. Estos pueden utilizarse para llevar múltiples flujos con el mismo contenido pero con diferentes niveles de calidad para varios anchos de banda disponibles y dispositivos de reproducción. Característica que representa una ventaja para nuestro sistema tomando en cuenta que el ancho de banda variará dependiendo del número de usuarios conectados. El archivo de indexado entonces apunta a flujos alternos al incluir listas especialmente etiquetadas que referencian otros archivos de indexado. Nótese que el cliente puede elegir cambiar de flujo en cualquier momento, por ejemplo cuando un dispositivo móvil entra o sale del área de cobertura de un punto de acceso.

2.4.4 – Protección contra fallos

Si se tienen múltiples flujos alternos, no sólo operan como alternativas para el ancho de banda o el dispositivo de acceso, sino como redundancia. En el caso que se produzca una falla al cargar un archivo de medios, el cliente escogerá otro con la mayor calidad posible, sino cambiará a otro de menor calidad.

Para implementar esta protección contra fallos se crea una lista con múltiples flujos como se hace normalmente. Posteriormente se crean uno o varios flujos paralelos en un servidor por separado. Y se agrega la lista de los flujos de respaldo inmediatamente después de la lista del flujo principal como se observa en la figura 2.3.

Figura 2.3 Lista de flujos de respaldo

2.5 – Red Inalámbrica

Las Redes Inalámbricas son sistemas flexibles de comunicaciones. Utilizan tecnología de radiofrecuencia minimizando así la necesidad de conexiones cableadas. El atractivo fundamental de este tipo de redes es la facilidad de instalación y el ahorro que supone la eliminación del medio de trasmisión cableado. Son la alternativa ideal para hacer llegar una red LAN a lugares donde el cableado no lo permite.

14 | P á g i n a

2.5.1 – Beneficios de las Redes Inalámbricas

Simplificar la Instalación de Sistemas

Disminuir el costo de mantenimiento por averías, reposiciones, eliminación e

incorporación de nuevas unidades, así como costos de instalación.

Dar movilidad a los equipos de forma que se puedan conectarse o desconectarse de

manera rápida y sencilla.

Aumentar el alcance de las conexiones.

El cambio de topología de red es sencillo y trata de igual manera pequeñas y grandes

redes[10]

. 2.5.2 – Funcionamiento General

Este tipo de redes utilizan ondas de radio o rayos infrarrojos para transmitir la información de un punto a otro sin necesidad de un medio físico, las ondas de radio son normalmente referidas a portadoras de radio que únicamente realizan la función de llevar la energía a un receptor remoto. Los datos a transmitir se superponen a la portadora de radio y de este modo pueden ser extraídos exactamente en el receptor final, esto es llamado modulación de la portadora por la información que está siendo transmitida. Varias portadoras pueden existir en igual tiempo y espacio sin interferir entre ellas, si las ondas son trasmitidas a distintas frecuencias de radio.

Para extraer los datos el receptor se sitúa en una determinada frecuencia ignorando el resto. En una configuración típica de Red Inalámbrica los puntos de acceso (AP) son los encargados de recibir la información, almacenarla y transmitirla. Estos pueden soportar un pequeño grupo de usuarios y puede funcionar en un rango de al menos treinta metros.

El usuario final accede a la red inalámbrica a través de tarjetas de usuario, que proporcionan una interfaz entre el sistema de operación de red del cliente y las ondas, vía una antena. La naturaleza de la conexión sin cable es transparente al sistema del cliente[10].

2.5.3 – Tipos de Estándares para las Redes Inalámbricas

Existen varios estándares para las redes inalámbricas, los cuales se listan a continuación.

Home RF BlueTooth HiperLAN IEEE 802.11

15 | P á g i n a

En la tabla 2.1 se muestran las diferentes características de los estándares HomeRF, BlueTooth y 802.11b.

Home RF Blue Tooth 802.11b

Capa Física FHSS FHSS FHSS Potencia de Transmisión Máxima

100 mW 100 mW 800 mW

Velocidad de Datos 1 o 2 Mbps 1 Mbps 11 Mbps Número Máximo de Dispositivos

Hasta 127 Hasta 26 Hasta 256

Covertura 46 m 8 m 80 m

Costo Ni más ni menos

costoso Menos costoso Más costoso

Alcance Exterior No No Sí Tabla 2.1. Estándares y Características

2.5.4 – Estándar IEEE 802.11

WiFi es el nombre comercial del estándar IEEE 802.11 desarrollado por el grupo de comercio industrial WiFi Alliance. Éste fue adoptado en 1997 y se convirtió en el estándar para redes inalámbricas. El objetivo es desarrollar un Control de Acceso al Medio (MAC) y las especificaciones de la capa Física para la conectividad inalámbrica para terminales fijas y móviles dentro de una LAN.

El estándar define varías funciones específicas, entre las cuales destacan:

Especifica las funciones y servicios requeridos para operar en una red con topología Ad-Hoc y con topología de infraestructura, además de los aspectos de movilidad de estaciones dentro de las redes.

Define los procedimientos de la capa MAC. Define las técnicas de señalización. Describe los procedimientos y requerimientos para proveer privacidad a la

transferencia de datos.

Wi-Fi es una tecnología novedosa y práctica que se está difundiendo muy rápidamente, pero Wi-Fi es una tecnología inmadura, ya que va requiriendo nuevos estándares o modificaciones en los estándares existentes, a medida que van apareciendo inconvenientes.

A continuación la tabla 2.2 muestra las versiones del estándar 802.11 más utilizadas comercialmente.

16 | P á g i n a

VERSIÓN

DEL ESTÁNDAR

FRECUENCIA PORTADORA

VELOCIDAD DE DATOS

NÚMERO DE CANALES NO

TRASLAPADOS RESUMEN

802.11a 5.1 – 5.2 GHz, 5.2 – 5.3 GHZ, 5.7 – 5.8 GHz

54 Mbps 12 La potencia máxima es de 40 mW en la banda 5.1 y 800 mW en la banda 5.7

802.11b 2.4 – 2.485

GHz 11 Mbps 3

Es el estándar que mayor mercado tiene actualmente

802.11g 2.4 – 2.485

GHz 36 o 54 Mbps

3 Para redes de alto desempeño

Tabla 2.2. Versiones del estándar 802.11

2.5.5 – Topologías de Red

Las redes basadas en el estándar 802.11 pueden operar bajo dos topologías de red:

Topología Ad-Hoc: consiste de dos o más nodos, también llamados estaciones. Estas redes tienden a ser temporales y se usan cuando dos o más equipos portátiles se conectan entre ellos para intercambiar información. La figura 2.4 muestra un ejemplo de este tipo de red.

Figura 2.4. Red Wi-Fi Ad-Hoc

Topología de Infraestructura: existe un punto de acceso con la que se conectan los usuarios, es el dispositivo encargado de controlar el tráfico que fluye entre los AP y los usuarios. La figura 2.5 muestra un ejemplo de una red con esta topología.

Figura 2.5. Red Wi-Fi de Infraestructura

17 | P á g i n a

2.5.6 – Velocidades de transmisión datos en Wi-Fi

Las redes Wi-Fi están alcanzando un gran auge a pesar de las restricciones técnicas que presentan, tales como la velocidad de transmisión, alcance de los puntos de acceso (AP) y el restringido número de usuarios por cada AP.

Para aumentar o disminuir el desempeño de la red inalámbrica hay que tener en cuenta que no está en función de disminuir o cambiar en ancho de banda, por el contrario, es una función del tipo de modulación que se utilice. Como se puede observar en la tabla 2.2 la velocidad de cada uno de los estándares va variando ya que cada uno utiliza una modulación diferente[11].

La velocidad de transmisión del estándar 802.11g es de 54 Mbps, pero en la práctica se podrán tener velocidades máximas de 20 a 24 Mbps. Los puntos de acceso que trabajan con este estándar incorporan una función denominada “auto- step” que es la disminución de la velocidad. Estas disminuciones no son graduales si no que se presentan en escalones. Para el estándar 802.11g las velocidades bajan de: 54 Mbps a 48, 36, 24, 18, 12, 11, 9, 6, 5.5, 2, 1Mbps. Estableciendo que los usuarios que estén más lejos del puto de acceso tendrán comunicaciones a velocidades más bajas que los que estén cerca.

Una relación genérica es que, a medida que la velocidad aumenta, el alcance disminuye. La tabla 2.3 ilustra una aproximación de los alcances en las diversas tecnologías y velocidades.

DATA RATE

802.11A (40 MW CON 6DBI DE GANANCIA POR DIVERSIDAD)

ALCANCE

802.11G (30 MW CON 2,2 DBI DE

GANANCIA POR DIVERSIDAD)

ALCANCE

802.11B (100 MW CON 2,2 DBI DE GANANCIA POR DIVERSIDAD)

ALCANCE

54 13 m 27 m 48 15 m 29 m 36 19 m 30 m 24 26 m 42 m 18 33 m 54 m 12 39 m 64 m 11 48 m 48 m 9 45 m 76 m 6 50 m 91 m

5.5 67 m 67 m 2 82 m 82 m 1 124 m 124 m

Tabla 2.3. Alcances en las diversas tecnologías y velocidades

18 | P á g i n a

2.5.7 – Mecanismos de Seguridad para Wi-Fi

La seguridad en las redes inalámbricas es una necesidad, dado que la información se trasmite a determinadas zonas, en las cuales cualquier usuario con un equipo que trabaje bajo el estándar que se esté utilizando en la red puede acceder a la información. Sin embargo, la mayoría de las redes no cuentan con una herramienta de seguridad debidamente configurada o poseen un nivel de seguridad muy débil, con lo cual se pone en riesgo la confidencialidad e integridad de la información de la red. A continuación se presentan los mecanismos de seguridad más usados en las redes Wi-Fi[10].

WEP (Wired Equivalent Protocol): Es un sistema de cifrado implementado en la capa MAC y soportado por la mayoría de los puntos de acceso. Comprime y cifra los datos que se envían a través de las ondas de radio. Su objetivo es proporcionar confidencialidad, autenticación y control de acceso a las redes inalámbricas. No contemplan ningún mecanismo de distribución automática de claves, lo que obliga a escribir la clave manualmente en cada uno de los equipos de la red

OSA (Open System Authentication): Es el mecanismo de autenticación por defecto del estándar 802.11, sirve para autenticar todas las peticiones que recibe el AP. El principal problema que tiene es que no realiza ninguna comprobación del equipo del usuario, además las tramas son enviadas sin cifrar, por lo tanto es un mecanismo poco fiable.

ACL (Acces Control List): Utiliza como mecanismo de autenticación la dirección MAC de cada equipo del usuario, permitiendo el acceso a aquellas direcciones que consten en la lista de control de acceso.

WAP (Wi-Fi Protected Acces): soluciona todas las debilidades conocidas de WEP y se considera suficientemente seguro. Sus principales características son la distribución dinámica de claves, mejora la confidencialidad e integra nuevas técnicas de autenticación.

19 | P á g i n a

CAPÍTULO III - Diseño del Sistema

3.1 – Arquitectura del Sistema

De acuerdo al funcionamiento descrito en la Solución Propuesta del Capítulo I, el sistema a poner en práctica puede ser dividido en cinco módulos que se describen a continuación:

Figura 3.1. Diagrama de módulos del sistema

1. Base de Datos del Contenido Multimedia (CM) – El sistema debe de contar con una base de datos con la cual se administre el contenido multimedia que se le asociará a cada objeto de la exposición. La base de datos además podrá gestionar los archivos y su ubicación; esto se hará almacenando la dirección con la que podrá acceder la aplicación móvil a cada archivo del contenido multimedia como un campo de la tabla que contenga los datos del contenido.

2. Aplicación Administrativa – Es una aplicación de escritorio con la que el personal del centro de exposición podrá contar para asociar contenido multimedia a un objeto en la exposición; entre otras tareas también podrá quitar este contenido o actualizarlo.

3. Red Inalámbrica Dedicada – Se implementará la red que permita dar servicio a los usuarios de la aplicación móvil. Esto conlleva identificar las características que deberá tener para poder transmitir los archivos multimedia a un determinado número de visitantes dentro del área correspondiente al recorrido. Es importante mencionar que de ser necesario se utilizarán varios puntos de acceso para distribuir la carga de trabajo. Se debe tomar en cuenta además que la calidad, duración (no mayor a tres minutos) y formato de los videos no serán un problema al momento de transmitirlos, no ocupando un ancho de banda mayor que podría soportar la red que se implementará, tomando en cuenta que habrá más usuarios conectados.

Aplicación administrativa de

gestión de los contenidos

SERVIDOR

PUNTO DE ACCESO

CM

2

1

USUARIOS

3

Aplicación

gráfica móvil

COMUNICACIÓN

4

Descarga de

la aplicación

móvil previo

al recorrido 5

20 | P á g i n a

4. Aplicación Móvil (guía) – Se diseñará un programa, que mediante el uso de gráficos permitirá navegar en una representación virtual del recinto de exposición, se pretende además explotar las características que un iPhone® o un iPod Touch® ofrecen en los controles (acelerómetros y pantalla táctil) y el procesamiento de gráficos. El programa también deberá hacer la petición al servidor cuando el usuario así lo requiera para reproducir un contenido determinado.

5. Instalación de la Aplicación Móvil – Previo al recorrido el visitante deberá de descargar e instalar la aplicación móvil a la que podrá acceder a través de la iTunes Store® de Apple.

3.2 – Análisis de los requerimientos del sistema

El análisis de requerimientos representa el conjunto de procedimientos que permiten conocer los elementos necesarios para definir el sistema, en esta etapa se especifica lo que desea el usuario y la forma en la cual se va a presentar la solución. Es decir, implica determinar el conjunto de necesidades que debe cubrir la aplicación para ejecutar todas sus funciones de manera correcta. Este análisis sirvió para determinar alcances y características con las que debe contar el sistema. 3.2.1 – Diagramas de Casos de Uso

Los diagramas de casos de uso modelan el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas; y presentan una vista de cómo pueden utilizarse los distintos elementos de la aplicación en un contexto dado. A continuación se muestran los casos de uso del sistema[11]. En primer caso para poder realizar la virtualización un programador será necesario, con el cual colaborará el curador. Una vez que se terminó de montar la exposición físicamente es entonces cuando se procederá a virtualizar las salas del recorrido con los objetos que en ella se encuentren. La cuestión principal en este escenario es que los identificadores de los objetos virtualizados por la guía deberán de coincidir con los registros de estos en la base de datos en el servidor. Es por esto que un programador se asegurará de dar de alta en la BD sólo aquellos objetos que se hayan virtualizado, y sean resultado de la estrecha colaboración con el curador, la disposición que estos tengan dentro de una sala.

21 | P á g i n a

Figura 3.2. Diagrama de Casos de Uso de la Preparación de la Exposición

Actor Principal: Programador Personal involucrado e intereses:

Programador: hacer la virtualización del recinto, registrar las salas y obras de exposición en la Base de Datos y asignar identificadores de las obras.

Precondiciones: Mantener contacto con un Curador, el cual proporcionará la información acerca de las salas

que conformar el recorrido, la disposición de los objetos dentro de una sala, y el contenido temático del mismo.

Escenario principal de éxito: Se registrarán satisfactoriamente en la Base de Datos las salas y sus respectivas obras en exposición, además de que la virtualización corresponda con las características físicas del recinto.

Garantías de éxito: Haber registrado primero una sala en la cual se quiera colocar un objeto. Estar además en comunicación con el Curador para hacer coincidir la virtualización con el recinto. Mantener la concordancia entre los objetos almacenados en la Base de Datos y los mostrados en la aplicación móvil.

Requisitos especiales: El alta de las salas y los objetos se tiene que hacer posterior al montaje de la exposición.

Frecuencia: El registro de salas y objetos se hará sólo una vez al poner en marcha el sistema. Tabla 3.1. Casos de Uso de la Preparación de la Exposición

UML versión 2.0 NetBeans 6.7

22 | P á g i n a

Figura 3.3. Diagrama de Casos de Uso de la Aplicación Administrativa

Actor Principal: Administrador, quien es un profesional designado por las autoridades del museo con conocimientos informáticos

Personal involucrado e intereses: Administrador: Gestionar el contenido multimedia de las obras de exposición.

Precondiciones: Haber dado de alta las salas del recinto y las obras de exposición.

Escenario principal de éxito: Se asociaron contenidos satisfactoriamente a un objeto en particular de la exposición.

Garantías de éxito: El identificador para acceder al contenido deberá ser único

Requisitos especiales: El formato del contenido multimedia a asociar sea soportado por el iPhone® o iPod Touch ®.

Frecuencia: Durante el perido en que la exposición este en exhibición Tabla 3.2. Casos de Uso de la Aplicación Administrativa

El diagrama de la figura 3.3 describe los procesos que un administrador realiza sobre los objetos de exposición. A través de la aplicación de escritorio se puede asociar o desasociar determinados contenidos multimedia a un objeto de la exposición.


23 | P á g i n a

Es importante mencionar que la aplicación administrativa se encargará de realizar las operaciones de programación que hagan estos cambios a la base de datos del contenido multimedia y ponerlos a disposición de los usuarios a través de la aplicación móvil. Es justo la figura 3.4 la que nos describe el respectivo diagrama de casos de uso de la aplicación móvil. Aquí se describe el proceso de navegar por la virtualización del recinto y la consulta de los contenidos multimedia que efectúa el visitante. Además es la aplicación móvil la que funge como interfaz entre el visitante y el servidor de medios, obteniendo la lista de contenido multimedia referente a un objeto de la exposición en particular; y posteriormente obtener el contenido multimedia elegido. El servidor se encargará entonces de procesar estas peticiones y enviar el contenido requerido por la aplicación móvil a través de la red establecida. Además, al inicio de la navegación la aplicación móvil se encargará de resaltar las obras de una determinada sala si estas se encuentran en una lista de objetos con contenido multimedia asociado.

Figura 3.4. Diagrama de Casos de Uso de la Aplicación Móvil


24 | P á g i n a

Actor Principal: Visitante.

Personal involucrado e intereses: Visitante: Navegar con la aplicación móvil, seleccionar un objeto con contenido asociado y

seleccionar un contenido disponible.

Precondiciones: Haber descargado la aplicación móvil en su iPhone® al inicio del recorrido. Estar dentro del

alcance de la red WiFi.

Escenario principal de éxito: El visitante tras haber navegado seleccionará un objeto y un contenido y podrá observarlo y escucharlo en su iPhone® sin tener que descargarlo.

Garantías de éxito: Haber tecleado el código correcto del objeto.

Requisitos especiales: Ninguno

Frecuencia: Mientras dure el recorrido. Tabla 3.3. Casos de Uso de la Aplicación Móvil

Figura 3.5. Diagrama de Casos de Uso del Servidor

Actor Principal: Servidor .

Personal involucrado e intereses: Servidor: atiende peticiones de la aplicación móvil siendo un intermediario entre está y la

BD.

Precondiciones: Haber cargado el contenido multimedia en el Servidor.

Escenario principal de éxito: Ejecución y envío de resultado de consultas.

Garantías de éxito: Ninguno

Requisitos especiales: La red de comunicación inalámbrica este en operación.

Frecuencia: Mientras dure el recorrido. Tabla 3.4. Casos de Uso del Servidor


25 | P á g i n a

3.2.2 – Diagrama de Clases

El diagrama de clases es el diagrama principal de diseño para el sistema. En él, la

estructura de clases del sistema se especifica, con relaciones entre clases y estructuras que se han

definido para el funcionamiento de la guía.

Una clase captura la estructura y comportamiento común del conjunto de objetos que se

requieren para integrar el sistema.

El diagrama de clases de la figura 3.6 describe el funcionamiento general del sistema

donde se especifican los objetos que intervienen así como las relaciones que entre ellos existen,

describiendo la cardinalidad, sus parámetros y métodos particulares.

Figura 3.6. Diagrama de Clases del Sistema


26 | P á g i n a

3.2.3 – Diagramas de Secuencia

En estos diagramas descriptivos se muestra la interacción que existe entre los objetos que componen el sistema y la secuencia de mensajes que se intercambian entre ellos.

El primer diagrama (figura 3.7) se muestra cómo el visitante a través de su iPhone®

o iPod Touch® navega en la aplicación y hace peticiones para poder reproducir el contenido multimedia deseado en su dispositivo.

Figura 3.7. Diagrama de secuencia de la Aplicación Móvil

Los siguientes diagramas (figura 3.8 a y b) ejemplifican las funciones que puede realizar el administrador con la aplicación administrativa. Se muestra el intercambio de mensajes entre los objetos para poder asociar o desasociar un contenido multimedia a una obra en exposición determinada.


27 | P á g i n a

(a) Eliminar Contenido Multimedia de una obra de Exposición

(b) Asociar Contenido Multimedia a una Obra de Exposición

Figura 3.8. Diagrama de Secuencia de la Aplicación Administrativa

Por último se presenta el diagrama (figura 3.9) que muestra la intervención del programador para preparar el sistema antes de que se ponga en marcha.



28 | P á g i n a

Figura 3.9. Diagrama de Secuencia del papel del Programador

3.2.4 – Diagramas de Actividades

Permiten modelar el flujo de actividades del sistema. Las actividades originan alguna acción que produce un cambio en el estado del sistema o la devolución de un valor.

A continuación, en la figura 3.10 se presentan las actividades que pude realizar el administrador con la aplicación administrativa.

29 | P á g i n a

Figura 3.10. Diagrama de Actividades de la Aplicación Administrativa

En el diagrama de la figura 3.11 se muestra el proceso por medio del cual el usuario podrá reproducir el contenido multimedia seleccionado. Muestra también actividades que el servidor realizará al recibir peticiones de los visitantes. Cabe resaltar que desde la actividad de navegar por las salas hasta reproducir el contenido se estarán repitiendo mientras el visistante esté dentro de las instalaciones del recinto.


30 | P á g i n a

Figura 3.11. Diagrama de Actividades de la Aplicación Móvil interactuando con el servidor

3.2.5 – Diagrama de Estados

Los diagramas de estados son una técnica que permite describir el comportamiento del sistema. Describe todos los estados posibles en los que puede entrar un objeto, que, para nuestros fines serán las aplicaciones móvil y administrativa. En el caso de la aplicación móvil, se inicia mostrando las salas que conforman el espacio de exposición, sea un recinto en su totalidad o una parte de éste.


31 | P á g i n a

Figura 3.12. Diagrama de Estados de la Aplicación Móvil

Como se muestra en el diagrama de la figura 3.12, el paso posterior es la esperar “selección de sala”, y, una vez seleccionada, será virtualizada. Es justo este proceso el que implica dibujar los objetos propios de la sala, consultando la base de datos en el servidor. El siguiente paso es la navegación en la sala por parte del usuario, actualizando la virtualización con cada movimiento. Luego, se espera por la selección de un objeto en la sala; al seleccionarse uno, se procede a consultar los contenidos que éste tiene registrados en el servidor y mostrarlos en pantalla como una lista, dónde se esperará que el usuario escoja uno de los contenidos. Finalmente, y al seleccionar un contenido, éste se reproducirá mediante streaming. Es importante mencionar que el usuario puede regresar a los menús anteriores seleccionando salir, pudiendo así regresar hasta la lista de salas o salir por completo de la aplicación. Por parte de la aplicación administrativa el número de estados y su descripción pueden verse descritos en el diagrama de la figura 3.13.


32 | P á g i n a

Figura 3.13. Diagrama de Estados de la Aplicación Administrativa El primer estado de la Aplicación Administrativa es la autenticación del usuario, que deberá identificarse como administrador. Posteriormente, se puede gestionar el contenido multimedia de las obras en exposición. Para el registro o eliminación de contenido se deberá primero seleccionar la sala en el que estará exhibido, después se selecciona el objeto con el cual se quiere asociar. Finalmente, cualquiera de estos procesos termina, si así se desea con el fin de la aplicación.


33 | P á g i n a

3.2.6 – Diagramas de Colaboración

Los diagramas de colaboración son la segunda forma de diagramas de interacción. En estos diagramas los objetos ahora se muestran como iconos. Las flechas indican, como en los diagramas de secuencia, los mensajes enviados dentro del caso de uso dado. Sin embargo, ahora se numeran los mensajes para indicar la secuencia. Al igual que en los anteriores diagramas, se hizo un diagrama para cada aplicación, granularizando cada proceso propio del uso de cada módulo del sistema. El siguiente diagrama (figura 3.14) describe la colaboración que se da entre los actores y objetos definidos para la aplicación móvil.

Figura 3.14. Diagrama de Colaboración de la Aplicación Móvil

El diagrama de colaboración que se muestra anteriormente describe los procesos que se siguen al elegir un contenido multimedia a través de la aplicación móvil. Es de notarse la interacción que se da entre actores y objetos involucrados. Al igual que en los diagramas de secuencia se puede observar el camino que se tiene que recorrer para hacer pleno uso de la aplicación mencionada. Y tal como se describió para el diagrama de secuencia, primero debe de seleccionarse una de las salas que conforman el recorrido, posteriormente se buscan los objetos registrados en el servidor pertenecientes a esta sala. Una vez obtenida la lista se muestran en la visualización esperando por que el usuario seleccione uno y a su vez se buscarán los contenidos en la base de datos que estén relacionados con dicho objeto.


34 | P á g i n a

Para el caso de la aplicación administrativa, el diagrama es el siguiente (figura 3.15).

Figura 3.15. Diagrama de Colaboración de la Aplicación Administrativa

En este caso la secuencia a seguir para ingresar un contenido para determinado objeto se bosqueja en el diagrama anterior, donde nuevamente se muestra la interacción entre actores y objetos. Finalmente se muestra las acciones que desempeña el programador dentro del sistema, cabe mencionar que estas funciones se deben realizar antes de poner en marcha el sistema.

Figura 3.16. Diagrama de Colaboración del papel del Programador

3.2.7 – Diagrama de Paquetes

Como diagrama final, se presenta el diagrama de paquetes que permite fragmentar el sistema completo en sistemas más pequeños, haciendo más fácil comprender de qué partes está conformado. El diagrama de paquetes se muestra en la figura 3.17.



35 | P á g i n a

Figura 3.17. Diagrama de Paquetes del sistema GMM

La división natural de nuestro sistema se da entre el equipo del visitante (guía) y el servidor. Del lado del visitante tenemos:

El paquete de interacción que comprende todas aquellas clases y componentes que van a permitir la programación de los controles (acelerómetros, pantalla táctil).

El paquete de virtualización, que se refiere a las clases proporcionadas por las librerías gráficas OPENGL para realizar la representación del recinto.

La visualización que permitirá enviar una salida en pantalla durante la navegación

no sólo por el recinto sino también por los menús de la aplicación. En el otro lado tenemos al servidor con los paquetes de:


36 | P á g i n a

Transmisión, donde describimos aquellos procesos que implementan el protocolo de transmisión Live streaming, y las peticiones de envío de información hechas por la aplicación móvil.

Gestión, que permitirá procesar y hacer las operaciones sobre la base de datos de contenidos.

Contenido, que es precisamente la recopilación de los archivos seleccionados como un contenido asociado a determinado objeto.

3.3 – Análisis de la Base de Datos

La base de datos del sistema es uno de los puntos fundamentales para su correcto funcionamiento, ya que en ella se encuentra centralizada la información sobre los contenidos multimedia asociados a una obra dentro de una sala de exposición. En el presente apartado se presenta el diseño de la base de datos por medio del modelo Entidad- Relación (E-R) y el Modelo Relacional.

Uno de los enfoques básicos antes de plantear la base de datos es el análisis de las

características de los usuarios del sistema, para lo cual es indispensable conocer los requerimientos de los mismos en el acceso a la información.

Como ya se ha explicado en el Capítulo I, los usuarios harán consultas del contenido

multimedia almacenado en el servidor por medio de la aplicación móvil. El tipo de datos multimedia que se utilizarán son los siguientes.

Texto: para hacer referencia a descripciones de las obras en exposición. Imágenes: elementos gráficos codificados en formato png, jpg, o gif. Video: secuencia temporal de imágenes en formato MPEG4, soportado por los

teléfonos iPhone® y dispositivos iPod Touch®. Audio: en formato MPEG3.

El contenido multimedia se forma asociando diferentes tipos de objetos a una obra

en exposición. La representación del contenido multimedia en la base de datos busca comunicar de

forma efectiva a la aplicación administrativa con las peticiones de los usuarios y el contenido multimedia, por lo que se hará uso de una base de datos referencial, las cuales se definen como bancos de datos sobre material como películas, imágenes, audio, animaciones, etc[13].

En la mayoría de los casos, la información que se almacena hace referencia a

cuestiones descriptivas (autor, título, duración, productor, etc.) o a cuestiones técnicas (formato, duración, etc.).

37 | P á g i n a

Dentro de la base de datos se almacenará la dirección donde la aplicación móvil encontrará el contenido dentro del servidor de medios. Es importante mencionar que existen Bases de Datos Multimedia que son mecanismos de representación y recuperación de información gráfica que permiten el desarrollo de nuevas interfaces de usuario, integración general de hipertexto e hipermedia, etc[15]. Pero se ha descartado esta opción debido a los inconvenientes que se presentan a continuación

Necesita grandes espacios para almacenar toda la información que queremos.

Este tipo de bases de datos necesitan grandes anchos de banda para obtener un rendimiento óptimo.

Complejidad en cuanto a programar operaciones, o incluso la interfaz, debido a la alta cantidad de formatos que hay que manejar, lo que puede repercutir en su rendimiento.

El sistema no integrará distintos formatos, debió a el procesamiento del servidor para poder compartir los archivos por medio de streaming

3.3.1 – Diseño Conceptual

Se requiere diseñar una base de datos con el fin de integrar toda la información referente a las obras de una exposición. Es importante identificar a las personas que podrán administrar la base de datos a través de un nombre de usuario y una contraseña esto con el fin de controlar el acceso a la aplicación administrativa.

De cada sala es importante conocer el nombre y su descripción. Este último se

refiere a los temas que se abarcan en ella. En cada sala se puede albergar una o varias obras de exposición de las cuales se

requiere saber el nombre, autor y una breve descripción, donde se incluya la información referente a la obra.

Cada obra puede tener asociado uno o varios contenidos multimedia. Éste puede ser audio, imágenes o videos de los cuales interesa conocer su nombre, ubicación en el servidor y tamaño que ocupan en disco duro. Además para los videos se requiere saber la resolución, duración, y ubicación del archivo original, para las imágenes se requiere sus dimensiones y una breve descripción, y para el audio el tiempo de duración, calidad del archivo, y la ubicación original. La información de ubicación original se requiere ya que como los archivos de audio y de video son codificados para implementar el protocolo HTTP live streaming, la aplicación necesita la ruta de los archivos originales para poder reproducirlos. Es importante tener en cuenta que no toda obra tendrá contenido multimedia asociado.

38 | P á g i n a

De acuerdo con el texto anteriormente planteado y habiéndose analizado, la figura 3.18 presenta el modelo Entidad Relación.

Figura 3.18. Diagrama Entidad Relación

Los atributos de cada una de las entidades mostradas en el diagrama anterior son:

ADMINISTRADOR

Id_administrador ہ(id principal)

nombre_usuario ہ password ہ Nombre ہ Apellido Paterno ہ Apellido Materno ہ puesto ہ

SALA

id_sala (id primario) ہ nombre ہ descripción ہ

OBRA DE EXPOSICIÓN

id_obra (id primario) ہ nombre ہ autor ہ descripción ہ

CONTENIDO MULTIMEDIA

id_contenido (id primario) ہ

nombre ہ

ubicación ہ

tamaño ہ

39 | P á g i n a

AUDIO

duración ہ calidad ہ reproducir ہ

IMAGENES

alto ہ ancho ہ descripción ہ

VIDEO

duración ہ reproducir ہ resolución ہ

3.3.2 – Diseño Lógico

A partir del diagrama entidad relación y aplicando el algoritmo de conversión se obtiene el modelo relacional descrito por la figura 3.19[15]:

Figura 3.19. Modelo Relacional

40 | P á g i n a

3.3.3 – Diccionario de Datos Tabla SALA

ATRIBUTO TIPO DE DATO DEFINICIÓN INFORMACIÓN

Id_sala Integer(3) No nulo Número entero no mayor a 999 Nombre Varchar(50) No nulo Texto no mayor de 50 caracteres Descripción Varchar(500) nulo Texto no mayor de 500 caracteres

Tabla 3.5. Descripción de la relación SALA Tabla OBJETO DE EXPOSICIÓN


Id_obra Integer(4) No nulo Número entero no mayor a 9999 Id_sala Integer(3) No nulo Número entero no mayor a 999 Nombre Varchar(50) No nulo Texto no mayor de 50 caracteres Autor Varchar(100) nulo Texto no mayor de 100 caracteres Descripción Varchar(500) nulo Texto no mayor de 500 caracteres

Tabla 3.6. Descripción de la relación OBJETO Tabla CONTENIDO


Id_contenido Integer(5) No nulo Número entero no mayor a 99999 Id_obra Integer(4) No nulo Número entero no mayor a 9999 Nombre Varchar(50) No nulo Texto no mayor de 50 caracteres Ubicación Varchar(100) No nulo URL del archivo no mayor de 100 caracteres Tamaño Varchar(10) No nulo Tamaño en bytes del archivo, 10 caracteres

Tabla 3.7. Descripción de la relación CONTENIDO Tabla VIDEO


Id_contenido Integer(5) No nulo Número entero no mayor a 99999 Id_video Integer(5) No nulo Número entero no mayor a 99999 Resolución Varchar(10) No nulo Texto descriptivo de la resolución del video Duración Integer(3) No nulo Duración en segundos, no mayor a 999

segundos Reproducir Varchar(100) No nulo Texto no mayor a 100 caracteres

Tabla 3.8. Descripción de la relación VIDEO

41 | P á g i n a

Tabla AUDIO


Id_contenido Integer(5) No nulo Número entero no mayor a 99999 Id_audio Integer(5) No nulo Número entero no mayor a 99999 Calidad Varchar(10) No nulo Texto descriptivo de la calidad del audio (e.g.

CD de Audio) Duración Integer(3) No nulo Duración en segundos, no mayor a 999

segundos Reproducir Varchar(100) No nulo Texto no mayor a 100 caracteres

Tabla 3.9. Descripción de la relación AUDIO

Tabla IMAGEN


Id_contenido Integer(5) No nulo Número entero no mayor a 99999 Id_imagen Integer(5) No nulo Número entero no mayor a 99999 Alto Integer(3) No nulo Numero entero indicando el alto en pixeles, no

mayor a 999 Ancho Integer(3) No nulo Numero entero indicando el ancho en pixeles, no

mayor a 999 Descripción Varchar (500) No nulo Texto no mayor a 500 caracteres

Tabla 3.10. Descripción de la relación IMAGEN

Tabla ADMINISTRADOR


Id_admisnistrador Integer(2) No nulo Número entero no mayor a 999 Nombre_usuario Varchar(10) No nulo Palabra no mayor a 10 caracteres Contraseña Varchar(10) No nulo Palabra no mayor a 10 caracteres Nombre Varchar(50) No nulo Texto no mayor a 50 caracteres Apellido Paterno Varchar(50) No nulo Texto no mayor de 50 caracteres Apellido Materno Varchar(50) No nulo Texto no mayor de 50 caracteres Puesto Varchar(20) No nulo Texto no mayor a 20 caracteres

Tabla 3.11. Descripción de la relación ADMINISTRADOR

3.4 – Herramientas a Utilizar.

Se utilizará software libre para las aplicaciones que requiere el sistema, por las siguientes razones:

Poder utilizar gran cantidad de herramientas libres disponibles en la actualidad. Esto no sólo implica la ejecución de dichas herramientas, sino también la modificación de las mismas para adaptarlas a casos particulares y la exploración de sus mecanismos de funcionamiento para luego reutilizarlos. De esta forma se

42 | P á g i n a

obtiene una ventaja significativa respecto al modelo propietario o cerrado, que no pueden utilizar esta base de herramientas y conocimiento.

El liberar un programa facilita enormemente su distribución y publicidad.

Si el producto tiene suficientes méritos técnicos, con seguridad despertará el interés de un gran número de desarrolladores, los cuales comenzarán a contribuir en su desarrollo, extensión y depuración. Muchos son los casos en que pequeños emprendimientos han engendrado productos de gran nivel técnico y de una extensión impensada.

3.4.1 – Aplicación Administrativa

Para la Aplicación Administrativa que se desarrollará se requiere contar con las siguientes características:

Portabilidad: pueda ejecutarse en diferentes sistemas operativos sin hacer modificaciones de importancia, ya que en dado caso de distribuir la aplicación, se pueda instalar en cualquier máquina que funja como servidor.

Programación Orientada a Objetos: permita la creación de interfaces gráficas.

Software Libre: El manejo del lenguaje de programación es gratuito.

Manejo de excepciones: El leguaje de programación ayude a tener un control de los errores que se pueden presentar durante la ejecución del mismo.

Existen numerosos lenguajes de programación utilizados para el desarrollo de aplicaciones de escritorio. Está investigación se realizó en base a los lenguajes de programación actualmente más usados y los requerimientos anteriormente planteados. Entre los que destacan:

Java Visual Basic Visual Basic .NET – C#

La tabla 3.12 muestra una tabla comparativa entre las características de estos leguajes de programación.

43 | P á g i n a

REQUERIMIENTOS JAVA[16] Visual Basic [17] C #[17] Software libre Si Comercial Comercial

Creación de interfaces de usuario

Si Si Si

Portable Si No No

Conexión al SGBD Soportado Soportado Soportado

Paradigma Orientado a Objetos Orientado a Objetos Orientado a Objetos

Dinámico Si No No Manejo de Excepciones

Soportado Soportado Soportado

Tabla 3.12 – Comparación entre Lenguajes de Programación utilizados en aplicaciones de Escritorio

Se observa que Java se adecua más a nuestras necesidades por el hecho de ser software libre y ser multiplataforma ya que en los otros requerimientos los tres lenguajes de programación analizados se encuentran en igualdad de condiciones. Por lo que Java será el lenguaje a utilizar.

El entorno de desarrollo (IDE) que se utilizará será NetBeans debido a que es gratuito y de código abierto. Sus componentes básicos son:

Un editor de texto Un compilador Un intérprete Herramientas de automatización Posibilidad de ofrecer un sistema de control de versiones. Factibilidad para ayudar en la construcción de interfaces de usuarios.

Es posible que en NetBeans se trabajen varios lenguajes de programación, mediante plugins que se puede agregar. Con la ayuda de estas herramientas NetBeans se utilizó para realizar el diagramado UML correspondiente. 3.4.2 – Aplicación Móvil

Como ya se mencionó en el Capítulo I la aplicación que se requiere desarrollar es para un teléfono móvil iPhone® o dispositivo iPod Touch®. Además, se mencionó que se realizará una vitalización del recinto por lo que para generarla se puede hacer uso de las siguientes herramientas mostradas en la tabla 3.13.

44 | P á g i n a

Requerimientos OPENGL[7] JAVA 3D[16] DIRECTX

Desarrollador Silicon Graphics Sun Microsystems Microsoft

Software libre Sí Sí No

Plataformas de trabajo

PC, Mac, Linux, SGI workstations, etc.

Multiplataforma Windows

Dimensiones de visualización

Aceleración en hardware 3D

3D Aceleración en hardware 3D

Lenguajes soportados

C, C++ y Objective C, con bindings para VB, Pascal, Delphi,

Python, Java, C#, etc.

Java como binding de OPENGL

Microsoft Visual C++, Delphi, C# y Visual

Basic .NET

Documentación Muy bien

documentado Bien documentado Bien documentado

Soportado por iPhone OS

Sí No No

Tabla 3.13. Comparación entre herramientas para dibujar gráficos

Desde un inicio se planteó el uso de las bibliotecas gráficas OPENGL para realizar

esta tarea. Basándonos en la tabla 3.13, se observar que la elección de OPENGL como especificación de gráficos es la elección natural, no sólo por su popularidad, facilidad de uso y documentación, sino porque es soportado por el iPhone®, punto que inclina la balanza en su favor. Además el que sea multilenguaje y multiplataforma facilita la selección del lenguaje de programación y la plataforma de desarrollo más adecuada para el sistema.

Para desarrollar la Aplicación Móvil es importante denotar los requerimientos de la misma como se muestran a continuación:

Deberá de trabajar sobre una arquitectura definida por su sistema operativo

(iPhone OS, a su vez basado en una variante del Mach kernel que se encuentra en MacOS X). El iPhone OS adem|s incluye el componente de software “Core Animation” de MacOS X v10.5 que, junto con el PowerVR MBX, el hardware de 3D, es responsable de las animaciones usadas en el interfaz de usuario.

Emulación de aplicaciones para iPhone® o iPod Touch®

Soporte de librerías gráficas de OPENGL ES

De acuerdo con lo planteado se procedió con la investigación de los entornos de desarrollo más comunes que nos permitan programar la aplicación móvil para el iPhone®. Véase 3.14.

45 | P á g i n a

REQUERIMIENTOS

MOBIONE® NETBEANS® XCODE®

Proveedor GENUITEC Sun MicroSystems Apple Inc.

Sistema Operativo Windows Windows, Linux Mac OS X

Compatibilidad con sistema operativo iPhone OS

Sí Sí, mediante una API Sí

Emulación de aplicaciones para iPhone o iPod Touch

Sí No Sí

Soporte de librerías gráficas de OpenGL ES

No No Sí

Capacidad para soportar distintos lenguajes de programación

No Sí, entre ellos Java, C y

C++.

Sí, entre ellos Java, C, C++ y Objective

C

Ser gratuito y de libre distribución

No Sí Sí

Tabla 3.14. Comparación entre IDE’s para la Aplicación Móvil

Finalmente, y de acuerdo con la tabla comparativa, decidimos que el entorno más adecuado es XCode® para Mac pues cumple con los requerimientos básicos necesarios para desarrollar la aplicación móvil del sistema.

Habiendo elegido el entorno de desarrollo se acota la investigación sobre el mejor lenguaje de programación para la aplicación móvil. Es importante mantener la compatibilidad con el sistema operativo iPhone OS y con la sintaxis de las librerías gráficas OPENGL ES.

OPENGL al ser un lenguaje multiplataforma y multilenguaje brinda varias opciones para elegir, sin embargo es XCODE el que nos permite delimitar y puntualizar los requerimientos para el lenguaje que se utilizará en el desarrollo de la aplicación móvil.

Tabla 3.15. Comparación entre Lenguajes de Programación utilizados en aplicaciones para iPhone® o iPod Touch®.

REQUERIMIENTOS C JAVA[17] Objective C Paradigma Procedural Orientado a Objetos Orientado a Objetos

Soporte de librerías gráficas de OPENGL

Sí, totalmente No por completo,

existen bindings que son limitados

Sí, totalmente

Implementación para iPhone

No No Sí

Documentación para MAC

Poco documentado Poco documentado Bien documentado

46 | P á g i n a

El lenguaje a utilizar, basados en la tabla 3.15 será Objective-C pues a pesar de no ser

tan difundido es el más utilizado en programación no sólo para iPhone® pues se usa extendidamente en la mayoría de las aplicaciones diseñadas para la plataforma de MAC. 3.4.3 – Sistema Gestor de Base de Datos (SGBD)

Existen en la actualidad una gran cantidad de SGBD de código libre, muchos de ellos del mismo nivel cualitativo que algunos de los SGBD comerciales más conocidos. Los Sistemas Gestores de Bases de Datos son un tipo de software muy específico, dedicado a servir de interfaz entre las bases de datos y las aplicaciones que la utilizan, consiguiendo entre otras cosas, que el acceso a los datos se realice de una forma más eficiente, más fácil de implementar y sobre todo, más segura. Entre los SGBD más utilizados y de código libre se encuentran:

PostgreSQL MySQL

La investigación que se realizó[19] incluye además el paquete Java DB. A continuación se muestran diversos cuadros comparativos los SGBD mencionados anteriormente. Se evalúan en cuanto a:

Características de Programabilidad Compatibilidad, Integración e Interoperabilidad Características Administrativas

Requerimientos PostgreSQL[20] MySQL[21] Java DB[22][18] Soporte tipo de datos Soporte Completo (SC) SC SC

Vistas SC SC SC

Disparadores SC SC NS

Procedimientos almacenados SC SC No Soportado (NS)

Definición de funciones SC SC NS

Cursores SC SC NS

Select, update, delete, join, insert, union, select anidados

SC SC SC

XML SC SC SC

Funciones estándares Sql SC SC SC

Indexación SC SC SC Tabla3.16. Características de Programabilidad

47 | P á g i n a

Requerimientos PostgreSQL MySQL Java DB Soporte ODBC SC SC SC

Soporte JDBC SC SC SC

Soporte OLE DB SC SC No Soportado (NS)

SQL 92 SC SC SC Tabla 3.17. Compatibilidad con estándares

Requerimientos PostgreSQL MySQL Java DB Soporte Importación/Exportación de información

SC SC SC

Soporte replicación de datos

SC SC SC

Soporte multiplataforma SC SC SC

Soporte por parte de la organización creadora del software

SC SC SC

Tabla 3.18. Integración e Interoperabilidad

Requerimientos PostgreSQL MySQL JavaDB Herramientas para analizar consultas

SC SC NS

Seguridad de Datos SC SC SC

ACID SC SC SC

Multi-threading NS SC SC Tabla 3.19. Características administrativas

Como se puede observar los tres SGBD poseen casi las mismas características por lo que nos hemos inclinado por Java DB debido a que es suficiente para ejecutar las acciones que se pretender hacer con la base de datos, es perfectamente compatible con la aplicación de escritorio, facilita la distribución de la aplicación, ya que sólo se necesita proveer a los clientes el archivo javaDb.jar, para que puedan trabajar con la aplicación y la Base de Datos y permite una ejecución rápida y confiable debido a que las llamadas que se hacen son hacía un método local.

Se ha descartado MySQL y PostgreSQL ya que son un SGBD más robustos y porque ofrecen características más especializadas las cuales no son requeridas.

3.5 – Análisis y Diseño de la Red Inalámbrica

Tomando como referencia la teoría mostrada en el Capítulo II, se procede a analizar los requerimientos de la red para poder proponer una solución que satisfaga dichas necesidades.

48 | P á g i n a

3.5.1 – Capacidad de la Red

El primer paso para diseñar cualquier red es determinar el objetivo final de ella, es decir, las necesidades de los usurarios. Para determinar los requerimientos de la red se debe tomar en cuenta la capacidad que requiere cada usuario para ejecutar la aplicación, y que es la siguiente:

Los usuarios intercambiarán información con el servidor de tipo audio, imágenes y videos.

Los videos serán de una resolución aproximada de 480 x 320 píxeles y de duración no mayor a tres minutos, se plantea usar el formato de compresión MPEG4 soportado por el iPhone® y iPod Touch®.

Las imágenes serán de un tamaño pequeño respetando el tamaño de la pantalla del dispositivo móvil

El audio no durará más de tres minutos y el formato utilizado será MPEG3. Para poder estimar la capacidad podemos utilizar la siguiente fórmula:

𝐶𝑢 = 𝐴𝐵

𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑠 (1)

Donde: Cu = capacidad de salida para cada usuario AB = ancho de banda de la red, para las Wi-Fi basadas en el estándar 802.11g Usuarios = cantidad de usuarios que soportará un punto de acceso

Para efectos de prueba, cada AP brindará servicio a 5 usuarios máximo al mismo tiempo, y empleando la ecuación (1), obtenemos:

𝐶𝑢 = 𝐴𝐵

𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑠=

22 𝑀𝑏𝑝𝑠

5= 4.4 𝑀𝑏𝑝𝑠

En teoría cada uno de los usuarios podría disponer de 4.4 Mbps para operar dentro de la red al mismo tiempo, pero es importante mencionar que este valor varia en la medida en que se conecten o desconecten los usuarios a la red, por lo que disminuye o aumenta en igual proporción. 3.5.2 – Designación del Área

El área que se va a cubrir con la red inalámbrica se muestra en la figura 3.20. Que corresponde a aulas de trabajo de la UPIITA. En particular elegimos tres salones que se muestran con sus respectivas dimensiones.

49 | P á g i n a

Figura 3.20. Área donde se instalará la red inalámbrica

Las redes inalámbricas Wi-Fi pueden operar bajo dos topologías de red: topología

Ad-Hoc y topología de infraestructura. La topología que se implementará será de infraestructura, esto es debido a que está arquitectura define dos elementos de conexión, los puntos de acceso y las estaciones cliente, que en nuestro caso serán teléfonos iPhone® o dispositivos iPod Touch®.

Los Puntos de Acceso instalados en la red inalámbrica nos permiten:

Tener mayor cobertura en el recinto Controlar el tráfico que fluye entre los usuarios Soportar mayor cantidad de usuarios Poder transmitir con mayor potencia Implementar una red inalámbrica más segura Filtrado de direcciones MAC

3.5.3 – Evaluación física del sitio

Los efectos que distintos materiales de construcción tienen en la energía de radio varía de acuerdo al tipo del material que se utilice, en general, mientras más denso sea el material de construcción evita que la energía de RF pase a través de él. Los salones de clase están separados por paredes de concreto con un espesor no mayor a 18 centímetros. Estos materiales tienen menos aire dentro de ellos por lo que tienden a ser más densos e impiden el paso de las señales. Es importante señalar que estos materiales no reflejan en gran medida las señales.

Las grandes empresas han realizado mediciones con la finalidad de conocer las

pérdidas a través de distinto materiales, del documento “Wireless LAN User’s Guide version

50 | P á g i n a

4.2” de Ericsson[10] se conoció que el valor de atenuación asignado para paredes gruesas es de 18.3 dB. Además de este tipo de interferencias la red es susceptible de interferir con otros equipos que trabajen en la misma banda de frecuencia. Afortunadamente para el desarrollo de las pruebas no existen este tipo de dispositivos.

3.5.4 – Selección del estándar y hardware para el Punto de Acceso

El estándar que se utilizará para la implementación de la red es el 802.11g el cual tiene las siguientes características:

Compatibilidad con el estándar 802.11b y productos anteriores Células mixtas y la operación en la banda de 2.4 GHz Proporciona 3 canales de transmisión, esto es trabajar en diferentes frecuencias

para evitar interferencias tales como: Co-canales: diferentes puntos de acceso transmiten simultáneamente sobre el ہ

mismo canal y su cobertura se traslapa lo que hace deficiente el diseño de la red y el funcionamiento de la misma.

.Inter-canales: al trasmitir sobre canales adyacentes ہ La operación libre de licencia en prácticamente todo el mundo.

Su principal desventaja contra el estándar 802.11a es que la banda en que trabaja el 802.11g está saturada con redes WLAN, teléfonos inalámbricos, dispositivo bluetooth, etc. Pero el estándar 802.11a no está soportado en el iPhone® por lo que se descarta su uso[29]. Las características de los puntos de acceso (AP) que se utilizarán se muestran en la tabla 3.20.

CARACTERÍSTICAS PUNTO DE ACCESO (2WIRE 2701HG-T)

Dirección MAC 00:21:7c:16:64:a1 Canales en los que puede trabajar

Canal 1: 2412 MHz Canal 6: 2437 MHz Canal 11: 2462 MHz

Seguridad de Red WEP WPA

Modo Inalámbrico 802.11b 802.11g

Velocidad de conexión máxima

11 Mbps en 802.11b 54 Mbps en 802.11g

Máxima Potencia de Transmisión

400 mW variable

Periodo de DITM 1 segundo Tabla 3.20. Características del Punto de Acceso

51 | P á g i n a

Estos AP poseen una antena dipolo con patrón de radiación omnidireccional lo que permite tener un haz amplio pero de corto alcance. Este tipo de antenas envían la información teóricamente a los 360 grados por lo que es posible establecer comunicación independientemente del punto en el que se esté.

La figura 3.21 muestra el patrón de radiación de un dipolo, esto es importante

considerarlo ya que la posición en la que se coloque el punto de acceso nos permitirá proporcionar una mejor cobertura en el área propuesta.

Figura 3.21. Patrón de radiación de una antena dipolo

De acuerdo con la figura 3.21, los puntos de acceso se colocarán de forma horizontal

en el techo con el propósito de que en los puntos donde no existe patrón de radiación que es en 270° y 90° como se aprecia en la figura queden al nivel del techo, por lo que en realidad se estaría aprovechando el lóbulo inferior del patrón de radiación de la antena. Además de esta forma las personas no serán una fuente de interferencia

El trabajar con el estándar 802.11g permitirá instalar un punto de acceso en cada

salón de ser necesario y cada uno estará trabajando en un canal diferente para evitar interferencias. La figura 3.22 muestra el esquema donde los canales que se usarán no presentan dominios de colisión, de esta manera se consiguen velocidades de datos más altas y un enlace más sólido.

Figura 3.22. Canales de radio del estándar 802.11

52 | P á g i n a

Otra característica importante de los AP es la forma de seguridad en la que se puede configurar. El que se utilizará será WEB ya es menos robusto que WAP, lo que permitirá un mejor rendimiento en la red, que es lo que se busca para satisfacer las necesidades de los usuarios.

Dentro de la configuración del modem se debe deshabilitar la función de DHCP para la asignación de direcciones IP, estas deben de ser fijas, evitando que usuarios ajenos puedan descifrar una dirección valida y acceder a la red. 3.5.5 – Arquitectura de Red y Disposición de los Puntos de Acceso

A continuación la figura 3.24 muestra el área a cubrir con las ubicaciones de los puntos de acceso y líneas de corriente y cables de Ethernet que se utilizarán desde el servidor hacia los Puntos de Acceso.

SIMBOLOGÍA

Punto de Acceso 1 Punto de Acceso 2 Punto de Acceso 3

Servidor Cable Ethernet Cable de corriente

Figura 3.23. Disposición de los Puntos de Acceso

53 | P á g i n a

Los puntos de acceso se conectaran entre sí por medio de un switch lo que permitirá un punto central de conexión para un grupo de nodos en este caso los tres puntos de acceso y así conectarlos al servidor. En la siguiente figura se muestra el diagrama de cómo quedará conectada la Red.

Figura 3.24. Conexión de los Puntos de Acceso

El switch que se utilizará será un 3COM modelo 3C16790 con las siguientes características:

CARACTERÍSTICA 3COM 3C16790

Puertos Cinco Velocidad de Puertos 100 Mbps Conectores del puertos RJ-45

Tabla 3.21. Características del Switch

Este dispositivo se ajusta a nuestras necesidades ya que sólo requerimos tres puertos para conectar los tres puntos de acceso y las velocidades soportadas por el switch son mayores a las que trabaja el estándar 802.11g, por lo que permitirá un correcto funcionamiento. 3.5.6 – Propuesta del modelo de propagación

Para poder estimar la potencia recibida en los equipos de los usuarios y estimar el área de cobertura de cada punto de acceso se recurrió al modelo de propagación para interiores ETSI TR–101–102 probado para la transmisión de datos en medios inalámbricos.

54 | P á g i n a

Para esto, empleamos la siguiente ecuación:

𝐿 𝑅 = 37 + 30 𝑙𝑜𝑔 𝑅 + 18.3 𝑛 𝑛+1

𝑛+2−.0.46

Donde: 37 = constante de perdida R = distancia entre el transmisor y el receptor 18.3 = materiales de las paredes (concreto) n = # de paredes 0.46 = constante empírica

Sustituyendo el valor de n = O para ver la potencia requerida sin considerar la potencia que llegaría al otro salón y R = 1,2, m para ver la potencia cubriendo todo el salón de clases.

NÚMERO DE PAREDES /DISTANCIA 1M 2M 3M

n=0 37 dB 46.03 dB 51.31 dB

Por último sustituimos el valor de n=1 para ver la potencia que llegaría al otro salón de clases considerando el muro que los divide. Cabe recordar que las señales que se usan en cada salón no se interferirían ya que cada punto de acceso estará trabajando en un diferente canal.

NÚMERO DE PAREDES /DISTANCIA 4M 5M 6M

n=1 73.36 dB 76.26 dB 78.64 dB

La mayoría de las veces los resultados obtenidos con los modelos de propagación

varían en comparación con los resultados obtenidos mediante mediciones, esto debido a que los modelos de propagación no toman en consideración todos los fenómenos que pueden afectar la propagación de la señal.

55 | P á g i n a


4.1 – Aplicación Administrativa

La Aplicación Administrativa será la encargada de gestionar el contenido multimedia referente a las obras presentadas en el recinto. A continuación se explicarán las partes que conforman esta aplicación y cómo interactúan entre ellas para que el servidor funcione correctamente.

4.1.1 – Creación de la Base de Datos

La creación de la base de datos es fundamental para el funcionamiento del sistema, ya que es en esta donde se encuentra contenida toda la información que permitirá atender las peticiones de los usuarios realizadas a través de la aplicación móvil.

La base de datos se administrará con la ayuda de la paquetería JavaDB como se menciono en Capítulo 3. Este paquete utiliza sintaxis SQL. El código utilizado para la creación de las tablas se adjunta en el archivo llamado tablas.txt en el disco compacto.

A continuación se explica el tipo de información que se almacena en cada tabla de la base de datos.

Tabla Usuarios: Se almacena información de las personas que podrán acceder al sistema a través de un nombre y contraseña del usuario.

Tabla Sala: En esta relación se guarda el nombre y descripción de cada una de las salas del museo o recinto.

Tabla Objeto: Aquí se almacena la información de las obras en exposición como es: nombre, autor y descripción. Cada obra está asociada a una sala de exposición

Tabla Contenido: en esta tabla se mantiene la información de los contenidos multimedia asociados a una obra en exposición, no importando si son audio, video o imágenes. La información que se requiere es: nombre del contenido, ruta donde se encuentra la información en el servidor y tamaño del archivo en bytes.

Tabla Imagen: Aquí se almacena información específica de las imágenes como es: alto y ancho especificado en pixeles y también se guarda una pequeña descripción de la imagen para que los usuarios puedan conocer información referente a la misma.

Tabla Audio: En esta tabla se guarda información referente a los archivos de audio. La información requerida es duración del archivo en segundos y calidad del audio que se define como buena, regular o mala. En el campo de reproducir se almacena la ruta del archivo MPEG3 para que pueda ser reproducido por la aplicación administrativa.

Tabla Video: al igual que la tabla anterior se almacena la duración del archivo en segundos, la resolución la cual puede ser calificada como buena, regular o mala y la ruta del archivo de video MPEG4.

56 | P á g i n a

4.1.2 – Poblar Base de Datos

Para que el sistema funcione correctamente debe existir una estrecha relación entre las salas y obras dadas de alta en la base de datos y las dibujadas en la aplicación móvil, es por esto que está información ya debe estar cargada en la base de datos. Para las pruebas que se realizaron se cargaron tres salas y quince obras en cada una de ellas.

En la Tabla 4.1 se muestran las salas y obras cargadas en la Base de Datos.

Sala Obras en Exposición

México – Prehispánico

Chichén Itzá Chac Mool Chinampa Calendario Azteca Coatlicue Códice Maya Códice Mendoza

Guerrero Águila Máscara maya Pectoral Tenochtitlán Vasija Serpiente

Egipto Antiguo

Akenaton Templo de Luxor Joyería Egipcia Osiris Rosetta Pirámides Busto de Nefertiti

Tutankamon Pintura Egipcia Vasija Esculturas Konsu Karnak

El Renacimiento

Baptisterio Bernini Carabelas Colón Da Vinci David David Bernini Galileo

La escuela de Atenas La Piedad Maddona de Milán Maddona de Rafaello Mapa Migue Angel Monalisa

Tabla 4.1. Datos cargados en la Base de Datos

El ingreso de los datos se hizo directamente con sintaxis SQL como se muestra en el fragmento de código de la figura 4.1.

INSERT INTO Sala VALUES(Identificador, 'Nombre', 'Descripción');

.

.

.

INSERT INTO Objeto VALUES(identificador Obra, Identificador Sala, 'Nombre',

'Autor(es)','Descripción');

.

.

.

Figura 4.1. Sentencias SQL para el ingreso de los registros en la tablas Sala y Obra

57 | P á g i n a

4.1.3 – Configuración del Servidor Las características de la computadora que se utilizó como servidor son las siguientes:

Característica Modelo IBM ThinkPad X41

Procesador Centrino (1.40GHz, 90nm technology, 2MB L2 Cache, 400MHz FSB)

Tarjeta de Red Intel PRO 2200BG

Capacidad en Disco Duro 40 GB

Memoria RAM 1 GB

Pantalla 12.1" TFT XGA (1024 x 768)

Sistema Operativo Linux, Ubuntu 9.10

Tabla 4.2. Características del Servidor Para que la computadora funja como servidor se le instaló Apache 2.0, de esta manera se pueden proveer servicios HTTP a los usuarios de la aplicación móvil y así permitir que los dispositivos realicen las peticiones al servidor.

La información dentro del servidor está organizada por carpetas, las cuales se explican a continuación:

Imágenes: Almacena todas las imágenes cargadas desde la aplicación

administrativa. Streaming: Posee los archivos .ts y archivos .m3u8 con los que se implementará el

protocolo HTTP Live Streaming para la descarga de videos. Archivos XML: Contiene los archivos encargados de mantener la comunicación

entre la aplicación administrativa y la aplicación móvil.

La figura 4.2 muestra las carpetas creadas en el Servidor para organizar los contenidos multimedia y los archivos XML.

Figura 4.2. Organización de la Información dentro del Servidor

4.1.4 – Protocolo HTTP Live Streaming para archivos de video

Para la implementación del protocolo se hace uso de las librearías de FFmpeg[25],

estas son una colección de software libre que pueden grabar, convertir y hace streaming de

vídeo. FFmpeg está desarrollado en Linux, pero puede ser compilado en la mayoría de los

sistemas operativos, incluyendo Windows.

A continuación se describen los pasos necesarios para hacer uso de las librerías

FFmpeg e implementar el protocolo.

http://www.notebookreview.com/price/default.asp?productID=12460&productFamilyID=590&brandID=9&display=priceDetail

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/Streaming

http://es.wikipedia.org/wiki/V%C3%ADdeo

http://es.wikipedia.org/wiki/GNU/Linux

http://es.wikipedia.org/wiki/Windows

58 | P á g i n a

1. Instalar las librerías X264 [26].

2. Instalar FFmpeg.

3. Configurar FFmpeg: en esta parte se le indica a las librearías cuales son los codecs

que utilizará para gestionar el audio y video. La configuración utilizada es la

siguiente:

configure --enable-gpl --enable-nonfree --enable-pthreads --enable-libfaac --enable-

libx264 --enable-shared

Figura 4.3. Configuración de las librerías FFmpeg

4. Codificar el Video para el iPhone®: se codifica el archivo de video a un formato que el

iPhone® pueda leer, además se indica la tasa de bit que se utilizará para la

transmisión del contenido multimedia. La codificación de los archivos de video se

realizó con la siguiente instrucción:

ffmpeg -i <in file> -f mpegts -acodec libmp3lame -ar 48000 -ab 64k -s 320×240 -

vcodec libx264 -b 96k -flags +loop -cmp +chroma -partitions

+parti4×4+partp8×8+partb8×8 -subq 5 -trellis 1 -refs 1 -coder 0 -me_range 16 -

keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -maxrate 96k -bufsize 96k -

rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect

320:240 -g 30 -async 2 <output file>

Figura 4.4. Codificación de videos utilizando las librerías FFmpeg

5. Compilar y crear el archivo binario que permitirá segmentar el video: Se hizo uso

de un código segmentador de archivos escrito en lenguaje C, es utilizado para

dividir los videos en archivos con duración no mayor a 10 segundos y con

extensión .ts, además este código crea el archivo de índices con extensión .m3u8, el

cual indica la secuencia de lectura para la reproducción del video. Las instrucciones

utilizadas para implementar lo descrito anteriormente son:

gcc -Wall -g segmenter.c -o segmenter -L/home/jasson/ffmpeg/libavformat -lavformat -

L/home/jasson/ffmpeg/libavcodec -lavcodec -L/home/jasson/ffmpeg/libavutil -lavutil -

I/home/jasson/ffmpeg/ -lm -lmp3lame -lxvidcore -lx264 -lfaad -lfaac -lbz2 -lpthread

–lz

Figura 4.5. Código para generar el archivo binario del segmentador de archivos

segmenter sample_low.ts 10 sample_low stream_low.m3u8

http://192.45.65.32/Streaming

Figura 4.6. Código utilizado para ejecutar el segmentador de archivo

http://192.45.65.32/Streaming

59 | P á g i n a

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXTINF:10,

http://www.ioncannon.net/prueba-1.ts

#EXTINF:10,

http://www.ioncannon.net/prueba-2.ts

Figura 4 .7. Formato del archivo de índices

En la figura 4.7 se puede observar que los segmentos de los archivos tienen una

duración de 10 segundos, y además se especifica la ruta de donde el iPhone® o iPod

Touch® descargarán el contenido Multimedia. La figura 4.8 muestra los archivos

creados por el programa segmentador.

Figura 4.8. Archivos creados por la aplicación Administrativa para la implementación

del protocolo HTTP live streaming

6. Preparar el Servidor: como se mencionó en el punto 4.1.3 de este capítulo se hace

uso del servidor Apache para que los dispositivos a través de la aplicación móvil

puedan acceder al contenido multimedia. Para permitir la descarga de archivos con

extensión .m3u8 y .ts se modificó el archivo de configuración del servidor Apache,

incluyendo las siguientes líneas de código.

AddType application/x-mpegURL .m3u8

AddType video/MP2T .ts

Figura 4.9. Código para permitir la descarga de los archivos segmentados en el Servidor

Una vez realizados los pasos anteriores el servidor está listo para proveer el servicio de live streaming en los archivos de video. Es importante saber que el paso cuarto y el quinto se repiten cada que se carga un nuevo video o cuando se actualiza un archivo ya dado de alta.

60 | P á g i n a

4.1.5 – Protocolo HTTP Live Streaming para archivos de audio Para ofrecerles a los usuarios del sistema una descarga más rápida de los archivos de audio se siguieron los siguientes pasos para configurar el servidor y hacer la implementación del protocolo.

1. Compilar e instalar las herramientas MPEG4IP, la cual permite codificar y reproducir archivos con formato MPEG4[27].

2. Instalar el Servidor Darwin Streaming[28]: este servidor de código abierto permite transmitir archivos multimedia a través del protocolo HTTP. Es distribuido por Apple y se puede instalar en el sistema operativo Windows, Linux, Solaris y Mac.

Figura 4.10. Servidor Darwin Streaming

3. Conversión del archivo de audio: el archivo se convierte a un formato PCM con

extensión .aac, la figura 4.11 muestra el código utilizado para la conversión.

ffmpeg –i audioOriginal.mp3 –vn audio.aac

Figura 4.11. Código que permite la conversión de formato mp3 a formato .aac

4. Codificar el archivo de audio: para esta tarea se utiliza el siguiente línea de código

faac -w –B64 –c48000 –P audio.aac audio.aaa

Figura 4.12. Código utilizado para la codificación del archivo

Las etiquetas de la figura 4.12 representan lo siguiente:

-w: especifica la versión de MPEG utilizada en este caso MPEG-4. -B: especifica la tasa de bit con la que se codificará el archivo. -c.: especifica el número de muestras que se toman del archivo de audio. -P: especifica el perfil que se utilizará, el cual incluye todas las herramientas

para la correcta codificación del archivo.

61 | P á g i n a

5. Creación y optimización del archivo MPEG 4: para esta tarea se utilizan las librerías instaladas en el paso número uno, ejecutando los siguientes comandos:

Mp4creator –c audio.aac audio.mp4

Mp4creator –optimize audio.mp4

Figura 4.13. Código que permite crear el archivo con extensión MPEG 4

6. Mover el archivo de audio codificado a la carpeta de donde el servidor Darwin toma

los archivos para transmitirlos a través del protocolo de comunicación HTTP.

De los pasos anteriores los que ejecuta la aplicación administrativa cada que se agrega un nuevo archivo o se modifica alguno son desde el paso tres al sexto.

4.1.6 – Creación de los Archivos XML

A continuación se expondrá el medio que permite al servidor publicar los cambios relacionados con los contenidos multimedia, los cuales, serán requeridos por la aplicación móvil para el funcionamiento del sistema.

El intercambio de información entre las dos aplicaciones será a través de archivos XML. La aplicación administrativa debe publicar los cambios que se realicen en la base de datos generando, eliminando o actualizando los archivos de texto.

Se generan dos tipos de archivos que se describirán a continuación. Todos ellos se crean en la carpeta de Archivos XML en el servidor.

Un archivo por obra en exposición: este tipo de archivo se genera cada que se agrega un contenido multimedia a una obra en exposición y el sistema lo elimina en caso de que todos los contenidos que posea la obra, sean eliminados. Para la creación de estos archivos se consultan los contenidos multimedia relacionados a la obra en exposición, en la base de datos, y a través de la paquetería de java Jdom se va escribiendo el archivo. El nombre de este archivo es el identificador que le pertenece a la obra en exposición en la base de datos. De esta manera la aplicación móvil sabrá asociar el archivo XML a la obra correcta, dibujada en la aplicación. Los etiquetas que contiene este archivo son las siguientes:

title: Nombre del contenido Multimedia link: Ubicación del archivo en el servidor type: Nos indica el tipo de contenido; para imágenes toma el valor uno, dos

para audios y tres para videos. description: es una etiqueta propia de las imágenes donde contiene la

descripción de la imagen cargada en el servidor

62 | P á g i n a

La figura 4.14 muestra un ejemplo de este tipo de archivos.

<?xml version="1.0" encoding="ISO-8859-1" >

<channel>

<item>

<title>México Tenochtitlán</title>

<link>http://169.254.109.122/Videos/MexTen.m3u8</link>

<type>3</type>

</item>

<item>

<title>Egipto Faraónico</title>

<link>http://169.254.109.122/Imagenes/Egip.jpg</link>

<descriptio>Está imagen es ….. </description>

<type>1</type>

</item>

.

.

.

</channel>

</rss>

Figura 4.14. Archivo XML que muestra la información de los contenidos multimedia asociados a una obra

Archivo general de Imágenes, Videos y Audios: debido a que la aplicación móvil tiene

un apartado donde se muestran todas las imágenes, todos los videos y todos los

archivos de audio cargados en el servidor. En la figura 4.15 se muestra el formato del

archivo XML.

<?xml version="1.0" encoding="ISO-8859-1" >

<channel>

<item>

<title>México Tenochtitlán</title>

<link>http://169.254.109.122/Videos/MexTen.m3u8</link>

<type>1</type>

</item>

.

.

.

</channel>

</rss>

Figura 4.15. Archivo general de videos

Para la creación de estos archivos se consulta la información referente a un tipo de

contenido multimedia ya sea imágenes, video o audio en la base de datos y haciendo

uso nuevamente de la paquetería de java Jdom se va escribiendo el archivo. El

nombre de este archivo será entonces: Imágenes, Videos o Audios, de esta manera la

aplicación móvil sabrá cuál es el archivo que tiene que mostrar dependiendo lo que

el usuario solicite. Este archivo de forma análoga que el anterior se actualiza cada

http://169.254.109.122/Videos/MexTen.m3u8%3c/link

http://169.254.109.122/Imagenes/Egip.jpg%3c/link

http://169.254.109.122/Videos/MexTen.m3u8%3c/link

63 | P á g i n a

que se asocia un nuevo contenido a la obra, modifica o cuando se elimina algún

contenido.

Las etiquetas del archivo se describen a continuación

name: nombre del contenido multimedia

link: ubicación del archivo en el servidor

type: contiene el identificador de la sala a la cual pertenece la obra en

exposición

description: etiqueta exclusiva de las imágenes donde contiene la descripción

de la imagen cargada en el servidor

Estos archivos constituyen una parte muy importante para que la aplicación

administrativa mantenga informada, de los cambios hechos en la base de datos, a la

aplicación móvil. Esta última, antes de descargar un contenido multimedia deberá de leer

un archivo XML, para poder identificar la ruta a la cual tiene que acceder para descargar el

contenido deseado.

4.1.7 – Funcionamiento de la Aplicación Administrativa En la figura 4.16 se muestra la pantalla de inicio, donde los usuarios se identificarán para poder acceder al sistema. Al ingresar el nombre y contraseña se verifica que los dos campos estén llenos y además que la información ingresada corresponda con alguno de los usuarios dados de alta en el sistema. Esto con el fin de restringir que cualquier usuario en el servidor gestione el contenido multimedia que se les presenta a los visitantes del recinto.

Figura 4.16. Autenticación de Usuarios

En el caso en el que no exista ningún usuario registrado, la aplicación abrirá el

catálogo que permite darlo de alta. Una vez realizada esta tarea el usuario deberá abrir de nuevo la aplicación administrativa para que de esta manera ingrese nombre y contraseña de usuario. El proceso descrito anteriormente se describe en el diagrama de la figura 4.17.

64 | P á g i n a

Figura 4.17. Procesos de registro de usuario(s) por primera vez

Ya que el sistema corroboró los datos y estos son correctos presenta la pantalla de la figura 4.18 que muestra el menú principal.

Figura 4.18. Menú Principal de la Aplicación Administrativa

En está pantalla se encuentran tres botones los cuales representan cada una de las salas que están dadas de alta en el sistema. Cada vez que el mouse se posiciona sobre un botón se muestra la información correspondiente a esa sala, en los campos nombre de la sala y descripción, y al dar click sobre el botón nos llevará a la ventana de la figura 4.19.

En la parte superior de la figura 4.18 existe una barra de menús donde podemos

ingresar al catálogo de Usuarios y hacer gestión de los mismos. Es importante mencionar que el menú principal es el que mantiene a la aplicación administrativa en ejecución.

65 | P á g i n a

Figura 4.19. Consulta de contenidos multimedia asociados a una obra

Dependiendo de qué botón se haya presionado en la ventana del menú principal, son las obras que se cargarán en la pantalla de la figura 4.19. Aquí se pueden realizar las siguientes acciones:

Consultar la información referente a la obra: nombre, autor(es) y descripción Consultar los contenidos multimedia asociados a una obra en exposición

determinada. Imágenes: tamaño en bytes, alto y ancho en pixeles Video: tamaño en bytes, duración del archivo en minutos, y resolución

del video Audio: tamaño en bytes, duración del archivo en minutos y calidad del

audio

Observar las imágenes asociadas a la obra y la descripción de la misma Reproducir los archivos de audio y video asociados Acceder a la ventana que permite asociar nuevo contenido, a través del botón

asociar contenido Acceder a la ventana que permite actualizar la información de un archivo de audio,

video o imagen Eliminar el contenido multimedia seleccionado

66 | P á g i n a

Figura 4.20. Asociar nuevo contenido multimedia a una obra en exposición

La pantalla de la figura 4.20 permite asociar nuevo contenido. El dato que debe ingresar el usuario es el nombre del contenido, el cual debe ser mayor a cuatro caracteres, y seleccionar el archivo que desea dar de alta.

Al seleccionar el archivo que se cargará en el servidor se realizan las siguientes funciones dependiendo del tipo de contenido.

Imágenes 1. Valida que el nombre de la imagen que se quiere guardar no sea igual a otra

imagen que ya haya sido carga. Esto debido a la forma de organizar la información en el servidor, como se explicó en el punto 4.3 de este capítulo. El sistema informa por medio de un cuadro de diálogo cuando el nombre que se quiere asignar al contenido es igual a uno ya dado de alta en la base de datos.

2. Verifica que la imagen sea de formato jpg, png o gif. Si no se cumple con el formato requerido se mostrara un mensaje de error y se pedirá seleccionar otro contenido.

3. Lee el archivo para obtener su tamaño en bytes, su ancho y alto en pixeles. En el caso de que el sistema no pueda abrir el archivo se pide que se seleccione uno diferente.

4. Valida que el tamaño de la imagen no sobrepase el tamaño de la pantalla del iPhone® que es de 320 x 480 pixeles. Al igual que en los puntos anteriores se muestra un mensaje de error en cado de no cumplir con la condición del tamaño de imagen.

Si el contenido cumple los requerimientos del sistema, éste cargará los datos automáticamente en la pantalla. Y permitirá guardar el archivo seleccionado.

Audio 1. Valida el nombre del archivo de audio de manera análoga que con el

nombre de las imágenes. 2. Se valida que los archivos sean de formato MPEG3. 3. Se abre el archivo para comprobar que el sistema lo puede leer. Si no se

puede abrir pide que se seleccione uno nuevo.

67 | P á g i n a

4. Una vez abierto se lee la duración en minutos y tamaño del audio en bytes y se verifica que la duración sea menor a tres minutos. Esto con la finalidad de que la transmisión de los contenidos no congestionen la red inalámbrica.

De igual manera si se cumplen con los requerimientos se cargarán automáticamente los datos en la pantalla y permitirá guardar el contenido seleccionado.

Videos 1. Valida que el nombre del video que se quiere guardar no sea igual a otro

video ya almacenado anteriormente. 2. Se validan que los archivos sean de formato MPEG 4 3. Se hace la conversión de MPEG4 a MPEG con la finalidad de que el sistema

lo pueda leer. 4. Se hace la lectura del archivo MPEG y se validan sus características de

forma análoga que los archivos de audio.

Si el video cumple con las condiciones, se procede a eliminar el archivo MPEG y se cargan automáticamente los datos en la pantalla permitiendo guardar el contenido seleccionado.

Al presionar el botón de guardar, el sistema realizará las siguientes tareas dependiendo del tipo de contenido:

Imágenes Hace una copia del archivo seleccionado a la carpeta de Imágenes donde la

aplicación móvil accederá para descargar los contenidos.

Audio El archivo se cambia a un formato .aac. Se codifica el archivo .aac como se explica en el punto 4.1.5 de este capítulo Se crea el archivo MPEG4, y se optimiza la codificación para que la descarga

del mismo sea más rápida a través del servidor de streaming.

Video Se codifica el video para que pueda ser reproducido en el iPhone® o iPod

Touch® Se procede a segmentar los archivos para poder implementar el protocolo

HTTP Live Streaming, como se explica en el punto 4.1.4 de este capítulo.

68 | P á g i n a

Figura 4.21. Actualización de Contenido Multimedia

La figura 4.21 muestra la pantalla que se abre cuando se presiona alguno de los botones de modificar en la ventana de consulta de obras en exposición, ya sea el de audio, imagen o video. El sistema realiza las siguientes tareas.

Carga las características del contenido multimedia Deshabilita el campo donde se ingresan el nombre del contenido. Esto se hace

debido a la disposición de los archivos dentro de las carpetas del servidor

Una vez realizadas estas tareas el usuario podrá cargar un nuevo archivo si así lo desea o modificar la calidad de los archivos de audio o la resolución en los videos si es el caso. Al guardar los cambios se realizarán las mismas tareas antes mencionadas si es que se seleccionó un archivo diferente al que ya estaba cargado anteriormente.

Para eliminar los contenidos multimedia basta con presionar el botón de eliminar en cualquiera de los paneles de la ventana 4.19. El sistema sólo pedirá una confirmación, al ser esta verdadera los archivos cargados en las carpetas de donde la aplicación móvil realiza las descargas se eliminarán así como el registro en la base de datos.

Por último la ventana de la figura 4.22 permite realizar las siguientes funciones:

Dar de Alta un nuevo usuario Consultar usuarios Eliminar usuarios Modificar información de un usuario

Las validaciones que se realizan en esta ventana consisten en verificar que todos los campos sean llenados y determinar el tipo de caracteres que aceptan los distintos campos que posee la pantalla.

69 | P á g i n a

Figura 4.22. Administración de usuarios

4.2 – Aplicación Móvil

4.2.1 – Temática de las salas y el contenido referente

Para iniciar con el proceso de virtualización del recinto debieron identificarse en primer lugar los archivos para la descarga de contenido multimedia referente y las imágenes que formarán parte de la representación virtual de cada una de las salas. De acuerdo con los requerimientos definidos en los capítulos anteriores los contenidos multimedia a utilizar en la Aplicación Móvil son caracterizados a continuación.

Basándonos en el modelo de distribución de las salas de un museo contemporáneo, y en particular tomando como caso de estudio El Museo Británico en Londres, se escogieron los siguientes temas para las tres salas que nuestro museo virtual tendrá.

Sala 1 – Exposición Egipcia. Se mostrarán algunos de los elementos más icónicos del antiguo Egipto, se parte desde la conformación de la sociedad, tomando en cuenta la evolución de las artes y los oficios, así también se harán claras referencias a los más conocidos faraones y sus legados.

Imágenes

• Las imágenes debieron ser tratadas debido a la restricción de formatosque acepta y reproduce el iPhone. En el caso de las imágenes éstas seconsiguieron o editaron para tener el formato JPG. A manera deestandarización las imágenes que se usaron en ambas aplicacionestendrán este formato; habiendo algunas excepciones, utilizando imágenesPNG (Portable Network Graphics).

Videos y Audio

• No se utilizaron como parte integral de la aplicación éstos se utlizan comocontenido multimedia y se descargarán del servidor.

70 | P á g i n a

Sala 2 – México-Tenochtitlán. En esta sala virtual podremos observar, de acuerdo al

modelo del Museo Nacional de Antropología, en México, un recorrido por dos de las más grandes culturas de la antigüedad que poblaron nuestro país. De igual manera se abordarán los temas de la composición social, sus artes y sus templos.

Sala 3 – Renacimiento. Fuente de conocidos pintores y escultores, se escogió este periodo de la historia por la explosión que se manifestó en desarrollo de las artes. La exposición se enfocará en mostrar los personajes más ilustres de este periodo, sus hazañas y trabajos.

Los archivos, y en particular las imágenes que forman parte de la virtualización se anexaron al proyecto en XCODE para la aplicación móvil. Estas imágenes son estáticas y no cambian después de la finalización de esta aplicación. Por el contrario, los archivos que se administren a través de la aplicación de escritorio podrán ligarse y desligarse a las obras en cada sala.

4.2.2 – Virtualización del recinto Como paso inicial tenemos que definir el espacio virtual que nos permitirá homologar el espacio físico que una sala ocupa. Para esto se transfirió la relación de las dimensiones de un salón de la escuela a las dimensiones del área de dibujo en OPENGL. De manera gráfica la sala virtual es un cubo de 7m de ancho y largo y de 3m de altura. De acuerdo con esto se tomaron 7 unidades de lado para las caras superior e inferior de cubo a dibujar y 3 de altura.

4.2.2.1 – Uso de texturas para piso y paredes Colocar texturas para el piso y paredes en la representación virtual no es un proceso diferente al que se sigue en el mundo real. Llenar el plano correspondiente al piso implica dibujar un cuadro en el que se cargue la textura de una loseta y volverlo a dibujar cuantas veces se necesite hasta llenar el área deseada.

71 | P á g i n a

ACCIÓN REPRESENTACIÓN VIRTUAL

CÓDIGO EN OPENGL

1

Dibujar un polígono dónde cargar la textura.

2

Cargar textura de la loseta en el cuadro.

3

Dibujar múltiples losetas hasta llenar el espacio total del piso.

Tabla 4.3. Procedimiento para dibujar el piso de una sala

Así para el piso se colocarán múltiples losetas siguiendo los pasos que se describieron en la tabla 4.3. Aquí, se hizo hincapié en las instrucciones de OPENGL que se utilizaron y el resultado obtenido.

Se siguió el mismo procedimiento para dibujas las cuatro paredes ahora utilizando una textura diferente. En este caso para la sala de la Exposición Egipcia se escogió una textura con motivos en jeroglíficos, dicha textura se muestra en la figura 4.24.

Figura 4.23. Textura de los muros en la sala Egipcia

Es importante mencionar que las texturas como imágenes deben seguir el formato mencionado en la sección anterior y además deben de tener un tamaño en pixeles limitado por potencias de 2, así las texturas utilizadas en el proyecto tienen por tamaño 512x512 pixeles. El resultado final del dibujo de una sala se muestra en la figura 4.25.

72 | P á g i n a

Figura 4.24. Vista preliminar de la sala Egipcia

De acuerdo al modelo anterior se desarrollaron las demás salas del museo teniendo en cuenta la lógica de programación más conveniente de acuerdo con los recursos del teléfono. Fue necesario elegir las texturas adecuadas de acuerdo con la temática de cada sala. El verdadero reto en programación fue adaptar la lógica que se utilizó para dibujar la primera sala, para dibujar ahora tres. Tomando en conceptos importantes de la POO como la creación y destrucción de objetos y el paso de parámetros. En la programación de aplicaciones para el iPhone es necesario definir vistas diferentes para cada función diferente de los componentes de nuestro sistema. Por lo tanto se debió crear una subclase de UIView (clase genérica de una vista), la subclase para poder dibujar haciendo uso de la librerías de OpenGL es EAGLView. Una vez teniendo una clase de este tipo definida podemos utilizarla para crear los objetos para cada una de nuestras salas.

Figura 4.25. Creación de un objeto de tipo EAGLView en ObjectiveC

Las texturas elegidas por sala se muestran en la tabla 4.4. Los criterios que se utilizaron para elegir la apariencia de cada una corresponden a los archivos seleccionados en la primera entrega.

73 | P á g i n a

SALA TEXTURAS ELEGIDAS VIRTUALIZACIÓN RESULTANTE

PISOS MUROS

1 México Prehispánico

2 Egipto Antiguo

3 El Renacimiento

Tabla 4.4. Texturas y salas virtualizadas

4.2.2.2 – Dibujo de obras en sala

Para el proceso de virtualización de las obras de debió crear una plantilla en la que se incluyen todas las imágenes a dibujar en sala, esto con el fin de reducir la cantidad de llamadas al método para cargar texturas. Debimos de tomar en cuenta la capacidad de procesamiento de directivas de dibujo del dispositivo, pues teniendo una memoria limitada es necesario optimizar el rendering de las salas. Por lo tanto para cargar las obras se debió de seleccionar una región de una textura que incluya todas las imágenes como se muestra a continuación. De manera contraria a como se hizo con el piso y los muros no se cargará una textura nueva para cada operación, para hacer esto se hizo uso extensivo de operaciones con matrices y arreglos.

74 | P á g i n a

Figura 4.26. Plantilla de imágenes a descomponer

El método para dibujar una obra en particular consiste en cargar una sola vez la plantilla y mediante tres matrices de posicionamiento podemos determinar una región de la ésta, posicionar la imagen en la sala y determinar sus dimensiones. El método es el siguiente.

Figura 4.27. Código del método para dibujar una obra

Cada que se dibuje una obra solamente deberá de llamarse este método especificando los índices de las matrices de localización de texturas y obras. El resultado final puede observarse en la figura 4.29.

Figura 4.28. Presentación de las obras en sala

75 | P á g i n a

4.2.3 – Navegación entre salas Tras haber realizado la virtualización individual del espacio de las salas, la elección de texturas y la colocación de las imágenes representativas de cada obra, se incluye una vista que permita intercambiar entre salas. Para esto se utilizó una vista genérica UIView en la que se cargaron tres botones correspondientes al acceso a cada sala. Cada vista de sala tiene un botón que permite regresar al inicio.

Figura 4.29. Vista inicial y vistas de navegación en sala

En la imagen 4.30 se muestra la vista inicial, donde el visitante podrá escoger entrar a cualquiera de las 3 salas que componen el recinto. Para acceder a cada una de las salas bastará con presionar sobre el botón correspondiente. En cada una de las salas el usuario podrá navegar a través del espacio virtual usando los acelerómetros del iPhone® pudiéndose así acercar a una obra para verla con más detalle o simplemente para observar la clave que deberá teclear para acceder al contenido referente a una obra en particular. La vista principal de navegación en sala además incluye dos botones en la parte superior como se muestra en la figura 4.31, del lado izquierdo tenemos el botón para regresar a la ventana inicial mostrada anteriormente, y del lado derecho tenemos un botón que nos llevará a la vista de búsqueda de contenidos.

76 | P á g i n a

INICIO BÚSQUEDA DE CONTENIDOS

Figura 4.30. Elementos de la vista de navegación en sala

4.2.4 – Navegación en sala con controles de iPhone®

4.2.4.1 – Uso de los eventos de los acelerómetros

Como componente de control de una sala se programó el uso del acelerómetro del teléfono para poder navegar por el espacio virtual. Para esto únicamente se debieron invocar los eventos predefinidos para cualquier aplicación del iPhone, adjuntarlos a nuestra aplicación y programar el comportamiento de éstos.

Figura 4.31. Código para configurar e inicializar los acelerómetros

Para nuestros fines debimos de acoplar los valores de las señales regresados por el método de lectura de lo acelerómetros. En este sentido se utilizó un filtro que permitiera determinar el valor de cada uno de los tres acelerómetros que el dispositivo incluye y utilizarlos para transformar la vista a dibujar. La figura 4.33 describe la operación que modela el comportamiento del filtro y cómo se acopló para el uso en la aplicación móvil, así al cambiar los valores obtenidos se ejecutará una acción que cambiará la vista que se muestra.

77 | P á g i n a

Figura 4.32. Uso de un filtro para obtener los valores de los acelerómetros

4.2.4.2 – Uso de los eventos de la pantalla táctil

Adicionalmente, como una característica que hace más robusta la aplicación, se incluyó la navegación alternativa a través de los eventos de de la pantalla táctil. Análogo al proceso de activación de los acelerómetros se hizo uso de los eventos predefinidos que permiten obtener los valores de detección de selección y movimiento que el usuario ejecuta sobre la pantalla del dispositivo. Así, se programó la rutina mostrada en la figura 4.34 donde además se detecta si el usuario eligió utilizar la navegación con acelerómetros, en su defecto se activan los eventos de la pantalla. Dependiendo del toque inicial y de la dirección del movimiento se desplazará el usuario hacia una dirección determinada en la sala virtual. Cabe mencionar que al momento de efectuarse el movimiento el código perteneciente a las obras no se mostrará con el fin de mejorar los resultados del despeño y para un efecto visual más claro.

78 | P á g i n a

Figura 4.33. Programación de los eventos de la pantalla táctil

El usuario entonces deberá de tocar la parte superior de la pantalla para efectuar un movimiento de acercamiento, la parte inferior para alejarse, y los extremos izquierdo y derecho para girar en la dirección correspondiente.

4.2.5 – Consulta de contenidos multimedia 4.2.5.1 – Búsqueda de contenidos por obra

Una vez terminadas las diferentes vistas correspondientes a la virtualización de las salas del recinto, nos centramos en la recuperación del contenido que se asociará a las obras que en ellas se exhiban. Tal como se especificó en la investigación inicial la forma en la que se hará el intercambio de información entre las dos aplicaciones será de la siguiente manera:

Intercambio de texto: a través de archivos XML Recuperación de imágenes: transferencia sobre HTTP Transferencia en vivo de audio y video: usando HTTP Live Streaming

En su rol de cliente únicamente, la aplicación móvil deberá de hacer las peticiones al servidor por medio de la red inalámbrica dedicada para este propósito. Por lo tanto el servidor tendrá una dirección fija y única por medio de la cual se ingresará a los diferentes

79 | P á g i n a

contenidos archivados dentro del mismo como se describe en el apartado de la Aplicación Administrativa. El método de conexión utilizado para cada uno de los casos anteriores es muy similar pues se buscarán los archivos en el servidor variando la dirección de acuerdo al sistema de archivos definido en la primera etapa de este proyecto. Por otro lado el protocolo a utilizar cambiará dependiendo del caso; así, la solicitud del contenido relacionado con una obra implicará la búsqueda del archivo XML correspondiente, su lectura, desglose y el cargar los datos en una vista particular de la aplicación móvil. En el caso de la transferencia de video o audio solamente habrá que especificar la dirección en el objeto creado del framework de QuickTime utilizado para reproducir este tipo de archivos. El proceso de conexión está descrito en el diagrama de flujo mostrado en la figura 4.35.

Figura 4.34. Diagrama de flujo de la recuperación de información

Como me mencionó en el capítulo 3 la búsqueda del contenido por obra se realizará mediante una clava única, misma que permitirá identificar qué archivo XML del servidor deberá de leerse. En este respecto se diseñó una vista UITableView que integra la búsqueda y la visualización de los resultados como puede observarse en la figura 4.36. A esta búsqueda puede accederse a partir de la vista de virtualización del recinto.

Solicitud de búsqueda de contenido

Verificación de la conexión con el servidor

Lectura y descomposición del archivo XML correspondiente

Presentación de los datos al usuario

80 | P á g i n a

Figura 4.35. Vista para la búsqueda de contenidos

Al seleccionarse el campo de la búsqueda se desplegará en pantalla un teclado numérico que permitirá ingresar el código de la obra elegida; luego, para realizar la petición del contenido se deberá presionar el botón que muestra una lupa en la parte superior derecha de la pantalla. Cuando se solicite la búsqueda de un contenido se validó que la aplicación pueda conectarse primeramente a la red del museo, de lo contrario se enviará un mensaje de alarma y no podrá continuarse con la solicitud de petición. También se validó la inexistencia del archivo, en ambos casos se mostrará un diálogo como el que se observa en la figura 4.37.

Figura 4.36. Mensaje de validación de red y obra

81 | P á g i n a

4.2.5.2 – Recuperación y lectura del archivo XML de obra La operación de descomposición del archivo se hace usando una instancia de uno de los lectores XML propios del framework del iPhone® (NSXMLParser). Estas funciones nos permiten leer y descomponer un archivo detectando las marcas o claves que se encuentran en el archivo que genera la aplicación móvil (para más detalle véase la sección 4.3). Los archivos se accederán mediante un identificador compuesto por la clave de la obra y el número de la sala, así la obra con identificador 9 de la sala Egipcia (sala 2) tendrá la clave “29”. Entonces se buscar| el archivo 29.xml en el servidor de acuerdo con la rutas que s especificaron en el apartado 4.3.

4.2.5.3 – Carga y construcción de la vista de contenidos Los datos recopilados mediante el NSXMLParser se almacenan en arreglos mutables que son utilizados para llenar los datos de una celda de la vista de tabla UITableView. Así, el campo nombre del archivo se mostrará dentro de la celda, y a ésta se le ligará la ruta del contenido. La vista de contenidos los mostrará clasificados de acuerdo con tu tipo, mismos que se especifican como clave en el archivo XML de la obra. La vista final para la consulta de contenidos por obra quedó tal como se observa en la figura 4.38.

Figura 4.37. Vista de contenidos encontrados por obra

82 | P á g i n a

4.2.5.4 – Reproducción de contenidos

La solicitud de un contenido en particular se hará seleccionando la celda donde se muestra el nombre del mismo. Al seleccionarse un contenido de tipo audio o video se mostrará una nueva vista donde se hace uso del framework QuickTime y una nueva vista en el caso de las imágenes como se muestra en la figura 4.39.

Figura 4.38. Reproducción de contenido de acuerdo con su tipo

Cabe señalar que para el caso de la vista de imágenes se puede consultar información relacionada con ésta seleccionando el botón “Ver detalle”. La información se mostrar| en la misma ficha en la que se muestra la imagen pero del lado opuesto como se observa en la figura 4.40, para esto se programó el efecto de giro sobre la ficha; la ficha girará hacia la derecha para mostrar la información y de vuelta hacia la izquierda para volver a ver la imagen.

Figura 4.39. Anverso y reverso de la ficha en la vista de imágenes

83 | P á g i n a

4.2.5.5 – Consulta de contenidos por tipo

Además de la consulta de contenidos por obra, se incluyó también una vista de tabla UITableView en la que se mostrarán todos los contenidos del museo clasificados por tipo. Se incluyeron tres botones que permiten elegir el tipo de contenido (véase la figura 4.41) y en la tabla éstos se clasifican por la sala a la que pertenece la obra a la cual hacen referencia.

Figura 4.40. Vista de contenidos multimedia por tipo El procedimiento de recuperación de la información se realiza de manera análoga al procedimiento descrito para la consulta de contenidos por obra. La diferencia principal radica en que ahora se tiene un archivo XML único para videos, audio y video respectivamente. La construcción de este archivo se describe en el apartado 4.3.

4.2.6 – Programación de las vistas y menús de acceso

Una vez finalizada la virtualización de las salas y las vistas de consulta de contenidos por obra y por tipo, se procedió a crear los menús de navegación para acceder a las diferentes funciones que enriquecerán la aplicación. En la vista inicial se utilizó una barra de ítems que se colocó en la parte inferior de la pantalla que nos lleva a las diferentes vistas que componen el programa.

Figura 4.41. Menú de ítems de navegación en la aplicación móvil

84 | P á g i n a

Los botones de SALAS y CONTENIDO mostrarán las vistas ya descritas anteriormente y además se incluyó una vista adicional que mostrará información referente a la aplicación y la forma de usarla. Estas vistas se ven en la figura 4.43.

Figura 4.42. Vistas de la barra de ítems

4.2.7 – Uso y configuración de la aplicación Como ya se mencionó la aplicación móvil será instalada en un iPod Touch® o un iPhone® antes de ingresar al recorrido en el museo o galería. El diagrama de flujo recomendado para el uso de la aplicación móvil muestra en la figura 4.44.

Figura 4.43. Diagrama de flujo para el escenario de uso de la aplicación móvil

Instalación de la aplicación previo al

recorrido

Configuración de la opciones

Iniciar la aplicación

Elegir operación

•Ingresar a una sala

•Consulta de todos los contenidos

•Consulta de información sobre la guía

Navegación en salaBúsqueda de contenidos

por obra

Visualización del contenido

85 | P á g i n a

Previo al inicio del recorrido por la galería o el museo la instalación deberá de descargarse a partir de la tienda virtual de Apple®, iTunesStore® a la que puede accederse por medio de la aplicación iTunes® que puede descargarse de internet y que es primordial para la administración de los contenidos de un iPod® o un iPhone®.

Figura 4.44. AppStore en iTunes ®

Como un valor agregado a la funcionalidad inicial de nuestro sistema, se desarrolló también un menú de opciones de configuración que puede accederse desde la aplicación propia del dispositivo llamada Ajustes.

Figura 4.45. Menú de configuración de GMM en Ajustes

Aquí el usuario podrá elegir si desea navegar por la sala haciendo uso de los acelerómetros de su dispositivo o mediante la función táctil de la pantalla. Además, la aplicación, pensada para ser utilizada en grandes y populares museos, está disponible en 4

86 | P á g i n a

idiomas (español, inglés, francés e italiano). Y, por último, también podrá especificarse la dirección IP del servidor al que se conectará el dispositivo. Por defecto se activarán los acelerómetros, el idioma se especificará como español y la dirección IP será la que especifique el museo. Posteriormente, una vez instalada y opcionalmente configurada la guía podrá accederse a ella mediante el ícono que puede identificarse en la vista de presentación de aplicaciones del dispositivo.

Figura 4.46. Pantalla inicial de GMM

Iniciada la aplicación se mostrará el logotipo del proyecto mientras se carga el contenido de la guía y a continuación se verá la vista inicial con las salas del museo.

87 | P á g i n a

CAPÍTULO V –Pruebas

5.1 – Pruebas de la Red Inalámbrica

Para poder evaluar los niveles de potencia que ofrece el punto de acceso en un salón de clases de la UPIITA se hizo uso del software de detección de puntos de acceso llamado “WirelessMon”. Este software permite capturar información acerca de los puntos de acceso relacionados a un SSID.

Dentro de un salón de clases, se realizaron tres mediciones. Se coloco el Punto de Acceso en el centro del salón en la parte superior, esto con la finalidad de evitar la interferencia que pudiesen causar las personas que estén dentro del aula, de acuerdo al análisis realizado en el capítulo III.

La configuración con la cual trabaja el punto de acceso es la siguiente:

Modo Inalámbrico: 802.11g; velocidad de transmisión: 54 Mbps Autenticación: WEP-Open Canal : 1 Potencia: 400 mW Desabilitado DHCP

La primera medición que se realizó fue cerca de donde se encontraba el punto de acceso a dos metros de distancia. Las figuras 5.1 y 5.2 muestran los resultados arrojados por el programa WirelessMon instalado en una computadora portátil con Sistema Operativo Windows XP.

Figura 5.1. Intensidad de la señal detectada por el software a dos metros de distancia del punto de acceso

88 | P á g i n a

Figura 5.2. Gráfica que muestra la relación de la potencia de la señal [dBm] en el tiempo a dos metros de distancia

La segunda medición tomada fue cerca de las paredes del aula. Se hizo en esta parte ya que será aquí, donde se espera que los usuarios estén colocados observando las obras en exposición. Las figuras 4.50 y 4.51 muestran los resultados.

Figura 5.3. Intensidad de la señal detectada por el software a cuatro metros de distancia del punto de acceso

Como se puede observar en el radar de la figura 5.3, la fuerza con la que el dispositivo recibe la señal disminuye en comparación con la figura 5.1 esto debido a la distancia en la que se encuentra la computadora. Pero al observar la gráfica de la figura 5.4, donde se muestra la potencia de recepción se observa que es ligeramente pequeña a la gráfica de la figura 5.2, por lo tanto se concluye que se tendrá un buen comportamiento de la red en ese punto del aula.

Por último se realizaron mediciones fuera del aula para ver la intensidad de la señal cuando está atraviesa una pared. En las figuras 5.3 y 5.4 podemos observar los resultados de las mediciones.

89 | P á g i n a

Figura 5.4. Gráfica que muestra la relación de la Potencia de la señal [dBm] en el tiempo a cuatro metros de distancia

Figura 5.5. Intensidad de la señal detectada por el software a siete metros de distancia del punto de acceso

Figura 5.6. Gráfica que muestra la relación de la Potencia de la señal [dBm] en el tiempo a siete metros de distancia

Un punto importante a destacar es que en comparación con los cálculos teóricos que se realizaron en capítulo 3 se observa que no coinciden con los prácticos, en estos últimos se obtuvieron mejores niveles de potencia que los esperados en la teoría, lo cual resulta favorable.

90 | P á g i n a

Por lo tanto con el Punto de Acceso colocado en esa posición podemos dar cobertura a toda el aula, que es el área de interés. Adicionalmente, al realizar mediciones por el área exterior al aula se observa que también se tiene cobertura. Se realizaron las mediciones en el aula de junto que simula la otra sala de exposición y se obtuvieron resultados similares a los obtenidos en el primer salón de clases.

5.2 – Pruebas de conectividad y concurrencia del sistema Una de las directrices principales a lo largo de la planeación y el desarrollo del presente proyecto es la concurrencia o manejo de la demanda de contenidos. Como ya se mencionó anteriormente, uno de los objetivos es dar servicio a la mayor cantidad de visitantes en un momento dado. En este sentido se realizaron múltiples pruebas con condiciones de laboratorio; el lugar donde se realizaron las pruebas es un salón de la escuela, cumpliendo por lo tanto con las características del análisis de la red realizado. La prueba consistió en colocar un punto de acceso en el techo falso de la sala al centro de la misma, tal como se describió en el análisis de la red del capítulo 3. Se probó la concurrencia de peticiones de contenidos al servidor en 5 dispositivos (3 iPod Touch y 2 iPhone). Se realizó la petición simultánea del mismo contenido, variando en cada prueba el tipo de contenido a descargar y a su vez el proceso se repitió 12 veces aumentando la distancia en que se realizó la petición desde el punto de acceso. Los resultados promedio de las pruebas fueron bastante satisfactorios y son resumidos en la tabla 5.1.

Figura 5.7.Reproducción de un video en iPhones®

91 | P á g i n a

DISPOSITIVOS TIEMPO DE RESPUESTA

DISTANCIA: 0 – 3m

0 – 5s 5 – 10s Más de 10 s Retrasos

Observados

Medio Descargado

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

1 iPhone #1 2 iPhone #2

3 iPod Touch #1

4 iPod Touch #2 5 iPod Touch #3

DISTANCIA: 3 – 6m


Observados

Medio Descargado

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

1 iPhone #1

2 iPhone #2

3 iPod Touch #1

4 iPod Touch #2

5 iPod Touch #3

DISTANCIA: 6 – 9m


Observados

Medio Descargado

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

AU

DIO

VID

EO

S

IMÁ

GE

N

1 iPhone #1

2 iPhone #2

3 iPod Touch #1 4 iPod Touch #2 5 iPod Touch #3

Tabla 5.1.Resultados de las pruebas de conectividad y concurrencia

Los resultados derivados de estas pruebas fueron muy satisfactorios cumpliendo en todos los casos con las peticiones. En un futuro, pruebas más rigurosas pueden realizarse con más dispositivos tomando en cuenta el ancho de banda calculado para la red a emplear.

92 | P á g i n a

CONCLUSIONES

Tras haber analizado, desarrollado y probado el sistema, es gratifícate comprobar que los objetivos iniciales de administración, comunicación y consulta de contenidos se alcanzaron plenamente. El análisis realizado fue la base fundamental para el desarrollo del sistema ya que nos permitió comprender el problema y seleccionar las herramientas necesarias para

permitir el completo funcionamiento del sistema. Un valor agregado es que el sistema sienta las bases en el desarrollo de aplicaciones para los dispositivos iPhone® y iPod Touch® dentro

de la UPIITA, dispositivos que cada día son más populares en la sociedad.

Profesionalmente, nuestro sistema involucró retos que requerían de investigación en el

manejo de herramientas con las que no se había trabajado durante el trascurso de la carrera y que sin embargo fueron ampliamente explotadas para solucionar problemas medulares. Un

caso notable fue la integración de archivos XML con el servidor de contenidos multimedia; aún más importante fue la implementación de la tecnología HTTP Live streaming para los

dispositivos móviles que utilizamos que permitió tener un mejor desempeño de la red empleada y en la administración de peticiones tal como lo demostraron los resultados de las

pruebas.

Un punto que vale la pena resaltar también, es la modelación virtual de las salas del museo

utilizando OPENGL, un proceso que normalmente está integrado en la programación de juegos de video y que es una característica que terminó enriqueciendo la navegación por el

recinto. Cabe mencionar que en este respecto hubo algunas dificultades que resolver al momento de trabajar con la memoria del dispositivo móvil, pues ésta es limitada. Esta

situación nos llevó a reevaluar la forma en la que estábamos acostumbrados a programar y orientarnos también en el eficiente manejo de los recursos que tenemos disponibles.

Por otro lado, la documentación del sistema y la granularización de sus subprocesos fueron

estrategias muy útiles al permitir caracterizar cada subsistema por separado, comprenderlo y atacar su problemática individual. Esto es muy palpable en el caso de la aplicación móvil,

donde se requirió trabajar con una plataforma independiente a la del sistema operativo del servidor de medios.

Finalmente, en cuanto al análisis de la red a implementar debieron determinarse las

características del lugar sobre el que se tenían que realizar las pruebas, como por ejemplo, el área que abarca y el material de su construcción. Durante el desarrollo de esta actividad se trabajó con profesores del área de comunicaciones de la escuela y con el invaluable acervo

bibliográfico de la ESIME Zacateco. Esta interacción además de ser enriquecedora académicamente permitió involucrarnos en otros ambientes de trabajo y conocer ideologías

diferentes acerca de lo que debe integrar un verdadero proyecto telemático. Al final las pruebas demostraron que la red era capaz dar un buen servicio en un área más grande que la

propuesta inicialmente.

93 | P á g i n a

TRABAJO A FUTURO

El sistema telemático que conforma el proyecto Guía Museográfica Multimedia fue diseñado pensando en que pueda ser mejorado. De acuerdo con los módulos definidos en los capítulos anteriores los componentes que se utilizan pueden cambiar. El mejor caso de mejoras futuras lo constituye la red empleada, pues de acuerdo con el recinto donde se vaya a proveer el servicio de contenidos tendrán que hacerse los respectivos ajustes al modelo presentado en esta tesis. El factor del ancho de banda también es determinante al manejar videos de más altas definiciones ya que la transferencia de estos requiere de de una mayor tasa de bits por lo que será importante tomar en cuenta estos aspectos al elegir la topología y la tecnología de la red inalámbrica. Por otro lado, la aplicación móvil por sí sola deberá de ser adaptada en cada escenario de uso, teniendo que tomar en cuenta la disposición de las obras, la forma de la sala a virtualizar y las características físicas de ésta. Un trabajo a futuro sería modelar un recinto real con sus respectivas salas y obras para hacer de la aplicación móvil una herramienta útil y verdaderamente valiosa al visitar un museo, por ejemplo, de nuestra ciudad. Finalmente, la investigación museográfica deberá de hacerse como convencionalmente se hace: al inicio de los trabajos para la preparación de una exposición, y determinar el material multimedia con el que se llenará el repositorio de contenidos (Base de Datos) que permitirá ponerlos al alcance de los visitantes.

94 | P á g i n a

BIBLIOGRAFÍA

[1] Jorge Lázaro Laporta, “Fundamentos de telemática”, Ed. Universidad

Politécnica de Valencia, 408 páginas, 2005, España

[2] Audioguía – Sé tu propia audioguía [Sitio web, última consulta 11/Nov/09],

http://www.audioguia.com.mx/

[3] Garibay Gerardo, Ibarra Arturo, “Sistema para la navegación guiada en

espacios reales con soporte de información contextual para dispositivos móviles”, tesis

profesional, UPIITA IPN, Junio 2006, México DF

[4] Fundamentos de Programación para el iPhone [Sitio web, última consulta

11/Nov/09], http://www.cristalab.com/tutoriales/fundamentos-de-programacion-

para-iphone-c260l/

[5] Dibujo por computadora [Sitio web, última consulta 11/Nov/09],

http://dibujo-por-computadora.infored.com.mx/categoria0.html

[6] Shreiner Dave, “The OpenGL® Programming Guide”, Addison-Wesley, 2005,

Nueva York EEUU

[7] Realidad virtual [Sitio web, última consulta 11/Nov/09],

http://www.fib.upc.edu/retro-informatica/avui/realitatvirtual.html

[8] Aplicaciones Web vs. Escritorio [Sitio web, última Consulta 11/Nov/09]

http://alxplus.blogspot.com/2006/08/aplicaciones-web-vs.html

[9] Apple Developer Connection[Sitio web, última Consulta 11/Nov/09]

http://developer.apple.com

[10] Borzelli Miguel, “Diseño de la red inalámbrica para la UPIITA y la UPIBI del

IPN”, tesis magistral, ESIME IPN, 2005, México DF

[11] Cruz Alfredo, Melo Víctor, Rodríguez Juan, ”Ampliación de la Red Inalámbrica

de la Universidad Lucerna”, tesis profesional, ESIME IPN, 2008, México DF.

[12] Fowler Martin, “UML gota a gota”, Ed. Addyson Wesley Longman, 214

páginas, 2000, Illinois EEUU

http://alxplus.blogspot.com/2006/08/aplicaciones-web-vs.html

95 | P á g i n a

[13] Rodríguez Luis, “Base de datos documentales: Estructura y principios de uso”,

CINDOC-CSIC, 2001, Madrid España.

[14] Base de Datos Multimedia, Universidad Nacional de Trujillo, Escuela de

Informática, 2009, Perú.

[15] Ramírez Elmasri, “Fundamentos de Sistemas de Base de Datos”, Ed. Prentice

Hall, 2ra Edición.

[16] Sun Developer Network [Sitio web, última consulta 11/Nov/09]

http://developers.sun.com/

[17] Canal Visual Basic .NET, [Sitio Web última consulta 11/Nov/09]

http://www.canalvisualbasic.net/manual-net/c-sharp

[18] Java DB easy and Advanced [Sitio Web última consulta 11/Nov/09]

http://developers.sun.com/javadb/features/faqs.jsp#1q1

http://developers.sun.com/javadb/features/index.jsp

[19] Saenz Luis, “Comparación entre sistemas de gestión de bases de datos bajo

licenciamiento libre y comercial”, tesis profesional, Universidad Católica de Colombia,

2005, Bogotá Colombia

[20] Proyecto PostgreSQL [Sitio Web última consulta 11/Nov/09]

http://es.tldp.org/Postgresql-es/web/navegable/user/user.html

[21] MySQL 5.0 Reference Manual, [Sitio Web última consulta 11/Nov/09]

http://dev.mysql.com/doc/refman/5.0/es

[22] Dance Chris, “Using Apache Derby in the real world”, Victorian AJUG, 2008,

Australia

[23] IPhone OS Reference Library [Sitio web, última consulta 11/Nov/09]

http://developer.apple.com/iphone/library/navigation/index.html

[24] SimonMaurice’scodingheaven[Sitio web, última consulta 11/Nov/09]

http://web.me.com/smaurice/AppleCoder/Welcome.html


96 | P á g i n a

[25] FFMPEG[Sitio web, última consulta 16/Mayo/10]


[26] Install and use the latest FFmpeg and x264 [Sitio web, última consulta

16/Mayo/10] http://ubuntuforums.org/showthread.php?t=786095

[27] Streaming MPEG4 with Linux[Sitio web, última consulta 16/Mayo/10]

http://www.linuxjournal.com/article/6720?page=0,0&postcount=636

[28] Streaming Server[Sitio web, última consulta 16/Mayo/10]

http://developer.apple.com/opensource/server/streaming/index.html

[29] iPhone [Sitio web, última consulta 16/Mayo/10]

http://www.apple.com/iphone/specs.html


http://ubuntuforums.org/showthread.php?t=786095

http://www.linuxjournal.com/article/6720?page=0,0&postcount=636

http://developer.apple.com/opensource/server/streaming/index.html

http://www.apple.com/iphone/specs.html

97 | P á g i n a

GLOSARIO

API (Applicaton Programming Interface): Interfaz de programación de aplicaciones. DHCP: Protocolo de red que permite a los nodos obtener sus parámetros de configuración automáticamente. GMM: Guía Museográfica Multimedia Framework: Estructura de soporte definida mediante la cual otro proyecto de software puede ser desarrollado y organizado. HTTP (Hypertext Transfer Protocol): Protocolo de Transferencia de Hipertexto. IEEE (Institute of Electrical and Electronics Engineers): Instituto de Ingenieros Eléctricos y Electrónicos. LAN (Local Area Network): Red de área local. MAC (Media Access Control) address: Dirección de control de acceso al medio. Objeto (de exposición): pintura, mural, pieza arqueológica, arte plática, planta, animal, monumento o cualquier otra cosa que pueda ser sujeta a exhibición.

OPENGL (Open Graphic Libraries): Bibliotecas gráficas libres. Quicktime: Es un framework mutimedia desarrollado por Apple que consiste en un conjunto de bibliotecas y un reproductor multimedia (QuickTime Player). Sistema Telemático: Conjunto de recursos distribuidos que utilizan los sistemas informáticos para comunicarse. SSID: Es un nombre incluido en todos los paquetes de una red inalámbrica WiFi para identificarlos como parte de esa red. Virtualización: proceso de cálculo complejo desarrollado por un ordenador destinado a generar una imagen 2D a partir de una escena 3D. La computadora interpreta la escena en tres dimensiones y la plasma en una imagen bidimensional. WiFi (Wireless Fidelity): Estándar de comunicación inalámbrica que cumple con los estándares IEEE 802.11g. WLAN (Wireless Local Area Network): Red de área local inalámbrica. p

instituto politÉcnico nacional...m. en c. blanca alicia rico jiménez d. en c. miguel félix mata...

Documents