LEANDRO LOURENZONI GUIX - FERRAMENTA COMPUTACIONAL PARA ANÁLISE, DESCRIÇÃO E GERAÇÃO DE INTERFACES GRÁFICAS PARA APLICAÇÕES REMOTAS

Transcrição

1 LEANDRO LOURENZONI GUIX - FERRAMENTA COMPUTACIONAL PARA ANÁLISE, DESCRIÇÃO E GERAÇÃO DE INTERFACES GRÁFICAS PARA APLICAÇÕES REMOTAS São Paulo 2007

2 LEANDRO LOURENZONI GUIX - FERRAMENTA COMPUTACIONAL PARA ANÁLISE, DESCRIÇÃO E GERAÇÃO DE INTERFACES GRÁFICAS PARA APLICAÇÕES REMOTAS Trabalho de formatura apresentado à disciplina PCS2502 Projeto de Formatura II, da Escola Politécnica da Universidade de São Paulo São Paulo 2007

3 LEANDRO LOURENZONI GUIX - FERRAMENTA COMPUTACIONAL PARA ANÁLISE, DESCRIÇÃO E GERAÇÃO DE INTERFACES GRÁFICAS PARA APLICAÇÕES REMOTAS Trabalho de formatura apresentado à disciplina PCS2502 Projeto de Formatura II, da Escola Politécnica da Universidade de São Paulo Área de concentração: Engenharia da Computação Orientadora: Profa. Dra. Lucia Vilela Leite Filgueiras São Paulo 2007

4 FICHA CATALOGRÁFICA Lourenzoni, Leandro GUIX ferramenta computacional para análise, descrição e geração de interfaces gráficas para aplicações remotas / L. Lourenzoni. -- São Paulo, p. Trabalho de Formatura - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Computação e Sistemas Digitais. 1.Engenharia de computação 2.Interface gráfica 3.Computacão gráfica 4.Computação móvel 5.Usabilidade de software 6.XML I.Universidade de São Paulo. Escola Politécnica. Departamento de Engenharia de Computação e Sistemas Digitais II.t.

5 DEDICATÓRIA Dedico este trabalho aos meus pais, aos professores e amigos, por terem acreditado na minha capacidade e por me apoiarem ao longo das dificuldades.

6 AGRADECIMENTOS À Luizemara Soares Alves, pela paciência, compreensão e apoio nos momentos mais difíceis durante a execução deste trabalho. Aos amigos Daniel Christovam e Silva, Enzo Lorenzon Tosi, Leonardo Cipriani, Marco Antonio da Silva e Ricardo Scherrer, pelo companheirismo, pelo incentivo e pelas contribuições para a realização deste trabalho. Aos professores doutores Andrea Sanna e Fabrizio Lamberti, pelas diretrizes seguras e pelo permanente incentivo na realização da tese que deu origem a este trabalho. À professora Lucia Vilela Leite Filgueiras, pela pronta aceitação do projeto e pela orientação na continuação do mesmo.

7 A simplicidade é o último grau de sofisticação. (Leonardo da Vinci)

8 RESUMO No presente trabalho foi desenvolvido um sistema computacional capaz de realizar a análise, a descrição e a geração de interfaces gráficas, possibilitando o controle remoto de aplicativos através da utilização de dispositivos móveis (Pocket PC e smartphone). A análise das interfaces, realizada por meio de algoritmos da computação gráfica, resulta na produção de descrições estruturadas das mesmas, codificadas em XUL linguagem de descrição de interfaces baseada em XML, desenvolvida no âmbito do projeto Mozilla. As descrições produzidas são utilizadas para a reconstrução das interfaces nos dispositivos móveis, permitindo a interação do usuário com os aplicativos remotos. A comunicação entre o dispositivo móvel e a máquina remota é realizada através da Internet, por meio de um protocolo de comunicação desenvolvido para possibilitar o envio de comandos ao aplicativo controlado e a atualização da interface no dispositivo móvel. Durante a utilização do sistema, o usuário pode modificar dinamicamente a configuração da interface, de acordo com suas preferências. O sistema desenvolvido foi denominado GUIX (Graphical User Interface extensible). Palavras-chave: Interface Gráfica. Computação Gráfica. Computação Móvel. Usabilidade de Software. XML.

9 ABSTRACT This work presents an automatic tool designed to perform graphical user interface analysis, description and generation, enabling remote control of computer applications through the use of mobile devices (Pocket PC and smartphone). The user interface analysis held through computer graphics algorithms results in the production of structured descriptions in XUL user interface description language based on XML developed within the Mozilla project. These descriptions are used in the reconstruction of the user interfaces on mobile devices, allowing the user to interact with the remote applications. The communication between the mobile device and the remote machine is performed over the Internet through a communication protocol. This protocol was developed to allow the transmission of commands to the controlled application and to permit the update of the user interface on the mobile device. During the use of the system, the user can dynamically change the configuration of the new interface according to his preferences/necessities. The system developed was called GUIX (Graphical User Interface extensible). Keywords: Graphical User Interface. Computer Graphics. Mobile computing. Software Usability. XML.

10 LISTA DE ILUSTRAÇÕES Figura 1 - Esquema simplificado do sistema, (a) Criação da nova interface, (b) Controle da aplicação remota através da nova interface Figura 2 - Aplicação de desenho técnico com interface inovadora Figura 3 - ZenZui: navegador web inovador para dispositivos móveis Figura 4 - iphone Figura 6 - Visualização de desktop remoto com VNC, (a) desktop Unix visualizado através de cliente Windows, (b) desktop Windows visualizado com cliente X Windows Figura 7 - Cliente VNC em um dispositivo móvel Figura 8 - Login do desktop remoto do Windows Figura 9 - Desktop remoto visualizado no cliente Figura 10 - Remote Desktop Protocol em diversos dispositivos Figura 11 - Remote Desktop client no Internet Explorer Figura 12 - Apple Remote Desktop Figura 13 - Desktop virtual Goowy Figura 14 - Exemplo de documento XML Figura 15 - Dispositivos móveis utilizados: Pocket PC e smartphone Figura 17 - Varredura da interface através de deslocamentos do cursor do mouse Figura 18 - Mapa para evitar que o cursor pare mais de uma vez sobre o mesmo elemento Figura 19 - Representação gráfica de um slider Figura 20 - Representação gráfica do algoritmo da divisão da imagem em blocos Figura 21 Exemplo de forma reconhecida pelo algoritmo Figura 22 - Análise do contorno de figuras baseado no comprimento das scanlines Figura 23 - Representação gráfica do algoritmo para o reconhecimento de formas... 52

11 Figura 24 - Classificação dos elementos da interface do Windows Explorer Figura 25 - Remoção do texto dos elementos durante a classificação Figura 26 - Classificação dos elementos da interface do Blender Figura 27 - Resultado da análise e classificação da interface do Windows Explorer Figura 28 - Descrição da interface do Windows Explorer gerada automaticamente Figura 29 - Descrição da interface reconstruída no navegador web Figura 30 - Arquitetura geral do sistema Figura 31 - Arquitetura do servidor Figura 32 - Seleção dos elementos da interface Figura 33 - Classificação dos elementos de interface Figura 34 - Exemplo de descrição de interface Figura 35 - Servidor pronto para o recebimento de comandos Figura 36 - Funcionamento do servidor Figura 37 - Arquitetura do cliente Figura 38 - Estrutura em árvore resultante da leitura de uma descrição Figura 39 - Visualização dos elementos excluídos na interface reconstruída Figura 40 - Interface reconstruída em um Pocket PC Figura 41 - Aplicação cliente em execução no pocket PC Figura 42 - Comparação entre displays com resoluções diferentes Figura 43 - Eliminação automática do texto das seleções dos botões Figura 44 - Ganho de espaço no programa cliente Figura 45 - Zoom do elemento workarea Figura 46 - Pan do elemento workarea Figura 47 - Diagrama de classes do servidor Figura 48 - Diagramas de classes do cliente Figura 49 - Ícone do servidor Figura 50 - Tela inicial do servidor Figura 51 - Caixa de diálogo da opção New from running Figura 52 - Janela principal do servidor após a captura de tela do aplicativo alvo Figura 53 - Adicionar seleção da workarea... 96

12 Figura 54 - Seleção da workarea Figura 55 - Varredura da interface Figura 56 - Resultado da análise Figura 57 - Classificação dos elementos Figura 58 - Resultado da classificação Figura 59 - Descoberta dos itens dos menus Figura 60 - Resultado da varredura dos menus Figura 61 - Reconhecimento de caracteres Figura 62 - Propriedades da seleção exibindo o texto reconhecido Figura 63 - Geração da descrição em XML Figura 64 - Visualização do resultado no navegador web Figura 65 - Configuração dos parâmetros de varredura da interface Figura 66 - Configuração dos parâmetros de classificação Figura 67 - Configuração dos parâmetros de conexão Figura 68 - Janela principal do cliente Figura 69 - Visualização dos elementos removidos Figura 70 - Opção do menu de contexto global para ativar o servidor Figura 71 - Ícone do GUIX na área de notificação do Windows Figura 72 - Tela de conexão no cliente Figura 73 - Resultado da análise da interface do Blender Figura 74 - Resultado da análise dos menus do Windows Explorer Figura 75 - Resultado da análise dos menus do Blender Figura 76 - Resultado da classificação dos elementos do Blender

13 LISTA DE TABELAS Tabela 1 Vantagens e desvantagens da linguagem XUL Tabela 2 - Correspondência entre cor e tipo de elemento Tabela 3 - Resumo das funções dos componentes do servidor Tabela 4 - Principais mensagens da comunicação entre cliente e servidor Tabela 5 - Parâmetros de varredura Tabela 6 - Parâmetros da varredura parcial e da varredura completa Tabela 7 - Parâmetros da varredura dos itens de menu e combo box Tabela 8 - Parâmetros de classificação

14 LISTA DE ABREVIATURAS E SIGLAS DOM DTD GUI ITU-T OCR PC RDP UIDL URI URL VNC W3C XML XUL Document Object Model Document Type Definition Graphical User Interface International Telecommunication Union - Telecommunication Standardization Bureau Optical Character Recognition Personal Computer Remote Desktop Protocol User Interface Description Language Uniform Resource Identifier Uniform Resource Locator Virtual Network Computing Wide Web Consortium extensible Markup Language extensible User Interface Language

15 SUMÁRIO 1 INTRODUÇÃO OBJETIVO JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA TECNOLOGIAS ALTERNATIVAS VIRTUAL NETWORK COMPUTING DESKTOP REMOTO DESKTOP VIRTUAL MATERIAIS E MÉTODOS FERRAMENTAS DE DESENVOLVIMENTO LINGUAGENS DE DESCRIÇÃO DE INTERFACES XML XML documents XML namespace XML validation XUL OUTRAS LINGUAGENS DE DESCRIÇÃO UIML AUIML XIML Seescoa XML ESCOLHA DA LINGUAGEM UIDL DISPOSITIVOS MÓVEIS ANÁLISE DE INTERFACES LOCALIZAÇÃO DOS ELEMENTOS DE INTERFACE VARREDURA DA INTERFACE CLASSIFICAÇÃO DOS ELEMENTOS DE INTERFACE Divisão da imagem em blocos Reconhecimento de formas Regras de classificação... 52

16 4.4 EXEMPLOS DE CLASSIFICAÇÃO DESCRIÇÃO DE INTERFACES DESCRIÇÃO DA INTERFACE EM XUL Window Server Workarea Button Menu Combobox EXEMPLOS DE DESCRIÇÃO CARREGANDO A DESCRIÇÃO NO NAVEGADOR WEB ARQUITETURA DO SISTEMA ARQUITETURA DO SERVIDOR Analisador gráfico Classificador de elementos Gerador de descrições Tradutor de comandos FUNCIONAMENTO DO SERVIDOR ARQUITETURA DO CLIENTE Reconstrução da interface Modificações na interface reconstruída A nova interface PROTOCOLO DE COMUNICAÇÃO CLIENTE PARA DISPOSITIVOS MÓVEIS CLIENTE PARA SMARTPHONE MELHORIAS NO SERVIDOR MELHORIAS NO CLIENTE Recurso de zoom Recurso de pan DIAGRAMAS DE CLASSES DO SISTEMA CLASSES DO SERVIDOR CLASSES DO CLIENTE UTILIZAÇÃO DO SISTEMA... 93

17 9.1 UTILIZAÇÃO DO SERVIDOR Salvando o projeto Configurações personalizadas Configuração da varredura da interface Configuração da classificação dos elementos Configuração da conexão com o aplicativo cliente UTILIZAÇÃO DO CLIENTE CONEXÃO E CONTROLE REMOTO RESULTADOS ANÁLISE DAS INTERFACES CLASSIFICAÇÃO DOS ELEMENTOS DE INTERFACE GERAÇÃO DAS DESCRIÇÕES RECONSTRUÇÃO DAS INTERFACES CONTROLE DE APLICATIVOS REMOTOS UTILIZAÇÃO DO CLIENTE NO SMARTPHONE CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS...120

18 17 1 INTRODUÇÃO O presente trabalho é uma continuação do trabalho realizado na Itália [1] para a conclusão do curso referente ao acordo de duplo diploma entre a Escola Politécnica da USP e o Politecnico di Torino. Nesse trabalho foi iniciado o desenvolvimento de um sistema capaz de produzir descrições estruturadas de interfaces gráficas, utilizando algoritmos da área de computação gráfica. Esse sistema, denominado GUIX Graphical User Interface extensible compreende a análise de interfaces, a geração de descrições XML, a reconstrução das interfaces em dispositivos móveis (Pocket PC e smartphone) e o controle remoto de aplicativos através das interfaces reconstruídas. A figura 1 ilustra o funcionamento simplificado do GUIX. GUI do programa alvo Análise da interface Descrição da interface Reconstrução da interface Nova interface (a) Nova interface Tradução de comandos Aplicativo alvo (b) Figura 1 - Esquema simplificado do sistema, (a) Criação da nova interface, (b) Controle da aplicação remota através da nova interface GUIX possibilita a criação de novas interfaces homem-computador para aplicativos existentes. Entre as possibilidades oferecidas pelo GUIX estão: controle remoto de aplicativos, reconstrução das interfaces de acordo com as necessidades específicas e integração com projetos de visualização remota. Como primeira aplicação para o sistema, foi escolhido o controle remoto de aplicativos através da reconstrução de interfaces em um Pocket PC. Na continuação do projeto na Escola Politécnica, foram realizadas melhorias no sistema para permitir o funcionamento em smartphones com sistema Windows Mobile. As limitações dos dispositivos móveis utilizados evidenciam a necessidade de realizar alterações nas interfaces dos

19 18 aplicativos, de forma a proporcionar uma interação satisfatória com o usuário. Desse modo, GUIX se apresenta como uma alternativa viável na utilização de dispositivos móveis para o controle remoto de aplicativos. 1.1 OBJETIVO O objetivo do presente trabalho de formatura é o projeto e desenvolvimento de uma ferramenta computacional capaz de analisar a interface gráfica de um aplicativo, através de algoritmos da computação gráfica, e produzir uma descrição estruturada da mesma em uma linguagem de descrição de interfaces baseada em XML. Além disso, como aplicação para o sistema, pretende-se possibilitar a reconstrução das interfaces em dispositivos móveis (Pocket PC e smartphone) a partir das descrições produzidas, de forma a permitir o controle remoto de aplicativos. 1.2 JUSTIFICATIVA Desde a invenção do computador pessoal sempre houve um grande esforço no sentido da criação de interfaces homem-máquina mais intuitivas e fáceis de usar. O objetivo sempre foi o de encurtar a distância entre o mundo dos seres humanos e o mundo da máquina. Na tentativa de aproximar os dois mundos foram empregadas diversas técnicas ao longo do tempo. A introdução das interfaces gráficas GUI (Graphical User Interface) tornou possível a construção de interfaces através da utilização de elementos parecidos com objetos reais, tais como desktop, lixeira, pastas e arquivos. A utilização dessas metáforas do mundo real tem a intenção de facilitar o primeiro contato com o usuário, na tentativa de fazer com que o mesmo aprenda a utilizar a interface mais rapidamente. Outro conceito muito estudado é o dos instrumentos locais [2]. Ao contrário das barras de ferramenta, onde pode existir somente um elemento ativo por vez, instrumentos locais podem ser movidos para qualquer parte da área de trabalho de um aplicativo, mantendo seus atributos. Em [3] é descrita uma aplicação de desenho técnico cuja interface se baseia em conceitos inovadores, como os mencionados

20 19 anteriormente. A interface da aplicação citada apresenta uma proposta que se contrapõe ao modelo WIMP (window, icons, menus and pointing). Nesta interface, os instrumentos de desenho são transportados ao mundo virtual, como ilustra a figura 2. Espera-se que uma pessoa familiarizada com esses instrumentos consiga utilizar o programa sem a necessidade de treinamento específico. Figura 2 - Aplicação de desenho técnico com interface inovadora Por outro lado, o crescimento da complexidade dos aplicativos tem aumentado significativamente o número de elementos de interação presentes nas interfaces. Desta forma, torna-se cada vez mais difícil para o usuário encontrar a função que deseja em meio à infinidade de opções disponíveis. Apesar da existência de várias propostas para melhorar a interação com o usuário, são poucos os aplicativos que adotam soluções diversas das usuais, provavelmente por causa dos riscos envolvidos na criação de uma interface inovadora. No projeto de uma interface deve-se levar em consideração a experiência passada do usuário e o custo de aprendizagem de novos conceitos. Se o usuário não estiver disposto a aprender o mínimo necessário para usar a nova interface, não conseguirá utilizá-la e escolherá um aplicativo com funções semelhantes, dotado de uma interface que lhe seja familiar. Diante do exposto, justifica-se a criação de uma ferramenta computacional capaz de gerar uma descrição estruturada da interface de um aplicativo para possibilitar sua

21 20 reconstrução de diversas formas, independentemente da configuração original da mesma. A reconstrução da interface permite a utilização de novos conceitos, permite também adaptar a interface às necessidades do usuário e às limitações do dispositivo, podendo ainda mudar o estilo da interface, por exemplo, de desktop like a página web. Através dessa ferramenta seria possível modificar dinamicamente a interface reconstruída, de forma a possibilitar a sua utilização em dispositivos móveis, como Pocket PC ou smartphone. 1.3 ESTRUTURA DA MONOGRAFIA Na seção 2 serão descritas as principais tecnologias alternativas ao GUIX, como o VNC, o Desktop Remoto e os desktops virtuais. A descrição dessas tecnologias levará em consideração os pontos não abordados pelas mesmas, justificando a criação de uma nova tecnologia. Na seção 3 serão apresentados os materiais e os métodos utilizados no projeto do GUIX, a escolha das ferramentas de desenvolvimento e da linguagem para a descrição das interfaces. Nessa seção será feita ainda uma breve introdução ao XML e às linguagens UIDL (User Interfase Description Language). Na seção 4 será descrita a análise das interfaces e os problemas encontrados para o desenvolvimento dos algoritmos necessários. Será detalhada a varredura das interfaces e a classificação dos elementos encontrados. Na seção 5 será apresentada a descrição das interfaces com a conseqüente geração automática de código na linguagem de descrição de interfaces escolhida. Será explicado como a linguagem escolhida é utilizada para a descrição dos elementos e objetos de interesse. Ainda nessa seção, será apresentado um exemplo completo onde o código produzido automaticamente é carregado em navegador web para a reconstrução automática da descrição. Na seção 6 será descrita a arquitetura geral do sistema desenvolvido e a arquitetura dos módulos que o compõe. A escolha dessa arquitetura permitiu a realização da primeira aplicação do sistema: controle remoto de aplicativos através de interfaces

22 21 reconstruídas em dispositivos móveis a partir das descrições produzidas. Nessa seção será apresentado também o funcionamento dos diversos módulos do sistema. Na seção 7 será apresentado o aplicativo cliente desenvolvido para funcionamento em dispositivos móveis como parte da aplicação de controle remoto de aplicativos. Serão descritas também as melhorias realizadas no Brasil para permitir o funcionamento em um smartphone. Na seção 8 serão descritas as principais classes do sistema e apresentados os diagramas de classes correspondentes. Na seção 9 será apresentado um manual passo a passo de utilização do sistema para o controle remoto de um aplicativo através da interface reconstruída em um Pocket PC ou smartphone. Por fim, nas seções 10 e 11 serão apresentados, respectivamente, os principais resultados e as conclusões do projeto.

23 22 2 TECNOLOGIAS ALTERNATIVAS Diversas são as tentativas de lançar no mercado produtos que tornem a utilização de dispositivos móveis mais simples e prática, ao mesmo tempo oferecendo aplicações mais completas. Tratam-se normalmente de dispositivos ou aplicativos dotados de interfaces inovadoras. A Microsoft anunciou no início do ano, através da parceria com uma empresa independente chamada ZenZui, Inc. [4], uma nova tecnologia que segundo os fabricantes promete revolucionar o modo como é realizada a navegação das páginas web através de dispositivos móveis. Tal tecnologia apresenta uma interface em formato de grade na qual cada célula corresponde a um conteúdo diferente. Na figura 3 é mostrado o aspecto geral dessa interface. As células são selecionáveis e oferecem o recurso de zoom, com auxílio da tela sensível ao toque, ou mesmo através do teclado numérico do próprio dispositivo. A mesma coisa vale para a rolagem da grade e das páginas visualizadas. Essa proposta apresenta, porém, a desvantagem de impor um modo totalmente diferente daquele com o qual o usuário já está acostumado. Figura 3 - ZenZui: navegador web inovador para dispositivos móveis A Apple, por outro lado, criou o iphone (figura 4) [5], um dispositivo híbrido que corresponde à união de vários objetos normalmente distintos, como reprodutor multimídia, telefone celular com conectividade wireless e Bluetooth, câmera digital e

24 23 palmtop. As funções do dispositivo são acessíveis mediante um inovador sistema de touchscreen denominado multi-touch, que ocupa todo o lado frontal do aparelho e não requer a utilização de dispositivos de apontamento, pois é operável diretamente com as pontas dos dedos, gerenciando contatos múltiplos. Essa característica possibilita a combinação de gestos para interagir com as interfaces dos aplicativos. A combinação de gesto pode ser utilizada, por exemplo, para acionar o efeito de zoom de fotos ou páginas web simplesmente apoiando dois dedos na tela e afastando-os (zoom in), ou aproximando-os (zoom out). Outra característica da interface relacionada ao touchscreen é a possibilidade de rolar rapidamente o conteúdo arrastando o dedo na tela o que simula o efeito de inércia, ou seja, a operação continua por certo tempo depois de finalizado o gesto, dependendo da intensidade com que este é realizado. Para as aplicações que necessitam da entrada de texto, a plataforma disponibiliza um teclado virtual do tipo QWERTY que também é operado através do touchscreen. Figura 4 - iphone Apesar de apresentar mecanismos inovadores de interação, um dos pontos fracos desse sistema é a necessidade de desenvolvimento de aplicações específicas para se aproveitar os novos recursos de interface. Num caso como esse seria interessante a utilização de uma ferramenta como o GUIX para criar uma nova interface para um aplicativo conforme as características dos mecanismos de entrada do dispositivo.

25 24 Além das características das interfaces homem-computador, o projeto prevê também o controle remoto de aplicativos. Existem atualmente várias tecnologias que permitem controlar um computador à distância, mas todas elas apresentam a característica de reproduzir toda a área de trabalho, ou uma dada região da tela, no lado cliente, não tratando cada aplicação individualmente. Exemplos dessas tecnologias são o VNC e o Desktop Remoto. Os desktops virtuais, por outro lado, são computadores virtuais acessados através da Internet, que oferecem aplicações simples como , agenda, calendário, etc. 2.1 VIRTUAL NETWORK COMPUTING O termo virtual network computing (VNC) [6] se refere à tecnologia que possibilita o controle remoto de um computador mediante um protocolo de acesso aos recursos gráficos (display protocol), em modo independente da plataforma. Como mostra o esquema ilustrado na figura 5, essa tecnologia é composta por cliente, servidor e protocolo de comunicação. Figura 5 - Componentes do VNC O cliente é denominado viewer, pois sua função principal é a visualização da interface do computador remoto. Um aplicativo cliente VNC deve ser projetado para que possa ser executado mesmo em dispositivos de baixa capacidade de processamento (thin client), funcionando também dentro de navegadores web. Os esquemas de codificação suportados dependem das limitações de cada dispositivo.

26 25 A funcionalidade mínima que um cliente deve apresentar é a possibilidade de desenhar retângulo de uma única cor na tela, de forma que o servidor possa decompor a representação gráfica do desktop do computador remoto em regiões homogêneas e enviar ao cliente somente as informações correspondentes, tais como: localização, tamanho e cor de preenchimento, exigindo uma banda de transmissão muito menor do que a que seria necessária para enviar as informações de todos os pixels da tela. O servidor é muito mais complexo que o cliente, pois deve gerenciar os diversos tipos de codificação suportados e realizar a interação com o sistema operacional do computador remoto. Para a codificação do conteúdo extraído da memória de vídeo pode ser utilizado JPEG ou mesmo MPEG, no caso de envio das imagens como streaming de vídeo. A visualização remota do desktop de um computador é realizada através do acesso do servidor à memória de vídeo (frame buffer). O servidor monitora as alterações no frame buffer e mantém atualizada a interface exibida no cliente. Porém, as informações referentes às variações na representação gráfica do desktop são enviadas somente sob requisição do cliente, o que torna viável o funcionamento do sistema mesmo com dispositivos lentos e redes de baixa velocidade. A interação entre o servidor e a máquina remota através do acesso ao frame buffer torna o protocolo independente da plataforma. Entre as idéias iniciais do projeto do VNC pretendia-se expandir o protocolo para o controle de vários dispositivos, como reprodutores de vídeo e fornos microondas, evitando que fosse necessário escrever programas específicos para acessar as funções de cada aparelho. Através do VNC seria possível extrair as informações necessárias da própria interface homemmáquina fornecida pelo dispositivo. A independência da plataforma possibilita, por exemplo, o controle de um computador com sistema operacional Windows através de outro com sistema operacional Unix e vice-versa, como mostra a figura 6.

27 26 Figura 6 - Visualização de desktop remoto com VNC, (a) desktop Unix visualizado através de cliente Windows, (b) desktop Windows visualizado com cliente X Windows Existem atualmente diversos produtos que utilizam a tecnologia do VNC. Entre os mais famosos estão o RealVNC e o UltraVNC. O primeiro é um produto desenvolvido pelos próprios criadores da tecnologia. No site da empresa está disponível uma versão gratuita muito simples e que funciona somente em ambiente Windows. As versões mais completas e para outras plataformas devem ser adquiridas através do pagamento da licença de utilização. Por outro lado, o UltraVNC è um aplicativo open source disponibilizado sob os termos da GNU general public license [7] apresentando também a desvantagem de funcionar somente em ambiente Windows. Foram desenvolvidas aplicações baseadas em VNC para dispositivos móveis. No início existiam somente versões do cliente (figura 7), que possibilitavam o controle de um computador remoto através de um dispositivo móvel. A melhoria do desempenho dos dispositivos e o aumento da resolução dos displays permitiram o

28 27 desenvolvimento de servidores para dispositivos móveis, possibilitando o controle remoto desses dispositivos através de clientes para PC. Uma vez que o VNC prevê o envio da representação inteira da área de trabalho, a utilização de dispositivos móveis como cliente só é possível através da utilização de barras de rolagem laterais (figura 7). Além disso, ao tentar reduzir a imagem do desktop, perde-se qualidade não só das regiões destinadas à visualização, mas de toda interface, pois não há um meio de separar os elementos de controle do restante da interface de um aplicativo. Figura 7 - Cliente VNC em um dispositivo móvel 2.2 DESKTOP REMOTO O protocolo do desktop remoto (Remote Desktop Protocol) [8] foi desenvolvido pela Microsoft com base na família de protocolos ITU T.120. O RDP permite fazer o login em um computador remoto e controlá-lo, conforme ilustrado na figura 8. O sistema operacional da máquina remota deve ser uma versão do Windows dotada da tecnologia Terminal Services, como Windows 2003 o Windows XP.

29 28 Figura 8 - Login do desktop remoto do Windows Figura 9 - Desktop remoto visualizado no cliente Tal como ocorre com o VNC, o protocolo RDP possibilita o acesso aos recursos gráficos (display) e aos mecanismos de entrada do servidor, porém, permite também controlar os drivers e utilizar a impressora conectada à máquina remota. Além disso, o áudio da máquina controlada é direcionado diretamente ao cliente. RDP é um protocolo multicanal, permitindo enviar áudio, vídeo e dados através de canais distintos. O número máximo de canais pode chegar a Os canais podem ser usados inclusive para comunicação multiponto. No servidor, o protocolo utiliza um driver de vídeo específico para gerar as saídas em pacotes RDP a serem enviados ao cliente. A saída de vídeo contém informações

30 29 que depois serão utilizadas pelo cliente para reconstruir a representação gráfica do desktop remoto, através da produção de primitivas gráficas GDI win32. O protocolo conta com drivers dedicados para mouse e teclado. Esses drivers tratam os pacotes que chegam pela rede e os convertem em eventos de entrada que simulam os eventos reais do mouse e do teclado. Os eventos resultantes são inseridos na fila de sistema da máquina onde está sendo executado o servidor. Por razões de segurança, os dados de entrada são criptografados antes de serem enviados ao cliente. Por ser integrado ao sistema operacional, o RDP tende a apresentar um desempenho mais elevado do que os concorrentes. Porém, apresenta a desvantagem de funcionar somente na plataforma Windows, apesar de existirem versões do cliente para outros sistemas, como Mac e Unix. Há também uma versão do cliente para sistemas baseados no Windows CE (figura 10) que permite ao usuário conectar-se a um computador remoto através de um dispositivo móvel e controlá-lo. Analogicamente ao VNC, o desktop remoto dispõe de uma versão do cliente para navegador web, como mostra a figura 11. Figura 10 - Remote Desktop Protocol em diversos dispositivos 1 RDP apresenta várias otimizações para funcionar também em redes de baixa velocidade. As otimizações compreendem compressão de áudio e vídeo, cache para bitmaps, símbolos e fontes. Outra funcionalidade fornecida é utilização da área de 1 Fonte:

31 transferência (clipboard) para transferência de dados entre o sistema operacional local e o remoto. 30 Figura 11 - Remote Desktop client no Internet Explorer A tecnologia do desktop remoto não é uma exclusividade da Microsoft. Na realidade, existem aplicações de desktop remoto para Unix e Macintosh (figura 12). O objetivo é sempre o de controlar um computador remoto mediante a transmissão da representação gráfica do desktop remoto ao cliente e a reprodução dos dados de entrada do cliente na máquina controlada.

32 31 Figura 12 - Apple Remote Desktop Analogamente ao VNC, a tecnologia do desktop remoto não permite modificar as interfaces das aplicações. É necessário, portanto, recorrer a outros meios para contornar as limitações dos dispositivos móveis, como as barras de rolagem mencionadas anteriormente. Além do desktop remoto e do VNC, existem os chamados desktops virtuais. Tratamse de sistemas baseados na web que, ao contrário das tecnologias já discutidas, não têm como objetivo controlar uma máquina remota, mas um computador virtual disponível em uma página web. Os desktops virtuais permitem que o usuário se conecte através de um mecanismo de autenticação e utilize os aplicativos disponíveis em um ambiente que se assemelha a um desktop de um computador real. 2.3 DESKTOP VIRTUAL O desktop virtual é um tipo de serviço que disponibiliza ao usuário ferramentas simples e intuitivas para comunicação e compartilhamento de dados na Internet. Entre os aplicativos oferecidos é normal encontrar sistemas de correio eletrônico, calculadora, agenda, gerenciadores de contatos, jogos, sistemas de mensagem instantânea, etc.

33 32 Um desktop virtual simula a área de trabalho de um computador, permitindo a execução de vários programas ao mesmo tempo. A figura 13 apresenta um portal que oferece o serviço de desktop virtual denominado Goowy [9]. Normalmente, esses portais oferecem também serviços de armazenamento de dados simulando um sistema de arquivos local. Em geral, a tecnologia por trás desses sistemas é baseada no AJAX (Asynchronous JavaScript and XML) e no Flash da Adobe. A utilização do AJAX evita que uma página seja recarregada a cada requisição do usuário, pois muitas requisições são previstas e tratadas em paralelo pelo sistema. Por esse motivo, as aplicações do desktop virtual são mais parecidas com as aplicações de um PC do que as páginas web comuns. Figura 13 - Desktop virtual Goowy

34 33 3 MATERIAIS E MÉTODOS Para o desenvolvimento do projeto, inicialmente foi realizada, uma pesquisa bibliográfica sobre as tecnologias existentes semelhantes ao sistema proposto, tais como VNC, Desktop Remoto e Desktop Virtual. Além disso, foram pesquisados algoritmos de computação gráfica que poderiam ser utilizados no projeto, bem como tecnologias para o desenvolvimento do software que permitissem a interação de baixo nível com o sistema operacional e com os aplicativos em execução. Para a geração das descrições das interfaces, foram pesquisadas as linguagens de descrição de interface existentes. Após essa fase de pesquisa, iniciou-se o projeto do sistema. Devido ao caráter inovador do mesmo, foi adotado um ciclo de desenvolvimento iterativo e incremental, com base na realização de experimentos a partir da construção de protótipos do sistema. 3.1 FERRAMENTAS DE DESENVOLVIMENTO O projeto consiste no desenvolvimento de um aplicativo servidor para PC, um aplicativo cliente para computadores portáteis e um protocolo de comunicação para troca de mensagens entre o cliente e servidor por meio da Internet. A primeira versão do sistema foi desenvolvida para a plataforma Windows, por ser a mais comum no mercado, embora pudesse ter sido escolhida outra plataforma qualquer. O servidor foi desenvolvido em linguagem C++, utilizando as bibliotecas de sistema da plataforma Win32 e as bibliotecas de classes do MFC (Microsoft Foundation Classes). A escolha da linguagem C++ facilitou a interação de baixo nível com o sistema operacional necessária para a execução das diversas etapas do processo de geração das descrições e do controle remoto dos aplicativos. O aplicativo cliente, por outro lado, foi implementado em linguagem C# através da utilização das bibliotecas de classes do.net Compact Framework. A facilidade e a rapidez no desenvolvimento de aplicativos para dispositivos móveis proporcionadas por essa tecnologia, além da disponibilidade de uma versão gratuita para fins

35 34 acadêmicos, foram fundamentais para a escolha desse ambiente de desenvolvimento integrado. O projeto prevê ainda a geração de arquivos contendo as descrições das interfaces codificadas de acordo com o formalismo da linguagem XUL, uma linguagem de descrição de interface baseada em XML desenvolvida no âmbito do projeto Mozilla. O protocolo de comunicação desenvolvido apóia-se sobre o protocolo TCP, através da utilização de Sockets. A escolha do TCP permitiu que os esforços de desenvolvimento se concentrassem nas funcionalidades do sistema, em vez de nos detalhes da transmissão de dados. 3.2 LINGUAGENS DE DESCRIÇÃO DE INTERFACES Uma linguagem de descrição de interface (UIDL) [10] é uma linguagem de programação de alto nível desenvolvida com o objetivo de capturar a essência da interação homem-computador, independentemente da linguagem de implementação da aplicação, como Java, C++ ou C#. A necessidade desse tipo de linguagem se tornou evidente quando projeto de interfaces começou a ser realizado através da especificação de módulos independentes da lógica de controle dos programas. Essa necessidade foi reforçada quando os módulos de interface passaram a serem descritos como conjuntos de especificações a serem comunicadas e discutidas pelas pessoas envolvidas no projeto. A possibilidade de geração automática ou semi-automática de código foi outro fator de incentivo ao desenvolvimento das linguagens UIDL. O desenvolvimento das linguagens UIDL foi interrompido por alguns anos até que a utilização do XML começou a se difundir. A possibilidade da criação de novas linguagens com a facilidade promovida pelo XML junto à grande variedade de plataformas existentes (laptops, palmtops, smartphone, tablet PC, desktop PC) despertaram novamente o interesse pelas linguagens UIDL. As linguagens UIDL possuem também a vantagem de serem declarativas, ou seja, especificam o que se deseja e não o como deve ser feito. Por esse motivo, as UIDL

36 podem ser utilizadas por não programadores ou por programadores ocasionais, permitindo a discussão dos requisitos do projeto com pessoas não técnicas XML A meta linguagem XML [11], desenvolvida pelo W3C XML Working Group, é uma tecnologia portável, amplamente suportada e não proprietária para a descrição dos dados das aplicações XML, que está se tornando rapidamente um padrão utilizado pelas aplicações para o armazenamento de dados e para troca de mensagens. Utilizando XML é possível descrever qualquer tipo de dados: fórmulas matemáticas, parâmetros de configuração de programas, músicas, receitas, relatórios financeiros, etc. Além disso, através do XML são produzidos documentos compreensíveis tanto pela máquina como pelos seres humanos XML documents A figura 14 mostra um exemplo de documento XML para a descrição de um artigo, extraído de [12].

37 36 1 <?xml version = "1.0"?> 2 3 <!-- Artigo.xml --> 4 <!-- Artigo estruturado com XML --> 5 6 <article> 7 8 <title>xml Simples</title> 9 10 <date>6 de dezembro de 2001</date> <author> 13 <firstname>mario</firstname> 14 <lastname>rossi</lastname> 15 </author> <summary>xml é muito simples.</summary> <content> 20 Este è um exemplo muito simples de documento que utiliza XML 21 </content> </article> Figura 14 - Exemplo de documento XML O documento apresentado na figura anterior inicia com uma declaração XML opcional (linha 1), que identifica o documento como XML document. O parâmetro version especifica a versão da sintaxe XML utilizada. Os comentários (linhas 3 e 4), que iniciam sempre com <!-- e terminam com -->, podem ser inseridos em qualquer parte do documento. Como em outras linguagens de programação, os comentários são utilizados para efeito de documentação. Em XML, os dados são assinalados com a utilização dos tags nomes delimitados entre os símbolos < e >. Os tags são sempre utilizados aos pares para delimitar os caracteres. O tag que inicia a marcação é denominado start tag, enquanto que o tag utilizado para encerrá-la é denominado end tag. Exemplos de start tag são <article> e <title> (linhas 8 e 23 respectivamente). Os end tags são diferenciados dos start tags com um caracter de slash (/). Exemplos de end tag são </title> e </article> (linhas 6 e 8 respectivamente).

38 37 Uma unidade de marcação, ou seja, tudo aquilo que está entre um start tag e o end tag correspondente, é denominada elemento XML. Um documento contém um elemento especial chamado raiz que engloba todos os outros elementos. Na figura 14, article (linha 6) é o elemento raiz. Os elementos são dispostos em uma estrutura hierárquica com o elemento raiz no topo, o que permite criar associações explícitas entre os dados. Por exemplo, os elementos title, date, author, summary e content são colocados dentro do elemento article. Os elementos firstname e lastname são colocados dentro do elemento author. O elemento title (linha 8) contém o título do artigo. Analogamente, os elementos date (linha 10), summary (linha 17) e content (linha 19) contêm a data, o resumo e o conteúdo, respectivamente. O nome de um elemento pode ter um tamanho qualquer e pode conter letras, dígitos, underscore, hífen e ponto. Todavia, deve iniciar por letra ou underscore. Considerado isoladamente este documento é apenas um arquivo de texto chamado article.xml. Embora não seja obrigatório, a maior parte dos documentos XML terminam com a extensão.xml. O processamento de um documento XML requer uma aplicação específica denominada XML parser. Esse tipo de aplicação verifica a sintaxe do documento e disponibiliza os dados contidos no mesmo às aplicações XML namespace As linguagens orientadas a objetos como C++ e C# fornecem bibliotecas de classes que agrupam suas funcionalidades nos chamados espaços de nome (namespaces). Os namespaces evitam conflitos de nome entre identificadores definidos pelo programador e as palavras reservadas pela própria linguagem. Um namespace XML é um meio de identificar univocamente um elemento XML. Além disso, as linguagens baseadas em XML normalmente utilizam os namepaces para identificar seus elementos específicos. Os elementos são diferenciados através do prefixo do namespace ao qual pertencem. Por exemplo:

39 38 <poli:tese>guix project</poli:tese> Nesse exemplo, o prefixo poli referente ao namespace qualifica o elemento tese, o que significa que o elemento tese faz parte do namespace poli. Pode-se usar qualquer nome como um prefixo, exceto o prefixo reservado xml. Caso se utilize um só namespace no interior do elemento raiz, então o uso do prefixo é opcional. Para garantir que os namespaces sejam únicos, é comum utilizarem-se URIs. Uma prática comum é usar uma URL como namespace, pois os domínios representados por URLs (como não podem ser repetidos. <poli:tese xmlns:poli = " GUIX project </poli:tese> No exemplo acima foi utilizada a URL referente à página da Escola Politécnica da USP para identificar o namespace. O aplicativo parser nunca visita essa URL, ela é simplesmente uma string de caracteres usada para distinguir os nomes XML validation Os documentos XML podem fazer referência a documentos opcionais que definem como os mesmos devem ser estruturados. Esses documentos são chamados Document Type Definition (DTD) e XML schema. Quando um DTD ou um schema é fornecido, alguns parsers, chamados validating parsers, são capazes de usar o DTD ou schema para verificar se a estrutura do documento XML está correta. Se o documento XML está de acordo com o DTD ou schema, então o documento XML é considerado válido. Os parsers que não verificam se o documento está de acordo com o DTD ou schema são chamados non-validating parser.

40 39 Se um parser XML é capaz de processar um documento XML, mesmo não utilizando um DTD ou schema, o documento é considerado bem formado (well formed), ou seja, é considerado sintaticamente correto. Por definição, um documento válido é também um documento bem formado. Se um documento não é bem formado, o processo de parsing é interrompido e o parser sinaliza o erro ocorrido. Para ser considerado bem formado, um documento XML deve apresentar as seguintes características: Deve ter um único elemento raiz que engloba todos os outros elementos. No exemplo anterior, article é o elemento raiz. Todos os tags devem ser fechados. Por exemplo, o tag <title> deve ser fechado com </title> Não pode existir sobreposição de tags. A seqüência <article> <title> </article> </title> é errada. O correto seria <article> <title> </title> </article>. Os elementos vazios devem ser indicados simplesmente com o start tag seguido do end tag sem nada entre eles ou com a sintaxe <empty_element/>. 3.4 XUL XUL (pronunciado zul) é uma linguagem de alto nível baseada em XML desenvolvida no âmbito do projeto Mozilla para a descrição de interfaces baseadas em janelas. O objetivo do XUL é possibilitar a criação de aplicativos independentes da plataforma, promovendo portabilidade para os diversos sistemas operacionais para os quais existem versões dos programas do projeto Mozilla. XUL promove uma nítida separação entre a interface e a lógica de controle. Por conseqüência, o aspecto geral (look and feel) de uma aplicação feita em XUL pode ser variado independentemente do modelo de dados e da lógica de controle do programa.

41 40 A interface é descrita como um conjunto de elementos estruturados (window, menubar, scrollbar, button) caracterizados através de uma série de atributos. A interação com o usuário é realizada através da utilização de linguagens de script. Além disso, para a criação de aplicações web multiplataforma, podem ser utilizadas outras tecnologias: XBL (extensible Binding Language) linguagem de marcação que define novos elementos (métodos, conteúdos e propriedades) para os widgets de XUL Overlays arquivos XUL utilizados para descrição de conteúdo extra para a interface XPCOM / XPConnect permite a utilização de bibliotecas escritas em outras linguagens como C++ e Java XPInstall fornece um mecanismo para criar pacotes de aplicações XUL para facilitar a distribuição das mesmas A Tabela 1 resume as principais vantagens e desvantagens da linguagem de descrição de interface XUL. Tabela 1 Vantagens e desvantagens da linguagem XUL Vantagens Simples de usar e fácil de aprender Disponibilidade de versão estável e gratuita Flexibilidade na descrição dos elementos Disponibilidade de ferramentas de suporte Integração com programas do Mozilla Ampla documentação disponível Desvantagens Representação limitada de componentes Não oferece abstrações de interação com o usuário, por exemplo, durante a interação com caixas de diálogo sucessivas para a execução de uma tarefa complexa.

42 OUTRAS LINGUAGENS DE DESCRIÇÃO UIML UIML (User Interface Markup Language) é uma meta-linguagem que permite ao desenvolvedor descrever uma interface em termos gerais e usar uma descrição de estilo para associar a interface a diferentes sistemas operacionais, linguagens e dispositivos. UIML foi criado pelo Virginia Tech's Center for Human Computer Interaction, e outras organizações ( Os trabalhos no projeto tiveram início em Um documento UIML contém três partes distintas: A descrição da interface, uma seção para os links aos documentos externos (lógica de controle e biblioteca gráfica do sistema) e a seção de modelo que permite a reutilização de elementos de interface. Em UIML, a interface é descrita como um conjunto de elementos com os quais o usuário pode interagir. Para cada elemento é atribuído um estilo de apresentação (disposição, fonte, cor), um conteúdo (texto, imagem), conjunto de entradas prováveis e as ações correspondentes. A reconstrução é realizada a partir da descrição UIML conforme as especificações do componente de apresentação. A comunicação com a lógica de controle é realizada através da seção de links. O aplicativo que executa a reconstrução interpreta o código UIML no dispositivo cliente (de modo semelhante à exibição de arquivos HTML da web) ou transforma a descrição em uma linguagem alvo. Uma desvantagem da linguagem UIML é que ela fornece uma única forma para definir diferentes tipos de interfaces e, portanto, não permite a criação de interfaces para diferentes linguagens, nem mesmo para dispositivos distintos a partir de uma única descrição. Existe ainda a necessidade de se desenvolver uma interface de usuário separada para cada dispositivo. Além disso, UIML é uma linguagem em desenvolvimento e ainda possui muitas imperfeições.

43 AUIML Em 1998 a IBM iniciou um projeto de tecnologia avançada para o desenvolvimento de uma linguagem de descrição de interface independentes dos dispositivos. Este projeto resultou em um vocabulário XML chamado AUIML (Abstract User Interface Markup Language). AUIML permite ao desenvolvedor definir o nível de interação com o usuário, em vez de se concentrar apenas no aspecto visual. Isto significa que os desenvolvedores devem focar na semântica da interação. Na verdade, AUIML foi projetada para ser independente de qualquer plataforma cliente e de qualquer linguagem de programação final. Uma descrição seria capaz de funcionar em diversos dispositivos clientes. A interface do usuário é descrita em termos de manipulação de objetos, de elementos de interação e de ações para gerenciar eventos entre a interface a as estruturas de dados. Além de especificar a aparência da interface, o modelo de apresentação possui uma grande flexibilidade em fornecer as informações necessárias para o desenvolvimento do processo. O desenvolvedor pode verificar aquilo que deve ser apresentado ou apenas definir o estilo da interação, deixando outras decisões para o aplicativo responsável pela reconstrução da interface. Uma vez que a AUIML foi desenvolvida para uso interno da IBM, grande parte das informações é confidencial. Até o momento não existem editores disponíveis e pouca informação é disponibilizada publicamente, além do mecanismo de reconstrução ser mantido em segredo XIML O XIML (extensible Markup Language Interface) fornece um meio de descrever uma interface de usuário sem se preocupar com sua implementação. XIML foi desenvolvido pelo centro de pesquisa de RedWhale Software Corp. Hoje ele é mantido pelo fórum XIML ( uma organização dedicada a pesquisas industriais, divulgação e padronização dos códigos XIML.

44 43 O objetivo do XIML é descrever aspectos abstratos da interface (por exemplo, atividades, domínios e usuários) e aspectos concretos (apresentação e diálogos) durante o ciclo de desenvolvimento. XIML permite também realizar associações entre aspectos abstratos e concretos. A definição da linguagem ainda não está concluída. Apesar da especificação do XIML visar à geração de código em tempo de desenvolvimento (design time) e interpretação do código em tempo de execução (runtime), não existem ainda ferramentas disponíveis para estes fins Seescoa XML O projeto Seescoa (Software Engineering for Embedded Systems using a Component Oriented Approach) foi iniciado em 1999 envolvendo quatro universidades belgas. O principal objetivo do projeto é adaptar as tecnologias de engenharia de software às necessidades do software para dispositivos móveis. O Seescoa propõe uma arquitetura para serialização da interface desenvolvida em Java em uma descrição XML. Isto fornece uma descrição abstrata da interface, a qual é descrita como uma hierarquia de objetos abstratos de interação. Uma vez que a interface foi serializada e a descrição XML produzida, a descrição é transferida para outro dispositivo no qual pode ser desserializada em uma interface de usuário para o dispositivo cliente. Este processo envolve a associação entre objetos abstratos e objetos concretos da plataforma específica. Na verdade, a aplicação responsável pela reconstrução da interface processa a descrição XML com liberdade de escolher entre as formas de apresentação disponíveis para representar uma determinada funcionalidade. O projeto ainda está sendo desenvolvido e até agora não existem versões estáveis da linguagem. Uma desvantagem do Seescoa é oferecer suporte apenas a interfaces de usuários desenvolvidas em Java.

45 ESCOLHA DA LINGUAGEM UIDL Considerando as vantagens e desvantagens do XUL em comparação com as demais linguagens UIDL e o fato da maioria delas estarem ainda em fase de desenvolvimento, chegou-se à conclusão de que o XUL era a linguagem que melhor satisfazia as necessidades do projeto, além de oferecer vários mecanismos de suporte, não presentes em outras linguagens. Além disso, XUL é uma das poucas linguagens que possui uma versão estável e gratuita. 3.7 DISPOSITIVOS MÓVEIS Os dispositivos móveis são dispositivos portáteis que possuem funcionalidades semelhantes às de um PC. As limitações relativas às dimensões, capacidade de processamento e capacidade de armazenamento fazem com que as aplicações muitas vezes sejam desenvolvidas especificamente para cada tipo de dispositivo, nem sempre satisfazendo as necessidades do usuário. Os dispositivos móveis utilizados nesse trabalho são o Pocket PC e o smartphone ilustrados na figura 15. Figura 15 - Dispositivos móveis utilizados: Pocket PC e smartphone

46 45 4 ANÁLISE DE INTERFACES Como nem sempre o código fonte do aplicativo alvo está disponível, para a geração das descrições estruturadas das interfaces decidiu-se utilizar algoritmos da computação gráfica. As informações necessárias são obtidas através da utilização desses algoritmos para a análise das representações gráficas das interfaces. Em seguida serão descritas as dificuldades encontradas para viabilizar tal análise e a solução obtida, a qual faz parte da primeira aplicação escolhida para o GUIX, desenvolvida para o controle remoto de aplicativos através de interfaces reconstruídas em dispositivos móveis. 4.1 LOCALIZAÇÃO DOS ELEMENTOS DE INTERFACE O primeiro problema enfrentado no processo de análise foi o de descobrir a localização dos elementos de interface que possibilitam a interação com o usuário. Com a intenção de entender melhor o problema, decidiu-se começar pela identificação de um botão na interface de um aplicativo simples, como a calculadora do Windows. A primeira tentativa de encontrar uma solução para o problema foi a de utilizar algoritmos de computação gráfica [13], em particular o algoritmo de edge detection [14] para determinar o contorno da figura que representava o botão. Porém, tal algoritmo não resolvia o problema completamente, pois, apesar de encontrar as linhas que correspondiam aos lados dos objetos contidos na imagem, não localiza os elementos sem a utilização de outras técnicas. Durante essa fase de abordagem do problema, analisando alguns aplicativos com o objetivo de descobrir os detalhes das interfaces que poderiam dar idéia para uma possível solução, percebeu-se que na maioria dos casos a própria interface destacava os elementos com os quais o usuário poderia interagir quando se passava o cursor do mouse sobre eles. Assim, o problema de descobrir a localização dos elementos poderia ser resolvido fazendo a diferença entre a imagem inicial da interface e a imagem no momento em que um elemento era destacado.

47 46 Uma vez que todo o resto da interface permanece invariável quando um elemento é colocado em evidência somente a região que sofre mudança aparece na imagem resultante. Calculando-se o contorno dessa região na imagem resultante permite descobrir a localização e as dimensões do elemento. A figura 16 mostra um exemplo de localização de um botão. (a) (b) (c) (d) Figura 16 - Utilizando o recurso de highlighting para encontrar um botão (a) tela inicial, (b) highlighting do botão Back, (c) diferença entre as imagens, (d) elemento selecionado 4.2 VARREDURA DA INTERFACE A varredura da interface é realizada através de deslocamentos sucessivos do cursor do mouse sobre a janela do aplicativo de forma que os elementos sejam destacados pelo recurso de highlighting da interface. O deslocamento do cursor é efetuado através de chamadas às funções de sistema.

48 47 O movimento do cursor é sempre da esquerda para a direita, linha por linha. Quando chega à extremidade direita, o cursor vai para o início da linha sucessiva. A distância entre as linhas é especificada através do passo vertical, enquanto que o passo horizontal define o quanto o cursor é deslocado horizontalmente em cada iteração (figura 17). Os parâmetros discutidos devem ser configurados antes do início da varredura, assim como o tempo entre as amostras da interface. Este último parâmetro é importante porque indica quanto tempo o sistema fica em espera entre uma iteração e outra, permitindo que o processo do aplicativo alvo efetue a atualização da interface em correspondência à movimentação do cursor. Passo horizontal Passo vertical Figura 17 - Varredura da interface através de deslocamentos do cursor do mouse A cada deslocamento do cursor é executado um algoritmo para verificar se algum elemento foi encontrado. Em caso afirmativo, esse mesmo algoritmo calcula a posição e as dimensões do elemento. Analisando ainda a figura 17 nota-se que a identificação dos elementos depende fortemente dos parâmetros que controlam a varredura da interface. Se os valores dos passos horizontal e vertical forem muito altos, elementos menores podem passar despercebidos. Por outro lado, se forem muito baixos, o tempo total de

49 48 varredura pode ser muito longo. Além disso, muitas vezes o cursor posiciona-se sobre o mesmo elemento mais de uma vez. Por esse motivo, foi elaborado um algoritmo que evita que o cursor pare sobre um elemento já encontrado, usando as informações adquiridas até o momento. Esse algoritmo é baseado em um mapa dos elementos já encontrados. Trata-se de uma matriz do mesmo tamanho da imagem da interface cujas células são atualizadas durante a varredura. Quando um elemento é encontrado, a região correspondente no mapa é preenchida com o valor da posição imediatamente após o elemento se a próxima posição do cursor for calculada e por ventura cair sobre esse mesmo elemento, o valor do cálculo será ajustado para a posição obtida diretamente da matriz. Na figura 18, as regiões em cinza escuro representam os elementos encontrados. Cada célula em uma dessas regiões aponta para a posição representada na cor cinza claro no lado direito da região cinza escuro. É para esse ponto que o cursor do mouse é deslocado quando cai sobre um elemento já encontrado. Figura 18 - Mapa para evitar que o cursor pare mais de uma vez sobre o mesmo elemento

50 CLASSIFICAÇÃO DOS ELEMENTOS DE INTERFACE Após a localização dos elementos realizada através das técnicas descritas na seção precedente, prossegue-se com a classificação dos elementos encontrados empregando-se técnicas de reconhecimento de formas no interior das figuras que representam os elementos. Devido à grande variedade de interfaces e da utilização de ícones e outros elementos gráficos não padronizados para a criação das mesmas, torna-se muito complicado criar um algoritmo capaz de classificar todos os elementos possíveis. Além disso, muitas vezes a resolução e o contraste das figuras são muito baixos. A imagem na figura 19 representa um elemento do tipo slider, o qual permite modificar o valor de um parâmetro numérico simplesmente arrastando o mouse sobre o elemento. Analisando essa figura percebe-se a existência de uma seta em cada extremidade do elemento e um rótulo ao centro, que contém texto e um número inteiro. Uma das possibilidades para classificar uma imagem com este tipo de padrão seria identificar as setas nas extremidades do elemento. Figura 19 - Representação gráfica de um slider Para que fosse possível classificar as seleções, foram criados alguns algoritmos de reconhecimento de formas no interior de figuras. Esses algoritmos apresentam um bom desempenho na classificação dos elementos com base nos padrões encontrados nas imagens. O primeiro algoritmo desenvolvido divide a imagem de um elemento em blocos contendo símbolos separados dos demais. Em seguida, foi desenvolvido um algoritmo para determinar o reconhecimento de formas nos blocos. Por fim, foram

51 criadas regras de classificação com base nas informações extraídas das imagens para atribuir os tipos aos elementos Divisão da imagem em blocos O primeiro algoritmo desenvolvido divide a imagem de um elemento em blocos contendo símbolos separados dos demais. Esse algoritmo permite detectar a presença de símbolos particulares em uma imagem fazendo inferências a partir das características dos blocos encontrados, como quantidade, largura média, espaçamento e alinhamento. O algoritmo realiza uma varredura na imagem do elemento da esquerda para a direita (figura 20), analisando coluna por coluna da matriz que representa a imagem. Para cada coluna, traça uma scanline vertical de cima para baixo até chegar à extremidade inferior da imagem ou encontrar um pixel de cor diferente da cor do fundo (o que indica que encontrou um símbolo). Quando encontra um pixel diferente do fundo, começa a contar o número de colunas que passam antes de uma scanline chegar até a base novamente. Quando isso acontece, armazena o número de colunas como a largura de um bloco e calcula as demais informações de interesse, recomeçando o ciclo para encontrar os demais símbolos. Figura 20 - Representação gráfica do algoritmo da divisão da imagem em blocos

52 Reconhecimento de formas Muitos dos elementos que se propõe classificar contêm figuras em forma de seta, fato que motivou o desenvolvimento de mecanismos para o reconhecimento desse tipo de forma. O algoritmo desenvolvido para tal fim recebe as informações extraídas da imagem pelo algoritmo da divisão em blocos e determina se um determinado bloco contém uma seta, além de determinar a direção e o sentido da mesma. O reconhecimento das setas é realizado através da análise do contorno da figura contida no bloco passado como parâmetro. A figura 1 mostra um exemplo de forma reconhecida pelo algoritmo (nesse caso trata-se de uma seta para baixo). Figura 21 Exemplo de forma reconhecida pelo algoritmo De maneira análoga ao algoritmo anterior, a imagem é analisada através de uma varredura onde são traçadas scanlines. Essas linhas são traçadas enquanto não se encontram pixels diferentes do fundo. Toda vez que um desses pixels é encontrado, o comprimento da linha traçada é armazenado. Posteriormente, a análise baseada no comprimento das scanlines permitirá inferir a forma do contorno da figura. Quando todas as colunas forem analisadas, será traçada uma linha perpendicularmente as scanlines onde se espera que o contorno seja fechado. Se essa linha detectar pixels diferentes da cor do fundo, o contorno não é o que se estava prevendo e, portanto, a figura não contém a seta procurada. A figura 22 ilustra a análise do contorno de uma seta para baixo através da varredura com scanlines.

53 52 Figura 22 - Análise do contorno de figuras baseado no comprimento das scanlines Na figura 23 é ilustrado um exemplo de aplicação do algoritmo de reconhecimento de formas após a divisão da imagem em blocos. Nesse exemplo, foi encontrada uma seta na parte direita da figura o que representa um indício de que o elemento é uma combo box (o elemento apresentado foi extraído de uma interface real). Figura 23 - Representação gráfica do algoritmo para o reconhecimento de formas Regras de classificação Para a classificação dos elementos foram adotadas regras de classificação simples que quando combinadas apresentam um bom nível de acerto. Essas regras foram estabelecidas com base em experimentos realizados com algumas interfaces comumente encontradas hoje em dia. O objetivo não era permitir a classificação de todos os elementos existentes, mas de um subconjunto de elementos escolhidos para a primeira versão do sistema. As regras são representadas na forma condição1, condição2,..., condiçãon tipo. Se um elemento satisfaz as condições à esquerda da expressão, o mesmo é classificado com o tipo indicado. As regras utilizam as informações obtidas dos algoritmos explicados anteriormente.

54 53 As regras apresentadas a seguir são aplicadas na ordem indicada. Se depois da verificação de todas as regras o elemento ainda não foi classificado, seu tipo é marcado como desconhecido (unknown). Os tipos que podem ser atribuídos aos elementos são: button, menu, combo box e slider. Nas regras são utilizados valores de comparação que podem ser configurados antes do início do processo para melhorar o desempenho do mesmo. 1. Número de blocos maior que o número mínimo de letras de um texto, Distância entre o primeiro bloco e o segundo maior que o espaçamento do texto, Distância entre o penúltimo bloco e o último maior que o espaçamento do texto, Primeiro bloco contém seta para a esquerda, Último bloco contém seta para a direita slider 2. Número de blocos maior que um, Distância entre o penúltimo bloco e o último maior que o espaçamento do texto, Último bloco contém seta para baixo combo box 3. Número de blocos maior que o número mínimo de letras de um texto, Distância média entre os blocos menor igual ao espaçamento máximo do texto, Número de ícones encontrados igual a zero menu 4. Número de blocos maior que o número mínimo de letras de um texto, Número de ícones maior igual a um button 5. Número de blocos igual a um, Número de ícones igual a um button

55 EXEMPLOS DE CLASSIFICAÇÃO Na seqüência serão apresentados alguns exemplos de classificação dos elementos de interface. Lembrando que as seleções ainda não classificadas são representadas em vermelho, enquanto que as classificadas possuem cores diversas conforme o tipo que foi atribuído a cada uma delas. A correspondência entre o tipo e a cor das seleções está representada na tabela 2. Tabela 2 - Correspondência entre cor e tipo de elemento Cor Vermelho Azul claro Azul escuro Lilás Verde Tipo Unknown Button Menu Combo box Slider Se após o processo de classificação não foi possível efetuar a atribuição de um tipo à seleção, essa permanece com a cor vermelha e o tipo é marcado como desconhecido (unknown). A figura 24 traz um exemplo onde foram classificados cinco menus, três combo boxes e quatro botões. Percebe-se ainda que não foi possível classificar quatro seleções: o menu help (? ) e os três botões de controle da janela (minimizar, maximizar e fechar). Quanto ao primeiro, o motivo pelo qual não foi possível classificá-lo pode ter sido o fato de o sistema não ter reconhecido o símbolo de interrogação como texto. Com relação aos botões de controle da janela, o processo de classificação não obteve sucesso provavelmente porque o preenchimento do fundo desses elementos não é uma cor sólida e sim um preenchimento do tipo gradiente. Desta forma, o

56 55 algoritmo que decompõe a imagem em blocos não consegue desempenhar o seu papel, pois o mesmo funciona com base em um fundo cuja cor de cada pixel pode variar somente dentro de uma faixa de tolerância pré-configurada. Ainda na mesma figura, percebe-se que os botões que contém texto não são diferenciados daqueles que não têm. Às vezes é útil remover a parte textual de um botão, como no caso da utilização do aplicativo cliente no smartphone. Figura 24 - Classificação dos elementos da interface do Windows Explorer Por esse motivo foi incluída uma funcionalidade que reduz a seleção de um elemento de forma a eliminar a parte textual, quando no processo de classificação o sistema detecta a existência de ícone e texto no mesmo elemento. Essa funcionalidade faz com que na seleção permaneça somente o ícone, diminuindo significativamente a largura do elemento classificado, como ilustra a figura 25.

57 56 Figura 25 - Remoção do texto dos elementos durante a classificação Na figura 26 é representado o resultado do processo de classificação dos elementos de interface do programa Blender. A partir da figura se conclui que foram classificados com sucesso nove menus, seis combo boxes, sete botões e um slider. Figura 26 - Classificação dos elementos da interface do Blender

58 57 5 DESCRIÇÃO DE INTERFACES Após a análise e a classificação dos elementos passa-se à geração da descrição da interface. A descrição é armazenada em um arquivo de texto codificado de acordo com o formalismo da linguagem XUL. Nas seções seguintes serão discutidos os principais elementos utilizados e as adaptações realizadas para a descrição das interfaces. Por fim, será apresentado um exemplo de descrição gerada pelo GUIX. 5.1 DESCRIÇÃO DA INTERFACE EM XUL Embora a linguagem XUL seja bastante completa para a descrição de interfaces clássicas, alguns elementos de interface necessários do projeto não fazem parte da linguagem, como o elemento slider. Para contornar essa limitação foram feitas algumas adaptações no código de forma a possibilitar a descrição de novos elementos, bem como para a inclusão de informações relevantes para a reconstrução da interface. Essas adaptações foram feitas somente com base nos recursos da própria linguagem, sem que fossem realizadas mudanças na linguagem em si, o que fugiria do escopo do projeto. Em seguida serão explicados os elementos utilizados na descrição das interfaces através de código XUL. Serão indicadas também as adaptações que foram feitas na utilização dos elementos.

59 Window <window id="window1" title="program s name" orient="horizontal" width="320" height="240" xmlns=" <!-- Elementos de interface --> </window> O elemento window é utilizado para representar a janela do aplicativo. Esse elemento contém atributos referentes ao título da janela e às suas dimensões. Contém também um campo para identificação, um atributo de orientação e o namespace utilizado entre o start tag e o end tag Server <groupbox id="server"> <caption label="server Properties"/> <textbox id="ip" value=" "/> <textbox id="port" value="20000"/> </groupbox> O elemento server não tem um correspondente direto na linguagem XUL e por isso foi representado por um elemento groupbox com o atributo id definido como server. Esse elemento serve para passar informações importantes para o cliente a fim de facilitar a configuração dos parâmetros de conexão, como endereço IP do servidor e número da porta do protocolo de transporte.

60 Workarea <groupbox id="workarea"> <caption label="work Area"/> <image id="1" left="5" top="94" width="240" height="240" src="image1.bmp"/> </groupbox> O elemento workarea é outro elemento que não possui um correspondente na linguagem XUL, sendo representado por uma groupbox com id igual a workarea. Esse elemento contém o título da área de trabalho, um campo para identificar a seleção no servidor a posição e as dimensões da área de trabalho, e o nome do arquivo que contém a imagem inicial a ser utilizada na reconstrução da interface Button <hbox id="buttons"> <button id="11" left="10" top="50" width="30" height="20" image="img11.bmp"/> <button id="13" left="50" top="50" width="30" height="20" image="img12.bmp"/> <button id="14" left="90" top="50" width="30" height="20" image="img13.bmp"/> </hbox> O elemento button representa um botão, contendo atributos referentes à posição e às dimensões desse elemento, um campo para identificar a seleção correspondente no servidor e o nome do arquivo que contém a imagem inicial.

61 60 No exemplo acima se nota que os elementos do tipo botão devem ser agrupados através de um elemento hbox, cujo atributo id é definido com a palavra buttons, de forma que a construção desses elementos possa ser realizada corretamente no dispositivo móvel Menu <toolbox id="menus"> <menubar> <menu id="100" left="6" top="31" width="31" height="18" label="menu1"> <menupopup> <menuitem id="101" label="submenu 1.1"/> <menuitem id="102" label="submenu 1.2"/> <menuitem id="103" label="submenu 1.3"/> </menupopup> </menu> <menu id="200" left="38" top="31" width="31" height="18" label="menu2"> <menupopup> <menuitem id="201" label="submenu 2.1"/> <menuitem id="202" label="submenu 2.2"/> <menuitem id="203" label="submenu 2.3"/> </menupopup> </menu> </menubar> </toolbox> No exemplo acima está representada uma barra de menu que contém dois itens principais, um com id igual a 100 e o outro com id igual a 200. Os menus são constituídos por seus submenus. A barra de menu é representada pelo elemento menubar que deve estar contida em um elemento toolbox. O elemento menubar não contém atributos. Cada menu possui um campo para identificação, atributos para armazenar a posição, as dimensões e o rótulo. O atributo rótulo serve para armazenar o título do menu e normalmente é gerado automaticamente pelo OCR.

62 61 Cada elemento menu é composto por um elemento menupopup que engloba os itens do menu. Cada item é representado por um elemento menuitem, contendo o identificador da seleção correspondente no servidor e um rótulo. Os submenus devem estar contidos em um menupopup, o qual, por sua vez, deve estar contido em um elemento menu. Todos os menus devem ser colocados dentro de um elemento menubar. Por fim, o menubar deve estar delimitado por um elemento toolbox Combobox <hbox id="combo_boxes"> <button type="menu" id="20" left="10" top="10" width="50" height="30" image="img20.bmp"> <menupopup> <menuitem id="21" label="submenu 20.1"/> <menuitem id="22" label="submenu 20.2"/> <menuitem id="23" label="submenu 20.3"/> </menupopup> </button> <button type="menu" id="30" left="10" top="10" width="50" height="30" image="img20.bmp"> <menupopup> <menuitem id="31" label="submenu 30.1"/> <menuitem id="32" label="submenu 30.2"/> <menuitem id="33" label="submenu 30.3"/> </menupopup> </button> </hbox> O elemento combobox se assemelha muito ao elemento menu, pois ambos possuem itens contidos em menupopups. No entanto, a combo box é representada por um elemento button especial, com atributo type igual a menu. Não se trata de uma adaptação, pois é essa a forma normal de representação de combo box na linguagem XUL. Os demais atributos são iguais aqueles descritos para o elemento menu.

63 EXEMPLOS DE DESCRIÇÃO Em seguida será apresentado um exemplo de descrição gerada a partir da análise da interface do Windows Explorer. A figura 27 mostra o resultado final da análise da interface e classificação dos elementos no servidor. Da figura conclui-se que a interface é constituída por cinco menus, três combo boxes, três botões e pela área de trabalho. O código na figura 28 foi produzido automaticamente. Figura 27 - Resultado da análise e classificação da interface do Windows Explorer

64 63 <?xml version="1.0"?> <!-- Guix Interface Description: Explorer5.xml --> <!-- XML-based user interface language: XUL > <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <window id="explorer5-window" title="explorer5" orient="horizontal" width="448" height="397" xmlns=" <vbox align="center" pack="center" flex="1"> <!-- Server properties --> <groupbox id="server"> <caption label="server Properties"/> <textbox id="ip" value=" "/> <textbox id="port" value="20000"/> </groupbox> <!-- WorkArea --> <groupbox id="workarea"> <caption label="work Area"/> <image id ="77" left="5" top="94" width="438" height="298" src="explorer5_xml_sel77.bmp"/> </groupbox> <!-- Buttons --> <hbox id="buttons"> <button id="12" left="150" top="54" width="31" height="37" image="explorer5_xml_sel12.bmp"/> <button id="13" left="188" top="54" width="66" height="37" image="explorer5_xml_sel13.bmp"/> <button id="14" left="255" top="54" width="75" height="37" image="explorer5_xml_sel14.bmp"/> </hbox> Figura 28 - Descrição da interface do Windows Explorer gerada automaticamente

65 64 <!-- Menus --> <toolbox id="menus"> <menubar> <menu id="4" left="6" top="31" width="31" height="18" label="file"> <menupopup> <menuitem id="17" label="sincronizzazione cartella di groove >"/> <menuitem id="18" label="nuovo >"/> <menuitem id="19" label="crea collegamento"/> <menuitem id="20" label="elimina"/> <menuitem id="21" label="rinomina"/> <menuitem id="22" label="proprieta"/> <menuitem id="23" label="chiudi"/> </menupopup> </menu> <menu id="5" left="38" top="31" width="54" height="18" label="modifica"> <menupopup> <menuitem id="24" label="annulla ctrl+i"/> <menuitem id="25" label="taglia ctrl+x"/> <menuitem id="26" label="copia ctrl+c"/> <menuitem id="27" label="incolla ctrl+v"/> <menuitem id="28" label="incolla collegamento"/> <menuitem id="29" label="copia nella cartella..."/> <menuitem id="30" label="sposta nella cartella..."/> <menuitem id="31" label="seleziona tutto ctrl+s (tn)"/> <menuitem id="32" label="inverti selezione"/> </menupopup> </menu> <menu id="6" left="93" top="31" width="60" height="18" label="visualizza"> <menupopup> <menuitem id="33" label="barre degli strumenti >"/> <menuitem id="34" label="barra di stato"/> <menuitem id="35" label="barra di explorer >"/> <menuitem id="36" label="anteprima"/> <menuitem id="37" label="titoli"/> <menuitem id="38" label="icone"/> <menuitem id="39" label="elenco"/> <menuitem id="40" label="dettagli"/> <menuitem id="41" label="disponi icone per >"/> <menuitem id="42" label="scelta dettagli..."/> <menuitem id="43" label="personalizza cartella..."/> <menuitem id="44" label="vai a >"/> <menuitem id="45" label="aggiorna"/> </menupopup> </menu> Figura 28 - Descrição da interface do Windows Explorer gerada automaticamente (cont.)

66 65 <menu id="7" left="154" top="31" width="53" height="18" label="preferiti"> <menupopup> <menuitem id="46" label="aggiungi a preferiti..."/> <menuitem id="47" label="organizza preferiti..."/> <menuitem id="48" label="collegamenti >"/> <menuitem id="49" label="entertainment >"/> <menuitem id="50" label="trasporti >"/> <menuitem id="51" label="programming >"/> <menuitem id="52" label="studying >"/> <menuitem id="53" label="utile >"/> <menuitem id="54" label="preferiti portatile >"/> <menuitem id="55" label="other >"/> </menupopup> </menu> <menu id="8" left="208" top="31" width="61" height="18" label="strumenti"> <menupopup> <menuitem id="56" label="connetti unita di rete..."/> <menuitem id="57" label="disconnetti unita di rete..."/> <menuitem id="58" label="sincronizza..."/> <menuitem id="59" label="opzioni cartella..."/> </menupopup> </menu> </menubar> </toolbox> <!-- Combo boxes --> <hbox id="combo_boxes"> <button type="menu" id="10" left="6" top="54" width="92" height="37" image="explorer5_xml_sel10.bmp"> <menupopup> <menuitem id="60" label="polito"/> <menuitem id="61" label="documenti"/> <menuitem id="62" label="leandro lourenzoni"/> <menuitem id="63" label="documents and settings"/> <menuitem id="64" label="vaio (cz.)"/> <menuitem id="65" label="documenti"/> <menuitem id="66" label="cronologia </menupopup> ctrl+h"/> Figura 28 - Descrição da interface do Windows Explorer gerada automaticamente (cont.)

67 66 <button type="menu" id="11" left="99" top="54" width="50" height="37" image="explorer5_xml_sel11.bmp"> <menupopup> <menuitem id="67" label="code"/> <menuitem id="68" label="guix"/> <menuitem id="69" label="guix"/> <menuitem id="70" label="debug"/> <menuitem id="71" label="cronologia ctrl+h"/> </menupopup> </button> <button type="menu" id="15" left="337" top="54" width="38" height="37" image="explorer5_xml_sel15.bmp"> <menupopup> <menuitem id="72" label="anteprima"/> <menuitem id="73" label="t i t o i i"/> <menuitem id="74" label="- icone"/> <menuitem id="75" label="elenco"/> <menuitem id="76" label="dettagli"/> </menupopup> </button> </hbox> </vbox> </window> Figura 28 - Descrição da interface do Windows Explorer gerada automaticamente (cont.) 5.3 CARREGANDO A DESCRIÇÃO NO NAVEGADOR WEB Como o código da descrição foi gerado na linguagem XUL, o mesmo pode ser carregado diretamente no navegador web Mozilla Firefox. O navegador reconstrói a interface descrita no arquivo, validando o código XML conforme o xml schema do XUL. Embora a interface seja reconstruída, não é possível controlar o aplicativo remoto correspondente sem incluir a lógica de controle necessária em alguma linguagem de programação como Java ou C++. Apesar disso, a utilização do navegador para carregar o código XUL foi intensamente utilizada durante o desenvolvimento do

68 67 projeto para fins de testes e verificação do código produzido automaticamente pelo GUIX. A figura 29 mostra o resultado da reconstrução da interface no Firefox. Nessa figura é possível observar que alguns elementos (server properties) não fazem parte da interface em si, mas como o navegador não tem como diferenciá-los acabou representado-os na interface. Esses elementos servem para passar informações importantes para o aplicativo cliente, que servirão para possibilitar a comunicação durante o controle do aplicativo remoto. Figura 29 - Descrição da interface reconstruída no navegador web

69 68 6 ARQUITETURA DO SISTEMA Para a realização da primeira aplicação do GUIX controle remoto de aplicativos através de interfaces reconstruídas em dispositivos móveis adotou-se a arquitetura cliente-servidor. O servidor é o responsável pela análise das interfaces dos aplicativos, pela produção de descrições UIDL e pela interpretação e execução dos comandos enviados pelo cliente para o controle da aplicação remota. O cliente realiza a reconstrução da interface a partir das descrições, permite realizar modificações na interface reconstruída e obtém entradas através da interação com o usuário, as quais são enviadas ao servidor para o controle do aplicativo remoto. O servidor realiza a análise da interface para a localização dos elementos que a compõe. Os elementos encontrados são processados para determinar as interrelações entre os mesmos. Além disso, o servidor também classifica os elementos encontrados com base nos padrões reconhecidos nas imagens de cada elemento. Após a classificação dos elementos, o servidor produz a descrição da interface na forma de um arquivo de texto. O cliente recebe como entrada a descrição gerada pelo servidor e reconstrói a interface do aplicativo remoto, permitindo ao usuário modificar dinamicamente a interface reconstruída, sem precisar repetir o processo de reconstrução. O controle do aplicativo remoto é efetuado através do mapeamento dos comandos gerados na nova interface com os comandos a serem executados na interface original. Para que isso seja possível, as entradas são enviadas ao servidor para serem convertidas em eventos do mouse e do teclado na máquina remota. A comunicação entre o cliente e o servidor é realizada através de um protocolo de comunicação simples desenvolvido para possibilitar o controle dos aplicativos remotos. A arquitetura geral do GUIX é representada na figura 30. GUIX Client GUIX Protocol GUIX Server Figura 30 - Arquitetura geral do sistema

70 ARQUITETURA DO SERVIDOR O servidor é um aplicativo que deve ser executado na mesma máquina que o aplicativo que se deseja controlar. O servidor efetua duas atividades distintas: a análise de interfaces e a comunicação com o cliente. A primeira é uma atividade que não depende do cliente. Na realidade, o cliente entra em operação somente depois que a descrição da interface é produzida pelo servidor. Na comunicação com o cliente, o servidor permanece à espera de requisições, as quais serão interpretadas e convertidas em operações válidas na interface original do aplicativo controlado. Como mostra a figura 31, o servidor é composto por quatro módulos: o analisador de interfaces, o classificador de elementos, o gerador de descrições e o tradutor de comandos. Apesar de parecer que o último módulo é independente dos demais, na verdade todos são interdependentes. O resultado do processo de análise da interface não é somente um arquivo texto contendo a descrição da interface, mas também um esquema de mapeamento baseado em seleções de imagens utilizado para determinar a localização exata de cada elemento na interface original. Cada elemento da nova interface possui um identificador unívoco que serve para estabelecer um vínculo com o elemento correspondente na interface do aplicativo remoto. Quando o servidor recebe um comando, a primeira coisa que faz é encontrar o elemento ao qual o comando se refere para poder efetuar as operações correspondentes. GUIX Server Tradutor de comandos Gerador de descrições Classificador de elementos Analisador gráfico Figura 31 - Arquitetura do servidor

71 70 No início da operação do servidor existe a possibilidade de executar o aplicativo alvo ou conectar o servidor a uma instância em execução desse aplicativo. Uma vez em execução o aplicativo alvo, o servidor providência a extração da representação gráfica da interface da memória de vídeo (frame buffer). Em seguida, é aplicada uma série de operações sobre a imagem obtida para encontrar os elementos de interface. Nesse ponto entra em ação o analisador gráfico Analisador gráfico O analisador gráfico é o módulo do servidor responsável pela localização dos elementos de interface a partir da análise de imagem da interface. Em particular, efetua a varredura da interface determinando a localização e as dimensões de cada elemento que a constitui. Para desempenhar seu papel, o analisador gráfico interage constantemente com o sistema operacional através de chamadas às bibliotecas de sistema. Para aproveitar o recurso de highlighting dos elementos, uma característica das interfaces atuais de destacar um elemento quando o mouse está sobre o mesmo, são realizadas chamadas às funções de sistema para o deslocamento do cursor do mouse sobre os elementos. Em primeiro lugar, capturam-se as imagens da interface antes da ativação do highlighting e imediatamente depois, calculando-se a diferença entre elas de modo a determinar a localização do elemento destacado. Quanto aos elementos mais complexos como menus e combo Box, o analisador gráfico efetua uma varredura adicional da interface após a classificação dos elementos encontrados na primeira varredura. A região que delimita um elemento na imagem da interface presente no servidor é denominada seleção. Seleções são representadas por retângulos com contorno tracejado e preenchimento semitransparente, como ilustrado na figura 32.

72 71 Figura 32 - Seleção dos elementos da interface Classificador de elementos A fase sucessiva à análise da interface é a classificação dos elementos encontrados. O processo de classificação é baseado no reconhecimento de padrões nas imagens dos elementos delimitadas pelas seleções. Os elementos efetivamente classificados são representados com cores distintas conforme o tipo atribuído. Os botões, por exemplo, são representados em azul claro, enquanto que os menus azul escuro e as combo boxes roxo, como ilustrado na figura 33. Os elementos não classificados permanecem com a cor padrão da seleção (vermelho claro). O classificador também é responsável pelo reconhecimento do texto nos elementos. O reconhecimento de caracteres (OCR) é realizado através da utilização de um módulo externo ao sistema composto por um software open source denominado GOCR [15]. Ainda em fase de desenvolvimento, esse software já apresenta taxa média de acerto superior a 90%. Dessa forma, a maior parte do texto é reconhecida sem problemas, mas podem ocorrer imprecisões resultando em símbolos estranhos em meio ao texto reconhecido. Levando em conta essa limitação, decidiu-se incluir uma funcionalidade no sistema que permitisse ao usuário efetuar correções manualmente.

73 72 Figura 33 - Classificação dos elementos de interface Gerador de descrições O módulo gerador de descrições produz arquivos texto contendo descrições de interfaces codificadas de acordo com o formalismo de uma linguagem UIDL baseada em XML. No contexto do presente trabalho foi escolhida a linguagem desenvolvida no âmbito do projeto Mozilla denominada XUL [16]. Das linguagens UIDL avaliadas, XUL é a mais simples e fácil de utilizar, além de oferecer uma ampla variedade de funcionalidades de suporte. É possível, por exemplo, criar um arquivo XUL e abri-lo diretamente no navegador Mozilla Firefox. Linguagens derivadas do XML têm a vantagem de produzir documentos cujo conteúdo é compreensível tanto para a máquina quanto para os seres humanos. A figura 34 ilustra um exemplo de descrição de interface constituída por uma janela 448 pixels de largura e 397 pixels de altura. Analisando ainda a mesma figura, conclui-se que a interface em questão é composta por três botões (linhas 22 a 26) e uma área de trabalho retangular (linhas 15 a 18). A listagem da figura 34 apresenta ainda informações relevantes para o aplicativo cliente, como o endereço IP do servidor e a porta utilizada para a comunicação (linhas 7 a 11).

74 73 Figura 34 - Exemplo de descrição de interface Tradutor de comandos O tradutor de comandos é uma parte fundamental do servidor. É ele que realiza a conexão com o cliente e recebe as requisições do mesmo através das mensagens do protocolo de comunicação. A cada mensagem recebida, o tradutor de comandos efetua as respectivas atividades contidas na mensagem. Existem basicamente dois tipos de mensagem: um para o envio de dados referentes aos dados de entrada da nova interface e outro para solicitar atualização de um determinado elemento. O tradutor de comandos simula os eventos do mouse e do teclado através de chamadas às funções de sistema. As mensagens provenientes do cliente contêm o identificador da seleção que representa o elemento no servidor. As mensagens contêm também informações que junto com as recuperadas da seleção permitem simular os dados de entrada como se o usuário estivesse em frente ao computador. A figura 35 ilustra o servidor aguardando mensagens do cliente.

75 74 Figura 35 - Servidor pronto para o recebimento de comandos 6.2 FUNCIONAMENTO DO SERVIDOR No computador onde está instalado o aplicativo que se deseja controlar deve ser executado o servidor. Se o aplicativo alvo já estiver em execução pode-se escolher de conectar o servidor ao mesmo. Caso contrário, existe a possibilidade de mandar executá-lo com um comando interno ao servidor, no qual o usuário deve indicar a localização do arquivo executável correspondente.

76 75 Analisador gráfico Tradutor de comandos Classificador Gerador de descrição Figura 36 - Funcionamento do servidor Uma vez conectado ao aplicativo alvo, o analisador gráfico localiza os elementos que compõem a interface. Na seqüência, os elementos encontrados são classificados pelo classificador, que também realiza o reconhecimento do texto presente nas imagens dos elementos. Nesse ponto é adicionado o gerador de descrição para produzir um arquivo texto com a descrição da interface em código XUL. O arquivo de descrição é utilizado pelo cliente para a reconstrução da interface, de modo a possibilitar a interação com o usuário. Para que isso seja possível, o tradutor de comandos converte os dados enviados pelo cliente em eventos de sistema que simulam o mouse e o teclado da máquina remota. O processo geral está representado na figura 36, enquanto que a tabela 3 resume as principais funções de cada componente do servidor.

77 76 Tabela 3 - Resumo das funções dos componentes do servidor Componente Analisador gráfico Classificador de elementos Gerador de descrição Tradutor de comandos Função Localização dos elementos de interface contidos na representação gráfica do aplicativo alvo. Classificação dos elementos encontrados pelo analisador gráfico através de técnicas de reconhecimento de padrões. Realiza também o reconhecimento do texto presente nos elementos. Produção de arquivos texto contendo as descrições das interfaces codificadas na linguagem XUL. Comunicação com o cliente, interpretação de comandos recebidos e realização das operações correspondentes na máquina remota. 6.3 ARQUITETURA DO CLIENTE O cliente do sistema GUIX é uma aplicação projetada para reconstruir interfaces a partir de descrições em código XUL contidas em arquivos de texto. Além disso, o cliente possibilita a interação do usuário com a aplicação remota através da interface reconstruída no dispositivo móvel. Enquanto utiliza o sistema, o usuário pode modificar dinamicamente a configuração da nova interface, por exemplo, mudando os elementos de lugar. A nova interface pode ter um número de elementos menor do que a interface original, pois, é possível escolher os elementos mais importantes. Um elemento particular de nova interface denominado workarea, corresponde à porção da interface do aplicativo remoto destinada à edição e à visualização dos dados. O cliente é composto por um módulo para a reconstrução da interface, um módulo para gerenciamento das reconstruções e um módulo para interação com o usuário. A figura 37 representa a arquitetura do aplicativo cliente.

78 77 GUIX Client Interface com o usuário Controle de modificações Reconstrução da interface Figura 37 - Arquitetura do cliente Reconstrução da interface A reconstrução da interface é realizada a partir do arquivo que contém a descrição da interface em código XUL. O cliente varre a descrição coletando informações necessárias para a reconstrução dos elementos que compõe a interface gráfica do aplicativo remoto. A leitura do código XUL é realizada através da tecnologia XML DOM. Essa tecnologia prevê o carregamento em memória da estrutura de dados em formato de árvore que representa o documento. A figura 38 ilustra um exemplo dessa estrutura após a leitura de um arquivo de descrição. Nessa figura os dados para a reconstrução da interface estão representados como elementos XML cada nó representa um elemento. Porém, alguns objetos representados na figura como elementos XML são implementados como atributos de outros elementos, devido às limitações já discutidas da linguagem XUL. Por exemplo, o elemento servidor é representado no código através do atributo id de um elemento groupbox, pois XUL representa apenas elementos de interface. O cliente procede com a leitura da árvore criada e cada vez que encontra um novo elemento instancia em memória um objeto que representa o elemento de interface.

79 78 window server workarea buttons ip porta caption image button1 button2 button3 Figura 38 - Estrutura em árvore resultante da leitura de uma descrição Modificações na interface reconstruída A interface reconstruída no dispositivo cliente pode ser modificada dinamicamente enquanto o usuário opera o sistema. Os elementos podem ser movidos para qualquer lugar da interface, mesmo para áreas não visíveis. Nesse caso, surgem barras de rolagem laterais para possibilitar o acesso a todos os elementos. Para mover um elemento, basta arrastá-lo de um ponto a outro. Além de mover os elementos, é possível excluí-los (figura 39). Para isso basta selecionar uma opção no menu de contexto do elemento, que aparece quando se segura a ponta da canetinha sobre um elemento por certo tempo. Na realidade os elementos não são excluídos definitivamente, pois è possível recuperá-los posteriormente. Através da opção de visualização de elementos removidos é possível escolher os elementos que serão exibidos novamente. Quando se escolhe essa opção, os elementos que foram eliminados em precedência aparecem com um símbolo em forma de x sobre os mesmos para diferenciá-los dos demais elementos. Para restaurar um elemento basta selecionar a opção apropriada no menu de contexto. Essas são apenas algumas possibilidades de modificações da interface. Outros tipos de modificações poderão ser incluídas em versões futuras do sistema. A interface reconstruída no dispositivo móvel independe de como é feita a interface original uma vez que realiza o mapeamento de comandos entre as duas interfaces. Além disso, os comandos provenientes da interface reconstruída são convertidos em eventos do mouse e do teclado da máquina remota em vez de comandos específicos da interface original.

80 79 Figura 39 - Visualização dos elementos excluídos na interface reconstruída A nova interface A interface reconstruída a partir da descrição em código XUL é composta por elementos correspondentes às seleções existentes no servidor no momento em que foi gerada a descrição, os quais podem ser modificados dinamicamente. Figura 40 - Interface reconstruída em um Pocket PC

81 80 Na aplicação cliente a interface é reconstruída utilizando-se os componentes disponibilizados pela plataforma Windows Mobile (Pocket PC). Desse modo, a interface reconstruída contém outros elementos além dos elementos originais: menu principal, teclado virtual (Soft Input Panel), reconhecedor de caracteres manuscritos, barra de título e botão para terminar a aplicação, como ilustra a figura PROTOCOLO DE COMUNICAÇÃO O protocolo de comunicação entre o cliente e o servidor é um protocolo desenvolvido para tornar possível o controle remoto de uma aplicação através de um dispositivo móvel com limitações de processamento, memória e forma de visualização. A cada requisição do cliente corresponde uma ação no servidor. Existem basicamente dois tipos de mensagens: no primeiro tipo as mensagens resultam no envio de imagens ao cliente e no segundo são tratadas as entradas realizadas pelo cliente por meio da nova interface. As mensagens deste último tipo provocam a geração de eventos no sistema operacional da máquina remota para a simulação do mouse e do teclado. As imagens enviadas ao cliente podem ter formatos diversos de acordo com a velocidade de transmissão e da qualidade da representação que se deseja na interface reconstruída. Atualmente a versão para pocket PC e smartphone suporta imagens no formato JPEG. Esse formato apresenta um bom compromisso entre a taxa de atualização da interface no cliente e a qualidade da representação gráfica da mesma. Como em geral os dispositivos móveis apresentam baixa resolução de vídeo, a compressão das imagens é quase imperceptível, proporcionando uma redução significativa na banda de transmissão. Por exemplo, uma imagem de um elemento de interface de dimensões de 320x240 pixels, em formato BMP, com 24 bits por pixel, ocupa aproximadamente 220KB, enquanto que a mesma imagem em formato JPEG ocupa somente 12KB. No projeto inicial as atualizações da interface reconstruída seriam feitas a cada mensagem enviada ao servidor. No entanto, como o tempo necessário para o aplicativo remoto atualizar a interface original em resposta aos eventos

82 81 encaminhados ao mesmo não é um tempo determinístico depende, por exemplo, do schedulling do sistema operacional ocorria freqüentemente da imagem enviada ao cliente não estar atualizado. Por esse motivo, decidiu-se utilizar um thread independente no cliente que periodicamente requisitasse a atualização dos elementos e aguardasse a resposta do servidor. Na tabela 4 estão resumidas as principais mensagens utilizadas na comunicação entre cliente e servidor durante o controle do aplicativo remoto através da interface reconstruída.

83 82 Tabela 4 - Principais mensagens da comunicação entre cliente e servidor Mensagem Formato (bytes) Descrição Refresh Click R F S H Id C L C K Id Solicita que o servidor envie ao cliente a imagem atualizada do elemento identificado pelo campo id. Solicita que o servidor simule um clique no hotspot (área sensível) do elemento identificado por id. Click At C K A T Id x y Solicita que o servidor simule um clique na posição (x,y) dentro da seleção identificada pelo campo id. Double-click At C K A T Id x y Solicita que o servidor simule um clique duplo na posição (x,y) dentro da seleção identificada pelo campo id. Keyboard K E Y B key Solicita que o servidor simule o pressionamento da tecla key do teclado. Escape Key E S C K Solicita que o servidor simule o pressionamento da tecla ESC. Finish F N S H Encerra a comunicação.

84 83 7 CLIENTE PARA DISPOSITIVOS MÓVEIS Com o objetivo de demonstrar a idéia da reconstrução de interfaces, foi desenvolvido um aplicativo cliente para pocket PC. A figura 41 ilustra o controle remoto do programa de modelagem 3D Blender. Mais tarde, durante a continuação do projeto, no Brasil, a versão desenvolvida para pocket PC sofreu alterações para funcionar em um smartphone, que apresenta maiores limitações quanto ao poder de processamento e características do display. Figura 41 - Aplicação cliente em execução no pocket PC

85 CLIENTE PARA SMARTPHONE Durante o desenvolvimento da primeira versão do sistema foi utilizado um pocket PC com sistema operacional Windows Mobile 2003, dotado de resolução de vídeo VGA (640x480 pixels). Durante a continuação do projeto na disciplina projeto de formatura II, foi escolhido como dispositivo móvel um smartphone com Windows Mobile 2005 e resolução QVGA (320x240 pixels). A utilização de um dispositivo com resolução mais baixa (figura 42) revelou novos problemas, mas permitiu detectar alguns pontos que poderiam ser melhorados para facilitar a interação com o usuário. Com um display de resolução maior é possível visualizar mais informações da interface original, o que significa ter um número maior de elementos visíveis ao mesmo tempo. Já no display de resolução mais baixa, o número de elementos visíveis é menor, o que traz a necessidade de mecanismos auxiliares, como a mudança da área de visualização. O conteúdo visualizado num dado instante pode ser mudado através das barras de rolagem. No entanto, tal mecanismo exige que o usuário desvie a atenção para posicionar a ponta da canetinha sobre a barra de rolagem, o que é ainda mais difícil em um display de dimensões reduzidas. Desta forma, tornase oportuno o emprego de outros mecanismos que exijam menos esforços por parte do usuário. Tais mecanismos foram incluídos através de melhorias no servidor e no cliente. Figura 42 - Comparação entre displays com resoluções diferentes

86 MELHORIAS NO SERVIDOR Durante a continuação do projeto, foram implementadas melhorias no aplicativo servidor com o intuito de aumentar a estabilidade do sistema durante o controle de um aplicativo remoto através do dispositivo móvel. Nesse sentido, foram implementados mecanismos de tratamento de exceções nos módulos correspondentes à conexão e à tradução dos comandos provenientes do programa cliente. Foi constatado, porém, que a instabilidade observada na primeira versão do sistema estava sendo causada por um defeito do dispositivo então utilizado e não por falha do sistema. Este fato foi comprovado quando se passou a utilizar o novo dispositivo móvel para a continuação do desenvolvimento, o qual não apresentou o mesmo problema (queda freqüente da conexão com o servidor), mesmo antes da introdução dos mecanismos de tratamento de exceções. Outra funcionalidade incluída no servidor permite eliminar a parte textual de botões que contenham ícone e texto (figura 43), reduzindo significativamente o tamanho dos botões que serão exibidos na interface reconstruída, pois, para cada botão será exibido apenas o ícone que indica a funcionalidade do mesmo, como mostra a figura 44. Embora seja um pouco mais difícil reconhecer o elemento, o prejuízo é muito menor em comparação ao ganho obtido através da economia de espaço, especialmente quando se utiliza um dispositivo de baixa resolução para hospedar o programa cliente. Figura 43 - Eliminação automática do texto das seleções dos botões Figura 44 - Ganho de espaço no programa cliente

87 MELHORIAS NO CLIENTE Ao executar o programa cliente no smartphone constatou-se a necessidade de novos mecanismos para lidar com o problema da baixa resolução do display. Quando se utilizava o pocket PC era possível obter uma boa área de visualização sem recorrer ao redimensionamento da representação gráfica da interface. Entretanto, com a diminuição da resolução, o número de elementos visíveis diminuiu e a porção da área de trabalho (workarea) exibida tornou-se muito pequena, prejudicando a interação com o usuário. Para minimizar tal problema foram incluídas as funções de zoom e pan no aplicativo cliente Recurso de zoom Através da utilização do recurso de zoom é possível aumentar ou diminuir a representação gráfica da interface, e conseqüentemente a área visualizada num dado instante. Apesar da diminuição do nível de detalhe quando se diminui o zoom, essa operação possibilita uma visão mais abrangente dos elementos. Desta forma, foi implementado o recurso de zoom out, isto é, diminuição da representação da interface com o objetivo de aumentar a área de visualização. Além disso, como o elemento workarea foi o mais afetado pela baixa resolução do dispositivo, o recurso de zoom foi desenvolvido especialmente para esse elemento, sendo o seu acionamento efetuado através de uma opção do menu de contexto (figura 45).

88 87 Figura 45 - Zoom do elemento workarea Recurso de pan A workarea ganhou também o recurso de pan, que pode ser acionado diretamente, bastando arrastar e soltar o elemento, da mesma forma como já ocorria com os botões. A grande vantagem é a praticidade em mudar a região visível, sem recorrer às barras de rolagem. O recurso de pan é ilustrado na figura 46. Figura 46 - Pan do elemento workarea

89 88 8 DIAGRAMAS DE CLASSES DO SISTEMA Nesta seção serão apresentadas as principais classes do sistema e os diagramas de classes correspondentes. 8.1 CLASSES DO SERVIDOR O servidor é composto por sete classes: GUIX, XServer, XAppManager, XSelManager, XSelList, XSelection, XBitmap. GUIX: classe que contém a janela principal do servidor. Possui referências para objetos das classes que realizam a análise da interface, a classificação de elementos, a conexão com o cliente e o controle remoto do aplicativo alvo. É também nesta classe que está localizado o código referente à criação dos arquivos de descrições com extensão.guix. XServer: classe que controla a conexão com o cliente. Contém referências para objetos das classes que realizam a análise da interface e o controle remoto do aplicativo alvo. XAppManager: classe que realiza todo o gerenciamento do aplicativo alvo, incluindo as capturas de tela e a varredura da interface através da movimentação do cursor do mouse. Um objeto desta classe representa o aplicativo alvo no sistema. Possui uma referência para um objeto da classe XBitmap que guarda a imagem da interface. XSelManager: classe que realiza o gerenciamento das seleções dos elementos de interface. Abrange a criação, modificação, eliminação e classificação das seleções, reconhecimento de caracteres e a geração da descrição do elemento. O objeto desta classe (único no sistema) possui uma referência para uma lista de seleções (objeto da classe XSelList) e quatro referências para objetos da classe XSelection, que representam a

90 89 seleção corrente, a área de trabalho, uma seleção temporária e a seleção para indicar a área de varredura da interface, no caso de varredura parcial. XSelList: classe que representa uma lista de referências a objetos da classe XSelection. É a classe que representa a estrutura de dados interna do sistema. XSelection: classe que representa um elemento de interface. Uma seleção é uma área retangular que delimita a região de um elemento na imagem da interface inteira, ou nas imagens escondidas dos menus e combo boxes. Contém uma referência para a imagem na qual delimita o elemento. Possui um campo de tipo para distinguir os elementos. Um elemento do tipo menu ou do tipo combo box pode conter uma lista (XSelList) de itens representados por outras seleções. XBitmap: classe que representa uma imagem bitmap e fornece funções para o processamento de imagens. A maior parte dos algoritmos de processamento de imagem está contida nos métodos desta classe. Um objeto desta classe pode ser usado para representar a imagem da interface inteira ou as imagens internas de menus e combo boxes. Desse modo, um objeto desta classe pode ser compartilhado por diversas seleções. O diagrama de classes correspondente às inter-relações das classes apenas descritas está ilustrado na figura 47.

91 90 XAppManager GUIX XServer dropdown XBitmap menu * XSelection 4 XSelManager menu * XSelList lista de sub-itens OBS: onde não indicado assume-se cardinalidade 1 Figura 47 - Diagrama de classes do servidor 8.2 CLASSES DO CLIENTE O cliente é composto por nove classes e uma interface. As classes são: GuixForm, GuixClient, GuixXML, GuixWorkArea, GuixButton, GuixMenu, GuixCombo, GuixSlider e GuixMath. A interface é a IGuixControl. GuixForm: classe que contém a janela principal do cliente, responsável pela interação com o usuário e pelas modificações dinâmicas na nova interface.

92 91 GuixClient: classe responsável pela conexão com o servidor, envio de comandos e recebimento de mensagens contendo informações para a atualização da interface. GuixXML: classe que realiza a reconstrução da interface de um programa a partir da descrição contida no arquivo com código XUL. GuixWorkArea: representa a área de trabalho do programa na nova interface. Possibilita a interação com o usuário através do dispositivo de apontamento utilizado (canetinha) e do teclado virtual disponibilizado pela plataforma. É a área onde são visualizados os resultados da interação com a aplicação remota. GuixButton, GuixMenu, GuixCombo e GuixSlider: representam as classes cujos objetos são instanciados durante o processo de reconstrução da interface no dispositivo móvel. GuixMath: fornece métodos estáticos para efetuar operações matemáticas. IGuixControl: interface que estabelece os métodos e as propriedades comuns a todos os elementos da nova interface, como workarea e botões. O diagrama de classes do aplicativo cliente é ilustrado na figura 48.

93 92 <<interface>> IGuixControl GuixMath GuixWorkArea GuixButton GuixMenu GuixCombo GuixSlider * * * * GuixXML GuixForm GuixClient OBS: onde não indicado assume-se cardinalidade 1 Figura 48 - Diagramas de classes do cliente

94 93 9 UTILIZAÇÃO DO SISTEMA Esta seção descreve as principais funções do sistema, desde a execução da aplicação remota na máquina do servidor à utilização da nova interface através do aplicativo cliente desenvolvido para pocket PC e smartphone. Uma das características do sistema é a divisão dos processos que o compõem em etapas separadas em vez de uma única operação disparada pelo usuário, o que permite que o mesmo acompanhe o andamento de cada processo, corrigindo eventuais erros de uma etapa antes de passar para a sucessiva. Na seção seguinte serão descritos todos os passos necessários para a produção da descrição da interface de um aplicativo. Em seguida, será explicado o que deve ser feito para que a interface seja reconstruída no cliente. Por fim, será discutido como controlar o aplicativo remoto através da nova interface. 9.1 UTILIZAÇÃO DO SERVIDOR O servidor é um aplicativo que possibilita a produção da descrição da interface de um aplicativo em código XUL. Na seqüência serão descritos os passos necessários para gerar e armazenar a descrição em um arquivo de texto. 1. Antes de tudo deve-se iniciar o aplicativo servidor com um clique duplo no ícone do programa. Figura 49 - Ícone do servidor 2. Na tela inicial do servidor, um clique faz aparecer o menu de contexto (figura 50) no qual pode-se escolher abrir um projeto existente, criar um novo projeto, ou criar um novo projeto com base em um aplicativo já em execução. Esta última opção deve ser escolhida se o usuário já tiver colocado em execução o aplicativo alvo. Apesar disso, esta é a opção mais simples, porque a criação

95 de um projeto do zero requer que o usuário indique o caminho do executável no sistema de arquivos. 94 Figura 50 - Tela inicial do servidor 3. Escolhendo a opção New from running é solicitado ao usuário de clicar na barra de título do aplicativo alvo, para que o servidor se conecte ao mesmo. Figura 51 - Caixa de diálogo da opção New from running 4. Nesse exemplo foi escolhido o Windows Explorer que estava em execução, através do clique na barra de título conforme indicado na mensagem anterior. O servidor então captura a janela do aplicativo e inicia um novo projeto.

96 95 Figura 52 - Janela principal do servidor após a captura de tela do aplicativo alvo 5. Através das funcionalidades do servidor é possível selecionar manualmente os elementos, atribuir um tipo e adicionar um rótulo. Apesar da possibilidade de fazer o trabalho manualmente, a única coisa que deve ser feita desse modo é a seleção da área de trabalho (workarea), pois o restante o sistema se encarrega de fazer automaticamente. Para selecionar a workarea basta escolher a opção correspondente no menu de contexto, que surge sempre que se clica com o botão direito do mouse em uma área vazia da tela, e selecionar a região correspondente na imagem que representa a interface.

97 96 Figura 53 - Adicionar seleção da workarea Figura 54 - Seleção da workarea 6. O próximo passo é a varredura da interface (figura 55 e figura 56) para encontrar os elementos de interação com o usuário e gerar as seleções automaticamente. Pode-se escolher a varredura parcial ou total. No primeiro caso será solicitado ao usuário de indicar a região que deseja analisar. No outro, a interface é analisada por completo, levando mais tempo para o término do processo.

98 97 Figura 55 - Varredura da interface Figura 56 - Resultado da análise 7. Depois da análise prossegue-se com a classificação dos elementos. É possível classificar um elemento por vez, ou todos de uma vez só. A primeira opção está disponível no menu de contexto que aparece quando se clica com o botão direito sobre uma seleção e a outra quando o clique é feito em uma área vazia.

99 98 Figura 57 - Classificação dos elementos Figura 58 - Resultado da classificação 8. Os elementos não classificados podem receber um tipo manualmente ou, se não forem importantes, podem ser eliminados. Ambas as opções estão disponíveis no menu de contexto do elemento (clique com botão direito). 9. Depois da classificação passa-se à varredura dos menus e dos elementos do tipo combo box. Nesse caso também é possível efetuar a operação elemento por elemento ou todos de uma vez.

100 99 Figura 59 - Descoberta dos itens dos menus Figura 60 - Resultado da varredura dos menus 10. Para incluir os títulos dos menus e dos itens encontrados pode-se escolher a opção relativa ao reconhecimento automático de caracteres (OCR) no menu de contexto. Na janela de propriedades da seleção representada na figura 62 é possível visualizar texto reconhecido automaticamente.

101 100 Figura 61 - Reconhecimento de caracteres Figura 62 - Propriedades da seleção exibindo o texto reconhecido 11. Nesse momento é possível gerar a descrição da interface e salvá-la em um arquivo de texto (figura 63). O arquivo pode ter extensão.xml ou.xul. Esta última permite que o arquivo seja aberto no navegador Mozilla Firefox, o qual pode ser usado para visualizar o resultado obtido.

102 101 Figura 63 - Geração da descrição em XML Figura 64 - Visualização do resultado no navegador web Salvando o projeto O projeto pode ser armazenado em um arquivo para utilização futura. A opção de salvar o projeto está contida no menu de contexto que aparece quando se clica com o botão direito em uma área vazia. Essa opção cria um arquivo com extensão.guix no local indicado. Se o projeto foi criado a partir de um programa em execução, o mesmo também deve estar em execução no momento da reabertura do arquivo de projeto.

103 Configurações personalizadas O servidor permite que sejam configurados os parâmetros referentes à varredura da interface, à classificação dos elementos e à conexão com o cliente. Em seguida serão enumeradas as opções disponíveis em cada caso Configuração da varredura da interface A figura 65 mostra a tela de configuração dos parâmetros de varredura, descritos nas tabelas seguintes. Figura 65 - Configuração dos parâmetros de varredura da interface

104 103 Tabela 5 - Parâmetros de varredura Parâmetro Min selection width Min selection height Max selection width Max selection height Cursor move tolerance Descrição Largura mínima que uma seleção pode apresentar. Se o objeto encontrado possuir largura menor do que esta o mesmo é descartado. Altura mínima que uma seleção pode apresentar. Se o objeto encontrado possuir altura menor do que esta o mesmo é descartado. Largura máxima que uma seleção pode apresentar. Se o objeto encontrado possuir largura maior do que esta o mesmo é descartado. Altura máxima que uma seleção pode apresentar. Se o objeto encontrado possuir altura maior do que esta o mesmo é descartado. Tolerância máxima de movimentação do cursor sem interromper a varredura. Evita que a varredura seja interrompida acidentalmente. Selection initial margin Margens adicionadas à seleção logo após a sua criação. Max number of elements Time for displaying app Número máximo de elementos a procurar. Quando se atinge esse valor a varredura da interface é interrompida. Tempo que o sistema deve esperar antes de começar a varredura para que o aplicativo alvo possa desenhar sua interface.

105 104 Tabela 6 - Parâmetros da varredura parcial e da varredura completa Parâmetro Scan interval Horizontal step Vertical step Descrição Período de tempo entre uma amostra e outra. Se muito pequeno, o aplicativo alvo pode não ter tempo suficiente para efetuar o highlighting do elemento sob o cursor. Passo horizontal do deslocamento do cursor durante a varredura. Passo vertical do deslocamento do cursor durante a varredura. Tabela 7 - Parâmetros da varredura dos itens de menu e combo box Parâmetro Scan interval Time for dropping Time for retracting Vertical step Recognize text Scan upward menus Descrição Período de tempo entre uma amostra e outra. Se muito pequeno, o aplicativo alvo pode não ter tempo suficiente para efetuar o highlighting do elemento sob o cursor. Tempo que o sistema deve esperar para que a imagem do menu ou combo box apareça antes de começar a varredura. Tempo que o sistema deve esperar para que a imagem do menu ou combo box desapareça antes de passar para o próximo elemento. Passo vertical do deslocamento do cursor durante a varredura dos itens de menu ou combo box. Define se o sistema deve realizar o reconhecimento automático do texto presente nos itens de menu ou combo box durante a varredura. Define se deve ser feita a varredura de menus cuja imagem interna aparece acima do menu.

106 Configuração da classificação dos elementos Na figura 66 é representada a tela de configuração dos parâmetros referentes ao processo de classificação dos elementos, descritos nas tabelas seguintes. Figura 66 - Configuração dos parâmetros de classificação Tabela 8 - Parâmetros de classificação Parâmetro Background color tolerance Selection internal margins Descrição Valor de tolerância para a cor de fundo de um elemento. Dimensões da margem interna das seleções em pixels. Icon width Largura aproximada dos ícones presentes nas imagens dos elementos em pixels. Space between arrow and text or icon Mínimo espaço entre símbolos (ícones, setas, etc) e texto nas imagens dos elementos.

107 106 Parâmetro Descrição Number of icons inside a control Número de ícones normalmente presentes nas imagens dos elementos. Menu item min number of letters Número mínimo de letras em um texto reconhecido na imagem de um menu ou um item de menu Configuração da conexão com o aplicativo cliente Na figura 67 é representada a tela de configuração dos parâmetros de conexão com o aplicativo cliente, descritos na tabela na seqüência. Figura 67 - Configuração dos parâmetros de conexão Tabela 9.1 Parâmetros de conexão Parâmetro IP Address Port number Descrição Endereço IP do servidor utilizado para a conexão. São listados todos os endereços, se houver mais de um, disponíveis na máquina que hospeda o servidor. Número da porta utilizada pela conexão TCP.

108 UTILIZAÇÃO DO CLIENTE O aplicativo cliente é muito mais fácil de ser utilizado do que o servidor. O único esforço necessário é que o arquivo contendo a descrição da interface seja copiado para o dispositivo móvel. Quando se inicia o cliente, surge uma janela com um menu no canto inferior direito (menu GUIX) contendo as principais funções do sistema, como abrir um arquivo de descrição como texto e reconstruir a interface descrita em um arquivo com extensão.xml. A figura 68 ilustra a janela principal do cliente. Figura 68 - Janela principal do cliente Além do menu principal, cada elemento da interface reconstruída possui um menu de contexto específico (figura 69). As opções comuns a todos os elementos permitem atualizar ou eliminar o elemento. É possível também recuperar um elemento eliminado em precedência escolhendo a opção de visualização de elementos removidos no menu principal e em seguida a opção de restaurar no menu de contexto do elemento.

109 108 Figura 69 - Visualização dos elementos removidos 9.3 CONEXÃO E CONTROLE REMOTO Para tornar possível a conexão entre cliente e servidor é necessário configurar os parâmetros de conexão e ativar o servidor para que fique a espera do pedido de conexão do cliente. Quando o servidor é colocado no estado de espera de conexão (figura 70), a janela principal do programa é minimizada e surge um ícone na área de notificação (system tray) do Windows, como mostra a figura 72. Através desse ícone é possível interromper o servidor e restaurar a janela principal do programa. No cliente é necessário abrir o arquivo contendo a descrição da interface, verificar se os parâmetros de conexão (IP e porta) estão corretos e clicar no botão de conectar (figura 72). Se a conexão é bem sucedida, a interface reconstruída é atualizada, ficando pronta para a interação com o usuário.

110 109 Figura 70 - Opção do menu de contexto global para ativar o servidor Figura 71 - Ícone do GUIX na área de notificação do Windows Figura 72 - Tela de conexão no cliente

111 RESULTADOS Nesta seção serão analisados os resultados obtidos no presente trabalho referentes às diversas fases do projeto: análise da interface de um aplicativo, classificação dos elementos de interface, reconhecimento de texto, produção e armazenamento da descrição da interface codificada em linguagem UIDL, reconstrução da interface nos dispositivos móveis e controle do aplicativo remoto através da interface reconstruída ANÁLISE DAS INTERFACES O processo de análise de uma interface depende dos parâmetros de varredura, como o passo horizontal, passo vertical e intervalo de amostragem. Uma varredura com maior previsão requer passos menores e intervalo de amostragem maior. Para não obrigar o usuário a configurar esses parâmetros toda vez que deva analisar uma nova interface, foram determinados valores padrões para os mesmos com base em experimentos realizados com várias interfaces, desde a interface da calculadora do Windows até a interface do programa de modelagem 3D Blender. A figura 73 ilustra o resultado da varredura da interface do Blender com os parâmetros padrões. A partir da figura é possível concluir que foi identificada a maior parte dos elementos: 54 de um total de 67 elementos (81%). Os elementos não encontrados são na maior parte aqueles que não possuem o recurso de highlighting, como os painéis retráteis e os elementos inativos, botões já pressionados, por exemplo. Outro elemento na interface do Blender que causa problemas na classificação é o elemento usado para retrair os menus. Trata-se de um elemento representado por um único símbolo em forma de seta para baixo (ao lado dos menus View e Panels na figura) que quando pressionado recolhe os itens de menu localizados na mesma barra escondendo-os. O problema é que o highlighting desse elemento é diferente dos demais, pois uma vez que o cursor passa sobre ele, o mesmo permanece destacado até que o cursor saia da barra de menus. Isso faz com que mais de um elemento sejam destacados ao mesmo tempo, interferindo o algoritmo da diferença de imagens.

112 Apesar desses problemas, o sistema permite que o usuário corrija manualmente eventuais erros na análise. 111 Figura 73 - Resultado da análise da interface do Blender A análise dos menus e dos elementos do tipo combo box também depende de parâmetros específicos. Além dos parâmetros discutidos anteriormente, este segundo nível de varredura depende do tempo necessário para que o aplicativo alvo desenhe a imagem interna de um menu e do tempo que essa imagem leva para desaparecer para que o próximo menu seja analisado. Se o primeiro tempo é muito curto, corre-se o risco de capturar a imagem da interface antes que seja desenhada a imagem interna do menu. Caso contrário, o cursor pode ficar sobre um menu por muito tempo, fazendo com que apareçam caixas com dicas dos comandos (hints), comprometendo o processo de análise. O intervalo de amostragem também é muito importante. Em algumas interfaces, se o intervalo for muito curto, pode acontecer de dois elementos estarem destacados ao mesmo tempo, pois pode não dar tempo do primeiro ser redesenhado depois que o mouse passa para o outro.

113 112 Nos exemplos a seguir foram utilizados os parâmetros padrões. A partir da análise dos resultados dos exemplos apresentados é possível concluir que o sistema é capaz de reconhecer os itens de menu e combo box de maneira satisfatória. Figura 74 - Resultado da análise dos menus do Windows Explorer Figura 75 - Resultado da análise dos menus do Blender