MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA CURSO DE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO

FELIPE DE ALMEIDA OLIVEIRA GERALDO AVELINO DE OLIVEIRA NETO

IMPLEMENTAÇÃO DE UMA INTERFACE PARA VALIDAÇÃO CRUZADA DE EXPERIMENTOS EM APRENDIZADO DE MÁQUINA

Rio de Janeiro 2013

INSTITUTO MILITAR DE ENGENHARIA

FELIPE DE ALMEIDA OLIVEIRA GERALDO AVELINO DE OLIVEIRA NETO

IMPLEMENTAÇÃO DE UMA INTERFACE PARA VALIDAÇÃO CRUZADA DE EXPERIMENTOS EM APRENDIZADO DE MÁQUINA

Projeto Final de Curso apresentado ao Curso de Engenharia de Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção da graduação em Engenharia de Computação. Orientador: Julio Cesar Duarte - D.Sc.

Rio de Janeiro 2013

INSTITUTO MILITAR DE ENGENHARIA

FELIPE DE ALMEIDA OLIVEIRA GERALDO AVELINO DE OLIVEIRA NETO

IMPLEMENTAÇÃO DE UMA INTERFACE PARA VALIDAÇÃO CRUZADA DE EXPERIMENTOS EM APRENDIZADO DE MÁQUINA

Projeto Final de Curso apresentado ao Curso de Engenharia de Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção da graduação em Engenharia de Computação. Orientador: Julio Cesar Duarte - D.Sc. Aprovada em 11 de junho de 2013 pela seguinte Banca Examinadora:

_______________________________________________________________ Julio Cesar Duarte - D.Sc., do IME

_______________________________________________________________ Ricardo Choren Noya - D.Sc., do IME

_______________________________________________________________ Maria Claudia Reis Cavalcanti - D.Sc., do IME

Rio de Janeiro 2013

3

SUMÁRIO

1

INTRODUÇÃO .................................................................................................9

1.1

CONTEXTUALIZAÇÃO ........................................................................................................ 9

1.2

OBJETIVO ............................................................................................................................... 9

1.3

MOTIVAÇÃO ........................................................................................................................ 10

1.4

METODOLOGIA................................................................................................................... 11

1.5

ESTRUTURA DA MONOGRAFIA ..................................................................................... 12

2

FRAMEWORK DE APRENDIZADO DE MÁQUINA (FAMA) .........................13

2.1

FRAMEWORK ........................................................................................................................ 13

2.2

APRENDIZADO DE MÁQUINA ......................................................................................... 14

2.3

FRAMEWORK DE APRENDIZADO DE MÁQUINA (FAMA) ........................................ 17

3

DESENVOLVIMENTO ...................................................................................20

3.1

VALIDAÇÃO CRUZADA..................................................................................................... 20

3.2

MUDANÇAS NO FAMA ....................................................................................................... 22

3.2.1

MUDANÇAS NO FAMA DECORRENTES DA INTERFACE ......................................... 25

4

INTERFACE GRÁFICA .................................................................................27

4.1

EXPERIMENTAÇÃO DA INTERFACE ............................................................................ 27

4.2

MANUTENÇÃO E EVOLUÇÃO DA INTERFACE .......................................................... 44

4.3

PROBLEMAS ENCONTRADOS NO DESENVOLVIMENTO E SUGESTÕES ........... 50

5

CONCLUSÃO .................................................................................................52

6

REFERÊNCIAS BIBLIOGRÁFICAS ..............................................................53

7

APÊNDICES ...................................................................................................54

7.1

APÊNDICE 1 – REQUISITOS ............................................................................................. 54

7.2

APÊNDICE 2 – CASOS DE USO ......................................................................................... 54

7.3

APÊNDICE 3 – DIAGRAMA DE CLASSES PARTICIPANTES..................................... 63

4

LISTA DE ILUSTRAÇÕES FIG. 2.3.1 – Classes abstratas do framework previamente desenvolvido................................18 FIG. 3.1.1 – Instâncias do Validador no framework................................................................21 FIG. 3.2.1 – Classes abstratas do framework atual..................................................................24 FIG. 3.2.1.1 – Estrutura do CorpusMatrizUI...........................................................................26 FIG. 4.1.1 – Tela inicial da interface........................................................................................27 FIG. 4.1.2 – Interface após escolha do corpus.........................................................................28 FIG. 4.1.3 – Botão que permite a escolha da configuração......................................................29 FIG. 4.1.4 – Pop-up com o formulário de configuração..........................................................30 FIG. 4.1.5 – Botão para abertura de arquivo............................................................................31 FIG. 4.1.6 – Interface após carregamento do arquivo..............................................................32 FIG. 4.1.7 – Seleção de um atributo.........................................................................................33 FIG. 4.1.8 – Interface para a aba de validação.........................................................................34 FIG. 4.1.9 – Interface após a escolha do treinador...................................................................35 FIG. 4.1.10 – Botão que permite a configuração de parâmetros..............................................35 FIG. 4.1.11 – Formulário de configuração de parâmetros..............................,........................36 FIG. 4.1.12 – Exemplo de escolha de método de validação, avaliador e atributo de treino....37 FIG. 4.1.13 – Resultado do experimento..................................................................................38 FIG. 4.1.14 – Interface exibe parâmetros salvos do experimento............................................39 FIG. 4.1.15 – Interface para a aba de treinamento/classificação..............................................40 FIG. 4.1.16 – Interface após a importação dos dados..............................................................41 FIG. 4.1.17 – Interface após o treinamento..............................................................................42 FIG. 4.1.18 – Interface após a classificação.............................................................................43 FIG. 4.2.1 – Diagrama UML das classes da Interface.............................................................49 FIG. 7.3.1 – Diagrama de visão de classes participantes do CDU 1........................................64 FIG. 7.3.2 – Diagrama de visão de classes participantes do CDU 2........................................64 FIG. 7.3.3 – Diagrama de visão de classes participantes do CDU 9........................................65

5

FIG. 7.3.4 – Diagrama de visão de classes participantes do CDU 10......................................65 FIG. 7.3.5 – Diagrama de visão de classes participantes do CDU 11......................................66

6

RESUMO O constante e rápido desenvolvimento tecnológico dos últimos anos possibilitou às pessoas um crescente acesso às novas tecnologias, que passaram a ser fato comum no dia-adia de todos. Nesse contexto, destaca-se o tema de Aprendizado de Máquina. Esse assunto vai ao encontro das tentativas cada vez maiores de conseguir auxílio automatizado em tarefas eminentemente humanas. Este trabalho desenvolve uma interface de fácil uso para o usuário executar experimentos de validação cruzada na área de aprendizado de máquina. Em paralelo ao desenvolvimento da interface, adicionam-se novas funcionalidades e instâncias a um framework de suporte para avaliação comparativa dos diversos algoritmos de aprendizado de máquina, outrora desenvolvido. Com esse trabalho espera-se reiterar a importância das pesquisas nas áreas supracitadas, além de facilitar, através da interface, desenvolvida e documentada com o intuito de ser simples e autoexplicativa, a realização de experimentos de aprendizado de máquina, sem a necessidade de que o usuário tenha conhecimento profundo sobre a programação do framework e suas instâncias utilizadas.

7

ABSTRACT The constant and rapid technological development in recent years has allowed people an increasing access to new technologies, which have become a common occurrence in dayto-day activities. In this context, one issue stand out: Machine Learning. This subject meet the increasing attempts to achieve automated assistance in eminently human tasks. This work develops an easy to use interface for the user to execute cross-validation experiments in the area of machine learning. In parallel to the development of the interface, new functionalities are added to a support framework for comparative evaluation of various machine learning algorithms, once developed. With this work is expected to reiterate the importance of research in the abovementioned areas, and facilitate, through the interface, developed and documented in order to be simple and self-explanatory, the conduction of machine learning experiments, without the need for the user to have intimate knowledge about the programming of the framework and its instances used.

8

1

INTRODUÇÃO

1.1 CONTEXTUALIZAÇÃO Neste trabalho aborda-se o tema framework aplicado a aprendizado de máquina (FAMA), uma subárea da inteligência artificial (IA). Inteligência artificial (IA) é o ramo da ciência da computação que estuda a simulação dos comportamentos de inteligência humana em um computador, como por exemplo, a capacidade de raciocinar, tomar decisões e resolver problemas (RUSSEL e NORVIG, 2002). São muitas as aplicações de IA hoje em dia, dentre elas pode-se destacar: escolha de ações inteligentes em jogos (mecanismo de jogos), movimentos e decisões de robôs, dispositivos de reconhecimento de escrita e voz, programas de diagnóstico médico, entre outros. Aprendizado de máquina (AM) é a subárea da IA responsável pela criação de programas que melhoram seu desempenho com a experiência adquirida em determinado problema (MITCHELL, 1997), ou seja, programas que aprendem sozinhos. Dentre as aplicações de AM destacam-se: reconhecimento de voz; jogos de estratégia; mineração de texto e dados; e detecção de fraudes em cartões. O framework começou seu desenvolvimento no trabalho de Iniciação à Pesquisa pelos autores Joilson Cisne do Nascimento e Felipe de Almeida Oliveira. Ele é um framework que possibilita a instanciação de diversos classificadores de corpus. Neste trabalho suas funcionalidades são expandidas, principalmente adicionando a validação cruzada, e é criada uma interface gráfica para seu uso. O FAMA possibilita e facilita a pesquisa de diferentes algoritmos de aprendizado de máquina, apresentando de maneira simples diferentes resultados obtidos em diversos experimentos. 1.2 OBJETIVO O objetivo principal deste trabalho é desenvolver uma interface gráfica para diversas instâncias do framework que facilite, simplifique e agilize seu uso, por parte do usuário. Seu foco está principalmente em usuários interessados na pesquisa de algoritmos de AM aplicados a um corpus. Para executar a validação cruzada é adicionada uma classe abstrata ao framework e

9

também são criadas instâncias que possibilitem o experimento. Outro objetivo também é evoluir o framework conforme verifique-se a necessidade, por meio de criação de novas funcionalidades para classes antigas, correção de erros encontrados e criação de novas instâncias de uso para o FAMA. Ainda dentre os objetivos está criar uma documentação para o projeto da Interface das instâncias, que o descreva de tal forma que facilite a sua evolução posteriormente, apresentando diagramas de casos de uso e diagrama de classes participantes. Por fim, como objetivo complementar, as funcionalidades do software são exaustivamente testadas na tentativa de concluir um produto sem falhas. 1.3 MOTIVAÇÃO Na área de aprendizado de máquina o suporte oferecido pelo FAMA à execução de testes de diversos algoritmos de AM é inquestionável, porém um usuário interessado apenas em executar os testes para verificar os resultados e as diferenças entre os algoritmos teria que entender toda a sintaxe das classes do FAMA em C++, sabendo criar objetos e utilizar os métodos corretamente. Aprender isto apenas demandaria tempo e atrapalharia o trabalho do usuário. Neste contexto a interface gráfica se torna de grande ajuda. O desenvolvimento da interface gráfica é de grande utilidade para o projeto do FAMA e suas instâncias, uma vez que simplifica e diminui o tempo de aprendizado para o uso de suas funcionalidades, sendo assim de grande interesse do meio acadêmico e comercial. A estrutura de validação cruzada apoiará a pesquisa de algoritmo de AM, agindo como um elemento facilitador, uma vez que possibilita inúmeros testes automatizados. Documentar o software e ter como base de desenvolvimento o framework facilitará sua evolução e manutenção, garantindo com isso uma sobrevida maior ao projeto da interface e a transmissão de seu conhecimento de uma forma mais fácil.

10

1.4 METODOLOGIA Para o desenvolvimento da interface gráfica é utilizado o SDK (Software Development Kit) Qt Creator, uma IDE (Integrate Development Environment) de C++ desenvolvida pela Digia. Dentre os motivos da escolha merece destaque o fato do SDK possuir uma versão gratuita,

possuir

uma

API

(Application

Programming

Interface)

proprietária

de

desenvolvimento de interface gráfica de alto nível, simples de se aprender e bem completa, possuir uma boa documentação por parte da Digia na web, e utilizar a linguagem C++, a mesma em que as classes do projeto foram criadas. Quanto à especificação dos requisitos para o desenvolvimento da interface gráfica é utilizada na maior parte a metodologia da análise de conteúdo baseada no projeto Weka (Waikato Environment for Knowledge Analysis), um open source de mineração de dados com algoritmos de aprendizado de máquina. A interface também está sendo desenvolvida na forma de protótipos com os quais é possível refinar os requisitos específicos deste subprojeto. Para o auxílio na documentação referente à parte dos diagramas é utilizado o programa Star UML, programa gratuito e fácil de utilizar. Para o controle do versionamento do projeto é utilizado o SVN (Subversion) com repositório online pertencente ao Google Code, isso facilita o desenvolvimento de código paralelo pelos dois autores deste trabalho. Além disso, nesse repositório, receberam também o direito de enviar código fonte alunos de pesquisa interessados em desenvolver o framework em outras subáreas diferentes deste trabalho.

11

1.5 ESTRUTURA DA MONOGRAFIA Este trabalho está estruturado em cinco capítulos. O capítulo dois discorre sobre frameworks, aprendizado de máquina e FAMA, mostrando alguns conceitos e .apresentando de forma sucinta a base do projeto do FAMA que foi utilizado do trabalho de iniciação à pesquisa. O terceiro capítulo traz mudanças adicionadas ao FAMA neste trabalho, com enfoque em validação cruzada, apresentando conceitos e classes da mesma. O quarto capítulo apresenta uma experimentação de uso completo da interface (simulação de uso), um passo a passo de como evoluir a interface adicionando novas instâncias do framework e também apresenta alguns problemas encontrados e sugestões gerais sobre a continuação do projeto da interface e do FAMA. Finalmente, o quinto capítulo apresenta as conclusões e sugestões para trabalhos futuros. Ainda há um apêndice no fim que apresenta a documentação da interface do FAMA com requisitos, diagramas de casos de uso e visão de classes participantes.

12

2

FRAMEWORK DE APRENDIZADO DE MÁQUINA (FAMA)

2.1 FRAMEWORK Esta seção visa abordar alguns conceitos básicos sobre framework, suas principais utilizações, vantagens e desvantagens. O conteúdo desta seção é baseado em (RIEHLE, 2000). Um framework é uma abstração que une códigos comuns entre vários projetos de software provendo uma determinada funcionalidade genérica. Basicamente, o framework pode ser visto como um conjunto de classes que, em conjunto, realizam determinada função para um domínio de um subsistema da aplicação. De fato, a estrutura de um framework representa mais do que somente um conjunto de classes, pois também define como as instâncias das classes são permitidas a interagir entre si em tempo de execução. Efetivamente, o framework age como uma espinha dorsal, no que diz respeito a como as classes estarão relacionadas entre si. Um framework é construído utilizando-se implementações reusáveis na forma de classes concretas e abstratas. As classes abstratas implementam toda a abstração do framework (podendo ser implementadas tanto como classes abstratas ou interfaces), mas deixam as implementações de fato para suas subclasses. As subclasses concretas implementam as operações de modo que as classes possam ser instanciadas e não necessitem de outras subclasses. É importante fazer a distinção entre o framework e os padrões de projeto de software. Os padrões de projeto possuem um nível de abstração mais alto. Um framework, por exemplo, inclui o código, diferentemente do padrão de projeto. Além disso, um framework pode ser modelado e desenvolvido utilizando-se vários padrões de projeto, e sempre possui um domínio de aplicação particular, o que não acontece com os padrões de projeto, que podem abranger vários domínios de aplicação. Geralmente, aplicações reais não utilizam somente um framework, mas sim vários. Uma aplicação pode vincular conjuntamente um framework para lidar com a interface com o usuário e outro para o acesso a banco de dados e persistência, por exemplo. Um framework de aplicação é um framework que vincula um conjunto de frameworks já existentes, com o intuito de cobrir grande parte dos aspectos da aplicação a ser desenvolvida.

13

Daí vem a grande vantagem da utilização de frameworks: o reuso. Em desenvolvimento de software baseado em frameworks de aplicação, os sistemas desenvolvidos são apenas uma extensão dos frameworks de aplicação. Quanto maior e melhor for o framework de aplicação, maior é a possibilidade de fazer o reuso no desenvolvimento do sistema. Outra vantagem que pode ser citada em sistemas baseados em framework é a facilidade de manutenção, pois as implementações chave se localizam em apenas um local, o próprio framework. Em termos de negócio também há vantagens em relação ao uso de frameworks, como por exemplo a alta taxa de produtividade devido ao reuso. Além disso, as aplicações desenvolvidas tendem a possuir menos bugs, pois estas utilizam implementações robustas, proporcionadas pelo framework, e também aparentam ser mais homogêneas, pois possuem implementações e arquiteturas semelhantes, visto que baseiam-se em um framework. Apesar de ser uma aplicação bastante eficiente, os frameworks também possuem desvantagens com relação à implementação e principalmente em relação ao uso. No que diz respeito à implementação, um framework bem projetado demora a ser desenvolvido, pois este necessita ser robusto. Em termos de uso, os frameworks são ferramentas que possuem uma curva íngreme em relação ao aprendizado de uso, por parte dos desenvolvedores que o utilizarão. Os programadores não somente terão de entender cada classe isoladamente, mas também o desenvolvimento das classes abstratas, cujas instâncias colaboram em diferentes propostas. 2.2 APRENDIZADO DE MÁQUINA Aprendizado de máquina é um ramo da inteligência artificial que trata do projeto e desenvolvimento de algoritmos que permitem aos computadores desenvolver comportamentos baseados em dados empíricos (RUSSEL e NORVIG, 2002). O núcleo do aprendizado é via inferência indutiva, baseada na observação de dados que representam informação incompleta acerca de um determinado fenômeno estatístico. Classificação, também chamado reconhecimento de padrões, que é parte do escopo desse trabalho, é uma importante tarefa de AM no qual as máquinas aprendem a reconhecer padrões automaticamente, compará-los com os padrões já conhecidos, e tomar boas decisões. No processo de aprendizagem pode-se necessitar ou não da intuição humana. É preciso deixar claro que essa intuição humana não pode ser completamente removida, uma vez que o projetista do sistema necessita, ao menos, especificar como os dados serão

14

apresentados e quais mecanismos serão utilizados para buscar uma caracterização dos dados. Algoritmos de AM são algoritmos que aprendem automaticamente a partir de um conhecimento ou experiência gerados (MITCHELL, 1997). Um programa aprendiz utiliza algoritmos de AM para ser capaz de criar respostas úteis para novos casos de teste a partir de uma generalização das respostas de casos conhecidos. Algumas classificações comuns de algoritmos de AM são: de aprendizado supervisionado; de aprendizado não supervisionado, de aprendizado semi-supervisionado; e de aprendizado por reforço. Algoritmo de aprendizado supervisionado gera uma função que mapeia entradas em saídas desejadas (tipicamente usado em problemas de classificação). Diferentemente, num algoritmo de aprendizado não supervisionado, o próprio sistema aprendiz modela o conjunto de entradas. Como um meio termo, aparecem os de aprendizado semi-supervisionado, que combinam tanto o supervisionado, quanto o não supervisionado para gerar uma função apropriada ou um classificador. Por sua vez algoritmos de aprendizado por reforço aprendem como agir dada uma observação do ambiente, isto é, utilizam os retornos dados pelo ambiente, em cada observação, como um guia para a aprendizagem. Com grande potencial de utilização prática, a técnica de AM pode ser aplicada em diversas áreas. Dentre suas principais aplicações, pode-se destacar o processamento de linguagem natural (PLN), motores de busca, diagnósticos médicos, bioinformática, reconhecimento de fala, reconhecimento de escrita, visão computacional e locomoção de robôs. A seguir são listadas algumas das principais abordagens usadas na resolução de problemas por meio de aprendizado de máquina: 

Redes Neurais Artificiais (RNA): também chamadas somente de redes neurais (RN), são algoritmos baseados, seja estrutural, seja funcionalmente, em redes neurais biológicas. A computação realizada é organizada em termos de um grupo de neurônios interconectados processando as informações. São usados comumente para modelar complexos relacionamentos entre entradas e saídas, ou descobrir padrões em dados (NILSON, 1998).

15



Máquina de vetores de suporte (SVM, do inglês: support vector machine): é um conjunto de métodos relacionados ao aprendizado supervisionado que, após uma análise dos dados, reconhecem padrões, sendo usado, por exemplo, para classificação. O SVM padrão analisa um conjunto de dados de entrada que possui apenas duas classes distintas de dados, e determina a fronteira entre essas duas classes, de tal forma que todos os objetos serão classificados de acordo com a região em que ficaram após a criação da fronteira (NILSON, 1998).



Modelos ocultos de Markov (HMM, do inglês: hidden markov models): são utilizados quando se deseja modelar a probabilidade de ocorrência de uma sequência de eventos, em que essa sequência representa um conjunto de ações lógicas interligadas e realizadas pelo dispositivo de IA a fim de solucionar o problema. No caso de PLN, a sequência a ser modelada é a de classificações morfossintáticas de palavras do texto (RABINER, 1989).



Aprendizado baseado em transformações (TBL, do inglês: transformationbased learning): a lógica do TBL é iniciar com uma solução simples para o problema, e aplicar transformações - em cada passo, a transformação que resulta no maior benefício para o problema é selecionada e aplicada. O algoritmo para quando a transformação selecionada não gera mais uma quantidade significativa de modificações nos dados ou não há mais transformações a serem selecionadas (BRILL, 1992).



Agrupamento (Clustering): é um método de dividir um conjunto de objetos em grupos (clusters), de forma que objetos dentro do mesmo grupo são mais similares entre si do que com os demais do conjunto. Seus principais usos são em mineração de dados e na análise de dados estatísticos. Não constitui um algoritmo em si, mas um problema geral a ser resolvido. Vários algoritmos podem objetivar o clustering, porém podem apresentar significativas diferenças quanto à escolha dos parâmetros que serão levados em consideração na realização dos agrupamentos (NILSON, 1998).

16



Redes Bayesianas (RB): é um modelo gráfico probabilístico que utiliza um grafo acíclico direcionado para representar um conjunto de variáveis aleatórias e suas independências condicionais. Uma rede bayesiana poderia, por exemplo, representar o relacionamento probabilístico entre doenças e sintomas. A partir de uma lista de sintomas a rede poderia calcular a probabilidade de estar ocorrendo certa doença (NILSON, 1998).

2.3 FRAMEWORK DE APRENDIZADO DE MÁQUINA (FAMA) O framework de base deste projeto começou seu desenvolvimento na iniciação à pesquisa (IP) e tem a função principal de classificar textos utilizando algoritmos de AM (FAMA), além de outras funções. Para isso, o framework recebe um arquivo de dados tokenizados (corpus) e com a classificação prévia de pelo menos um token de cada exemplo já executada (armazenada como um token também) por um sistema especialista de base humana (base do aprendizado). A produção do FAMA ocorreu na plataforma C++, onde foram criadas classes especializadas em determinadas tarefas e a execução do programa se dá pela troca de mensagens entre as classes. Do IP Foram trazidos três sistemas treinadores/classificadores instanciáveis e consolidados, além de um sistema avaliador e um de corpus. Um dos classificadores é bem simples e age apenas baseado na classificação mais comum de uma palavra (MaisProvavel), outro age baseado em diagramas de estados de sequência de classificações (HMM) e o último refina a classificação de outro método aplicando ao corpus um conjunto de regras otimizadas de refinamento (TBL). A figura seguinte (FIG. 2.3.1) mostra um diagrama UML da estrutura básica inicial do framework, que foi de onde este trabalho iniciou, apresentando as interfaces Avaliador, Treinador e Classificador, e a classe abstrata Corpus.

17

FIG. 2.3.1 – Classes abstratas do framework previamente desenvolvidas.

A classe Corpus é a classe que armazena o corpus no qual se deseja aplicar os métodos de AM. Ela contém dois métodos abstratos (carregarArquivo e gravarArquivo) que servem para carregar o corpus da memória secundária para a principal e da principal para a secundária, respectivamente. Esses métodos devem ser implementados por classes herdeiras, especializadas em tipos diferentes de arquivos. Há somente uma instância desta classe: a CorpusMatriz que trabalha com arquivos de texto da forma txt. Uma classe que trabalha com outro tipo de arquivo poderia ser adicionada ao projeto facilmente, bastando acoplá-la a classe Corpus. A classe Avaliador é implementada somente pela classe AvaliadorAcuracia e seu método (calcularDesempenho) é o responsável por fazer uma avaliação do resultado final da classificação do corpus. A classe AvaliadorAcuracia avalia com base na porcentagem de acertos do Classificador. O FAMA possibilita a utilização de outro critério avaliador, bastando uma nova classe implementar a classe Avaliador com o seu método específico. Na classe Corpus os dados tokenizados do corpus são armazenados em uma matriz, em que cada linha representa um conjunto de dados relacionados e cada elemento é um conjunto de tokens dependentes. Um token pode ser o dado a se classificar ou uma

18

classificação humana ou do sistema deste dado. A fim de diminuir a quantidade de memória utilizada e agilizar processos de comparação de strings, os tokens são representados por números inteiros que tem uma relação biunívoca com cada palavra do dicionário (diferentes strings levam em números diferentes e vice-versa). Exemplo: a: 1, cadeira: 2, correr: 3, para: 4, ... Uma vez carregado o corpus por um objeto da classe herdeira de Corpus, esse é então passado para um objeto da classe Treinador, que é a responsável por executar os algoritmos de AM, ou seja, é nessa etapa que o programa aprende a classificar um dado. A classe Treinador tem o método abstrato executarTreinamento que é implementado pelas classes derivadas dele, cada uma contendo um método diferente de aprendizado. Os três métodos de aprendizado da instância do FAMA são implementados pelas classes MaisProvavel, HMM e TBL. O resultado da classe Treinador retorna um Classificador que é então utilizado para classificar outro texto qualquer armazenado em um objeto da Corpus. Finalmente o resultado da classificação é avaliado pela classe Avaliador, que recebe o Corpus classificado como parâmetro no método calcularDesempenho, retornando uma pontuação específica da classe instanciada.

19

3

DESENVOLVIMENTO Este capítulo apresenta as novas funcionalidades adicionadas ao framework e suas

instâncias. Uma das principais e que constitui um dos objetivos deste trabalho é a adição das classes de validação cruzada ao projeto, que será apresentada na seção 3.1. Cabe colocar que o FAMA foi inicialmente desenvolvido para tarefas de aprendizado de máquina aplicado a processamento de linguagem natural (PLN) e, consequentemente, algumas alterações visam permitir que o framework possa ser utilizado em qualquer tipo de tarefa de classificação por meio de AM. Já outras modificações são apenas para correção ou então adição de métodos simples que trazem algum benefício ao programador. 3.1 VALIDAÇÃO CRUZADA Validação cruzada é uma ferramenta de realização de experimentos na qual a amostra de experimento é dividida aleatoriamente em n partes. A partir disso realizam-se n experimentos sequenciais tomando como base de treino n-1 partes do todo e como teste somente uma parte, o procedimento ocorre de tal forma que todas as partes sejam utilizadas pelo menos uma vez como teste. No final o resultado médio obtido se aproxima muito mais do resultado que seria obtido com uma amostra não tendenciosa do que os outros tipos de validação que serão explanados a seguir (Treino, Teste e Divisão). Outra vantagem da validação cruzada é que ela permite ao usuário realizar um grande número de experimentos de forma automatizada, simplificando seu trabalho, ou seja, sem ela o usuário teria que realizar todo o trabalho de particionamento e aleatorização da amostra. A respeito do FAMA foi criada a classe abstrata Validador, responsável pela execução do experimento de AM. Há 4 possibilidades de instaciação dessa classe: ValidadorTreino, ValidadorTeste, ValidadorDivisão, ValidadorKDobras, conforme o diagrama a seguir (FIG. 3.1.1). Todas ao serem criadas tem que receber uma referência a um Avaliador que será utilizado como critério de avaliação no experimento.

20

FIG. 3.1.1 –Validadores na instância do framework.

A

validação

será

realizada

por

meio

da

chamada

ao

método

virtual

executarExperimento com parâmetros Treinador e Corpus, cada concretização da Validador realizará uma validação diferente. O ValidadorTreino realiza o treino no Corpus e, em seguida, aplica a classificação ao mesmo Corpus, terminando por avaliar o resultado por meio do Avaliador que tem referência (este é o método com resultados mais tendenciosos). O ValidadorTeste é idêntico ao ValidadorTreino, exceto que aplica o conhecimento de classificação a um Corpus distinto, inicializado no construtor.

21

O ValidadorDivisão realiza uma divisão do Corpus por meio de chamada ao novo método splitCorpus da classe Corpus (será abordado na seção 3.2) com um parâmetro que especifica a porcentagem de divisão. A partir disso é realizado o treino em x porcento do tamanho do Corpus e a classificação em (100-x) porcento restante, finalizando com o Avaliador. Este processo é repetido o número de vezes definido pelo parâmetro numeroIteracoes. O ValidadorKDobras é semelhante ao ValidadorDivisão, a diferença é que o KDobras divide o Corpus em n partes (n igual ao atributo numeroIteracoes), sendo utilizada n-1 para treino e 1 para classificação, repetindo o processo até que todas as partes tenham sido usadas para classificação. Este último é o responsável pela utilização da ferramenta de validação cruzada. 3.2 MUDANÇAS NO FAMA Além da adição dos validadores, a seguir são descritas algumas funcionalidades adicionadas no FAMA e correções além de adição de novas funcionalidades em alguns pontos da instância do FAMA. No fim é apresentado um novo diagrama de classes do framework (FIG. 3.2.1) que poderá ser comparado a FIG. 2.3.1 para se ter ideia da evolução do projeto do FAMA como um todo. 

Corrigido um bug na instância de Classificador: o ClassificadorHMM, que cometia um pequeno erro na matriz de caminhos da Programação Dinâmica do método HMM. Após a correção houve uma pequena melhora em seus resultados de classificação.



Realizada modificações gerais de desempenho no treinadorTBL (instância de Treinador) diminuindo um fator de complexidade de n para log(n) e reduzindo consumo de memória na ordem de 70%. Ainda cabe dizer que o fator log(n) pode ser levado a uma constante se o método utilizar HashTable em uma de suas buscas.



Adicionada

uma

nova

funcionalidade

ao

método

carregarArquivo

da

CorpusMatriz (instância de Corpus): agora é possível definir os atributos do corpus e o caractere separador a partir da 1ª linha do mesmo utilizando para isso a

22

seguinte sintaxe, [features = word, pos, adpos] [separator=_], onde features indica a lista de atributos e separator o caractere. Também é possível agora definir os atributos por meio de um arquivo de extensão .names que tenha o mesmo nome do corpus carregado. 

Adicionado o método virtual na classe Corpus: *Corpus splitCorpus( vector vetMascara ), que recebe um vetor de máscara de bits e divide o Corpus atual em dois de acordo com os bits, retornando um ponteiro para esta estrutura. Esse método foi adicionado devido a necessidade das classes validadoras já apresentadas.



Corrigido um bug do método executarClassificacao de todas as instâncias de Classificador: o parâmetro atributo era tratado erroneamente como o atributo base do corpus que seria classificado, modificou-se para indicar a posição que seria adicionado o novo atributo da nova classificação executada. O antigo atributo base agora é armazenado com um atributo de classe de todos os filhos de Classificador.



Adicionado dois novos métodos sobrecarregados a classe Corpus: bool removerAtributo( string atributo ) e bool removerAtributo( int indice ). Com os dois métodos é possível remover um atributo do corpus por meio do nome ou do índice.



Adicionados os métodos int pegarQtdConjExemplos() e int pegarQtdExemplos( int i ) à classe Corpus com o objetivo de realizar as mesmas funções que os métodos pegarQtdSentencas e pegarQtdTokens, porém com uma nomenclatura mais correta para uso geral em AM.



Adicionado o método virtual string descricaoConhecimento() à classe Classificador. Suas instâncias retornarão uma string com a descrição do seu conhecimento de AM para classificação.



Adicionada a classe abstrata Processador ao framework, responsável por realizar o pré-processamento dos corpus utilizados.

23



Adicionados

os

métodos

int

pegarQtdTotalExemplos()

e

Corpus*

gerarSubCorpus( vector< vector< bool > > vetMascara ) na classe Corpus que retorna o total de exemplos de todos os conjuntos e gera um subcorpus a partir da máscara, respectivamente. Todas as mudanças aqui apresentadas podem ser encontradas no controle de versionamento do Google Code, mostrando detalhadamente os trechos do código que foram alterados e a data em que ela ocorreu.

FIG. 3.2.1 – Classes do framework atual.

24

3.2.1

MUDANÇAS NO FAMA DECORRENTES DA INTERFACE A seguir são apresentadas algumas mudanças que ocorreram no projeto do framework

e suas instâncias devidas exclusivamente ao projeto da interface gráfica. O objetivo destas mudanças foi facilitar o desenvolvimento da classe de interface diminuindo seu grau de acoplamento com as classes bases e facilitar sua evolução ao adicionar novas instâncias das classes bases. A construção que motivou as mudanças foi a seguinte: Ao se escolher os tipos de Corpus e Treinador/Classificador na interface é possível abrir uma nova janela gráfica na qual ocorre a inserção dos dados dos construtores, esta janela é sempre a mesma e pode ter seu conteúdo alterado dinamicamente dependendo do tipo associado. Num primeiro momento as classes da interface foram as responsáveis por montar essa janela, porém encontrou-se um problema, estas classes ficaram muito sobrecarregadas com códigos e switch de decisão lógica, dificultando posteriores evoluções. A solução encontrada foi tirar esta responsabilidade das classes de interface e passá-la para as classes do FAMA que precisam da janela. Assim bastaria apenas a classe de interface fazer a chamada ao método polimórfico responsável por construir a janela. Assim adicionou-se o método virtual Corpus* construirJanela(void* popUp) à classe Corpus e Treinador* construirJanela(void* popUp) à classe Treinador, para ser implementado por suas instâncias. Este método constrói a janela de parâmetros para o construtor da classe que a executa, toma os valores preenchidos e retorna o Corpus ou Treinador gerado. O único problema que se encontrou depois da adição deste método é a dependência dele com funções de biblioteca do Qt Creator, e como as instâncias de Corpus e Treinador podem ser executadas fora do ambiente do Qt, isto ocasionaria um erro. Sua solução foi criar classes que herdam das instâncias de Corpus e Treinador todas as suas funcionalidades e estas sim, implementam o método construirJanela sem problemas. Assim no ambiente do Qt, estas são as classes a serem instanciadas ao invés de seus pais (que não perdem mais generalidade de uso). Portanto adicionou-se as Classes CorpusMatrizUI herdando da CorpusMatriz, MaisProvavelUI da MaisProvavel, HMMUI da HMM e TBLUI da TBL.

25

A figura seguinte (FIG 3.2.1.1) apresenta a estrutura da classe CorpusMatrizUI em UML para melhor visualização do que foi exposto.

FIG. 3.2.1.1 – Estrutura do CorpusMatrizUI.

26

4

INTERFACE GRÁFICA A seguir são apresentadas 3 seções: uma envolve a experimentação da interface

mostrando uma simulação completa do uso da ferramenta, outra apresenta aspectos de evolução e manutenção da interface, discutindo como adicionar novas instâncias do FAMA à interface e um diagrama de classes resumido da interface, por fim a última seção apresenta alguns aspectos e problemas encontrados durante e desenvolvimento e também sugestões de melhorias e continuações do projeto. 4.1 EXPERIMENTAÇÃO DA INTERFACE Antes de iniciar a experimentação cabe ressaltar que todas as janelas possuem tamanho dinâmico, podendo ser maximizada ou minimizada mantendo as proporções corretas, sendo que esta parte não é apresentada, mantendo-se as janelas sempre em tamanho constante. Ao inicializar a interface do FAMA, o usuário se depara com a seguinte tela:

FIG. 4.1.1 – Tela inicial da interface.

27

A interface apresenta uma tela bastante limpa, o que facilita a utilização do software por parte do usuário. Para iniciar a utilização do programa, a primeira ação do usuário é a escolha do tipo de corpus para a execução do experimento, que pode ser feita simplesmente selecionando o tipo de corpus no combo box “Escolha o Corpus”. Nesta parte o usuário escolherá o tipo de corpus que será carregado com base em uma lista disponível (atualmente só há o tipo CorpusMatriz), após escolher o tipo desejado será habilitado o botão de configuração do corpus à direita e o botão para selecionar o arquivo desejado à esquerda do combo box.

FIG. 4.1.2 – Interface após escolha do corpus. O usuário agora deve informar ao programa os parâmetros de configuração do corpus, ação essa que pode ser executada ao clicar no botão “...”.

28

FIG. 4.1.3 – Botão que permite escolha de configuração. Ao clicar no botão, o programa exibe uma janela pop-up, com um pequeno formulário de configuração dos parâmetros. No caso do formulário do CorpusMatriz que é aquele que se apresenta abaixo, há 4 campos a serem definidos: separador que define o caractere que é usado no arquivo para separar os atributos relacionados; dividir exemplos que coloca cada atributo em um conjunto de exemplo diferente se setado; atributos automáticos que, com base nos metadados do arquivo a ser selecionado, definirá automaticamente o número de atributos que há no corpus e o nome de cada atributo; se atributos automáticos não for setado será habilitado o campo Nº atributos na qual se deve definir o número de atributos que há no arquivo e o nome de cada atributo.

29

FIG. 4.1.4 – Pop-up com o formulário de configuração. Ao executar tais ações preliminares, é hora do usuário carregar o arquivo para a realização do experimento. Para isso deve-se clicar na pasta, e com isso uma caixa de diálogos em formato padrão do sistema operacional é exibida. Após a exibição da nova janela, o usuário seleciona o arquivo desejado e o programa carrega o arquivo previamente selecionado.

30

FIG. 4.1.5 – Botão para abertura de arquivo. Após a abertura do arquivo, o programa exibirá algumas características do corpus; nome do arquivo, quantidade de instâncias no arquivo, ou seja, quantidade de exemplos, quantidade de atributos e, mais detalhadamente, o nome dos atributos presentes.

31

FIG. 4.1.6 – Interface após carregamento do arquivo. Caso o usuário deseje exibir informações mais detalhadas acerca dos atributos presentes no corpus, é suficiente que o mesmo selecione algum atributo exibido na tabela Atributos. Ao selecionar um atributo são exibidas informações estatísticas a respeito desse atributo na group box Atributo selecionado: nome do atributo, tipo do atributo (nominal ou numérico), quantidade total de dados distintos daquele atributo, quantidade de dados que ocorrem uma única vez no atributo e lista de dados com total de ocorrências de cada dado no arquivo (se numérico também é exibido média dos valores, desvio padrão, máximo e mínimo).

32

FIG. 4.1.7 – Seleção de um atributo. Feita toda a parte de processamento inicial, o usuário agora já pode começar a configurar todos os métodos e parâmetros de validação, para de fato executar o experimento desejado. O primeiro passo é clicar na aba Validação.

33

FIG. 4.1.8 – Interface para a aba de validação. Nos mesmos moldes da fase de pré-processamento, o usuário agora deve selecionar o treinador desejado, procedendo de maneira semelhante à escolha do corpus (seleção de treinador via combo box, habilitação do botão de configuração e preenchimento de configurações na pop-up que será exibida ao clicar-se em “...”). Atualmente estão disponíveis os treinadores MaisProvável, HMM e TBL. Se o usuário não tiver carregado um corpus na aba anterior o combo box do treinador não estará disponível, pois este corpus será utilizado no experimento de validação.

34

FIG. 4.1.9 – Interface após a escolha do treinador.

FIG. 4.1.10 – Botão que permite a configuração de parâmetros.

35

FIG. 4.1.11 – Formulário de configuração de parâmetros. No caso da escolha do treinador a pop-up de parâmetros é executada pelo menos uma vez, automaticamente. Assim como na pop-up do corpus, esta depende do tipo de treinador selecionado. Feita a escolha do treinador, o usuário agora deve escolher o método de validação (caso seja necessário, deve-se ajustar alguns valores da validação, como no caso do KDobras ou então realizar uma nova abertura de arquivo, no caso do validador de teste, para mais detalhes vide seção 3.1) e ajustar alguns parâmetros do experimento (método de avaliação e atributo que será usado para treino).

36

FIG. 4.1.12 – Exemplo de escolha de método de validação, avaliador e atributo de treino. Tendo o usuário preenchido todas as configurações, a realização do experimento é feita simplesmente clicando-se no botão “Começar” que acaba de ser habilitado. Após algum tempo de processamento, o programa exibe os resultados na tabela “Resultados”.

37

FIG. 4.1.13 – Resultado do experimento. O resultado apresentado é o número do experimento, tempo de duração em segundos, porcentagem de acerto de acordo com o método de avaliação e a média de resultados do experimento. Caso o usuário deseje pode realizar outros experimentos de validação ajustando os dados para tal, conforme fizera para realizar este primeiro experimento. Os resultados dos novos experimentos serão adicionados embaixo do anterior na tabela de resultados sendo indicado pela cor verde.

38

FIG. 4.1.14 – Interface exibe parâmetros salvos do experimento. Após realizar inúmeros experimentos o usuário pode escolher qual deles apresentou um melhor resultado e assim exportar as configurações que foram usadas no mesmo com o objetivo de serem reusadas. Para isso basta selecionar o experimento com o botão direito do mouse e escolher a opção “Exportar Dados”, podendo ser exportado para a aba de Validação ou para aba de Treinamento (será abordado mais adiante). Após exportar para a validação o treinador do experimento, o método de validação usado, o avaliador e o atributo de treino são recuperados ocorrendo o preenchimento automático dos campos citados. Também existe a possiblidade do usuário poder limpar a lista de resultados de experimentos pressionando o botão “Limpar”.

39

FIG. 4.1.15 – Interface para a aba de treinamento/classificação. Outra possibilidade da interface além da validação é realizar o treinamento e a classificação separadamente (3ª aba). No caso de treinamento o usuário deve informar o tipo de treinador e os seus parâmetros e o atributo de treino do corpus, de forma idêntica à validação, ou então definir esses dados por meio da exportação de experimento para o treinamento. O treinamento e a classificação somente serão habilitados após o carregamento do corpus na 1ª aba.

40

FIG. 4.1.16 – Interface após a importação dos dados. Feitas as operações iniciais, basta o usuário clicar no botão “Treinar”. Caso deseje, é possível fazer o armazenamento do conhecimento adquirido no treinamento, utilizando-se o botão de salvar que será habilitado após a realização do treinamento. O usuário determina o arquivo em que será gravado o conhecimento por meio de uma caixa de diálogos padrão do sistema operacional.

41

FIG. 4.1.17 – Interface após o treinamento. Caso o usuário deseje realizar uma classificação, o procedimento a ser realizado também é bastante simples. Deve-se escolher o tipo de classificador (MaisProvável, HMM e TBL), carregar o arquivo de conhecimento (obtido em algum treinamento) e atribuir um nome ao novo atributo, caso o usuário queira. Feito isso, basta clicar no botão “Classificar”, e, opcionalmente, pode-se também gravar o corpus gerado de maneira semelhante à descrita para o treinamento.

42

FIG. 4.1.18 – Interface após a classificação.

43

4.2 MANUTENÇÃO E EVOLUÇÃO DA INTERFACE Agora são apresentados alguns aspectos importantes para manutenção e evolução do projeto. Esta seção visa principalmente facilitar o acoplamento de novas instâncias desenvolvidas para o FAMA à interface gráfica. Para adicionar uma nova instância da classe Corpus à interface deve-se primeiro chamar o método addItem do objeto comboBox_corpus (correspondente ao comboBox de Corpus da interface), passando uma string com o nome da nova instância criada. Tudo isso pode ser feito no construtor da classe de controle Janela. Conforme o trecho de código a seguir:

No método habilitarBotao da classe Janela deve-se criar um índice dependente da escolha do usuário que aloque dinamicamente (dê new) o tipo de Corpus a ser adicionado. Conforme o código a seguir:

...

44

No caso, o próximo item adicionado seria o de valor 2 no index. Deve-se criar uma nova classe filha da nova instância de Corpus, esta classe será a responsável por construir a estrutura da interface gráfica da janela de parâmetros (pop-up) da nova instância, que será aberta quando o usuário selecionar o botão de configuração do Corpus, e ela deve possuir includes de bibliotecas do Qt Creator correspondentes às funções que utilizará para construir a interface. Esta classe deve implementar essa rotina no método virtual herdado da Corpus: Corpus* construirJanela( void *popUp ). É recomendado que o nome da classe seja idêntico a classe pai adicionado do sufixo UI (User Interface). Segue o cabeçalho da CorpusMatrizUI de exemplo:

Observa-se que a CorpusMatrizUI descende da classe CorpusMatriz e ela implementa o construtor e dois métodos. O construtor apenas chama o construtor da CorpusMatriz, o método construirJanela é o objetivo da classe e, neste caso, o método clone também tem que ser reimplementado, pois tem que retornar uma instância da CorpusMatrizUI e não mais da CorpusMatriz. No método definirParametros da classe Janela será chamada a função construirJanela da classe Corpus passando como parâmetro um ponteiro da classe Param (nada a ser alterado no código). A pop-up é representada pela classe Param (derivada da Qdialog) que possui um objeto da classe QTableView. Esse objeto do Qt Creator recebe um modelo e com base nesse

45

modelo apresenta diferentes visões na interface, a partir disso é possível generalizar a pop-up com os parâmetros de qualquer tipo de classe. A estrutura de Param pode ser observada no diagrama UML no fim desta seção. Então o que deve-se fazer no método construirJanela é primeiramente instanciar o modelo, representado no caso pela classe ModeloParam, a seguir deve-se definir os atributos do modelo por meio de seus métodos inserirDados(). A estrutura de dados interna ao ModeloParam é uma matriz com 2 colunas e um número qualquer de linhas, a 1ª coluna é sempre uma string e representa o título do campo que o usuário deverá preencher na 2ª coluna correspondente. Já a 2ª coluna aceita string ou QWidget, que é uma classe do Qt Creator que representa objetos da interface gráfica como ComboBox, CheckBox, PushButton entre outros. Deve-se primeiro definir todas as strings que o modelo possuirá, para isso deve-se chamar o método inserirDados( int row, int column, string v ), especificando qual a linha (row) e coluna (column) que a string (v) será inserida para aparecer na pop-up. Em seguida deve-se avisar à classe Param qual modelo ela receberá, para isso basta chamar o método ajustarModelo( QAbstractItemModel m ) passando como parâmetro o ModeloParam que foi instanciado. Por último deve-se inserir as QWidgets chamando o método inserirDados( int row, int column, Param &ct, QWidget *x ), especificando qual linha (row) e coluna (column) que a QWidget (x) será inserida, também deve-se informar em relação a qual pop-up (Param) que a inserção ocorrerá. Terminada essa fase, deve-se inserir os eventos que ocorrerão na pop-up e então, chamar o método iniciarDialog() da Param. A partir desse momento a pop-up aparecerá na tela do usuário. È imprescindível que a chamada aos métodos respeite a ordem aqui estabelecida. Para recuperar os dados que o usuário preencheu na pop-up basta chamar os métodos pegarString e pegarWidget da classe Param, ou então acessar diretamente o QWidget criado. O trecho de código seguinte exemplifica a criação da janela pelo método construirJanela da classe CorpusMatrizUI:

46

Este código gera a pop-up da figura 4.1.4. Para adicionar uma nova instância de Treinador deve-se proceder de forma semelhante à adição de um Corpus. Deve-se primeiramente executar o método addItem dos comboBox_metodo e comboBox_metodoTreinador no construtor da classe Janela, passando uma string com o nome do novo método.

47

Em sequência, deve-se adicionar um novo índice correspondente ao new do novo treinador nos métodos escolherMetodo( int index ) e escolherTreinador( int index ) da Janela. Por fim, deve-se também criar uma classe filha do tipo UI que implemente o método virtual construirJanela do Treinador para estruturar a pop-up. A regra é a mesma aplica na criação de uma nova instância de Corpus. Já para adicionar um novo Avaliador usa-se o addItem da comboBox_avaliador no construtor de Janela e atualiza-se o índice no método escolherAvaliador também da Janela. Nos moldes atuais da interface não existe pop-up para avaliador, portanto não é necessário criar uma classe de UI. Por

fim

para

adicionar

um

Classificador

usa-se

o

addItem

da

comboBox_metodoClassificador no construtor de Janela (recomenda-se que a string utilizada seja exatamente a mesma do treinador correspondente) e atualiza-se o índice de new no método carregarConhecimento. O classificador também não possui pop-up de parâmetros. Na figura a seguir (FIG. 4.2.1) apresenta-se um diagrama UML dos métodos, atributos e relacionamentos entre as classes da Interface, excluindo-se as classes de fronteira como combo box, push button, text, entre outras.

48

FIG. 4.2.1 – Diagrama UML das classes da Interface.

49

A exceção do construtor e do método lógicaDeAbertura da classe Janela, todos os outros métodos estão associados a eventos de apertar botão ou selecionar itens da interface gráfica (são chamados de slots no Qt). Por exemplo, quando o usuário aperta o botão Começar da aba de Validação é gerado um sinal dirigido a um slot, no caso o executarValidação que começa o processo de validação. 4.3 PROBLEMAS ENCONTRADOS NO DESENVOLVIMENTO E SUGESTÕES Primeiramente cabe colocar um problema que se encontrou durante o desenvolvimento com a ferramenta Qt Creator. No mês de Dezembro de 2012 a Digia, produtora do Qt, deixou de disponibilizar a versão SDK do Qt gratuita, disponibilizando apenas a IDE sem os componentes internos, como tool kit e compilador. Tentou-se instalar a última versão sem o SDK disponível no site da Digia, porém tiveram-se muitos problemas que acarretaram no fracasso da instalação completa, assim utiliza-se uma versão mais antiga do Qt, no qual o instalador é um SDK (Qt IDE 2.4.1, com kit 4.7.4). No cronograma inicial deste projeto estava previsto na fase final além do desenvolvimento da interface a elaboração de casos de teste. Porém devido a dificuldades encontradas para o desenvolvimento da interface e sua documentação, além de alguns eventos externos que acabaram tomando todo o tempo restante, não foi possível elaborar os casos de teste. Pelo menos para garantir que o produto final seria livre de bugs foram realizados inúmeros testes no software desenvolvido procurando cobrir todos os casos possíveis, inclusive aqueles em que não faria sentido o usuário executar, foi também testado se existia a possibilidade de ocorrer memory leak, principalmente em opções de escolha de Treinadores, Classificadores, Corpus e Avaliadores. Também não chegou a ser construído um instalador para o programa da interface, seu executável não roda fora do ambiente de desenvolvimento (Qt Creator) por causa da dependência com bibliotecas proprietárias, duas possíveis soluções são colocar no instalador as dlls para a execução do código ou inserir as bibliotecas de forma estática no código.

50

Deixa-se aqui uma sugestão para posteriormente ocorrer a refatoração do código da interface. Apesar do projeto de interface ser simples e não necessitar muito de uma estrutura otimizada, conforme ele cresça com novas funcionalidades sua manutenção se tornará complicada, evidenciando a necessidade de uma boa estrutura. Dentre os principais aspectos a se modificar estão: criar uma classe de controle para cada aba da interface, diminuindo a carga sobre a classe Janela que é a única controladora existente; substituir as classes UI criadoras de janela de pop-up do corpus por outra estrutura na qual não se necessite criar um vínculo com a interface dentro do FAMA; pesquisar e utilizar uma arquitetura de software que diminua o acoplamento entre as classes da interface e as classes do FAMA. Outra sugestão levantada é alterar os códigos de aprendizado de máquina para incluir programação concorrente de multithread, pois uma vez que os principais algoritmos são muito lentos e hoje em dia os processadores têm evoluído principalmente adicionando núcleos, haveria um ganho bem significativo em desempenho.

51

5

CONCLUSÃO Este trabalho tem sua importância no desenvolvimento de uma interface que

possibilite e facilite a realização de experimentos de aprendizado de máquina, principalmente por usuários que não detém o conhecimento da linguagem de programação do software. Isso servirá de estímulo à pesquisas na área de aprendizado, muito importante para automatização de tarefas tipicamente humanas. A documentação e o capítulo de desenvolvimento do projeto apresentados são de grande importância para a evolução do mesmo, seja por meio de adição de novas classes (instâncias do framework) e funcionalidades nas existentes, ou modificações na interface, ou mesmo, simples manutenção, como correção de bugs. As ferramentas utilizadas no desenvolvimento do trabalho (Qt Creator, Star UML, Weka, SVN no Google Code) foram utilizadas com o intuito de simplificar e facilitar o desenvolvimento, tendo peso em sua escolha o fato de serem livres e de fácil manuseio. Para trabalhos futuros de caráter geral, vislumbra-se a implementação de outros algoritmos de aprendizado de máquina a serem adicionados à instância do framework, como Redes Neurais Artificiais – RNA e C4.5, implementação de novas instâncias de Corpus, com outras metodologias e especializadas em diferentes tipos de arquivo, adição de outros elementos à interface, como ambiente de manipulação dos atributos do corpus e experimentos por cluster. Além disso, deseja-se fazer uma remodelagem das classes do projeto, de modo a construir uma arquitetura do software que possibilite um menor acoplamento entre as classes e, por conseguinte, simplifique a manutenção do sistema. Pretende-se também adicionar à interface, um conjunto de novas estatísticas, tanto para o corpus, quanto para os experimentos realizados. Finalmente, vislumbra-se a implementação de um webservice com as funcionalidades providas pelo FAMA.

52

6

REFERÊNCIAS BIBLIOGRÁFICAS

BEZERRA, E. Princípios de análise e projeto de sistemas UML. Campus, 2006. BRILL, E. A simple rule-based part of speech tagger. Em Proceedings of the Third Conference on Applied Natural Language Process, Trento, Italy, 1992. Association for Computational Linguistics. MITCHELL, T. Machine Learning. McGraw-Hill, 1997. NILSON, N. J., Introduction to machine learning. Stanford, 1998. 179 p. RABINER, L. R. A tutorial on hidden Markov models and selected applications in speech recognition. Proceedings of the IEEE, 1989. RIEHLE, D. Framework Design: A Role Modeling Approach. Ph.D. Thesis, No. 13509. Zürich, Switzerland, ETH Zürich, 2000. RUSSEL, S.; NORVIG, P. Artificial Intelligence: A modern approach. Prentice-Hall, 2002.

53

7

APÊNDICES Aqui nos apêndices é apresentada a documentação de software do projeto da interface.

A documentação é de grande importância ao projeto, pois facilita a propagação do conhecimento de software do mesmo, agilizando e simplificando sua compreensão. Consequentemente a documentação trará economia de tempo às pessoas envolvidas com o projeto futuramente. Primeiramente é feita uma análise de como se dá o levantamento de requisitos do projeto, em seguida são apresentados os casos de uso e os diagramas de classes participantes. 7.1 APÊNDICE 1 – REQUISITOS Os requisitos de desenvolvimento do projeto foram levantados principalmente de duas formas: a primeira é por meio do método da análise de conteúdo, na qual a ferramenta open source de mineração de dados de AM, Weka, serviu como base; outra forma é por meio da criação de protótipos a partir de um conjunto inicial de requisitos, no qual os autores e o orientador do projeto refinam os mesmos. 7.2 APÊNDICE 2 – CASOS DE USO O modelo de casos de uso é uma ferramenta capaz de representar, de modo satisfatório, as funcionalidades externamente observáveis do sistema e os elementos externos que interagem com o mesmo, sendo capaz de modelar os requisitos funcionais do sistema. Um caso de uso especifica, de modo pouco ou bastante detalhado, uma sequência completa de interações entre o sistema e o(s) agente(s) externo(s) ao sistema, não considerando o comportamento interno do mesmo, exibindo o sistema pela perspectiva externa (BEZERRA, 2006). Com base nos requisitos levantados é possível descrever algumas interações entre usuário e sistema, com base no modelo de casos de uso, que serão especificadas a seguir:

Caso de Uso 1: – Nome: Carregar CorpusMatriz – Ator Primário: Usuário – Ator Secundário: Não há

54

– Pré-condições: Não há – Fluxo Básico de Eventos: 1. Este caso de uso começa quando o usuário seleciona CorpusMatriz no tipo do corpus. 2. O sistema habilita as opções de abertura de arquivo e de configuração. 3. O usuário seleciona a opção de configuração. 4. O sistema exibe o formulário de configuração. 5. O usuário preenche o formulário de configuração e confirma. 6. O sistema armazena as informações preenchidas. 7. O usuário seleciona a opção de abrir arquivo. 8. O sistema exibe uma caixa de diálogos de abertura de arquivo. 9. O usuário seleciona o arquivo desejado e confirma. 10. O sistema carrega o arquivo selecionado e exibe informações do corpus e o caso de uso termina. – Fluxo Alternativo de Eventos: – CANCELAMENTO DE ABERTURA DE ARQUIVO 1. No passo 10 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar. 2. O sistema fecha a caixa de diálogos e retorna ao passo 6 do fluxo básico de eventos. – USUÁRIO SELECIONA A OPÇÃO ABRIR ARQUIVO SEM SELECIONAR AS OPÇÕES DE CONFIGURAÇÃO 1. No passo 4 do fluxo básico de eventos, se o usuário seleciona a opção abrir arquivo. 2. O sistema retorna ao passo 8 do fluxo básico de eventos. – CANCELAMENTO DAS OPÇÕES DE CONFIGURAÇÃO 1. No passo 6 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar das opções de configuração. 2. O sistema retorna ao passo 2 do fluxo básico de eventos. – ERRO EM ABERTURA DE ARQUIVO 1. No passo 10 do fluxo básico de eventos, se o arquivo não pôde ser carregado.

55

2. O sistema exibe uma mensagem de falha. 3. O usuário confirma a mensagem. 4. O sistema retorna ao passo 1 do fluxo básico de eventos. – Pós-condições: – O sistema carregou o arquivo selecionado e exibiu informações do corpus. – Outras informações: As informações exibidas após o carregamento do arquivo são: nome do corpus, quantidade de instâncias, número de atributos e lista de atributos. As informações presentes no formulário de configuração são: tipo de separador, dividir exemplos, atributos automáticos e número de atributos.

Caso de Uso 2: – Nome: Exibir Estatísticas – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o arquivo selecionado e exibiu informações do corpus – Fluxo Básico de Eventos: 1. Este caso de uso começa quando o usuário deseja visualizar as estatísticas de atributo selecionando um dos atributos da lista. 2. O sistema exibe as estatísticas de atributo e o caso de uso termina. – Fluxo Alternativo de Eventos: Não há – Pós-condições: O sistema exibiu as estatísticas de atributo. – Outras Informações: As estatísticas exibidas pelo sistema são: número de instâncias distintas, número de atributos com ocorrência única, média, desvio padrão, tipo do atributo, valor máximo, valor mínimo e ocorrências de um atributo.

Caso de Uso 3: – Nome: Escolher Treinador – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Este caso de uso começa quando o usuário seleciona um treinador.

56

2. O sistema habilita a opção de configuração do treinador. 3. O usuário seleciona a opção de configuração. 4. O sistema exibe o formulário de configuração de parâmetros. 5. O usuário preenche o formulário de configuração e confirma. 6. O sistema armazena as informações preenchidas e o caso de uso termina. – Fluxo Alternativo de Eventos: – CANCELAMENTO DO FORMULÁRIO DE CONFIGURAÇÃO 1. No passo 6 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar do formulário de configuração. 2. O sistema retorna ao passo 2 do fluxo básico de eventos. – Pós-condições: – O sistema armazenou as informações preenchidas. – Outras informações: Os possíveis treinadores a serem selecionados são: Mais Provável, Hidden Markov Model (HMM) e Transformation Based Learning (TBL).

Caso de Uso 4: – Nome: Executar o Método de Validação – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Este caso de uso começa quando o usuário seleciona o método de avaliação. 2. O sistema armazena o método de avaliação. 3. O usuário seleciona o atributo de treino. 4. O sistema armazena o atributo de treino. 5. O usuário informa o nome do novo atributo. 6. O sistema armazena o nome do novo atributo. 7. O usuário seleciona a opção de executar validação. 8. O sistema processa as informações previamente armazenadas. 9. O sistema exibe os resultados da validação e o caso de uso termina. – Pós-condições: – O sistema exibiu os resultados da validação. – Outras informações: O método de avaliação disponível é Ácurácia.

57

Os atributos de treino que podem ser selecionados são os atributos do corpus carregado.

Caso de Uso 5: – Nome: Executar Validação Treino – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Incluir caso de uso Escolher Treinador. 2. O usuário seleciona o método de validação de treino. 3. O sistema armazena o método de validação de treino. 4. Incluir caso de uso Executar o Método de Validação e o caso de uso termina. – Pós-condições: – O sistema exibiu os resultados da validação.

Caso de Uso 6: – Nome: Executar Validação Teste – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Incluir caso de uso Escolher Treinador. 2. O usuário seleciona o método de validação de teste. 3. O sistema armazena o método de validação de teste. 4. O usuário seleciona a opção de abrir arquivo. 5. O sistema exibe uma caixa de diálogos de abertura de arquivo. 6. O usuário seleciona o arquivo desejado e confirma. 7. O sistema exibe o formulário de configuração. 8. O usuário preenche o formulário de configuração e confirma. 9. O sistema armazena as informações preenchidas. 10. O sistema carrega o arquivo selecionado. 11. Incluir o caso de uso Executar o Método de Validação e o caso de uso

58

termina. – Fluxo Alternativo de Eventos: – CANCELAMENTO DE ABERTURA DE ARQUIVO 1. No passo 7 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar. 2. O sistema fecha a caixa de diálogos e retorna ao passo 3 do fluxo básico de eventos. – CANCELAMENTO DAS OPÇÕES DE CONFIGURAÇÃO 1. No passo 9 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar das opções de configuração. 2. O sistema retorna ao passo 3 do fluxo básico de eventos. – ERRO EM ABERTURA DE ARQUIVO 1. No passo 10 do fluxo básico de eventos, se o arquivo não pôde ser carregado. 2. O sistema exibe uma mensagem de falha. 3. O usuário confirma a mensagem. 4. O sistema retorna ao passo 3 do fluxo básico de eventos. – Pós-condições: – O sistema exibiu os resultados da validação.

Caso de Uso 7: – Nome: Executar Validação Kdobras – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Incluir caso de uso Escolher Treinador. 2. O usuário seleciona o método de validação kdobras. 3. O sistema armazena o método de validação kdobras. 4. O usuário seleciona a quantidade de dobras na validação cruzada. 5. O sistema armazena a quantidade de dobras. 6. Incluir caso de uso Executar o Método de Validação e o caso de uso termina.

59

– Pós-condições: – O sistema exibiu os resultados da validação.

Caso de Uso 8: – Nome: Executar Validação Divisão – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Incluir caso de uso Escolher Treinador. 2. O usuário seleciona o método de validação divisão. 3. O sistema armazena o método de validação divisão. 4. O usuário seleciona a porcentagem de divisão do corpus. 5. O sistema armazena a porcentagem de divisão. 6. Incluir caso de uso Executar o Método de Validação e o caso de uso termina. – Pós-condições: – O sistema exibiu os resultados da validação.

Caso de Uso 9: – Nome: Executar Treinamento – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Incluir caso de uso Escolher Treinador. 2. O usuário seleciona o atributo de treino. 3. O sistema armazena o atributo de treino. 4. O usuário seleciona a opção de executar treinamento. 5. O sistema processa as informações previamente armazenadas. 6. O sistema executa o treinamento. 7. O sistema exibe o tempo total do treinamento. 8. O usuário seleciona a opção de guardar o conhecimento gerado no treinamento.

60

9. O sistema exibe uma caixa de diálogos de salvar arquivos. 10. O usuário seleciona o arquivo desejado e confirma. 11. O sistema armazena o conhecimento no arquivo selecionado e o caso de uso termina. – Fluxo Alternativo de Eventos: – CANCELAMENTO DA OPERAÇÃO DE GUARDAR CONHECIMENTO 1. No passo 10 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar. 2. O sistema fecha a caixa de diálogos e retorna ao passo 6 do fluxo básico de eventos. – Pós-condições: – O sistema armazenou o conhecimento no arquivo selecionado. – Outras informações: Os atributos de treino que podem ser selecionados são os atributos do corpus carregado.

Caso de Uso 10: – Nome: Executar Classificação – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema carregou o corpus e exibiu sua informações. – Fluxo Básico de Eventos: 1. Este caso de uso começa quando o usuário seleciona um classificador. 2. O sistema armazena o classificador selecionado. 3. O usuário seleciona a opção de carregar conhecimento. 4. O sistema exibe uma caixa de diálogos de abertura de arquivo. 5. O usuário seleciona o arquivo desejado e confirma. 6. O sistema carrega o arquivo selecionado. 7. O usuário informa o nome do novo atributo. 8. O sistema armazena o nome do novo atributo. 9. O usuário seleciona a opção de executar classificação. 10. O sistema executa a classificação. 11. O sistema exibe o tempo total da classificação. 12. O usuário seleciona a opção de gravar o corpus gerado na classificação.

61

13. O sistema exibe uma caixa de diálogos de salvar arquivos. 14. O usuário seleciona o arquivo desejado e confirma. 15. O sistema armazena o corpus no arquivo selecionado e o caso de uso termina. – Fluxo Alternativo de Eventos: – CANCELAMENTO DA OPERAÇÃO DE CARREGAR CONHECIMENTO 1. No passo 6 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar. 2. O sistema fecha a caixa de diálogos e retorna ao passo 2 do fluxo básico de eventos. – CANCELAMENTO DA OPERAÇÃO DE GRAVAR CORPUS 1. No passo 14 do fluxo básico de eventos, se o usuário seleciona a opção Cancelar. 2. O sistema fecha a caixa de diálogos e retorna ao passo 10 do fluxo básico de eventos. – Pós-condições: – O sistema armazenou o corpus no arquivo selecionado. – Outras informações: Os possíveis classificadores a serem selecionados são: Mais Provável, Hidden Markov Model (HMM) e Transformation Based Learning (TBL).

Caso de Uso 11: – Nome: Executar Exportação de Dados – Ator Primário: Usuário – Ator Secundário: Não há – Pré-condições: O sistema executou a validação. – Fluxo Básico de Eventos: 1. Este caso de uso começa quando o usuário seleciona a opção de exportar dados. 2. O sistema carrega os parâmetros armazenados no experimento. 3. O sistema exibe os parâmetros armazenados no experimento na aba de treinamento/classificação e o caso de uso termina. – Fluxo Alternativo de Eventos: – USUÁRIO SELECIONA EXPORTAR PARA VALIDAÇÃO 1. No passo 2 do fluxo básico de eventos, se o usuário seleciona a opção de

62

exportar dados para validação. 2. O sistema exibe os parâmetros armazenados no experimento na aba de validação e o caso de uso termina. – Pós-condições: – O sistema exibiu os parâmetros armazenados no experimento na aba de treinamento/classificação. – O sistema exibiu os parâmetros armazenados no experimento na aba de validação. 7.3 APÊNDICE 3 – DIAGRAMA DE CLASSES PARTICIPANTES Uma visão de classes participantes (VCP) é um diagrama de classes cujos objetos presentes participam da realização de um determinado caso de uso. É recomendável que seja definida uma VCP para cada caso de uso. A construção da visão de classes participantes tem uma grande importância no que diz respeito à capacidade de adaptação a eventuais mudanças. Uma VCP bem modelada fornece atribuições específicas a cada objeto e as mudanças acabam se tornando menos complexas e mais localizadas (uma modificação em uma parte do sistema tem menos possibilidades de acarretar mudanças em outra parte) (BEZERRA, 2006). Com base nos casos de uso desenvolvidos na seção anterior, foram desenvolvidas as visões de classes participantes (VCP). Devido à limitação de tamanho, aqui são exibidas somente as VCPs simplificadas dos CDU 1, 2, 9, 10 e 11 a seguir:

63

FIG. 7.3.1 – Diagrama de visão de classes participantes do CDU 1.

FIG. 7.3.2 – Diagrama de visão de classes participantes do CDU 2.

64

FIG. 7.3.3 – Diagrama de visão de classes participantes do CDU 9.

FIG. 7.3.4 – Diagrama de visão de classes participantes do CDU 10.

65

FIG. 7.3.5 – Diagrama de visão de classes participantes do CDU 11.

66