Diagrama de Classes

A implementação do compilador foi realizada adotando o modelo de desenvolvimento orientado a objetos. Neste modelo, o diagrama de classes representa a estrutura do sis- tema, possuindo informações sobre métodos, atributos, nome das funções e como estas são integradas entre si. A Figura 4.14 representa o diagrama de classes do compilador integrado ao ambiente. Como podemos ver, o compilador é constituído por cinco classes principais.

A classe analisadorSintatico é a principal do compilador, ela é a responsável por rea- lizar a análise sintática e gerenciar a escrita do código intermediário em um arquivo, além de fazer as chamadas para compilação deste. As suas principais funções são writeOnFile, responsável pela escrita no arquivo texto, analyse, responsável por análisar que regra da gramática está me uso, e wordTest, que verifica a validade completa da sentença.

A classe TestCondition é a classe responsavél pela verificação da validade de uma condição inserida em um controlador de fluxo. A classe ControlFlowStatement é respon- sável por verificar a validade de sentenças que utilizam controles de fluxo e realizar a escrita destas no arquivo. Possui funções relativas a cada controlador de fluxo presente na linguagem R-Educ. Já a classe Mapeamento é a responsável por gerenciar o acesso ao banco de dados e fornecer os dados para escrita à classe analisadorSintatico.

4.5. COMUNICAÇÃO E ENVIO 49

4.5

Comunicação e Envio

A proposta do ambiente de desenvolvimento configurável implementado neste tra- balho não inclui apenas fornecer ao usuário um ambiente de desenvolvimento onde é possível programar em várias linguagens e realizar a tradução entre as linguagens cadas- tradas e a linguagem R-Educ, mas sim um ambiente que, além disso, permite ao usuário estabelecer comunicações com diversas plataformas robóticas. Qualquer dispositivo com acesso a um navegador web - computadores, notebooks, tablets, etc - podem acessar o ambiente, que está conectado à Internet através de um servidor e implementar e compilar seu programa e, caso tenha recursos capazes de executar ou estebelecer comunicação com o hardware fazê-lo.

Figura 4.15: Diagrama de conexões

A Figura 4.15 apresenta o diagrama de conexões do sistema. Neste, podemos obser- var que existem um servidor onde o processamento do ambiente é realizado, este servidor estabelece comunicação com os dispositivos computacionais, sejam eles computadores, tablet, smartphones ou notebooks, através de um navegador web. E estes últimos se co- municam com os dispositivos robóticos que possuem compatibilidade através de cabo de dados ou através de algum mecanismo de comunicação sem fio.

O envio de dados ao dispositivo robótico ou execução do código gerado é feito através de chamadas de sistemas, fornecidas pelo usuário no momento do cadastro da linguagem. Essa chamada de sistema é feita via applet Java.

50 CAPÍTULO 4. AMBIENTE PROPOSTO

Java instalada e assinar o certificado digital requerido para que a applet possa ter acesso e executar operações no computador local. Ressaltamos que para a comunicação entre o dispositivo computacional local e o dispositivo robótico é necessária, dependendo da pla- taforma robótica utilizada e forma de envio, uma compatibilidade de hardware, podendo ser necessário ao usuário a instalação de drivers específicos.

4.6

Ambiente de Desenvolvimento

Para realizar a programação em R-Educ e demais linguagens cadastradas pelo usuário foi desenvolvido um ambiente web utilizando APIs específicas do Java EE. O ambiente desenvolvido é executado online, o que permite uma maior disseminação da ferramenta, visto que a escrita e compilação do código pode ser realizada através de qualquer disposi- tivo com acesso a um navegador web, sendo toda a capacidade computacional requerida apenas ao servidor. Além disso, o fato da ferramenta ser web torna descenessária a insta- lação de programas auxíliares.

Figura 4.16: Ambiente de desenvolvimento

A tela principal do ambiente é apresentada na Figura 4.16. A página possui recursos para salvar, compilar, enviar , fazer download e upload do código em R-Educ e na lingua- gem cadastrada. Possui na lateral esquerda, uma lista com os programas cadastrados para essa linguagem no servidor, os quais podem ser escolhidos para edição pelo usuário.

O ambiente possui na lateral esquerda uma área destinada aos resultados, nesta o usuário é informado se seu código foi salvo ou deletado com sucesso, se o arquivo foi

4.6. AMBIENTE DE DESENVOLVIMENTO 51

compilado com sucesso e se não foi, o ambiente informa, para compilações em linguagem R-Educ, a descrição do erro e em que linha ele se encontra. Além disso, caso o programa seja compilado com sucesso é gerado um programa na linguagem cadastrada que pode ser visualizado pelo usuário; sendo assim, é possível fazer estudos comparativos entre os códigos escritos e gerados.

Ainda na lateral esquerda é encontrada uma lista de robôs que podem ser seleciona- dos e trocados pelo usuário durante a programação, sem a necessidade de recarregar o ambiente. Caso o usuário realize a troca de robô, a linguagem associada a este será então utilizada na tradução e compilação de código final.

Outra funcionalidade deste ambiente de programação é que, caso a linguagem tenha sido cadastrada com erros, o código gerado pelo usuário vai ser compilado com sucesso em R-Educ, porém o usuário será informado que houve um erro ao cadastrar a linguagem, visto que foi encontrado um erro na compilação final.

Capítulo 5

Resultados

O projeto e desenvolvimento do ambiente de desenvolvimento web configurável para aplicações em robótica educacional levou em consideração a proposta de ser utilizado como ambiente de desenvolvimento por alunos a partir de 8 anos até estudantes universi- tários, ou até mesmo qualquer pessoa interessada em aprender sobre robótica. Atendendo, assim, a todo o público alvo dos níveis três e cinco da linguagem de programação R-Educ. Levamos em consideração a proposta de que o projeto deveria ter um ambiente de cadastro de linguagens de programação para robótica, que pudesse ser facilmente uti- lizado por usuários experientes na linguagem e por usuários leigos em conhecimentos específicos dessa linguagem que ao receber informações do usuário experiente pudessem cadastrar com sucesso uma nova linguagem e fazer uso dela.

Realizando uma análise a partir destas primitivas, verificamos que o ambiente de ca- dastro deveria possuir uma série de atributos e guias explicativos que auxiliassem no ca- dastro de linguagens de programação. Além disso desenvolvemos o ambiente de progra- mação de forma que seus usuários pudessem ter um maior aproveitamento dos recursos disponíveis em uma oficina de robótica, contribuindo assim para o seu aprendizado e aumento da criatividade.

Neste Capítulo apresentaremos e discorreremos sobre as seis etapas de teste que foram realizadas. Além disso apresentaremos os resultados obtidos e alguns comentários dos usuários que participaram dos testes.

5.1

Testes

A realização dos testes do ambiente de cadastro, ambiente de programação e suas fun- cionalidades foram divididos em seis etapas que avaliaram o uso da ferramenta em todos os estágios de seu desenvolvimento e seu uso por usuários experientes e inexperientes em linguagens de programação aplicadas a robótica.

54 CAPÍTULO 5. RESULTADOS

5.1.1

Primeira Etapa

A primeira etapa dos testes foi realizada assim que o desenvolvimento do ambiente teve a sua primeira versão finalizada. Nesta etapa, verificamos que a linguagem de pro- gramação mais utilizada e conhecida por o grupo de pesquisa do laboratório NatalNet era a linguagem NXC para programação de robôs Lego Mindstorms NXT. Com isso julga- mos ser essa a primeira linguagem que deveria ser cadastrada e testada, visto que, caso a ferramenta funcionasse apenas para essa linguagem já seria de grande contribuição.

O cadastro da linguagem foi realizado por um usuário experiente, que possui conhe- cimentos específicos, já trabalhando e ministrando oficinas de robótica com ela desde o ano de 2008. Este usuário, avaliou o ambiente de cadastro e relatou que o formulário não estava fornecendo dados suficientes para que o cadastro fosse realizado de forma sa- tisfatória, sugeriu que fosse realizada uma verificação ao finalizar o cadastro de que as palavras solicitadas tenham sido utilizadas corretamente.

Apesar dos impasses encontrados, o cadastro da linguagem NXC para programação de robôs Lego Mindstorms NXT foi realizado com sucesso. Neste cadastro foram inclusas funções essenciais para participações em competições escolares de robótica.

5.1.2

Segunda Etapa

A segunda etapa foi realizada em um treinamento para participação da Olimpíada Brasileira de Robótica 2013, o foco desta etapa do teste foi avaliar o funcionamento do ambiente de desenvolvimento.

O treinamento contou com a participação de 25 pessoas as quais podem ser divididas em três grupos:

• Grupo 1: Estudantes do ensino fundamental com faixa etária média de 13 anos e conhecimentos de robótica;

• Grupo 2: Estudantes do ensino superior da área de tecnologia;

• Grupo 3: Estudantes do ensino superior com conhecimentos específicos de robó- tica.

O primeiro treinamento seguiu as etapas básicas de uma oficina de robótica educaci- onal. Primeiramente foi apresentada a situação problema que era a resolução da prova do ensino fundamental da etapa regional da Olímpiada Brasileira de Robótica - OBR2013, resgate com robôs. Uma aula expositiva foi realizada, levando os participantes a refletirem sobre como deveria ser o robô e qual seria a melhor estratégia para a sua programação. Em seguida eles foram desafiados a montar um robô que fosse apto a realizar o desafio. Ao

5.1. TESTES 55

término o ambiente de desenvolvimento foi apresentado e as formas de programação dis- poníveis até o momento (programação em linguagem NXC e programação em R-Educ), foram introduzidas aos participantes.

(a) Montagem do robô utilizando o kit Lego Mindstorms NXT

(b) Apresentação do ambiente de programação

(c) Programação utilizando o ambiente web

Figura 5.1: Etapas do treinamento para a OBR 2013

Ao término da apresentação do ambiente de programação os usuários acharam inte- ressante o fato de que eles poderiam intercambiar entre seus programas gerados em NXC e R-Educ com apenas um clique. Além disso, um subgrupo do Grupo 1, relatou que pos- suía experiência em linguagem Java, e questionou se seria possível utilizar o ambiente programando em Lejos, linguagem baseada em Java utilizada para programação de robôs Lego, já que a proposta do trabalho era inclusão de qualquer linguagem de programação. Outro aluno, participante de um projeto de pesquisa, relatou que trabalhava com progra- mação utilizando o módulo de programação do Arduino e questionou se seria possível utilizar o ambiente para realizar a programação destes.

Foi então dado início a programação dos robôs, parte dos integrantes do Grupo 1 optou por utilizar a linguagem R-Educ, por ser uma linguagem em português e de fácil

56 CAPÍTULO 5. RESULTADOS

entendimento, outra parte do Grupo 1, decidiu esperar para que a linguagem Lejos fosse cadastrada no ambiente. Já os participantes dos Grupos 2 e 3 foram incitados a programar em NXC, já que esta é uma linguagem baseada em C, semelhante a que eles fazem uso em seus trabalhos acadêmicos. Um dos usuários do Grupo 2, questionou sobre a possibilidade de realizar o envio do programa ao robô via Bluetooth.

A Figura 5.1 apresenta a segunda etapa dos testes, a Figura 5.1(a) mostra usuários do Grupo 1 realizando a montagem. A Figura 5.1(b) apresenta a etapa de apresentação do ambiente e a Figura 5.1(c) um usuário do Grupo 2 realizando a programação utilizando o ambiente.

Durante os testes, alguns usuários encontraram problemas com o sistema devido a instabilidade da Internet. Além disso, por o sistema ainda não possuir um módulo de cadastro de usuário, todos os que estavam programando no ambiente tinham acesso aos programas dos demais. Avaliamos a necessidade de inclusão de mais funções na lingua- gem NXC para que a realização do desafio pudesse ser feito de forma mais eficiente. Todos os participantes conseguiram utilizar o ambiente.

5.1.3

Terceira Etapa

Após a primeira e segunda etapas de teste, realizamos uma avaliação das necessidades, críticas e requisições apresentadas pelos participantes das etapas anteriores.

O ambiente de programação foi avaliado de acordo com as observações dos partici- pantes da primeira etapa de testes. Inserimos opções para download do código gerado para o computador local. Preparamos o sistema para que as chamadas de envio que utilizas- sem alguma porta de comunicação do computador local fosse feita de forma satisfatória atendendo ao pedido do participante de possibilitar o envio via Bluetooth.

Quanto a primeira etapa de testes, realizamos uma reformulação do ambiente de ca- dastro de linguagens, para tal inserimos mais textos explicativos de cada campo do ca- dastro e reestruturamos sua interface gráfica a fim de que este ficasse mais intuitivo. Im- plementamos um sistema para realizar a verificação do texto inserido em cada campo checando e informando caso alguma das palavras requisitadas não tenham sido inseridas.

5.1.4

Quarta Etapa

Na quarta etapa dos testes solicitamos que um usuário experiente em programação estudasse algumas linguagens de programação para robótica e elaborasse guias com os dados necessários para cadastro.

5.1. TESTES 57

As linguagens escolhidas foram a linguagem NXC, cadastrada e utilizada nas etapas anteriores, a linguagem Lejos, solicitada por participantes de Grupo 1 da segunda etapa e a linguagem CCS para programação de robôs H-Educ, desenvolvido no mesmo laboratório deste trabalho.

A linguagem NXC é uma linguagem baseada em C que para ser compilada utiliza um compilador executável que não precisa ser instalado no servidor. Para que os códigos compilados desta linguagem sejam enviados ao robô o sistema também deve enviar o compilador utilizado para a máquina local, além disso, o envio dos códigos pode ser feito via Bluetooth ao robô caso essa funcionalidade esteja disponível e a chamada de sistema de envio seja modificada.

A linguagem Lejos é uma linguagem baseada em Java que para ser compilada utiliza um compilador que necessariamente precisa ser instalado no servidor. Além disso para que o envio do código compilado ao robô seja enviado o compilador também deve estar instalado no dispositivo computacional local. Os códigos traduzidos de R-Educ para Lejos devem formar classes com o mesmo nome do arquivo salvo, esse tratamento é fornecido por completo pelo tradutor desenvolvido, não sendo necessários campos extras a serem preenchidos no cadastro de linguagens.

CCS é um compilador utilizado para programação em linguagem C de microcontrola- dores da marca PIC. Incluímos o seu cadastro neste trabalho visto que ela é a linguagem utilizada para programação de robôs H-Educ, desenvolvido por Sá (2011), para o funci- onamento do H-Educ um código auxiliar deve ser utilizado. Sendo assim, a geração de arquivos desta linguagem deve conter um cabeçalho com todas as funções e estabeleci- mentos de pinos necessários. Essa linguagem nos permite visualizar o quanto é possível transparecer aos usuários a dificuldade da programação fazendo uso do ambiente desen- volvido neste trabalho.

Figura 5.2: Sequência de geração de arquivos

58 CAPÍTULO 5. RESULTADOS

mencionadas. A primeira linha da figura representa a sequência de arquivos gerada para a linguagem CCS, ao solicitarmos a compilação com um código escrito corretamente em R-Educ, será gerado um código .c que ao ser processado pelo compilador CCS deverá gerar um arquivo .hex. A segunda e terceira linha representam a mesma sequência de geração para as linguagens NXC e Lejos respectivamente.

O usuário experiente gerou os guias de cadastro para cada uma dessas linguagens bem como selecionou os arquivos que deveriam ser enviados para o servidor para prover a compilação e envio.

5.1.5

Quarta Etapa

Na quarta etapa de testes selecionamos um grupo para realizar o cadastro das lingua- gens NXC, CCS e Lejos no ambiente de cadastro a partir dos guias elaborados na etapa anterior. Este grupo pode ser dividido em três, sendo o primeiro, correspondente a 23%, sem conhecimento em programação, o segundo, correspondente a 64%, com conheci- mentos básicos em programação e o terceiro, correspondente a 13%, com conhecimentos específicos em linguagens de programação para robótica.

Foram realizados um total de 17 cadastros de linguagens, sendo o cadastro realizado com sucesso por 70% dos participantes, a maioria dos erros cometidos foi ocasionado por esquecimento de elementos chaves da sintaxe do código. Não sendo realizada a compila- ção completa devido a este erro.

Figura 5.3: Conhecimento necessário para cadastro

Na Figura 5.3 apresentamos um gráfico que mostra a avaliação dos participantes do grupo de testes quanto ao conhecimento necessário da linguagem pelo usuário para que este realize o cadastro. O nível de conhecimento está representado de 0 a 5 no eixo

5.1. TESTES 59

x onde 0 representa nenhum conhecimento e 5 representa muito conhecimento. Como podemos ver, foi avaliado pela maioria dos participantes que era necessário no mínimo um conhecimento intermediário da linguagem para que o cadastro pudesse ser realizado.

Figura 5.4: Gráfico comparativo entre dificuldade de cadastro e conhecimento necessário

O gráfico apresentado na Figura 5.4, apresenta uma avaliação comparativa entre o nível de conhecimento necessário para o cadastro de cada item solicitado e a dificuldade de cadastro de cada um. Os dados do gráfico foram obtidos a partir de uma pesquisa com os participantes que avaliaram o grau de dificuldade e o nível de conhecimento necessários para cadastro de cada item individualmente. Cada participante avaliou de 0 a 8 o nível de dificuldade, o gráfico apresenta o somatório das avaliações de cada item.

Ainda nos dados da Figura 5.4 podemos observar que o item que foi julgado como o que requer um maior nível de conhecimento da linguagem foi o de compilação e en- vio, visto que o usuário precisa saber as chamadas de sistema para compilação e precisa referenciar corretamente o diretório a ser acessado.

5.1.6

Quinta Etapa

A quinta e última etapa de testes foi realizada imediatamente após a quarta. Visto que os participantes do grupo de cadastro foram solicitados a testar o funcionamento de sua linguagem.

60 CAPÍTULO 5. RESULTADOS

dulo de programação após realizarem o cadastro e utilizar um programa de teste presente no guia fornecido. Após inserir o seu código, o participante teve que selecionar o seu robô dentre a lista de robôs associados a linguagens cadastradas, compilar o código em R-Educ, em seguida teve de abrir o código gerado na extensão da linguagem cadastrada e realizar novamente a compilação a fim de verificar que que o código traduzido foi gerado corretamente. Em seguida, caso o envio fosse possível, devido as limitações técnicas do participante, o envio deveria ser realizado.

Nesta etapa, alguns dos participantes que cadastraram a linguagem com algum tipo de erro, se depararam com uma mensagem informativa ao solicitar a compilação em R-Educ. Visto que, com erros de cadastro, o código é traduzido com sucesso para a extensão da linguagem cadastrada porém a compilação completa não é satisfeita.

O gráfico apresentado na Figura 5.5 apresenta a avaliação dos participantes do grupo de teste quanto a complexidade relacionada com algumas funcionalidades do ambiente de desenvolvimento, tais como: seleção de robôs, troca de linguagens, compilação e envio do programa. Cada um destes itens foi avaliado em uma escala de 0 a 5 onde 0 representa muito fácil e 5 representa muito difícil.

Figura 5.5: Complexidade atribuída às funcionalidades do ambiente de programação

Podemos observar, a partir dos dados obtidos e apresentados, que todos os participan- tes julgaram o ambiente de desenvolvimento como sendo de fácil utilização.

Nos Algoritmos 6, 7 e 8, apresentamos o código traduzido para cada uma das lin- guagens cadastradas pelos participantes - NXC, Lejos e CCS respectivamente - a partir

5.1. TESTES 61

de um código básico, apenas com a rotina principal, escrito em R-Educ, apresentado no Algoritmo 5.

Algorithm 5 Código escrito em R-Educ

i n i c i o fim

O código escrito em R-Educ apresenta apenas os dados básicos para que a compilação seja satisfeita. Observe que no Algoritmo 6, apenas a inicialização da função principal é realizada.

Algorithm 6 Código traduzido de R-Educ para NXC

t a s k main ( ) { }

O código traduzido para Lejos, diferentemente do traduzido para a linguagem NXC, possui inclusões de bibliotecas, estas inclusões foram inseridas no campo do cadastro re- ferente ao cabeçalho, e são inseridas em todos os códigos traduzidos para esta linguagem. Podemos observar também que para que os códigos escritos em Lejos funcionem eles de- vem possuir uma classe com o mesmo nome do arquivo salvo. Este tratamento é realizado a partir da utilização da palavra "nomedoprograma"no cabeçalho.

Algorithm 7 Código traduzido de R-Educ para Lejos

i m p o r t l e j o s . n x t . B u t t o n ; i m p o r t l e j o s . n x t . LCD ; i m p o r t l e j o s . n x t . Motor ; i m p o r t l e j o s . u t i l . Delay ; p u b l i c c l a s s nomedoprograma { p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) { } }

O código traduzido para a linguagem CCS, apresentado no Algoritmo 8, teve parte de