| |
| Acadêmico(a): Henrique Machado Muller |
| Título: RunGroovy: Extensão do Bluej para Execução de Linhas de Código |
| |
| Conclusão: |
| O ambiente BlueJ é utilizado por inúmeras instituições de ensino superior nos cursos de computação e informática. Ao mesmo tempo em que ela é considerada uma ferramenta com recursos didáticos úteis na aprendizagem de POO como a criação e interação de objetos no próprio ambiente, ela é considerada falha em alguns aspectos na autoria (um editor com poucos recursos em relação à produtividade e auxílio na codificação) e representação das classes (o diagrama de classes considera as relações de herança e dependência, além de omitir informações sobre atributos e métodos). Porém, a ferramenta permite sua extensibilidade, isto é, implementar novos recursos no ambiente. No site do desenvolvedor existem publicados 17 extensões desenvolvidas por diversos autores (KÖLLING, 2007a). O desenvolvimento desse trabalho visou o estudo e compreensão na produção de extensões para a ferramenta BlueJ, gerando uma documentação introdutória e expertise sobre o assunto. A escolha de linguagem Groovy para criação destas linhas de código se deu por ser uma linguagem ágil, de script e também por sua familiaridade com Java diminuindo a sobrecarga cognitiva na aprendizagem de mais uma linguagem. No decorrer do desenvolvimento surgiram muitas dificuldades para a integração de Java, Groovy e o ambiente do BlueJ. A documentação de extensão é pouca e muito restrita. O resultado no desenvolvimento da extensão se deu em uma ferramenta de simples utilização e acesso alcançando todos os objetivos propostos. A flexibilidade na digitação de código também é um ponto forte na sua utilização, pois qualquer script Groovy pode ser executado na ferramenta. Outras características importantes que foram observadas na linguagem Groovy é que ela é totalmente compatível com a JVM e se integra facilmente com Java. Em relação às limitações com a ferramenta é possível observar que: a) há restrição com o acesso direto aos atributos públicos, pois não foi implementado este acesso, visto que isso não é uma boa prática de POO; b) os nomes dos objetos no script não refletem o nome dos objetos no ambiente. Não se conseguiu realizar esta intercepção nas linhas de comandos digitadas; c) os objetos criados e nomeados no script são validos na própria execução e não conseguem ser acessados em execuções posteriores. |
| |
|
