Realidad 3

MODELO DE CONTEXTO PARA REALIDAD AUMENTADA

´ AGUDELO TORO ANDRES

UNIVERSIDAD EAFIT ESCUELA DE INGENIER´IA ´ DEPARTAMENTO DE INFORMATICA Y SISTEMAS MEDELL´IN 2004

MODELO DE CONTEXTO PARA REALIDAD AUMENTADA

´ AGUDELO TORO ANDRES

Proyecto de grado para optar al titulo de Ingeniero de Sistemas

Asesores Profesor Helmuth Trefftz Profesor Juan F. Cardona

UNIVERSIDAD EAFIT ESCUELA DE INGENIER´IA ´ DEPARTAMENTO DE INFORMATICA Y SISTEMAS MEDELL´IN 2004

Nota de Aceptaci´on

Presidente del Jurado

Jurado

Jurado

Medell´ın, 1 de Noviembre de 2004

A mi familia

Powered by Google

AGRADECIMIENTOS

La realizaci´on de este trabajo no habr´ıa sido posible sin en el apoyo de mi familia. Agradezco a mi madre Alba Luc´ıa, hermanas Adriana y Mar´ıa Alejandra, abuela Emilia y t´ıa Alejandra por su apoyo durante mi carrera y elaboraci´on de ´este escrito. Agradezco a mis asesores Helmuth Trefftz y Juan Francisco Cardona, y evaluadores Mar´ıa V´elez y Carlos Correa por su colaboraci´on y orientaci´on. Agradezco adem´as a los integrantes del Laboratorio de Realidad Virtual de la Universidad EAFIT y del Center for Advanced Information Processing en Rutgers University por su apoyo y participaci´on en la construcci´on de los dos sistemas de Realidad Aumentada.

RESUMEN

Las tecnolog´ıas de Realidad Aumentada (RA) permiten presentar informaci´on virtual en el mundo real. La Realidad Aumentada toma el papel de interfaz de usuario de la informaci´on digital en el mundo. Un sistema de software de realidad aumentada se separa de los sistemas tradicionales pues interact´ uan en gran medida con el usuario y su entorno. En su definici´on cl´asica, la Realidad Aumentada es s´olo un tipo de ambiente virtual en el mundo real, y por tanto m´etodos de desarrollo de RA se han tomado de la Realidad Virtual y la Computaci´on Gr´afica. No obstante, lograr la combinaci´on realvirtual en la RA es compleja y no debe consistir simplemente en sobreponer un mundo sobre el otro. En la mayor´ıa de los casos las aplicaciones de RA requierir´an de m´etodos apropiados para estar al tanto de lo que sucede en el entorno. En tal caso, los m´etodos de abstracci´on son de vital importancia. El modelo de datos de la RA debe ser flexible, extensible y con la potencia suficiente para representar informaci´on del mundo real y virtual. Otra ´area de investigaci´on ha enfrentado el problema de la representaci´on del mundo previamente. La Computaci´on Ubicua y las Aplicaciones Dependientes del Contexto estudian los sistemas de software que act´ uan de acuerdo a la informaci´on del ambiente o contexto. Esta ´area ha podido establecer caracter´ısticas fundamentales del contexto y encontrar modelos de datos para representarlo. En este trabajo se presentar´a un modelo contexto para RA. Se trata de modelo de datos orientado a objetos, en el cual, la informaci´on del contexto es estructurada en un conjunto de objetos organizados en forma de grafo, describiendo entidades reales o virtuales. Las ventajas encontradas en el uso de este modelo de datos se comparan con el modelo tradicional. Se hace un an´alisis preliminar de las desventajas te´oricas de el modelo previo y luego una evaluaci´on pr´actica de dise˜ no con base en un caso de estudio. Se comprueba el cumplimiento de un conjunto de requerimientos de dise˜ no propuestos. Se concluye que el modelo tradicional es limitado y debe hacerse uso del modelo de contexto. La aplicaci´on resulta m´as compleja de desarrollar con el modelo tradicional. Se encontr´o que puede conservarse el modelo gr´afico, pero debe existir un modelo de contexto. Un patr´on de dise˜ no resume la propuesta de forma que sea de r´apida comprensi´on y reutilizaci´on.

CONTENIDO

´ 1. INTRODUCCION

10

1.1. Realidad Aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.2. Experiencias preliminares de desarrollo en Realidad Aumentada . . . . . .

12

1.3. Computaci´on Ubicua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

1.4. Aplicaciones Dependientes del Contexto . . . . . . . . . . . . . . . . . . .

17

1.5. Definici´on del problema y objetivos . . . . . . . . . . . . . . . . . . . . . .

18

1.6. Trabajo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2. MODELOS DE DATOS

20

2.1. Definici´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2. Evoluci´on de los modelos de datos . . . . . . . . . . . . . . . . . . . . . . .

22

3. APLICACIONES DEPENDIENTES DEL CONTEXO

23

3.1. El contexto en las aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2. Caracter´ısticas de la informaci´on del contexto . . . . . . . . . . . . . . . .

24

3.3. Representaci´on del contexto . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4. REALIDAD AUMENTADA

26

4.1. Aspectos b´asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.1.1. Visualizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.1.2. Registro de objetos virtuales . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.1.3. Interacci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

CONTENIDO

4.2. Sistemas actuales de Realidad Aumentada . . . . . . . . . . . . . . . . . .

30

4.3. Fallas de los Sistemas Actuales . . . . . . . . . . . . . . . . . . . . . . . .

30

4.4. Exigencias del nuevo modelo de datos . . . . . . . . . . . . . . . . . . . . .

32

5. MODELO DE CONTEXTO PARA REALIDAD AUMENTADA

33

5.1. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.2. Definici´on del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.2.1. Componentes del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.3. Definici´on formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.3.1. Definici´on del esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3.2. Definici´on de las instancias . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.3.3. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

´ 6. IMPLEMENTACION

43

6.1. Representaci´on del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

6.2. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

6.2.1. Visores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2.2. Localizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2.3. Separaci´on Modelo-Vista . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

´ 7. EVALUACION

54

7.1. Comparaci´on con el modelo tradicional . . . . . . . . . . . . . . . . . . . .

54

7.2. Experimento de dise˜ no . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

7.3. Ventajas de codificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

7.4. Satisfacci´on de los requerimientos . . . . . . . . . . . . . . . . . . . . . . .

59

IX

CONTENIDO

˜ 8. APORTE DE DISENO

62

9. CONCLUSIONES

65

9.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

BIBLIOGRAF´IA

68

X

1.

´ INTRODUCCION

La l´ınea entre el mundo real y el mundo virtual es cada vez m´as delgada. La informaci´on de los sistemas digitales se filtra cada vez m´as en las actividades diarias de las personas. La Realidad Aumentada (RA) se encuentra en la l´ınea entre el mundo real y la informaci´on del mundo digital. La RA toma el papel de una interfaz de usuario al poder presentar informaci´on digital en el mundo por medio de dispositivos de representaci´on especiales. Un sistema de software de Realidad Aumentada se separa de los sistemas tradicionales pues interact´ uan en gran medida con el usuario y su entorno. Desarrollar sistemas de RA representa retos en cuanto a m´etodos de procesamiento y representaci´on de informaci´on. Lograr la combinaci´on real-virtual es de por s´ı compleja y no consiste simplemente en sobreponer geom´etricamente un mundo sobre el otro. El salto de la informaci´on digital al mundo requiere de metodolog´ıas apropiadas para hacer que los sistemas conciban lo que est´a sucediendo en el ambiente y puedan reaccionar ante los eventos que all´ı ocurren. Los m´etodos de abstracci´on son de vital importancia. Los modelos de datos son claves en tiempo de desarrollo y ejecuci´on. Las aplicaciones de Realidad Aumentada actuales se ven limitadas en el conocimiento que tienen del mundo. La dependencia en m´etodos tradicionales de desarrollo de sistemas de gr´aficos tridimensionales y de Realidad Virtual han restringido su acceso a la riqueza de informaci´on del usuario y el entorno. Los modelos de datos heredados de tales aplicaciones fueron efectivos dentro de su alcance, pero son limitados para los requerimientos de la RA. La necesidad de evoluci´on en los modelos de memoria para sistemas que interactuaban m´as cercanamente al usuario se reconoci´o desde trabajos tempranos en computaci´on (Licklider, 1968). Se ha dado por hecho que las aplicaciones que dependen en gran medida de la informaci´on del mundo real requieren de nuevos metodolog´ıas de dise˜ no (Norman, 1998; Banavar et al., 2000; Henricksen et al., 2001; Satyanarayanan, 2001). En espec´ıfico, este trabajo considerar´a el modelo de datos para sistemas RA. Un modelo de datos para sistemas de computo se describe como un formalismo matem´atico que consta de una notaci´on para describir la representaci´on los datos en un sistema de software y de un conjunto de operaciones v´alidas que se pueden usar para

1.1 Realidad Aumentada

manipularlos (Graham, 1991). En una definici´on m´as pr´actica, un modelo de datos es la abstracci´on usada para describir un problema en un sistema de software (Aho y Ullman, 1995). Una aplicaci´on de RA requiere de un modelos de datos apropiado para manejar la informaci´on del mundo real que sea flexible, extensible y con la capacidad para representar informaci´on del mundo real y virtual. Modelos m´as apropiados impactar´an positivamente el tiempo de desarrollo y har´an de los sistemas de RA m´as efectivos, prestando un mayor beneficio al usuario. Otra ´area de investigaci´on, aparte de la RA ha reconocido la existencia del problema de la representaci´on del mundo. La Computaci´on Ubicua (Weiser, 1995) y las Aplicaciones Dependientes del Contexto (Schilit et al., 1994), estudian los sistemas de software que act´ uan de acuerdo a la informaci´on que tienen del lugar donde se ejecutan, tambi´en llamado contexto. Investigaci´on en esta ´area ha permitido establecer las caracter´ısticas principales del contexto y ha prove´ıdo soluciones cercanas, m´as no completas, de representaci´on del mundo. Este trabajo busca proponer un modelo de contexto propio para aplicaciones de Realidad Aumentada. Se describir´an a continuaci´on los sistemas de RA y se presentar´an los antecedentes que ratifican la necesidad de b´ usqueda de nuevos modelos.

1.1.

Realidad Aumentada

Se habla de Realidad Aumentada cuando se presenta informaci´on virtual en el mundo real (Azuma et al., 2001). En la RA por ejemplo, puede observarse un objeto tridimensional generado por computador flotando en el aire frente a nuestros ojos. Con el uso de tecnolog´ıas realidad aumentada, la informaci´on digital puede ser presentada en el mundo real directamente al usuario, sin requerir su atenci´on expl´ıcita en la pantalla de un dispositivo. Por sus caracter´ısticas, la Realidad Aumentada siempre se ha considerado como una extensi´on de los sistemas de Realidad Virtual (Azuma, 1995). El concepto de RA es definir´a con m´as detalle en la secci´on 4. Puede considerarse por el momento a la realidad aumentada como algo similar a la tecnolog´ıa hologr´afica, donde objetos virtuales flotan ubicados en lugres del mundo.

11

1.2 Experiencias preliminares de desarrollo en Realidad Aumentada

1.2.

Experiencias preliminares de desarrollo en Realidad Aumentada

El desarrollo de dos sistemas de RA permiti´o conocer exigencias comunes y encontrar carencias de los m´etodos de desarrollo actuales. Una aplicaci´on de realidad aumentada en general busca resolver el problema de combinar el mundo real con el virtual. Se concluy´o que los sistemas de RA requieren m´etodos de desarrollo especiales, incluyendo t´ecnicas avanzadas de programaci´on orientada a objetos, sistemas distribuidos e interfaces gr´aficas. En especial, la representaci´on del mundo y la forma de combinar los elementos del mundo real y virtual son de especial atenci´on. Durante la construcci´on de ARMotodo1 (ARM) se experiment´o con sistemas de que combinaban realidad aumentada y realidad virtual. ARM es un juego de bloques de construcci´on que permite que dos usuarios ubicados, uno en un ambiente virtual y otro en el real, puedan fabricar conjuntamente una figura tridimensional compuesta de bloques. La figura 1.1 ilustra una sesi´on de colaboraci´on en ARM. Los bloques de ´ ARM son completamente virtuales. Estos pueden ser manipulados por el usuario en el mundo real por medio de un dispositivo de rastreo que funciona a manera de un rat´on de computadora tridimensional. El usuario en el mundo virtual (para este caso un computador de escritorio), tiene una visi´on simulada del mundo real y manipula los bloques con el rat´on. La principal observaci´on durante el desarrollo de este sistema fue la necesidad de contar con un modelo de datos unificado. Los elementos principales, es decir los bloques, son representaciones visibles de entidades virtuales con caracter´ısticas, principalmente de forma y ubicaci´on en el espacio. De alguna forma deb´ıan representarse esos objetos, como elementos dentro de la aplicaci´on. Se seleccion´o para el sistema un modelo de datos basado en una matriz tridimensional donde cada bloque era representado por una estructura de datos que pod´ıa ocupar una de las posiciones en la matriz. Este modelo de datos era simple y expresaba y representaba bien la situaci´on que venia desarroll´andose de elaboraci´on de figuras a partir de cubos. Adicionalmente, este modelo permit´ıa implementar f´acilmente detecci´on de colisiones y simular el efecto de la fuerza 1

El sistema colaborativo ARMotodo se construy´o en 2002 y se encuentra disponible ante petici´on.

12

1.2 Experiencias preliminares de desarrollo en Realidad Aumentada

Figura 1.1: Sesi´on colaborativa en ARMatodo. de gravedad. Una vez definido, se requer´ıa que tal modelo pudiera ser compartido por m´ ultiples instancias de la aplicaci´on. El estado del modelo deb´ıa ser actualizado en tiempo real a manera de los sistemas de realidad virtual distribuida (Singhal y Zyda, 1999). Una vez compartido, el modelo era modificado por m´ ultiples dispositivos de entrada y a su vez pod´ıa ser representado por diferentes dispositivos de salida (una ventana de escritorio y un casco de Realidad Virtual). En la versi´on final de ARM se logr´o una sincronizaci´on real-virtual adecuada, en tiempo real y distribuci´on que facilitaba la interacci´on de los usuarios. La arquitectura del sistema construido se muestra en la figura 1.2. Considerar este primer dise˜ no es de gran importancia. Se trat´o de un dise˜ no simple basado en una estructura de datos est´atica y de m´ınima escalabilidad. Un t´ıpico modelo que seria propio de una aplicaci´on de escritorio. El sistema de colaboraci´on a distancia Parallel Worlds fue el segundo paso en la evoluci´on de un sistemas de colaboraci´on a distancia entre usuarios de realidad virtual y aumentada (Ganapathy et al., 2003). El Parallel Worlds Framework (PWF) integraba un sistema de colaboraci´on distribuida, uno de realidad virtual y uno de realidad aumentada (Figura 1.3). PWF agregaba varios niveles de complejidad al sistema de colaboraci´on a distancia original. PWF deb´ıa soportar m´ ultiples usuarios en el mundo real y virtual. Otro tipo de usuario, un agente inteligente, hacia parte de la colabora-

13

1.2 Experiencias preliminares de desarrollo en Realidad Aumentada

Figura 1.2: Artquitectura de sistema de ARM.

Figura 1.3: Sesi´onn colaborativa en Parallel Worlds.

14

1.2 Experiencias preliminares de desarrollo en Realidad Aumentada

Figura 1.4: Arquitectura de sistema de PWF. ci´on. La interacci´on era m´as compleja, pues tanto objetos virtuales como reales deb´ıan ser manipulados por el usuario. Otras formas de comunicaci´on con el sistema, como reconocimiento de voz deb´ıan incluirse. El sistema final era formado por un conjunto de sub-aplicaciones con tareas espec´ıficas de presentaci´on en realidad virtual o presentaci´on en realidad aumentada (V´ease figura 1.4). En PWF las sub-aplicaciones necesitaban conocer hasta cierto punto el estado general de la situaci´on del mundo real-virtual. En espec´ıfico se requer´ıa conocimiento de: Objetos virtuales y reales Usuarios Dispositivos Relaciones entre los anteriores La soluci´on propuesta para incluir la informaci´on de objetos virtuales y reales, usuarios, dispositivos y relaciones entre estos fue el Scene Graph (SG), pues el sistema distribuido estaba basado en el middleware de DISCIPLE (Marsic, 1999) cuyo un modelo de datos es un Scene Graph replicado.

15

1.3 Computaci´ on Ubicua

Figura 1.5: Evoluci´on del Modelo. Debido a esto se busc´o una forma de organizar jer´arquicamente los elementos, pero se presentaron limitaciones. El modelo jer´arquico no permit´ıa expresar las relaciones distintas a espaciales. La jerarqu´ıa dise˜ nada era adem´as compleja y no representaban bien la situaci´on del entorno que se pretend´ıa expresar. Aparte de esto el SG tuvo que extenderse para agregar atributos adicionales a los elementos y debieron adicionarse representaciones virtuales de los objetos reales para poder manejarlos. En la implementaci´on final la informaci´on de la situaci´on qued´o dispersa en el sistema y se vio la necesidad de agregar un protocolo adicional de paso de mensajes para mantener el estado. La experiencia adquirida en el desarrollo de ARM y PWF llev´o a una de las preguntas que este trabajo trata de responder. Deb´ıa existir un modelo m´as adecuado para representar la situaci´on del mundo. Lo que sucedi´o puede expresarse en el esquema de la figura 1.5. Se encontr´o que problemas similares se hab´ıan encontrado en otra ´area de investigaci´on: la de la Computaci´on Ubicua y las Aplicaciones Dependientes del Contexto.

1.3.

Computaci´ on Ubicua

En 1991 Mark Weiser, de Xerox PARC, describi´o su visi´on del computador del siglo 21. En The Computer for the 21st Century Weiser discuti´o que las tecnolog´ıas m´as profundas son aquellas que tienden a desaparecer (Weiser, 1995). El ejemplo de Weiser permite entender mejor esta idea. La escritura fue la primera tecnolog´ıa de la informaci´on. En

16

1.4 Aplicaciones Dependientes del Contexto

alg´ un momento del tiempo, la escritura permiti´o la captura en una forma simb´olica del leguaje y permiti´o que este fuera almacenado a largo plazo. En la actualidad, la escritura, como tecnolog´ıa, es ubicua2 , es accesible en cualquier lugar y situaci´on. La escritura puede encontrarse en libros, signos en la calle o en la ropa. El uso de esta tecnolog´ıa no requiere de esfuerzo ni excesiva atenci´on, la podemos usar sin inconvenientes casi en cualquier lugar. Las tecnolog´ıas de informaci´on basadas en sistemas se asemejan a la escritura. En un principio los computadores se encontraban estacionados en lugares espec´ıficos y eran empleados para tareas limitadas en muy pocos campos del conocimiento. Sin embargo ahora, las tecnolog´ıas de c´omputo se hacen ubicas en la medida que cada vez se encuentran en m´as lugares y hacen cada vez m´as parte de nuestra vida cotidiana. A´ un se requiere desarrollo para que estas tecnolog´ıas sean del todo parte del ambiente. Es en parte de un problema de interfaz gr´afica y una necesidad de que el potencial de la computaci´on se “impregne” en el mundo y pase desapercibida. Los dispositivos port´atiles no dejan de ser una caja que aunque tuviera acceso a toda la informaci´on del mundo, aun requerir´ıa de toda nuestra atenci´on y de que la estemos observando continuamente. El estado ideal seria tal, que la computaci´on mejore al mundo real transparentemente. Se introdujo el termino “Virtualidad incorporada”3 , que consiste en tomar la computaci´on fuera del hardware. La virtualidad de los datos del computador y el procesamiento en el mundo f´ısico.

1.4.

Aplicaciones Dependientes del Contexto

Una aplicaci´on que permita tal escenario puede clasificarse como dependiente del contexto. Una aplicaci´on dependiente del contexto es aquella que provee informaci´on o toma acciones de acuerdo al contexto en que se encuentra el usuario (Brown et al., 1997). El contexto se define como cualquier informaci´on que pueda ser usada para caracterizar la situaci´on de una entidad (Dey y Abowd, 2000). Una aplicaci´on de RA se podr´ıa clasificar como una aplicaci´on dependiente del contexto. La RA requiere de 2 3

Que se encuentra al mismo tiempo en todas partes. En ingl´es “Embodied Virtuality”. 17

1.5 Definici´ on del problema y objetivos

gran cantidad de informaci´on sobre la situaci´on del mundo real en que se halla el usuario. Este trabajo considera la realidad aumentada como una interfaz de usuario en la computaci´on ubicua.4

1.5.

Definici´ on del problema y objetivos

Las aplicaciones de Realidad Aumentada requieren de un modelo de datos diferente al modelo de datos de las aplicaciones tradicionales de graficas tridimensionales y de Realidad Virtual. Durante este trabajo se justificar´a que existe tal necesidad y se presentar´a un modelo que satisface un conjunto de requerimientos establecidos de acuerdo a un an´alisis del modelo actual. Para cumplir con este objetivo, este trabajo pretende cumplir con los siguientes objetivos espec´ıficos: Presentar un marco de referencia en modelos de datos, Computaci´on Dependiente del Contexto y Realidad Aumentada. Presentar las deficiencias de las arquitecturas tradicionales. Determinar una lista de requerimientos del modelo buscado. Mostrar un caso de aplicaci´on que refleje los requerimientos. Describir el modelo de contexto. Implementar y describir el sistema propuesto bas´andose en el modelo. Evaluar el modelo en base a un experimento de dise˜ no, antecedentes e implementaci´on del caso de aplicaci´on. Definir un patr´on de dise˜ no que resuma la propuesta del modelo para su uso en sistemas de Realidad Aumentada. 4

Se puede ver la RA como una de las m´ ultiples formas de interacci´on con sistemas ubicuos. Hasta el momento no se ha encontrado referencia que considere la RA como interfaz de usuario de la computaci´ on ubicua. 18

1.6 Trabajo relacionado

Obtener conclusiones y proponer trabajo futuro.

1.6.

Trabajo relacionado

Este trabajo de fundamenta en la visi´on de la Computaci´on Ubicua y las Aplicaciones dependientes del Contexto de Weiser (1995) y Schilit et al. (1994); la definici´on de contexto de Dey y Abowd (2000); la descripci´on de modelos de datos y sistemas de computo de Aho y Ullman (1995); la definici´on de Realidad Aumentada de Azuma (1995); el estudio de arquitecturas de RA de Br¨ ugge et al. (2002); se toman los principios del modelo de contexto de Henricksen et al. (2002) y la formalizaci´on de Gyssens et al. (1994). Las estructuras y modelos de datos no han sido de especial preocupaci´on para el ´area de Realidad Aumentada. Se presta m´as atenci´on a m´etodos de ubicaci´on (Azuma, 1995; Kato y Billinghurst, 1999; Azuma et al., 2001) y arquitectura general del sistema (Schmalstieg et al., 2002; Reicher et al., 2003; Reitmayr, 2004). El uso el Scene Graph como modelo de datos central es generalizado, pues siempre se ha partido de que la realidad aumentada es una extensi´on de la Realidad Virtual (Azuma, 1995; Br¨ ugge et al., 2002). Estudios arquitect´onicos en general han reconocido la necesidad de mantener la informaci´on el contexto (Br¨ ugge et al., 2002), pero no se han buscado modelos para representarlo. Newman et al. (2004) considera el uso de un modelo de datos basado en grafos para el sistema de ubicaci´on, sin embargo se usa exclusivamente para coordinar los sensores del sistema. Se han presentado modelos de represtaci´on de contexto en Kindberg et al. (2000); Harter et al. (1999); Schmidt et al. (1999); Gray y Salber (2001) y Dey et al. (1999). Tales modelos son limitados a aplicaciones espec´ıficas, en especial de computaci´on m´ovil y a tipos de contexto restringidos, ninguno de RA. En Henricksen et al. (2001) se presenta un modelo general para aplicaciones dependientes de contexto, sin embargo tal modelo maneja un conjunto limitado de relaciones entre los elementos del contexto. Este trabajo presenta un modelo de contexto con un enfoque en sistemas RA.

19

2.

MODELOS DE DATOS

En el ´area de la ciencia y la tecnolog´ıa, un modelo es una representaci´on abstracta o te´orica de un fen´omeno. Un modelo es fundamental para la construcci´on de cualquier sistema (Gigch, 1991). La creaci´on de sistemas de software se basa fundamentalmente en la abstracci´on: crear un modelo para pensar acerca de un problema y encontrar m´etodos apropiados para resolverlo. En la computaci´on, se debe crear una abstracci´on de los problemas del mundo real para que el problema pueda ser entendido por los desarrolladores y a su vez ser representado y manipulado por el computador (Aho y Ullman, 1995). Por ejemplo, para modelar el comportamiento de un circuito electr´onico se hace uso de lo l´ogica preposicional como forma de abstracci´on. El modelo de un circuito basado en l´ogica no es exacto, pues no representa el fen´omeno f´ısico-el´ectrico en su totalidad, sin embargo es suficiente para dise˜ nar y simular el comportamiento del circuito. Otro ejemplo claro de uso de modelos es el problema de determinar la conectividad de equipos de c´omputo. Un modelo de la situaci´on seria asignar, en un grafo, un nodo a cada equipo y trazar un arco entre los equipos interconectados para indicar una conexi´on directa. Obtendr´ıamos entonces un grafo que modela un problema o situaci´on del mundo real. Tal abstracci´on del problema es comprensible tanto por los sistemas de c´omputo como por los dise˜ nadores. Se definir´a modelo de datos y se aclarar´a la diferencia existente entre un modelo de datos y una estructura de datos. Se introducir´a a la especificaci´on de modelos de datos y los modelos de datos orientados a objetos.

2.1.

Definici´ on

Un modelo de datos se describe como un formalismo matem´atico que consta de una notaci´on para describir los datos y estructuras de datos, y de un conjunto de operaciones v´alidas que se pueden usar para manipularlos (Graham, 1991). Una especificaci´on de un modelo de datos no contiene ning´ un tipo de implementaci´on, esto requerir´ıa de una traducci´on a una sintaxis de un lenguaje, describiendo datos y funciones (Heileman, 1996). Las estructuras de datos (ED) son la implementaci´on de los datos del modelo en

2.1 Definici´ on

un lenguaje de programaci´on. Los datos de las ED son conformados por tipos b´asicos del lenguaje y otras estructuras de datos. La especificaci´on de un modelo se hace matem´aticamente como una colecci´on de objetos y el conjunto de operaciones definidas en los elementos de esta colecci´on. La colecci´on de objetos usualmente se representa gr´aficamente. Una matriz es un ejemplo de un modelo de datos. El modelo de datos matriz se define como una disposici´on rectangular de elementos en filas y columnas, donde n es el n´ umero de filas y m el n´ umero de columnas. La dimensi´on de la matriz se define como n × m y puede ser representada como se ve a continuaci´on:    M =  

a11 a12 . . . a1m a21 a22 . . . a2m .. .. .. . . . an1 an2 . . . ann

     

aqui aij representa al elemento de la fila i y la columna j. Las operaciones definidas sobre una matriz son entre otras: Obtener elemento Asignar elemento Sumar dos matrices Producto de dos matrices La implementaci´on de este modelo debe representar de alguna forma el elemento matriz y establecer las funciones. La implementaci´on de la matriz no necesariamente implica que deban usarse arreglos de datos del lenguaje. Cada implementaci´on puede determinar los tipos y estructuras requeridas.

21

2.2 Evoluci´ on de los modelos de datos

2.2.

Evoluci´ on de los modelos de datos

El desarrollo de los modelos de datos para representar informaci´on compleja, tal como el mundo real, est´a fuertemente ligado con la evoluci´on de las bases de datos. Gracias a las bases datos se establecieron modelos formales para sistemas que requer´ıan acceso a fuentes ricas en informaci´on de una manera eficiente y comprensible para el dise˜ nador. La historia de los modelos de datos para bases de datos se divide en tres generaciones. La primera generaci´on fue formada por los llamados modelos de datos en red y modelos jer´arquicos, tales modelos carec´ıan de una definici´on formal. Por algunas limitaciones, estos modelos fueron sobrepasados por el Modelo Relacional, que representa la segunda generaci´on. El Modelo Relacional fue el primer modelo formal de datos y es el fundamento de la mayor´ıa de los sistemas de bases de datos comerciales en la actualidad. No obstante el Modelo Relacional est´a orientado a bases de datos empresariales y se concluy´o que era limitado para nuevos tipos de aplicaciones que, de igual forma, manejaba informaci´on compleja. Ejemplo de ´estos son los sistemas de dise˜ no asistido por computador (CAD) y de ingenier´ıa de software asistida por computador (CASE) (The Committee for Advanced DBMS Function, 1990). Tal necesidad dio origen a los sistemas de tercera generaci´on. Los modelos de tercera generaci´on, dentro de los que se encuentran modelos sem´anticos como el Modelo Entidad-Relaci´on y los modelos de datos orientados a objetos, son m´as apropiados para representar informaci´on m´as din´amica y compleja. El modelo de datos Orientado a Objetos es particularmente adecuado pues encaja perfectamente con sistemas orientados a objetos (Graham, 1991). Los modelos de datos orientados a objetos son representados en forma de grafos (Andries, 1996). Los modelos de datos orientados a objetos representan la u ´ltima generaci´on en la evoluci´on de los modelos de datos. Un caso particular es de especial atenci´on. El modelo de datos central de los sistemas operativos actuales (el sistema de archivos) es una estructura jer´arquica. Este modelo se introdujo desde sistemas operativos como UNIX. Sin embargo el modelo jer´arquico de archivos es limitado y puede ser complicado de manejar por los usuarios si la jerarqu´ıa es compleja. Existe una alternativa con los sistemas de archivos orientados a objetos. Los sistemas de archivos orientados a objetos facilitan el manejo de archivos al usuario (Kim y Popek, 1997). Muchos sistemas operativos actuales buscan cambiar su modelo de archivos a uno orientado a objetos (Ricciuti, 2002). 22

3.

APLICACIONES DEPENDIENTES DEL CONTEXO

Una aplicaci´on es una herramienta computacional que permite a un usuario realizar una tarea. Al proveer acceso al contexto1 a las aplicaciones, se incrementa la riqueza de la comunicaci´on hombre-m´aquina y la efectividad de la elaboraci´on de la tarea. Es similar a lo que sucede en una conversaci´on entre dos personas, ´esta se enriquece gracias a la informaci´on impl´ıcita de la situaci´on. Durante este trabajo se hablar´a del contexto o situaci´on de una manera intercambiable. Hasta ahora las maquinas en gran medida son un ambiente virtual tal como lo explica Saha y Mukherjee (2003). Un ambiente virtual es cerrado y obtiene informaci´on exclusivamente del sistema y del usuario. Para enriquecer la relaci´on usuario-aplicaci´on, deber´ıa proveerse acceso al contexto. As´ı, m´ ultiples sistemas podr´ıan trabajar en conjunto sobre un modelo de contexto en beneficio de las personas que las usan. Tal salto plantea indudables retos y exige de cambios en los m´etodos de desarrollo actuales (Satyanarayanan, 2001). A continuaci´on se definir´an las aplicaciones dependientes del contexto y sus caracter´ısticas b´asicas.

3.1.

El contexto en las aplicaciones

Se han dado m´ ultiples definiciones de contexto para aplicaciones. Inicialmente Schilit y Theimer (1994) defini´o el contexto como la ubicaci´on, objetos y personas alrededor y los cambios de estos objetos. Brown et al. (1997) y Ryan et al. (1997) lo definen como ubicaci´on, identidades de los usuarios, tiempo, temperatura, etc. Hull et al. (1997) define contexto como aspectos de la situaci´on actual. La definici´on de Dey y Abowd (2000) ha tenido amplia aceptaci´on: se define contexto como cualquier informaci´on que pueda ser usada para caracterizar la situaci´on de una entidad. Las entidades en el contexto son cualquier persona, lugar, objeto, actividad, etc. que sea relevante para el sistema. Una aplicaci´on dependiente del contexto se defini´o inicialmente como un sistema que 1

La palabra contexto se define como la informaci´on impl´ıcita en una situaci´on cualquiera.

3.2 Caracter´ısticas de la informaci´ on del contexto

examina y reacciona al contexto en que se encuentra el usuario (Schilit et al., 1994). Hull et al. (1997) las define como los sistemas de c´omputo capaces de sensar, interpretar y responder de acuerdo al entorno en que se encuentra el usuario. Para Dey y Abowd (2000) un sistema es dependiente del contexto si hace uso del contexto para proveer informaci´on o servicios relevantes al usuario, de acuerdo a la tarea que este se encuentre desarrollando. Brown et al. (1997) define una aplicaci´on dependiente del contexto como aquella que provee informaci´on o toma decisiones de acuerdo al contexto en que se encuentra el usuario.

3.2.

Caracter´ısticas de la informaci´ on del contexto

De acuerdo a Henricksen et al. (2001) existen cuatro caracter´ısticas b´asicas de la informaci´on del contexto a tener e cuenta. La informaci´on de contexto exhibe distintas caracter´ısticas temporales, es imperfecta, tiene diferentes representaciones y est´a altamente relacionada.

Caracter´ısticas temporales La informaci´on del contexto puede ser est´atica o din´amica. Un sistema dependiente del contexto se caracteriza por cambios frecuentes en los datos. La mayor parte de la informaci´on es din´amica. Esta caracter´ıstica determina los medios en que la informaci´on debe ser obtenida. Informaci´on est´atica puede ser obtenida, por ejemplo, de los usuarios. La informaci´on din´amica requiere de otras fuentes, tales como sensores. Esto implica adem´as que se requieren m´etodos para predecir informaci´on ante fallos o retrasos.

Imperfecci´ on La informaci´on del contexto puede determinarse como incorrecta cuando falla en reflejar el verdadero estado de la situaci´on que modela. Puede ser inconsistente si contiene contradicciones o incompleta si se desconoce parte de ´esta. Combinado esta caracter´ıstica con el dinamismo, se nota que la informaci´on puede llegar a degradarse. La informaci´on proveniente del entorno cuenta con retrasos causados por lo medios de comunicaci´on y capacidad de procesamiento. Adicionalmente, sensores, algoritmos y usuarios pueden proveer informaci´on corrupta o alterada por ruido. En 24

3.3 Representaci´ on del contexto

un momento de tiempo determinado la informaci´on con que se cuenta puede estar parcialmente equivocada.

Representaciones alternas La informaci´on proveniente de sensores y sistemas maneja diferentes formatos. Adem´as, cada aplicaci´on envuelta en una situaci´on de contexto cuenta con diferentes formas de procesar la informaci´on y actuar sobre ´esta. M´ ultiples abstracciones pueden usarse. El punto clave se encuentra en proveer un modelo de representaci´on que sea flexible y pueda ser interpretado por m´ ultiples aplicaciones con distintas tareas a la vez.

Alta interrelaci´ on Diferentes relaciones se presentan entre los elementos que interact´ uan en una situaci´on en que se encuentre el usuario. La informaci´on del contexto se interrelaciona de tal forma que las relaciones entre dos entidades las afecta entre s´ı. Las relaciones deben ser identificadas y mantenidas por el sistema.

3.3.

Representaci´ on del contexto

El contexto es una fuente rica en informaci´on que requiere modelos de representaci´on avanzados. El contexto puede llegar a tener m´ ultiples representaciones alternativas. El punto clave est´a en encontrar la representaci´on que sea m´as adecuada facilitando el desarrollo de la aplicaci´on. Variadas formas de representar o abstraer el contexto se han presentado. Dey et al. (1999) presenta a una arquitectura centrada en sensores que actualizan una lista de par´ametros del sistema asociados a una probabilidad. Schilit et al. (1993) hace uso de servidores de entorno que manejan la informaci´on del contexto y la distribuyen para los m´ ultiples sistemas cliente. La informaci´on el contexto es mantenida en un conjunto de variables de entorno. El modelo de contexto presentado por Harter et al. (1999) est´a basado en un modelo conceptual basado en el modelo Entidad-Relaci´on. El modelo es mantenido en una base de datos actualizable en tiempo de ejecuci´on. Henricksen et al. (2001) presenta un modelo de contexto orientado a objetos y basado en grafos que permite modelar el contexto como un conjunto de entidades y relaciones.

25

4.

REALIDAD AUMENTADA

La Realidad Aumentada (RA) es la mezcla de informaci´on computacional con el mundo real. En una definici´on cl´asica, la realidad aumentada es un tipo de ambiente virtual en el cual el usuario no se sumerge completamente en un mundo virtual sino en una mezcla de ´este con el mundo real de tal forma que, para el usuario, aparezcan los objetos virtuales y reales coexistiendo en el mismo espacio Azuma (1995). La figura 4.1 muestra un ejemplo de realidad aumentada donde cubos completamente virtuales pueden ser observados en la realidad por un usuario. El usuario debe hacer uso de un dispositivo especial como el de la figura 4.2. La Realidad Aumentada hace parte de la definici´on de Realidad Mixta. La Realidad Mixta se define como un continuo de posibles formas de un usuario percibe su entorno en el mundo real, virtual o en una mezcla real-virtual (Milgram et al., 1994). En el caso completamente virtual, el entorno est´a creado completamente por computador. En la realidad aumentada el entorno es mejorado por el computador.

Figura 4.1: Cubos virtuales aumentando la realidad Una aplicaci´on de realidad aumentada, a diferencia de las aplicaciones de escritorio, se lleva a cabo en la realidad. Una aplicaci´on de escritorio o aplicaci´on tradicional es en la que uno o varios usuarios hacen uso en un dispositivo tradicional, como un computador personal. El sistema de escritorio tradicional est´a formado por uno dispositivo de presentaci´on como una pantalla, un teclado y un instrumento de interacci´on como un

4.1 Aspectos b´ asicos

Figura 4.2: Ejemplo de dispositivo de visi´on de realidad aumentada. rat´on o un l´apiz ´optico.

4.1.

Aspectos b´ asicos

Para Azuma (1995) un sistema de realidad aumentada cuenta con las siguientes caracter´ısticas: 1. Combina lo real y lo virtual. La informaci´on digital es combinada con la realidad. 2. Funciona en tiempo real. La combinaci´on de lo real y lo virtual se hace en tiempo real. 3. Registra en tres dimensiones. En general la informaci´on aumentada se localiza o “registra” en el espacio. Para conservar ilusi´on de ubicaci´on real y virtual esta tiende a conservar su ubicaci´on o moverse respecto a un punto de referencia en el mundo real. La informaci´on de la que se habla aqu´ı puede referirse, a parte de informaci´on visual, a informaci´on auditiva, olfativa o t´actil. En cuanto al funcionamiento de las aplicaciones de RA, tres componentes fundamentales deben presentarse. Estos tres componentes son visualizaci´on (salida), ubicaci´on de objetos virtuales en el mundo real (registro) y m´etodos de interacci´on (entrada).

27

4.1 Aspectos b´ asicos

Figura 4.3: M´etodos. a) Combinaci´on de visi´on con objetos virtuales, b) M´etodo directo, c) M´etodo Indirecto.

4.1.1.

Visualizaci´ on Actualmente la Realidad Aumentada visual se logra con

el uso de dispositivos de visualizaci´on similares a los de Realidad Virtual. Algunos de estos dispositivos son los cascos y gafas, ´estos se componen por pantallas de cristal l´ıquido que se ubican al frente de los ojos para presentar con ellas las gr´aficas generadas por el computador. Estas pantallas deben funcionar como si fueran lentes trasparentes, para que pueda observarse el mundo real, y permitir adicionar los objetos virtuales (Figura 4.3, a)). Para lograr esto existen dos m´etodos visi´on directa e indirecta. En el m´etodo directo se utiliza un espejo semi-reflectante para ver el mundo real a trav´es de ´este y a la vez reflejar las im´agenes del computador (Figura 4.3, b)). En el m´etodo indirecto se cubre totalmente la visi´on de la persona y se remplaza por im´agenes obtenidas por una c´amara ubicada a la altura de los ojos (Figura 4.3, c)).

4.1.2.

Registro de objetos virtuales Por objeto virtual no referimos a

cualquier imagen generada por computador que se genere en el dispositivo de visualizaci´on y se presente como parte de la realidad aumentada, esto incluye texto, figuras, 28

4.1 Aspectos b´ asicos

Figura 4.4: Problema del registro. En a) Mezcla del mundo (libro) con una gr´afica de RA (cubo). En b) el observador se desplaza, sin registro (la grafica conserva su posici´on en pantalla). En c) desplazamiento con registro (gr´afica conserva su posici´on). im´agenes bidimensionales o modelos tridimensionales. Uno de los problemas de la RA es lograr que tales objetos puedan “registrarse” con el mundo real de tal forma que cuando el usuario se mueva los objetos parezcan conservar su posici´on al igual que los objetos reales se quedan en su lugar cuando el observador cambia de posici´on (Figura 4.4). Los dispositivos empleados para enfrentar este problema son: 1. Sensores: Se hace uso de dispositivos de hardware de corto alcance que permiten determinar una ubicaci´on en el espacio. Existen sensores ´opticos (infrarojos), magn´eticos y de movimiento. 2. Visi´on de m´aquina: Se hace uso de una combinaci´on de hardware y software para identificar objetos o patrones y calcular su distancia respecto al observador. Por ejemplo se puede usar una c´amara de video para identificar un libro real y dibujar sobre ´este un texto virtual. Un sistema de reconocimiento de patrones de alta difusi´on es ARToolkit (Kato y Billinghurst, 1999). 3. Sistemas a campo abierto: Para aplicaciones de realidad aumentada en campo abierto se ha usado el Sistema de Posicionamiento Global para determinar la posici´on del usuario (Feiner et al., 1997).

29

4.2 Sistemas actuales de Realidad Aumentada

4.1.3.

Interacci´ on Una vez que se logra presentar objetos y se pueden ubicar

en el mundo real, pueden requerirse m´etodos para manipular o modificar tales objetos. Muchos m´etodos de manipulaci´on actual en analog´ıa a los sistemas de escritorio utilizan apuntadores o cursores para representar la posici´on de la mano del usuario. Tambi´en se hace uso de objetos reales como una tabla o panel de interacci´on (Ej. el Personal Interaction Panel (Szalavari y Gervautz, 1997) o paletas con marcadores para rastreo visual (Kato y Billinghurst, 1999)).

4.2.

Sistemas actuales de Realidad Aumentada

Br¨ ugge et al. (2002) presenta un resumen de las arquitecturas de los mayores sistemas de software de realidad aumentada. El estudio incluy´o 18 arquitecturas de donde se extrajo una arquitectura de referencia que contiene los componentes comunes de tales sistemas. El diagrama de componentes y dependencias pueden observarse en la figura 4.5. La funci´on de cada componente se define a continuaci´on. Aplicaci´on: maneja la l´ogica y contenidos espec´ıficos del sistema Tracking: determina la posici´on de los usuarios y objetos Control: procesa las entradas para el usuario Presentaci´on: se encarga de la representaci´on gr´afica Contexto: recoge diferentes datos de contexto Modelo del Mundo, almacena informaci´on sobre los objetos virtuales y reales

4.3.

Fallas de los Sistemas Actuales

Estas arquitecturas no consideran la informaci´on del contexto y el modelo del mundo como un todo. No se habla de un modelo del contexto. El componente contexto solo se encarga de procesar la informaci´on del subsistema de Tracking y repartirla a otros 30

4.3 Fallas de los Sistemas Actuales

Figura 4.5: Arquitectura de referencia de Br¨ ugge et al. (2002). subsistemas. El modelo que se tiene del mundo s´olo incluye los objetos reales o con representaci´on gr´afica, algunos sistemas, s´olo incluyen los objetos virtuales. Seg´ un el estudio, el modelo de mundo es el Scene Graph, que es limitado a relaciones geom´etricas. El usuario como tal no se considera como elemento de ning´ un componente, a pesar de la importancia que este tiene en las aplicaciones dependientes del contexto (Schilit et al., 1994; Dey y Abowd, 2000; Henricksen et al., 2001). Agregando lo anterior a la experiencia adquirida en el desarrollo en realidad aumentada (V´ease la secci´on 1.2) permite concretar las consecuencias de estas fallas en las arquitecturas de realidad aumentada. Las fallas se reflejan en dos aspectos fundamentales: 1. Desconocimiento de la aplicaci´on de la situaci´on del mundo real. Los elementos adicionales del contexto no est´an en el modelo. Lo que se conoce del mundo (s´olo los objetos) describe u ´nicamente como relaciones espaciales geom´etricas. En la mayor´ıa de los casos ´estas no son suficientes. 2. Dificultad en la implementaci´on del sistema de RA. No tener acceso directo a la situaci´on del contexto hace complicada la implementaci´on de la l´ogica de la aplicaci´on. El acceso al contexto, como se da a cabo hora se hace mediante operaciones indirectas en distintos subsistemas. 31

4.4 Exigencias del nuevo modelo de datos

Una aplicaci´on de Realidad Aumentada puede clasificarse como una aplicaci´on dependiente del contexto. Los sistemas actuales no tienen la infraestructura necesaria para incluir la riqueza de la informaci´on del contexto. Las aplicaciones para el contexto requieren de un cambio radical sobre las arquitecturas actuales. Debe proveerse un modelo de contexto apto para la RA.

4.4.

Exigencias del nuevo modelo de datos

Para aplicaciones dependientes del contexto no se puede partir simplemente de extender los m´etodos de dise˜ no procedentes de las aplicaciones de escritorio (Norman, 1998; Banavar et al., 2000; Henricksen et al., 2001; Satyanarayanan, 2001). La Realidad Aumentada tom´o su modelo principal de la Realidad Virtual y esta a su vez de las aplicaciones gr´aficas. Se define una lista de requerimientos que debe satisfacer el nuevo modelo. Un modelo de contexto para realidad aumentada debe cumplir por lo menos con cinco requerimientos: 1. El modelo debe permitir contener informaci´on sobre todos los elementos del contexto (mundo real) y del sistema (mundo virtual) relevantes a la aplicaci´on. 2. El modelo debe ser unificado. La informaci´on no debe estar dispersa por el sistema. La forma de acceder a la informaci´on debe ser gen´erica. 3. El modelo debe ser escalable y extensible. Debe soportar m´ ultiples tipos de aplicaciones y situaciones de contexto. Por ejemplo, no debe permitir solamente manejar la informaci´on de un usuario, sino de un creciente n´ umero de estos. 4. El modelo debe abstraer la situaci´on de manera tal que sea comprensible por el dise˜ nador y el sistema. 5. El modelo debe poder expresarse formalmente y ser v´alido dentro de la teor´ıa de modelos de datos. Se presenta a continuaci´on un modelo de contexto que pretende satisfacer tales requerimientos.

32

5.

MODELO DE CONTEXTO PARA REALIDAD AUMENTADA

Para desarrollar el estudio del modelo de contexto propuesto se presentar´a un caso de sistema de Realidad Aumentada, que ser´a u ´til para ilustrar cada una de sus caracter´ısticas. Una vez presentado el caso, se definir´a el modelo y se ejemplificar´a describiendo la informaci´on de contexto requerida por tal aplicaci´on de RA. Para garantizar la generalidad del modelo de datos se definir´a formalmente.

5.1.

Caso de estudio

Poder manejar informaci´on digital con nuestras propias manos agilizar´ıa la manipulaci´on de datos y facilitar´ıa la compresi´on de la informaci´on (Ishii y Ullmer, 1997). La Realidad Aumentada permite que objetos virtuales se ubiquen en el espacio real. Una vez all´ı, objetos virtuales pueden ser manipulados a manera de un objeto f´ısico (Kato y Billinghurst, 1999). Una aplicaci´on en particular consistir´ıa en hacer que un objeto digital, tal como un archivo, representado por un icono, texto o una imagen, se pudiera “extraer” del computador. Una vez en nuestras manos, tendr´ıamos la oportunidad de mover el objeto a cualquier lugar f´ısico y observarlo en el espacio. Este tipo de interacci´on har´ıa m´as f´acil e intuitivo, por ejemplo el trasladar un archivo de una m´aquina a otra o compartir informaci´on m´as f´acilmente en un grupo de trabajo. Seria sencillamente entretenido poder poner sobre nuestro escritorio un objeto gr´afico tomado del computador. La figura 5.1 ilustra el caso propuesto. En a), un usuario tiene en su computador un grupo de archivos representados en este caso por objetos tridimensionales. En b), gracias al sistema de RA que est´a al tanto del contexto, el usuario toma el objeto de su computador. El objeto adquiere una representaci´on en el mundo real gracias a la RA. Tal objeto, puede ser conservado en la mano o computador m´ovil del usuario. En c), el usuario ense˜ na a sus compa˜ neros el objeto. En el caso de una gr´afica tridimensional, sus compa˜ neros podr´ıan hacer comentarios acerca del dise˜ no de ´esta. En caso de un archivo de sonido, otros usuarios podr´ıan escuchar el sonido a medida que se acercan

5.2 Definici´ on del modelo

Figura 5.1: Migracion de Objetos en RA. y talvez observar las gr´aficas que presenta el reproductor de audio. En d), el usuario decide retornar el objeto en una estaci´on de trabajo distinta. Un sistema de RA debe estar consciente de la situaci´on en que se desenvuelve el usuario. Este sistema debe conocer, por lo menos, la ubicaci´on del usuario, dispositivos a los cuales tiene acceso y ubicaci´on de los objetos virtuales.

5.2.

Definici´ on del modelo

Se requiere un modelo de datos para expresar la situaci´on en la que la aplicaci´on de realidad aumentada toma lugar. Tal modelo debe incluir los elementos virtuales, del contexto y las relaciones que existen entre ´estos. La Realidad Aumentada se caracteriza por presentar elementos virtuales y relacionarlos con elementos f´ısicos. Existen relaciones entre los elementos tales como posesi´on, uso o conocimiento. Se presenta un modelo de datos orientado a objetos, en el cual, la informaci´on del contexto requerida por la aplicaci´on es estructurada en un conjunto de objetos organizados en forma de grafo, describiendo entidades reales o virtuales. Los objetos f´ısicos pueden representar objetos o situaciones del contexto. Un objeto f´ısico podr´ıa ser por ejemplo un lugar o una ac34

5.2 Definici´ on del modelo

tividad (Ej. Estudiar). Los objetos virtuales son elementos de informaci´on (procesos o datos). Las entidades se relacionan con otras entidades por medio de enlaces dirigidos. Las entidades y relaciones cuentan con atributos, estos especifican, por ejemplo nombre, caracter´ısticas o valores num´ericos. El modelo es simple y flexible. Esto permite su uso en m´ ultiples aplicaciones de RA. Este modelo no restringe los tipos de relaciones entre las entidades, de ´esta forma se garantiza la potencia de representaci´on y el soporte a distintos tipos de contexto. Como se definir´a en la siguiente secci´on cada aplicaci´on tiene la posibilidad de restringir los tipos de entidades y relaciones a un conjunto limitado por medio de esquemas. Este modelo cumple con la teor´ıa de modelo de datos orientado a objetos presentada por Atkinson et al. (1989). Como se explic´o en la secci´on 2.2, los modelos de datos orientados a objetos son ideales para situaciones con entidades y relaciones complejas tales como modelos sem´anticos y de IA (Graham, 1991).

5.2.1.

Componentes del modelo Para mostrar los componentes del mo-

delo se modelar´a la situaci´on del caso de estudio. La figura 5.2 presenta un primer acercamiento al modelo del sistema, ´esta se refinar´a cuando se presente la definici´on formal. Las entidades participantes son el usuario, los dispositivos (tanto computadores de escritorio como el computador m´ovil del usuario) y los objetos virtuales. Existen relaciones establecidas que no var´ıan en el tiempo, por ejemplo la relaci´on del usuario con su equipo port´atil permanecer´a durante la ejecuci´on de la aplicaci´on. Existen relaciones que cambian durante la ejecuci´on, tal como la relaci´on usuario-m´aquina. En el gr´afico se presentan relaciones en potencia como las relaciones que podr´ıan establecerse durante la ejecuci´on. Los objetos, cuando se trasladan de m´aquina, adquieren una relaci´on con la m´aquina en la que se encuentran y abandonan la relaci´on anterior. N´otese que el modelo para el caso es una jerarqu´ıa en la que el usuario es la ra´ız. En general se permite cualquier tipo de relaci´on, forma del grafo y enlaces entre elementos. El modelo se especific´o de esta forma por simplicidad del ejemplo. Este primer acercamiento demuestra la claridad del modelo. A su vez, esta claridad permite flexibilidad y potencial del modelo para representaciones m´as complejas. Como se ver´a en la siguiente secci´on tal construcci´on est´a bien fundamentada dentro de los mo35

5.2 Definici´ on del modelo

Figura 5.2: Primer acercamiento al modelo. delos de datos orientados a objetos y tiene una representaci´on formal. Se especificar´an los componentes del modelo.

Entidades Una entidad es cualquier objeto f´ısico o virtual. La definici´on de objeto representa aqu´ı el mismo concepto de objeto de la programaci´on Orientada a Objetos. Una entidad podr´ıa ser por ejemplo, una persona, lugar, una actividad o un sistema. De igual forma que un objeto, toda entidad pertenece a una clase de entidades. Para un usuario, la clase de su entidad es Persona. Toda entidad puede o no relacionarse con otras entidades por medio de relaciones. Adem´as, toda entidad puede caracterizarse por atributos que son a su vez propios de cada entidad y u ´nicos. Un atributo ser´ıa, para un dispositivo, por ejemplo, su tipo o especificaciones. Otros atributos podr´ıan tomar distintos valores y tipos de datos b´asicos. En el ejemplo m´aquina A, m´aquina B y port´ atil son entidades de la clase de objetos Dispositivo. Los objetos a y b pertenecen a la clase Objeto 1 . Por medio de atributos se le dar´an caracter´ısticas a los objetos a y b. En este caso a y b tendr´ıan un atributo 1

Objeto toma aqu´ı la connotaci´ on de objeto tangible u objeto 3D.

36

5.3 Definici´ on formal

llamado tipo que tomar´ıa el valor de virtual.

Relaciones Una relaci´on es un enlace unidireccional entre entidades. Una relaci´on es una afirmaci´on acerca de la entidad en la que se origina, por ejemplo la relaci´on entre usuario y m´aquina A, puede tomarse como la afirmaci´on “usuario hace uso de m´aquina A”. Los enlaces son dirigidos para dar significado a tales relaciones. Las relaciones son el elemento fundamental del modelo pues en s´ı describen el contexto. Debe insistirse en que las relaciones no son u ´nicamente espaciales. Pueden presentarse por ejemplo una relaci´on trabaja con entre dos usuarios. El valor sem´antico de estas relaciones es dado por el dise˜ nador y la aplicaci´on. Por tanto existen m´ ultiples tipos de relaciones, cada una u ´til de acuerdo a la aplicaci´on. En general, las relaciones pueden ser est´aticas o din´amicas durante el tiempo de ejecuci´on. Las relaciones est´aticas permanecen invariables. Las relaciones din´amicas por su parte cambian a medida que se desarrolla la situaci´on. Las relaciones tambi´en cuentan con atributos que describen caracter´ısticas sobre estas. Estos atributos pueden usarse para contener las caracter´ısticas temporales y de imperfecci´on del contexto, como se explic´o en la secci´on 3.2. Una relaci´on din´amica puede cambiar tanto en la entidad a la que apunta como en los valores de sus atributos. Las relaciones din´amicas son alteradas por decisi´on de la aplicaci´on, valores derivados de un sensor o tiempo. En el modelo, la relaci´on usuario port´atil es una relaci´on est´atica. La relaci´on usuario m´aquina, es una relaci´on din´amica determinada por un sensor de ubicaci´on. Un atributo propio de ´esta ser´ıa la probabilidad o el error asociado con la posici´on del usuario. Las relaciones objeto a y b con m´ aquina B y port´ atil son relaciones modificadas a decisi´on del usuario por medio de interacci´on con el sistema.

5.3.

Definici´ on formal

El fundamento te´orico para dar soporte a este modelo de datos se encontr´o en los sistemas de bases de datos orientados a objetos. Los sistemas de bases de datos, requieren de igual forma una definici´on formal que permita verificar su validez en cuanto a expresividad y computabilidad. Los sistemas de bases de datos orientados a objetos son 37

5.3 Definici´ on formal

Figura 5.3: Las relaciones se descomponen en dos enlaces y un nodo para permitir atributos y la validez dentro del modelo. descritos por Atkinson et al. (1989) y Graham (1991). El modelo de datos orientado a objetos de Gyssens et al. (1994) tiene la potencia suficiente para cubrir el modelo propuesto. El modelo se especifica como un multigrafo dirigido2 que puede ser restringido por un esquema y manipulado por medio de un conjunto b´asico de operaciones. En el grafo, tanto las entidades y atributos son definidos como nodos. Para permitir la adici´on de atributos a las relaciones ´estas son descompuestas en un par de aristas y un nodo como se observa en la figura 5.3. La definici´on se divide en esquema e instancia. Un esquema es una restricci´on sobre un modelo de datos que permite tanto al dise˜ nador como a la aplicaci´on, tener un conjunto de reglas v´alidas que describen una estructura bien formada en un lenguaje o representaci´on gr´afica. Una instancia es una construcci´on v´alida de acuerdo a un esquema. Se definen a continuaci´on esquemas e instancias para el modelo.

5.3.1.

Definici´ on del esquema Un esquema se define como una cinco-tupla

S = (C, A, F, N F, P) donde: 2

Un multigrafo dirigido es un grafo dirigido que permite m´as de una arista dirigida entre dos nodos (Grassman y Tremblay, 1996)

38

5.3 Definici´ on formal

C es un conjunto finito de nombres de clase de objetos; A es un conjunto finito de nombres de tipo de atributo de objetos; F es un conjunto finito de nombres tipo de enlaces funcionales; N F es un conjunto finito de nombres de tipo de enlaces no-funcionales; y P ⊂ C × (F ∪ N F ) × (C ∪ A). Un esquema puede ser representado por un grafo dirigido con dos tipos de nodos y dos tipos de aristas. El primer tipo de nodos toma cada uno de los nombres en C. El segundo tipo de nodos toma los nombres en A. El primer tipo de aristas est´ an marcadas con los nombres en F y el segundo tipo marcado con nombres en N F . P representa las aristas en el grafo. Las figura 5.4 ense˜ na el esquema para el caso. Los aristas funcionales representan propiedades y relaciones entre clases u ´nicas. Las aristas no-funcionales, sin embargo, expresan multiplicidad de relaciones. Los nodos usuario y dispositivo son ejemplos de clases de entidades. N´otese como las relaciones usa, tiene y porta se representan tambi´en como nodos, permitiendo que tengan atributos. Este esquema define que la relaci´on tiene es posible solamente entre un usuario y un dispositivo. La arista entre tiene y dispositivo es funcional para evitar enlaces con otro dispositivo. Las relaciones entre entidades en este esquema (usuario, dispositivo y objeto), s´olo se dan por intermedio de nodos de relaci´on (usa, tiene y porta). Las aristas de los atributos tienen valores sem´anticos. Los atributos son tipos b´asicos de lenguaje (Se puede considerar archivo como un tipo b´asico). El uso de aristas funcionales para los atributos asegura que no habr´a atributos duplicados.

5.3.2.

Definici´ on de las instancias Sea S = (C, A, F, N F, P) un esque-

ma. Una instancia sobre el esquema es un grafo I = (N, E) donde: N es un conjunto finito de nodos con nombre. Para un nodo n en N , la funci´on de obtenci´on de tipo λ(n) debe estar en C ∪ A; si λ(n) se encuentra en C se dice que n es un objeto; si λ(n) se encuentra en A, se habla de n como un atributo; 39

5.3 Definici´ on formal

Figura 5.4: Esquema para el caso de estudio. E es un conjunto de aristas con nombre. Para una arista e en E, se cumple que e = (m, α, n) con m y n en N y α = λ(e) en F ∪N F ; adem´ as (λ(m), α, λ(n)) ∈ P; si λ(e) est´a en F , e se define como una arista funcional; si λ(e) est´ a en N F se refiere a una arista no-funcional; y Si (m, α, n1 ) y (m, α, n2 ) ∈ E, entonces λ(n1 ) = λ(n2 ), (las clases de objetos conectados por aristas de tipo α a un mismo nodo m deben ser igual para conservar el esquema); adem´as, si α ∈ F , entonces n1 = n2 (si α es funcional no se permite que sea duplicada). La figura 5.5 ejemplifica una instancia sobre el esquema propuesto en la figura 5.4. Las clases y tipos de atributos toman valores concretos de objetos y datos al convertirse en instancias3 . S´olo las relaciones definidas por el esquema pueden establecerse. Un usuario puede contar con m´ ultiples dispositivos y ´este a su vez con m´ ultiples objetos dado que el enlace es no-funcional. 3

Comp´ arese con la relaci´ on clase-objeto en programaci´on Orientada a Objetos.

40

5.3 Definici´ on formal

Figura 5.5: Instancia para el caso de estudio.

41

5.3 Definici´ on formal

5.3.3.

Operaciones Se definen cinco operaciones sobre el modelo:

Adicionar un nodo Adicionar una arista Remover un nodo Remover una arista Redirigir una arista Las primeras cuatro operaciones son b´asicas en teor´ıa de modelos de grafos. La operaci´on de redirecci´on de arista consiste en eliminar y adicionar una arista. Las operaciones son v´alidas dentro del modelo. Esto puede verificarse en Gyssens et al. (1994).

42

6.

´ IMPLEMENTACION

Se implement´o el sistema propuesto en el caso de estudio. Las figuras 6.1, 6.2 y 6.3 presentan la interfaz gr´afica del sistema en el computador de escritorio y en realidad aumentada. La implementaci´on del caso permite definir c´omo se integra el modelo a un sistema de RA.

Figura 6.1: Los objetos en el computador de escritorio. La implementaci´on permitir´a, como se presentar´a en la parte 7, evaluar las ventajas del uso de este modelo frente a los m´etodos de implementaci´on tradicionales. Esta evaluaci´on ser´a u ´til para probar el concepto propuesto. A continuaci´on se presentar´a la implementaci´on del modelo y la arquitectura del sistema y como encaja el modelo dentro de ´esta.

6.1.

Representaci´ on del modelo

Se implement´o una librer´ıa de grafos dirigidos en el lenguaje Java para representar el modelo. La librer´ıa permite independencia de la aplicaci´on haciendo posible que sus elementos sean extendidos mediante herencia e implementaci´on de interfaces. La librer´ıa

6.1 Representaci´ on del modelo

Figura 6.2: El usario antes de tomar los objetos.

Figura 6.3: El usuario toma los objetos.

44

6.1 Representaci´ on del modelo

Figura 6.4: Librer´ıa de grafos. contiene la funcionalidad b´asica de construcci´on de entidades, relaciones y atributos como se propuso en 5.2. El diagrama de objetos de la figura 6.4 ense˜ na las clases principales de la librer´ıa. La clase Graph es la clase principal. Una instancia de Graph contiene un grupo de v´ertices (nodos1 ) y aristas formando un grafo dirigido. En la figura 6.4 las l´ıneas punteadas se˜ nalan dependencias de Graph con las dem´as clases. VertexListener y EdgeListener son interfaces que deben implementarse para ser subscriptores de un objeto Graph 2 , que se encarga de notificar ante cambios en los v´ertices o aristas. Los v´ertices y aristas son representados por los objetos Vertex y Edge. Los miembros comunes entre estos se definieron en la superclase GraphElement. La excepci´on de grafos GraphException es lanzada en caso de una operaci´on inv´alida sobre el grafo. Conocer los m´etodos miembro de Graph permitir´a entender la forma en que se mantiene la informaci´on del modelo. La figura 6.5 detalla los m´etodos de las clases principales. Graph implementa las cinco operaciones principales como se defini´o en 5.3. Adem´as, adiciona funciones para consultar el estado del grafo, obtener elementos y adicionar subscriptores. Los elementos del grafos tienen en com´ un atributos, identificaci´on y datos de usuario, que es un objeto opcional que puede ser requerido por la aplicaci´on para almacenar informaci´on adicional. Los atributos se definen como un par nombre-valor almacenados 1 2

Se nombraron v´ertices en vez de nodos par evitar conflictos de nombre con otras librer´ıas de Java. V´ease el patr´ on del observador o publicador-subscriptor de Gamma et al. (1995) 45

6.1 Representaci´ on del modelo

Figura 6.5: Clases principales de la librer´ıa de grafos. ambos como objetos String de Java. El uso de cadenas permite simplicidad y extensibilidad en el dise˜ no. La clase Vertex representa a un v´ertice o nodo. Este incluye m´etodos p´ ublicos dentro de la librer´ıa que conservan la integridad del grafo (Ej. addEdge()) y m´etodos p´ ublicos de consulta (Ej. getIncomingEdges()). La clase Edge representa una relaci´on. Un objeto Edge representa un nodo de relaci´on mas no un enlace en s´ı. Los enlaces no requieren de representaci´on debido a la descomposici´on presentada en la secci´on 5.2. Los valores sem´anticos de la relaci´on son almancenados por una atributo especial en Edge. En la implementaci´on para la aplicaci´on del caso de estudio fue requerido que el grafo fuera representado en XML. Puede pasarse del grafo XML al grafo en objetos y viceversa pues son equivalentes. El modelo descrito en formato XML nos permitir´a comprender la forma en que se estructuran los tributos y relaciones. La figura 6.6 presenta el c´odigo XML. Se usaron elementos node para representar v´ertices3 y edge para representar 3

Se us´o ahora la palabra node por compatibilidad con lenguajes de descripci´on de grafos basados en XML.

46

6.1 Representaci´ on del modelo

<node id="null" class="null"/> <node id="user1" class="user" name="user1"/> <edge id="u0" class="uses" source="user1" target="Da" time="0.0"/> <edge id="u1" class="has" source="user1" target="Ma"/> <node id="Da" class="device" type="desktop"/> <node id="Db" class="device" type="desktop"/> <node id="Ma" class="device" type="mobile"/> <node id="Oa" class="object" type="virtual" data="boxa.wrl"/> <edge id="Oa0" class="ported" source="Oa" target="Da"/> <node id="Ob" class="object" type="virtual" data="boxb.wrl"/> <edge id="Ob0" class="ported" source="Ob" target="Da"/> <node id="Oc" class="object" type="virtual" data="boxc.wrl"/> <edge id="Oc0" class="ported" source="Oc" target="Da"/>

Figura 6.6: Codigo en XML.

47

6.2 Arquitectura del sistema

relaciones. Un atributo de identificaci´on id es necesario para cada v´ertice y relaci´on. La clase o tipo de relaci´on se almacena como class. Los enlaces se representan como los atributos source y target que apuntar´an a los identificadores de los nodos. Los dem´as atributos son de igual forma atributos XML. Por la simplicidad del modelo a implementar no se definieron esquemas. En caso de requerirse, el lenguaje Scheme de XML podr´ıa usarse para restringir los elementos 4 . No obstante, las restricciones a las relaciones no podr´ıan definirse en Scheme pues est´an expresadas como valores sem´anticos de los atributos y no sint´acticos. Para restringir las relaciones deber´ıa incluirse l´ogica en la clase Graph.

6.2.

Arquitectura del sistema

La aplicaci´on propuesta en el caso de estudio se construy´o como un sistema distribuido compuesto por tres sub-aplicaciones conectadas por un middleware com´ un. Para su construcci´on se parti´o de Parallel Worlds Framework (Ganapathy et al., 2003) reimplementando el m´odulo de Realidad Aumentada, agregando soporte a una interfaz de usuario para escritorio y nuevos m´etodos de ubicaci´on. El grafo en forma de Scene Graph original se us´o a manera de jerarqu´ıa plana donde los v´ertices y aristas son todos hijos de la ra´ız del ´arbol. Como se present´o en 5.1, la aplicaci´on permite a un usuario tomar un objeto virtual de un equipo de escritorio a la realidad y luego tomarlo de regreso al mismo equipo de escritorio u otro. La ubicaci´on del objeto, es decir qu´e lo contiene, es el escritorio o el computador m´ovil. Se requiere entonces: Presentar al usuario el objeto virtual en el computador de escritorio. Presentar al usuario el objeto virtual en la realidad. El sistema debe saber en que equipo se encuentra el usuario.

4 El lenguaje de definici´ on de esquemas XML permite describir y restringir el contenido de un documento XML (Vlist, 2002).

48

6.2 Arquitectura del sistema

Figura 6.7: Arquitectura general del sistema. En la figura 6.7 puede verse la arquitectura general del sistema. Se defini´o la clase AwareApplication para encerrar la funcionalidad com´ un de las denominadas “subaplicaciones”. La funci´on m´as importante de AwareApplication es el acceso al modelo, eso se hace con un objeto GraphAdapter que hereda de Graph. GraphAdapter oculta los detalles de implementaci´on inherentes al middleware de PWF, DISCIPLE (Marsic, 1999). DiscipleGraphOperations tiene la tarea de convertir las operaciones sobre el grafo en operaciones de manipulaci´on del SG de DISCIPLE y viceversa. Una vez convertidas en operaciones del SG, el middleware se encarga de la distribuci´on y sincronizaci´on de las operaciones en la red. Las operaciones en el sentido opuesto son notificadas al GraphAdapter que usa los m´etodos de publicador-subscriptor del objeto grafo. Pueden extenderse dos tipos de sub-aplicaciones, una aplicaci´on de presentaci´on y una de localizaci´on. Una aplicaci´on de presentaci´on (AwareViewer ) presenta en realidad aumentada ejecut´andose en el computador port´atil o en una ventana en el computador de escritorio. La aplicaci´on de localizaci´on (AwareLocator ) por su parte controla el sistema que ubicaci´on del usuario. Tambi´en se ejecuta en el computador port´atil. Se presenta ahora cada una de ´estas.

6.2.1.

Visores Se implement´o el visor heredando de AwareApplication. La pre-

sentaci´on se hace independiente con la interfaz Viewer, que se implementa de acuerdo a s´ı es un visor de RA o de escritorio. Esto puede observarse en la figura 6.8. Aug49

6.2 Arquitectura del sistema

Figura 6.8: Arquitectura de los visores. mentedViewer hace uso de un adaptador que esconde el funcionamiento del representador gr´afico de RA. Este se encuentra implementado en c´odigo nativo para mayor rendimiento5 . DesktopViewer extiende una ventana gr´afica de las librer´ıas de Java. La presentaci´on 3D se hace con la librer´ıa Java3D (Sowizral et al., 2000). El uso del modelo hizo de la construcci´on del visor algo bastante simple. Los visores de escritorio presentan un bot´on que permite al usuario tomar o devolver el objeto. En la figura 6.9 en a) se observa como el usuario puede descargar los objetos, y en b) ponerlos de nuevo. El conocimiento de la aplicaci´on de la situaci´on del usuario se puede ver en c) cuando el sistema determina que el usuario no puede tomar los objetos pues no se encuentran en su computador m´ovil. Cuando el usuario no se encuentra en el lugar el bot´on se desactiva. El efecto del comando del usuario y el estado del bot´on se logran gracias al modelo. Descargar o tomar el objeto es una operaci´on de redirecci´on de enlace entre un objeto virtual y el dispositivo que lo porta. Tener conocimiento de qu´e dispositivos tiene el usuario se realiza con una simple consulta al nodo que lo representa. Una vez ubicado el dispositivo del usuario, los objetos se trasladan all´ı. 5

M´as detalles sobre la implementaci´ on pueden verse en Ganapathy et al. (2003) y Kato y Billinghurst (1999).

50

6.2 Arquitectura del sistema

Figura 6.9: Estados del visor de escritorio. Tanto el visor de realidad aumentada como el de escritorio son notificados de los cambios y determinan si tienen o no el objeto virtual. El activar o desactivar el bot´on se determina cuando el localizador decide en que lugar se encuentra el usuario. Si un visualizador de escritorio es notificado de un cambio en la relaci´on que indica la ubicaci´on del usuario, ´este verifica si se trata del computador donde se est´a ejecutando, en caso de que s´ı, debe activarlo, pues el usuario acaba de llegar. De lo contrario debe desactivarlo, pues no est´a all´ı. El visor de realidad aumentada, que se ejecuta en el computador m´ovil del usuario, tiene la funci´on de estar atento a cambios en la ubicaci´on de los objetos virtuales y presentar los objetos 3D como se observ´o en la figura 6.3. Si seg´ un el modelo, la ubicaci´on de los objetos virtuales es el computador m´ovil, estos deben presentarse en RA. El sistema RA es el mismo de PWF, haciendo uso de la librer´ıa de visi´on ARToolkit (Kato y Billinghurst, 1999). No se profundizar´a en los detalles del funcionamiento de este sistema pues se encuentra fuera del objetivo de este trabajo.

6.2.2.

Localizador El localizador se encarga de determinar qu´e equipo se en-

cuentra utilizando el usuario o si el usuario no se encuentra en ninguno. En la figura 6.10 se presenta el localizador. AwareLocator usa el sistema de ubicaci´on de PWF. La ubi51

6.2 Arquitectura del sistema

Figura 6.10: Arqutectura del localizador. caci´on se hace con una c´amara de video y patrones gr´aficos que pueden ser reconocidos por ARToolkit. La l´ogica del localizador es trivial con el uso del modelo. Al sistema de ubicaci´on se le asignan un conjunto de patrones y a cada patr´on se le asigna una ubicaci´on. Una vez se reconoce un patr´on se obtiene el nombre la ubicaci´on. El sistema de ubicaci´on notifica al AwareLocator cuya reacci´on es ejecutar una operaci´on de redirecci´on de arista entre la entidad que representa el usuario y la entidad del equipo de escritorio que representa la ubicaci´on. El localizador asocia un atributo de tiempo a la relaci´on entre el usuario y el equipo. Este atributo es u ´til para comprobar cuando estuvo el usuario en un lugar para poder mantener temporalmente una relaci´on en caso de que falle el sistema de ubicaci´on.

6.2.3.

Separaci´ on Modelo-Vista Una tercera aplicaci´on se implement´o con

la intenci´on visualizar el estado del grafo y demostrar en la arquitectura la aplicabilidad del concepto de separaci´on Modelo y Vista (Krasner y Pope, 1988). La aplicaci´on monitorea el modelo y lo presenta como un grafo que cambia durante la ejecuci´on (Ver figura 6.11).

52

6.2 Arquitectura del sistema

Figura 6.11: Monitor del modelo.

53

7.

´ EVALUACION

Las ventajas encontradas en el uso de un modelo de datos que contenga informaci´on del contexto pueden ser evaluadas en comparaci´on con el modelo de los sistemas tradicionales. Se hizo un an´alisis preliminar de las desventajas te´oricas del modelo previo. Se realiz´o luego una evaluaci´on pr´actica. La evaluaci´on se hizo mediante una prueba de dise˜ no y observaci´on en los beneficios de desarrollo con el nuevo modelo. Finalmente se comprob´o el cumplimiento de los requerimientos de dise˜ no establecidos en la secci´on 4.4.

7.1.

Comparaci´ on con el modelo tradicional

En las secciones 1.2 y 4.2 se mostr´o c´omo el modelo de datos central por excelencia en sistemas de RA es el Scene Graph. La preferencia por el Scene Graph como modelo central proviene de las aplicaciones de gr´aficas tridimensionales y la Realidad Virtual. El modelo del SG es limitado y debe complementarse con otros modelos que expresen en mejor medida la situaci´on del contexto. Como se mostr´o en 5.2 una de las posibles representaciones del contexto es como un conjunto de relaciones entre entidades u objetos que corresponden a elementos de la realidad. Los modelos de entidades y objetos son usados en sistemas que manejan datos complejos tales como la Inteligencia Artificial (Graham, 1991). Para Henricksen et al. (2002) y seg´ un el modelo como se defini´o en la secci´on 5.3, las relaciones entre entidades del mundo son relaciones sem´anticas de m´ ultiples tipos y en s´ı expresan la informaci´on del contexto. En el modelo de SG en su forma original (Strauss y Carey, 1992), las relaciones son de tipo jer´arquicas geom´etricas. El Scene Graph no puede, por s´ı solo, representar la informaci´on del contexto.

7.2 Experimento de dise˜ no

Figura 7.1: Modelo de datos simple geom´etrico.

7.2.

Experimento de dise˜ no

Se realiz´o un experimento de dise˜ no para comparar los modelos de datos. El experimento consisti´o en dise˜ nar el mismo sistema propuesto en el caso de estudio con modelos de datos restringidos. Se hizo un estudio por niveles, en donde en cada nivel se agregaba m´as informaci´on de contexto. La primera aproximaci´on, o nivel cero, fue el caso de una aplicaci´on de escritorio con la misma funcionalidad, es decir, que permitiera trasladar un objeto. La conclusi´on para este dise˜ no fue que ser´ıa una aplicaci´on habitual de transferencia de archivos donde la informaci´on de la situaci´on es provista por el usuario manualmente. Esta informaci´on, como por ejemplo, cu´al es el destino del archivo, es dada expl´ıcitamente por el usuario. La aplicaci´on s´olo cuenta con el modelo de datos del objeto, que corresponde al sistema de archivos y desconoce totalmente el entorno y el usuario. No se implement´o este sistema por su similitud a aplicaciones actuales (Ej. FTP). Para el nivel uno se consider´o un sistema de realidad aumentada que mantuviera la informaci´on de los objetos pero sin agregar a´ un la informaci´on del usuario. La implementaci´on fue basada en el modelo de datos de PWF (v´ease secci´on 1.2), pues al igual que en este nivel, PWF s´olo consideraba en el modelo los objetos reales, virtuales y sus relaciones geom´etricas. Tal modelo se puede apreciar en la figura 7.1 y el c´odigo XML correspondiente en la figura 7.2. En la aplicaci´on de nivel uno, debido a que no se contaba con la informaci´on del usuario,

55

7.2 Experimento de dise˜ no

<Model source="boxa.wrl"/> <Model source="boxb.wrl"/> <Model source="boxc.wrl"/>

Figura 7.2: C´odigo en XML. se desconoc´ıa su ubicaci´on y no se pod´ıan determinar los estados del visor como se mostr´o en la secci´on 6.2. En este nivel, para fijar la posici´on del objeto, cada aplicaci´on asociaba la posici´on virtual de los objetos virtuales con el lugar en que se encontraban. Es decir, que para estar en un computador de escritorio, el objeto deb´ıa estar dentro de un rango de coordenadas (un cubo), fuera de este cubo el objeto estaba en RA. Este tipo de asociaci´on se ha usado previamente en Realidad Aumentada en el trabajo de Schmalstieg et al. (2002). En el nivel dos, se consider´o la ubicaci´on del usuario, aunque no se agreg´o el usuario como un elemento del modelo. Para determinar la ubicaci´on de igual forma se usaron relaciones espaciales entre la posici´on del usuario y la de los equipos. Trat´o de darse una posici´on aproximada del usuario usando el reconocedor de patrones del localizador. La manera en que esta aplicaci´on es semejante a la de la arquitectura de referencia presentada en la secci´on 4.2. Al igual que en ´esa, una parte del sistema (subsistema de contexto) se encarga de recoger la informaci´on de los sensores de ubicaci´on o Trackers para manejar la informaci´on del contexto. Contando con la posici´on se pod´ıa entonces dar conocimiento a la aplicaci´on de donde se encontraba el usuario y dar el mismo funcionamiento al bot´on del visor. A pesar de que el sistema cumpl´ıa con la misma funci´on result´o menos intuitivo al momento de implementarlo. El mapeo de la posici´on del usuario no ten´ıa sentido sabiendo que lo u ´nico que importaba era saber a cual equipo se encontraba y no su posici´on exacta. Otra desventaja del modelo en este punto, es la

56

7.3 Ventajas de codificaci´ on

ausencia del atributo de tiempo que puede toma la relaci´on usa. Tal valor se usa para saber qu´e tan v´alida puede ser la afirmaci´on “usa”, en caso de que fallara el sistema de ubicaci´on. Las relaciones en un modelo SG no incluyen atributos. Se determin´o que el nivel tres, que agregar´ıa al usuario como un elemento, corresponder´ıa a un modelo similar al propuesto sin los valores sem´anticos ni atributos de las relaciones. Este modelo no se evalu´o por sus similitudes y porque se sal´ıa de la definici´on de SG, resultando en un modelo h´ıbrido. El modelo propuesto en este trabajo ser´ıa de nivel cuatro, que agrega atributos a las aplicaciones y por tanto valores sem´anticos. Se concluy´o que la aplicaci´on como tal resultaba m´as compleja de desarrollar con el modelo tradicional. Este modelo no integra en una misma estructura la informaci´on del contexto (incluyendo al usuario) y limita las relaciones a espaciales. Se concluy´o adem´as que en caso de implementarse, puede conservarse el modelo gr´afico debido a su eficiencia (Strauss y Carey, 1992), pero debe existir un modelo de datos de contexto como se present´o aqu´ı.

7.3.

Ventajas de codificaci´ on

Se analizaron las ventajas del modelo al momento de la programaci´on. Haciendo uso del modelo la l´ogica del sistema se redujo a comprobar los estados del modelo y reaccionar por medio del conjunto de operaciones b´asicas. Se hizo uso del patr´on del publicadorsubscriptor para escuchar por los cambios del grafo como se vio en la parte 6. Las cinco operaciones b´asicas fueron las u ´nicas requeridas para cambiar el estado del modelo. Un ejemplo ser´a u ´til para hacer la comparaci´on. En la figura 7.3, se presenta el c´odigo Java de la adici´on de un objeto 3D a uno de los visores. Este c´odigo proviene de la implementaci´on del nivel uno de la que se habl´o en la secci´on anterior. Los objetos de un SG en general no cuentan con identificadores por lo que la operaci´on de adici´on requiere de una b´ usqueda. Para este caso se busca un elemento del tipo Model que almacena el objeto. Luego se hace uso de un objeto Viewer para presentarlo. En la implementaci´on del modelo para el caso, la misma operaci´on se hace por medio del objeto grafo. Se puede ver el c´odigo Java de en la figura 7.4. Todos los elementos del grafo cuentan con un identificador y se usa ´este para adquirir el objeto y cargar el 57

7.3 Ventajas de codificaci´ on

//UnawareViewer.java //... Node node; NodeInfo info; Enumeration e = nodeInfos.elements(); for( ;e.hasMoreElements(); ) { info = (NodeInfo)e.nextElement(); node = info.getNode(); if ( node.getNodeType() == Node.ELEMENT_NODE && node.getNodeName().equals("Model")) { viewer.loadObject( ((Element)node).getAttribute("source")); //...

Figura 7.3: Detectando la adici´on de un objeto en el SceneGraph.

58

7.4 Satisfacci´ on de los requerimientos

//AwareViewer.java public void edgeChanged(Edge edge){ Vertex loc = graph.getVertex(location); if(edge.getSource().getAttribute("class").equals("object")){ if(edge.targetIs(loc)){ viewer.loadObject(edge.getSource()); //...

Figura 7.4: Detectando la adici´on de un objeto en el modelo. objeto 3D. El grafo mantiene una tabla de hashing con cada uno de los elementos y relaciones. El manejo de identidades fue una de las mayores ventajas encontradas. Se encontraron ventajas tambi´en con la redirecci´on de aristas. El c´odigo de la figura 7.5 hace parte del localizador. La funci´on del localizador es informar al sistema donde se encuentra el usuario, en este caso en qu´e equipo. Una vez el localizador conoce el nombre de la posici´on, ´este adquiere la arista que relaciona al usuario con la ubicaci´on y el v´ertice correspondiente. Una operaci´on de redirecci´on es suficiente para determinar la ubicaci´on del usuario. En el Scene Graph, debido a que se hace uso de geometr´ıa, la misma operaci´on requerir´ıa determinar la posici´on en el espacio del usuario y bas´andose en ´esta, calcular en qu´e lugar se ubica.

7.4.

Satisfacci´ on de los requerimientos

Se comprobar´a la satisfacci´on de los requerimientos propuestos en la secci´on 4.4. El requerimiento (1) se cumple con la definici´on de clases y objetos en 5.3. Un objeto puede abstraer cualquier tipo de entidad, virtual o real y almacenar sus atributos. La unicidad de (2) se cumple con la definici´on del modelo en forma de grafo y las operaciones sobre ´este. El grafo es un ente u ´nico. S´olo hay un objeto grafo por aplicaci´on. La escalabilidad y extensibilidad requeridas en (3) son permitidas por la multiplicidad de relaciones definida en 5.3. La capacidad de abstracci´on por el sistema (4) es evidente pues la estructura de grafo es representable y se pudo implementar en un lenguaje de 59

7.4 Satisfacci´ on de los requerimientos

//AwareLocator.java //... if(newLoc.equals("")){ newLoc = "null"; } Edge locationEdge = graph.getEdge("uses"); Vertex newTarget = graph.getVertex(newLoc); if(locationEdge == null){ Logger.log(this,"could not find location edge"); return; } graph.redirectEdge(locationEdge,newTarget); return; }

Figura 7.5: Cambiando la ubicaci´on del usuario en el modelo.

60

7.4 Satisfacci´ on de los requerimientos

programaci´on como Java, como se vio en la secci´on 6.1. Los grafos son una estructura natural para los humanos (Grassman y Tremblay, 1996) y han sido una abstracci´on u ´til para variedad de problemas (Aho y Ullman, 1995). La definici´on formal del modelo exigida por (5) se present´o en 5.3 y est´a soportada por Gyssens et al. (1994).

61

8.

˜ APORTE DE DISENO

El aporte al dise˜ no de aplicaciones RA se presenta como un Patr´on de Dise˜ no. Un patr´on de dise˜ no describe una soluci´on a un problema de software que puede reutilizarse. Un patr´on es una descripci´on corta y general del problema, una alternativa de soluci´on, su implementaci´on y consecuencias. El patr´on resumir´a la propuesta en una forma que sea de r´apida comprensi´on y reutilizaci´on. Se hace uso de la estructura de definici´on presentada en Gamma et al. (1995).

Nombre Modelo de Contexto

Clasificaci´ on Estructural - Objetos

Objetivo Representar la informaci´on de la situaci´on del mundo dentro de la aplicaci´on de Realidad Aumentada.

Motivaci´ on Las aplicaciones de Realidad Aumentada requieren conocer la situaci´on en que se encuentra el usuario. Tal situaci´on puede incluir el usuario, objetos virtuales y reales, dispositivos y dem´as elementos relevantes a la aplicaci´on. El modelo gr´afico de la Realidad Virtual es en general insuficiente para almacenar tal informaci´on.

Aplicabilidad Haga uso del patr´on de Modelo de Contexto cuando exista relaciones m´as que geom´etricas entre los elementos del mundo real y virtual.

Estructura Separe la aplicaci´on del modelo. Maneje el modelo como un objeto que a su vez encierra un conjunto de elementos. Los elementos representan las partes del mundo. Estos est´an relacionados entre s´ı. Separe la vista del modelo dejando que la aplicaci´on de encargue de la representaci´on (V´ease figura 8.1).

Figura 8.1: Estructura del patr´on.

Participantes Application: contiene la l´ogica de la aplicaci´on. Model: abstrae el modelo. ModelElement: abstrae los elementos del modelo.

Colaboraci´ on Application act´ ua sobre Model. Model efect´ ua los cambios sobre los ModelElement. 63

Ante cambios en ModelElement, Model notifica a Application.

Consecuencias 1. Flexibilidad y riqueza de representaci´on. 2. Separaci´on de la l´ogica y el modelo. 3. Separaci´on de la vista y el modelo. 4. M´ ultiples aplicaciones pueden acceder al modelo. 5. Debe mantenerse sincronizaci´on entre la vista y el modelo. 6. El numero de objetos crece con la informaci´on que se maneja.

Implementaci´ on 1. Se debe proveer una vista para el modelo. Cada aplicaci´on debe encargarse de esto. 2. El modelo debe proteger los elementos de modificaci´on externa de las relaciones entre elementos. 3. Defina el conjunto de operaciones b´asicas sobre el modelo.

Patrones relacionados Modelo-Vista-Controlador Observador Fachada

64

9.

CONCLUSIONES

Este trabajo present´o un modelo de datos para representar la informaci´on del mundo o contexto, en aplicaciones de Realidad Aumentada (RA). Se defini´o la RA y se present´o la necesidad de un nuevo modelo de datos para representar la informaci´on del mundo. Se explic´o luego c´omo el ´area de las Aplicaciones Dependientes del Contexto ha encontrado problemas similares y como podr´ıa emplearse esa experiencia en RA. Se defini´o un marco de referencia en modelos de datos, Aplicaciones Dependientes del Contexto y RA. Para proceder con la propuesta de modelo se presentaron cu´ales eran los problemas de las arquitecturas actuales, partiendo de la experiencia en el desarrollo de dos sistemas de Realidad Aumentada y presentando una arquitectura de referencia. Se defini´o una lista de requerimientos que deb´ıa cumplir el modelo de contexto. Se present´o un caso de estudio para poder analizar las ventajas del modelo. Se defini´o el modelo y se expres´o formalmente. El caso de estudio planteado se implement´o con el modelo de contexto. Se present´o la arquitectura del sistema construido. Para evaluar la soluci´on planteada se hizo una comparaci´on te´orica y pr´actica con el modelo tradicional y se determinaron las ventajas sobre ´este. La propuesta cumpli´o con los requerimientos y se encontr´o que simplificaba el dise˜ no de la aplicaci´on. Un patr´on de dise˜ no fue u ´til para expresar la propuesta de una forma resumida y reutilizable para el desarrollo de aplicaciones de RA. De lo aqu´ı expresado puede concluirse que: 1. Lograr la combinaci´on real-virtual en la Realidad Aumentada es compleja y no consiste simplemente en sobreponer geom´etricamente uno mundo sobre el otro. 2. La realidad aumentada puede considerarse como una de las interfaces de la computaci´on ubicua. 3. Las arquitecturas de Realidad Aumentada actuales no cuentan con la informaci´on adecuada del mundo real. 4. Los sistemas de RA heredaron el modelo de las aplicaciones de gr´aficas y de Realidad Virtual y no se hab´ıan considerado alternativas a ´este.

5. Las aplicaciones de Realidad Aumentada pueden considerarse como aplicaciones dependientes del contexto. 6. Las aplicaciones de Realidad Aumentada requieren de un modelo de datos diferente al modelo de datos de las aplicaciones tradicionales de graficas tridimensionales y de Realidad Virtual. 7. Las estructuras y modelos de datos no han sido de especial preocupaci´on para el ´area de RA. 8. El avance de las aplicaciones ha requerido que los modelos de datos evolucionen a la par. El modelo orientado a objetos es un ejemplo de la b´ usqueda de modelos m´as apropiados para sistemas de alta interacci´on con el mundo y el usuario. 9. La informaci´on de contexto exhibe distintas caracter´ısticas temporales, es imperfecta, tiene diferentes representaciones y sus elementos est´an altamente relacionados. 10. Un modelo de datos para RA debe admitir la representaci´on de entidades virtuales, reales y sus relaciones; debe ser unificado; debe poder escalarse y extenderse; el modelo debe ser comprensible por el sistema y el dise˜ nador; y debe poder expresarse formalmente. 11. El contexto puede representarse como un grafo formado por un conjunto de entidades y sus relaciones. 12. Los modelos de datos orientados a objetos tiene una definici´on formal que puede aplicarse al modelo propuesto. 13. La implementaci´on del caso de estudio demostr´o la aplicabilidad del modelo y present´o sus caracter´ısticas fundamentales. 14. El Scene Graph no puede, por s´ı s´olo, representar la informaci´on del contexto. 15. La aplicaci´on del caso de estudio result´o m´as compleja de desarrollar con el modelo tradicional. 16. El modelo propuesto cumple con los requerimientos planteados. 66

9.1 Trabajo futuro

17. El modelo no niega el uso del Scene Graph, s´olo se sugiere el uso del modelo como modelo principal de la aplicaci´on de RA. 18. Un patr´on de dise˜ no permiti´o resumir la propuesta de una forma tal que se pueda comprender y reutilizar f´acilmente.

9.1.

Trabajo futuro

En general se pretende realizar un estudio m´as profundo de modelos de datos, en especial, explorar la combinaci´on de modelos de datos sem´anticos y orientados a objetos. Tambi´en se busca encontrar una forma de comparaci´on formal que permita expresar m´as estrictamente las ventajas del modelo de contexto frente al Scene Graph. Debe probarse el modelo con aplicaciones m´as complejas, de mayor interacci´on con el usuario y dinamismo para determinar su verdadero potencial. Existe un ´area en espec´ıfico que es de especial atenci´on. La sincronizaci´on entre el modelo de datos de contexto y el modelo de representaci´on visual (Ej. el Scene Graph) debe ser tenida en cuenta. La figura 9.1 ilustra este caso. Una instancia de modelo incluye tanto elementos visibles como no visibles. Los elementos visibles, a ser representados en realidad aumentada podr´ıan necesitar ser extra´ıdos del modelo y organizados de acuerdo a las relaciones espaciales existentes. El mapeo del modelo al grafo debe considerarse. En especial, si los sistemas son complejos, altamente din´amicos y requieren gran cantidad de elementos gr´aficos. Se trata de un problema de bases de datos dual1 y fue uno de los problemas de dise˜ no que intent´o solucionar el Scene Graph en sus or´ıgenes (Strauss y Carey, 1992). El Scene Graph, por esta raz´on, mezcl´o el modelo y la vista para simplificar y tratar de hacer m´as eficiente el despliegue gr´afico. El patr´on Modelo-Vista-Controlador sugiere, sin em´ bargo, tal separaci´on (Krasner y Pope, 1988). Esta, se hace bastante apropiada para sistemas distribuidos y que presentan la informaci´on de distintas formas, tales como los dependientes del contexto (Banavar et al., 2000). Para tal caso, formas de mapeo de modelo gr´afico al modelo de datos deben investigarse. M´etodos heur´ısticos o de extrac1

En ingl´es The Dual Database Problem. Reitmayr (2004); Schmalstieg et al. (2002)

67

9.1 Trabajo futuro

Figura 9.1: Mapeo entre el modelo y un modelo de representaci´on. ci´on de a´rboles, como los algoritmos de ´arboles de expansi´on (Grassman y Tremblay, 1996) deben tenerse en cuenta.

68

BIBLIOGRAF´IA Aho, Alfred V.; Hopcroft, John E. y Ullman, Jeffrey D. Data Structures and Algorithms. Addison-Wesley Series in Computer Science and Information Processing AddisonWesley, 1983. Aho, Alfred V. y Ullman, Jeffrey D. Foundations of Computer Science. Computer Science Press, 1995. Andries, M. Graph Rewrite Systems and Visual Database Languages. Tesis Doctoral Leiden University The Netherlands, 1996. Atkinson, Malcolm; Bancilhon, Fran¸cois; DeWitt, David; Dittrich, Klaus; Maier, David y Zdonik, Stanley. The Object-Oriented Database System Manifesto. En : Proceedings of the First International Conference on Deductive and Object-Oriented Databases p. 223–240. Kyoto, Japan, 1989. Azuma, R. A survey of augmented reality. En : Computer Graphics (SIGGRAPH ’95 Proceedings, Course Notes 9: Developing Advanced Virtual Reality Applications) p. 1–38. 1995. Azuma, R.; Baillot, Y.; Behringer, R.; Feiner, S.; Julier, S. y MacIntyre, Blair. Recent Advances in Augmented Reality. En : IEEE Computer Graphics and Applications, 2001. Banavar, Guruduth; Beck, James; Gluzberg, Eugene; Munson, Jonathan; Sussman, Jeremy y Zukowski, Deborra. Challenges: an application model for pervasive computing. En : Proceedings of the 6th annual international conference on Mobile computing and networking p. 266–274. ACM Press, 2000. ISBN 1-58113-197-6. Brown, P. J.; Bovey, J. D. y Chen, X. Context-aware Applications: from the Laboratory to the Marketplace. En : IEEE Personal Communications tomo 4, no 5, p. 58–64, 1997. Br¨ ugge, Bernd; MacWilliams, Asa y Reicher, Thomas. Software Architectures for Augmented Reality Systems – Report to the ARVIKA consortium. Inf. T´ec. TUM-I0410 Technische Universit¨at M¨ unchen, 2002.

BIBLIOGRAF´ IA

Dey, A.; Abowd, G. y Salber, D. A Context-based Infrastructure for Smart Environments. En : Proceedings of the 1st International Workshop on Managing Interactions in Smart Environments (MANSE ’99) p. 114–128. 1999. Dey, A. K. y Abowd, G. D. Towards a better understanding of context and contextawareness. En : CHIA’00 workshop on Context-Awareness. 2000. Feiner, Steven; MacIntyre, Blair; Hollerer, Tobias y Webster, Anthony. A Touring Machine: Prototyping 3D Mobile Augmented Reality Systems for Exploring the Urban Environment. En : Proceedings of the 1st IEEE International Symposium on Wearable Computers p. 74. IEEE Computer Society, 1997. ISBN 0-8186-8192-6. Gamma, E.; Helm, R.; Johnson, R. y Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Ganapathy, S. Kicha; Morde, Ashutosh y Agudelo, Andres. Tele-collaboration in Parallel Worlds. En : Proceedings of the 2003 ACM SIGMM workshop on Experiential telepresence p. 67–69. ACM Press, 2003. ISBN 1-58113-775-3. Gigch, J. System design modeling and metamodeling. Plenum Press, New York, 1991. Graham, Ian. Object oriented methods. Addison-Wesley Longman Publishing Co., Inc., 1991. ISBN 0-201-56521-8. Grassman, Winfried Karl y Tremblay, Jean-Paul. Logic and Discrete Mathematics. Prentice-Hall, 1996. Gray, Philip D. y Salber, Daniel. Modelling and Using Sensed Context Information in the Design of Interactive Applications. En : Proceedings of the 8th IFIP International Conference on Engineering for Human-Computer Interaction. 2001. Gyssens, Marc; Paredaens, Jan; den Bussche, Jan Van y van Gucht, Dirk. A GraphOriented Object Database Model. En : IEEE Transactions on Knowledge and Data Engineering, 1994. Harter, A.; Hopper, A.; Steggles, P.; Ward, A. y Webster, P. The anatomy of a contextaware application. En : Mobile computing and networking p. 59 – 68. 1999.

70

BIBLIOGRAF´ IA

Heileman, Gregory L. Data Structures, Algorithms and Object Oriented Programming. McGraw-Hill Higher Education, 1996. ISBN 0070278938. Henricksen, K.; Indulska, J. y Rakotonirainy, A. Modeling context information in pervasive computing systems. En : Springer, ed., 1st International Conference on Pervasive Computing. Zurich, Switzerland, 2002. Henricksen, Karen; Indulska, Jadwiga y Rakotonirainy, Andry. Infrastructure for Pervasive Computing: Challenges. En : GI Jahrestagung (1) p. 214–222. 2001. Hull, R.; Neaves, P. y Bedford-Roberts, J. Towards Situated Computing. En : 1st International Symposium on Wearable Computers p. 146–153. 1997. Ishii, Hiroshi y Ullmer, Brygg. Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms. En : CHI p. 234–241. 1997. Kato, H. y Billinghurst, M. Marker tracking and HMD calibration for a video-based augmented reality conferencing system. En : Proceedings of the 2nd IEEE and ACM International Workshop on Augmented Reality ’99 p. 85–94. 1999. Kim, Ted H. y Popek, Gerald J. Frigate: An Object-Oriented File System for Ordinary Users. En : Proceedings of the 3rd Conference on ObjectOriented Technologies and Systems p. 115–129. 1997. Kindberg, T.; Barton, J. et al. People, places, things: Web presence for the real world. En : Proceedings of the Third IEEE Workshop on Mobile Computing Systems and Applications (WMCSA’00) p. 19. IEEE Computer Society, 2000. Krasner, Glenn E. y Pope, Stephen T. A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. En : J. Object Oriented Program. tomo 1, no 3, p. 26–49, 1988. ISSN 0896-8438. Licklider, J. C. R. Man-Computer Symbiosis. En : W. D. Orr, ed., Conversational Computers p. 3–5. Wiley, New York, 1968. Marsic, Ivan. DISCIPLE: a framework for multimodal collaboration in heterogeneous environments. En : ACM Comput. Surv. tomo 31, no 2, p. 4, 1999. ISSN 0360-0300.

71

BIBLIOGRAF´ IA

Milgram, P.; Takemura, H.; Utsumi, A. y Kishino, F. Augmented Reality: A Class of Displays on the Reality-Virtuality Continuum. En : Proceedings on Telemanipulator and Telepresence Technologies SPIE. 1994. Newman, Joseph; Wagner, Martin; Bauer, Martin; MacWilliams, Asa; Pintaric, Thomas; Beyer, Dagmar; Pustka, Daniel; Strasser, Franz; Schmalstieg, Dieter y Klinker, Gudrun. Ubiquitous Tracking for Augmented Reality. En : Proceedings of The Third IEEE and ACM International Symposium on Mixed and Augmented Reality. Valtimore, US, 2004. Norman, D. The Invisible Computer. MIT Press, Cambridge, Massachusetts, 1998. Reicher, Thomas; MacWilliams, Asa; Br¨ ugge, Bernd y Klinker, Gudrun. Results of a Study on Software Architectures for Augmented Reality Systems. En : The Second IEEE and ACM International Symposium on Mixed and Augmented Reality. 2003. Reitmayr, Gerhard. On Software Design for Augmented Reality. Tesis Doctoral Vienna University of Technology, 2004. Ricciuti, M. New windows could solve age old format puzzle at a price. CNET News.com, 2002. Ryan, N.; Pascoe, J. y Morse, D. Enhanced Reality Fieldwork: the Context-Aware Archaeological Assistant. Computer Applications in Archaeology, 1997. Saha, Debashis y Mukherjee, Amitava. Pervasive Computing: A Paradigm for the 21st Century. En : IEEE Computer Magazine p. 25–31, 2003. Satyanarayanan, M. Pervasive Computing: Vision and Challenges. En : IEEE Personal Communications p. 10–17, 2001. Schilit, B.; Adams, N. y Want, R. Context-Aware Computing Applications. En : 1st International Workshop on Mobile Computing Systems and Applications p. 85–90. 1994. Schilit, B. y Theimer, M. Disseminating Active Map Information to Mobile Hosts. En : IEEE Network p. 22–32, 1994.

72

BIBLIOGRAF´ IA

Schilit, Bill; Theimer, Marvin y Welch, Brent. Customizing Mobile Application. En : USENIX Symposium on Mobile and Location-independent Computing p. 129–138. Cambridge, MA, US, 1993. Schmalstieg, Dieter; Fuhrmann, Anton; Hesina, Gerd; Szalavari, Zsolt; Encarnacao, L. Miguel; Gervautz, Michael y Purgathofer, Werner. The studierstube augmented reality project. En : Presence: Teleoper. Virtual Environ. tomo 11, no 1, p. 33–54, 2002. ISSN 1054-7460. Schmalstieg, Dieter; Reitmayr, Gerhard y Hesina, Gerd. Distributed applications for collaborative three-dimensional workspaces. En : Presence: Teleoper. Virtual Environ. tomo 12, no 1, p. 52–67, 2003. ISSN 1054-7460. Schmidt, A.; Aidoo, K. A.; Takaluoma, A.; Tuomela, U.; Laerhoven, K. Van y de Velde, W. Van. Advanced Interaction in Context. En : Lecture Notes in Computer Science tomo 1707, p. 89–??, 1999. Singhal, S. y Zyda, M. Networked Virtual Environments: Design and Implementation. Addison-Wesley, 1999. Smith, M. y Smith, D. C. P. Database Abstractions: Aggregations and Generalization. En : ACM. TODS, 1977. Sowizral, H.; Rushforth, K. y Deering, M. The Java 3D API Specification. AddisonWesley Publishing Company, 2000. Strauss, Paul S. y Carey, Rikk. An object-oriented 3D graphics toolkit. En : Proceedings of the 19th annual conference on Computer graphics and interactive techniques p. 341–349. ACM Press, 1992. ISBN 0-89791-479-1. Szalavari, Z. y Gervautz, M. The personal interaction panel- A two handed interface for augmented reality. En : Proceedings of EUROGRAPHICS 97. 1997. The Committee for Advanced DBMS Function. Third-Generation Data Base System Manifesto. Inf. T´ec. ERL-90-28 SIGMOD RECORD, 1990. Vlist, Eric. XML Schema: The W3C’s Object-Oriented Descriptions for XML. O’Reilly, 2002. 73

BIBLIOGRAF´ IA

Weiser, Mark. The computer for the 21st century. En : Human-computer interaction: toward the year 2000 p. 933–940, 1995.

74