Este capítulo apresentou uma nova abordagem, intitulada Where, What, Why and How - 3W1H, inspirada por uma outra área da ciência, conhecida como Behaviorismo e embasada em estudos de diversas pesquisas científicas e tecnológicas relacionadas com ambientes interativos internos.
Ao contrário de trabalho Pinhanez[27], que se aprofunda nas ações dos usuários, este capí- tulo introduziu o conceito de associação (interação/reação) através dos Behavior Frames. Este conceito traz características semelhantes ao modelo de regras ECA (Event Control Action) apre- sentadas por Lawson [1]. O estabelecimento de cadeias de comportamento (Behavior Chain), utilizando estas associações (interação/reação) como a unidade básica do comportamento do ambiente, traz uma flexibilidade de adaptação na construção de ambientes interativos para di- ferentes cenários e contextos por possibilitar modificar as associações, sem modificar todas as regras do comportamento definido. Para abordar o comportamento e os diferentes contextos de um ambiente interativo, um Diagrama de Estado, semelhante ao trabalho de Fleer[33], foi proposto. A união de todas essas características, juntamente com a formalização do processo de desenvolvimento de ambientes interativos, são contribuições importantes deste capítulo.
A proposta oferece artefatos de produção rápida e com conceitos retirados das experiências práticas, experimentadas pelo autor e por pesquisas científicas relacionadas com o tema. Nela, é concebido um modelo de processo, com etapas bem definidas, que serve para mitigar erros relacionados à concepção de um cenário e seus artefatos, reconhecimentos de interações, inter- pretação das interações, dentre outros e guiar os projetistas na concepção de espaços interativos internos. Tal processo força o projetista considerar aspectos relevantes relacionados com: a importância do cenário e suas instalações físicas; a compreensão do contexto para o correto funcionamento do ambiente; e, por fim, a redução do esforço cognitivo para a interação/reação utilizada no ambiente.
A viabilidade de utilização da abordagem 3W1H será avaliada através de experimentos e es- tudos de caso descritos na Seção 5.5 do Capítulo 5 [120]. Além disso, todo o processo proposto na abordagem será validado através da construção de um estudo de caso real para controlar uma TV por meio de gestos (subsecção 5.1 do Capítulo 5). Embora o exemplo utilizado para vali- dar toda a proposta se restrinja a uma sala inteligente para controlar uma TV, a utilização desta abordagem pode ser eficiente em outros contextos. O trabalho de Saleme et al. [2], por exemplo, coloca em prática toda a abordagem proposta com o objetivo de integrar efeitos multisensoriais em ambientes interativos. Esse e outros estudos de casos, utilizando a abordagem proposta, bem como a validação da abordagem, serão discutidos no capítulo 5. O Capítulo 4 disponibiliza a implementação dos conceitos desta abordagem, fornecendo uma camada de abstração para as fases de desenvolvimento de 4 a 7.
4
Este capítulo apresenta um framework intitulado Touch The Air - TTAir, que oferece como contribuição uma especificação e implementação de um conjunto de métodos e funções, embasados nas fases de desenvolvimento de 4 a 7, para facilitar e padronizar o desenvolvimento de aplicações interativas.TOUCH THE AIR FRAMEWORK
Um framework pode ser definido como uma especificação ou implementação (por exemplo, uma coleção de classes) que fornece uma solução geral para algum domínio de aplicação [121]. Desta maneira, o detalhamento do domínio de aplicação relacionado com ambientes interati- vos, feito no Capítulo 2, permitiu identificar as atividades mais comuns da área. O Capítulo 3 mostrou uma maneira estruturada, dividida em sete etapas (Figura 3.1), de se conceber novos ambientes interativos, mantendo o foco no reuso e no reaproveitamento de trabalhos já concebi- dos. Diante do que foi apresentado nos capítulos anteriores, foi possível projetar um framework que fornece uma solução estruturada para uma família de problemas semelhantes, através de um conjunto de classes flexível e extensível o suficiente para permitir a construção de aplicações distintas com pouco esforço, especificando apenas as particularidades de cada aplicação.
Este capítulo apresenta um framework intitulado Touch The Air - TTAir, que oferece como contribuição uma especificação e implementação de um conjunto de métodos e funções para facilitar e padronizar o desenvolvimento de aplicações interativas. Embora o TTAir não se li- mite a algum tipo de sensor específico, a maioria dos testes e exemplos utilizados no decorrer do capítulo foi baseada nos sensores (RGB, DEPTH e IR) encontrados no Kinect da Micro- soft1e no Carmine da Primesense2, por serem dispositivos tipicamente de baixo custo, quando comparados aos equipamentos que os antecederam, com funcionalidades similares.
As soluções dos problemas disponibilizados pelo TTAir estão fundamentados nas fases de desenvolvimento de 4 a 7, descritas no Capítulo 2 (Seção 3.2), por serem atividades diretamente relacionadas com a parte de implementação/construção da aplicação interativa. As fases 1, 2 e 3 estão mais relacionadas com a interpretação e contextualização do cenário, das interações e das ações a serem utilizadas no ambiente. Embora as três primeiras fases não estejam diretamente
1http://www.microsoft.com/en-us/kinectforwindows/ 2http://www.primesense.com
relacionadas com implementação do ambiente, elas são partes fundamentais para nortear cada uma das fases seguintes. A seguir, serão elencados esses problemas e a maneira como eles foram tratados pelo framework TTAir:
• Implementar as ações/reações para os objetos ativos: o ambiente disponibiliza maneiras de reaproveitar as reações que já foram implementadas e métodos que facilitem novas implementações. Ou seja, não é necessário implementar uma reação para ligar a lâm- pada, para ser utilizada em outro ambiente interativo ou outro contexto. Somente será necessário implementar reações que não estejam presentes no barramento. O TTAir já disponibiliza um conjunto de reações implementadas para serem utilizadas pelos desen- volvedores. Requisito baseado na quarta fase de desenvolvimento "Implementação do Ambiente Interativo"
• Implementar reconhecedores (recognizers): disponibiliza maneiras de facilitar a forma de processar informações obtidas dos sensores, através de um conjunto de métodos comu- mente utilizados na comunidade científica. Ou seja, o usuário não precisaria saber como reconhecer uma pose, por exemplo. Simplesmente, utilizaria um reconhecedor desta pose que já estaria disponível a partir do framework. Requisito baseado na quarta fase de de- senvolvimento ”Implementação do Ambiente Interativo”
• Associação de eventos capturados às reações: o ambiente disponibiliza um módulo de abstração de tecnologias utilizadas para estes fins. Para que a associação exista, é neces- sário receber um arquivo XML seguindo os conceitos do Behavior Frame. Este arquivo é responsável por indicar ao TTAir, o que será disparado caso um determinado evento ocorra. Requisito baseado nos conceitos relatados na quinta fase de desenvolvimento. • Determinar o comportamento do sistema: da mesma maneira que os Behavior Frames, o
TTAir permite que o comportamento do ambiente interativo, com seus níveis de expec- tativa e associações, seja configurado através de um arquivo XML seguindo os conceitos do Behavior Chain. Requisito baseado na sexta fase de desenvolvimento
• Monitoramento dos eventos ocorridos durante a execução do software: o TTAir permite o armazenamento de informações de diferentes sensores de maneira estruturada, criando um banco de dados de informações importantes para futuros processamentos e inferên- cias. Este requisito é baseado na sétima fase de desenvolvimento ”Monitoramento da Expectativa”.
Além dessas características globais, algumas características específicas foram acrescentadas no TTAir, dentre elas podemos citar a possibilidade de:
• Dar suporte aos desenvolvedores para que elaborem suas próprias interfaces baseadas em gestos, seguindo a arquitetura de programação estruturada pelo framework. Desta
maneira, as aplicações interativas desenvolvidas a partir do ambiente poderiam gozar de uma maior flexibilidade, reutilização e interoperabilidade.
• Mapeamento/Armazenamento das informações multimodais: o framework TTAir dispo- nibiliza um outro módulo (que abstrai onde estão localizadas as informações) para ar- mazenar as mídias capturadas. Estas informações podem estar localizadas em quaisquer bases de dados, sejam elas relacional, orientada a objetos ou em arquivos XML.
• Sincronização das informações dos sensores com os tempos (timestamps) de captura: o framework disponibiliza um módulo de apresentação que abstrai a exibição da mídia sincronizada com o momento que esta foi capturada. Isso permite que informações de diversas modalidades, como voz, imagem RGB e imagem de profundidade, widgets, efei- tos visuais ou até ações a serem executadas, sejam apresentadas de maneira sincronizada com o tempo.
• Navegação entre as camadas de apresentação: o framework, através do módulo de apre- sentação, disponibiliza diversas camadas a serem exibidas. Cada uma destas camadas representa as informações obtidas de algum sensor ou criada pelo próprio desenvolve- dor. Ou seja, se tivermos três camadas que representem informações de imagem RGB, imagem de profundidade e informações de um usuário em cena, é possível disponibilizar ao usuário um controle de navegabilidade nessas camadas. O framework disponibiliza um mecanismo de navegação interativa que permite ao usuário navegar entre as cama- das, passando para a primeira, anterior, próxima ou última camada, decidindo ele quanto tempo esta deverá permanecer visível e possibilitando a exibição de seu conteúdo. • Facilitar a forma de apresentação das informações, criando modelos e escondendo toda
a complexidade de apresentações na tela. Em outras palavras, o usuário não precisa conhecer ou criar maneiras de apresentar as informações de suas aplicações. Bastaria ele utilizar os modelos preexistentes ou estender as funcionalidades dos modelos atualmente disponíveis.
Em suma, conforme será mostrado na próxima seção, o TTAir torna possível o desenvol- vimento de aplicações em ambientes interativos, sem que seja necessário se preocupar com os problemas típicos deste domínio (associação, armazenamento, processamento, sincronização e exibição). Além disso, o TTAir torna simples a adição de novas funcionalidades e, com sua arquitetura modular (apresentada nas próximas seções), possibilita a reutilização de código e a interoperabilidade entre aplicações desenvolvidas a partir deste framework.
O TTAir foi desenvolvido em Java, utilizou como base o padrão aberto de interação natural - OpenNI e é aderente a toda arquitetura modular por ele proposta. Toda a configuração é lida, constantemente a partir da entrada das informações do comportamento do ambiente estruturadas de arquivos XML.
4.1 A ARQUITETURA TTAIR
A Figura 4.1 ilustra uma visão geral da arquitetura projetada para sustentar as diversas ne- cessidades de desenvolvedores, já identificadas e citadas anteriormente, no framework TTAir. A arquitetura modular com baixo acoplamento permite que sejam utilizados os módulos de maneira isolada ou em conjunto com outros módulos, a depender das necessidades do desen- volvedor.
A arquitetura do TTAir (Figura 4.1) mostra que o acesso aos dados é feito através da ca- mada DataAcces. Esta camada entrega as informações não processadas para as camadas se- guintes, Presentation e Process. A camada Presentation, estrutura as informações recebidas para exibição em tela. Já a camada Process possui uma abstração de processo de reconheci- mento, chamada de Recognize Process. Esta abstração pode receber os dados da camada de apresentação, de uma base de informações e, em conjunto com um modelo de comparação a ser utilizado (MatchModel), disparar um evento de reconhecimento através do barramento de eventos (EventBus). Na camada de Action, estão todas as ações implementadas, categorizadas por tipo do ambiente onde serão executadas (mundo real ou virtual). Tais ações, são associadas a um ou mais eventos de reconhecimento através Listener Bus. É o Listener Bus, barramento de escutadores de eventos, que comunica quando e quais ações deverão ser executadas. Por fim, a camada de comportamento que traduz todas as regras de execução (as associações dos eventos de reconhecimento com as ações, os estados possíveis do ambiente e suas transições) de um arquivo no padrão XML, para o efetivo comportamento do ambiente. É esta camada que permite que o ambiente se comporte conforme as regras definidas no arquivo XML.
Aqui estamos chamando de módulos a efetiva implementação de cada camada da arquite- tura. As seções seguintes detalharão cada um dos módulos que compõem o TTAir (DataAccess, Presentation, Proccess, Action e Behavior), além de alguns exemplos de sua utilização.