Merlin: Interfaces CRUD Em Tempo de Execução

Marcelo Mrack1, Álvaro de Freitas Moreira2, Marcelo Pimenta2

13Layer TecnologiaPorto Alegre, RS – Brazil

2Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)Porto Alegre – RS – Brazil

marcelo@3layer.com.br, {afmoreira,mpimenta}@inf.ufrgs.br

Abstract. This article presents a software called Merlin. Merlin is a free tool that generates CRUD interfaces at runtime. Using a model-based approach with support to rules binding, Java input interfaces can be generated with high usability and minimum effort. Taking advantage of standards like Java Annotations, the software aims to take a low learning courve. Furthermore, an exclusively feedback mechanism are used, enhancing the system pro-activity.

Resumo. Este artigo apresenta o software Merlin. O Merlin é uma ferramenta livre para geração de interfaces CRUD em tempo de execução. Utilizando uma abordagem baseada em modelos e possibilitando a ligação de regras de negócio através da programação dirigida a eventos, ele é capaz de gerar interfaces de edição de dados para sistemas Java com grande usabilidade e mínimo esforço. Usando padrões de mercado como o Java Annotations, o produto visa uma rápida assimilação pelas equipes de desenvolvimento. Além disso, a ferramenta conta com um exclusivo mecanismo de realimentação, o que eleva sua pró-atividade a cada uso.

1. Introdução

A geração automatizada de interfaces de usuário (IU) é objeto de estudo há longo tempo [Hayes et al. 1985]. Entre as propostas idealizadas nesse período, a abordagem baseada em modelos (model-based approach) [Schlungbaum e Elwert 1996] recebeu muitos adeptos e, conforme destaca [Myers 1995], representa o futuro para a construção das IU. Como exemplos de iniciativas que utilizam esse paradigma, podem ser citadas as ferramentas JANUS, TRIDENT, TADEUS e GENIUS [Schlungbaum e Elwert 1996].

Entretanto, segundo [Pribeanu e Vanderdonckt 2002], o excesso de formalismo na definição dos modelos, a utilização de linguagens proprietárias e a busca por soluções genéricas, as quais implicam em um elevado grau de configuração, acabam dificultando a adoção dessas ferramentas em ambientes reais de desenvolvimento.

Não obstante, problemas de cunho operacional também acabam surgindo. Entre eles, podem ser citados o pequeno suporte a refatoração do código-fonte produzido, dificuldades de obter respostas rápidas às mudanças do projeto e a ausência de pontos para extensão e integração de recursos.

Diante desse cenário, e motivado por necessidades profissionais relativas a melhorias no processo de construção de IU para sistemas de banco de dados, foi iniciado em 2002 o projeto de um software para o preenchimento dessas lacunas. Para dar uma visão geral desse projeto e sintetizar as principais características da solução idealizada, esse artigo divide o seu conteúdo no seguinte formato: A seção 2 apresenta o projeto, elencando suas principais características e arquitetura. A seção 3 mostra um exemplo ilustrado e comentado de uso da ferramenta. A seção 4 conclui o artigo, expondo os resultados obtidos até o momento e os direcionamentos do trabalho.

2. O projeto Merlin

2.1. Histórico

O projeto Merlin (em alusão ao mago) tem início em 2004, com a retomada em âmbito pessoal de um trabalho anterior, denominado Metagen [Mrack e Moreira 2003]. Com a sua arquitetura revista, o software fora portado para a linguagem Java, objetivando o suporte multiplataforma e um maior número de ferramentas e frameworks de apoio.

2.2. Foco em interfaces CRUD

Entre as características mantidas da proposta inicial, está o foco nas interfaces CRUD (do inglês Create, Retrieve, Update and Delete), também conhecidas como telas de cadastro. Esse posicionamento se deve a pesquisas realizadas internamente no ambiente profissional, as quais evidenciaram que as interfaces CRUD representam, em média, 65% das telas em sistemas que operam sobre banco de dados.

2.3. Características

Em ordem de relevância, as principais características da ferramenta Merlin são:

1. Geração da IU em tempo de execução: Usando uma abordagem de interpretação em tempo de execução, nenhum código-fonte é gerado para as interfaces. Entre as vantagens dessa técnica, os testes indicam (i) a disponibilidade imediata de protótipos reais (basta a classe de dado estar disponível); (ii) a diminuição de erros de programação e (iii) a resposta imediata a mudanças, permitindo alterações no sistema (como a adição de campos na IU) mesmo durante a sua execução.

2. Configuração realimentada: Como em [Nichols 2004], o uso de informações históricas na auto-configuração do sistema é explorado em profundidade. Através de um mecanismo próprio de gerência e estimativas, comportamentos de sucesso, como esquemas de layout, uso de validadores de conteúdo e associação de regras de negócio a componentes de IU, podem ser transparentemente reutilizados e propagados. Todo esse mecanismo opera sobre informações federadas de contexto, seja em nível de sistema, pacote, classe, propriedade, método ou evento.

3. Facilidade para ligação de regras de negócio: A programação dirigida a eventos (event-driven programming) [Eiffel 2006], é utilizada como forma de ligar controles de tela, eventos e regras de negócio sem dependências sintáticas.

4. Abordagem totalmente baseada no modelo de dados: Como único ponto de trabalho do programador está o conjunto de classes de dados do sistema, o que

evita mecanismos externos para armazenamento de informações, como banco de dados ou arquivos binários.

5. Reuso de padrões de mercado e integração: Entre outros, padrões como Java Annotations [Java 2006], Hibernate Annotations [Hibernate 2006] e Enterprise Java Beans [EJB3 2006] são utilizados para decoração do modelo de dados.

6. Ambiente multiplataforma: Implementado em Java 5 e possuindo uma camada abstrata para representação dos elementos da IU, a solução pode operar sobre pacotes gráficos diferentes, como o Swing (desktop) e o Java Server Faces (web).

7. Suporte a estruturas mestres-detalhe de múltiplos níveis: Tal como em [Balzert 1995], regras de navegação são inferidas automaticamente a partir das relações existentes entre os dados do modelo, possibilitando tanto a geração de telas simples quanto mestre-detalhe (1-n e n-n) de vários níveis.

8. Usabilidade, consistência, e internacionalização: Regras de usabilidade, como “reduza a perda de espaço” ou “mantenha próximas informações relacionadas” [Bodart et al. 1995] são automaticamente aplicadas pelos algoritmos de posicionamento. Informações de legado sobre conteúdo internacionalizado e validação também são transparentemente reutilizadas. Todo esse comportamento pode ser sobrescrito através da configuração ou da implementação de interfaces e classes disponibilizadas, tornando-se parte do sistema de histórico (realimentação).

2.4. Arquitetura e Processo de Desenvolvimento

A figura 1 exibe a arquitetura do software, bem como o processo de desenvolvimento utilizando o seu paradigma:

Tempo de projeto Tempo de execução

Roundtrip

ProgramadorProgramador

Anotações EJB3Anotações HibernateAnotações MerlinCrie suas anotações!

Anotações EJB3Anotações HibernateAnotações MerlinCrie suas anotações!

javacjavac

manualCASEetc.

leituraleitura

leituraleitura

<<Anotações Java>>Meta-informações

<<Classe Java>>Modelo de dados

CAFE . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .

geração

Interface CRUD

Merlin

Módulo interpretador

Arquivo .java Arquivo .class

ConfiguraçãoArquivo .properties

Sistema cliente

Figura 1. Arquitetura e processo de desenvolvimento utilizando o Merlin.

Os elementos da figura são assim descritos:

1. Programador: Responsável pela criação do modelo de dados. Ele pode fazer isso manualmente ou utilizando qualquer processo automatizado, como ferramentas CASE, máquinas de template, engenharia reversa, etc.

2. Modelo de dados: Uma estrutura orientada a objetos, representada pelas classes de dados da aplicação. A ferramenta aqui descrita assume que esse modelo já esteja disponível e, durante a execução, a interface CRUD gerada itera sobre o conteúdo desse modelo apenas em memória. É tarefa do programador preocupar-se com a persistência do objeto ao final da sessão do usuário.

3. Meta-informações: Descritas através de anotações [Java 2006], são elementos opcionais que agregam semântica ao modelo, aumentando a qualidade das interfaces produzidas. Objetivando o reuso, anotações do Hibernate e EJB3 são automaticamente reconhecidas. Além disso, o software disponibiliza suas próprias anotações e permite ao programador criar as suas. Entre as informações que podem ser descritas pelas anotações citam-se: tamanhos de campos, uso de validadores de conteúdo, máscaras, layout de tela, ligação de regras de negócio, etc.

4. Arquivo compilado: São os arquivos compilados (.class) do modelo de dados gerados pelo compilador Java.

5. Sistema final: É o software cliente desenvolvido. Ele contém as chamadas ao módulo interpretador, as quais se resumem à invocação do método de fachada createIhc. É nesse método que ocorrem os processos envolvidos na geração da IU, como a interpretação da configuração, das anotações e do histórico de uso.

6. Módulo interpretador: É o conjunto de classes e interfaces que compõe o software Merlin. Empacotadas em um arquivo de distribuição Java (.JAR) encapsulam toda a complexidade do processo de geração das interfaces CRUD.

7. Configuração: É o arquivo (.properties) que armazena o conjunto de configurações do sistema em construção. Opcionalmente, esse arquivo pode indicar a ativação do mecanismo de realimentação; nesse caso informações históricas são automaticamente computadas e acrescidas ao processo de geração das IU.

8. Interface CRUD: É a interface de usuário gerada pelo método createIhc. Corresponde a um container de IU (no Swing, um JPanel) com todos os controles necessários para a edição de um objeto do sistema. Se esse objeto for uma estrutura hierárquica, uma IU mestre-detalhe é produzida. Todas as características dessa IU são baseadas em padrões de mercado e podem ser sobrescritas pelo desenvolvedor.

9. Roundtrip: É o processo contínuo de refatoração do sistema. Utilizando como informação de geração os arquivos compilados, basta que o programador efetue modificações no modelo de dados para que a correspondente interface de usuário esteja disponível, mesmo com esse em execução.

Ainda, com base na figura, se percebe claramente dois momentos distintos no processo. No tempo de projeto, o programador define as características do modelo de dados e o comportamento esperado para o sistema através das anotações e ajustes na configuração. No tempo de execução, o módulo interpretador “renderiza” a IU com base nos arquivos compilados do modelo de dados e na configuração fornecida.

3. Exemplo de uso

Nesta seção, um pequeno exemplo de uso é mostrado. Nele, é apresentada a interface CRUD gerada e o respectivo código-fonte do modelo de dados decorado com as meta-informações. Um fragmento de código da aplicação cliente também é exibido.

Figura 1. Interface CRUD gerada e o código-fonte do modelo de dados.

Nesse exemplo é gerada uma interface simples para edição de um objeto do tipo Telefone. Nela, a propriedade nome é herdada da classe ancestral DispositivoMovel. O software automaticamente mapeia o controle mais adequado com base no tipo de dado (exemplo, caixas de seleção para propriedades enumeradas e atributos de referência). A anotação @Dependence do tipo ENABLEMENT indica que o controle correspondente à qtdeMinima somente é habilitado quando isQtdeMinima for assinalado. Já especificacao é mapeado para uma caixa de texto de várias linhas, pois este atributo é considerado (pela configuração ou com base no histórico) um texto longo. Ainda, sobre esse atributo existe um agente [Eiffel 2006], o qual aciona a regra de negócio ValidarConteudo no evento focusLost do controle. Essa regra de negócio pode ser um mapeamento para um método do próprio objeto de dados, ou um serviço externo, como um webservice. Os descritivos dos controles (à esquerda) são montados a partir dos nomes dos atributos em conjunto com serviços externos de correção ortográfica e internacionalização.

Todo esse funcionamento é encapsulado no código cliente através de uma chamada ao método de fachada createIhc, como abaixo:

Telefone objetoTelefone = new Telefone();JPanel panelDados = Merlin.createIhc(objetoTelefone,false);JFrame frame = new JFrame(“Cadastro”);frame.add(panelDados, BorderLayout.CENTER);frame.add(panelBotoesPadrao,BorderLayout.SOUTH);frame.setVisible(true);

Figura 2. Fragmento de código da aplicação cliente.

Nesse fragmento, o código cliente (uma aplicação Swing) instancia um objeto do tipo Telefone. Logo após uma chamada à Merlin.createIhc é efetuada. Como parâmetros estão o objeto instanciado e um valor false, o qual indica que os controles de tela não devem ser preenchidos com os dados do objeto. Como retorno do método está um objeto do tipo JPanel que contém os respectivos controles de edição. Este é inserido em um JFrame e então exibido ao usuário.

@Caption("Cadastro de telefones celulares")public class Telefone extends DispositivoMovel { MarcaDeTelefone marca; String modelo; Fornecedor fornecedor; @Caption("Quantidade mínima") @Dependence("qtdeMinima", type=ENABLEMENT) boolean isQtdeMinima; int qtdeMinima; @Agent( event="focusLost", action="ValidarConteudo" ) String especificacao;}public enum MarcaDeTelefone { SONY, LG, NOKIA;}

4. Conclusões

Esse artigo apresentou as características gerais do software Merlin, uma ferramenta para geração de interfaces CRUD em tempo de execução para a linguagem Java.

Utilizando uma abordagem baseada em modelos e um mecanismo de realimentação, ele permite a geração de IU para plataformas desktop e web, suportando telas mestre-detalhe e a adição de regras de negócio. A configuração centrada em anotações e arquivos de propriedades cria uma estrutura auto-contida, que elimina a necessidade de recursos ou sistemas externos para o armazenamento das informações necessárias para a geração das interfaces.

Atualmente, o Merlin é tema de mestrado na UFRGS e principal produto em desenvolvimento pela 3Layer Tecnologia. O projeto está disponibilizado sob licença Eclipse em http://merlin.dev.java.net e deve ter uma versão estável em 2007.

5. Referências bibliográficas

[Balzert 1995] Balzert, H.. “From OOA to GUI - The JANUS-System”. INTERACT. 1995.

[Bodart et al. 1995] Bodart, F.; Hennebert, A. M.; Leheureux, J.M.; Vanderdonckt, J.. “Computer-Aided Window Identification in TRIDENT”. INTERACT, 1995.

[Eiffel 2006] Event Driven Programming. Disponível em http://docs.eiffel.com/eiffelstudio/docs_no_content.html. Abril, 2006.

[EJB3 2006] Enterprise Java Beans Specification. Disponível em www.jcp.org/en/jsr/detail?id=220. Abril, 2006.

[Hayes et al. 1985] Hayes, P.J.; Szekely, P.A.; Lerner, R.A.. “Design Alternatives for User Interface Management Systems Based on Experience with COUSIN”. International Conference on Human Factors in Computing Systems. 1985.

[Hibernate 2006] Hibernate Annotations. Disponível em http://www.hibernate.org. Abril, 2006.

[Java 2006] Java Annotations. Em http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html. Abril, 2006.

[Mrack e Moreira 2003] Mrack, M.; Moreira, D.. “Sistemas Dinâmicos Baseados em Metamodelos” II Workshop de Computação e Gestão da Informação. 2003.

[Myers 1995] Myers, B.A.. “User Interface Software Tools”. ACM Transactions on Computer-Human Interaction, Vol. 2, No. 1. 1995.

[Nichols 2004] Nichols, J. Automatically Generating User Interfaces for Appliances. Annual ACM Symposium on User Interface Software and Technology. 2004.

[Pribeanu e Vanderdonckt 2002] Pribeanu, C.; Vanderdonckt, J.. “Exploring Design Heuristics for User Interface Derivation from Task and Domain Models”. CADUI. 2002.

[Schlungbaum e Elwert 1996] Schlungbaum, E.; Elwert T.. “Automatic User Interface Generation from Declarative Models”. CADUI. 1996.