\chapter{TECNOLOGIAS AVALIADAS}

Em várias partes do projeto nos apoiamos em tecnologias já existentes com o intuito de obter mais agilidade no desenvolvimento e maior qualidade no trabalho final obtido, procurando aproveitar as soluções já existentes para resolver principalmente os problemas mais periféricos do nosso sistema, isto é, os que não são relacionados diretamente com os algoritmos de tradução. 

Nesta seção descrevemos as tecnologias que foram analisadas nesse contexto, sendo algumas delas selecionadas e por nós utilizada.

\section{Analisadores morfológicos}

Foram levantados possíveis analisadores morfológicos para a língua portuguesa, para que servissem de base a alguma implementação de analisador morfológico que satisfizesse à interface levantada, a qual lida das relações entre os analisadores sintático e morfológico.

Os dois analisadores avaliados foram o MXPOST e o JSpell. Estudou-se a complitude das informações fornecidas por cada um e o grau de facilidade prevista para integração com os demais módulos do projeto. As conclusões foram:



\subsection*{MXPOST}

A bem de verdade, menos que um analisador morfológico, MXPOST é um programa rotulador (\emph{tagger}), ou seja, ele aplica rótulos às palavras que lhe são apresentadas; isso, com base num conjunto de dados de treinamento que lhe proveram uma aprendizagem supervisionada. Utilizando o trabalho "NILC's Taggers"\footnotemark, no qual pesquisadores aplicaram ao MXPOST um treinamento de rótulos morfológicos anexos a textos em português, pode-se utilizar o programa para se descobrirem as classes morfológicas de palavras na língua portuguesa.

\footnotetext{NILC's Taggers. Disponível em: \url{<http://www.nilc.icmc.usp.br/nilc/tools/nilctaggers.html>}. Acesso em 05/12/2010}

O MXPOST apresentou resultados com alto índice de acerto nos testes realizados. Um exemplo de par entrada/saída do MXPOST treinado:

Entrada: Os carros vermelhos bateu no poste.

Saída: Os\_ART carros\_N vermelhos\_ADJ bateu\_VERB no\_PREP+ART poste\_N

No entanto, o MXPOST apresenta algumas limitações que nos levaram a preteri-lo. Em primeiro lugar, não seria fácil usá-lo como biblioteca: as classes existentes tinham nomes pouco intuitivos e não encontramos documentação, além dele também não ser \emph{open-source} e, portanto, não se poder ver seu código-fonte em Java. Além disso, as informações apresentadas pelo programa são limitadas e podem ser insuficientes, pois ele só retorna a classe morfológica: não retorna gênero, número, nem tempo verbal e transistividade para os verbos

\subsection*{JSpell}

Outra alternativa encontrada foi o JSpell\footnotemark. Este é um analisador morfológico de código aberto, que apresenta maiores possibilidades e informações em sua saída. 

\footnotetext{JSpell. Disponível em: \url{<http://natura.di.uminho.pt/wiki/doku.php?id=ferramentas:jspell>}. Acesso em 05/12/2010.}

Por exemplo: dado um lexema de entrada, caso a ele correspondam mais de uma interpretação, todas são apresentadas. Ainda, caso não haja derivação própria para o lexema (ou seja, ele é uma palavra desconhecida do JSpell), é retornado um conjunto de possíveis soluções. No idioma inglês, essas soluções para sequências de letras aproximadas são chamadas de \emph{near misses}, e é assim como o JSpell as designa; durante o projeto descrito neste documento, contudo, pela natureza da informação representada, trataram-se as como "soluções aproximadas".

O exemplo acima mostra quanto o JSpell é completo para obtenções sobre o universo ao redor dum lexema, mas não diz nada sobre como o lexema em si é descrito pela ferramenta. Segue uma explicação: para cada possível interpretação, seja para o exato lexema, seja referente a soluções aproximadas, é informada a forma de dicionário da palavra, sua categoria{EXEMPLOS..ou link p descrição} e informações pertinentes à categoria (\emph{e.g.}: para verbos, uma informação pertinente seria, o número, a pessoa, \emph{etc}; já para substantivos, o gênero, \emph{etc}).

O único porém dele é que foi feito para português de Portugal. Uma grande vantagem do JSpell é uma saída com muito mais informações:

\begin{itemize}
  \item Se existe dúvida ou várias possibilidades para uma mesma palavra, ele mostra todas as opções; 
  \item Gênero e número;
  \item Tempo verbal;
  \item Identificação dos sufixos e prefixos das palavras compostas
\end{itemize}

\section{Ferramentas gráficas}

Para implementar o sintetizador de sinais é fundamental o uso de tecnologias de computação gráfica, sendo essas ferramentas divididas principalmente em duas categorias: \emph{ferramentas de modelagem} que geram os modelos tridimensionais e \emph{APIs} que manipulam esses modelos em tempo de execução.

A seguir uma listagem das ferramentas pesquisadas e consideradas neste processo, incluindo ferramentas que se enquadram em uma das duas categorias ou até mesmo em ambas.

\subsection*{Flash}

Num primeiro momento considerou-se a possibilidade de seu uso por ser uma tecnologia amplamente difundida, tanto entre usuários quanto entre desenvolvedores e até por observarmos soluções de tradução de \libras~\cite{falibras} usando Flash.

No entanto, sendo o uso do Flash mais adequado para o 2D, observou-se que embora pudesse ser relativamente fácil criar uma animação de um avatar falando \libras, seria extremamente complexo criar um modelo com as unidades morfológicas segmentadas de forma que pudessem ser sintetizadas e integradas em tempo de execução; para este tipo de tarefa modelos 3D se mostram bem mais adequados.

\subsection*{Blender}

Blender é uma suíte de criação de conteúdo 3D \emph{open source}, disponível sob a \emph{GNU General Public License} (GPL) para os principais sistemas operacionais.

Além de permitir a modelagem de objetos 3D, contém também uma \emph{game engine} embutida que permite a manipulação desses objetos em tempo real, inclusive com o uso de scripts na linguagem Python (o que equivale ao que definimos ferramentas gráfiicas do tipo API).

Neste aspecto, um dos mais recentes feitos na ferramenta foi a produção de um jogo, o \emph{Yo Frankie!}, disponível para download, incluindo os arquivos de projeto do Blender.

O site da ferramenta conta com uma farta documentação, de modo que iniciamos o aprendizado através de seus tutorial no wiki do site~\footnotemark. Além disso o grupo realizou a aquisição do livro \emph{Mastering Blender} \cite{blender}, que discutia com mais profundidade questões ligadas à game engine, uma vez que a comunidade de usuário em geral encontra-se mais voltada para o uso do Blender como modelador 3D.

\footnotetext{Blender Wiki. Disponível em: \url{<http://wiki.blender.org/>}. Acesso em 05/12/2010}

Seguindo essas fontes chegamos a construir uma animação de uma mão, sendo construída com base em um modelo de mão baixado da Internet; o modelo continha apenas a "pele" e nós criamos a estrutura de armadura (\emph{bones}) para o modelo e com a manipulação da armadura gerou-se o vídeo com a animação.

\begin{figure}[h]
  \centering
  \includegraphics[scale=0.3]{imagens/mao_blender.png}
  \caption{Exemplo de tela do Blender}
  \label{fig:blender}
\end{figure}

Uma desvantagem do uso do Blender é que parece não haver nenhuma forma de integrar o resultado em um ambiente como a \emph{web} ou mesmo gerar uma aplicação \emph{stand alone} sem que o usuário possua o próprio Blender instalado em sua máquina. 

Outra suposta desvantagem seria a alta curva de aprendizagem do Blender, característica pela qual é famoso. Mostra disso é que a própria comunidade reconhece que o Blender não foi projetado para ser fácil ou intuitivo, mas sim para ser uma ferramenta de alta produtividade tão logo o usuário a domine. No entanto em nossa experiência com o ambiente, essa dificuldade acabou sendo bem menor do que a esperada devida a essa impressão geral.

\subsection*{Processing}

Consiste em uma API \emph{open source} em Java para geração de aplicações interativas em 3D mais simples, de uso geralmente didático, que permite a manipulação direta de modelos no formato texto OBJ, suportado por praticamente todas as ferramentas modelagem 3D.

Sua principal vantagem é a facilidade de aprendizado, mas apresenta graves restrições, como a impossibilidade de lidar com modelos que apresentem \emph{bones}, que são usados para criar vínculos e restrições de movimentos entre partes do modelo a ser animado; de forma geral pode-se dizer que não é indicado para manipulação de personagens animados, embora suficiente e prático para outras aplicações gráficas, como \emph{puzzles} por exemplo.

Outra vantagem é que a aplicação resultante é na verdade um Applet, ou seja, uma aplicação Java integrável com navegadores web.

\subsection*{Panda3D}

Assim como o Processing, o Panda3D também é uma API \emph{open source} para manipulação em tempo de execução de modelos gráficos.

Seu diferencial é que esta é uma ferramenta profissional, tendo sido desenvolvida e utilizada pela Disney e pela Carnegie Mellon University's Entertainment Technology Center.

Uma das principais vantagens do Panda3D sobre o Processing é a possibilidade de lidar com o conceito de \emph{bones} em tempo de execução.

Embora tenha uma base bem reduzida de usuário, sua comunidade de desenvolvedores se mostrou bem aberta a novatos, prestando um auxílio bem amigável aos que desejam dominar a tecnologia, ao contrário do que tipicamente acontece na comunidade do Blender, que prefere prezar pela vasta documentação.

Também apresenta vantagem sobre à \emph{game enngine} do Blender, que não possui uma documentação tão vasta em comparação com o total de documentação da aplicação como um todo e também pelo fato de \emph{game engine} do Blender ser a parte mais imatura da ferramenta.

Mas como o Processing é apenas a API ainda seria preciso de uma ferramenta de modelagem, de forma que uma boa combinação seria a do Panda3D como API e do Blender como ferramenta de modelagem.

\subsection*{3DStudio}

Assim como o Blender, é também um ambiente de modelagem 3D. A principal diferença é o fato de o 3DStudio ser uma ferramenta proprietária e cara, mas, ao mesmo tempo, possuir uma penetração bem maior no mercado.

Tanto o Blender quando o 3DStudio podem gerar modelos compatíveis com o Processing e o Panda3D.

\subsection*{Comparação}

Na tabela abaixo resumimos as principais características das ferramentas de computação gráfica consideradas.

\begin{table}[h]
       \centering
       \caption{Comparação entre tecnologias de computação gráfica}
       \label{table:tabela_comp_grafica}
       \begin{tabular}{|l|l|l|l|l|l|}
               \hline% horizontal line
                       \itshape &
                       \itshape Flash&
                       \itshape Blender&
                       \itshape Processing&
                       \itshape Panda3D&
                       \itshape 3DStudio \\*
               \hline
               Modelagem& Sim (2D)& Sim& Não& Não& Sim\\
               API& Sim& Sim& Sim& Sim (a melhor)& Não\\
               Base de usuários& Grande& Média& Pequena& Pequena& Grande\\
               Documentação& Ampla& Ampla& Pequena& Média& ?\\
               Linguagem& Action Script& Python& Java& C++ / Python& -\\
               Integração web& Sim& Não& Sim& Sim& -\\
               Curva de aprendizado& Média& Grande& Pequena& Média& ?\\
               Open source& Não& Sim& Sim& Sim& Não\\
               \hline
       \end{tabular}
\end{table}

Obs1: considerando as linguagens da tabela, a que seria mais vantajosa para nós seria Java, por já possuirmos um domínio maior e pelo resto do projeto ser em Java;

Obs2: não listada na tabela, mas lembrando que o Panda3D ainda apresenta a vantagem adicional da cordialidade de sua comunidade.

Com essa análise, concluímos que a princípio a melhor combinação seria o uso do Blender para modelagem e a do Panda3D para a API; no entanto, por motivos que serão explicados na seção que trata da implementação do sistema, já adiantamos que a combinação escolhida foi a do 3DStudio para a modelagem e a do Processing para a API.

\section{Frameworks web}

Para o desenvolvimento das módulos web estudamos tecnologias que poderiam ser usadas e nos proporcionar um ganho de produtividade, evitando a perda de tempo com a escrita de código repetitivo, o chamdo \emph{boilerplate code}, seja na construção de interfaces e no gerenciamento de navegação entre páginas, quanto na automatização do mapeamento objeto-relacional para armazenar as informações em bancos de dados.

\subsection*{Java EE - Servlets}

Java EE (ou J2EE, ou Java 2 Enterprise Edition, ou em português Java Edição Empresarial) é uma plataforma de programação para servidores na linguagem de programação Java.

A tecnologia básica para processamento das requisições na plataforma Java EE são os \emph{servlets}, enquanto que a interface é gerada principalmente pelas \emph{JSP} (Java Server Pages). 

Os servlets são basicamente classes definidas pelo programador que realiza o processamento da execução web e gera a página HTML de resposta, ou mais adequadamente, seta parâmetros e encaminha a requisição para uma página JSP que é mais apropriada para o \emph{design} da interface. A parte do sistema que gerencia o ciclo de vida dos servlets e lhes encaminham as requisições chegadas ao servidor é denominada \emph{container}, sendo as implementações open source mais conhecidas o \emph{Tomcat} e o \emph{Glassfish}. 

Em geral, os frameworks mais avançadas para Java / web são baseados na tecnologia de servlets.

Em nosso trabalho primeiramente estudamos extensivamente essas tecnologias através de um livro \cite{javaee} e iniciamos a implementação com base nele.

No entanto, percebemos que seu uso demandava códigos extensivos e repetidos para tratar a navegação além de fazer o mapeamento entre os parâmetros da requisição e os objetos.

Portanto decidimos verificar a possibilidade de usar frameworks mais avançados.

\subsection*{Struts}

Struts foi um dos primeiros frameworks para Java EE, implementando uma camada controladora, de acordo com o modelo MVC de aplicações web, simplificando o uso de servlets, necessitando apenas a criação de classes Action

Este framework foi originalmente desenvolvido por Craig McClanahan e doado para a Apache Software Foundation em 2002, onde continua sendo desenvolvido segundo o padrão desta fundação.

\subsection*{JBoss Seam}

É um framework mais avançado desenvolvido pela Red Hat, fazendo parte do bastante utilizado servidor de aplicações JBoss, que consiste em uma plataforma que engloba o container e mais outras facilidades para os desenvolvedores criarem aplicações Java de servidor.

A ideia do framework consiste basicamente em criar uma forma fácil de unir (daí o nome) as tecnologias de componentes EJB (lógica do negócio) e as interfaces JSF (uma "evolução" do JSP). Também oferece componentes que facilitam em muito a criação de CRUD's (formulários para criação, edição, atualização e remoção de entidades do banco de dados).

No entanto, sendo bem poderoso, possui também uma curva considerável de aprendizado, em especial é preciso lidar com vários arquivos de configurações complexos.

\subsection*{VRaptor}

É um Framework MVC Java para Web focado em desenvolvimento rápido, prometendo aos seus usuários uma alta produtividade com uma baixa curva de aprendizagem, economizando tempo no desenvolvimento de soluções.

O VRaptor é desenvolvido pela Caelum, escola que oferece cursos de Java em São Paulo.

Assim como nos outros frameworks, a ideia é liberar o desenvolvedor de código repetitivo e tedioso ligado à tecnologia para que se possa focar no desenvolvimento da lógica do negócio. 

Alguns aspectos aproveitados é a automatização da conversão de parâmetros da requisição HTTP em objetos esperados pelo controlador e a facilidade de controle da navegação entre as páginas.

Uma característica interessante é que a necessidade da escrita de arquivos de configuração em geral e suplantada pelo uso de convenções na programação das partes da aplicação que interagem com o framework.

Por ter uma estrutura mais simples, com uma documentação direta e de fácil entendimento, e por ser suficientes para nossas necessidades (dado o porte relativamente pequeno de nossos módulos web) foi essa a nossa escolha para framework web.

\subsection*{Hibernate}

Quando lidamos com aplicações web é muito comum a necessidade de se armazenar informações no banco de dados, mas dado que na aplicação lidamos com objetos em geral é preciso realizar um complexo processo de conversão dos objetos em dados que possam ser registrados em tabelas do banco de dados e vice-versa.

Felizmente esse trabalho pode ser automatizado com o uso de frameworks que implementam a JPA (Java Persitence API) que define como aplicações Java EE devem realizar esta conversão.

A implementação open source mais conhecida e utilizada da JPA é o Hibernate, que possui suporte a vários bancos de dados disponíveis no mercado, entre eles ao MySQL, banco de dados também open source por nós utilizado.

E mais ainda, vários frameworks, entre eles o Seam e o VRaptor, já possuem mecanismos de integração que facilitam a configuração e uso do Hibernate.
