O processamento mais complexo ´e efectuado por um m´odulo de gest˜ao de informa¸c˜ao, que, na essˆencia, ap´os receber uma entrada vinda do m´odulo de rastreio, activa um m´odulo interpretador contextual que indica como a informa¸c˜ao adicional deve ser composta. S˜ao questionados dois servi¸cos de dados distintos com vista a obter a informa¸c˜ao adicional total. A informa¸c˜ao ´e ent˜ao direccionada para o objecto/ecr˜a ou cliente m´ovel que a solicitou. A Figura 4.3 apresenta uma arquitectura mais detalhada, onde s˜ao vis´ıveis os m´odulos principais que a integram. Estes m´odulos correspondem `a camada do objecto aumentado, implementando apenas o requisito prim´ario de interac¸c˜ao passiva.
Passa-se a descrever mais detalhadamente cada um dos m´odulos e sub-m´odulos determinan- tes.
• Rastreio: Este m´odulo ´e o complemento para a aumenta¸c˜ao visual do objecto, sendo essencial para qualquer aplica¸c˜ao na ´area. ´E o respons´avel pela detec¸c˜ao e identifica¸c˜ao do utilizador, adicionando ao objecto a capacidade de percep¸c˜ao de co-presen¸ca. ´E, por
Figura 4.3: M´odulos da Arquitectura Gen´erica (Objecto Aumentado).
exemplo, atrav´es deste m´odulo que se pode saber durante quanto tempo o utilizador se de- teve na ´area do objecto. Num espa¸co repleto de objectos aumentados consegue-se conhecer o percurso do utilizador ao longo dos objectos, conhecendo-se a localiza¸c˜ao e podendo-se estimar o sentido da movimenta¸c˜ao. S˜ao v´arias as tecnologias que podem ser utilizadas neste m´odulo (e.g., RFID, Bluetooth, etc. - ver Subsec¸c˜ao 3.3), sendo aconselh´avel criar uma camada de abstrac¸c˜ao - Gestor de Rastreio - que funcione como interface de sa´ıda e providencie de forma linear todos os dados ao n´ucleo aplicacional. Destaque ainda para a camada Middleware que se encontra dependente da tecnologia utilizada. Esta camada faz a abstrac¸c˜ao do Dispositivo de Rastreio (hardware) utilizado, sendo essencial para a camada superior, o Gestor de Rastreio, que deste modo apenas tem que integrar a(s) interface(s) disponibilizadas pelo Middleware.
Apresenta¸c˜ao da informa¸c˜ao adicional sobre o objecto e de poss´ıveis servi¸cos. A infor- ma¸c˜ao deve ser apresentada o mais rapidamente poss´ıvel ao utilizador, verificando-se o menor tempo de latˆencia entre o momento de detec¸c˜ao/identifica¸c˜ao do utilizador e o de visualiza¸c˜ao da informa¸c˜ao. Uma vez que a informa¸c˜ao adicional ´e direccionada para o utilizador detectado, n˜ao far´a muito sentido que este j´a n˜ao se encontre no local quando a mesma for apresentada. O cen´ario de aplica¸c˜ao, e em particular a cadˆencia de utili- zadores, ´e determinante para a escolha da tecnologia a usar. Visto existir uma grande diversidade nesta escolha (ver Subsec¸c˜ao 3.7), poder´a existir a necessidade de se criar uma camada de gest˜ao/abstrac¸c˜ao - Gestor de Dispositivo - para determinados casos de uso, i.e., criar protocolos uniformes para gest˜ao do(s) Dispositivo(s) de Visualiza¸c˜ao, facilitando a programa¸c˜ao do sub-m´odulo Composi¸c˜ao de Apresenta¸c˜ao. Este m´odulo questiona e recebe mensagens do servidor no m´odulo central da aplica¸c˜ao. As mensagens d˜ao indica¸c˜oes sobre os intervenientes na interac¸c˜ao, i.e., objecto, utilizador e respectivo perfil, e ainda sobre o tipo de informa¸c˜ao adicional. Este tipo indica que tipo de interface gr´afica deve ser constru´ıda/utilizada, enquanto que os m´odulos de Personaliza¸c˜ao e de Conte´udos de Objectos devem ser questionados para que se obtenham os conte´udos para a apresenta¸c˜ao.
• Personaliza¸c˜ao: Este m´odulo comporta-se como um servi¸co de dados que faz a gest˜ao dos perfis da aplica¸c˜ao e dos dados dos utilizadores, podendo integrar um sub-m´odulo opcional para defini¸c˜oes individuais. O sub-m´odulo Gest˜ao de Perfis encarrega-se da defini¸c˜ao e da gest˜ao de um conjunto de perfis baseados em preferˆencias e interesses relacionados com o cen´ario de aplica¸c˜ao. Uma vez que a quantidade de informa¸c˜ao adicional sobre um objecto pode ser muita, justifica-se que a mesma seja estruturada e organizada de acordo com os perfis criados para o cen´ario. Num sistema de partilha de ecr˜a p´ublico este ´e um requisito essencial. Da mesma forma, o utilizador n˜ao dever´a receber toda a informa¸c˜ao sobre o objecto no seu dispositivo m´ovel, em caso de cen´ario com interac¸c˜ao activa. Nem toda a informa¸c˜ao ´e relevante para um determinado utilizador. ´E ainda este m´odulo o respons´avel pelo reposit´orio dos dados do utilizador. Estes est˜ao separados em Dados p´ublicos e em Dados privados do utilizador. Os primeiros podem ser livremente relacionados com a informa¸c˜ao do objecto e/ou apresentados directamente no ecr˜a p´ublico. J´a os segundos s˜ao resguardados e mantidos para conhecimento do sistema, podendo ser disponibilizados em cen´arios que envolvam a interac¸c˜ao activa do utilizador atrav´es de dispositivos m´o- veis pessoais. Pode existir um sub-m´odulo adicional de Defini¸c˜oes/Configura¸c˜oes de
Utilizador que em determinadas aplica¸c˜oes pode ser ´util. Assim sendo, configura¸c˜oes, calibra¸c˜oes e defini¸c˜oes de preferˆencias individuais s˜ao armazenadas para posteriormente ser mais simples a configura¸c˜ao autom´atica do sistema para cada utilizador. N˜ao sendo visto como algo essencial para todas as aplica¸c˜oes, pode ser interessante sempre que se quiser adaptar os m´odulos de rastreio e interface ecr˜a aos utilizadores.
• Conte´udos de Objectos: Este servi¸co de dados ´e respons´avel pelo reposit´orio de dados sobre os objectos presentes no cen´ario. O reposit´orio ´e tipicamente extenso e volumoso, incluindo os mais variados conte´udos multim´edia, tais como texto, som, imagem e v´ıdeo. Este m´odulo ´e questionado pelos m´odulos Gestor de Informa¸c˜ao e Interface Ecr˜a. O ´
ultimo exige um maior tr´afego de dados visto ser o respons´avel pela composi¸c˜ao final da apresenta¸c˜ao da informa¸c˜ao ao utilizador. J´a o primeiro faz quest˜oes nas quais pede basicamente texto e imagens para compor mensagens com a informa¸c˜ao sobre o objecto. As respostas a estes pedidos devem ser r´apidas, pois a informa¸c˜ao criada ´e disponibilizada num servidor para ser acedida posteriormente pelo Interface ecr˜a ou por um m´odulo presente num dispositivo m´ovel. Caso seja para o ecr˜a, ent˜ao depois o respectivo sub-m´odulo Composi¸c˜ao de Apresenta¸c˜ao voltar´a a questionar este m´odulo, para obter o maior volume de conte´udos, se for necess´ario para a apresenta¸c˜ao em quest˜ao. J´a o dispositivo m´ovel n˜ao obrigar´a, em geral, a uma segunda consulta deste m´odulo. ´E necess´aria uma camada de gest˜ao - Gestor de Pedidos - para resolver eventuais conflitos e gerir a concorrˆencia em cen´arios que englobem v´arios objectos e muitos utilizadores.
• Gestor de Informa¸c˜ao: A arquitectura do sistema apresenta uma orienta¸c˜ao para o evento, na medida em que cada vez que o utilizador altera o seu estado, i.e., sendo, ou deixando de ser, detectado junto a um objecto/ecr˜a, funciona como um evento para o qual existe um handler, garantindo-se a actualiza¸c˜ao do estado da aplica¸c˜ao. O sistema reage a est´ımulos externos, as interac¸c˜oes dos utilizadores, mantendo-se est´avel quando esses est´ımulos n˜ao ocorrem. Assim sendo, a porta de entrada principal deste m´odulo ´e o Gestor de Eventos, que controla as entradas geradas pelo m´odulo de rastreio. A arquitectura aconselha ainda a utiliza¸c˜ao de uma Fila de Eventos, para garantir que estes n˜ao se perdem e possibilitando, ao mesmo tempo, a programa¸c˜ao de situa¸c˜oes temporais. O n´ucleo deste m´odulo reside nos sub-m´odulos Interpretador Contextual (IC) e Ges- tor de Composi¸c˜ao (GdC). Com a obten¸c˜ao da informa¸c˜ao do m´odulo de rastreio, o Interpretador ´e respons´avel por correlacionar o utilizador detectado, que possui um de-
terminado perfil, com o objecto que o detectou para que posteriormente se obtenha a informa¸c˜ao adicional correspondente. No passo seguinte, envia uma mensagem (docu- mento) para o GdC dando conhecimento sobre a interpreta¸c˜ao realizada. O sub-m´odulo de composi¸c˜ao combina essa informa¸c˜ao com a que recolhe dos servidores de dados (Per- sonaliza¸c˜ao e Conte´udos de Objectos), produzindo um outro documento para o Servidor de Informa¸c˜ao. O documento ´e tamb´em produzido de acordo com a origem da detec¸c˜ao ou do pedido. Caso o GdC tenha recebido a mensagem da parte do Interpretador, ent˜ao o documento produzido deve conter um m´ınimo de informa¸c˜ao, pois ´e direccionado para o m´odulo Interface Ecr˜a, que ent˜ao o utiliza para saber como compor a apresenta¸c˜ao multi- m´edia final. Se o GdC receber um pedido vindo de um dispositivo m´ovel (uma interac¸c˜ao activa), ent˜ao o documento a disponibilizar no servidor deve ser o final, contendo todos os dados questionados ou esperados. Dependendo do cen´ario, o GdC pode ter ainda em conta, por exemplo, as defini¸c˜oes locais, as preferˆencias do utilizador, e a localiza¸c˜ao do objecto. Este m´odulo de composi¸c˜ao ´e o respons´avel por compor, estruturar e seleccionar a informa¸c˜ao que deve ser apresentada.
Se, por um lado, o sub-m´odulo GdC est´a dependente da aplica¸c˜ao, j´a o sub-m´odulo IC ´e completamente independente, apresentando uma arquitectura (modelo) que se adequa a qualquer cen´ario (ver Figura 4.4). O modelo funciona caso se esteja perante um cen´ario composto por v´arios objectos, como por exemplo numa sala de um museu, mas tamb´em nos casos em que se considera apenas um grande objecto conceptual, como por exemplo uma institui¸c˜ao. Permite que possam ser associados v´arios ecr˜as ao objecto, sendo colo- cados em v´arias localiza¸c˜oes da institui¸c˜ao. Um ”ObjectoAumentado” corresponde a um ”Objecto”, a uma ”Localiza¸c˜ao”, e tem associados um ”Leitor” (que pode ser apenas uma antena, dependendo do tipo de tecnologia utilizada) e um ”Ecr˜a”. J´a a ”Informa¸c˜aoAdi- cional” indica que dados de um ”Objecto” devem ser conjugados tendo em considera¸c˜ao um determinado ”Perfil”. O ”TipoInfo” ´e importante para o GdC, pois indica quais os tipos de informa¸c˜ao multim´edia que se encontram presentes na por¸c˜ao de ”Informa¸c˜aoA- dicional”, condicionando a interface visual da apresenta¸c˜ao. Um ”UtilizadorIdentificado” corresponde a um ”Utilizador” com uma determinada ”Etiqueta” (e.g., uma tag de RFID ou um dispositivo m´ovel com Bluetooth) durante um determinado per´ıodo de tempo, que pode ser menor que uma hora ou durar muitos meses. Um ”Utilizador” tem sempre um ”Perfil”, nem que seja o mais gen´erico, caso tenha uma actividade residual no cen´ario de aplica¸c˜ao. Dependendo do tipo de ”Etiqueta” (tipo de tecnologia) utilizada, s˜ao v´arios os
Figura 4.4: Arquitectura do Interpretador Contextual.
servi¸cos que podem ser disponibilizados, podendo ser mais preciosos num contexto que permita a interac¸c˜ao activa por parte do utilizador. Por fim, sempre que um utilizador ´e detectado por um ”ObjectoAumentado”, ´e criada uma nova ”Interac¸c˜ao” que, al´em de disparar um novo evento, regista v´arios dados que ajudam a perceber o tipo de interac¸c˜ao. Assim sendo, este sub-m´odulo ´e tamb´em um servi¸co de dados que cont´em a informa¸c˜ao elementar sobre os objectos, os perfis, os utilizadores, os dispositivos de identifica¸c˜ao e a informa¸c˜ao adicional de modo a poder relacionar todas estas entidades, guardando ainda todas as interac¸c˜oes detectadas entre utilizadores e objectos.
O Servidor de Informa¸c˜ao disponibiliza os documentos finais, criados pelo GdC, tanto para o m´odulo Interface Ecr˜a como para os pedidos vindos dos dispositivos m´oveis, que s˜ao uti- lizados por utilizadores para interac¸c˜oes activas. O mecanismo de Cache ´e implementado para garantir uma maior robustez e uma maior rapidez do sistema. Integra-se um sistema ass´ıncrono de pedidos de informa¸c˜ao ao Gestor de Informa¸c˜ao, para que n˜ao seja necess´ario
parar o processamento enquanto se espera pelo resultado dos pedidos ao Servidor ou ao GdC. Dependendo do cen´ario de aplica¸c˜ao, e dos servi¸cos disponibilizados na interac¸c˜ao activa, um pedido pode ter de passar primeiro pelo GdC, caso se tenha que produzir um novo documento de informa¸c˜ao. O Gestor de Pedidos ´e o respons´avel pela informa¸c˜ao passada ao M´odulo Rastreio, que realiza a comunica¸c˜ao de curto alcance com o dispositivo m´ovel. Por outro lado, um pedido pode ir directamente para o Servidor quando ´e referente a informa¸c˜ao anteriormente gerada, sendo disponibilizada via GPRS.