universidad de castilla-la mancha escuela superior

Transcripción

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
“AVISMI
Asistente para Visita Multimedia Interactiva de Museos y
Salas de Exposiciones”
Miguel Ángel Martı́nez Pinedo
Junio, 2009
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
“Arquitectura de Computadores”
PROYECTO FIN DE CARRERA
“AVISMI
Asistente para Visita Multimedia Interactiva de Museos y
Salas de Exposiciones”
Autor: Miguel Ángel Martı́nez Pinedo
Director: Francisco Moya Fernández
Junio, 2009
TRIBUNAL:
Presidente:
Vocal 1:
Vocal 2:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE
Fdo.:
VOCAL 1
Fdo.:
VOCAL 2
Fdo.:
SECRETARIO
Fdo.:
c Miguel Ángel Martı́nez Pinedo. Se permite la copia, distribución y/o modificación de este
documento bajo los términos de la licencia de documentación libre GNU, versión 1.1 o cualquier
versión posterior publicada por la Free Software Foundation, sin secciones invariantes. Puede consultar esta licencia en http://www.gnu.org.
Este documento fue compuesto con LATEX. Imágenes generadas con Dia y Netbeans.
Resumen
La cantidad de información que se maneja hoy en dı́a es ingente, siendo la mayorı́a
relevante; sin embargo el problema reside en la dimensión espacio-tiempo en la que se
ofrece. Es decir, la información es relevante sólo si se recibe en el momento y el lugar
adecuado. Por ello la necesidad de obtener información precisa en un instante y en una
ubicación concreta plantea un reto a resolver.
Este problema se presenta en multitud de contextos tanto en los referentes al ámbito
tecnológico como en cualquier otro, siendo nuestra obligación resolverlo (al menos en el
ámbito tecnológico) en la medida que sea posible. Este proyecto fin de carrera aborda esta
problemática y propone una solución para un contexto concreto: un museo.
Se ha elegido este contexto, y no otro, por varios motivos; el primero es la creencia en el
acceso libre y universal a la cultura y al conocimiento. El segundo motivo para la elección
de este contexto, consecuencia del primero, es dotar de una herramienta libre a los pequeños
museos para difundir conocimiento valiéndose de las nuevas tecnologı́as, enriqueciendo de
ese modo sus visitas.
VII
A mis padres
Agradecimientos
La realización de este proyecto es la culminación de todo el esfuerzo invertido durante
la carrera universitaria, por lo que no sólo tengo palabras de agradecimiento para todos los
que me han apoyado en esta última etapa, sino que estoy muy agradecido a todos los que
han hecho posible que llegue a realizarlo.
En primer lugar quiero agradecer a mis padres los valores que me han enseñado, ya que
de no ser por su educación basada en el esfuerzo y el respeto, por su cariño, por su afecto y
su apoyo nunca habrı́a conseguido nada. También quiero agradecer a mis abuelos, a todos
ellos, sus consejos, su afecto, su cariño y su hambre de conocimiento, ya que aunque ellos
no tuvieron la suerte de estudiar si que han apoyado a sus hijos y nietos para que lo hagan.
Por supuesto para Eva no tengo mas que palabras de cariño y agradecimiento ya que
siempre ha estado ahı́ cuando he tenido problemas, cabreos o decepciones; animándome a
seguir y apoyándome en todo momento, enseñándome a mirar hacia el futuro con perspectiva y a valorar las cosas que realmente importan.
Desde que empecé la carrera siempre estuviste allı́, enseñándome a vivir por mi cuenta,
y ayudándome siempre que me hizo falta. También hemos tenido algún roce, pero conviviendo durante tres años lo raro es que no nos tiráramos nada a la cabeza, en fin, muchas
gracias por todo Pedro. Pero tampoco me olvido de ti Carlos, que aunque eres el pequeño,
nunca me dejas de sorprender; seguro que llegarás muy lejos.
Mención especial en estos agradecimientos merece mi director de proyecto, Francisco
Moya; gracias a que confió en un alumno al que prácticamente desconocı́a, me ha sido
posible llevar a cabo un proyecto con el que crecer tanto a nivel profesional como moral.
También quiero agradecer a Juan Carlos el hueco que me hizo en ARCO, lo que me
ha permitido conocer a unos compañeros extraordinarios, tanto a nivel profesional como
personal. De hecho, tengo que agradecer a todos y cada uno de ellos el magnı́fico ambiente
de trabajo, ası́ como sus aportaciones en todos los aspectos al proyecto. Mas concretamente,
gracias Peris por enseñarme LATEX, a hacer interfaces con glade, por compartir penas y
alegrı́as, etc. Muchas gracias Lucas por ayudarme con GTK, con Python, con la fonera,
por amenizarnos los cafés, etc... Gracias Cleto, por mostrarme el camino hacia C++ y a los
palomos sin mantequilla. Gracias Oscar por tu paciencia infinita con mis preguntas (triviales
para tu infinita sabidurı́a) sobre Ice y GTK. Muchas gracias Tobias por aguantarme a tu
vera, por enseñarme cómo “guarrear” sistemas, por echarme un cable con el Bluetooth, con
las redes... Gracias Nacho por montar esos magnı́ficos servidores, por echarme una mano
con el scripting, por aguantar mis quejas tanto en el laboratorio como en el gimnasio...
Gracias también a Manu, Julian y Javi (Alsoez), ya que aunque no entienda lo que están
IX
haciendo colaboran para tener un ambiente de trabajo ejemplar. También quiero agradecer
a Ricardo su paciencia a la hora de echarme una mano con C++, su forma original de
detractar, los viajes en el Yellow Mobil... Muchas gracias Gloria por cuidarnos, sin ti seguro
que tendrı́amos un par de kilos menos. Tampoco me olvido de los de arriba, de David y Paco
(menudo pedazo de ayuda con gobject.init), de David y Felix, de Maria José y Xavi, y de
Fernando (live man).
Por último, y no por ello menos importante, quiero agradecer a todos los compañeros
que me han aguantado a lo largo de la carrera tanto en Madrid como en Ciudad Real, ya
que no sólo me han aportado buenos momentos, sino buenas amistades. Muchas gracias
a todos: a los madrileños Tagle y Ruyman, a los puertollaneros David, Antonio, Ismael,
José, Reinoso, Jesús, Sergio... seguro que se me olvidan muchos, pero ellos os representan
a todos.
En fin, sólo quiero mostrar mi mas sincero agradecimiento a todos los que me habéis
apoyado en todos estos años (incluso a los que no aparecen mencionados explı́citamente),
ya que de una u otra manera habéis aportado algo muy importante en mi vida.
Muchas gracias a todos.
Índice general
Lista de Figuras
XV
1. Introducción
1
1.1. Motivación y justificación del trabajo . . . . . . . . . . . . . . . . . . . . .
1
1.2. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2. Objetivos
3
2.1. Objetivos principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2. Objetivos secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3. Antecedentes, estado de la cuestión
5
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2. Sistemas de administración de contenidos . . . . . . . . . . . . . . . . . .
6
3.2.1. IBM Content Manager Data System . . . . . . . . . . . . . . . . .
6
3.2.2. Vernon CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.2.3. PastPerfect Museum Software 4 . . . . . . . . . . . . . . . . . . .
7
3.3. Sistemas de localización en interiores . . . . . . . . . . . . . . . . . . . .
7
3.3.1. The Cricket Indoor Location System. . . . . . . . . . . . . . . . .
8
3.3.2. Sensor-assisted wi-fi indoor location system for adapting to environmental dynamics . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3.3. Ekahau Positioning Engine . . . . . . . . . . . . . . . . . . . . . .
8
3.3.4. WhereMoPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.4. Sistemas dependientes del contexto . . . . . . . . . . . . . . . . . . . . . .
9
3.4.1. MobiShare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.4.2. An infrastructure for context dependent mobile multimedia communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4. Método de trabajo
13
XI
XII
ÍNDICE GENERAL
4.1. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.2. Identificación de los requisitos funcionales del sistema. . . . . . . . . . . .
18
4.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.4. Iteración 0. Definición de la arquitectura base. . . . . . . . . . . . . . . . .
24
4.4.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.4.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.4.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.4.4. Pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.5. Iteración 1. Inteligencia del sistema. . . . . . . . . . . . . . . . . . . . . .
40
4.5.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.5.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.5.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.5.4. Pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.5.5. Vista actual del sistema. . . . . . . . . . . . . . . . . . . . . . . .
48
4.6. Iteración 2. Herramienta de gestión. . . . . . . . . . . . . . . . . . . . . .
51
4.6.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.6.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.6.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
58
4.7. Iteración 3. Cálculo de rutas . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.7.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.7.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.7.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
63
4.8. Iteración 4. Ampliación de la herramienta de gestión . . . . . . . . . . . .
67
4.8.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.8.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.8.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
74
4.9. Iteración 5. Servidor de Medios. . . . . . . . . . . . . . . . . . . . . . . .
76
4.9.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.9.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.9.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
81
4.10. Iteración 6. Obtención de informes. . . . . . . . . . . . . . . . . . . . . .
84
ÍNDICE GENERAL
XIII
4.10.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.10.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.10.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
89
4.11. Iteración 7. Distribución de la aplicación del dispositivo móvil. . . . . . . .
92
4.11.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.11.2. Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.11.3. Implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
94
4.12. Iteración 8. Despliegue del sistema . . . . . . . . . . . . . . . . . . . . . .
96
4.12.1. Análisis del hardware necesario . . . . . . . . . . . . . . . . . . .
96
4.12.2. Recopilación de información para el sistema . . . . . . . . . . . .
98
4.12.3. Puesta en funcionamiento del sistema. . . . . . . . . . . . . . . . .
98
5. Resultados
6. Conclusiones y propuestas.
99
103
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2. Propuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Bibliografı́a
110
7. Anexos
111
7.1. Anexo I. Herramienta de administración. . . . . . . . . . . . . . . . . . . . 112
7.1.1. Panel para el manejo de documentos. . . . . . . . . . . . . . . . . 112
7.1.2. Panel para el manejo de objetos del museo. . . . . . . . . . . . . . 113
7.1.3. Panel para el manejo de relaciones entre objetos. . . . . . . . . . . 114
7.1.4. Panel para el manejo de puntos de información. . . . . . . . . . . . 115
7.1.5. Panel para la visualización de la localización de visitantes. . . . . . 116
7.1.6. Panel para la obtención de informes. . . . . . . . . . . . . . . . . . 117
7.1.7. Barra de menú. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2. Anexo II. Instalación de Hesperia OpenLS. . . . . . . . . . . . . . . . . . 122
7.2.1. Software necesario . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.2.2. Configuración de la base de datos OpenLS . . . . . . . . . . . . . 123
7.2.3. Vista final del archivo odbc.ini . . . . . . . . . . . . . . . . . . . . 124
7.3. Anexo III. Hesperia IndirectPropertyService. . . . . . . . . . . . . . . . . 125
XIV
ÍNDICE GENERAL
7.3.1. Hesperia.PropertyService . . . . . . . . . . . . . . . . . . . . . . . 125
7.3.2. Hesperia.IndirectPropertyService . . . . . . . . . . . . . . . . . . 125
7.4. Anexo IV. Hesperia GISPropertyService . . . . . . . . . . . . . . . . . . . 127
7.5. Anexo V. Proyecto Hesperia. . . . . . . . . . . . . . . . . . . . . . . . . . 129
Índice de figuras
3.1. Arquitectura de MobiShare . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2. Infraestructura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.1. Diagrama de Casos de Uso. Visión general del sistema . . . . . . . . . . .
18
4.2. Iteración 0. Primera aproximación . . . . . . . . . . . . . . . . . . . . . .
30
4.3. Diagrama de casos de uso (Iteración 0) . . . . . . . . . . . . . . . . . . . .
30
4.4. Diagrama de secuencia (Iteración 0) . . . . . . . . . . . . . . . . . . . . .
31
4.5. Diagrama de casos de uso del MuseumPersistence (iteración 0) . . . . . . .
33
4.6. Diagrama de clases reducido del MuseumPersistence (Iteración 0) . . . . .
36
4.7. Diagrama de clases seguido para realizar Tests . . . . . . . . . . . . . . . .
38
4.8. Log de la herramienta Tester para el subsistema MuseumPersistence . . . .
39
4.9. Diagrama de casos de uso (Iteración1) . . . . . . . . . . . . . . . . . . . .
42
4.10. Diagrama de secuencia (Iteración1) . . . . . . . . . . . . . . . . . . . . .
43
4.11. Diagrama de clases reducido del VisitorsPersistence (Iteración1) . . . . . .
46
4.12. Diagrama de clases (reducido) del Server (Iteración 1) . . . . . . . . . . .
47
4.13. Diagrama de clases reducido de la aplicación J2ME . . . . . . . . . . . . .
49
4.14. Sistema tras la iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.15. Diagrama de casos de uso del MuseumPersistence (Iteración 2) . . . . . . .
53
4.16. Diagrama de casos de uso de AdminAVISMI (Iteración 2) . . . . . . . . .
54
4.17. Diagrama de clases reducido del MuseumPersistence (Iteración 2) . . . . .
55
4.18. Diagrama de clases (reducido) del Server (Iteración 2) . . . . . . . . . . .
56
4.19. Diagrama de clases final (reducido) de la herramienta de administración
(Iteración 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
58
4.21. Vista general del servicio Hesperia.OpenLS . . . . . . . . . . . . . . . . .
60
4.22. Base de datos del servicio Hesperia.OpenLS . . . . . . . . . . . . . . . . .
61
4.23. Diagrama de clases reducido del ManagerOpenLS . . . . . . . . . . . . . .
64
XV
XVI
ÍNDICE DE FIGURAS
4.24. Diagrama de secuencia de la iteración 3 . . . . . . . . . . . . . . . . . . .
65
66
4.26. Estructura de GRASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.27. Diagrama de secuencia que muestra la integración de PositionEngine . . . .
72
75
4.29. Diagrama de casos de uso del MediaServer . . . . . . . . . . . . . . . . .
81
4.30. Diagrama de clases del MediaServer . . . . . . . . . . . . . . . . . . . . .
82
83
4.32. Diagrama de casos de uso de AdminAVISMI (Iteración 6) . . . . . . . . .
86
4.33. Diagrama de clases (reducido) del sistema Statistics . . . . . . . . . . . . .
88
4.34. Diagrama de clases de AdminAVISMI (Iteración 6) . . . . . . . . . . . . .
90
91
4.36. Diagrama de clases del Spammer . . . . . . . . . . . . . . . . . . . . . . .
93
95
7.1. Panel para el manejo de documentos . . . . . . . . . . . . . . . . . . . . . 112
7.2. Panel para el manejo de objetos del museo . . . . . . . . . . . . . . . . . . 113
7.3. Panel para el manejo relaciones entre objetos . . . . . . . . . . . . . . . . 114
7.4. Panel para el manejo de puntos de información . . . . . . . . . . . . . . . 115
7.5. Panel para la visualización de la localización de visitantes . . . . . . . . . . 116
7.6. Panel para la obtención de informes . . . . . . . . . . . . . . . . . . . . . 117
7.7. Menú Archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.8. Menú Importar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.9. Menú Exportar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.10. Menú OpenLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.11. Menú Ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.12. Comportamiento del IndirectPropertyService . . . . . . . . . . . . . . . . 126
7.13. Diagrama de clases del GISPropertyService . . . . . . . . . . . . . . . . . 128
Capı́tulo 1
Introducción
1.1. Motivación y justificación del trabajo
1.2. Entorno
1.3. Estructura del documento
1.1.
Motivación y justificación del trabajo
Hoy en dı́a la concepción que se tiene de un museo sigue siendo la misma que hace
veinte años; un recinto en el que se exponen obras que el visitante contempla. Esta concepción ha dejado de ser válida ya que la tecnologı́a ha evolucionado rápidamente, generando
grandes espectativas en la sociedad. Sin embargo la mayorı́a de los museos siguen anclados
en la concepción anticuada de museo provocando un distanciamiento entre la sociedad y la
cultura.
Teniendo esto en cuenta se puede afirmar que la necesidad de integrar los museos y la
tecnologı́a pasa por ser un factor clave para su supervivencia.
Este factor se acentúa en pequeños museos ya que la relevancia de sus obras suele ser
menor. Es por ello por lo que se ha enfocado este proyecto hacia este tipo de museos,
ya que incentivando la visita con medios tecnológicos se aumentan las posibilidades de
supervivencia del mismo.
Sin embargo la arquitectura que se busca en este proyecto permite soportar un amplio
abanico de posibilidades. Estas posibilidades abarcan desde salas de exposiciones, hasta
museos al aire libre o rutas turı́sticas, lo que convierte al proyecto en un punto de partida
para posibles sistemas de carácter más amplio.
1.2.
Entorno
Aunque el enfoque del proyecto se oriente hacia un museo, la arquitectura abierta y
flexible que ofrece el sistema permite que este proyecto sea fácilmente adaptable a otros
2
CAPÍTULO 1. INTRODUCCIÓN
proyectos. Concretamente la localización de dispositivos y su visualización, ası́ como la
distribución de medios a dispositivos móviles se integran en el proyecto Hesperia (véase
Anexo V).
Teniendo en cuenta que el proyecto se puede ampliar o adaptar según las necesidades
del usuario final el sistema se ha desarrollado por medio del uso de tecnologı́as libres. Por
ello se ha evitado el uso de software privativo, reduciendo costes y solventando posibles
problemas legales motivados por la reutilización y mejora del código del sistema.
1.3.
Estructura del documento
A lo largo de esta memoria se expone el proceso de desarrollo del proyecto, abordando los distintos aspectos que conlleva. En el siguiente capı́tulo se establecen los objetivos
que persigue el proyecto. En el capı́tulo tres se realiza un estudio previo sobre los distintos
sistemas que abordan problemáticas parecidas a la que se aborda en el proyecto. Posteriormente en el capı́tulo cuatro, se centra la atención en cómo se ha llevado a cabo el proyecto,
atendiendo al análisis, al diseño y a la implementación. En el capı́tulo cinco se muestran los
resultados obtenidos tras la ejecución del proyecto. Para finalizar la memoria se abordan las
conclusiones obtenidas y posibles mejoras del sistema.
Capı́tulo 2
Objetivos
2.1. Objetivos principales
2.2. Objetivos secundarios
Este proyecto persigue varios objetivos que se catalogan atendiendo a su relevancia con
respecto al marco en el que se desarrolla. Teniendo esto en cuenta se muestran los objetivos
separados en dos grupos; objetivos principales y objetivos secundarios.
2.1.
Objetivos principales
Los objetivos principales se centran en los aspectos necesarios para satisfacer las necesidades comunes entre el marco en el que se desarrolla el proyecto (proyecto Hesperia,
véase anexo V), y dicho proyecto.
Distribución contextual de medios. Enviar información de diversos medios a los usuarios
dependiendo de la ubicación en la que se encuentren, de forma trasparente y cuando
los solicite. Este objetivo se puede dividir en varios subobjetivos.
Aplicación para la recepción de medios en el dispositivo móvil. Es necesario crear
una aplicación para dispositivos móviles que sea capaz de reproducir los distintos medios que ofrece el sistema. Debe realizarse con un diseño abierto para
permitir la integración de futuras funcionalidades, y es deseable que sea portable a la mayorı́a de dispositivos móviles del mercado.
Localización geográfica de dispositivos móviles. Esta localización se debe hacer de
forma transparente al usuario y de forma eficiente para el sistema. El error de
precisión en la localización dependerá de la tecnologı́a utilizada para ello.
Visualizar a los visitantes que interactúan con el sistema. Se debe crear una herramienta capaz de visualizar en tiempo real la ubicación de los visitantes en el museo.
4
2.2.
CAPÍTULO 2. OBJETIVOS
Objetivos secundarios
Además de estos objetivos fundamentales se persiguen otros objetivos de segundo nivel,
especı́ficos para este proyecto, que se enumeran a continuación:
Personalización de la visita. Se debe adaptar la información que el visitante puede recibir
teniendo en cuenta parte del contexto, es decir, conseguir dotar a la aplicación de
cierto grado de inteligencia para que a partir de la información que va recopilando el
sistema (ruta seguida y contenido solicitado) se consiga mostrar la información más
relevante para el visitante.
Obtención de informes. Con motivo de dar soporte a la ayuda en la toma de decisiones se
debe almacenar información sobre los elementos visitados que pueda ser útil para la
obtención de informes de actividad.
Sistema de navegación orientativo. Para ayudar al visitante durante su estancia en el museo el sistema debe ser capaz de esbozar el camino entre el punto en el que se encuentre el visitante y al que desee llegar.
Capı́tulo 3
Antecedentes, estado de la cuestión
3.1. Introducción
3.2. Sistemas de administración de contenidos
3.2.1. IBM Content Manager Data System
3.2.2. Vernon CMS
3.2.3. PastPerfect Museum Software 4
3.3. Sistemas de localización en interiores
3.3.1. The Cricket Indoor Location System.
3.3.2. Sensor-assisted wi-fi indoor location system for adapting to environmental
dynamics
3.3.3. Ekahau Positioning Engine
3.3.4. WhereMoPS
3.4. Sistemas dependientes del contexto
3.4.1. MobiShare
3.4.2. An infrastructure for context dependent mobile multimedia communication
3.1.
Introducción
En la actualidad el enfoque que se está aplicando en los museos es el de trasladarlos a
la web. En este campo se pueden encontrar multitud de alternativas; sin embargo, cuando
se trata de sistemas que permitan interactuar con el museo in situ existen pocas alternativas
viables, y generalmente orientadas a sistemas de vigilancia y posicionamiento.
Otra consideración muy a tener en cuenta es que, en los dos enfoques, las opciones existentes son sistemas comerciales. Éste hecho influye directamente sobre el atraso tecnológico
de los pequeños museos sin ánimo de lucro.
6
CAPÍTULO 3. ANTECEDENTES, ESTADO DE LA CUESTIÓN
A continuación se realiza un análisis de las herramientas y los estudios existentes, que si
bien no tienen exactamente el mismo fin si que comparten temática y arquitectura. En concreto éstas herramientas pertenecen al campo de los sistemas de administración de contenidos, a los sistemas de localización en interiores y a los servicios dependientes del contexto.
3.2.
Sistemas de administración de contenidos
3.2.1.
IBM Content Manager Data System
Este sistema es la solución que ofrece IBM para la gestión de contenidos bajo demanda
en tiempo real. Es un sistema multiplataforma que puede operar sobre plataformas Linux,
UNIX o Windows.
Según IBM permite manejar de forma comprensible, escalable y segura los contenidos,
que puede ser de cualquier tipo y a su vez pueden ser ofrecidos a los usuarios en cualquier
momento y en cualquier sitio. Para ello da soporte a distintos protocolos de diversa ı́ndole
cómo son HTTP [Fie99], FTP[PR85], SOAP[SOA07] o SQL[SQL09] entre otros.
Cabe señalar que no se trata de un sistema estático, sino que es posible integrar este
sistema con otros ya que ofrece una serie de APIs que incluyen servicios web, servicios
XML [XML08], JavaBeans y las librerı́as fundamentales del sistema implementadas en
Java y C++.
Por último destacar que ofrece varias interfaces de administración, en concreto una web
eClient (que utiliza tecnologı́a AJAX) y otra de escritorio. Ésta última sólo está disponible
para plataformas Windows.
El coste de este sistema asciende a 76531.00 eanuales (a fecha de 19 de Febrero de
2009).
3.2.2.
Vernon CMS
Es un sistema cuya finalidad es administrar la colección de obras de un museo. Para ello
se sirve de cuatro herramientas que componen este sistema.
Vernon Cataloguing.
Esta herramienta se encarga del almacenamiento (entrada, salida y modificación) de
la información relativa a las obras del museo, y se puede considerar el núcleo del
sistema.
Vernon Activities
Permite administrar actividades tales cómo préstamos y exposiciones, ası́ como realizar seguimientos de cada obra.
Vernon Browser
Por medio de esta herramienta se puede consultar el catálogo desde la web.
3.3. SISTEMAS DE LOCALIZACIÓN EN INTERIORES
7
Vernon HTML Export
Gracias a esta herramienta se pueden generar páginas HTML[HTM99] estáticas con
datos del catálogo.
El precio de este sistema varia según las herramientas que se compren y está especificado en la página de la empresa. Como dato de interés aquı́ se señala el precio del sistema
completo que asciende a 12700.00 libras inglesas (aproximadamente 14340.00 e).
3.2.3.
PastPerfect Museum Software 4
Se trata de un sistema especializado para museos capaz de almacenar toda la información que puede ser relevante en este entorno, a continuación se enumeran algunas caracterı́sticas que el sistema es capaz de manejar.
Catálogos.
Permite crear catálogos de diversa ı́ndole cómo de arte, geologı́a, objetos históricos,
etc. Además permite interactuar con ellos de multiples formas, bien sean obteniendo subcatálogos indicando una localización (edificio, habitación, etc) o por medio
diversos filtros, o asociando información a elementos (links, imagenes, etc).
Préstamos.
Control sobre préstamos de entrada y salida, exhibiciones, repatriaciones, etc.
Donaciones.
Custodias Temporales.
Recuperación de información
El sistema permite recuperar toda la información existente en los catálogos, volcándola en diversos medios cómo CD, DVD y en varios formatos cómo FoxPro, D-Base,
ASCII, MS-Excel, o XML.
Este sistema no deja de ser una herramienta de administración estática, y sólo se palı́a
esta situación si se utiliza el complemento para poner en la web de forma automática los
catálogos, la herramienta VirtualExhibit.
El coste de esta herramienta con el complemento mencionado asciende a 1290.00 e.
3.3.
Sistemas de localización en interiores
Cabe destacar que éste es un campo emergente en el que todavı́a no se han alcanzado
soluciones totalmente satisfactorias, por lo que no solo se analizarán las pocas herramientas
existentes sino que se tendrán en cuenta las investigaciones realizadas hasta el momento.
8
3.3.1.
The Cricket Indoor Location System.
Los creadores del sistema Cricket [Pri05], perteneciente al grupo NMS (Networks and
Mobile Systems) del MIT(Massachusetts Institute of Technology), ofrecen una descripción
precisa del sistema; a continuación se muestra traducida.
“El sistema de localización en interiores Cricket para entornos computerizados basados
en sensores [...] proporciona una localización precisa (identificadores de espacio, coordenadas de posición y orientación) para aplicaciones que funcionan en dispositivos de mano,
ordenadores de sobremesa y nodos de sensores.
Este sistema utiliza una red de pequeños dispositivos inalámbricos proporcionados por
Crossbow Technologies para triangular la posición con un margen de error mı́nimo (entre
uno y tres centı́metros).”
Cabe destacar que éste sistema puede ser muy útil en entornos en el que se necesite una
alta precisión en el seguimiento y se tenga un conocimiento detallado del entorno. Además
se debe desplegar una infraestructura adicional con el coste que ello supone, tanto cómo
por la inversión inicial cómo por el mantenimiento, ya que estos dispositivos inalámbricos
deben ser recargados cada cierto tiempo.
Sin embargo en el ambiente en el que se desarrolla el proyecto esta solución no tiene
cabida debido a dos motivos:
Se intenta utilizar todo el hardware existente para proporcionar el servicio, intentando
reducir gastos en hardware adicional.
Se permite un margen de error elevado en la localización, ya que los contenidos relevantes dependen del contexto en el que se desenvuelve el visitante.
3.3.2.
Sensor-assisted wi-fi indoor location system for adapting to environmental dynamics
Este estudio [YCJRHh+ 05], llevado a cabo por el Departamento de Ingenierı́a Eléctrica
de la Universidad Nacional de Taiwan, permite realizar el seguimiento de dispositivos WiFi. Para ello se realizan mediciones de la calidad con la que el dispositivo recibe la señal y
además se utilizan etiquetas con tecnologı́a RFID para corregir las mediciones.
En este estudio se llega a la conclusión de la necesidad de complementar las mediciones
con varios dispositivos ya que hay multitud de perturbaciones en la señal Wi-Fi, desde tener
puertas cerradas hasta las interferencias de distintos aparatos electrónicos.
3.3.3.
Ekahau Positioning Engine
En el mercado encontramos esta solución para el posicionamiento en interiores; Si bien
está totalmente descartada utilizar dicha solución si que resulta interesante señalarla como
una de las pocas alternativas comerciales existentes para este tipo de servicios. A continuación se cita la traducción de la descripción del sistema ofrecida por la empresa.
3.4. SISTEMAS DEPENDIENTES DEL CONTEXTO
9
El sistema Ekahau RTLS(Real Time Location System, en castellano Sistema de localización en tiempo real) es el único sistema de seguimiento basado en Wi-Fi que puede operar
sobre cualquier banda o frecuencia Wi-Fi ofreciendo una precisión a nivel de habitación,
planta y edificio. Cómo este sistema trabaja con el estándar 802.11 no requiere lectores,
nuevo cableado o obsoletos sensores. El sistema utiliza software patentado basado en algoritmos que calculan la posición de los objetos seguidos y puede escalarse fácilmente para
soportar miles de etiquetas en un único servidor.
3.3.4.
WhereMoPS
El sistema WhereMoPS [Wal02] es una plataforma de investigación flexible para sistemas avanzados de geolocalización en interiores que se puede extender para integrar subsistemas sensibles adicionales y algoritmos de posicionamiento. La información de localización es distribuida mediante el Mobile Positioning Protocol (MPP, protocolo propietario de
Ericsson). En este artı́culo se describe el diseño y la implementación del sistema ası́ como
las modificaciones necesarias para adaptar el MPP a interiores.
Este sistema es interesante, sin embargo la utilización de un protocolo propietario limita
el sistema a las polı́ticas que la empresa desarrolladora del protocolo imponga.
3.4.
Sistemas dependientes del contexto
3.4.1.
MobiShare
MobiShare [VVV+ 03] es un sistema que permite conectar distintos recursos mediante
un framework común, teniendo en cuenta el contexto como caracterı́stica principal. Este
proyecto se desarrolló durante 2003, factor a tener en cuenta a la hora de contrastarlo con
los sistemas actuales.
Los objetivos que este sistema planteó fueron los siguientes:
Proporcionar un sistema middleware para el manejo de información.
Proporcionar una arquitectura e infraestructura para ofrecer conectividad a dispositivos móviles.
Optimizar una solución para el envı́o y la compartición de datos entre nodo móviles.
Enfoque centralizado de datos.
Orientado a servicios.
Para llevar a cabo este sistema se creó la arquitectura que se muestra en la figura 3.1. En
ésta figura se pueden apreciar varios elementos:
Cell Administration Server (CAS)
10
• Administra el área de cobertura del punto de acceso wireless
• Responsable de mantener la lista de dispositivos y servicios disponibles
• Proporciona el servicio de descubrimiento aptitudes
• Almacena información estadı́stica de usuarios y dispositivos
• Interacciona con los CAS vecinos para solicitar y recibir información de localización, descripciones de servicios, etc.
Área de influencia del CAS.
• Los dispositivos están conectados exactamente a un punto de acceso en cada
instante.
Dispositivos móviles.
• Consumidores de servicios.
• Posible proveedor de datos.
Figura 3.1: Arquitectura de MobiShare
La localización se realiza gracias a la entrada de un dispositivo en el área de influencia
de un punto de acceso. En concreto cuando el dispositivo se conecta a la red informa de
la posición previa, y cuando sale de ella el CAS que maneja la red de la que sale anota la
última posición.
Para solicitar y recibir servicios se utiliza la IP del dispositivo, mientras que la especificación de dichos servicios se realiza por medio de WSDL[W3C01].
Conviene destacar que los dispositivos móviles cuentan con hardware difı́cil de encontrar hoy en dı́a en dispositivos comerciales, ya que utilizan brújulas digitales además de
receptores GPS [GPS08] interfaces Wireless.
Este sistema presenta varios inconvenientes. El principal está motivado por la falta de
un middleware que maneje las comunicaciones y los descubrimientos de servicios, lo que
conlleva a realizar todo este manejo de forma manual y utilizando métodos poco eficientes
3.4. SISTEMAS DEPENDIENTES DEL CONTEXTO
11
cómo el intercambio de archivos de texto. Esto implica una ralentización en el descubrimiento de servicios y una sobrecarga en la red debido al aumento de tráfico. Además al no
utilizar un middleware que identifica de forma unı́voca a los dispositivos, éstos se deben
identificar con la IP, lo que conlleva más trabajo y posibles problemas en caso de solapamiento de áreas de influencia, etc.
El último inconveniente está condicionado a la naturaleza del proyecto que se va a realizar, ya que éste sistema utiliza tecnologı́as basadas en software privativo, tanto en el lado
de los servidores cómo de los clientes, lo que limita en gran medida los dispositivos que se
pueden utilizar en el sistema.
3.4.2.
An infrastructure for context dependent mobile multimedia communication
En este estudio [SKC+ 04] de la universidad de Copenhague se muestra un ejemplo de
infraestructura para distribuir contenidos multimedia a dispositivos móviles dependiendo
del contexto.
Este sistema (figura 3.2) se vale de herramientas comerciales cómo el IBM Via Voice y el
sistema de posicionamiento WiFi Ekahau para determinar la posición y ofrecer los medios
multimedia.
Figura 3.2: Infraestructura del Sistema
Cómo novedad tecnológica ofrece una capa software que permite actuar cómo interfaz
de comunicación y posicionamiento, y cómo proveedor de software para el desarrollo de
nuevos servicios. Además realiza una implementación del algoritmo Floyd-Warshall para
realizar el cálculo de rutas entre posiciones.
Esta infraestructura está fuertemente condicionada por la utilización de sistemas comerciales, aportando poco al campo de la investigación y la innovación. Además debido a ello
12
el coste de implantación y mantenimiento será elevado, reduciendo de ese modo el público
al que se dirige el sistema.
Teniendo en cuenta las caracterı́sticas del proyecto que se va a realizar este tipo de
sistema, hı́brido entre sistema comercial e investigador, no tiene cabida. Además se puede realizar una localización con un margen de error válido para este proyecto con otras
tecnologı́as y evitando encarecer el sistema con sistemas comerciales.
Capı́tulo 4
Método de trabajo
4.1. Metodologı́a
4.2. Identificación de los requisitos funcionales del sistema.
4.3. Planificación
4.4. Iteración 0. Definición de la arquitectura base.
4.4.1. Análisis.
4.4.2. Diseño.
4.4.3. Implementación.
4.4.4. Pruebas.
4.5. Iteración 1. Inteligencia del sistema.
4.5.1. Análisis.
4.5.2. Diseño.
4.5.4. Pruebas.
4.5.5. Vista actual del sistema.
4.6. Iteración 2. Herramienta de gestión.
4.6.1. Análisis.
4.6.2. Diseño.
4.7. Iteración 3. Cálculo de rutas
4.7.1. Análisis.
4.7.2. Diseño.
4.8. Iteración 4. Ampliación de la herramienta de gestión
13
4.8.1. Análisis.
4.8.2. Diseño.
4.9. Iteración 5. Servidor de Medios.
4.9.1. Análisis.
4.9.2. Diseño.
4.10. Iteración 6. Obtención de informes.
4.10.1. Análisis.
4.10.2. Diseño.
4.11. Iteración 7. Distribución de la aplicación del dispositivo móvil.
4.11.1. Análisis.
4.11.2. Diseño.
4.12. Iteración 8. Despliegue del sistema
4.12.1. Análisis del hardware necesario
4.12.2. Recopilación de información para el sistema
4.12.3. Puesta en funcionamiento del sistema.
4.1.
Metodologı́a
Desde la concepción inicial del proyecto se han considerado diversas alternativas, entre
las que destacan la metodologı́a eXtreme Programing (XP)[KB00], el modelo de vida software conocido cómo prototipado evolutivo y el Proceso Unificado de Rational [JBR99].
Todas coinciden en que son alternativas ágiles, que permiten un alto grado de flexibilidad a
la hora de realizar modificaciones tras detectar nuevos requisitos.
eXtreme Programming. XP[KB00] es una metodologı́a ligera que intenta obtener métodos sencillos para obtener software de calidad. Las técnicas que se utilizan en esta metodologı́a se enmarcan en cuatro ámbitos: planificación, diseño, codificación y
pruebas.
Con respecto a la planificación se parte de una serie de Historias de usuario (descripción informal de las necesidades de los usuarios) que orientan el desarrollo y las
4.1. METODOLOGÍA
15
pruebas de aceptación. Estas historias se dividen en tareas que sean planificables y
medibles en su estado de realización. Una vez que se han establecido y acotado las
tareas (tanto en alcance tecnológico cómo temporal) se procede a implementar las
funcionalidades de forma incremental. Para ello se fijan unos objetivos para cada incremento y se focaliza el esfuerzo en ese incremento hasta su finalización.
El diseño en XP apuesta por huir de las soluciones complejas; para ello aporta la
refactorización (obtener una solución común para puntos comunes de las historias de
usuario, siempre y cuando sea mas simple) y aconseja seguir extrictamente el plan
para evitar trabajar en algo que posteriormente pueda ser modificado.
Para la codificación se recomienda que el usuario vaya siendo informado de los cambios para adaptar en la mayor medida el software a sus necesidades. Además se aconseja seguir estándares de codificación ası́ cómo llevar a cabo pruebas unitarias automatizables de todo el código, de este modo al realizar cualquier cambio se puede
comprobar que sigue funcionando para todos los casos anteriores a la modificación.
También se recomienda que se establezca una infraestructura que se encarge de compilar y comprobar automáticamente todo el proyecto y que alerte en caso de que haya
errores.
Prototipado Evolutivo. El prototipado evolutivo permite generar aplicaciones mı́nimas
que incrementarán funcionalidad según se van conociendo nuevos requisitos. Mediante este modelo se pueden generar cada una de las aplicaciones de las que se compone el sistema obteniendo una arquitectura básica; posteriormente estos prototipos
se irán refinando obteniendo el sistema final.
Las ventajas que presenta este modelo frente a otros clásicos, como los basados en
cascadas, pasan por reducir el tiempo en el que se obtiene un producto tangible, facilitar la adaptación del producto a nuevos requisitos o facilitar el desarrollo cuando
los requisitos están definidos parcialmente.
No obstante este modelo también presenta desventajas, ya que no es posible acotar el
tiempo de ejecución del proyecto a priori y la calidad del mismo se puede ver afectada, ya que la mejora del prototipado puede limitarse a correcciones sin un diseño
previo.
Como se señala no es una metodologı́a en sı́ misma, sino que es un modelo de vida
software, y puede ser adoptado por distintas metodologı́as. Es decir, consta de las
fases tradicionales en la creación de software como son el análisis, diseño, implementación y las pruebas, pero es tarea de la metodologı́a el definir cómo se llevan a
la práctica estos mecanismos.
Proceso Unificado de Rational. Este modelo de desarrollo software es ampliamente acogido, respaldado por el OMG (Object Management Group), siendo un referente tanto
a nivel académico como a nivel comercial. Cabe destacar que asociado a este modelo se creó un lenguaje de modelado que actualmente es el más utilizado a cualquier
nivel; UML [UML07].
UML permite especificar un sistema software orientado a objetos por medio de diversos diagramas. Entre ellos destacan los diagramas de casos de uso, de clases y los de
16
CAPÍTULO 4. MÉTODO DE TRABAJO
secuencia.
El Proceso Unificado de Rational[JBR99] (en inglés RUP) está caracterizado por cuatro ideas principales.
Dirigido por casos de uso. El diseño del sistema empieza tras realizar el diagrama
de casos de uso obtenido a partir del análisis del sistema.
Centrado en la arquitectura. El proceso no esta pensado para una arquitectura única, por ello existen distintos modelos y vistas que permiten definir la arquitectura del sistema.
Iterativo. Este hecho implica que el desarrollo del sistema se lleva a cabo por medio
de iteraciones en las que se realizan fases especı́ficas de análisis de requisitos,
diseño, implementación y pruebas.
Incremental. El proceso permite un refinamiento sucesivo según se van conociendo
en detalle los requisitos del sistema.
Tras analizar las posibles alternativas, y debido a la naturaleza distribuida de la aplicación, se ha decidido utilizar el Proceso Unificado de Rational como modelo de desarrollo
de software.
El proyecto se puede realizar de forma cómoda por medio de este modelo ya que cada
subsistema puede abordarse en distintas iteraciones. A partir de un análisis inicial se obtiene
el diagrama de casos de uso del sistema. En sucesivas iteraciones se aborda el análisis y el
diseño de cada subsistema, permitiendo un refinamiento de forma incremental.
Sin embargo, a pesar de la solidez del modelo y de la naturaleza del proyecto, se deben
tener en cuenta factores de riesgo comunes a cualquier proyecto de ingenierı́a como son la
complejidad, el diseño y la calidad.
Teniendo en cuenta estos riesgos se van a seguir varias pautas para garantizar que los
resultados de cada iteración tienen la calidad suficiente, evitando de ese modo sufrir alteraciones demasiado significativas que impliquen rediseñar profundamente el sistema. A
continuación se describen dichas pautas.
Delimitar los objetivos finales. Se han acotado los objetivos tras realizar un análisis inicial
del proyecto y de las tecnologı́as a utilizar; de esta forma se consigue la capacidad de
establecer hitos para medir el estado en el que se encuentra el proyecto.
Realizar un diseño abierto de cada prototipo. El diseño del prototipo debe pensarse de
tal forma que permita crecer al mismo sin tener que modificar prácticamente lo que
ya está diseñado, es decir, debe permitir la ampliación de forma fácil y rápida.
Realizar pruebas automáticas. Cada uno de los prototipos diseñados debe tener una baterı́a de pruebas que permita detectar comportamientos erróneos durante las sucesivas
mejoras del sistema.
Para llevar a cabo estas medidas se han seguido diversos procedimientos que se detallan
a continuación.
4.1. METODOLOGÍA
17
Extracción de requisitos y elaboración de diagramas de casos de uso. Para poder delimitar el alcance del proyecto se han recabado los requisitos generales del proyecto,
elaborando un diagrama de casos de uso inicial. Posteriormente se han elaborado
diagramas de casos de uso especı́ficos para cada subsistema.
Elaboración de un plan de iteraciones. Teniendo en cuenta los requisitos del proyecto se
ha establecido un plan de iteraciones en el que establecen los objetivos básicos de cada
iteración. De este modo se centra la atención en solucionar cada objetivo delimitando
el alcance del trabajo en cada iteración.
Diseño de subsistemas. Cada subsistema se diseña de forma que facilite futuras mejoras,
para ello se crean diagramas de clases que se refinan en sucesivas iteraciones, facilitando de ese modo la comprensión del sistema a la hora de realizar modificaciones.
Utilización de un entorno de pruebas automático. La calidad de un proyecto está claramente influenciada por su fiabilidad, y para mantenerla es necesario contar con entorno de pruebas automático que permita comprobar de forma rápida y sencilla el
correcto funcionamiento de cada uno de sus componentes.
18
4.2.
Identificación de los requisitos funcionales del sistema.
Teniendo en cuenta los objetivos del proyecto y tras realizar un análisis inicial de la
tecnologı́a disponible se ha generado un diagrama de casos de uso (figura 4.1).
Figura 4.1: Diagrama de Casos de Uso. Visión general del sistema
Cada uno de estos casos de uso engloba una parte especı́fica del proyecto que debe ser
analizada en profundidad en sucesivas iteraciones. A continuación se describe cada uno de
los casos de uso, comenzando de éste modo la delimitación del alcance del proyecto.
Entrar en el Sistema. El primer caso de uso a considerar conlleva dos objetivos principales.
Suministrar la aplicación a los dispositivos móviles. Los visitantes del museo deben tener dispositivos adecuados para realizar la visita, es decir, sus dispositivos
deben dar soporte a las tecnologı́as Bluetooth [Blu04] y WiFi [WiF07]. Una vez
que entren en el edificio se les debe ofrecer la posibilidad de recibir la aplicación
a través de bluetooth o WiFi.
Entrada en el sistema. Una vez recibida la aplicación se deben establecer los parámetros iniciales para proceder a la personalización de la visita. Estos parámetros
son el tiempo que se desea invertir en la visita, el público al que se dirige la visita
y la deficiencia, en caso de que sea necesario, que padece el dicho visitante.
Aproximación a un punto del museo. Tras la entrada del visitante al sistema éste debe
reaccionar ante los eventos de aproximación. Para ello el sistema debe ser capaz de
trasladar este evento a los subsistemas que lo necesiten. Además se debe informar al
dispositivo móvil sobre las alternativas de las que dispone por el hecho de aproximarse al punto.
4.2. IDENTIFICACIÓN DE LOS REQUISITOS FUNCIONALES DEL SISTEMA.
19
Solicitar/Recibir Medio. Una de las posibles alternativas que el sistema ofrece al visitante
es la posibilidad de consultar documentos en distintos medios. En concreto el sistema permite consultar medios textuales, de audio y de vı́deo. Los archivos textuales
pueden ser enviados de forma directa sin necesidad de realizar transmisión en flujo
(streaming), sin embargo los medios de audio y vı́deo deben servirse por medio de
streaming. Esta consideración viene motivada por el tamaño de dichos medios ya que
éste tipo de medios son significativamente mayores y ralentizarı́an la visita.
Solicitar/Recibir Ruta. La otra alternativa que el sistema ofrece al visitante es la posibilidad de solicitar información para llegar a un determinado punto del museo. El sistema
debe dar cabida a este requisito en tiempo real, por medio de indicaciones sencillas y
directas.
Transición entre puntos del museo. En este caso de uso se deben considerar diferentes
aspectos ya que se encarga de manejar la información asociada al visitante según éste
se mueve por el museo. En concreto se debe tener en cuenta si el visitante está siguiendo una ruta o si se trata de una aproximación sencilla. En caso de ser una ruta
se debe diferenciar si se ha llegado al destino o no, ya que los métodos de actuación
son diferentes en cada caso.
Salir del Sistema. El último caso de uso del Visitante es la salida del sistema. En éste caso
de uso se debe atender a la actualización de las estadı́sticas del museo.
Obtener Informes. Por medio de este caso de uso se quiere mostrar que este sistema es
capaz de recolectar información puntual y convertirla en información, que de soporte
a la ayuda en la toma de decisiones, por medio de mecanismos sencillos. En concreto
se obtendrán informes sobre el tiempo invertido en las visitas, el tiempo invertido en
la visita a objetos, sobre los documentos y objetos más consultados y sobre la ruta
preferida por los visitantes.
Supervisar Museo. El sistema debe mostrar la posición de los visitantes en el museo de
forma gráfica y en tiempo real.
Gestionar Ubicaciones. Para manejar la información del sistema relativa a la ubicación de
los distintos elementos se debe suministrar una herramienta gráfica que permita este
manejo de forma clara y sencilla.
Gestionar Medios. Del mismo modo que se la información relativa a la ubicación se debe
tratar la información relativa a los distintos medios, permitiendo su manejo por medio
de una herramienta gráfica clara e intuitiva.
20
4.3.
Planificación
Para delimitar el alcance del proyecto se ha creado una planificación por medio de iteraciones en la que se fijan los objetivos que se deben cumplir en cada iteración, de este modo
se puede acotar el tiempo de ejecución de cada parte del proyecto, centralizando la atención
de cada iteración en cumplir unos objetivos concretos.
Conviene destacar que en cada iteración se lleva a cabo un análisis de las tecnologı́as
existentes necesarias para alcanzar los objetivos fijados. Gracias a este análisis se puede
elegir la tecnologı́a mas adecuada para cada propósito.
A continuación se detalla la planificación por medio de la descripción de cada iteración.
Iteración 0. Definición de la arquitectura base.
Analizando los casos de uso podemos observar que el caso de uso central y que va a
condicionar la arquitectura del sistema es el que determina cómo interactúa el sistema
con el visitante. Este caso de uso es “Aproximación a un punto del museo”.
Tras estudiar el caso de uso se han detectado los siguientes roles en el sistema:
• Servicio de localización Bluetooth[Blu04].
Se encarga de realizar un escaneo periódico en busca de dispositivos bluetooth,
publicando en un canal los dispositivos encontrados junto con su posición.
• Servidor.
Objeto encargado de recibir los eventos de localización de dispositivos moviles
y de generar un listado de documentos relaccionados con la posición de dicho
dispositivo móvil.
• Servicio de Persistencia.
Servicio que permite almacenar y recuperar la información del sistema.
Este servicio se encarga de almacenar los documentos y las indicaciones que el
sistema va generando dependiendo del contexto (posición, documentos leı́dos,
objetos visitados).
Los objetivos para esta iteración son los siguientes.
• Generar la arquitectura middleware básica.
Esta arquitectura debe dar soporte a los agentes detectados en el análisis por
medio de la definición de los archivos Slice necesarios para el intercambio de
información entre dichos agentes.
• Creación de los servicios detectados.
Diseño rápido e implementación de los servicios detectados.
• Establecimiento de la arquitectura de pruebas.
Diseño de la arquitectura de pruebas y de la organización del código para poder
distribuirlo de forma separada a cada parte del sistema.
4.3. PLANIFICACIÓN
21
Iteración 1. Inteligencia del sistema.
En esta iteración se afrontan los casos de uso “Recibir Ruta”, “Solicitar Ruta” y
“Transición entre puntos del museo”. Esto implica modificar adecuadamente el Servidor para que sea capaz de, a partir de unos datos iniciales y el contexto actual del
visitante, generar la ruta mas acorde a dicho visitante. Además debe ser capaz de discernir entre los puntos del museo con los que interactúa el visitante, ası́ como el tipo
de interacción que realiza con el dicho punto.
Los objetivos que se desprenden de esta iteración son los siguientes.
• Revisión del diseño del Servidor.
Se debe adaptar el Servidor para que sea capaz de almacenar el estado básico del
visitante (elementos visitados, información inicial, etc). Gracias a este estado y
a la información almacenada en la persistencia del museo debe ser capaz de
generar rutas básicas.
Además el Servidor debe dar soporte a la distribución de medios textuales.
• Creación de la aplicación del dispositivo móvil.
El dispositivo móvil debe dar soporte a la recepción y visualización de los medios textuales, de las rutas y los listados de objetos y documentos.
• Actualización de la baterı́a de pruebas.
Las pruebas existentes se deber actualizar, del mismo modo que en la iteración
anterior se deben generar nuevas pruebas que permitan detectar fallos de integración entre iteraciones.
Iteración 2. Herramienta de Gestión.
Los casos de usos que abarca esta iteración vienen definidos por parte del actor “Administrador”, y en concreto se deben solucionar los casos de uso “Gestionar Ubicaciones” y “Gestionar Medios”. Del análisis de estos requisitos podemos observar
claramente que hay un nuevo rol que debe ser cubierto.
• Aplicación de Gestión-Administración.
Esta aplicación es la herramienta que permite al administrador del sistema interactuar con el mismo. Gracias a esta herramienta se pueden actualizar los datos
del sistema, es decir, se puede interactuar con la capa de persistencia del sistema.
Teniendo en cuenta este nuevo rol y los casos de uso a los que se deben dar soporte
en esta iteración se establecen los siguientes objetivos.
• Creación de la herramienta de gestión-administración.
Se diseñara la herramienta (sin olvidar que posteriormente será modificada) que
de soporte a la entrada,salida y modificación de datos de la capa de persistencia.
• Creación de una baterı́a de pruebas para la aplicación.
Teniendo en cuenta que se trata de una herramienta gráfica, se generaran pruebas
que comprueben el correcto funcionamiento de los componentes que proporcionan funcionalidad a la herramienta.
22
Iteración 3. Cálculo de rutas.
El cálculo de rutas, debido a su complejidad, es necesario abordarlo en una iteración
especı́fica. En concreto en esta iteración se abordan los casos de uso “Solicitar/Recibir ruta” y “Transición entre puntos del museo”. Para ello se deben satisfacer los
siguientes objetivos.
• Creación del sistema de rutas.
Teniendo en cuenta la complejidad que conlleva este tipo de sistemas se debe
crear un subsistema, independiente del servidor principal, que calcule las rutas
necesarias para el sistema.
Iteración 4. Ampliación de la herramienta de gestión.
En esta iteración se atenderá al caso de uso “Supervisar Museo”. Para ello se ampliará la herramienta de gestión dando soporte a la visualización del museo en tiempo
real. Teniendo en cuenta esta consideración a continuación se muestra el objetivo de
esta iteración.
• Creación del panel de localización.
Se debe ampliar la herramienta de gestión por medio de un panel en el que se
muestre un mapa del museo en el que se reflejen los distintos puntos del museo
ası́ cómo la ubicación de los visitantes. Todo ello debe reflejarse en tiempo real.
Iteración 5. Servidor de Medios.
Analizando el caso de uso “Solicitar Medio” se ha detectado la necesidad de un nuevo
rol en sistema, el Servidor de Medios.
• Servidor de medios.
Es el encargado de ofrecer los distintos medios (tanto de audio, vı́deo o texto) a
los visitantes.
Los objetivos de esta iteración son los siguientes.
• Creación del servidor de medios.
Se debe crear el servidor teniendo en cuenta que debe ser accesible por los
visitantes, y sin olvidar que un funcionamiento deficiente del mismo repercute
directamente sobre la aceptación del sistema por dichos visitantes.
• Actualización del servidor.
Se debe actualizar el Servidor principal para que deje de servir medios y delegue
esta responsabilidad al Servidor de Medios.
• Creación de baterı́a de pruebas.
Se crearán, dentro de lo posible, pruebas que garanticen el correcto funcionamiento del Servidor de Medios.
4.3. PLANIFICACIÓN
23
Iteración 6. Obtención de informes.
Esta iteración atiende al caso de uso “Obtener Informes”, cuya finalidad es crear los
mecanismos necesarios para obtener información del sistema que pueda servir para
la ayuda a la toma de decisiones.
Teniendo en cuenta la finalidad de esta iteración se establecen los siguientes objetivos.
• Ampliar la herramienta de Gestión-Administración.
Ampliar la herramienta para que permita obtener gráficas estadı́sticas. En concreto el recorrido más usual, el tiempo medio por visita, por objeto visitado y
los objetos y documentos más consultados.
• Creación del sistema encargado de recopilar estadı́sticas.
Se debe implementar el sistema que almacene y administre de forma persistente
las estadı́sticas necesarias para la obtención de informes.
• Creación de baterı́a de pruebas.
Se generará una baterı́a de pruebas que permita comprobar el correcto funcionamiento de las clases encargadas de generar los informes estadı́sticos.
Iteración 7. Distribución de la aplicación del dispositivo móvil.
Para que los visitantes puedan interactuar con el sistema es necesario que dispongan
de la aplicación para el dispositivo móvil. El método de instalación debe ser lo más
simple posible, por lo que se debe hacer llegar la aplicación de forma prácticamente
transparente al usuario.
Teniendo esto en cuenta se establece el siguiente objetivo.
• Creación de un sistema de envı́o selectivo de archivos.
Se debe crear un sistema que permita enviar archivos vı́a Bluetooth de forma
selectiva a dispositivos móviles.
Iteración 8. Despliegue del sistema.
Una vez construido y probado el sistema en el entorno de desarrollo se debe poner en
funcionamiento sobre un escenario real. Esto motiva el siguiente objetivo.
• Puesta en funcionamiento del sistema en un entorno real.
24
4.4.
Iteración 0. Definición de la arquitectura base.
En esta iteración se debe crear una arquitectura robusta, que de soporte al sistema incluso si éste sufre alteraciones de diseño, por ello se deben elegir cuidadosamente los mecanismos y herramientas a utilizar para la concepción del mismo.
4.4.1.
Análisis.
La etapa de análisis de esta iteración se centra en la selección de los mecanismos y
herramientas principales que se necesitan para la elaboración del proyecto. Es decir, se
realiza una evaluación de las diversas tecnologı́as existentes, eligiendo las más adecuadas
para el propósito del proyecto.
Estos mecanismos se pueden englobar en tres grupos principales: la elección del middleware, de los lenguajes de programación y del entorno de pruebas.
Existe la posibilidad de realizar el proyecto sin utilizar un middleware. Sin embargo esto
conlleva una enorme serie de desventajas que implican realizar el trabajo del middleware
por vı́a propia con el riesgo que conlleva; la finalidad del proyecto no es crear un sistema
experto para el manejo de comunicaciones, por lo que intentar crear un sistema especı́fico
de estas caracterı́sticas aumenta las posibilidades de fracaso del proyecto drásticamente.
4.4.1.1.
Elección del Middleware.
La distribución de las distintas aplicaciones y su eficiencia en las comunicaciones es
crucial en este sistema, por ello la elección del middleware es una tarea crı́tica que debe
realizarse tras un estudio previo.
En el contexto del proyecto se requiere un middleware adecuado para sistemas heterogéneos, por lo que se ha recurrido a estudiar y comparar dos alternativas actuales; CORBA
[COR08b] [COR08a] [CCM08] e Ice[MH08].
CORBA
CORBA (del inglés Common Object Request Broker Architecture) es un estándar,
definido por el OMG (Object Management Group), que establece una plataforma de
desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo
un paradigma orientado a objetos.
Las caracterı́sticas principales de CORBA se enumeran a continuación [HV02].
Lenguaje de definición de interfaces (Interface Definition Language, IDL) del OMG.
CORBA utiliza IDL para generar las interfaces y los servicios que los objetos
que las implementan ofrecen al resto de objetos. Cabe destacar que CORBA no
soporta la definición de clases en IDL, lo que quiere decir que no se permite
pasar instancias de clases como argumento.
4.4. ITERACIÓN 0. DEFINICIÓN DE LA ARQUITECTURA BASE.
25
Mapping de lenguajes. CORBA ofrece compiladores de IDL a varios lenguajes de
programación, en concreto para Ada, C, C++, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I y Python.
Object Request Broker (ORB). “El Object Request Broker (en español intermediario de petición de objetos) ayuda a un cliente a invocar un método de un objeto.
Ello conlleva localizar el objeto, activar el objeto si fuera necesario y después
comunicar la petición del cliente a hacia el objeto, que la realiza y la responde
al cliente.” [HV02][página 638]
Adaptadores de objetos. Sirven de puente entre los objetos con interfaces IDL y
las interfaces del lenguaje de programación de las clases sirviente. Para llevar
a cabo esta labor tiene tres cometidos; crear referencias a objetos remotos para
los objetos CORBA, atender cada invocación remota y derivarla al sirviente
apropiado y activar objetos.[HV02][página 645]
Protocolo Inter-ORB. Protocolo que define estándares para permitir la comunicación entre implementaciones realizadas por desarrolladores diferentes. Cabe
destacar que define una representación de datos interna (CDR), formatos especı́ficos para los mensajes de un protocolo petición-respuesta y un estándar
para las referencias a objetos remotos.[HV02][página 638]
ZeroC Ice
Ice, del inglés Internet Communications Engine, es un middleware libre con un diseño relativamente similar a CORBA. A continuación se muestran sus caracterı́sticas
principales.
Semántica orientada a objetos. Ice está completamente diseñado e implementado
siguiendo el paradigma de la orientación a objetos.
Lenguaje de especificación para Ice, Slice (del inglés Specification Language for Ice).
Slice permite definir contratos entre el cliente y el servidor. Es independiente del
lenguaje de programación utilizado, ya que por medio de la compilación de los
archivos generado en este lenguaje se obtienen las APIs especı́ficas para las interfaces y tipos definidos en dichos archivos.
Servicios Ice. Ice proporciona una sofisticada plataforma para el desarrollo de aplicaciones cliente-servidor, sin embargo en las necesidades reales en este tipo de
sistemas son mayores. Se necesitan distribuir aplicaciones, distribuir eventos
ası́ncronos, configurar aplicaciones, etc.
Para solucionar estas necesidades Ice proporciona seis servicios.
Freeeze y FreezeScript. Proporcionan soluciones para el almacenamiento persistente de objetos.
IceGrid. Es una implementación del servicio de localización Ice que permite
localizar objetos, registrar servidores (con activación manual o bajo demanda), configurar aplicaciones, realizar balanceo de carga, etc.
IceBox. Es una aplicación servidora que permite manejar varios componentes
de aplicación.
26
IceStorm. Es un servicio de publicación-subscripción que permite desacoplar
clientes y servidores.
IcePatch2. Se trata del servicio que da soporte a la distribución de actualizaciones de las aplicaciones.
Glacier2. Es servicio de firewall transversal de Ice. Permite a los cliente y servidores la comunicación segura a través de un firewall sin comprometer la
seguridad.
Soporte para múltiples interfaces. Los objetos Ice pueden implementar varias interfaces. Este hecho permite un alto grado de flexibilidad ya que es posible envolver aplicaciones ya desarrolladas con nuevas capas que aumenten la funcionalidad de la aplicación.
Independencia de la máquina, del lenguaje, de la implementación y del sistema operativo.
Ice permite abstraer al programador de todo este tipo de problemas y consideraciones permitiendo conectar clientes, escritos en multitud de lenguajes y sobre
distintos sistemas operativos, a servidores escritos en lenguajes distintos y sobre
diferentes sistemas operativos.
Independencia del transporte. Ice ofrece TCP/IP y UDP como protocolos de transporte. Cabe destacar que ni clientes ni servidores se ven afectados por el protocolo de transporte, es decir, es transparente a ellos y solamente cambiando el
archivo de configuración se puede cambiar el protocolo sobre el que se envı́a la
información.
Transparencia y Servicio de Localización. Ice se encarga en tiempo de ejecución
de la localización de los objetos y de los mecanismos de transporte subyacentes.
Por medio de IceGrid se pueden organizar servidores para lanzarlos bajo demanda, es decir, que comience su ejecución cuando sus servicios son requeridos
por un cliente. Los servidores pueden migrar de ubicación fı́sica de forma transparente al resto de componentes del sistema, incluidos los clientes.
Seguridad. Las comunicaciones entre cliente y servidor se pueden asegurar mediante encriptación SSL, de forma transparente para la aplicación. Además por medio de Glacier2 se puede combinar esta tecnologı́a con los firewalls.
Persistencia integrada. Mediante Freeze se puede obtener almacenamiento persistente de objetos de forma fácil. Ice utiliza para ello la base de datos de alto
rendimiento Berkeley DB[Sle01].
Disponibilidad del código fuente. Éste hecho permite observar cómo esta implementada la plataforma o portarla a un nuevo sistema operativo, etc.
Una vez estudiados ambos middlewares se realiza la comparación entre ellos, para lo
que se tienen en cuenta tres aspectos fundamentales.
Diferencias en el Modelo de Objetos.
• Type System.
27
Un objeto Ice, al igual en CORBA, tiene al menos una interfaz principal. Mientras que en CORBA este objeto únicamente puede tener esa interfaz en Ice puede
tener varias de ellas con el mismo identificador. Esto dota de gran flexibilidad
arquitectural a Ice frente a CORBA.
Gracias a este mecanismo en Ice es fácil extender la funcionalidad del servidor sin tener que modificar los clientes antiguos. Este mismo caso en CORBA
implica rediseñar y reimplementar el cliente.
• Proxy Semantics.
En Ice los clientes pueden crear proxies sin necesidad de otros componentes del
sistema. En CORBA se delega esta responsabilidad en distintos variantes. Es decir existen distintas alternativas para soportar esta responsabilidad; en concreto
son IOR, corbaloc y corbaname.
La forma de manejar los proxies que tiene Ice presenta varias ventajas frente a
CORBA.
◦ No necesita la intervención de un agente externo proveedor de nombres
para la creación de proxies.
◦ Los clientes pueden arrancar por si mismos sin necesidad de servicios de
arranque automático.
◦ No se necesitan diferentes codificaciones a la hora de representar el proxy,
una representación legible para humanos es suficiente.
• Identidad de Objetos.
El modelo de objetos Ice asume que las identidades de objetos son únicas y universales, lo que permite migrar los servidores y combinar objetos sin colisiones.
Diferencias en la plataforma de soporte.
CORBA, dependiendo de la especificación elegida, proporciona muchos de los servicios ofrecidos por Ice. Sin embargo el problema que se presenta es que es prácticamente imposible obtener una implementación que satisfaga todos ellos.
Además algunas caracterı́sticas que Ice ofrece de forma directa no tienen equivalencia
en CORBA, como las que se muestran a continuación.
• Asynchronous Method Dispatch (AMD).
La API de CORBA no proporciona ningún mecanismo para suspender procesos
y operaciones en el servidor, liberar el hilo de control, etc.
• Seguridad.
A pesar de que en CORBA existen muchas páginas de especificaciones relativas
a la seguridad la mayorı́a de ellas carecen de implementación, además CORBA
no ofrece soluciones prácticas que permitan coexistir al middleware con firewalls.
• Caracterı́sticas de Protocolos.
El protocolo Ice ofrece soporte bidireccional. Este hecho es requisito fundamental para permitir callbacks a través de firewalls. Además Ice permite usar UDP
y TCP, mientras que CORBA solo permite el uso de TCP.
28
Otra caracterı́stica importante del procolo de Ice es que permite que todos los mensajes y los datos sean totalmente encapsulados en el cable. Esto permite a Ice implementar servicios como IceStorm de forma extremadamente eficiente ya que para
reenviar datos no es necesario realizar unmarshaling y remarshaling.
Diferencias en la complejidad.
La plataforma CORBA es grande y compleja. Esto se debe en parte a su estandarización ya que debe acomodarse a las condiciones de todas las partes interesadas, lo que
conlleva implementaciones grandes e ineficientes.
En contraste a CORBA, Ice es primero y sobre todo una plataforma simple. Los
servicios que ofrece Ice permiten obtener todo lo necesario para el manejo de sistema
distribuido de la forma mas simple posible.
4.4.1.2.
Elección del entorno de pruebas.
La calidad de un proyecto viene fuertemente influenciada por su fiabilidad, y esto se
consigue por medio de diversos factores cómo un buen diseño, una implementación eficiente y una exhaustiva baterı́a de pruebas.
Para llevar a cabo la elaboración de la baterı́a de pruebas se han estudiado distintas
alternativas, pero la gran mayorı́a de herramientas para realizar pruebas se centran en pruebas unitarias. Sin embargo la naturaleza del proyecto implica realizar pruebas mucho mas
complejas, ya que existen varias dependencias entre los distintos elementos del sistema.
Teniendo en cuenta la complejidad de estas pruebas se ha elegido la herramienta Tester1
desarrollada por el grupo ARCO en simbiosis con la herramienta GNU Make [SMS06].
Tester es un script realizado en Python [Ros95] que permite ejecutar programas o scripts
de forma ordenada y jerárquica, capturando el flujo de salida e interpretando los resultados.
Para obtener un entorno de pruebas consistente se deben aislar, de forma fı́sica y lógica,
cada uno de los subsistemas y crear pruebas especı́ficas para cada uno. Esto se consigue
por medio de una separación utilizando un directorio para cada subsistema. A su vez cada
subsistema debe contener un directorio que albergue las pruebas que debe superar dicho
subsistema. De este modo se contempla una arquitectura jerárquica de pruebas automatizable por medio de la herramienta GNU Make[SMS06].
4.4.1.3.
Tecnologı́as para desarrollo de aplicaciones de escritorio.
Siguiendo la filosofı́a subyacente del proyecto se han buscado alternativas libres que
permitan crear aplicaciones, con y sin interfaz gráfica, que soporten la complejidad del
sistema. Teniendo esto en cuenta se descartan entornos de desarrollo como el framework de
Apple ya que sólo funcionarı́a en sistemas propietarios.
Cabe destacar que el sistema necesita soporte de hilos ası́ cómo velocidad de ejecución
y soporte para interfaces gráficas avanzadas. A continuación se realiza un estudio de varias
1
Tester. David Villa Alises y Cleto Martı́n Angelina
29
alternativas posibles teniendo en cuenta estas consideraciones.
Java. [AGH05]
Lenguaje Orientado a Objetos cuya caracterı́stica principal es la multiplataforma. Esto lo consigue por medio de la Java Virtual Machine especı́fica para cada sistema
operativo. Dicha máquina virtual recibe bytecode generado por el compilador javac,
siendo la encargada de generar el archivo binario que finalmente ejecuta.
El soporte multiplataforma que ofrece este lenguaje es un factor a tener en cuenta en el
sistema. En concreto gracias a la utilización de este lenguaje se consigue que algunas
partes del sistema puedan ubicarse en prácticamente cualquier servidor, aumentando
las posibilidades de integración del sistema distintos en equipos sin necesidad de
cambiar su sistema operativo.
C++. [Str86]
Este lenguaje es la evolución de C en la filosofı́a de la orientación a objetos, y del
mismo modo que C se trata de un lenguaje que se compila para máquinas especı́ficas.
Debido a ello no tenemos la flexibilidad multiplataforma que ofrecen otros lenguajes,
sin embargo este hecho favorece a la velocidad de ejecución de los binarios generados
a partir del código.
Gracias a esta evolución se ha conseguido que C++ sea más mantenible que C. Para
ello utiliza los mecanismos clásicos de la orientación a objetos como clases abstractas
y herencia (simple y múltiple). Además amplia los lı́mites de C gracias a la sobrecarga
de operadores o las plantillas, permitiendo también utilizar C del modo tradicional.
Teniendo estas consideraciones en cuenta se contará con este lenguaje para diseñar
partes crı́ticas del sistema, entendiendo como crı́ticas aquellas que necesiten la mayor
rapidez posible para que el resto del sistema no tenga que esperar.
Python. [Ros95]
Se trata de un lenguaje orientado a objetos cuyas caracterı́sticas fundamentales son
su simplicidad y ser un lenguaje interpretado. Hay que tener en cuenta que pesar
de ser un lenguaje interpretado la velocidad es aceptable para construir este sistema.
Además cuenta con la ventaja de que se pueden construir prototipos rápidamente, con
mucho menos esfuerzo que con otros lenguajes, lo que permite rediseñar el sistema
(en caso de ser necesario) de forma ágil.
Por todo ello es el lenguaje dominante en el proyecto.
4.4.2.
Diseño.
Como punto de partida del proyecto se debe crear la infraestructura que se muestra en la
figura 4.2, y para ello es necesario definir las interfaces Slice que den soporte a todos estos
subsistemas.
Para conseguir esta infraestructura se han diseñado dos diagramas de casos de uso que
contemplan el sistema encargado de la persistencia del museo, MuseumPersistence, que se
30
Figura 4.2: Iteración 0. Primera aproximación
puede ver en la figura 4.5 y el diagrama que profundiza en el caso de uso “Aproximación a
un punto del museo” (figura 4.3).
Figura 4.3: Diagrama de casos de uso (Iteración 0)
También ha sido necesario establecer cómo se relacionan estos subsistemas para llevar a cabo los objetivos de esta iteración. Para representar ésta relación se ha utilizado un
diagrama de secuencia que se puede ver en la figura 4.4.
Siguiendo estos diagramas se han definido tres archivos Slice que se muestran a continuación.
31
Figura 4.4: Diagrama de secuencia (Iteración 0)
MobileDevManager.ice En este archivo se definen tipos e interfaces que utilizan los dispositivos móviles y el servidor. En concreto se da soporte al envı́o/recepción de peticiones de ruta e información ası́ como a la administración de visitantes (entrada/salida).
Conviene destacar el significado de las distintas interfaces definidas en este archivo.
En primer lugar se define la interfaz InfomationReceiver que será implementada por
la aplicación de los dispositivos móviles para interactuar con el sistema por medio de
las operaciones de notificación.
32
Listado 4.1: MobileDevManager.ice
interface InformationReceiver {
v o i d n o t i f y L i s t ( s t r i n g macBTMobileDev , L i s t l i s t C o m p l e t e ) ;
v o i d n o t i f y C h a n g e s ( s t r i n g macBTMobileDev , Changes l i s t C h a n g e s ) ;
v o i d n o t i f y L i s t E l e m e n t ( s t r i n g macBTMobileDev , L i s t E l e m e n t e l e m e n t ) ;
v o i d r e m o v e L i s t E l e m e n t ( s t r i n g macBTMobileDev , L i s t E l e m e n t e l e m e n t ) ;
v o i d n o t i f y E l e m e n t ( s t r i n g macBTMobileDev , I n f o r m a t i o n E l e m e n t
infoElement ) ;
v o i d n o t i f y R o u t e ( s t r i n g macBTMobileDev , R o u t e C o m p l e t e r o u t e ) ;
};
A continuación se define la interfaz de administración de dispositivos móviles Admin
que permite subscribir y dar de baja a dispositivos móviles en el canal de administración.
i n t e r f a c e Admin {
void a d d L i s t e n e r ( I n f o r m a t i o n R e c e i v e r ∗ l i s t e n e r ) ;
void removeListener ( I n f o r m a t i o n R e c e i v e r ∗ l i s t e n e r ) ;
};
Por último se presenta la interfaz Server que sera implementada por el servidor permitiendo a los dispositivos móviles interactuar con el sistema y permitiendo a su vez
al servidor la administración de dichos dispositivos.
i n t e r f a c e S e r v e r e x t e n d s Admin {
v o i d g e t E l e m e n t ( s t r i n g macBTMobileDev , L i s t E l e m e n t e l e m e n t ) ;
v o i d s t o p E l e m e n t ( s t r i n g macBTMobileDev , L i s t E l e m e n t e l e m e n t ) ;
v o i d v i s i t I n f o r m a t i o n ( s t r i n g macBTMobileDev ,
i n t time ,
AVISMI : : V i s i t o r T y p e s : : A u d i e n c e a u d i e n c e ,
AVISMI : : V i s i t o r T y p e s : : D i s a b i l i t y d i s a b i l i t y ,
AVISMI : : V i s i t o r T y p e s : : Language l a n g ) ;
v o i d v i s i t E x i t ( s t r i n g macBTMobileDev ) ;
};
VisitorTypes.ice La definición de tipos que afectan a los visitantes se aborda en este archivo. En concreto se representan los tipos que permiten representar aspectos cómo el
público, las deficiencias y el idioma.
Listado 4.4: VisitorTypes.ice
module AVISMI {
module V i s i t o r T y p e s {
enum A u d i e n c e { C h i l d , A d u l t } ;
enum D i s a b i l i t y { Noone , Deaf , B l i n d } ;
enum Language { ES , EN , DE , FR , JA , RU, IT , CH } ;
s e q u e n c e <D i s a b i l i t y > D i s a b i l i t y S e q ;
s e q u e n c e <Language> LanguageSeq ;
};
};
33
Persistence.ice Este archivo contiene la definición de los objetos persistentes del sistema
ası́ cómo las interfaces que permiten manejar la persistencia. Para elaborar esta definición se ha tenido en cuenta el diagrama de casos de uso relativo a este sistema que
se muestra en la figura 4.5
Figura 4.5: Diagrama de casos de uso del MuseumPersistence (iteración 0)
El sistema almacena cuatro objetos persistentes.
Point. Representa cada punto de información relevante para el sistema. Nótese que
en un punto de información pueden convivir varios objetos del museo. Es decir,
un punto de información puede representar un pequeño dispositivo con conexión a la red que informa de la presencia de dispositivos móviles cercanos, pero
también puede representar una escalera, un ascensor, etc.
Listado 4.5: Persistence.ice
enum DocTypes { Text , Audio , Video } ;
struct Point {
/ / P a r a m e t r o s o b l i g a t o r i o s en l o s a t r i b u t o s
/ / id = i n t
// description = str
/ / type = [ interest , information , stair , . . . . ]
//
S I i n f o r m a t i o n => r a d i u s = d o u b l e
//
=> o b j e c t s > 0
H e s p e r i a : : OpenLS : : P o i n t O f I n t e r e s t p o i ;
[ ” uml : m u l t i : 0 . . n ” ] I c e : : S t r i n g S e q o b j e c t s ;
};
MuseumObject. Representa un objeto del museo (cuadro, escultura, etc).
34
s t r u c t MuseumObject {
s t r i n g id ;
int infPointId ;
string description ;
int importance ;
int visitTime ;
[ ” java : type : java . u t i l . Vector ” ] Ice : : StringSeq o b j e c t s ;
int numVisits ;
};
Document. Representa un medio (de texto, audio o vı́deo) de información del museo.
s t r u c t Document {
s t r i n g id ;
s t r i n g name ;
string description ;
s t r i n g URL ;
DocTypes t y p e ;
AVISMI : : V i s i t o r T y p e s : : Language l a n g ;
int importance ;
AVISMI : : V i s i t o r T y p e s : : A u d i e n c e a u d i e n c e ;
AVISMI : : V i s i t o r T y p e s : : D i s a b i l i t y d i s a b i l i t y ;
int visitTime ;
int numVisits ;
};
RelationObjectDocs. Por medio de este objeto (listado 4.8)se representa la relación
entre un objeto y los documentos que tienen relevancia con respecto al mismo.
struct RelationObjectDocs {
string objectId ;
[ ” j a v a : type : j a v a . u t i l . Vector ” ] I c e : : S t r i n g S e q documents ;
};
Se han creado dos interfaces que permiten manejar el servicio de persistencia teniendo en cuenta la visión de administración. Es decir, una interfaz permite la consulta de
información mientras que la otra permite realizar cambios que afecten a la consistencia del sistema.
PersistentServices. Esta interfaz(listado 4.9) define métodos para obtener información del sistema, pero no permite realizar cambios sobre los objetos persistentes.
35
interface PersistentServices {
Points
Points
Point
Points
Points
Points
getPoints () ;
getNPoints ( int n ) ;
getPoint ( int id ) ;
getPointsByType ( s t r i n g type , s t r i n g value ) ;
g e t P o i n t s B y P o s ( double x , double y , double z ) ;
getPointsByPosAndType ( double x , double y , double z ,
s t r i n g type , s t r i n g
value ) ;
MuseumObject g e t M u s e u m O b j e c t ( s t r i n g o b j I d ) ;
MuseumObjects getNMuseumObjects ( i n t n ) ;
MuseumObjects g e t M u s e u m O b j e c t s ( ) ;
Document g e t D o c u m e n t ( s t r i n g d o c I d ) ;
Documents g e t D o c u m e n t s ( ) ;
Documents getNDocuments ( i n t n ) ;
v o i d updateDocumentURL ( s t r i n g d o c I d , s t r i n g URL) ;
Relations getRelationsObjectDocs () ;
Relations getNRelationsObjectDocs ( int n ) ;
RelationObjectDocs getRelationObjectDocs ( s t r i n g idObj ) ;
};
AdminPersistentServices. AdminPersistentServices hereda de la interfaz PersistentServices y además permite realizar cambios (eliminar, añadir) sobre los objetos
del sistema.
i n t e r f a c e AdminPersistentServices extends P er si ste nt Se rvi ce s {
void addPoint ( P o i n t a P o i n t ) ;
void removePoint ( i n t i d P o i n t ) ;
v o i d addMuseumObject ( MuseumObject museumObj ) ;
v o i d removeMuseumObject ( s t r i n g o b j I d ) ;
v o i d addDocument ( Document doc ) ;
v o i d removeDocument ( s t r i n g d o c I d ) ;
void addRelationObjectDocs ( RelationObjectDocs r e l a t i o n O b j D o c s ) ;
void removeRelationObjectDocs ( s t r i n g r e l I d ) ;
};
También se muestra parte del Slice, perteneciente al proyecto Hesperia , que se utiliza
para la publicación de eventos de localización.
Hesperia.MLP.Location.ice. El agente de localización bluetooth utiliza la interfaz LocationListener para publicar/recibir eventos de localización. Además debe implementar
la interfaz LocationAdmin consiguiendo con ello administrar el canal de eventos de
localización.
36
Listado 4.11: Location.ice
/ / Asynchronous Report
interface LocationListener {
[ ” n o n m u t a t i n g ” , ” cpp : c o n s t ” ]
i d e m p o t e n t void l o c a t e R e p o r t ( P o s i t i o n pos ) ;
i d e m p o t e n t void l o c a t e S e q R e p o r t ( P o s i t i o n S e q pos ) ;
i d e m p o t e n t void l o c a t e R a n g e R e p o r t ( P o s i t i o n S e q pos ) ;
};
/ / A s y n c h r o n o u s Admin s e r v i c e
i n t e r f a c e LocationAdmin e x t e n d s L o c a t i o n D a t a P r o v i d e r {
void a d d L i s t e n e r ( L o c a t i o n L i s t e n e r ∗ l i s t e n e r ) ;
void removeListener ( L o c a t i o n L i s t e n e r ∗ l i s t e n e r ) ;
};
4.4.3.
Implementación.
El diseño del subsistema encargado de la persistencia, MuseumPersistence, viene condicionado por el diseño de los archivos Slice mencionados anteriormente.
El MuseumPersistence está implementado en Java. Esta decisión se debe a que a pesar
de ser una parte importante del sistema no es crı́tica con respecto a la velocidad de respuesta
y puede ser interesante tener soporte multiplataforma para este subsistema. Además debido
a que utiliza la tecnologı́a Freeze de Ice, para el almacenamiento de la información, este
servicio debe escribirse en Java o en C++.
El diseño del MuseumPersistence se ve reflejado en la figura 4.6.
Figura 4.6: Diagrama de clases reducido del MuseumPersistence (Iteración 0)
Como se puede apreciar se ha prescindido de representar los métodos y la mayorı́a de
37
los atributos en las clases del diagrama para mejorar la legibilidad. Además los métodos de
las interfaces se han mostrado anteriormente en la definición de los archivos Slice.
Básicamente este subsistema implementa la interfaz AdminPersistentServices por medio
de la clase AdminPersistentServicesI, y la ofrece por medio de la Ice.Application MuseumPersistence. Cabe destacar que para almacenar la información utiliza una serie de FreezeMaps generados para cada elemento persistente del sistema.
Para llevar a cabo el diseño y la implementación del agente de localización bluetooth
se ha partido del activo experimental Hesperia.BTLocation, desarrollado por Cleto Martı́n
Angelina para el proyecto Hesperia.
Este activo utiliza las interfaces Slice de Hesperia.MLP, inspiradas en el Mobile Location Protocol[MLP04] de la Open Mobile Alliance, y consta de dos scripts en Python.
BTAdmin.py Implementa la clase BTAdmin que hereda de Ice.Application e implementa
la interfaz Hesperia.MLP.LocationAdmin y se encarga de la gestión del canal de localización (publicación y subscripción). Además realiza escaneos bluetooth periódicos
en busca de dispositivos, publicando los descubrimientos en el canal.
BTListener.py Por medio de la clase BTListener implementa la interfaz Hesperia.MLP.LocationListener y recibe los eventos que se publican en el canal.
Partiendo de este activo se ha independizado la gestión del canal de localización y la
publicación de eventos. Para ello se han creado dos scripts.
BTAdmin.py Realiza una modificación sobre el script del Hesperia.BTLocation ya que
elimina el escaneo de dispositivos bluetooth, centrándose únicamente en la creación
y administración del canal de eventos de localización.
BTPoint.py Este script contiene la clase BTPoint que realiza escaneos periódicos y solicita
al Ice.Storm.Publisher creado por el BTAdmin la publicación de eventos de localización.
Para llevar a cabo la implementación del servidor, subsistema Server, se implementa
la interfaz AVISMI.MobileDevManager.Server permitiendo a los dispositivos móviles interactuar con el sistema. En esta versión inicial se realiza una implementación sencilla y
directa por medio de la clase Server. Para ello se tiene acceso al MuseumPersistence por
medio de un proxy hacia dicho servidor.
4.4.4.
Pruebas.
Para llevar a cabo las pruebas y mantener una organización del código en subsistemas se
ha separado de forma lógica el código por medio de directorios. Es decir, cada subsistema
se encuentra en un directorio, y para cada subsistema existe un directorio para las pruebas.
El entorno de pruebas se comentó con anterioridad (GNUMake y Tester), y aquı́ se
muestra la arquitectura básica utilizada para las pruebas.
38
En concreto para cada grupo de tests de un subsistema se crea una clase base (que hereda
de Ice.Application) que se encarga de obtener todos los proxies necesarios para interactuar
con otros subsistemas. Además esa clase contiene un método abstracto al que se llama en
el método run.
La clase que implementa cada test hereda de esta aplicación base, consiguiendo de esta
forma acceso a los proxies que necesite, e implementa el método test realizando la prueba
correspodiente. En el diagrama de clases 4.7 se puede ver esta correspondencia de clases.
Figura 4.7: Diagrama de clases seguido para realizar Tests
Una vez creados los tests, teniendo especial cuidado en utilizar las marcas necesarias
para que puedan ser procesados por Tester, por medio de la llamada a la herramienta make
con el parámetro test se ejecutan todos los tests obteniendo un informe como el que se
muestra en la figura 4.8.
A continuación se muestra un ejemplo de marcado, para la herramienta Tester, consiguiendo de este modo que se ejecute el script que contiene el test.
# DESC : add P o i n t s t o M u s e u m P e r s i s t e n c e
# +CMD: p y t h o n $ f i l e −−I c e . C o n f i g= c o n f i g
La lı́nea que empieza por “DESC” permite establecer la descripción del test, mientras
que la lı́nea “+CMD” indica que se debe ejecutar la lı́nea que sigue a esta etiqueta en la
consola, y que para que el test sea positivo el resultado de la ejecución debe ser válido, es
decir, que no termine por motivo de un error.
Nótese que por medio de “$file” se hace referencia a este mismo archivo, es decir, se
ejecuta el archivo que contiene la descripción. También hay que destacar que pueden existir
múltiples lı́neas “CMD”
Las pruebas para comprobar el funcionamiento del servidor han requerido simular el
comportamiento del dispositivo móvil. Esto se ha conseguido por medio del uso del patrón
Mock. Para ello en los tests se ha implementado la interfaz “AVISMI.MobileDevManager.InformationReceiver” proporcionando de ese modo un cliente para el servidor.
Figura 4.8: Log de la herramienta Tester para el subsistema MuseumPersistence
39
40
4.5.
Iteración 1. Inteligencia del sistema.
En esta iteración se creará un sistema capaz de generar rutas básicas, además el sistema
diferenciará entre los posibles estados del visitante ofreciéndole la información teniendo en
cuenta su estado.
4.5.1.
Análisis.
Para llevar a cabo este sistema es necesario realizar diversos estudios y evaluar las alternativas que se presentan tanto a nivel de diseño como a nivel de implementación. En concreto se realiza el estudio de la tecnologı́a necesaria para el dispositivo móvil y se evalúan
las alternativas para tratar el estado del visitante, abordando finalmente el diseño e implementación del sistema.
4.5.1.1.
Elección de la tecnologı́a para el dispositivo móvil.
A la hora de alojar una aplicación en el dispositivo móvil se deben evaluar las distintas
alternativas disponibles valorando especialmente factores como la portabilidad y la integración con el middleware.
Se han considerado varios sistemas operativos especializados en dispositivos móviles
como son Windows Mobile, Palm OS o Symbian, pero desarrollar la aplicación exclusivamente para uno de ellos condenarı́a la aplicación al sistema operativo utilizado.
Teniendo en cuenta la limitación que supone realizar una aplicación para un sistema
operativo en concreto se ha buscado una alternativa que pueda convivir en todos ellos sin
necesidad de especialización. Por éste motivo, y debido a la integración que esta tecnologı́a
tiene con el middleware, se ha elegido la plataforma Java 2 Micro Edititon [Keo03] que
ofrece soporte multiplataforma gracias al uso de máquinas virtuales disponibles para cada
sistema operativo.
Durante la ejecución del proyecto Google ha lanzado un nuevo sistema operativo para
dispositivos móviles bajo licencia GPL2 , Android, que podrı́a resultar muy intersante, pero
que se ha descartado para este proyecto debido a la madurez del mismo y a la escasa disponibilidad de dispositivos, a dı́a de hoy, con ese sistema operativo. A pesar de ello la opción
elegida sigue siendo válida ya que la multiplataforma proporciona el uso de J2ME permite
que la aplicación funcione en prácticamente la totalidad de dispositivos móviles.
4.5.1.2.
Alternativas de diseño en el tratamiento del estado del visitante.
Para realizar un diseño consistente del estado del visitante se ha realizado un análisis
exhaustivo de la información necesaria para recuperar el estado de la visita de cada visitante
en caso de caı́da del sistema. A continuación se muestra la información necesaria obtenida
de este análisis.
2
GNU LESSER GENERAL PUBLIC LICENSE 2.1, Free Software Foundation
4.5. ITERACIÓN 1. INTELIGENCIA DEL SISTEMA.
41
Información inicial. El sistema debe almacenar los parámetros que se requieren al entrar
al sistema, es decir, el idioma, la duración de la visita, si el visitante tiene alguna
discapacidad y el tipo de publico del visitante.
Ruta. Se debe almacenar la ruta personalizada generada a partir de la información inicial.
Posición actual. El sistema debe mantener actualizada la posición en la que se encuentra
el visitante en cada momento.
Ruta parcial. Hay que almacenar la ruta que se le solicita al sistema para ir de un punto a
otro del museo, ası́ como si el visitante está siguiendo una ruta o deambulando por el
museo.
Información estadı́stica. Además del estado imprescindible para mantener la visita actualizada para el visitante se debe almacenar información sobre los documentos consultados, la ruta seguida, etc.
Tras realizar este análisis se aborda la elección del soporte de almacenamiento de información para los que se consideran distintas alternativas.
Almacenamiento en memoria. Se puede pensar en almacenar solo en memoria de ejecución toda esta información pero una caı́da del subsistema implicarı́a perder los datos
de las visitas, por lo que se descarta esta opción.
Base de datos relacional. Se trata de la alternativa mas tradicional para almacenar datos.
Esta alternativa permite recuperación frente a caı́das del sistema, pero hay tener en
cuenta que se va a acceder a la misma utilizando la orientación a objetos, lo que implica complicar el acceso a la misma, tanto a nivel programático como computacional.
FreezeEvictor y FreezeMaps. Ice proporciona FreezeEvictor, que implementa el patrón
evictor, para interactuar con objetos persistentes de forma eficiente. Utilizando de
forma adecuada los FreezeMaps, para almacenar la información estática, y el FrezeEvictor, para almacenar los objetos dinámicos del sistema, se obtiene una solución
muy eficiente.
Por todo ello se elige este método como alternativa para el almacenamiento de información relativa a los visitantes.
4.5.2.
Diseño.
Una vez realizado el estudio sobre el método de almacenamiento se ha llevado a cabo el
diseño del archivo slice que modela los objetos y las interfaces necesarias para dar cabida
a este subsistema. Para ello se ha modificado el diagrama de casos de uso de la iteración 0,
atendiendo a los objetivos de esta iteración, obteniendo el diagrama que puede verse en la
figura 4.9.
A partir del diagrama de casos de uso y el diagrama de secuencia, ambos adaptados a
esta iteración (figuras 4.9 y 4.10), se ha diseñado el archivo Slice Visitors.ice.
42
Figura 4.9: Diagrama de casos de uso (Iteración1)
Este archivo (listado 4.12) define las estructuras y objetos que soportan la necesidad
de información con respecto a los visitantes, ası́ como las interfaces que proporcionan los
métodos de acceso a los visitantes. Para ello se define la clase Visitor, que representa la
información de los visitantes gracias a la agregación de varias estructuras.
Figura 4.10: Diagrama de secuencia (Iteración1)
43
44
Listado 4.12: Visitors.ice
enum V i s i t S t a t e { C o n s u l t i n g , S e a r c h i n g } ;
struct State {
VisitState vState ;
AVISMI : : MobileDevManager : : L i s t E l e m e n t s e l E l e m e n t ;
};
s t r u c t TimePoint {
s t r i n g idObj ;
int seconds ;
};
[ ” java : type : java . u t i l . Vector ” ]
s e q u e n c e <T i m e P o i n t > T i m e P o i n t s ;
struct Counters {
i n t numTexts ;
i n t numVideos ;
i n t numAudios ;
Ice : : StringSeq visitedObjects ;
Ice : : StringSeq visitedDocuments ;
i n t i n i t i a l T i m e S t a m p ; / / UNIX t i m e s t a m p
int lastTimeStamp ;
TimePoints spentTimePoints ;
};
struct Features {
AVISMI : : V i s i t o r T y p e s : : Language l a n g ;
AVISMI : : V i s i t o r T y p e s : : A u d i e n c e a u d i e n c e ;
AVISMI : : V i s i t o r T y p e s : : D i s a b i l i t y d i s a b i l i t y ;
int visitTime ;
};
class Visitor {
s t r i n g macBT ;
Counters vCounters ;
Features vFeatures ;
State vState ;
AVISMI : : MobileDevManager : : L i s t m o b i l e L i s t ;
Ice : : StringSeq routeElements ;
};
s e q u e n c e <V i s i t o r > V i s i t o r S e q ;
Mención especial merece la clase PersistentVisitor ya que gracias a ella se podrán almacenar objetos en el Freeze Evictor.
c l a s s P e r s i s t e n t V i s i t o r extends V i s i t o r implements VisitorMethods {
};
Finalmente conviene destacar las interfaces que permiten interactuar con la persistencia
de los visitantes.
VisitorMethods. Esta interfaz proporciona los métodos necesarios para actualizar el objeto
visitante que se utilizan mientras que el visitante esta realizando la visita.
45
[ ” freeze : write ” ]
i n t e r f a c e VisitorMethods {
void setRoute ( Ice : : StringSeq r o u t e ) ;
void s e t S t a t e ( S t a t e t h e S t a t e ) ;
void s e t S t a t e V a l u e ( V i s i t S t a t e s t a t e ) ;
v o i d s e t S t a t e E l e m e n t ( AVISMI : : MobileDevManager : : L i s t E l e m e n t l e ) ;
void s e t F e a t u r e s ( F e a t u r e s v F e a t u r e s ) ;
v o i d s e t M o b i l e L i s t ( AVISMI : : MobileDevManager : : L i s t m o b i l e L i s t ) ;
[ ” freeze : read ” ]
AVISMI : : MobileDevManager : : L i s t g e t M o b i l e L i s t ( ) ;
void
void
void
void
void
void
long
void
void
incrementCounterTxt () ;
incrementCounterVideo ( ) ;
incrementCounterAudio ( ) ;
addVisitedObject ( s t r i n g idObj ) ;
a d d C o n s u l t e d D o c ( s t r i n g idDoc ) ;
setLastTime ( int lastTime ) ;
getLastTime ( ) ;
addTimePoint ( TimePoint time ) ;
addTimePoints ( TimePoints times ) ;
bool isRouteElement ( s t r i n g namePoint ) ;
b o o l i s C o n s u l t e d D o c ( s t r i n g idDoc ) ;
bool i s V i s i t e d O b j e c t ( s t r i n g idObj ) ;
Visitor getVisitor () ;
};
AdminVisitor. Permite gestionar la entrada/salida y acceso a los visitantes del museo que
se encuentran realizando la visita. Una vez que el visitante sale del museo se libera
esta información del evictor que almacena los visitantes en lı́nea, manteniendo de este
modo la parte más critica con el menor tráfico posible.
i n t e r f a c e AdminVisitor {
PersistentVisitor ∗ createVisitor ( Visitor v) ;
P e r s i s t e n t V i s i t o r ∗ g e t V i s i t o r ( s t r i n g macBT ) ;
v o i d r e m o v e V i s i t o r ( s t r i n g macBT ) ;
b o o l e x i s t V i s i t o r ( s t r i n g macBT ) ;
};
4.5.3.
Implementación.
Para llevar a cabo la implementación que de soporte a la persistencia de los visitantes se
ha creado el subsistema VisitorsPersistence.
VisitorsPersistence. Este subsistema realiza la implementación del objeto PersistentVisitor y de la interfaz AdminVisitor. Esta implementación se ha realizado en C++ y
utilizando FreezeEvictor para conseguir la máxima eficiencia.
46
Para ello se ha creado el objeto PersistentVisitorI y el servidor VisitorPersistenceServer.
El objeto PersistentVisitorI implementa la clase AVISMI.Visitors.PersistentVisitor dando soporte al almacenamiento de un visitante.
El servidor VisitorPersistenceServer se encarga de la administración del FreezeEvictor de los visitantes. Para ello implementa la interfaz AVISMI.Visitors.AdminVisitor
ofreciendo los métodos necesarios para crear, recuperar y eliminar visitantes en lı́nea.
Estos visitantes se manejan por el Freeze.Evictor, y vienen representado por objetos
PersitentVisitorI los cuales se crean por medio de la factorı́a de objetos PersistentVisitorFactory.
El diagrama de clases que ilustra el funcionamiento del sistema se puede ver en la
figura 4.11.
Figura 4.11: Diagrama de clases reducido del VisitorsPersistence (Iteración1)
Tras crear el subsistema que permite almacenar la información relativa a los visitantes
se debe actualizar el servidor modificándolo para que utilice el VisitorsPersistence en lugar
de almacenar esa información en estructuras en memoria. Además para satisfacer la inteligencia del sistema y mantener un buen diseño del mismo se ve la necesidad de separar la
lógica del servidor en distintas clases.
En concreto el subsistema Server se ha separado en tres clases que se detallan a continuación y se ilustran en la figura 4.12.
Server. Se trata de la clase principal, es decir, la que se encarga de lanzar el subsistema.
Para ello hereda de Ice.Application y se encarga de contactar con los subsistemas que
47
necesita, obteniendo un proxy a MuseumPersistence, VisitorsPersistence y BTAdmin.
Cabe señalar que para reducir el tráfico sobre la red se utiliza una caché de objetos.
En concreto se ha creado la clase Cache.
Cache es una clase que almacena N pares de objetos clave-valor en un diccionario,
proporcionando métodos para manejar estos pares y soportando el acceso concurrente
a los objetos almacenados.
ServerI. Realiza la implementación de la interfaz AVISMI.MobileDevManager.Server, manteniendo una estructura que permite asociar a cada visitante con su almacenamiento
persistente, y dando soporte a las necesidades del dispositivo móvil del visitante.
VisitAssistant. Se encarga de administrar las peticiones que el visitante realiza desde su
dispositivo móvil, resolviendo las rutas que solicita, actualizando su listado, etc.
Figura 4.12: Diagrama de clases (reducido) del Server (Iteración 1)
Para implementar la aplicación del dispositivo móvil se ha desarrollado un MIDlet
J2ME que implementa la interfaz AVISMI.MobileDevManager.InformationReceiver, utilizando la tecnologı́a LWUIT3 para crear la interfaz de usuario de la aplicación.
Se ha diseñado una arquitectura modular (figura 4.13) que permite incorporar nuevas
funcionalidades sin modificar el sistema ya creado. Para ello se parte de una clase principal,
MuseumAssistant; se trata de un midlet que contiene principalmente tres instancias de las
clases CommunicatorManager, OAManager y PluginManager.
CommunicatorManager encapsula el manejo del communicator de Ice. Por medio de
esta clase se permite tanto la creación del communicator a partir de un archivo de
3
LWUIT. Lightweight UI Toolkit. Sun Microsystems
48
configuración o desde una variable, como la parada y puesta en funcionamiento del
mismo.
OAManager encapsula el manejo del adaptador de objetos, siguiendo la misma filosofı́a
que el CommunicatorManager.
PluginManager ofrece soporte a la introducción de funcionalidad múltiple e independiente por medio de plugins. Gracias a esta clase se gestionan los plugins que soportan
cada funcionalidad del sistema, es decir, permite registrar plugins, mostrando una
interfaz que permite elegir cual de ellos ejecutar.
Los plugins que soporta el sistema deben extender la clase abstracta Plug e implementar
los métodos execute y clean. El primero se encarga de lanzar el plugin, mientras que el
segundo se encarga de limpiar los objetos utilizados durante la ejecución del mismo.
Atendiendo a las necesidades del proyecto se han creado dos plugins: PluginConfig y
PluginInfoMenu. El primero permite actualizar los valores de configuración de Ice, mientras
que el segundo permite interactuar con el sistema, es decir, es el encargado de dar soporte a
la implementación de la interfaz AVISMI.MobileDevManager.InformationReceiver.
Gracias a este diseño se puede incorporar funcionalidad a esta aplicación fácilmente,
sólo es necesario crear una clase que herede de Plug y registrarla desde la clase principal.
Conviene señalar que se está hablando de plugins que implican volver a compilar la aplicación, pero que aislan el desarrollo en una única clase. Esto se debe a que en esta tecnologı́a
todavı́a no se puede realizar refactorización.
4.5.4.
Pruebas.
La creación y modificación de estos subsistemas implican la creación y revisión de las
baterı́as de pruebas. La forma de proceder es la misma que en el resto del sistema, es decir,
se crea un directorio “tests” y en él se crean el archivo “DESCRIPTION” y los tests que
comprueban el funcionamiento del subsistema, en este caso del VisitorsPersistence.
Para la depuración de la aplicación del dispositivo móvil se utiliza el simulador que
proporciona J2ME para el desarrollo de aplicaciones para dispositivos móviles el Sun Java
Wireless Toolkit 2.5.2.
Además la tecnologı́a utilizada en la elaboración de la interfaz de usuario de esta aplicación permite y recomienda el uso de la clase com.sun.lwuit.Log para la depuración de
dichas aplicaciones. Teniendo esto en cuenta se utiliza para esta finalidad en la aplicación.
4.5.5.
Vista actual del sistema.
Tras crear estos sistemas y modificar los existentes la vista general del sistema en esta
iteración se muestra en la figura 4.14.
Figura 4.13: Diagrama de clases reducido de la aplicación J2ME
49
50
Figura 4.14: Sistema tras la iteración 1
4.6. ITERACIÓN 2. HERRAMIENTA DE GESTIÓN.
4.6.
51
Iteración 2. Herramienta de gestión.
En esta iteración se aborda el análisis, diseño e implementación de la herramienta de
gestión.
Esta herramienta permite a los usuarios finales interactuar con el sistema, es decir, es
la parte tangible del proyecto ya que permite consultar y editar la información del sistema.
Teniendo esto en cuenta se debe tratar con especial cuidado la presentación y la fiabilidad
de la interfaz de usuario.
4.6.1.
Análisis.
En primer lugar se ha realizado un estudio para elegir la tecnologı́a que se utilizará para
crear la interfaz gráfica, y después se ha abordado el diseño e implementación del servicio.
4.6.1.1.
Elección de la tecnologı́a para la creación de la interfaz gráfica.
Para realizar esta herramienta se debe elegir una tecnologı́a que permita el diseño de
interfaces gráficas que cumpla varios requisitos.
Software libre
Siguiendo la filosofı́a del proyecto se busca una alternativa con una licencia acorde
con la filosofı́a del Software libre.
Soportada por sistemas GNU
Conviene que la tecnologı́a este fuertemente integrada en sistemas GNU, facilitando
de ese modo la instalación de la herramienta en este tipo de sistemas.
Integración con Python
Debido a que este lenguaje es el predominante en el sistema, por sus caracterı́sticas
mencionadas en estudios anteriores, es conveniente que la tecnologı́a que se elija
tenga un alto grado de integración con este lenguaje.
Teniendo en cuenta estos requisitos se muestran a continuación las tecnologı́as que se
han considerado para diseñar la interfaz gráfica de la herramienta de gestión.
GTK. GTK [Kra07] es una liberı́a multiplataforma para la creación de interfaces gráficas.
Soporta varios lenguajes de programación tales cómo C++, Python, C#, etc. Cabe
destacar que esta especialmente bien integrado en entornos GNU/Linux, ofreciendo
una gran cantidad de documentación. En concreto ofrece una extensa documentación
para pyGTK (rama de GTK para Python) lo que resulta especialmente interesante
para este proyecto ya que la interfaz de administración principal esta escrita sobre
este lenguaje.
52
Está bajo la licencia GNU LGPL4 lo que permite utilizar esta librerı́a en cualquier
proyecto software.
Glade. Si bien GTK es una librerı́a potente, puede resultar tedioso realizar interfaces gráficas sin un editor para ello. Glade solventa esta situación, ya que es un diseñador de
interfaces gráficas para GTK.
Glade es una aplicación que permite, a través de su interfaz, generar interfaces GTK,
utilizando archivos XML [XML08] para almacenar esta información. Además también incluye la librerı́a libglade mediante la que se puede conectar el programa (realizado en alguno de los lenguajes que soporta) con la interfaz gráfica. Cabe destacar
que tiene soporte para una amplia variedad de lenguajes tales como C, C++, Java,
Perl, Python, C#, etc.
QT. Nokia define QT del siguiente modo: “QT is a cross-platform application framework.
Using Qt, you can write applications once and deploy them across many desktop and
embedded operating systems without rewriting the source code.”.
En una primera aproximación a la alternativa se comprobó que no era una librerı́a bajo
una licencia adecuada para el proyecto por lo que se descartó. A partir de Marzo de
2009 Nokia liberará QT (desde la versión 4.5) bajo la licencia GNU LGPL 2.15 , sin
embargo esta fecha es demasiado avanzada para plantearse utilizar esta alternativa.
wxWidgets. wxWidgets6 es una librerı́a de clases que permite compilar aplicaciones gráficas sobre distintas plataformas. Inicialmente estas aplicaciones debı́an estar escritas
en C++ pero actualmente se da soporte para mas lenguajes entre ellos Python.
wxWidgets define una API común para las plataformas, pero usa la GUI nativa de
cada plataforma, por ello la aplicación tendrá el aspecto de la plataforma en la que se
ejecute.
Para elegir la tecnologı́a a utilizar también se ha tenido en cuenta la madurez de la
misma ası́ cómo la documentación disponible, eligiendo finalmente GTK para Python. Cabe
señalar que dispone de una excelente documentación ofrecida por PyGTK7 .
Teniendo en cuenta que esta herramienta es la parte mas cercana al usuario final de la
aplicación se debe cuidar especialmente la presentación y facilidad de uso, por lo que se
han seguido una serie de directrices para el diseño de interfaces de usuario proporcionadas
por GNOME8 llamadas Gnome HIG[Pro]. Siguiendo estas directrices se garantiza un alto
nivel de calidad en las interfaces gráficas desarrolladas con GTK[Kra07].
4
6
wxWidgets. The wxWidgets Team. wxWidgets Project
7
PyGTK. The GNOME Project and PyGTK Team
8
GNOME: The Free Software Desktop Project. The GNOME Project
5
4.6.2.
53
Diseño.
Durante el diseño de esta interfaz se ha detectado una nueva necesidad con respecto
al servicio MuseumPersistence, como se puede ver en el los diagramas de casos de uso
actualizados para esta iteración (figuras 4.15 y 4.16). En concreto es necesario que este servicio implemente el patrón observador para permitir que los subsistemas que lo requieran
estén informados de los cambios que se realizan en el mismo. Esto conlleva dos cambios
importantes; el primero afecta a la arquitectura y el segundo afecta al subsistema MuseumPersistence.
Figura 4.15: Diagrama de casos de uso del MuseumPersistence (Iteración 2)
El cambio que se ha realizado en el diseño afecta al archivo Slice, Persistence.ice. En
concreto se han definido dos interfaces y una estructura mediante los que se puede gestionar
la notificación de cambios en el sistema de persistencia a todos aquellos servicios que lo
necesiten, como se puede ver en el listado 4.16.
54
Listado 4.16: MuseumPersistence.ice
/ / Automatic change n o t i f i c a t i o n s v i a I c e S t o r m
enum C l a s s C h a n g e {p , d , mo , r } ;
enum ModeChange { add , remove } ;
s t r u c t Change {
ClassChange c l a s ;
ModeChange mode ;
s t r i n g id ;
};
interface ChangePersistentServices {
v o i d n o t i f y C h a n g e ( Change c ) ;
};
i n t e r f a c e ChangeAdminPersistentServices extends AdminPersistentServices
{
void a d d L i s t e n e r ( C h a n g e P e r s i s t e n t S e r v i c e s ∗ l i s t e n e r ) ;
void removeListener ( C h a n g e P e r s i s t e n t S e r v i c e s ∗ l i s t e n e r ) ;
};
ChangePersistentServices. Define un método para recibir notificaciones cuando se realizan cambios en el sistema de persistencia. Gracias a la implementación del patron
observer llevada a cabo por esta interfaz y la interfaz ChangeAdminPersistentServices, cualquier sistema que implemente esta interfaz y se subscriba en el sistema
que implemente la interfaz ChangeAdminPersistentServices sera notificado cuando
se realicen cambios en la persistencia, pudiendo reaccionar ante estos eventos.
ChangeAdminPersistentServices. Extiende el comportamiento de AdminPersistentServices proporcionando métodos para subscribir a los objetos que necesiten ser avisados
de los cambios en la persistencia.
Para llevar a cabo la creación de la interfaz se ha creado un diagrama de casos de uso
que representa la semántica que debe contemplar. Este diagrama se muestra en la figura
4.16. En esta iteración sólo se debe dar soporte a la gestión de información como se refleja
en los casos de uso “Manejar datos del sistema” y “Sincronizar GUI - datos del sistema” de
dicha figura.
Figura 4.16: Diagrama de casos de uso de AdminAVISMI (Iteración 2)
4.6.3.
55
Implementación.
La modificación realizada en el diseño del slice Persistence.ice implica una actualización del servicio MuseumPersistence. En concreto se implementa la interfaz ChangeAdminPersistentServices dando soporte a la publicación de eventos de cambio en los mapas
freeze que almacenan la información persistente del museo. En la figura 4.17 se observa
este cambio.
Figura 4.17: Diagrama de clases reducido del MuseumPersistence (Iteración 2)
Esta modificación afecta al subsistema Server ya que la caché de objetos del sistema
que contiene debe mantenerse actualizada. Para conseguir este propósito se debe crear una
caché que implemente la interfaz ChangePersistentServices que reciba los eventos de actualización del sistema de persistencia.
La clase CacheMP satisface este objetivo, es decir, implementa la interfaz ChangePersistentServices y contiene la caché de objetos del MuseumPersistence. Para ello utiliza un
objeto de la clase Cache por cada tipo de objeto persistente en el sistema, actualizando cada
caché tras recibir las notificaciones de cambio del MuseumPersistence.
La modificación realizada en el subsistema Server se ve reflejada en el diagrama de
clases de la figura 4.18.
El diseño de la interfaz de usuario, independiente de la lógica de la aplicación, ha sido
realizado por medio de la herramienta Glade9 , permitiendo de este modo una visualización
9
Glade - a User Interface Designer for GTK+ and GNOME. The Gnome Foundation
56
Figura 4.18: Diagrama de clases (reducido) del Server (Iteración 2)
previa aproximada a la final y evitando realizar las declaraciones de objetos de la interfaz
en el código de la aplicación.
La interfaz presenta una ventana principal sobre la que hay un panel con pestañas. Cada
pestaña permite trabajar con un aspecto de la aplicación, permitiendo de ese modo una
separación lógica de contenidos.
El diseño de cada una de las pestañas tiene en cuenta las directrices indicadas por Gnome
HIG para garantizar la calidad de la interfaz. Cabe destacar que se ha dado soporte a la
traducción de la aplicación por medio de GNU gettext10 .
El diseño de la lógica final de la aplicación se muestra, de forma reducida para mejorar
la comprensión, en la figura 4.19.
La clase que da soporte a la interfaz gráfica es UI. Esta clase contiene multitud de
métodos que se pueden agrupar en base a su semántica. A continuación se enumeran estos
grupos explicando la finalidad a la que dan soporte.
Inicializadores de objetos de la interfaz gráfica. En este grupo se tienen métodos que
inicializan objetos como GTK.ListStore, GTK.Dialogs, etc. En general empiezan
por init* y suelen agruparse por categorı́as, por ejemplo initCB inicializa todos los
GTK.comboBox de la interfaz.
Cabe destacar que en este grupo también se engloban los métodos que permiten adecuar la aplicación al lenguaje necesario.
Manejadores Ice. En este grupo se engloban los métodos que integran el middleware en
la aplicación. El método más importante es el que crea el communicator a partir del
archivo de configuración (iniciarCommunicator).
Manejadores de eventos. Los eventos de la interfaz capturados se tratan por medio de los
callbacks definidos en este grupo. La nomenclatura general de este tipo de métodos
empieza por event*.
10
c 1998, 2009 Free Software Foundation
GNU gettext. Copyright 4.6. ITERACIÓN 2. HERRAMIENTA DE GESTIÓN.
57
Comprobación. Para garantizar la integridad de los datos introducidos se realizan comprobaciones antes de realizar cualquier operación que afecte al estado del sistema. Para
ello se han creado métodos que permiten comprobar la validez de dichos datos cuya
nomenclatura general empieza por check*.
La clase UI tiene multitud de atributos, muchos de ellos pertenecientes a diccionarios
(tablas Hash) que permiten la traducción de la aplicación, pero los más importantes se
muestran en la figura 4.19.
Figura 4.19: Diagrama de clases final (reducido) de la herramienta de administración
(Iteración 2)
Estos atributos se pueden subdividir en varios grupos dependiendo de su funcionalidad.
Proxy. El MPPrx es el proxy al sistema de persistencia del museo (MuseumPersistence).
Gracias a la implementación que realiza la clase UI de la interfaz AVISMI.Persistence.ChangePersistentServices la interfaz puede estar actualizada con los datos del museo,
ya que se subscribe al canal de eventos de modificación que tiene el MuseumPersistence actuando en consecuencia.
Instancias de clases auxiliares. Para simplificar la interfaz de usuario y ganar robustez por
medio de pruebas se han ido separando funcionalidades necesarias para la interfaz
en clases especializadas en tratar determinadas problemáticas, de ese modo se han
podido realizar test exhaustivos que comprueban el correcto funcionamiento de estas
clases, aumentando la fiabilidad de la interfaz de usuario.
Los atributos que almacenan este tipo de clases son admin y exportador.
El atributo admin es una instancia de la clase del AdministradorUI. Esta clase permite
la creación de objetos relacionados con la persistencia del museo y aporta los métodos
para interactuar con dicho subsistema (MuseumPersistence).
58
El segundo atributo mencionado, exportador, es una instancia de la clase Exportador.
Esta clase se especializa en generar/recuperar archivos textuales a partir de la información del sistema, es decir, se encarga de exportar/importar información a partir de
archivos de texto plano (véase Anexo I).
4.6.4.
Tras crear estos sistemas y modificar los existentes la vista general del sistema en esta
iteración se muestra en la figura 4.20.
4.7. ITERACIÓN 3. CÁLCULO DE RUTAS
4.7.
59
Iteración 3. Cálculo de rutas
En esta iteración se realiza el estudio, diseño e implementación de los sistemas encargados del manejo de la información geográfica, teniendo en cuenta tanto su almacenamiento
como su acceso.
Cabe destacar la especial complejidad de este tipo de sistemas, por lo que se ha decidido
utilizar una herramienta creada especı́ficamente para este propósito, ya que minimiza el
riesgo de errores en el resto del sistema.
Teniendo en cuenta estas consideraciones se ha elegido el servicio Hesperia.OpenLS
desarrollado por Julie Pichón en el grupo ARCO. Este servicio realiza una implementación
del estándar Location Service (OpenLS)[OGC07c] de la Open Geospatial Consortium y se
detalla a continuación.
4.7.1.
Análisis.
Para poder llevar a cabo la integración del sistema que se está creando con el sistema
elegido para realizar el cálculo de rutas es necesario realizar un estudio sobre cómo funciona
el servicio Hesperia.OpenLS.
4.7.1.1.
Hesperia.OpenLS
La especificación de implementación OpenLS [OGC07c] define un conjunto de servicios basados en localización que son el Directory Service, el Gateway Service, el Location
Utility Service (Geocoder/Reverse Geocoder), el Presentation Service y el Route Service.
Este sistema realiza una implementación de tres de éstos servicios; del Directory Service,
Route Service y del Location Utility Service.
El servicio Heperia.OpenLS utiliza las intefaces de localización ofrecidas por Hesperia.Location. En concreto utiliza dos interfaces; la interfaz Hesperia.MLP.LocationAdmin y
la intefaz Hesperia.MLP.LocationListener.
El servicio de directorio (que extiende la interfaz Hesperia.MLP.LocationListener) se
subscribe a los canales de localización, actualizando la base de datos PostGIS 11 en consecuencia. Estos canales son gestionados por objetos que implementan la interfaz Hesperia.MLP.LocationAdmin y están definidos vı́a proxy en el archivo de configuración.
Estos mecanismos permiten ofrecer los servicios de OpenLS a las aplicaciones de forma
sencilla mediante el uso de proxys a cada servicio. Además permite que aplicaciones GIS
estándar puedan recibir la información de localización de forma transparente. La figura 4.21
siguiente ilustra el funcionamiento general.
La información necesaria para dar soporte a los servicios Hesperia.OpenLS se almacena
en la base de datos openls cuya estructura se muestra en la figura 4.22.
Resulta fundamental entender este esquema y los valores que se deben almacenar en él,
11
PostGIS. Refractions Research
60
Figura 4.21: Vista general del servicio Hesperia.OpenLS
ya que los servicios de directorio y ruta se basan en los datos aquı́ almacenados para obtener
los resultados.
Las tablas ols dir geodata y ols dir yellowpages dan soporte al servicio de directorio,
mientras que las tablas ols route nodes, ols route edges y ols route sp matrix dan soporte
al servicio de ruta.
La tabla ols dir yellowpages almacena información relativa a un objeto. Hay que tener
especial cuidado a la hora de establecer el valor del identificador id ya que debe ser descriptivo, textual y único; name representa el tipo de la entrada, mientras que value representa
el objetivo final de la entrada. A continuación se muestran varios ejemplos de fila para esta
tabla.
Listado 4.17: Posibles inserciones en ols dir yellowpages
( ’ i n f i r m a r y : room45B : f l o o r 2 ’ , ’ t y p e ’ , ’ i n f i r m a r y ’ )
( ’ b t : 0 0 : 1 9 : 2 D : FC : A6 : CB# Nokia 6085#5898756 ’ , ’ t y p e ’ , ’ s e c u r i t y g u a r d ’ )
( ’ b t : 0 0 : 8 0 : 5 A : 4 6 : 4 6 : C4#UCLM−47#131332 ’ , ’ a d d r e s s ’ , ’UCLM, P a s e o de l a
U ni v e rs i da d , 4 , Ciudad Real ’ )
La tabla ols dir geodata almacena la última posición de un objeto. El objeto viene identificado mediante el campo id; el campo time refleja el instante en el que se recibió la
notificación de cambio de posición; el campo node indica cual es el nodo que registra la
notificación y geom refleja la posición geográfica en la que se ha detectado el evento de
notificación.
La tabla ols route nodes almacena el identificador id del nodo y su posición geográfica
61
Figura 4.22: Base de datos del servicio Hesperia.OpenLS
point, mientras que ols route edges se encarga de almacenar las posibles combinaciones de
rutas entre nodos con el coste que conlleva seguir dicha ruta.
La tabla ols route sp matrix contiene la mejor ruta entre dos nodos, para ello utiliza el
campo s path con una secuencia de identificadores de nodo que representan los nodos a
seguir para llegar al destino. Además almacena el coste de seguir la ruta en el campo cost.
A continuación se detalla brevemente la arquitectura de cada uno de los servicios que
este sistema implementa.
Servicio de Directorio. El servicio de directorio OpenLS permite obtener puntos de interés
a partir de diversos parámetros y consideraciones. El servicio de directorio se mantiene actualizado gracias al servicio de Localización ofrecido por Hesperia mediante
las intefaces Hesperia.MLP.LocationAdmin y Hesperia.MLP.LocationListener. Para
conseguir éste propósito el servicio de directorio extiende la interfaz Hesperia.MLP.LocationListener, de éste modo el servicio de directorio se puede subscribir a los
canales que reciben los eventos de localización y actuar en consecuencia. Cabe destacar que éstos canales son administrados por objetos que implementan la interfaz
LocationAdmin.
Los métodos que ofrece el servicio de directorio permiten obtener localizaciones a
partir de diversas consideraciones.
findLocation. Busca localizaciones a partir de n criterios.
62
findLocationFromAddress. Busca localizaciones a partir de una dirección.
findLocationNearest. Busca localizaciones cercanas a otra.
findLocationWithinDistance. Busca localizaciones que estén entre la distancia mı́nima y la máxima con respecto a otra localización.
findLocationWithinBoundary. Busca localizaciones que estén dentro de un área.
Servicio de Ruta. El servicio de ruta permite obtener una ruta a partir de una lista de localizaciones y de una secuencia de puntos de interés a evitar por medio del método
findRoute. Para ello define varias estructuras cómo son el plan de ruta, el sumario de
ruta y la ruta.
Servicio de Geocodificación. El servicio de geocodificación permite obtener codificaciones geográficas a partir de cadenas y viceversa, es decir, obtener cadenas a partir de
codificaciones geográficas. Para ello define una dirección geográfica y la interfaz de
acceso al servicio de obtención de coordenadas geográficas.
4.7.2.
Diseño.
Para integrar el servicio Hesperia.OpenLS en el sistema es necesario crear servicio que
permita interactuar de intermediario, permitiendo introducir los datos procedentes de la
persistencia del museo como datos válidos para este sistema.
En concreto el sistema necesita introducir y eliminar los datos procedentes del MuseumPersistence en la base de datos OpenLS, ası́ como eliminar posiciones anticuadas de
visitantes.
Para ello se ha diseñado un slice que recoge esta semántica; el ManagerOpenLS.ice
(listado 4.18). En este slice se define la interfaz AVISMI.ManagerOpenLS.Manager, que
recoge los métodos de actualización de la base de datos populateDataBase y cleanDataBase
y el método que permite eliminar filas de la tabla ols dir geodata.
Listado 4.18: ManagerOpenLS.ice
module AVISMI {
module ManagerOpenLS {
i n t e r f a c e Manager {
void populateDataBase ( ) ;
void cleanDataBase ( ) ;
void d e l e t e G e o d a t a ( s t r i n g id ) ;
};
};
};
4.7.3.
63
Implementación.
La puesta en ejecución de los cambios de diseño se reflejan en dos aspectos importantes:
Servicio frontend para OpenLS (ManagerOpenLS). Para encapsular el manejo de la base de datos OpenLS, centralizando de ese modo los errores relativos al acceso a dicha
base de datos, se hace necesario definir un servicio que permita realizar las operaciones básicas necesarias para el sistema.
Para resolver esta situación se ha creado el servicio ManagerOpenLS. Este servicio
realiza una implementación de la interfaz AVISMI.ManagerOpenLS.Manager proporcionando los métodos que necesita el sistema para interactuar con la base de datos
OpenLS.
Como se puede ver el diagrama de clases del ManagerOpenLS (figura 4.23) para
implementar este servicio se utiliza la clase ManagerI que a su vez implementa la
interfaz AVISMI.ManagerOpenLS.Manager. Para cumplir su objetivo se vale de otras
clases auxiliares como son Conversor, Database y QueryOLS.
Conversor. Gracias a esta clase se generan los archivos que necesita el script plain to route.py para poblar la base de datos OpenLS. Cabe señalar que estos archivos son generados a partir de la información del sistema que contiene el sistema
MuseumPersistence.
Database. Se encarga de gestionar el acceso a la base de datos.
QueryOLS. Por medio de esta clase se obtienen consultas, en forma de cadena, para
consultar a la base de datos.
Finalmente el servicio se lanza por medio de una Ice.Application, ManagerOpenLS,
que se encarga de crear el adaptador de objetos necesario para la publicación del
servicio, de instanciar el acceso a la base de datos y de obtener el proxy al MuseumPersistence.
Actualización del Server. Tras poner en marcha el Route Service y el Directory Service,
se ha procedido a integrarlo con el Server como se puede ver en el diagrama de
secuencia de la figura 4.24. Para ello se ha delegado la responsabilidad de la búsqueda
de rutas en el Route Service. Esta delegación se realiza en la clase VisitAssistant,
siendo transparente al resto del sistema del Server.
De la misma forma se integra el Server con el Directory Service, es decir, por medio
de la clase VisitAssistant y siendo transparente para el resto de este sistema. Gracias
al Directory Service se consigue localizar los elementos cercanos a la posición actual,
permitiendo adaptar los contenidos al contexto en el que se desenvuelve el visitante.
4.7.4.
Tras integrar el sistema Hesperia OpenLS y modificar los existentes la vista general del
sistema en esta iteración se muestra en la figura 4.25.
64
Figura 4.23: Diagrama de clases reducido del ManagerOpenLS
Figura 4.24: Diagrama de secuencia de la iteración 3
65
66
4.8. ITERACIÓN 4. AMPLIACIÓN DE LA HERRAMIENTA DE GESTIÓN
4.8.
67
Iteración 4. Ampliación de la herramienta de gestión
En esta iteración se proporcionará soporte a la visualización del museo en tiempo real.
4.8.1.
Análisis.
Tras analizar los requisitos del sistema se ha constatado la necesidad de tener algún
mecanismo para registrar los movimientos de los visitantes por el museo. A su vez es necesario modelar dicho museo, por lo que se ha decidido utilizar un sistema de información
geográfico que de soporte esta necesidad.
Para dar soporte a este requisito se necesita almacenar la información geográfica, permitiendo a su vez una correcta visualización gráfica en forma de mapa. Como consecuencia
se deduce que hay una separación entre los mecanismos de almacenamiento y visualización
de la información geográfica, por lo que se realizarán estudios separados para escoger la
mejor alternativa en cada caso.
4.8.1.1.
Formatos para el almacenamiento de información geográfica.
En la actualidad existen diversas formas de almacenar información geográfica dependiendo de la naturaleza del archivo, ya que puede ser un raster (imagen) o una descripción
vectorial.
Cabe señalar que existe un número elevado de sistemas comerciales que han creado
formatos propietarios totalmente orientados a sus sistemas, como por ejemplo la empresa
ESRI con la suite ArcGIS. Sin embargo, debido al carácter del proyecto se han buscado
soluciones bajo la filosofı́a del software libre. Además estas soluciones deben respetar los
estándares establecidos por el Open Geospatial Consortium (OGC).
Es posible utilizar imágenes (raster) para representar este tipo de sistemas utilizando
determinados formatos:
GeoTIFF. GeoTIFF [RR00] es un estándar de metadatos de domino público que permite
que información georreferenciada sea encajada en un archivo de imagen de formato
TIFF. La información adicional incluye el tipo de proyección, sistema de coordenadas, elipsoide, datum y todo lo necesario para que la imagen pueda ser automáticamente posicionada en un sistema de referencia espacial.
JPEG 2000 .
JPEG 2000 [TM02] es un estándar para compresión de imágenes que utiliza la transformada discreta del coseno para este propósito. Además este formato permite almacenar metainformación asociada al archivo. En concreto, para la georeferenciación,
el estándar ha contemplado el almacenamiento de datos en formato GML para jpeg
2000 [OGCa].
Las descripciones vectoriales se pueden almacenar en multitud de formatos, sin embargo
solo se estudiarán aquellos que cumplen los estándares del OGC.
68
Geography Markup Language Encoding Standard (GML). El lenguaje de marcado geográfico (traducción del inglés Geography Markup Language, GML[OGC07a]) se ha definido por el Open Geospatial Consortium (OGC) para expresar caracterı́sticas geográficas. GML sirve como lenguaje de modelado para sistemas geográficos ası́ como formato de intercambio para transacciones geográficas en Internet.
Keyhole Markup Language (KML). KML [OGC07b] es un lenguaje XML centrado en
la visualización geográfica que permite anotaciones sobre mapas e imágenes. La visualización geográfica incluye no sólo la presentación gráfica de los datos, sino también el control de la navegación de usuario en el sentido de donde se quiere ir y que
se quiere ver.
Desde esta perspectiva KML complementa la mayorı́a de los estándares de la OGC,
incluyendo GML (Geography Markup Language), WFS (Web Feature Service) y
WMS (Web Map Service). Actualmente, KML 2.2 utiliza elementos geométricos derivados de GML 2.1.2 cómo puntos o polı́gonos.
Shapefile. El formato ESRI Shapefile [ESR] es un formato de archivo geográfico propietario abierto de datos espaciales desarrollado por la compañı́a ESRI, quien crea y
comercializa software para Sistemas de Información Geográfica como ArcInfo o ArcGIS.
Originalmente se creó para la utilización con su producto ArcView GIS, pero actualmente se ha convertido en formato estándar de facto para el intercambio de información geográfica entre Sistemas de Información Geográfica.
Un Shapefile es un formato vectorial de almacenamiento digital donde se guarda la
localización de los elementos geográficos y los atributos asociados a ellos. El formato
carece de capacidad para almacenar información topológica.
Un shapefile es generado por varios archivos. Al menos se requieren tres archivos que
pueden ser complementados con otros que contengan información sobre la proyección cartográfica o metadatos. Los archivos mı́nimos se enumeran a continuación.
shp
Es el archivo que almacena las entidades geométricas de los objetos.
shx
Este archivo almacena el ı́ndice de las entidades geométricas.
dbf
Este archivo almacena la información de los atributos de los objetos.
Well known text (WKT). El estándar OpenGIS Simple Features Interface [OGCb] proporciona mecanismos comunes y bien definidos para recuperar y almacenar en bases
de datos relacionales y orientadas a objetos caracterı́sticas geográficas. Estas caracterı́sticas definen propiedades como puntos, lı́neas o polı́gonos por medio de cadenas
de texto.
Como ejemplo de WKT se muestra la definición de un punto.
“POINT(25.0 10.0 25.5)”
69
La elección del sistema que realiza el cálculo de rutas, Hesperia.OpenLS, restringe el
almacenamiento de la información geográfica ya que este sistema utiliza PostGIS para almacenar dicha información. Sin embargo esta información únicamente refleja los puntos de
información y los visitantes, por lo que es necesario completarla para tener una visión global de la ubicación. Es decir, se debe representar gráficamente la zona en la que se ubican
los visitantes y los puntos.
La representación geográfica de la zona se lleva a cabo mediante archivos Shapefile ya
que están ampliamente soportados por los sistemas de información geográfica.
4.8.1.2.
Herramientas para visualizar información geográfica.
De forma análoga a los formatos existen multitud de herramientas comerciales que permiten trabajar con este tipo de sistemas, sin embargo solo se estudiarán alternativas bajo la
filosofı́a del software libre y que se centren dar soporte a aplicaciones de escritorio.
GRASS (Geographic Resources Analysis Support System) Sistema de información geográfica (SIG, en inglés Geographic Information System, GIS) utilizado para mantenimiento y análisis de datos geoespaciales, procesamiento de imágenes, generación de
mapas e imágenes, modelado espacial y visualización.
GRASS es un programa de gestión de SIG pensado en trabajar en un entorno multiusuario en una red de ordenadores. Por tanto cada usuario debe tener su propio
entorno de trabajo, es decir su MAPSET al que los demás usuarios pueden entrar
pero no manipular.
Además de estos personales existe un MAPSET especial llamado PERMANENT que
contiene todos aquellos mapas que se consideran acabados, que no van a ser modificados, con lo que ningún usuario podrá modificarlos.
GRASS establece una arquitectura (figura 4.26) para almacenar la información por
medio de una estructura de directorios llamada DATABASE (también llamada GISDBASE), que debe haber sido creada con anterioridad a la ejecución del programa.
Dentro de este directorio el proyecto se organiza almacenando áreas en subdirectorios llamados LOCATIONS. A su vez una LOCATION se define por su sistema de
coordenadas, proyecciones y lı́mites geográficos, y puede contener varios MAPSETs.
Tras realizar el análisis inicial del sistema se puede comprobar que es demasiado
complejo para el propósito buscado, por lo que se descarta esta opción.
Quantum GIS. En la página web de Quantum GIS12 se muestra una descripción inicial de
este sistema. A continuación se muestra la versión traducida al castellano.
Quantum GIS (QGIS) es un Sistema de información geográfica de código abierto
bajo licencia GNU GPL versión 3.113 . QGIS es un proyecto oficial de la Open Source
Geospatial Foundation (OSGeo). Funciona sobre Linux, Unix, Mac OSX y Windows
12
13
Quantum GIS. Open Source Geospatial Foundation. http://www.qgis.org
70
Figura 4.26: Estructura de GRASS
y soporta varios formatos de archivo (basados en vectores y rasters) y de bases de
datos.
Quantum GIS proporciona multitud de funcionalidades para visualizar, editar, analizar datos, y componer mapas, tanto por medio de la aplicación qgis cómo por medio
de librerı́as. Esto permite que qgis sirva como editor de mapas del sistema ya que
permite crear mapas con formato Shapefile.
Cabe destacar que QGIS tiene soporte integrarse con aplicaciones de escritorio para
dos lenguajes de programación: Python y C++. Esta unión se realiza por medio de la
librerı́a gráfica QT, por lo que no es integrable con la interfaz de administración.
uDig. uDig14 es una plataforma de desarrollo de aplicaciones GIS de escritorio, sin embargo también puede utilizarse cómo aplicación GIS de escritorio.
En el caso de utilizarse como una aplicación uDig se ha diseñado para integrarse con
la mayorı́a de los formatos de archivo GIS, bases de datos y servicios web. Permite
trabajar con archivos ESRI Shape, con bases de datos PostGIS, DB2, Oracle Spatial
y ArcSDE.
Como plataforma uDig proporciona módulos Java para la Eclipse RCP (Rich Client
Platform).
Mapnik. En la página web de Mapnik se muestra una descripción de este toolkit y de todas
sus caracterı́sticas. A continuación se muestra una traducción de dicha descripción.
14
User Friendly Desktop Internet GIS. Refractions Research. http://udig.refractions.net/
71
Mapnik15 es un toolkit para el desarrollo de aplicaciones geográficas. Está escrito en
C++, proporciona bindings para Python para facilitar el desarrollo rápido y puede
utilizarse tanto en desarrollos de escritorio ası́ como en desarrollos web.
La versión 0.6 de este toolkit permite integrar la renderización de mapas en la herramienta de administración por medio de la librerı́a gráfica Cairo [WP03]. Gracias a
este mecanismo se reduce drásticamente el tiempo de actualización del mapa ya que
no es necesario llevarlo a disco (por medio de una imagen png o svg) para mostrarlo
después.
Una vez estudiadas las alternativas aquı́ mostradas se ha elegido el toolkit Mapnik para
visualizar los datos geográficos del sistema. Esta elección viene motivada por la simplicidad
y flexibilidad que presenta ası́ cómo por la integración que permite con GTK a través de
Cairo.
4.8.2.
Diseño.
El almacenamiento de posiciones en el sistema se actualiza automáticamente por medio del Directory Service. Este servicio se subscribe al canal de eventos de localización y
cuando los recibe los introduce en la base de datos OpenLS.
Este funcionamiento del Directory Service produce un pequeño daño colateral. En concreto la problemática reside en que un mismo punto puede detectar múltiples dispositivos
bluetooth, ubicándolos sobre la misma posición.
Conceptual y semánticamente este comportamiento es correcto, sin embargo a la hora
de visualizar los dispositivos se presentan todos sobre el mismo punto.
Para solucionar esta problemática se ha introducido un intermediario que resuelve la
posición que se debe almacenar en la base de datos OpenLS antes de la publicación del
evento. El diseño de este intermediario se explica a continuación y su integración con el
sistema se puede ver reflejado en el diagrama de secuencia de la figura 4.27.
Servicio para la integración de posiciones con OpenLS (PositionEngine). Este intermediario utiliza una caché de visitantes-posición conjuntamente con el servicio VisitorsPersistence, permitiendo anotar los visitantes en distintas localizaciones cercanas al
punto que emite el evento. Además gracias a este mediador también es posible diferenciar si el visitante esta en lı́nea.
Para dar soporte a este servicio se ha creado el slice PositionEngine. Este Slice (listado 4.19)contiene la interfaz AVISMI.Position.PositionEngine que a través del método
updatePos permite obtener la posición modificada.
15
Mapnik. Artem Pavlenko. http://www.mapnik.org/
72
Listado 4.19: PositionEngine.ice
module AVISMI {
module P o s i t i o n {
interface PositionEngine {
H e s p e r i a : : MLP : : P o s i t i o n u p d a t e P o s ( H e s p e r i a : : MLP : : P o s i t i o n posNow , s t r i n g mac ) ;
};
};
};
Figura 4.27: Diagrama de secuencia que muestra la integración de PositionEngine
4.8.3.
Implementación.
Los cambios introducidos en el diseño del sistema afectan a dos subsistemas; a la herramienta de administración y al BTPoint.
Integración de los cambios en el diseño en el sistema AdminAVISMI. La clase UI ha sido retocada por medio de la adición de nuevos métodos y atributos necesarios para la
creación y manejo del mapa.
Métodos para el control sobre el mapa. Métodos necesarios para manejar el mapa
y realizar operaciones como el zoom y el refresco. Estos métodos no siguen una
nomenclatura general ya que el nombre del método refleja el evento a tratar. Por
ejemplo, el método zoomOn atiende al evento que emite el botón de aumentar
el zoom sobre el mapa.
73
Atributos involucrados en la generación del mapa. Para conseguir la visualización
de los datos geográficos en forma de mapa se utiliza la librerı́a gráfica Cairo, el
toolkit Mapnik y la base de datos proporcionada por OpenLS (PostGIS).
Mapnik soporta el renderizado del mapa sobre archivos de imagen, pero también sobre un Cairo Context. Trabajando sobre un Cairo Context en lugar de un
archivo de imagen se obtiene una velocidad muy superior a la hora de visualizar
el mapa ya que no tiene que pasar por disco para su visualización, sino que se
obtiene directamente del Cairo Context. Los atributos map, surface y cairoCtx
dan soporte a esta solución.
Una vez obtenida la visualización del mapa se hace necesario mantenerlo actualizado. Para conseguir este propósito se utiliza el mecanismo de notificaciones
que proporciona Postgres, el servicio LISTEN/NOTIFIY.
Para ello es necesario conectar con la base de datos Postgres utilizando el atributo pgConn, subscribirse mediante una consulta LISTEN al servicio y chequear
cada cierto para comprobar si existen notificaciones. También es necesario definir un trigger (listado 4.20) que permita notificar cuando existan cambios en la
tabla que utiliza el mapa como fuente de datos.
Finalmente, y en caso de que existan notificaciones, se volverá a generar el
mapa.
Listado 4.20: Trigger Postgres
CREATE OR REPLACE FUNCTION n o t i f y E l e m e n t ( ) RETURNS t r i g g e r
AS
$resultado$
BEGIN NOTIFY l o c a t i o n E v e n t ;
RETURN NEW;
END;
$ r e s u l t a d o $ LANGUAGE ’ p l p g s q l ’ ;
CREATE TRIGGER g e o d a t a C h a n g e
AFTER INSERT OR UPDATE OR DELETE ON o l s d i r g e o d a t a
FOR EACH ROW
EXECUTE PROCEDURE n o t i f y e l e m e n t ( ) ;
Tras la explicación de los métodos y atributos principales de la clase UI cabe destacar
su funcionamiento multihilo, ya que para manejar los distintos aspectos de la interfaz
es necesario ejecutar varias tareas en paralelo.
En concreto se necesitan tres hilos; uno para la interfaz gráfica, otro para recibir los
eventos del middleware, y el tercero para chequear la existencia de notificaciones
desde Postgres.
Para que los hilos puedan convivir en la aplicación es necesario activar el soporte para
hilos de GObject (tipo básico para GTK) por medio del método gobject.threads init().
74
Una vez inicializado el uso de hilos en la aplicación se pueden utilizar los hilos de
forma transparente a GTK.
Integración de los cambios en el diseño en el sistema BTPoint. El cambio que se realiza en la implementación de este subsistema conlleva dos consecuencias; la primera
consiste en la introducción de un atributo que almacena el proxy al PositionEngine,
mientras que la segunda consiste en la llamada a este servicio antes de publicar el
evento de localización cuando se detecta un dispositivo bluetooth.
4.8.4.
Tras actualizar la herramienta de administración la vista del sistema (figura 4.28) no
varı́a en exceso, sin embargo conviene destacar el sistema PositionEngine y la conexión
entre AdminAVISMI y la base de datos OpenGIS.
75
76
4.9.
Iteración 5. Servidor de Medios.
La elección de las herramientas y el diseño de este subsistema influyen notablemente
en el resto del sistema, ya que se encarga de suministrar la mayor parte del tráfico a través
de la red; por lo que una ralentización del mismo tendrı́a consecuencias directas sobre la
percepción que el visitante recibe del sistema.
Los medios que se distribuyen son de dos tipos claramente diferenciables. Por un lado
tenemos textos y por el otro medios audiovisuales, que pueden ser archivos de audio o
vı́deo. El tratamiento que se realiza de cada uno de ellos también es distinto. Esto se debe a
que los protocolos más adecuados para servir cada medio son diferentes.
4.9.1.
Análisis.
4.9.1.1.
Estudio de tecnologı́as para realizar streaming.
Para elegir la forma de servir los medios se ha realizado un análisis exhaustivo de los
protocolos y herramientas existentes en el mercado, teniendo en cuenta la aceptación y la
eficiencia de cada protocolo ası́ como el carácter de las aplicaciones.
En primer lugar se han consultado los protocolos que dan soporte a este tipo de servicio,
para posteriormente seleccionar herramientas que los implementen. Conviene destacar que,
a pesar de estudiar todas las posibilidades, se utilizará alguna alternativa que se base en
estándares oficialmente aceptados y libres debido a la naturaleza del proyecto.
HTTP. El primer protocolo que se ha considerado ha sido HTTP [Fie99] ya que es el de
mayor calado y esta disponible en prácticamente la totalidad de los dispositivos, bien
sean móviles o estáticos. Sin embargo aunque es posible realizar streaming por medio
de descargas parciales, resulta pesado para realizar streaming de medios audiovisuales. Sin embargo para medios textuales puede ser útil debido a la naturaleza de los
mismos y a la flexibilidad en cuanto a formato y disponibilidad que ofrece este protocolo.
MMS. El MMS [MMS09] (Microsoft Media Services) es el protocolo propietario de Microsoft para realizar streaming. Utiliza una conexión TCP (fiable) para establecer
el control del streaming y puede utilizar UDP o TCP para enviar el flujo de datos.
Aunque esta ampliamente soportado (debido a la gran influencia en el mercado de
Microsoft) no representa ninguna mejora respecto a RTSP.
RTSP/RTP. RTSP [Sch98] (Real Time Streaming Protocol, en castellano Protocolo de Flujo de Datos en Tiempo Real) y RTP [Sch03] (Real Time Transport Protocol, en castellano Protocolo de Transporte en Tiempo Real) son protocolos para el transporte de
datos en tiempo real publicados por la IETF(Internet Engineering Task Force, en castellano Grupo de Trabajo en Ingenierı́a de Internet). Las especificaciones de dichos
protocolos son de dominio público y se utilizan por prácticamente la totalidad de las
herramientas que soportan streaming de datos.
4.9. ITERACIÓN 5. SERVIDOR DE MEDIOS.
77
Cada uno de estos protocolos tiene una función especı́fica, y aunque RTP puede funcionar por si mismo, la combinación de ambos es la mejor forma de realizar el streaming. RTSP es el protocolo de control de comunicaciones y RTP es el protocolo
utilizado para transmitir los datos entre cliente y servidor.
Aunque no es objetivo de este proyecto realizar un análisis exhaustivo de este protocolo, si que es conveniente comprender el funcionamiento del mismo para evaluar
esta alternativa y comprobar que las herramientas lo implementan correctamente. Por
lo que a continuación se ofrecerá una pequeña explicación del funcionamiento del
protocolo.
RTSP es un protocolo no orientado a conexión, por lo que el servidor mantiene una
sesión asociada a un identificador. Habitualmente RTSP utiliza TCP para datos de
control de reproducción y UDP para el flujo de datos multimedia. El protocolo soporta
varias operaciones.
Recuperación de contenidos.
El cliente solicita al servidor un contenido, y este lo sirve vı́a multicast o unicast, dependiendo de si el cliente proporciona el puerto por el que recibirá el
contenido.
Invitación a una conferencia.
Un servidor puede ser invitado a unirse a la reproducción de un contenido en
lugar reproducirlo desde el principio.
Adición multimedia a una presentación existente.
Una vez estudiados los protocolos existentes, se ha pasado elegir la herramienta para
realizar el streaming. Conviene señalar que para realizar streaming a dispositivos móviles
se necesitan adaptar los archivos para conseguir que la calidad de los mismos sea adecuada
para que se puedan procesar de forma fluida. Para solventar este problema se deben volver
a codificar los archivos reduciendo la calidad del vı́deo y del audio a la requerida por el
dispositivo móvil. Para este propósito también se han estudiado diversas herramientas como
se comprobará posteriormente.
Cabe destacar que debido a la naturaleza del proyecto se han buscado herramientas que
esten bajo la licencia GPL, sin embargo también se ha estudiado la posibilidad de utilizar
herramientas cuyas licencias sean cercanas a GPL.
VideoLAN - VLC Media Player. VideoLAN16 es un proyecto software que produce código abierto y libre para video, todo ello bajo la licencia GPL versión 2 .
La herramienta principal que engloba gran parte del proyecto VideoLAN es VLC
Media Player, cuyas caracterı́sticas más destacables son el soporte multiplataforma,
el soporte de multitud de formatos audiovisuales, la posibilidad de reproducir y emitir
flujos de datos sobre varios protocolos de streaming, y realizar conversiones entre
archivos de diferentes formatos.
Helix. Helix17 es la rama de código abierto de RealNetworks (bajo la licencia RPSL [Rea],
16
17
VLC media player. VideoLAN. http://www.videolan.org
Helix Community. RealNetworks.http://helixcommunity.org
78
RealNetworks Public Source License). Bajo esta rama están varios proyectos que
permiten manejar contenidos multimedia. Estos proyectos son:
Helix DNA Client
Este proyecto representa la parte central del proyecto Helix, ya que permite dar
soporte a la reproducción y codificación de multitud de formatos, ası́ como al
manejo de flujos multimedia por medio de varios protocolos.
Helix Player
Helix Player es un reproductor de medios de propósito general, multiplataforma
que utiliza el Helix DNA Client núcleo para su funcionamiento.
Helix Server
Se trata de un servidor de archivos multimedia que permite distribuir archivos
con formato mp3 y formatos propietarios de RealNetworks (rm, ra, rv) por medio de varios protocolos de streaming (RTSP, HTTP,...)
Helix Producer
Helix Producer es una herramienta que permite generar flujos en formato propietario de RealNetworks (rm, rmvb).
Darwing Streaming Server18 . Es la versión de código libre del Apple QuickTime Streaming Server, que permite enviar streaming de audio/video a clientes vı́a RTSP. Está disponible para varios sistemas operativos (Windows, MacOX, Linux) bajo la licencia
APSL [APS08].
Esta herramienta permite servir archivos con formato mp3, mov, mp4 y 3gp a cualquier dispositivo, y para ello utiliza listas de reproducción.
Cabe destacar que para que realice correctamente el streaming los archivos deben ser
marcados con metadatos sobre las condiciones con las que se deben poner a disposición de los clientes.
Mencoder. Es la herramienta de la suite MPlayer que se encarga de realizar la codificación entre formatos. Esta herramienta permite convertir entre una gran variedad de
formatos, sin embargo aún no soporta la codificación a formato 3gp.
FFmpeg. El proyecto FFmpeg19 ofrece una serie de herramientas para grabar, convertir y
generar flujos de audio y vı́deo. Este proyecto está desarrollado sobre Linux y bajo
la licencia GPL versión 2.1, y además puede ser compilado bajo la mayorı́a de los
sistemas operativos. Las herramientas que ofrece este proyecto se enumeran a continuación.
ffmpeg
Es una herramienta en lı́nea de comandos que permite convertir entre distintos formatos multimedia, permitiendo a su vez modificar la calidad del archivo
(alterar bitrate, los frames por segundo, etc...)
19
FFmpeg. http://www.ffmpeg.org
79
ffserver
ffserver es un servidor de flujos multimedia que soporta RTP, RTSP y HTTP.
ffplay
Reproductor básico basado en librerı́as SDL.
libavcodec
Es la liberı́a que contiene los codificadores y decodificadores de audio.
libavformat
La librerı́a libavformat contiene los demuxers y muxers para los distintos contenedores multimedia
GPAC. El framework GPAC20 , ubicado bajo licencia GNU versión 2.1, abarca diferentes
aspectos multimedia cómo codificadores de audio y vı́deo, marcado y encapsulado de
archivos multimedia, reproducción de archivos multimedia, etc ...
El framework está escrito ı́ntegramente en ANSI C, lo que permite que sea portable
a un gran número de plataformas (Windows, Linux, Embedded Linux, WindowsCE,
SymbianOS) y se compone de tres herramientas:
Osmo4
Osmo4 es el reproductor audiovisual de la suite, y permite reproducir archivos de diferentes formatos, reproducir la mayorı́a de protocolos de transporte
de audio y vı́deo, recuperar información gráfica y animaciones de los archivos
multimedia, etc.
MP4Client
Esta la herramienta equivalente a Osmo4 en lı́nea de comandos.
MP4Box
MP4Box permite codificar y multiplexar entre varios formatos (MP4, 3GPP,
etc...), además permite realizar marcas en los archivos para permitir realizar
streaming.
4.9.1.2.
Elección de tecnologı́as para realizar streaming
Se han buscado herramientas de código abierto, evitando utilizar software privativo,
siguiendo de éste modo la filosofı́a del proyecto.
Una vez realizado este estudio se han elegido dos alternativas para servir estos medios.
mini-httpd Se trata de un servidor web muy ligero que ofrece los mecanismos suficientes
para albergar los archivos textuales que necesitan servirse. Está albergado bajo la
licencia GNU GPL versión 2, y permite utilizar mecanismos de seguridad.
Utilizando un servidor web para este propósito se obtienen varios beneficios.
20
GPAC. GPAC Project on Avanced Content. http://gpac.sourceforge.net
80
Se puede representar la información en diferentes formatos, bien sea en texto
plano o formateado con HTML [HTM99].
Facilita ampliar la base de conocimiento del sistema. Desde el punto de vista del
visitante el procedimiento para obtener un documento del sistema es idéntico a
obtenerlo de la web, por lo que introduciendo documentos ubicados en la web
por medio su URL [BLCM94] se puede ampliar la base de conocimiento de
forma transparente al sistema.
Se acerca la aplicación final al visitante ya que el uso de navegadores web esta
ampliamente aceptado.
Darwin Streaming Server Este servidor es la versión de código abierto del QuickTime
Streaming Server. Cuenta con soporte multiplataforma (Windows, Linux, Solaris y
MacOX) y está bajo la licencia APSL [APS08]. Este servidor es capaz de distribuir
archivos con formato QuickTime, MPEG-4 y 3GPP por medio del protocolo RTSP
[Sch98].
Para servir los archivos este servidor requiere que se realice una marca sobre cada archivo. Esta marca viene en forma de metadatos que engloban parámetros adicionales
para las conexiones RTSP. Conviene señalar que existen herramientas bajo la licencias libres que permiten realizar este marcado, en concreto se ha utilizado el comando
MP4Box de la suite GPAC.
4.9.2.
Diseño.
Para dar soporte a la distribución de medios se ha creado una interfaz slice, basándose
en el diagrama de casos de uso de la figura 4.29, que define el servicio que se debe ofrecer.
Este slice se puede ver en el listing 4.21.
Listado 4.21: MediaServer.ice
module AVISMI {
module Media {
i n t e r f a c e MediaServer {
v o i d s e r v e r V i d e o ( s t r i n g idDoc ) ;
v o i d s e r v e r A u d i o ( s t r i n g idDoc ) ;
v o i d s e r v e r T e x t ( s t r i n g idDoc ) ;
v o i d s t o p V i d e o ( s t r i n g idDoc ) ;
v o i d s t o p A u d i o ( s t r i n g idDoc ) ;
v o i d s t o p T e x t ( s t r i n g idDoc ) ;
};
};
};
La interfaz AVISMI.Media.MediaServer ofrece dos conjuntos de métodos para manejar
medios textuales y audiovisuales. Por un lado se definen los métodos server* con los que
se solicita al servicio que distribuya un medio. Por el otro lado se tienen los métodos stop*
que permiten parar la distribución del medio.
81
Figura 4.29: Diagrama de casos de uso del MediaServer
4.9.3.
Implementación.
Conviene señalar que se ha diseñado el sistema de manera que admita distintos servidores multimedia. Para ello se ha utilizado el patrón factorı́a. En la figura 4.30 se puede
observar que la clase que implementa la factorı́a es StreamingServer por medio del método
createServer.
En caso de que se necesite utilizar otra alternativa para servir los archivos multimedia
se deberı́a crear una clase que herede de StreamingServer, que implemente sus métodos
abstractos (start, stop) para la nueva alternativa. Además habrı́a que actualizar la factorı́a
para permitir este nuevo tipo de servidores.
La integración entre las clases que realizan el streaming y la que ofrece el servicio al sistema se lleva a cabo por medio de la clase MultimediaServerI. Esta clase implementa las interfaces AVISMI.Media.MediaServer y AVISMI.Persitence.ChangeAdminPersistentServices.
Por medio de la primera esta clase ofrece el control al sistema del streaming de archivos,
mientras que gracias a la segunda consigue actualizar los servidores teniendo en cuenta los
cambios en el MuseumPersistence.
4.9.4.
Una vez creado el servidor de medios la vista del sistema se muestra en la figura 4.31.
82
Figura 4.30: Diagrama de clases del MediaServer
83
84
4.10.
Iteración 6. Obtención de informes.
En esta iteración se aborda la creación de informes, para lo que es necesario tener dos
aspectos fundamentales en cuenta: el almacenamiento de estadı́sticas y la representación de
la información mediante informes.
4.10.1.
Análisis.
4.10.1.1.
Alternativas de diseño en el almacenamiento de estadı́sticas.
El almacenamiento persistente de las estadı́sticas, de la misma forma que el almacenamiento persistente en el resto del sistema, se puede realizar de múltiples formas; utilizando
una base de datos relacional, por medio de archivos, etc.
Sin embargo también es posible utilizar FreezeMaps[MH08][capitulo 36]. Utilizando
FreezeMaps es posible almacenar la información siguiendo la filosofı́a de la orientación a
objetos, en consonancia con todo el proyecto. Además es posible ordenar los mapas por
medio de claves secundarias, facilitando de ese modo la recuperación de datos a partir de
fechas.
Teniendo esto en cuenta se ha elegido este método de almacenamiento (Freeze Maps)
para dar soporte a la persistencia de las estadı́sticas.
4.10.1.2.
Elección de la tecnologı́a para la representación de informes.
Una de las necesidades del proyecto es recabar información sobre las visitas para exponerlas de forma lo más clara posible a la administración, ayudando ası́ a la toma de
decisiones.
Para conseguir este propósito se ha considerado generar gráficas representativas para
distintas estadı́sticas, para lo que se hace necesario una librerı́a que permita generar dichas
gráficas. Cabe destacar que la librerı́a debe estar soportada por el lenguaje en el que se
encuentra la herramienta de administración, por lo que se han estudiado librerı́as acordes a
esta restricción.
PyCha21 . Paquete que permite la creación de gráficos simples, en concreto diagramas circulares, diagramas de barras (horizontal y vertical) y de lı́neas. Para ello utiliza la
librerı́a gráfica Cairo. A pesar de ser una posible solución hay que destacar que no se
tiene control adicional sobre las gráficas ya que no pueden realizarse modificaciones
sobre los gráficos para representar información adicional.
Python Google Chart22 . Se trata de un wrapper para Python de la API Google Chart, por
lo tanto es un servicio web para la creación de gráficos en el que se solicita un gráfico
a partir de una URL[BLCM94].
El principal problema de este método es la dependencia de la conexión y la velocidad
de la misma, ya que sin dicha conexión no se pueden obtener los gráficos, por lo que
no es una solución válida este sistema.
4.10. ITERACIÓN 6. OBTENCIÓN DE INFORMES.
85
pyCairoChart23 . Módulo para Python que ofrece mecanismos para crear gráficos en dos
dimensiones usando la librerı́a gráfica Cairo. Aunque la complejidad de uso es pequeña no ofrece las garantı́as necesarias para el proyecto ya que adolece de falta
documentación y los ejemplos no están suficientemente depurados.
matplotlib. Matplotlib24 es una potente librerı́a para la creación de gráficos en dos dimensiones. Permite generar cualquier tipo de gráfico estadı́stico ası́ como combinar varios
de ellos o crear uno acorde a las necesidades del usuario. Además ofrece una extensa
documentación ası́ como una gran fiabilidad. Por todos estos motivos es la librerı́a
elegida para la generación de gráficos en el proyecto.
Una vez analizada la tecnologı́a para realizar informes gráficos integrados en la interfaz
se ha buscado una tecnologı́a para convertir estos informes en archivos manejables por el
usuario. En concreto se realizan exportaciones de informes a formato PDF, utilizando para
ello la librerı́a de código abierto para la creación de PDF de ReportLab25 .
4.10.2.
Diseño.
El diagrama de casos de uso, relativo a la herramienta de gestión, actualizado en esta
iteración se muestra en la figura 4.32; prácticamente este diagrama es una especialización
del diagrama de casos de uso general, atendiendo a la parte relacionada con el actor Administrador.
Hasta el momento se han atendido todos los casos de uso salvo los involucrados en la
obtención de informes. Analizando estos casos de uso se han realizado las modificaciones
pertinentes en el diseño del sistema y se han implementado los subsistemas necesarios para
satisfacerlos. Todo ello se detalla a continuación.
Para dar soporte al almacenamiento de estadı́sticas, desde el punto de vista del diseño,
se ha modificado el archivo Slice Visitors.ice (listado 4.22). En concreto se ha creado una
interfaz que permite manejar las estadı́sticas y cuatro clases que dan soporte al almacenamiento de las mismas; Key, ConsultedDocument, VisitedObject y OldVisitor.
24
25
matplotlib. John Hunter, Darren Dale y Michael Droettboom. http://matplotlib.sourceforge.net
The ReportLab Open Source PDF. ReportLab. http://www.reportlab.org/rl toolkit.html
86
Figura 4.32: Diagrama de casos de uso de AdminAVISMI (Iteración 6)
c l a s s Key {
s t r i n g macBT ;
l o n g d a t e ; / / UNIX t i m e s t a m p ( S e c o n d s )
};
c l a s s C o n s u l t e d D o c u m e n t e x t e n d s Key {
s t r i n g idDocument ;
};
c l a s s V i s i t e d O b j e c t e x t e n d s Key {
string idObject ;
};
c l a s s O l d V i s i t o r e x t e n d s Key {
Ice : : StringSeq route ;
Features vFeature ;
int totalTime ;
TimePoints spentTimePoints ;
};
Por medio de la interfaz AVISMI.Visitors.Statistics (listado 4.23)se permite el acceso
a las estadı́sticas, permitiendo su recuperación de forma eficiente por medio de distintos
métodos de recuperación.
Para conseguir este propósito se han utilizado Freeze Maps con “Freeze Index” adicionales que proporcionan nuevos atajos de búsqueda utilizando para ello los atributos de la
clase que se almacena en el FreezeMap. Conviene destacar que son muy eficientes y que
permiten indexar a partir de atributos incluso una vez ya se hayan creado y poblado los
FreezeMaps.
87
interface
Statistics {
void a d d V i s i t o r ( V i s i t o r v ) ;
ConsultedDocumentSeq getConsultedDocuments ( ) ;
VisitedObjectSeq getVisitedObjects () ;
OldVisitorSeq getOldVisitors () ;
ConsultedDocumentSeq getConsultedDocumentsSince ( long d a t e ) ;
V i s i t e d O b j e c t S e q g e t V i s i t e d O b j e c t s S i n c e ( long d a te ) ;
OldVisitorSeq g e t O l d V i s i t o r s S i n c e ( long d a te ) ;
ConsultedDocumentSeq getConsultedDocumentsBetween ( long dInic , long
dEnd ) ;
V i s i t e d O b j e c t S e q g e t V i s i t e d O b j e c t s B e t w e e n ( l o n g d I n i c , l o n g dEnd ) ;
O l d V i s i t o r S e q g e t O l d V i s i t o r s B e t w e e n ( l o n g d I n i c , l o n g dEnd ) ;
};
4.10.3.
Implementación.
La implementación que da soporte al sistema encargado de las estadı́sticas viene dado
por el subsistema Statistics y por el subsistema VisitorsPersistence debidamente modificado. Además también hay que modificar el AdminAVISMI para permitir que el usuario final
interactúe con la obtención de estadı́sticas.
Integración del diseño y la implementación en el sistema Statistics. Gracias a este subsistema, cuyo diagrama de clases se puede ver en la figura 4.33, se consigue dar
soporte al almacenamiento persistente de las estadı́sticas. Para ello se implementa la
interfaz AVISMI.Visitors.Statistics ofreciendo los métodos necesarios para introducir
y recuperar información. Cabe destacar que esta implementación se ha realizado en
Java ya que este subsistema es menos dinámico que el que se encarga de los visitantes
en lı́nea.
La implementación se ha llevado a cabo por medio de dos clases; StatisticsI y ServerStatistics.
La clase StatisticsI realiza la implementación de la interfaz AVISMI.Visitors.Statistics,
utilizando FreezeMaps para almacenar la información relativa a los objetos ConsultedDocument, VisitedObject y OldVisitor.
ServerStatistics alberga la Ice.Application y administra la conexión con Freeze necesaria para manejar los Freeze Maps.
Integración del diseño y la implementación en el sistema VisitorsPersistence. En este subsistema se ha realizado una modificación que permite que cuando un visitante sale del
sistema su información asociada sea enviada al soporte persistente de estadı́sticas. Para ello se ha dotado a este subsistema de un proxy hacia Statistics y se ha modificado
el método encargado de eliminar el visitante en lı́nea, permitiendo que su información
asociada se almacene en el soporte persistente.
88
Figura 4.33: Diagrama de clases (reducido) del sistema Statistics
Integración del diseño y la implementación en el sistema AdminAVISMI. Una vez establecido el soporte persistente de estadı́sticas, ası́ como su acceso y manejo, se ha
procedido a diseñar e implementar la obtención de informes desde la herramienta de
gestión.
La obtención de informes se puede considerar una mejora de la herramienta ya creada,
tanto de forma lógica como a nivel de implementación. Teniendo esto en cuenta se
ha diseñado como una clase que puede funcionar de manera independiente a dicha
herramienta, facilitando de ese modo la elaboración de pruebas.
Para llevar a cabo esta implementación se ha creado una clase base, la clase Report,
que contiene los métodos para la creación de gráficas junto con un método abstracto,
encargado de generar el informe gráfico, que deben implementar las clases que la
especialicen.
Además se han creado tres clases que heredan de esta clase base y se encargan de la
realización de tres tipos de informe.
VisitedReport. Gracias a esta clase se atiende a la necesidad de crear informes con
las estadı́sticas sobre los visitantes del museo.
TimeReport. Por medio de esta clase se cubre la obtención de informes sobre el
tiempo se invierte en la visita.
RouteReport. La clase RouteInform permite obtener informes sobre cual es la ruta
más seguida por los visitantes del museo.
Cabe destacar que también se ha hecho necesario crear dos pequeñas librerı́as; la
primera es libDate y se encarga del manejo de fechas utilizando el módulo time de
Python. La segunda es myRlab y contiene métodos que encapsulan los métodos de la
librerı́a reportlab.
Utilizando la librerı́a myRlab se ha creado la clase PdfReport que permite crear un
informe en formato PDF.
Una vez creadas las clases necesarias para la obtención de informes se ha procedido
a la integración de dichas clases en la herramienta de administración.
89
Desde el punto de vista del diseño de la interfaz de usuario se ha habilitado un panel para la obtención de estadı́sticas. En el anexo I se puede ver una captura de la
herramienta de administración en la que se muestra dicho panel.
Para realizar la integración se han añadido dos nuevos atributos a la herramienta de
administración.
Atributo report. El atributo report es una instancia de la clase Inform. Esta es la
clase padre de los informes, y permite aislar la creación de informes de diversa
ı́ndole como son el informe de visitas, de ruta y de tiempo.
Atributo StatisticsPrx. El último proxy que necesita la interfaz es StatisticsPrx que
permite obtener la información estadı́stica necesaria para la generación de informes.
También se han creado los métodos que capturan los eventos de la interfaz y permiten
invocar a la clase que genera los informes.
En la figura 4.34 se muestra una visión reducida del diagrama de clases de la herramienta de administración.
4.10.4.
Una vez creado el servidor de estadı́sticas y modificada la herramienta de administración
la vista del sistema actual se muestra en la figura 4.35.
90
Figura 4.34: Diagrama de clases de AdminAVISMI (Iteración 6)
91
92
4.11.
Iteración 7. Distribución de la aplicación del dispositivo móvil.
En esta iteración se centra el interés en la distribución de la aplicación del dispositivo
móvil. Para ello se debe elegir la forma más adecuada para hacer llegar la aplicación de la
forma más simple posible al visitante.
4.11.1.
Análisis.
Existen distintas alternativas para realizar esta distribución, sin embargo debido a la
orientación hacia pequeños museos se busca una que no conlleve un gasto adicional en
personal. Por ello se ha elegido un método de distribución automático que realiza el descubrimiento de dispositivos y el envı́o selectivo de la aplicación.
Los dispositivos que quieran recibir la aplicación deberán tener activado el Bluetooth.
El sistema de distribución detecta el dispositivo y le envı́a la aplicación, anotando la fecha,
la hora y el dispositivo al que se envı́a dicha aplicación. De ese modo se tiene control sobre
la distribución ya que dependiendo de esos parámetros se puede decidir cuando volver a
distribuir la aplicación.
4.11.2.
Diseño.
El diseño del sistema de distribución no afecta al resto de sistemas ya que es totalmente
independiente.
Para conseguir un servicio que sea accesible se ha creado el archivo Slice Spammer.ice
(listado 4.24) que ofrece una interfaz para manejar la distribución de archivos.
Listado 4.24: Spammer.ice
module AVISMI {
module Spammer {
i n t e r f a c e SpammerFile {
void startSpamm ( s t r i n g
v o i d stopSpamm ( ) ;
file ) ;
};
};
};
Como se puede ver en el archivo Slice (listado 4.24) se ha creado la interfaz AVISMI.Spammer.SpammerFile que solo contiene los métodos starSpamm y stopSpamm. El primero
se encarga de iniciar la distribución del archivo cuyo nombre es pasado por parámetro. El
segundo se encarga de parar la distribución del archivo.
4.11. ITERACIÓN 7. DISTRIBUCIÓN DE LA APLICACIÓN DEL DISPOSITIVO MÓVIL.93
4.11.3.
Implementación.
La implementación de este servicio se ha llevado a cabo gracias a la utilización de
varias librerı́as. En concreto se ha utilizado la librerı́a obexftp 26 perteneciente al proyecto
OpenObex para el envı́o de archivos y las librerı́as BlueZ 27 para Python para realizar el
descubrimiento de dispositivos.
La figura 4.36 representa el diagrama de clases del Spammer. En este diagrama se puede
apreciar la separación de clases que existe en este subsistema.
Figura 4.36: Diagrama de clases del Spammer
La clase que alberga el servicio es Spammer. Cabe destacar que es una Ice.Application
que se encarga de crear el adaptador de objetos al que se añade un objeto de la clase SpammerI, actuando de sirviente.
La clase SpammerI realiza la implementación de la interfaz AVISMI.Spammer.SpammerFile,
valiéndose para ello de la clase Sender.
Sender hereda de la clase bluez.DeviceDiscoverer heredando los métodos que proporcionan el control sobre el descubrimiento de servicios Bluetooth. A su vez utiliza dos clases
auxiliares: FileDB e IdentifyBT.
Gracias a FileDB se puede almacenar y recuperar información relativa a los dispositivos
a los que se les ha distribuido la aplicación. Por medio de la clase IdentifyBT se puede
identificar el tipo de dispositivo Bluetooth a partir de su “device class”, consiguiendo de
este modo discriminar aquellos dispositivos Bluetooth que no sean apropiados para albergar
la aplicación.
26
27
OpenObex. Open OBEX proyect. http://dev.zuckschwerdt.org/openobex
BlueZ - Official Linux Bluetooth protocol stack. BlueZ Project. http://www.bluez.org
94
Por último hay que destacar que se ha creado una pequeña aplicación que se encarga
de enviar el archivo al dispositivo Bluetooth. Esta aplicación está escrita en C y hace uso
de la librerı́a obexftp. Gracias a esta aplicación la clase Sender puede enviar el archivo tras
detectar el dispositivo Bluetooth.
4.11.4.
La vista final del sistema que se muestra en la figura 4.37 prácticamente no difiere de
la vista en la iteración 6 ya que sólo aporta el sistema Spammer encargado de distribuir la
aplicación a los dispositivos móviles.
4.11. ITERACIÓN 7. DISTRIBUCIÓN DE LA APLICACIÓN DEL DISPOSITIVO MÓVIL.95
96
4.12.
Iteración 8. Despliegue del sistema
La puesta en funcionamiento del sistema, en un entorno real, se debe llevar a cabo en
una iteración a parte ya que conlleva multitud de factores a tener en cuenta. Entre estos
factores destacan los medios hardware y software, que deben ser analizados para elegir la
mejor alternativa, y la recopilación de información para el sistema.
4.12.1.
Análisis del hardware necesario
Los requerimientos mı́nimos para el funcionamiento del sistema se enumeran a continuación.
Distribuidor de la aplicación del dispositivo móvil. Para que la aplicación que permite
interactuar a los visitantes con el sistema sea distribuida adecuadamente es necesario
disponer de un nodo con soporte Bluetooth.
Este nodo debe tener unas caracterı́sticas software mı́nimas que se enumeran a continuación.
Sistema operativo Debian GNU/Linux.
El sistema de distribución de la aplicación del dispositivo móvil ha sido desarrollado para esta plataforma, por lo que el nodo debe tener instalado este sistema
operativo.
Soporte Bluetooth.
Debido al método de distribución, por medio de Bluetooth, es necesario tener
soporte para esta tecnologı́a. Además se necesitan varias librerı́as que se integran vı́a instalación de paquetes con el sistema operativo.
En concreto es necesario instalar los paquetes libopenobex1, libopenobex1-dev,
y python-bluez.
Middleware Zeroc Ice.
También es imprescindible la instalación del middleware utilizado para el desarrollo del sistema. Esto se realiza fácilmente por medio la instalación del paquete
zeroc-ice.
Con respecto a las especificaciones hardware del nodo conviene señalar que no es
necesario un dispositivo de altas prestaciones, es decir, un ordenador de bajo coste puede servir para este propósito; únicamente es preciso que tenga un dispositivo
bluetooth.
Puntos de localización. Para que el sistema adapte los contenidos al visitante es necesario
que recoja su información contextual. Para ello es necesario que existan puntos de
localización ası́ cómo una alimentación por medio de la interacción con la aplicación
del dispositivo móvil.
4.12. ITERACIÓN 8. DESPLIEGUE DEL SISTEMA
97
Estos puntos deben tener prácticamente los mismos requisitos que se han especificado
para el distribuidor de la aplicación del dispositivo móvil. Únicamente varia en que
no es necesario que se instale la librerı́a libopenobex1.
Nótese que estos puntos soportan muy poca carga de trabajo, están dedicados a una
tarea muy especı́fica, por lo que un ordenador de bajo coste es lo más indicado para
servir como punto de este tipo.
Red inalámbrica. Los dispositivos móviles interactúan con el sistema por medio de una
conexión inalámbrica, por lo que es indispensable disponer de una red inalámbrica
para que el sistema sea funcional.
Gestión. El almacenamiento de los datos del sistema, ası́ como los sistemas con mayor
complejidad deben, deben estar permanentemente accesibles y prestando un servicio
de calidad para garantizar el buen funcionamiento del sistema.
Nótese que cada uno de los sistemas de mayor complejidad puede ubicarse en un nodo
fı́sicamente distinto, sin embargo también es posible realizar un despliegue sobre el
mismo nodo.
Cabe destacar que desde el punto de vista del despliegue lógico (de las aplicaciones
software y su configuración) es indiferente desplegar sobre uno o varios nodos, gracias al servicio de distribución de aplicaciones que ofrece el middleware; IcePatch2.
Teniendo esto en cuenta se enumeran los requisitos software que deben contener este
tipo de puntos.
Sistema operativo Debian GNU/Linux.
Postgres y PostGIS.
Las posiciones geográficas, necesarias para el cálculo de rutas y la localización
de objetos cercanos a uno dado, se almacenan en una base de datos Postgres
con soporte PostGIS. Teniendo esto en cuenta se necesita instalar los paquetes
postgresql-8.3, postgresql-8.3-postgis y python-pygresql.
Hesperia OpenLS.
El sistema encargado del servicio de ruta y directorio lo proporciona Hesperia OpenLS, por lo que es necesario instalar correctamente este sistema. Este
proceso de instalación se detalla en el anexo II.
Sun Java Runtime Enviroment 5 o superior.
Es necesario disponer de la máquina virtual de Java para dar soporte a la persistencia de los datos y las estadı́sticas del museo.
Python 2.5.
La mayor parte de los subsistemas están escritos en Python, por lo que es necesario disponer del interprete de Python en su versión 2.5. Este interprete viene
incluido en la instalación básica del sistema operativo.
Middleware Zeroc Ice.
98
Todo el sistema está integrado gracias a la utilización en todos los sistemas
del middleware Zeroc Ice, por lo que se hace imprescindible tener instalado el
paquete zeroc-ice.
pyGTK y libglade.
La herramienta de administración utiliza la librerı́as GTK y libglade, por lo que
es necesario instalar los paquetes python-gtk y libglade para conseguir satisfacer
las necesidades de dicha herramienta.
Mapnik.
La visualización del mapa que se realiza en la herramienta de administración se
lleva a cabo gracias a la librerı́a Mapnik, por lo que es necesario que se instale
el paquete python-mapnik.
4.12.2.
Recopilación de información para el sistema
La recopilación de información se puede dividir en dos tareas; la obtención de medios
textuales y audiovisuales para satisfacer las necesidades de información del museo y la
creación del mapa de visualización del museo.
Obtención de medios. Es necesario recopilar la información que se desee ofrecer a los
visitantes, introduciéndola coherentemente en el sistema.
Para conseguir coherencia al introducir la información en el sistema se debe ubicar
el medio en el directorio que se indique en archivo de configuración del MediaServer. Además se debe introducir la información relativa a ese medio por medio de la
herramienta de administración AdminAVISMI.
Creación del mapa de visualización. Para conseguir visualizar el sistema de forma precisa es necesario diseñar el mapa del museo en formato Shapefile. Para este propósito
se puede utilizar la herramienta qgis. Además es necesario establecer las posiciones
geográficas de los puntos de localización del sistema, instanciando con las propiedades adecuadas los BTPoint necesarios.
4.12.3.
Puesta en funcionamiento del sistema.
4.12.3.1.
Creación de imágenes mı́nimas auto ejecutables.
Para facilitar el despliegue de los puntos de localización se ha creado una imagen del
sistema operativo auto-ejecutable desde usb con todo el software descrito en el punto anterior. De ese modo sólo es necesario configurar algunos archivos para integrar un nodo de
localización en el sistema.
Esto ha sido posible gracias a la utilización de la suite live-helper, consiguiendo de este
modo un sistema operativo mı́nimo que contiene únicamente la funcionalidad necesaria
para dar soporte al sistema de localización.
Capı́tulo 5
Resultados
Una vez finalizado el proyecto se ha conseguido crear una arquitectura distribuida capaz
de ofrecer servicios a dispositivos móviles dependiendo del contexto en el que se desenvuelvan. A continuación se describen con mayor detalle los resultados obtenidos.
Distribución selectiva de contenidos. Por medio de la arquitectura creada en el proyecto
se consigue ofrecer la información contextual más acorde al visitante en cada momento. Es decir, se consigue ofrecer al visitante la información más relevante en cada
momento. Para ello se utiliza la información relativa a su ubicación en el museo, los
parámetros de entrada (duración de la visita, tipo de público, lenguaje y deficiencia)
y su estado actual (documentos consultados, objetos visitados, etc).
Localización y visualización de dispositivos. La arquitectura creada permite seguir en tiempo real la posición aproximada de los visitantes en el museo. Aprovechando esta información se consigue, por medio de la herramienta de administración, visualizar en
un mapa a los visitantes del museo.
Distribución automática y selectiva de aplicaciones. Tras evaluar distintos métodos para
hacer llegar la aplicación que debe correr en el dispositivo móvil, se ha creado un
sistema capaz de detectar dispositivos y enviarles de forma selectiva un archivo.
Cabe destacar que este sistema no sólo es útil para la distribución de aplicaciones,
sino que también es útil en el campo de la publicidad.
Recopilación de información relativa a los visitantes. Con el objetivo de facilitar la toma de decisiones se recaba información sobre las visitas que se realizan. Conviene
señalar que la información recopilada no es de carácter privado, ya que no se recogen identificaciones ni datos relativos a la moral de los visitantes; la información es
estadı́stica y de ahı́ se infieren los resultados obtenidos en los informes.
Creación de la aplicación del dispositivo móvil. Los visitantes del museo utilizan una aplicación que se integra en su dispositivo móvil sin necesidad de instalar ningún otro
software. Esto ha sido posible gracias a la utilización de la tecnologı́a J2ME de Sun,
ya que la máquina virtual que soporta este tipo de aplicaciones está integrada en la
inmensa mayorı́a de dispositivos móviles.
100
CAPÍTULO 5. RESULTADOS
Sin embargo esta tecnologı́a solo sirve de base ya que es necesario integrarla con el
middleware y dotarla de una interfaz de usuario atractiva. Para ello se han utilizado
dos tecnologı́as:
Ice-E. Es la versión reducida de Ice para la tecnologı́a J2ME. Conviene destacar, como principal diferencia con Ice, que en esta versión sólo se permite la utilización
de estructuras en los slices.
LWUIT. Tecnologı́a creada por Sun para crear interfaces de usuario con tecnologı́a
J2ME.
Sistema de navegación orientativo. El sistema proporciona información a cerca de como
llegar desde un punto de información al elegido por el visitante. Esto se consigue
gracias a la integración satisfactoria del proyecto con el servicio Hesperia OpenLS.
Explotación y documentación del servicio Hesperia.Location. Por medio de la utilización y comprensión de este servicio se ha generado la documentación asociada al
mismo, aportando además el ejemplo de utilización que se desprende de su uso en el
proyecto.
Explotación y documentación del servicio Hesperia.OpenLS. Gracias a la utilización de
este servicio en el presente proyecto se ha generado documentación acerca de la instalación y configuración de este servicio. Además también se han creado programas
sencillos, a modo de ejemplo, que permiten comprender fácilmente la arquitectura y
la utilización del servicio.
Ponencia explicativa sobre Hesperia.OpenLS e Ice-E en dispositivos móviles. Tras la documentación y utilización de los diversos servicios ofrecidos por el proyecto Hesperia, y la utilización de la tecnologı́a Ice en dispositivos móviles, la experiencia del
autor en esta materia es suficientemente amplia como para ofrecer una charla explicativa sobre estas tecnologı́as.
En concreto se ha realizado una ponencia, junto con otros miembros del grupo ARCO y dirigida al resto de integrantes del proyecto Hesperia, sobre el activo Hesperia.OpenLS y la tecnologı́a Ice-E sobre J2ME.
Creación del servicio Hesperia.IndirectPropertyService. Véase anexo III.
Creación del servicio Hesperia.GISPropertyService. Véase anexo IV.
El sistema se ha diseñado de forma modular, permitiendo la separación fı́sica y lógica
de los subsistemas que lo componen. Esto proporciona varias ventajas que se detallan a
continuación.
Delimitación del alcance de fallos. Teniendo en cuenta que cada subsistema satisface un
conjunto de objetivos cercanos semánticamente, y que pueden ubicarse en localizaciones fı́sicas distintas, en caso de fallos se puede determinar el conflicto con bastante
precisión.
101
Además la separación fı́sica permite que ante caı́da de algún servicio el resto del
sistema se mantenga funcional (siempre que el servicio no sea crı́tico para el sistema),
siendo posible instanciar ese servicio en otro nodo de forma transparente al sistema
en ejecución.
Diversificación de la carga de trabajo. En un sistema en explotación la cantidad de información que se maneja puede llegar a ser un factor crı́tico. Este hecho afecta a los
subsistemas principales como el Server, el MediaServer o el VisitorsPersistence, por
lo que se podrı́a optar por ubicarlos en máquinas dedicadas a cada servicio. De este
modo se garantiza el funcionamiento del sistema bajo elevada cantidad de información.
Alto grado de integración. El diseño modular del sistema, ası́ como la utilización del lenguaje de definición de interfaces proporcionado por Ice, permite fácilmente la introducción de nuevos subsistemas y la modificación de los existentes.
Un ejemplo de posible ampliación del sistema serı́a la introducción de nuevos puntos de localización que utilizaran otras tecnologı́as para informar de la posición del
visitante. Para ello el nuevo subsistema sólo deberı́a implementar la interfaz que permite acceder a la publicación de eventos de localización, dejando el resto del sistema
invariable.
Como ejemplo de modificación de un elemento existente se podrı́a decidir ampliar
el servidor de medios para que sirva otro distinto a los actuales. Para ello se realizarı́a una herencia de la interfaz AVISMI.Media.MediaServer y se proporcionarı́an
los métodos de control pertinentes.
102
CAPÍTULO 5. RESULTADOS
Capı́tulo 6
Conclusiones y propuestas.
6.1. Conclusiones
6.2. Propuestas
6.1.
Conclusiones
En esta sección se detallan las conclusiones a las que se ha llegado tras la finalización
del proyecto.
Necesidad de utilizar estándares. Durante el desarrollo del proyecto se han estudiado y
utilizado diversos estándares. Gracias a la utilización coherente de estos estándares,
ha sido posible integrar diversas partes del proyecto con otros sistemas existentes,
obteniendo beneficios muy relevantes para el sistema.
Concretamente la utilización del sistema de los estándares ofrecidos por el Open
Geospatial Consortium Inc (en concreto OpenLS y EWKT) ha permitido la utilización de una base datos geográfica como PostgreSQL (mediante la extensión PostGIS),
lo que a su vez ha permitido la representación gráfica por medio de la librerı́a Mapnik.
Necesidad de diseños abiertos y modulares. El dinamismo de los sistemas software, junto con la constante evolución tecnológica requieren que los sistemas sean altamente
tolerantes a cambios. Esto implica la realización de sistemas con diseños que permitan mecanismos de inclusión de nuevas funcionalidades y encapsulen aquellas que
sean lo suficientemente especı́ficas.
Reutilización de software. La importancia de la reutilización de software se refleja en diversos aspectos.
Reducción del tiempo de implementación. Este aspecto es el más evidente a la hora de hablar de la reutilización del software, y conlleva reducir gastos a la hora
de construir el sistema.
104
CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS.
La reducción de tiempo permite invertir dicho tiempo en resolver nuevos problemas. Esto conlleva un progreso tecnológico exponencial, ya que cada vez se
tiene más software funcional con el que crear nuevo software alimentando de
ese modo el ciclo de creación de software.
Incremento de la calidad. La utilización de código fiable (exhaustivamente probado
mediante baterı́as de pruebas automatizables) utilizado en otros proyectos, tales
como librerı́as especı́ficas, permite reducir los errores al mı́nimo en las partes
reutilizadas. Esto permite incrementar la calidad del sistema resultante.
Creación de un prototipo de sistema real mediante la utilización de software libre. Por
medio de la realización de este proyecto se ha creado un sistema que podrı́a ser directamente explotable, y todo ello desde la utilización de herramientas basadas en la
filosofı́a del software libre. Con ello se demuestra que es posible la creación de sistemas explotables comercialmente por medio de este tipo de herramientas, reduciendo
los gastos de coste que implica la utilización de software privativo y garantizando la
estabilidad del sistema.
En concreto para instalar este sistema sólo es necesario realizar inversiones en el hardware necesario y en el mantenimiento del mismo. Además debido a la orientación que
se ha dado al proyecto el sistema funciona de forma automática por lo que, una vez
implantado, no se hace imprescindible la supervisión de ningún personal especializado.
6.2.
Propuestas
Un sistema de este tipo debe estar abierto a cambios ya que las tecnologı́as de la información avanzan rápidamente. Durante el diseño de la arquitectura del sistema se ha tenido
este aspecto en cuenta, y sin modificar en exceso la arquitectura del mismo se pueden realizar diversas mejoras. A continuación se muestran algunas mejoras interesantes que se
podrı́an realizar en el sistema.
Realidad aumentada. Actualmente el sistema ofrece de forma dependiente del contexto
medios estáticos, es decir, vı́deos, audios y textos almacenados. Sin embargo se puede
mejorar este servicio ofreciendo objetos en realidad aumentada.
Esto se podrı́a realizar utilizando una imagen de referencia en los objetos que dispongan de realidad aumentada. Dependiendo de la posición en la que se visualice la
imagen ası́ se mostrará la realidad aumentada. Como el sistema conoce la posición
del visitante podrá determinar el objeto sobre el que se interactúa y enviar los datos
en consecuencia.
En este nuevo sistema existen multitud de factores a tener en cuenta, tales como quien
realiza el renderizado (dispositivo móvil o el servidor), como se realiza la comunicación de control de la realidad aumentada, etc.
6.2. PROPUESTAS
105
Mejora en la toma de decisiones. También es posible captar más estadı́sticas y realizar
minerı́a de datos más depurada, obteniendo de este modo informes de mayor utilidad
y complejidad.
Agentes inteligentes. Utilizando la arquitectura del sistema es posible crear agentes que
extrapolen la información objetiva basada en eventos, obteniendo conclusiones por
sı́ mismos. Por ejemplo un agente podrı́a reaccionar ante aglomeraciones de personas en una determinada sala activando el aire acondicionado, avisando al conserje,
estableciendo rutas alternativas para el resto de visitantes, etc.
Gracias a la arquitectura distribuida y desacoplada del sistema la integración de este
tipo de agentes con el sistema se podrı́a realizar con un mı́nimo de cambios, que
además únicamente afectarı́an a un subconjunto de subsistemas.
Inclusión de sensores. El sistema está utilizando dispositivos bluetooth para determinar la
posición del visitante en el museo, sin embargo la arquitectura del sistema permite
la utilización de cualquier sensor de forma transparente al mismo. De este modo se
pueden utilizar otro tipo de sensores para proporcionar posiciones al sistema.
106
CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS.
Bibliografı́a
[AGH05]
Ken Arnold, James Gosling, y David Holmes. The Java Programming Language. Addison-Wesley Professional, 2005.
[APS08]
Apple. Apple Public Source License, Version 2.0, 2008. URL http:
//www.opensource.apple.com/apsl/.
[BLCM94]
Tim Berners-Lee, CERN, y L Masinter. Uniform Resource Locators
(URL). RFC 1738, 1994. URL http://www.ietf.org/rfc/
rfc1738.txt.
[Blu04]
Bluetooth SIG. Specification of the Bluetooth System, 2004. URL http:
//www.bluetooth.com.
[CCM08]
The Object Management Group. Common Object Request Broker Architecture (CORBA) Specification, Version 3.1 OMG. Part 3: CORBA Component Model, 2008. URL http://www.omg.org.
[COR08a]
The Object Management Group. Common Object Request Broker Architecture (CORBA) Specification, Version 3.1 OMG. Part 2: CORBA Interoperability, 2008. URL http://www.omg.org.
[COR08b]
The Object Management Group. Common Object Request Broker Architecture (CORBA) Specification, Version 3.1 OMG. Part1: CORBA Interfaces, 2008. URL http://www.omg.org.
[ESR]
ESRI. Shapefile Technical Description. URL http://www.esri.
com/library/whitepapers/pdfs/shapefile.pdf.
[Fie99]
Roy Fielding. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Informational), 1999. URL http://www.ietf.org/rfc/rfc2616.
txt.
[GPS08]
Department of Defense of United States of America. Global Positioning
System Standard Positioning Service Performance Standard, September
2008.
[HTM99]
World Wide Web Consortium. HyperText Markup Language 4.01, 1999.
URL
http://www.w3.org/Protocols/rfc2616/rfc2616.
html.
107
108
BIBLIOGRAFÍA
[HV02]
Michi Henning y Steve Vinoski. Programación Avanzada en Corba con
C++. PEARSON EDUCACIÓN S.A, Madrid, España, 2002.
[JBR99]
Ivar Jacobson, Grady Booch, y James Rumbaugh. The unified software development process. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999.
[KB00]
Martin Fowler Kent Beck. Planning Extreme Programming. AddisonWesley, 2000.
[Keo03]
James Edward Keogh.
Hill/OsborneK, 2003.
[Kra07]
Andrew Krause. Foundations of GTK+ Development. Apress, 2007.
[MH08]
Mark Spruiell Michi Henning. Distributed Programming with Ice. 2008.
URL http://www.zeroc.com.
[MLP04]
Open Mobile Alliance. Mobile Location Protocol (MLP), March 2004.
[MMS09]
Microsoft Corporation. Microsoft Media Server (MMS) Protocol Specification, 2009. URL http://msdn.microsoft.com/en-us/
library/cc234711(PROT.10).aspx.
[OGCa]
Open Geospatial Consortium. GML in JPEG 2000 for Geographic
Imagery Encoding. URL http://www.opengeospatial.org/
standards/gmljp2.
[OGCb]
Open Geospatial Consortium. OpenGIS Simple Features Interface Standard
. URL http://www.opengeospatial.org/standards/sfa.
[OGC07a]
Open Geospatial Consortium Inc. Geography Markup Language Encoding
Standard (GML), 2007. URL http://www.opengeospatial.org/
standards/gml/.
[OGC07b]
Open Geospatial Consortium Inc. Keyhole Markup Language (KML),
2007. URL http://www.opengeospatial.org/standards/
kml/.
[OGC07c]
Open Geospatial Consortium Inc.
OpenGIS Location Service
(OpenLS) Implementation Standards, 2007.
URL http://www.
opengeospatial.org/standards/ols.
[PR85]
Jon Postel y Joyce Reynolds. File Transfer Protocol. RFC 959, 1985. URL
http://tools.ietf.org/rfc/rfc959.txt.
[Pri05]
Nissanka Bodhi Priyantha. The Cricket Indoor Location System, 2005.
URL http://cricket.csail.mit.edu/.
[Pro]
The GNOME Usability Project. GNOME Human Interface Guidelines 2.2.
J2ME: the complete reference.
McGraw-
BIBLIOGRAFÍA
109
[Rea]
RealNetworks. RealNetworks Public Source License Version 1.0. URL
https://community.helixcommunity.org/Content/rpsl.
[Ros95]
Guido Van Rossum. Python Reference Manual. Mayo 1995.
[RR00]
Niles Ritter y Mike Ruth. GeoTIFF Format Specification GeoTIFF Revision 1.0, December 2000. URL http://www.remotesensing.org/
geotiff/spec/geotiffhome.html.
[Sch98]
Henning Schulzrinne. Real Time Streaming Protocol. RFC 2326 (Informational), 1998. URL http://www.ietf.org/rfc/rfc2326.txt.
[Sch03]
Henning Schulzrinne. RTP: A Transport Protocol for Real-Time Applications. RFC 3550 (Informational), 2003. URL http://www.ietf.
org/rfc/rfc3550.txt.
[SKC+ 04]
John A. Sorensen, Kare J. Kristoffersen, Anders Cervera, Martin Schiotz,
Thomas Lynge, Zoltan Safar, y Lars Birkedal. An infrastructure for context
dependent mobile multimedia communication, October 2004.
[Sle01]
Sleepycat Software. Berkeley DB. Sams Publishing, 2001.
[SMS06]
Richard Matthew Stallman, Roland McGrath, y Paul Smith. GNU Make.
Free Software Fundation, April 2006. URL http://www.gnu.org/
software/make/manual.
[SOA07]
World Wide Web Consortium. SOAP Version 1.2, 2007. URL http:
//www.w3.org/Protocols/rfc2616/rfc2616.html.
[SQL09]
International Organization for Standarization. ISO/IEC 9075-1:2008, Database languages SQL Part 1: Framework, 2009.
[Str86]
Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley,
New York, 1986.
[TM02]
David Taubman y Michael Marcellin. JPEG2000: Image Compression
Fundamentals, Standards and Practice (The International Series in Engineering and Computer Science). Kluwer Academic Publishers Group,
2002.
[UML07]
Object Management Group. OMG Unified Modeling Language (OMG
UML). Superstructure, V2.1.2, 2007. URL http://www.omg.org/
technology/documents/formal/uml.htm.
[VVV+ 03]
Efstratios Valavanis, Christopher Ververidis, Michalis Vazirgianis, George
Polyzos, Kjetil Norvag, y Michael Wallbaum. MobiShare: Sharing ContextDependent Data and Services from Mobile, 2003.
[W3C01]
W3C. Web Services Description Language (WSDL) 1.1, 2001. URL
http://www.w3.org/TR/wsdl.
110
BIBLIOGRAFÍA
[Wal02]
Michael Wallbaum. Wheremops: An Indoor Geolocation System, 2002.
[WiF07]
The Institute of Electrical y Electronics Engineers. IEEE Standard for
Information technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks - Specific requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 2007. URL http://standards.
ieee.org/getieee802/download/802.11-2007.pdf.
[WP03]
Carl Worth y Keith Packard. Cairo: Cross-device Rendering for Vector
Graphics. July 2003.
[XML08]
World Wide Web Consortium. Extensible Markup Language (XML)
1.0 (Fifth Edition), 2008. URL http://www.w3.org/TR/2008/
REC-xml-20081126/.
[YCJRHh+ 05] Chen Yi-Chao, Chiang Ji-Rung, Chu Hao-hua, Huang Polly, y Tsui Arvin Wen. Sensor-assisted wi-fi indoor location system for adapting to
environmental dynamics, 2005. URL http://portal.acm.org/
citation.cfm?id=1089466.
Capı́tulo 7
Anexos
111
112
7.1.
CAPÍTULO 7. ANEXOS
Anexo I. Herramienta de administración.
En este anexo se muestran capturas de la herramienta de administración en funcionamiento. Concretamente se muestra una captura por panel, incluyendo además una captura
por elemento del menú.
7.1.1.
Panel para el manejo de documentos.
Figura 7.1: Panel para el manejo de documentos
El panel para el manejo de documentos (figura 7.1) está separado en dos partes. En la
parte izquierda del panel se muestran las propiedades del documento seleccionado en la
lista de documentos de la parte derecha. Sobre la parte relativa a las propiedades se realizan
las modificaciones e inserciones pertinentes, utilizando para ello la barra de botones situada
en la parte inferior del panel.
7.1. ANEXO I. HERRAMIENTA DE ADMINISTRACIÓN.
7.1.2.
113
Panel para el manejo de objetos del museo.
Figura 7.2: Panel para el manejo de objetos del museo
El panel para el manejo de objetos del museo (figura 7.2) tiene la misma estructura que
el de manejo de documentos, es decir, está separado en dos partes. En la parte izquierda del
panel se muestran las propiedades del objeto, mientras que en la parte derecha se muestra
la lista de objetos existentes en el museo.
En la parte inferior del panel se encuentran los botones que permiten realizar las modificaciones, inserciones o eliminaciones necesarias.
114
7.1.3.
Panel para el manejo de relaciones entre objetos.
Figura 7.3: Panel para el manejo relaciones entre objetos
A diferencia de los paneles anteriormente mencionados aquı́ se presentan tres listas
(figura 7.3). La primera muestra todos los documentos disponibles en el sistema, mientras
que la segunda muestra los documentos que están asociados al objeto seleccionado en la
tercera columna.
Por medio de los botones “+” y “-” se pueden manejar las asociaciones entre los objetos
y los documentos, anotando los cambios por medio del botón ubicado en la parte inferior
del panel.
7.1.4.
115
Panel para el manejo de puntos de información.
Figura 7.4: Panel para el manejo de puntos de información
Este panel(figura 7.4) permite manejar la ubicación y descripción de los puntos de información del museo. Está diseñado de la misma forma que los paneles de manejo de documentos y objetos, es decir, en su parte izquierda muestra las propiedades del punto seleccionado
en la parte derecha.
En la parte inferior está la barra de botones que permite realizar las modificaciones,
inserciones o eliminaciones necesarias.
116
7.1.5.
Panel para la visualización de la localización de visitantes.
Figura 7.5: Panel para la visualización de la localización de visitantes
Por medio de este panel (figura 7.5) se obtiene una vista general del museo en tiempo
real. Únicamente contiene botones para manejar el zoom y la posición del foco.
7.1.6.
117
Panel para la obtención de informes.
Figura 7.6: Panel para la obtención de informes
El panel para la obtención de informes se divide en dos partes. En la parte izquierda se
selecciona el tipo de estadı́stica que se desea obtener, mientras que en la parte derecha se
obtiene el gráfico que representa dicha estadı́stica. Para generar este informe se utilizan los
botones de la barra de botones situada en la parte inferior del panel.
118
7.1.7.
Barra de menú.
La barra de menú, ubicada en la parte superior de la interfaz de usuario, está dividida en
cinco menús.
7.1.7.1.
Menú archivo
El primero, empezando de izquierda a derecha, es el menú de archivo y únicamente
ofrece la posibilidad de salir de la aplicación (figura 7.7).
Figura 7.7: Menú Archivo
7.1.7.2.
Menú importar
El siguiente menú, el segundo empezando por la izquierda, es importar. Por medio de
este menú se ofrece la posibilidad de poblar el sistema a partir de archivos con el formato
adecuado.
Figura 7.8: Menú Importar
Los formatos que deben seguir los archivos de entrada se especifican a continuación.
Documentos
Cada lı́nea del archivo debe seguir el siguiente formato.
Id|Descripción|URL|Tipo|Lenguaje|Importancia|Audiencia|Deficiencia|TpoVisita|NumVisitas
Nótese que cada campo está separado del siguiente por el carácter “|”. A continuación
se detallan los campos de la lı́nea.
Campo
Id
Descripción
URL
Tipo
Lenguaje
Importancia
Audiencia
Deficiencia
TpoVisita
Valor
String
String
String
[0-2]
[0-7]
Double
[0|1]
[0-2]
Integer
NumVisitas
Integer
119
Significado
Identificador unı́voco del documento
Descripción del documento
ubicación del documento
Textp, Audio, Video
ES,EN,DE,FR,JA,RU,IT,CH
Relevancia asignada al documento
Significados Niño, Adulto
Ninguna, Sordo, Invidente
Tiempo estimado que se invierte en consultar el
documento
Número de consultas que ha recibido el documento
Ejemplo:
Capitulo 1|En un lugar de la mancha...|/quijote/cap1.txt|0|0|10.0|1|0|10|0
Objetos
Las lı́neas de los archivos que definen objetos del museo deben seguir el siguiente
formato.
Id|IdPtoInformacion|Descripción|Importancia|TpoVisita|ObjsRels|NumVisitas
A continuación se especifica el significado de cada valor.
Campo
Valor
Id
String
IdPtoInformacion String
Descripción
Importancia
TpoVisita
ObjsRels
NumVisitas
Significado
Identificador unı́voco del documento
Identificador del punto de información en el que
se ubica el objeto
String
Descripción del objeto
Integer Estimación de la relevancia del objeto
Integer Estimación del tiempo invertido en la visita del
objeto
[IdObj] Secuencia de identificadores de objeto (separados por “,”) relacionados a este
Integer Número de visitas recibidas
Ejemplo:
Quijote|13|Hidalgo caballero|5.0|5||0
Puntos
El formato de los archivos que definen puntos de información es el siguiente:
Claves|Valores|Puntos|Direcciones
Los campos se definen a continuación.
120
Campo
Claves
Valor
[String]
Significado
Secuencia de claves (separadas por
un espacio en blanco )que definen
las propiedades del punto. Al menos debe contener type, id (integer)
y description
Valor
[String]
Valores de las propiedades de información
Puntos
[double double double ,] Localización en la que se ubica el
punto de información
Direcciones [String,]
Direcciones asociadas al punto
Ejemplo:
type id description—escalera 0 escalera1|26.0 20.0 0.0,|Escalera Hall-Edificio,
Relaciones entre documentos y objetos
Los archivos para la definición de relaciones entre documentos y objetos se muestra
a continuación.
ObjectId|Documents
El significado de estos campos se muestra en la tabla siguiente.
Campo
Valor
Significado
ObjectId
String
Identificador del objeto
Documents [String] Lista de documentos (separados por “,”) asociados al objeto
Ejemplo:
Quijote|Capitulo 1, Capitulo 2
7.1.7.3.
Menú exportar.
El menú exportar, el tercero empezando por la izquierda, ofrece la posibilidad de recuperar la información del sistema en archivos con el formato especificado en el punto
anterior.
Figura 7.9: Menú Exportar
7.1.7.4.
121
Menú OpenLS.
Este menú proporciona dos operaciones que permiten interactuar con la base de datos
OpenLS.
Vaciar BBDD. Esta opción limpia los datos relativos a las coordenadas y ubicaciones de
los puntos de información.
Actualizar BBDD. Por medio de esta opción se consigue introducir los datos procedentes
del sistema, en concreto los puntos de información, permitiendo la elaboración de
rutas entre ellos.
Figura 7.10: Menú OpenLS
7.1.7.5.
Menú Ayuda.
Por último se encuentra el menú de ayuda gracias al que se puede obtener información
acerca de la herramienta.
Figura 7.11: Menú Ayuda
122
7.2.
Anexo II. Instalación de Hesperia OpenLS.
El objetivo de este anexo es mostrar cómo utilizar los servicios OpenLS (de directorio
y de ruta) que se ofrecen desde el proyecto Hesperia. Para ello se deben seguir unos pasos
previos que explican a lo largo del documento.
Cabe destacar que este anexo se centra en la instalación y configuración del sistema
Hesperia OpenLS sobre GNU/Linux.
7.2.1.
Software necesario
A continuación se enumeran los paquetes Debian necesarios para la instalación del sistema. se recomienda utilizar las últimas versiones de los repositorios de Debian unstable.
Además para la obtención del paquete python-pyodbc es necesario el siguiente repositorio:
deb h t t p : / / a r c o . i n f −c r . uclm . e s / ˜ f r a n c i s c o . moya / d e b i a n / . /
deb−s r c h t t p : / / a r c o . i n f −c r . uclm . e s / ˜ f r a n c i s c o . moya / d e b i a n / . /
postgresql-8.3
postgresql-8.3-postgis
python-networkx (0.36-2)
python-matplotlib (0.98.3-3)
python-numpy
python-pyodbc
python-setuptools
unixodbc
odbcinst
odbc-postgresql
libgeos-dev
libatlas3gf-3dnow
libatlas3gf-altivec
libatlas3gf-base
libatlas3gf-sse
libatlas3gf-sse2
libatlas3gf-v9
7.2. ANEXO II. INSTALACIÓN DE HESPERIA OPENLS.
123
liblapack3gf
Librerias Python.
Shapely (http://pypi.python.org/pypi/Shapely)
• Descargar Shapely-*.tar.gz
• Ejecutar ”sudo python setup.py install”
Es necesario disponer de las slices de Hesperia y del código del servicio OpenLS. Ambos directorios deben estar al mismo nivel, es decir, colgando del mismo directorio.
7.2.2.
Configuración de la base de datos OpenLS
7.2.2.1.
Creación de un usuario para la base de datos postgresql y de la base de datos
con soporte PostGIS
Pasos a seguir:
1. sudo su - postgres
2. createuser -s -P -e <usuario>
3. createdb -O <dueño> <databasename>
4. createlang plpgsql -d <databasename>
5. psql <databasename> -f /usr/share/postgresql-8.3-postgis/lwpostgis.sql
6. psql <databasename> -f /usr/share/postgresql-8.3-postgis/spatial ref sys.sql
7. psql -d <databasename> -f <db-schema.sql>
7.2.2.2.
Configuración del archivo odbc.ini
Pasos a seguir:
1. sudo odbcinst -i -d -f /usr/share/psqlodbc/odbcinst.ini.template
2. sudo cat /usr/share/psqlodbc/odbcinst.ini.template >> /etc/odbc.ini
Nota.- /usr/share/psqlodbc/odbcinst.ini.template, este archivo es proporcionado por el paquete
odbc-postgresql
124
7.2.3.
Vista final del archivo odbc.ini
La configuración final del archivo odbc.ini para aceptar conexiones a OpenLS debe
quedar como se muestra a continuación; Nótese que es necesario añadir manualmente la
entrada [openls], pudiendo ser neceario especificar un ’Port’ y cambiar el ’Servername’
dependiendo del ambiente en el que se utilice la base de datos.
[ P o s t g r e S Q L ANSI ]
Description
= P o s t g r e S Q L ODBC d r i v e r ( ANSI v e r s i o n )
Driver
= / u s r / l i b / odbc / p s q l o d b c a . s o
Setup
= / u s r / l i b / odbc / l i b o d b c p s q l S . s o
Debug
= 0
CommLog
= 1
[ PostgreSQL Unicode ]
Description
= P o s t g r e S Q L ODBC d r i v e r ( U n i c o d e v e r s i o n )
Driver
= / u s r / l i b / odbc / p s q l o d b c w . s o
Setup
= / u s r / l i b / odbc / l i b o d b c p s q l S . s o
Debug
= 0
CommLog
= 1
[ openls ]
Description
Driver
Setup
Database
TraceFile
Trace
Servername
=
=
=
=
=
=
=
H e s p e r i a −OpenLS
/ u s r / l i b / odbc / p s q l o d b c a . s o
/ u s r / l i b / odbc / l i b o d b c p s q l S . s o
openls
/ tmp / o p e n l s . l o g
Yes
localhost
Anexo.- Para ejecutar los tests de Hesperia-OpenLS hay que crear el usuario openls con la
password 123456.
7.3. ANEXO III. HESPERIA INDIRECTPROPERTYSERVICE.
7.3.
Anexo III. Hesperia IndirectPropertyService.
7.3.1.
Hesperia.PropertyService
125
La mayorı́a de los objetos de cualquier aplicación Hesperia tienen multitud de propiedades asociadas que no son necesarias en todos los contextos pero que facilitan la configuración del sistema global. Por ejemplo, los dispositivos disponibles en la red pueden emplearse con total transparencia de localización. Un interruptor puede asociarse a cualquier
bombilla o fluorescente del complejo y de hecho el interruptor no necesita más información que una simple referencia al objeto que va a controlar. Sin embargo desde el punto de
vista del administrador de la red resulta más que conveniente disponer de una representación espacial de la posición real de los dispositivos, ası́ como de un icono representativo de
su función. Toda esta información se requiere en un momento puntual pero no es imprescindible para el correcto funcionamiento del sistema una vez configurado. Supondrı́a una
sobrecarga excesiva añadir este tipo de propiedades a las interfaces de los objetos.
Por este motivo en el middleware de Hesperia se dispone de un servicio de propiedades
desacoplado de los propios objetos. Esto permite que se habiliten bases de datos persistentes
con las propiedades de un subdominio de la red, se controle el acceso a estas propiedades y
se disponga de esta información en un entorno arbitrariamente escalable.
El servicio de propiedades de Hesperia está inspirado en el PropertyService de CORBA. Sin embargo, a diferencia de él, en Hesperia el servicio es fuertemente tipado, lo que
constituye una importante ventaja para detectar errores y para simplificar la programación.
7.3.2.
Hesperia.IndirectPropertyService
Para satisfacer cualquier método de almacenamiento de propiedades y mantener la transparencia a la hora de obtener propiedades se ha creado la interfaz PropertySetDefIndirect,
ubicada en el archivo /usr/share/slice/Hesperia/IndirectPropertyService.ice.
i n t e r f a c e PropertySetDefIndirect extends PropertySetDef {
v o i d d e f i n e P r o p e r t y W i t h C a l l b a c k ( s t r i n g theName ,
P : : T theValue ,
PropertySetDef∗ callback )
throws InvalidPropertyName ,
ConflictingProperty ,
UnsupportedTypeCode ,
UnsupportedProperty ,
ReadOnlyProperty ;
};
Esta interfaz extiende el comportamiento del PropertySetDef, añadiendo un método que
permite definir propiedades con un proxy asociado. Este proxy permite utilizar otro servidor
de propiedades para obtener propiedades que se almacenen de forma distinta a las demás.
Para adaptar el servidor de propiedades (PropertySetDef ) a servidor de propiedades
indirecto (PropertySetDefIndirect) y que permita realizar peticiones de propiedades a otros
servidores se ha dotado al PropertySetDefIndirect de un mapa freeze, llamado mapCallbacks,
que permite almacenar de forma persistente los proxys a las propiedades indirectas. De este
modo cuando un cliente solicite una propiedad el PropertySetDefIndirect buscará su valor,
126
a partir de su proxy asociado si es necesario, y lo retornará. Hay que tener en cuenta que
PropertySetDefIndirect hereda de PropertySetDef por lo que también permite almacenar
propiedades de forma análoga a éste por medio del mapa freeze properties. Este comportamiento se ilustra en la figura 7.12.
Figura 7.12: Comportamiento del IndirectPropertyService
7.4. ANEXO IV. HESPERIA GISPROPERTYSERVICE
7.4.
127
Anexo IV. Hesperia GISPropertyService
El GISPropertyService permite recuperar datos de un cliente OpenGIS ofreciéndolos
cómo propiedades. Para ello se ha implementado la interfaz PropertySetDef, almacenando
los valores de las propiedades en el GIS. De este modo se pueden aislar las propiedades
geográficas delegando la responsabilidad de almacenar dichas propiedades en el GISProperyService.
Definiendo propiedades en el PropertySetDefIndirect con el callback adecuado, para
este caso con un proxy al GISPropertyService, se consigue almacenar las propiedades en el
sistema GIS de forma transparente al sistema de propiedades.
Para llevar a cabo la implementación de este activo se han implementado las interfaces
Hesperia.PropertySet y Hesperia.PropertySetDef teniendo en cuenta las peculiaridades de
un sistema GIS.
En concreto se hace necesario realizar una conversión entre tipos MLP y consultas
EWKT(Extended Well Known Text). Para llevar a cabo estas conversiones se han creado las clases ShapeFactory y QueryFactory. ShapeFactory genera objetos MLP a partir de
cadenas con formato EWKT, mientras que QueryFactory genera cadenas EWKT a partir de
objetos MLP como se puede ver en la figura 7.13.
Cabe señalar que esta implementación es especı́fica para PostGIS y para la base de datos
Hesperia.OpenLS, no obstante PostGIS sigue el estandar OpenGIS Simple Features Interface Standard lo que conlleva que implementación también sigue este estándar. Además es
fácilmente modificable para adaptarla para conectar con otro sistema GIS, por lo que sirve
de ejemplo para futuras implementaciones sobre otros sistemas GIS.
128
Figura 7.13: Diagrama de clases del GISPropertyService
7.5. ANEXO V. PROYECTO HESPERIA.
7.5.
129
Anexo V. Proyecto Hesperia.
“El proyecto Hesperia tiene por objeto el desarrollo de tecnologı́as que permitan la
creación de sistemas punteros de seguridad, vı́deo vigilancia y control de operaciones de
infraestructuras y espacios públicos. El proyecto surge para dar respuesta a una demanda
sostenida a medio y largo plazo, en particular, en paı́ses de la Unión Europea y en Estados
Unidos. La gestión integrada de seguridad y control de operaciones permitirá la implantación de sistemas rentables que, en este momento, no existen en el mercado.” 1
Las tecnologı́as del proyecto resolver la seguridad en dos tipos de escenarios:
Permitir gestionar la seguridad y las operaciones de infraestructuras públicas especialmente sensibles, como subestaciones eléctricas, en gas, depósitos de agua o estaciones de telecomunicaciones.
Incrementar de forma sustancial los niveles de seguridad de grandes espacios públicos, como aeropuertos, estaciones de ferrocarril, puertos, centros de ciudades especialmente en zonas peatonales, centros comerciales, etc.
Las caracterı́sticas a resolver más importantes en este proyecto son las siguientes:
Detectar amenazas a ciudadanos e instalaciones.
Presentar la información del entorno de forma adecuada y fácil de entender.
Garantizar la seguridad en el acceso a la información del sistema.
Garantizar la privacidad de las personas.
Investigar hechos e incidentes que permitan prevenir futuras amenazas.
Proporcionar información sı́ncrona de las operaciones del sistema que permita incrementar el control y mejorar futuras actuaciones.
Este proyecto está parcialmente financiado por el CDTI, organismo adscrito al Ministerio de Industria Turismo y Comercio, invirtiendo un 45 % del presupuesto, proviniendo el
restante del sector privado.
En este proyecto participan las siguientes empresas: Indra Software Labs, Unión Fenosa,
o Tecnobit, SAC Control, Technosafe, Visual Tools y Brainstorm Multimedia. Por otro lado,
están también presentes las siguientes Universidades e instituciones públicas: Universidad
de Castilla La Mancha, Universidad de Granada, Universidad de Extremadura, Universidad
Politécnica de Madrid, Universidad de las Palmas, Universidad Politécnica de Valencia,
Universidad Politécnica de Cataluña, Centro Superior de Investigaciones Cientı́ficas(CSIC)
y el Centro Tecnológico del Paı́s Vasco (Ikerlan).
1
Proyecto Hesperia. https://www.proyecto-hesperia.org/

universidad de castilla-la mancha escuela superior

Transcripción

Documentos relacionados

Mapeo facial de emociones sintéticas - UPM ASLab

UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR

memoria

Extracción de Información

Visualización de medios participativos en entornos urbanos

XARE: Marco de desarrollo para sistemas colaborativos conscientes

Wireless Corba para Robots móviles

Mecanismos para la detección de ataques e intrusiones

an´alisis l´exico robusto

aretusa: sistema de reputaci´on para bittorrent

Aprendizaje Activo para Clasificación de Preguntas

DWN Ganancias garantizadas 2016

Monográfico. Red Temática

PhD thesis - NLP Group at UNED

Primeros pasos en Maxima

MANUAL DE INSTALACION Y REPARACIÓN SERIE - Ice-O

José Mar´ıa Ca˜nas Plaza - GSyC

Función picadillo determinista al grupo G_2 y su aplicación en