• Nenhum resultado encontrado

JLive 2. Avenida Teotônio Segurado, 1501 Sul, CEP , Palmas TO Brasil.

N/A
N/A
Protected

Academic year: 2021

Share "JLive 2. Avenida Teotônio Segurado, 1501 Sul, CEP , Palmas TO Brasil."

Copied!
10
0
0

Texto

(1)

JLive 2

Djonathas C. Cardoso1, Jackson G. de Sousa1, Parciline F. de Brito1

1Sistemas de Informação – Centro Universitário Luterano de Palmas (CEULP/ULBRA)

Avenida Teotônio Segurado, 1501 Sul, CEP 77.019-900, Palmas – TO – Brasil

{djonathas,jackson.souza,parcilene}@gmail.com

Resumo. Algo imprescindível na grade de ensino de um curso da área de

computação é uma disciplina que aborde a lógica de programação, pois esta é a base para o aprendizado das demais linguagens. Para que esta tarefa de aprendizado seja mais interessante e estimuladora, o uso de uma ferramenta ou aplicação dedicada a lógica de programação é um suporte para quem está começando a se aventurar neste novo paradigma. Desta forma, nasce o projeto JLive 2, um editor de código-fonte acadêmico baseado em uma plataforma totalmente web, sem a necessidade de instalação, acessível de qualquer lugar e com a portabilidade dos códigos dos usuários, já que são salvos na nuvem. Este trabalho tem por objetivo descrever todo o processo de desenvolvimento desta ferramenta.

1 Introdução

Na esfera do aprendizado na área de Tecnologia da Informação, algo imprescindível na grade de ensino é uma disciplina que aborde a lógica de programação, pois esta é a base para o aprendizado das demais linguagens. West define lógica como a forma correta de organizar os pensamentos e demonstrar um raciocínio de maneira formal (WEST, 2013). Desta forma, lógica de programação pode ser definida como a aplicação da lógica sobre a programação, tendo vital importância para este campo. Forbellone e Eberspacher adotam a mesma linha de pensamento, quando afirmam que o uso correto da lógica na programação contribui na racionalidade e o desenvolvimento de técnicas que cooperem para a produção de soluções logicamente válidas e coerentes, que resolvam com qualidade os problemas que se deseja programar (FORBELLONE; EBERSPACHER, 2000).

Para que essa tarefa de aprendizado seja mais interessante e estimuladora, o uso de uma ferramenta ou aplicação dedicada a lógica de programação é um suporte para quem está começando a se aventurar neste novo paradigma. Foi seguindo esta linha de raciocínio que professores da disciplina de Algoritmos dos cursos de Computação do CEULP/ULBRA desenvolveram uma ferramenta desktop em Java chamada JLive. Esta ferramenta tem o intuito de ser semelhante a uma IDE, porém, sendo muito mais simplificada, e voltada apenas para lógica de programação. A figura a seguir mostra a interface única da aplicação.

(2)

Figura 15 - Interface do JLive

Conforme a Figura 15, a interface do JLive é bastante simples: composta por três

menus, um botão Executar, a área de inserção do código e uma área de saída da compilação. O menu Arquivo é composto de 5 opções, sendo elas: Novo, Abrir, Fechar, Salvar e Sair. Já o menu Editar possui opções relacionadas à edição do código, como Copiar, Recortar, Colar e

Selecionar Tudo. O último menu, o Sobre, abre uma janela com informações do sistema. O

botão Executar é utilizado para compilar o código inserido na área dedicada a inserção do código pelo usuário, que fica logo abaixo do botão, e por fim, abaixo desta área fica localizada outra área, responsável por mostrar a saída da compilação do código.

Além de uma interface simplificada, o JLive propõe uma linguagem simplificada. Com base em observações, os professores propuseram uma simplificação do vocabulário Java, voltada para o português. Assim, foram fornecidas funções como as seguintes:

a) imprima(): para

imprimir saída na tela (a exemplo da função System.out.println()) b) leiaInt(): para leitura de número inteiro; e

c) leiaString(): para leitura de string.

Ainda, foi proposta uma simplificação da estrutura do código: ao invés da obrigação de começar com uma declaração de classe padrão do Java (public class ... ) o programa basta estar contido entre chaves. A figura seguir apresenta um trecho de código.

(3)

A Figura 16 mostra um exemplo de código feito no JLive. Por padrão, o código

inicia-se com a abertura de chave, conforme explicado no parágrafo anterior. Em inicia-seguida são declaradas duas variáveis do tipo primitivo int, depois é executada a função leiaInt para atribuir valores a estas variáveis através da entrada de dados do usuário. Por fim, é declarada uma nova variável chamada soma que realiza a soma das outras duas anteriores e finaliza imprimindo esse valor na tela do usuário através do comando imprima.

Atualmente, o JLive é utilizado no auxílio ao aprendizado de lógica de programação nos cursos de computação do CEULP/ULBRA. Porém, a plataforma na qual foi desenvolvida, Java para desktop, sempre ocasionou problemas e dificuldades na sua disseminação entre os alunos, pois exige o download da ferramenta e a instalação do Java JDK. Outra dificuldade é quando o usuário utiliza a ferramenta em diversos computadores, já que o código, embora possa ser salvo em arquivo, requer do aluno gerenciar o local de salvamento e posterior leitura.

Como uma forma de resolver estas questões, foi proposto o desenvolvimento de uma nova versão do JLive, sob o objetivo de criar uma versão web que iria manter todo seu funcionamento básico, mas resolvendo as dificuldades citadas anteriormente, além de adicionar recursos que ajudariam e facilitariam o acesso ao sistema. Esta ferramenta, chamada JLive 2, é o resultado deste trabalho. O presente trabalho, resultado do estágio supervisionado realizado pelo autor principal, sob orientação do prof. Jackson Gomes, apresenta o processo de desenvolvimento do JLive 2, bem como detalhes dele e da arquitetura definida para sua estruturação, além de considerações sobre conclusões e trabalhos futuros.

2 Desenvolvimento

O JLive 2 surgiu com uma missão: proporcionar um ambiente de auxílio para o aprendizado de lógica de programação, tendo como suas funcionalidades a compilação e armazenamento de algoritmos de forma online baseado no usuário, que pode utilizar sua conta da rede social Facebook. Desta forma, a base da arquitetura do JLive 2, ao invés de um software desktop, é a estrutura de um software baseado na web, o qual requer dois elementos básicos: o servidor web, que executa e dá acesso ao software; e o cliente, que é utilizado diretamente pelo usuário e é representado por um web browser.

Para que o sistema pudesse realizar uma compilação seguindo uma sintaxe semelhante ao Java, foi utilizado o BeanShell, que é a biblioteca usada nesse projeto e que permite interpretar e compilar códigos com a linguagem Java

Tendo em vista estas características, a arquitetura do JLive 2 foi pensada em uma divisão de três camadas bem definidas, sendo elas: Dados, Processamento e Interface. Cada camada é composta por outros itens, alguns dos quais se relacionam com outros da mesma camada como também de outras camadas. Porém, como as camadas são organizadas no formato de pilha, um item de uma camada só pode se comunicar com itens da mesma camada ou itens da camada imediatamente superior ou inferior a ela. A figura a seguir apresenta as três camadas que integram a arquitetura do sistema, para melhor entendimento.

(4)

Figura 17 - Arquitetura do JLive 2

Como pode ser observado na Figura 17, cada camada é composta por dois itens que

interagem entre si. As models, controllers e views, que formam o modelo MVC do JLive 2, são os únicos que se comunicam entre uma camada e outra, com exceção dos dois módulos do Facebook SDK, que se comunicam diretamente entre si, mesmo estando em camadas diferentes. O Facebook SDK é um rico conjunto de funcionalidades do lado do cliente para adicionar Social Plugins e possibilitar a implementação de autenticação no sistema usando o Facebook.

Grails é um framework para construção de aplicações para web através da linguagem de programação Groovy. Segundo o site do Grails, seu principal objetivo é criar um

framework web de alta produtividade para a plataforma Java (GRAILS, 2014). Para isso ele

utiliza tecnologias consideradas maduras do mundo Java, como os frameworks Hibernate e Spring, através de uma interface que busca ser simples e consistente (GRAILS, 2014).

As próximas seções demonstram o funcionamento das camadas do sistema bem como os elementos que as constituem.

2.1 Camada de Dados

A Camada de Dados é responsável pelo armazenamento dos dados registrados durante o uso do sistema. A camada é composta por dois itens: models e banco de dados. As models mapeiam o banco de dados de forma que o sistema possa acessar e gravar dados no mesmo. Desta forma, as outras partes do sistema não acessam diretamente o banco, precisando utilizar a model correspondente à tabela da qual se quer obter ou na qual se deseja gravar dados. A figura a seguir ilustra o modelo físico do banco de dados do sistema.

Dados

Banco de

Dados

Models

Processamento

Controllers

Facebook SDK Plugin

Interface

Views

Facebook SDK

(5)

Figura 18 - Modelo físico do banco de dados do sistema

Conforme o diagrama mostrado na Figura 18, cada usuário pode ter vários códigos

cadastrados e vinculados a si, porém todo código precisa obrigatoriamente pertencer a um único usuário. Resumindo, a Camada de Dados armazena os dados dos usuários, os códigos-fonte que os mesmos produzem e também a identificação do usuário no Facebook, caso este tenha optado pelo vínculo com a rede social. A próxima seção descreve a Camada de

Processamento e suas divisões.

2.2 Camada de Processamento

A Camada de Processamento é a principal camada do ambiente e permite a comunicação entre models e views. Em outras palavras, boa parte das funcionalidades do sistema passam por esta camada, sendo composta principalmente por controllers. Além das controllers, a

Camada de Processamento integra o plugin do Grails que se comunica diretamente com a

SDK do Facebook. As controllers no Grails exercem a mesma função descrita no modelo MVC, ou seja, realizar a interação entre as models e views, neste caso, as domains e views.

As controllers que compõem o sistema são CodigoController, EditorController e

UsuarioController, as quais são detalhadas a seguir.

2.2.1 UsuarioController

A controller UsuarioController tem como objetivo gerenciar os usuários do sistema, além disso também realiza a comunicação com o plugin do Facebook, para obtenção dos dados do usuário, e permite acesso ao sistema.

Na UsuarioController existem diversas funções, denominadas actions, que interligam e intermediam as domains e as views, dentre elas estão: create, edit, save e update, que são as funções de manipulação do banco de dados, geradas automaticamente pelo framework Grails, além das actions login e logout. O próximo tópico aborda as características e composição da CodigoController.

(6)

2.2.2 CodigoController

A CodigoController gerencia os códigos-fonte criados pelo usuário no sistema. O escopo desta controller incluem actions responsáveis por carregar, atualizar, listar e excluir os códigos gerados pelo usuário. Os códigos são gerados a partir do editor de código-fonte, que é gerenciado por outra controller, a EditorController.

O item a seguir apresenta a descrição e a utilidade de EditorController, que é a principal do sistema.

2.2.3 EditorController

Além de ser a controller mais importante do sistema, a EditorController também é a maior em termos de linhas de código e também de complexidade, pois é nela que fica armazenada toda a lógica e processamento do processo de interpretação e compilação dos códigos enviados ao JLive 2 (o qual será apresentado posteriormente). Ela é dividida em 12 actions, dentre as quais três são públicas e redirecionam o usuário para uma view; as demais são privadas e auxiliares de outras, de forma a possibilitar um melhor reuso de código e organização do mesmo. A figura a seguir mostra a classe com todas suas respectivas actions.

Figura 19 – Classe EditorController

A seguir será detalhado o funcionamento das três principais actions do sistema: index,

compilar e compileEngine.

2.2.3.1 Action index

A action index foi projetada para receber dois parâmetros, idcodigo e codigo. O primeiro recebe a identificação do código-fonte anteriormente salvo pelo usuário e verifica se o mesmo existe e pertence ao usuário autenticado, somente nestas condições ele será exibido no editor. Já o segundo parâmetro recebe o código enviado para compilação pelo usuário, de forma que seja possível carregá-lo no editor. Após as verificações executadas nesta action, o usuário é redirecionado a view index.

A action compilar é a base de grande parte do processo de interpretação e compilação, além de ser a maior e mais complexa das actions, também é dela que parte a

(7)

2.2.3.2 Action compilar

A action compilar é a responsável por receber, interpretar e compilar o código produzido e enviado pelo usuário através da view index. Antes de realizar o processo de compilação propriamente dito, a primeira ação feita é acionar a action save, que garante que o código será salvo antes de iniciar o processo de compilação.

Como o BeanShell não tem suporte nativo para envio de solicitações do servidor para o cliente, a compilação direta dele deixa de ser efetiva. Portanto foi necessário criar um procedimento para interpretação manual com a finalidade de identificar os comandos leia* (entrada de dados) e retornar uma entrada de dados Javascript ao lado cliente na view index. Esse procedimento foi nomeado neste projeto como interpretação linha a linha, que basicamente funciona da seguinte forma: quando o usuário aciona o botão para compilar o código, o sistema percorre linha por linha em busca de comandos que não executam diretamente pelo BeanShell. Esses códigos são então tratados e convertidos de forma que possam ser compilados diretamente pelo BeanShell. A figura a seguir ilustra como o código-fonte digitado pelo usuário é transformado pela interpretação do JLive.

Figura 20 - Funções leia: (A) Antes da entrada do usuário, (B) Depois da entrada do usuário

Conforme a Figura 20, o usuário inseriu 4 linhas de código no sistema, duas com

impressão na tela e duas com entrada de dados. Neste caso, o BeanShell sozinho não é capaz de apresentar a tela de entrada de dados ao usuário dos comandos leiaString e leiaInt presentes no código, pois ele só consegue interagir no lado servidor. Assim entra em ação uma das funções da interpretação linha a linha: identificar entrada de dados e convertê-la em um código Javascript que irá proporcionar essa entrada no lado cliente. Uma vez que o

usuário entra com os dados (Figura 20-A), o sistema substitui o texto da entrada de dados pelo

valor do usuário (Figura 20-B), de forma que agora já é possível a compilação direta pelo

BeanShell. O trecho de código a seguir mostrar como o JLive identifica essa entrada de dados e a seu tratamento para ser exibida na tela do usuário.

Código 1 - Verificação e tratamento das funções leia*

Conforme o Código 1, a primeira condição if (linha 100) é uma expressão regular que

verifica se na linha atual da interpretação contém uma das funções leia (leiaString, leiaInt, leiaFloat, leiaDouble, leiaBoolean, leiaChar). A segunda condição if (linha 102) verifica se a interação atual já contém uma entrada de dados do usuário, caso verdadeiro, o sistema substitui o texto da entrada de dados pelo valor informado pelo usuário, o resultado é o

(8)

acionada, sua função é capturar o texto para ser exibido na tela do usuário e gravá-lo na variável entrada, que por sua vez será retornada a view onde será exibida dentro da janela de entrada de dados Javascript.

Porém, uma problemática detectada na primeira definição desse processo de interpretação foi na ocorrência de um comando de entrada de dados dentro de um bloco condicional ou um laço. Isso é um problema devido ao sistema, até então, exibir a tela de entrada mesmo se a condição fosse falsa, já que a interpretação só considerava a existência de comandos do tipo leia*. Para resolver isso, foram criadas diversas outras verificações durante o processo da interpretação linha a linha para identificar e tratar a existência de condicionais (if e else) e laços (while e for) no código-fonte do usuário. O código a seguir ilustra a primeira parte do processamento manual de interpretação.

Código 2 – Trecho da primeira parte do processo de interpretação linha a linha

Conforme o trecho demonstrado no Código 2, existem alguns condicionais que utilizam expressões regulares para identificar e tratar o código de forma que este fique pronto para a compilação direta pelo BeanShell (linhas 65, 66, 71-73, 78, 79). Cada condicional existente verifica a existência de blocos de condicionais e laços. Caso seja identificado um condicional, o sistema verifica se a condição contida nele é verdadeira para então continuar a interpretação dentro do bloco do mesmo. Já se for um laço, o sistema verifica a condição inicial e então inicia um processo de loop com a interpretação linha a linha dentro do bloco desse laço, porém sempre verificando se a condição se mantém verdadeira em cada interação. A seção seguinte abordará o funcionamento da action responsável pela compilação direta do código.

2.2.3.3 Action compileEngine

Esta action é responsável por realizar a compilação direta do código com o BeanShell, para tanto o código necessita estar no formato correto para a compilação ocorrer da forma devida, tarefa que é responsabilidade da action anterior, compilar. A próxima seção fala um pouco

(9)

2.3 Camada de Interface

A Camada de Interface é responsável pela interação direta com usuário, sendo composta pelas views e a integração do Facebook, feita através da sua SDK.

A view index, que pertence à EditorController, pode ser considerada a mais importante do sistema, uma vez que o editor de código-fonte está localizado nela. A view é constituída de três elementos fundamentais, o nome do código, a área do editor e a área de

saída da compilação. A figura a seguir mostra estes três elementos e a estrutura da view da

forma que ela é apresentada ao usuário.

Figura 21 – Visão do usuário da view index da EditorController

A

Figura 21 mostra a composição da view index, conforme mencionado anteriormente, dividida

pelos seus três elementos principais. Além disso, a área do editor também é composta por diversos botões que influenciam diretamente no que é feito dentro do editor. A seguir é apresentada a lista com todos os componentes da view conforme a numeração mostrada na Figura 21.

1. Nome do código

2. Área do editor de código 3. Área de saída da compilação 4. Botão Executar

5. Botão Salvar 6. Botão Desfazer 7. Botão Refazer

8. Botão Aumentar Tamanho de Fonte 9. Botão Diminuir Tamanho de Fonte

1

4 5 6 7 8 9 10

2

(10)

10. Botão Tela Cheia

3 CONSIDERAÇÕES FINAIS

O desenvolvimento deste trabalho foi bastante árduo, com o surgimento de diversos imprevistos que ocasionaram em mudanças na estrutura do sistema e, muitas vezes, sendo até necessário mudar a lógica de programação.

O maior contratempo no desenvolvimento foi um procedimento de entrada de dados do usuário, pois isto impossibilitou o uso direto do BeanShell no seu trabalho de interpretação e compilação, onde foi necessário intervir e criar um procedimento próprio de interpretação manual, denominado interpretação linha a linha. Apesar do problema da entrada de dados já ter sido previsto desde o início do trabalho, não eram previstos os problemas que isso geraria na compilação, quando este tipo de código estivesse contido dentro de um bloco if, else, while e for. Este problema acontece devido que a interpretação linha a linha, no seu conceito inicial, só buscava por entrada de dados no código do usuário, logo, mesmo se uma entrada estivesse dentro de um if ou um while, ele o executaria normalmente, sem considerar a condição do if ou as interações do while.

Entretanto, os procedimentos incluídos na interpretação linha a linha proporcionaram o fim do problema com os blocos anteriormente mencionados. Também foi possível, com este trabalho, obter-se uma versão estável e funcional do JLive 2, que inclusive foi liberada para alguns alunos em caráter de teste.

Depois do período de testes, o JLive 2 foi liberado para uso público por qualquer

pessoa. Hoje o sistema encontra-se disponível pelo link

http://sandbox.ulbra-to.br:8081/JLive2/.

O JLive 2 é só o início de um projeto maior, com foco na melhoria do aprendizado na lógica de programação. Este projeto a ser desenvolvimento tem por objetivo criar uma ferramenta que tenha características de gamificação e que possa, com isso, contribuir e estimular os alunos no aprendizado em disciplinas que envolvem lógica de programação.

4 Referências

FORBELLONE, André Luiz Villar; EBERSPACHER, Henri Frederico. Lógica de

programação. Makron Books, 2000.

GRAILS, 2014. Portal Grails. Disponível online: <https://grails.org/>. Acesso em: 09/06/2014.

WEST, Marcelo. Lógica de Programação. Disponível em

Referências

Documentos relacionados

Cinema, então, além de atividade industrial, sempre foi, também, moeda de troca girando em rodadas de negócios, em busca de financiamento, retorno de investimento (para

Parágrafo único – Em caso de descumprimento do previsto no caput deste artigo, deverá ser imediatamente comunicado o fato ao Presidente do STJD que poderá

Paciente, RCC, 22 anos, sexo masculino, compareceu à clínica integrada da Faculdade de Odontologia da Universidade Fede- ral de Goiás (FO/UFG) com queixa principal de “meus dentes

Neste trabalho avaliamos as respostas de duas espécies de aranhas errantes do gênero Ctenus às pistas químicas de presas e predadores e ao tipo de solo (arenoso ou

Não deveríamos esperar conservação da energia cinética, embora a força externa resultante e o torque resultante sejam nulos, porque existem forças internas

Nos dois primeiros animais do presente relato, os sinais clínicos foram discretos e mais associados às doenças concomitantes, o que dificultou a inclusão da dirofilariose

Quanto ao Trabalho de Conclusão de Curso, discentes de pós-graduação, (81%) Docentes (86%) e Gestores (85%) consideram importante. Fazer trabalho de divulgação e

Descrição Detalhada do Objeto Ofertado: Contratação eventual, mediante registro de preços, de empresa especializada em serviços de infra-estrutura de rede com manutenção