As estratégias que compõem o arcabouço RFCore (Seção 3.2) podem variar amplamente em complexidade e tamanho. Em geral, uma estratégia pode possuir uma implementação arbitrariamente complexa, ou até mesmo em alguns casos ser tão simples que beira ao trivial. Por exemplo, uma implementação simples do módulo de seleção do conjunto de objetos pode apenas selecionar as 20 primeiras imagens da coleção reordenada para apresentar ao usuário. Alternativamente, essa estratégia pode incorporar algum algoritmo sofisticado de diversificação, para que o usuário não visualize muitas imagens semelhantes nas primeiras posições do rank.
Normalmente, a estratégia de interface gráfica com o usuário acaba fugindo a essa regra e apresentando uma complexidade maior em termos de projeto, custo e tempo de desenvolvimento. Por mais simples que seja uma interface de um sistema de recuperação de imagens, ela ainda precisa executar algumas tarefas trabalhosas tais como: leitura e exibição dos arquivos de imagem, tratamento dos eventos de usuário, gerenciamento de threads, indicação de imagens relevantes, dentre outros. Por outro lado, embora seja uma estratégia fundamental por permitir ao usuário interagir com o sistema e visualizar os resultados, essa estratégia não necessariamente está diretamente ligada aos métodos de recuperação de imagens, que são o foco do framework. Dessa forma, não é desejável que o pesquisador precise despender muito tempo e esforço para construir sua própria interface.
Uma solução para esse problema é fornecer uma estratégia padronizada que todos os pesquisadores pudessem usar para visualizar seus resultados, sem precisarem obrigatoriamente implementar uma nova interface. Um aspecto inconveniente dessa abordagem é forçar o pesquisador a utilizar um mecanismo de visualização fixa, com um layout único. Como foi descrito na Seção 2.3, os sistemas de CBIR apresentam seus resultados em layouts diversos. Alguns, por exemplo, priorizam totalmente a visualização das imagens retornadas pelo sistema, enquanto outros dão igual destaque às imagens selecionadas como consulta.
Diante desse cenário, neste trabalho foi proposta a especificação de um framework simples para a construção de interfaces de recuperação de imagens para sistemas que utilizam
Figura 11 - Três layouts possíveis para interfaces de realimentação de relevância.
Fonte: próprio autor.
realimentação de relevância. O objetivo é que um pesquisador possa programar uma nova interface com o mínimo de esforço, focando apenas nos aspectos visuais, reaproveitando toda a infraestrutura básica necessária. No contexto do RFCore, esse framework corresponde a uma implementação genérica para a estratégia de interface com o usuário, que deve ser extendida pelo programador para especificar os seus aspectos visuais. O restante desse capítulo descreve a especificação desse framework, que foi implementado e utilizado para a construção da interface do protótipo apresentado na Seção 5.2.
O framework de interface parte do princípio de que a interface de um sistema de realimentação de relevância possui três áreas principais ou containers: um container para apresentar as imagens selecionadas como consulta, um container para apresentar as imagens selecionadas como relevantes, e um container para apresentar os resultados da busca no sistema. A forma como esses containers são organizados na tela e a sua aparência específica não importam, ficando a cargo do usuário programador. A Figura 11 apresenta três exemplos de layouts possíveis para uma interface de RR.
O framework permite que o programador possa se utilizar de metadados para sinalizar quais componentes de interface no seu código fonte devem ser considerados como containers. Geralmente, os componentes do tipo “painel” são propícios para essa função, por agruparem outros componentes de interface. O programador também deve informar quais componentes se comportam como “gatilhos”, ou seja, componentes que sinalizam ao sistema que as imagens de consulta ou as imagens relevantes já foram selecionadas e que o RFCore deve
proceder para o próximo ciclo de realimentação de relevância. Botões e ícones geralmente são adequados para essa função.
No ambiente Java, um mecanismo conveniente para marcação de código fonte com metadados é a utilização de annotations. No framework proposto, os containers devem ser objetos do tipo JPanel, enquanto os gatilhos devem ser objetos do tipo JButton. Os objetos sinalizados devem necessariamente ser atributos (variáveis de instância) de uma classe que extenda a classe principal do framework, a RFGUIFramework. O seguinte conjunto de annotations é disponibilizado para o programador:
1 - @QueryContainer – sinaliza o atributo JPanel que exibirá as imagens de consulta. 2 - @RelevantContainer – sinaliza o atributo JPanel que exibirá as imagens relevantes. 3 - @OutputContainer – sinaliza o atributo JPanel que exibirá as imagens da coleção. 4 - @QueryTrigger – sinaliza o atributo JButton que dispara a primeira consulta.
5 - @RelevantTrigger – sinaliza o atributo JButton que dispara uma iteração de realimentação de relevancia.
6 - @SatisfiedTrigger – sinaliza o atributo JButton que finaliza as iterações de realimentação de relevância.
A Figura 12 apresenta o trecho de exemplo de uma classe Java que utiliza as annotations descritas. Os objetos declarados podem ser utilizados de maneira arbitrária na construção da interface gráfica, combinando com outros componentes e definindo o layout desejado. O framework acessa os objetos anotados por meio de reflexão e realiza a comunicação necessária entre eles. As imagens da coleção são automaticamente carregadas no painel outputContainer e o usuário poderá selecionar as imagens de consulta ao clicar sobre elas. Cada imagem selecionada é automaticamente adicionada ao painel queryContainer. O botão queryButton aciona a consulta inicial, e as imagens do resultado são adicionadas ao painel outputContainer. O usuário seleciona as imagens relevantes ao clicar sobre elas, e o framework adiciona essas imagens ao painel relevantContainer. O usuário submete as imagens ao sistema clicando no botão relevantButton, e o framework exibe o novo resultado no painel outputContainer. Por fim, o usuário finaliza o processo ao clicar no botão finishButton. Toda essa comunicação é gerenciada pelo framework e não precisa ser
Figura 12 - Exemplo de código Java utilizando as annotations do famework de interface gráfica.
Fonte: próprio autor.
codificada pelo programador da interface, que apenas se preocupa em montar os componentes na tela e desenvolver a sua aparência interna.
A Seção 5.1.2 apresenta uma modelagem de classes para implementação do framework descrito. Uma implementação padrão da interface é disponibilizada no prototipo desenvolvido neste trabalho que é apresentado na Seção 5.2.
5 RESULTADOS
Esse capítulo descreve os resultados obtidos no desenvolvimento deste trabalho. Foram gerados três artefatos de software: o documento de requisitos da plataforma (Anexo A), construído com base no estudo de usabilidade das ferramentas apresentadas na Seção 2.3 e na proposta apresentada no Capítulo 4; a modelagem de classes dos principais módulos da plataforma; e o código-fonte (implementação). As seções 5.1 e 5.2 descrevem respectivamente a modelagem e o protótipo desenvolvido.