\chapter{CONCLUSÕES}

Durante a elaboração do presente trabalho, o estudo das características morfológicas da \libras nos auxiliou na formulação de um modelo de codificação digital para sinais de \libras baseado na notação \sw, tendo esse sistema de codificação sido utilizado ao longo do projeto; este modelo é de extrema importância, pois além de facilitar a escrita e armazenamento digital de \libras (seja por XML ou bancos de dados), pode criar uma forma comum de comunicação entre diferentes sistemas de processamento computacional de \libras.

Tendo em vista a preocupação em obter um sistema de tradução que levasse em conta a coerência sintática da frase gerada em \libras, adotamos uma arquitetura de tradução baseada em sintaxe e por regras, em que se definem as alterações sintáticas da sentença original para a sentença traduzida.

Neste trabalho não nos limitamos ao processo de tradução em si, mas definimos uma arquitetura que incluísse todos os módulos adicionais para uma tradução completa, a saber:

\begin{itemize}
\item analisador morfológico;
\item analisador sintático;
\item dicionário de português para \libras;
\item sintetizador de sinais;
\item ferramenta colaborativa para criação e edição de sinais;
\end{itemize}

Para a criação e integração desses diferentes módulos, mais o tradutor em si, foram necessários estudos e prática em diferentes tecnologias, tais como de computação gráfica, banco de dados, tecnologias web, compiladores, integração Java-C e WebServices, dentre outros.

Tendo os últimos módulos, os de tradução, sido implementados mais ao fim do período do trabalho, não foi possível realizar uma avaliação adequada do processo completo de tradução, embora pudemos submeter a alguns testes a ferramenta colaborativa, que considerando as limitações do modelo, apresentou bom desempenho, embora fosse desejado a integração com o sintetizador de sinais.

Por fim, conseguiu-se estabelecer uma arquitetura modular para o processo de tradução, estabelecendo módulos bem definidos que, mais alguns do que outros, tem potencial para serem re-aproveitados em novos projetos.

Esperamos assim que de alguma forma, seja direta ou indireta ao incentivar ou facilitar o surgimento de novas aplicações, nosso projeto cumpra um papel positivo que traga algum benefício à comunidade surda.

\section{Trabalhos Futuros} % (fold)
\label{sec:trabalhos_futuros}

O projeto Poli-Libras deu início a um legado de sistemas abertos para o desenvolvimento de aplicações voltadas ao público surdo, mas cada um de seus componentes ainda precisam de melhorias, que são listadas a seguir:

\subsection*{Modelo de dados}

Inclusão de atributos especificados em \cite{manual_sw}, como expressão corporal (ex: movimento de ombros).

Realizar uma avaliação da capacidade de cobertura do modelo sobre os sinais da \libras.

Investigar mais o vocabulário da \libras e estudar como o modelo pode ser alterado para poder representar uma quantidade maior de sinais. 

Expandir o modelo de dados para ter um grupo de configurações de mão que abarque as configurações correspondentes às letras.

\subsection*{Virtual Jonah}

Deve evoluir para implementar todos os atributos previstos no modelo de dados, entre eles o movimento da mão, o ponto de contato, movimento dos dedos e expressão facial.

Para implementar os atributos acima também será importante o design do avatar de corpo inteiro, uma vez que alguns sinais utilizam o braço como ponto de locação, sendo que para isso, provavelmente, dever-se-á portar o programa para alguma plataforma que possibilite o controle de \emph{bones} em tempo de execução.

Uma possível melhoria também seria um ``controle de prosódia'' na execução dos sinais, retirando a linearidade dos movimentos, deixando-os mais naturais.

\subsection*{WikiLibras}

Integrar o Virtual Jonah ao WikiLibras assim que o primeiro apresentar uma implementação mais ampla dos atributos previstos para o sinal.

Adequar a interface às diretrizes de construção de web sites para o público surdo.

\subsection*{Analisador Morfológico}

Dada a base de dados (dicionário), o analisador morfológico obtido age como o esperado: devolve uma estrutura de dados contendo informações sobre cada interpretação morfológica contida na base de dados.

Infelizmente, a base de dados padrão que ora acompanha a publicação do JSpell não é completa, faltando várias palavras contidas no VOLP~\cite{volp}. É verdade que muitas dessas palavras faltantes são de uso muito especializado ou raras, mas há aquelas mais comuns, como "ímã", que não são suportadas. Ainda, o dicionário padrão não contém variações corretas brasileiras do português. Tome-se como exemplo o substantivo "projeto"; essa palavra não consta na base padrão, mas a vertente do português europeu, "projecto", lá figura. Mais fatídico ainda é o fato de, pelo novo acordo ortográfico, segundo interpretação da Academia Brasileira de Letras~\cite{volp}, "projecto" não mais ser grafia válida. O caso do 'c' mudo é o mais frequente.
 
O problema de inserção de novas palavras pode ser resolvido através do uso da função \emph{insert\_word} própria do JSpell; contudo, as operações de remoção ou atualização de palavra diretas não são suportadas diretamente, donde vem que, para efetuá-las, é necessário se criar um novo dicionário e povoá-lo sem a palavra a ser removida e/ou com as atualizações de palavras previamente existentes.

\subsection*{Analisador sintático}

Existe muito espaço para evolução no analisador sintático. Em primeiro lugar, a atual implementação só reconhece orações na ordem direta. Apesar do nosso analisador poder aceitar qualquer gramática livre de contexto, esta deve ser determinística e portanto dificilmente essa questão seria resolvida na gramática (assim como a gramática por nós utilizada, que gera as orações na ordem direta apenas), necessitando de recursos externos para tal. Uma opção seria o uso de técnicas adaptativas para realizar a inversão de certos termos nas regras, como vem sendo desenvolvido em~\cite{cerqueiraiblinaa}.

Outra aspecto que deve ser trabalhado futuramente é o reconhecimento de períodos compostos, i.e., frases com mais de uma oração, principalmente no caso de orações subordinadas. Para isso são necessários algumas modificações na gramática para que aceitem que um determinado sintagma (substantivo, por exemplo) possa se transformar numa oração completa. Além disso, a análise terá que ser mais profunda para que seja reconhecido qual é o nome que a conjunção que une as orações está substituindo, ou qual é o sujeito da 2ª oração, em geral oculto pois foi explicitado na 1ª oração. Por exemplo, na frase: ``Aquele é o menino que venceu", a oração ``que venceu" é subordinada adjetiva restritiva pois confere uma qualidade ao substantivo ``menino", sendo que a conjunção ``que" refere-se (substitui) justamente ele.

É possível também que a análise sintática gere mais de uma árvore válida, formando assim um caso de ambiguidade sintática. Outra evolução possível seria realizar o tratamento dessas ambiguidades, mas para isso seria necessário subir mais um nível na tradução, chegando ao semântico, para que essas alternativas possam ser esclarecidas quando comparados os seus significados.

\subsection*{O tradutor}

As regras de tradução sintática devem ser alteráveis após o deploy do projeto, para que especialistas (linguistas, por exemplo) possam melhorar o conjunto de regras (definição formal em alguma notação similar à gramática transformativa).

No caso do tradutor não conhecer um sinal possível para uma palavra, esta deve ser representada com a execução soletrada, usando os sinais correspondentes às letras. Isso é especialmente útil para nomes próprios.

Para uma melhor tradução para Libras, faltam ser considerados alguns aspectos sintáticos como a flexão de gênero e de número e a escolha da melhor ordem da frase (SVO, SOV ou OSV). Além disso, a incorporação de uma análise semântica também representaria uma grande evolução, possibilitando certas junções de sinais como a incorporação do objeto no próprio verbo ou determinadas adaptações semântico-visuais que tornariam a fala mais fluente.

Quanto a saída gerada, após a tradução ser exibida ao usuário é desejável que um vídeo possa ser baixado; alternativamente pode-se baixar o XML com a descrição dos sinais da sentença, que poderia ser usado em uma versão desktop do Virtual Jonah que funcionaria como um \emph{\libras player}.

