Pages

Recentemente, após um amigo avisar que a versão final do framework VRaptor4 estava disponível, resolvi atualizar o projeto que acabávamos de começar e que utilizava a versão anterior desse framework. Após alguns dias sofrendo com a migração para a nova versão, finalmente, tudo estava funcionando e continuamos o desenvolvimento.

A nova versão do VRaptor trouxe mudanças significativas, a principal delas foi a utilização do CDI 1.1 como container de DI (Dependency Injection).  Como estávamos utilizando o Tomcat 8 tivemos que habilitar o suporte ao CDI utilizando o Weld. Logo vimos que o tempo de inicialização do servidor estava muito demorado, cerca de 30 segundos, e a cada modificação realizada um restart do servidor acontecia e lá se iam mais 30 segundos. Ao final do dia, o tempo perdido com o redeploy da aplicação era bastante considerável, gastávamos cerca de 1/5 do dia só esperando as modificações realizadas surtirem efeito.

Não conformado, resolvi buscar uma forma de diminuir o tempo perdido, foi então que lembrei de uma conversa que tive a cerca de um ano atrás com outro amigo. Nela ele havia me falado de uma JVM que realizava um hotswapping mais eficiente do que o disponibilizado na versão padrão, tratava-se do JRebel, entretanto, ao verificar o valor da licença, descartei de imediato essa possibilidade. Então, o jeito foi procurar alguma solução open source que realizasse a mesma função.

Não demorou muito até que encontrei o projeto DynamicCode Evolution VM, que segundo a descrição do produto “possibilita um número ilimitado de redefinições de classes em tempo de execução”. Resolvi então fazer o download do binário e testar.

Logo de cara tive problemas de compatibilidade. A versão disponibilizada no site oficial estava desatualizada. Mais algumas buscas no Google até que encontrei um fork do projeto original no Github, fiz o download dos novos binários e dessa vez tudo funcionou corretamente. O processo de instalação é bem simples e não existem configurações a serem realizadas. Os testes realizados mostraram que o hotswapping realmente funciona, possibilitando um enorme ganho de produtividade para toda a equipe.

Para quem tiver interesse em utilizar a DCEVM, segue um passo a passo para um ambiente de desenvolvimento utilizando o Eclipse Luna, JDK 8 e Tomcat 8.

1. Faça o download do binário correspondente ao seu sistema operacional em https://dcevm.github.io/ , no meu caso a versão baixada foi Light Java 8 update 5, build 52. 
2. Abra o terminal e digite:

java -jar installer.jar

Caso esteja usando o Windows com o JDK instalado no diretório padrão você deverá inciar o cmd com privilégios de administrador, pra isso clique com o botão direito no ícone e selecione Executar como Administrador.

3. A seguinte tela irá aparecer:



Nela você poderá visualizar todas as instalações encontradas, podendo ainda adicionar uma nova instalação através do botão Add instalation directory, caso a versão desejada não tenha aparecido na listagem.

Para instalação tudo que você deve fazer é selecionar a instalação desejada e clicar em Replace by DCEVM. No meu caso, realizei a substituição do jdk1.8.0_05. Após a substituição a listagem deverá conter as seguintes informações:


Agora vamos configurar o Eclipse para utilizar a versão da DCEVM.

1. Abra o Eclipse e vá em Windows > Preferences > Java > Installed JREs
2. Caso a versão na qual foi realizada a substituição não esteja nesta listagem clique em Add.., escolha a opção Standard VM e informe a localização da instalação.
3. Marque-a como padrão (Figura abaixo).



4. O próximo passo é configurar o servidor Tomcat, para isso vá em Windows > Server > Runtime Environments.


5. Caso a versão desejada não esteja na lista clique em Add.., selecione a versão desejada (no meu caso foi a Apache Tomcat v8.0) e informe o diretório de instalação do tomcat.
6. Logo abaixo selecione a JRE escolhida no passo 2. Clique em finalizar.


7. Na view Servers, clique com o botão direito e vá em New > Server e adicione o servidor configurado no passo anterior.
8. Logo após, dê um clique duplo no servidor adicionado no passo anterior e na aba Publishing deixe marcada a opção Automatically publish when resourcess change.


9. Na parte inferior, clique em Modules e para cada um dos módulos existentes clique em Edit... e desmarque a opção Auto reloading enabled.


Pronto!

Estudo de Caso: Aplicação de Regras de Produção para gerenciamento de status processuais


Contexto do problema 

O Poder Judiciário vem ao longo do tempo tentando aperfeiçoar os sistemas informatizados de controle processual. Grande parte dos esforços está concentrada no aperfeiçoamento de duas das principais funcionalidades desses sistemas: A distribuição e a movimentação processual. A distribuição marca o início da vida de um processo e as movimentações que vão sendo realizadas representam a evolução do mesmo.

O ciclo de vida ou tramitação de um processo pode ser representado conforme o esquema abaixo:


Figura 1 Fluxo de tramitação


Cada retângulo acima representa um status que o processo pode assumir em um dado momento durante a sua tramitação. A mudança de um status para outro é determinada pelas movimentações que vão sendo realizadas, sendo que essas movimentações sempre devem obedecer a uma sequência lógica existente para evitar estados inconsistentes, por exemplo, arquivar um processo que ainda não foi baixado. 

Atualmente, a validação dessa sequencia lógica é realizada através de estruturas condicionais aninhadas, Figura 2.


Figura 2 Validação com estruturas condicionais


Existem alguns casos em que a movimentação só altera o status se o processo for de determinadas classe processual, por exemplo, a movimentação Incompetência só altera o status se o processo for do tipo Procedimento Ordinário. Para cobrir essas exceções uma nova entidade, que faz o relacionamento de um tipo de processo, uma movimentação e um status, foi criada.

Essa abordagem funciona corretamente, porém existe uma dificuldade muito grande no processo de avaliação dessas regras por parte dos especialistas (magistrados), devido ao fato das mesmas estarem hardcoded. Até mesmo os próprios programadores enfrentam dificuldades para entender e sentir confiança na alteração de uma dessas regras, tendo em vista o impacto que elas causam nos processos.

Partindo desse problema surgiu a ideia de utilizar regras de produção juntamente com uma linguagem específica de domínio (DSL) para implementar essas funcionalidades e ao mesmo tempo permitir a apreciação dessas regras por um especialista de forma mais fácil e natural.

Implementação

Para a representação e raciocínio do conhecimento especializado foi utilizado o framework JBoss Drools.

A primeira decisão a ser tomada foi sobre a utilização de Stateless ou Statefull Session. A diferença básica entre elas é que em uma sessão Statefull a modificação dos dados são informados ao motor de conhecimento para que um novo raciocínio possa ser realizado, esse processo recebe o nome de inferência. Já no outro caso isso não ocorre. Para esse trabalho foi utilizada uma Stateless Session, pois o mecanismo de inferência não se faz necessário.

O passo seguinte foi criação das regras, onde ficou clara a necessidade da elaboração de dois conjuntos distintos de regras: uma para a validação da movimentação (verificar se determinada movimentação pode ou não ser realizada), Figura 3, e outra para a alteração efetiva dos status, Figura 4.

A imagem abaixo apresenta algumas das regras criadas:

Figura 3 Validação da movimentação


Figura 4 Alteração do status

Uma pequena aplicação foi desenvolvida com o objetivo de testar as regras criadas e avaliar a aplicação dessa abordagem. O funcionamento é bem simples, basta informar o número do processo e a movimentação que deseja realizar. Primeiramente esses dados são submetidos às regras de validação, que decidirão se o procedimento poderá continuar a ser realizado ou não e nesse último caso ainda informará o motivo. Caso a movimentação possa prosseguir os dados passarão pelo segundo conjunto de regras, que pode atribuir ao processo o seu novo status.

Os resultados mostraram um correto funcionamento da aplicação de regras de produção no contexto apresentado e a resolução do problema inicial levantando (avaliação das regras por parte dos especialistas), obtendo uma boa aceitação pelos mesmos.

Estudo de Caso: Aplicação de Aprendizagem de Máquina para a classificação das Classes Processuais das Turmas Recursais do TJPI

Contextualização do Ambiente

Diariamente usuários do Sitema de Controle Processual das Turmas Recursais do TJPI entram em contato com o Service Desk tentando solucionar dúvidas de como fazer a classificação correta das petições iniciais.
Essa classificação é realizada de acordo com as Tabelas Processuais Unificadas do Conselho Nacional de Justiça – CNJ, que foram criadas com o objetivo de padronizar e uniformizar a taxonomia e terminologias dos processos de todos os Tribunais do Brasil. Porém, juntamente com os benefícios criados pela implantação dessas tabelas veio à dificuldade dos usuários conseguirem realizar tal classificação, tendo em vista que para o completo entendimento e domínio da mesma se faz necessário um amplo conhecimento dos códigos processuais.
Essa dificuldade deve-se, principalmente, ao fato de que boa parte dos servidores responsáveis por realizar essa atividade possui apenas o nível médio e nenhuma formação complementar em Direito.
Surge daí a ideia de utilizar a Aprendizagem de Máquina, mais especificamente a Mineração de Dados, para tentar facilitar as atividades de classificação.

Abordagem utilizada

A primeira ideia era obter as petições iniciais existentes na base de dados, extrair o texto e realizar o treinamento, tendo em vista que as petições existentes já se encontram classificadas corretamente.
Os arquivos disponíveis para realizar essa atividade foram digitalizados sem o reconhecimento de caracteres (OCR), com a menor qualidade possível (300 dpi e modo de cor preto e branco), visando a economia de espaço, e salvos no formato PDF.
O primeiro obstáculo enfrentado foi encontrar um software Open Source para realizar o OCR que garantisse uma boa taxa de acerto. Os seguintes softwares para OCR foram encontrados:

Devido o suporte a múltiplas línguas, principalmente a língua portuguesa, o Tesseract obteve um melhor desempenho, porém a entrada de dados é um arquivo de imagem.
Dessa forma foi necessário realizar a conversão dos arquivos PDF para arquivos de imagens. O formato de saída escolhido foi o TIFF (Tagged Image File Format) por realizar a compressão sem perda de dados. A desvantagem desse formato é o tamanho final do arquivo que é bem superior a outros formatos de imagens conhecidos como JPEG e PNG, o que ocasionou diversos estouros de memória da JVM (Máquina Virtual Java) durante a conversão de arquivos PDF com tamanho superior a 10 MB, por isso se fez necessário excluir do conjunto de treinamento as petições com tamanho superiores a esse.
O processo de extração de texto das imagens mostrou-se muito demorado, necessitando em média de 5 segundos para cada página. Cada petição possui em média 20 páginas, o que nos leva a um tempo médio de 100 segundo por petição.
A análise dos textos extraídos revelou uma grande quantidade de caracteres irrelevantes que o software gerou ao se deparar com arquivos contendo imagens, carimbos, assinaturas e outros gráficos que não representam caracteres. A saída seria a remoção desses ruídos, para enfim ter o conteúdo necessário para aplicar os algoritmos de classificação.
Entretanto, por questões de tempo essa ideia não pôde seguir, pois ainda seria necessário um pré-processamento para a remoção de palavras irrelevantes, análise léxica e seleção de termo de indexação para enfim realizar a classificação, como ilustra a imagem abaixo.


A segunda ideia foi tentar utilizar os demais dados dos iniciais dos processos existentes para realizar a classificação. Os mais relevantes levantados foram:
  •  Natureza (Cível e Criminal)
  • Assunto do Processo (Classificado pelas Tabelas Processuais Unificadas)
  • Classe Processual (Objetivo da classificação)


Classificação com WEKA

Os dados necessários foram extraídos diretamente da base de dados, através da conexão com o banco de dados SQL Server 2008, portanto nenhum arquivo .arff foi gerado para esse problema. A quantidade de instâncias (linhas do banco de dados) utilizadas foram 3882.
Após a obtenção dos dados iniciou-se a tentativa de classificação, os seguintes algoritmos foram utilizados:
  • Árvore de decisão - J48
  • Vizinhos mais próximos (k-nearest neighbor) – Ibk
  • Rede Bayesiana - BayesNet


Resultados

Os três algoritmos utilizados mostraram-se bastantes eficientes na classificação dos processos. A tabela a seguir apresenta os resultados:


O melhor desempenho ficou com o algoritmo BayesNet, a rede bayesiana criada pelo algoritmo é bastante simples, como podemos ver na imagem abaixo.



Através da Confusion Matrix podemos verificar as classificações incorretas que foram realizadas:


Os Mandados de Segurança obtiveram um índice de acerto muito baixo, quase 50% foram classificados incorretamente, um dos possíveis motivos para esse desempenho fraco é que essa classe é bastante genérica. Processos com essa classificação podem ter os mais variados tipos de assunto.

Conclusão

Esse estudo de caso discutiu a aplicação de Aprendizagem de Máquina em um problema real, apresentando as abordagens utilizadas e os resultados obtidos com a aplicação dos algoritmos de classificação.
A abordagem inicial continua interessante e será estudada mais detalhadamente, mas nesse momento, foi inviável para esse estudo de caso.
A segunda abordagem foi bastante satisfatória, através dela conclui-se que a classificação dos processos pode ser realizada com um ótimo índice de acerto, bastando para isso possuir dados mais simples de se obter: a natureza e o assunto do processo.