JHeat: framework para geração de aplicações

Transcrição

1 CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO PIAUÍ CURSO DE SISTEMAS DE INFORMAÇÃO JHeat: framework para geração de aplicações Mário Sérgio Coelho Marroquim Teresina, outubro de 2006.

2 2 CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO PIAUÍ CURSO DE SISTEMAS DE INFORMAÇÃO JHeat: framework para geração de aplicações Mário Sérgio Coelho Marroquim Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso e apresentada ao Curso de Sistemas de Informação do Centro Federal de Educação Tecnológica do Piauí, como pré-requisito para a obtenção do título de Tecnólogo em Sistemas de Informação. Orientador: Prof. Erick Baptista Passos Teresina, outubro de 2006.

3 3 Homens convictos são prisioneiros Nietzsche

4 4 Dedico este trabalho a todas as pessoas que contribuíram em maior ou menor grau não apenas com essa realização minha, mas, principalmente, com quem eu sou.

5 5 AGRADECIMENTOS Em primeiro lugar, agradeço à minha família cujo apoio me fortalece a cada dia. Aos professores Erick Passos, Adalton Sena e Ney Paranaguá pelas incontáveis vezes que me corrigiram e me orientaram na melhor maneira de realizar esse trabalho. Aos meus amigos, colegas e demais professores que de alguma forma contribuíram para o meu crescimento.

6 6 SUMÁRIO LISTA DE FIGURAS LISTA DE ABREVIATURAS E SIGLAS RESUMO ABSTRACT INTRODUÇÃO O PADRÃO PARA APLICAÇÕES J2EE O PADRÃO MVC O VASTO USO DE FRAMEWORKS QUAL É O PROBLEMA? GERAÇÃO DE CÓDIGO ATUALMENTE O JHEAT ARQUITETURA CAMADA DE MODELO CAMADA DE VISÃO CAMADA DE CONTROLE UTILIZAÇÃO CADASTROS FLUXOS SEQUÊNCIAIS COMPLEXOS FUNCIONAMENTO DA GERAÇÃO O ARQUIVO PRINCIPAL DE CONFIGURAÇÃO CONCLUSÃO REFERÊNCIAS ANEXO A LISTA DE GERADORES DE APLICAÇÕES ANEXO B LISTA DE FRAMEWORKS CITADOS ANEXO C CÓDIGO-FONTE DA APLICAÇÃO DE EXEMPLO... 37

7 7 LISTA DE FIGURAS Figura 1 arquitetura MVC...13 Figura 2 esquema da geração da camada de visão...19 Figura 3 organização de telas para CRUD...20 Figura 4 trecho da classe Usuario...21 Figura 5 trecho do mapeamento JHeat para a classe Usuario...22 Figura 6 listagem gerada para a classe Usuario...22 Figura 7 tela de cadastro/alteração gerada para a classe Usuario...23 Figura 8 tela de detalhes gerada para a classe Usuario...23 Figura 9 subdivisão de um fluxo em passos...24 Figura 10 trecho do mapeamento JHeat para o fluxo de alteração de senha...25 Figura 11 tela do fluxo de alteração de senha...26 Figura 12 configurações gerais da aplicação...27 Figura 13 tela de login gerada pelo JHeat...28 Figura 14 tela inicial com as abas (sections)...28 Figura 15 esquema geral de arquitetura do JHeat e do processo de geração...29 Figura 16 estrutura de pastas para um projeto que usa JHeat...29

8 8 LISTA DE ABREVIATURAS E SIGLAS J2EE XML HTML JSP CSS AJAX MVC SQL PDF CSV MDA UML CRUD API Java 2 Enterprise Edition extensible Markup Language HyperText Markup Language Java Server Pages Cascading Style Sheets Asynchronous Javascript And XML Model-View-Controller Structured Query Language Portable Document File Comma-separated Values Model Driven Architecture Unified Modeling Language Create, Retrieve, Update and Delete Application Programming Interface

9 9 RESUMO O desenvolvimento de aplicações em Java para o ambiente web (J2EE) pode envolver a utilização de diversos frameworks e gerenciamento de seus inúmeros arquivos de configuração. Além disso, vários trechos de código acabam se repetindo em muitos projetos. Geralmente são relacionados à construção de interface gráfica (páginas HTML, JSP, arquivos CSS e JavaScript) e a requisitos não-funcionais como autenticação, validação de dados, controle do fluxo de páginas, gerenciamento de layouts e geração de LOG's, entre outros. A geração de código veio para acelerar o desenvolvimento dessas aplicações, com ferramentas que geram esse código burocrático, evitando o desgaste de se gerenciar o uso de vários frameworks bem como a repetição da codificação dos requisitos acima citados. Atualmente, boa parte dos geradores de aplicações para o ambiente web são pagos e pouco eficientes, pois carecem de recursos avançados de customização, entre outros problemas, citados ao longo do trabalho. Essa monografia descreve o desenvolvimento e funcionamento do JHeat: um framework, de código 100% livre, para geração de aplicações comerciais escaláveis, fáceis de manter e customizáveis. O propósito é gerar aplicações completas utilizando os melhores frameworks de código aberto existentes como o Hibernate, Struts, DisplayTags, DWR, Ajax Tags, CeWolf e JfreeChart, retirando do programador preocupações com a configuração dessas ferramentas e com a criação e manutenção desse código burocrático e repetitivo. Palavras-chave: Java, J2EE, framework, geração de código, XML, JHeat.

10 10 ABSTRACT The development of Java web applications (J2EE) can involve using diverse frameworks and the management of their configuration files. Besides, there is a repetition of many code stretches in several projects. Generally they are related to the graphical interface construction (HTML pages, JSP, CSS files and Javascript) and non-functional requirements such as authentication, data validation, control of the page flows, layout management and generation of LOG's, among others. Code generation came to speed up the development of these applications, with tools that generate this "burocratic" code, avoids stressful management of using several frameworks as well as the repetition of the requirements codification above cited. Currently, mainly generators of web applications are paid and ineffective, because there is a need for advanced resources of customization, among other problems. This paper describes the development and functioning of the JHeat: an opensource framework that generates scalable, easy to maintain and customizable commercial applications. The purpose is to generate complete applications using the best opensource frameworks like Hibernate, Struts, DisplayTags, DWR, Ajax Tags, CeWolf and JfreeChart, removing from the programmer concerns with the configuration of these tools and with the creation and maintenance of this burocratic and repetitive code. Keywords: Java, J2EE, framework, code generation, XML, JHeat.

11 11 1 INTRODUÇÃO Mesmo com vasta utilização de padrões de projeto e de variados frameworks, existe uma parcela considerável de código que acaba sendo repetida em cada projeto. Isso acontece freqüentemente em módulos ligados à lógica de autenticação, construção de interfaces gráficas, controle de fluxo, tratamento de erros e manutenção de registros de auditoria. De certo modo, a maioria dessas funcionalidades, cujo código é implementado sempre de forma similar, representa um conjunto de requisitos não-funcionais desses projetos. É o chamado "código burocrático". Em grande parte, são funcionalidades que não são esperadas (ou até mesmo conhecidas) pelo usuário final e que, por representarem requisitos comuns a muitos sistemas, exigem dos desenvolvedores um trabalho repetitivo que tende a gerar muitos erros, como veremos ao longo desta monografia. O fato é que a codificação dessas funcionalidades em vários projetos, além do gerenciamento de diversos frameworks e seus arquivos de configuração, pode se tornar uma tarefa cansativa, repetitiva e falível, prejudicando o ciclo de desenvolvimento com muitas linhas de código que não agregam nenhuma lógica de negócio a esses sistemas. O principal objetivo dos frameworks de geração de código é eliminar essa grande etapa de desenvolvimento de código burocrático, gerando, a partir de configurações feitas pelo desenvolvedor, parte do código em algumas camadas da aplicação [1]. Esse trabalho tem como objetivo demonstrar o desenvolvimento e uso de um novo framework de geração de aplicações para a web em Java, o JHeat, e como o desenvolvimento de aplicações para a plataforma J2EE pode ser elevado a novos patamares de produtividade e confiabilidade através da geração de código. Ao longo do texto serão apresentados conceitos básicos sobre as tecnologias envolvidas no desenvolvimento web em Java, as ferramentas para geração de código existentes e detalhes sobre o framework JHeat, seguidos pela conclusão.

12 12 2 O PADRÃO PARA APLICAÇÕES J2EE 2.1 O PADRÃO MVC Com o intuito de se obter uma boa organização interna e, conseqüentemente, facilidade de manutenção nas aplicações, foram criados diversos padrões para separar o seu código em camadas. Essa prática produz código menos complexo e melhor de se entender, facilitando seu desenvolvimento e manutenção [2] [3] [5]. O principal padrão é o MVC (Model-View- Controller) que define três camadas básicas para uma aplicação [2] [3] [4] [5]: Model Camada de modelo onde são implementados todas as regras de negócio e o acesso à base de dados; View Camada de visão, responsável pela interface gráfica das aplicações. No ambiente web isso significa todas as páginas, figuras, arquivos JavaScript, CSS, etc; Controller Camada intermediária que interliga as outras duas, processando as requisições do usuário (na camada de visão) para a camada de negócio. É constituída, no caso da arquitetura J2EE, de classes Java chamadas de servlets. Boa parte dos requisitos não-funcionais está nessa camada. Ex.: controle de fluxo de páginas, autenticação e controle de acesso, entre outros. Esse padrão é uma das soluções encontradas pelos desenvolvedores para promover o desacoplamento entre partes específicas de uma aplicação [2] [3] [5]. Isso significa controle centralizado dos recursos utilizados, como conexão com o banco de dados, e diminuição de código duplicado. Com o padrão MVC, o designer de interfaces gráficas pode trabalhar normalmente com CSS, JavaScript ou Flash, sem se preocupar com lógica de negócio e conexão com a base de dados, preocupações relevantes apenas para os desenvolvedores que cuidam da camada de modelo, como analistas. Essa é a chamada separação de interesses. Assim, torna-se fácil modificar uma aplicação, pois as funcionalidades estão organizadas em camadas bem definidas, facilitando processos de depuração. Veja a arquitetura MVC na figura 1:

13 13 Chamada de métodos Model Contém a lógica de negócio e controla a conexão com o banco de dados Chamada de métodos View Provê a visualização do modelo Envia as requisições do usuário para o Controller Composto de Páginas JSP, arquivos CSS, JavaScript, etc Chamada de métodos Requisições do usuário Controller Define o comportamento da aplicação Processa e valida as requisições do usuário Figura 1: arquitetura MVC 2.2 O VASTO USO DE FRAMEWORKS É improvável que uma aplicação de médio ou grande porte não utilize alguns frameworks. Afinal, eles apresentam muitas soluções para problemas comuns a vários projetos. Geralmente na camada de modelo são utilizados frameworks para persistência de dados, como o Hibernate, a fim de facilitar o desenvolvimento, retirando do programador preocupações com comandos SQL e mapeamento de atributos das classes para atributos na base de dados. O seu uso, ou de similares, elimina uma boa parte do tempo de desenvolvimento [6]. Já na camada de controle podem ser utilizados diversos frameworks MVC como o Struts, WebWork ou Spring MVC. Essas ferramentas encapsulam funcionalidades comuns a vários projetos como autenticação, controle de fluxo de páginas e validação das entradas do usuário (dados de formulários, por exemplo), entre outras. O uso correto desses frameworks ajuda o desenvolvedor a programar correto com código seguindo a arquitetura MVC sem, por exemplo, misturar comandos SQL com código HTML [5]. Na camada de visão muitos componentes gráficos podem ser renderizados dinamicamente com o uso de alguns frameworks. As DisplayTags geram tabelas dinâmicas (a partir de dados fornecidos pelo desenvolvedor) com links para paginação de resultados, exportação dos dados em PDF, Excel ou CSV, além de ordenação automática por qualquer coluna da tabela. Podem-se usar as CeWolf Tags, que utilizam outro framework, o JfreeChart, para construir gráficos de todas as formas e cores em tempo de execução.

14 14 É cada vez mais comum uso da tecnologia Ajax para gerar interfaces gráficas ricas e usáveis na web [7]. Serviços como o Gmail, del.icio.us e Flickr utilizam muito o poder desse novo conceito, levando a Internet a novos padrões de usabilidade. Para se utilizar todas essas novidades é necessário o uso de alguns frameworks como DWR, Dojo, Rico, AjaxTags ou Script.aculo.us [7]. 2.3 QUAL É O PROBLEMA? Como visto, para se criar uma aplicação robusta, escalável e com as tecnologias mais novas, é necessário o conhecimento desses diversos frameworks, além do gerenciamento de suas configurações. Isso é necessário, pois não é saudável e produtivo reinventar a roda, codificando funcionalidades que já estão implementas em alguma dessas ferramentas [5]. Paralelamente, é necessário muito trabalho do desenvolvedor para criar seus Servlets para pesquisas, cadastros, relatórios, autenticação, etc. Também é necessário esforço na criação de layouts CSS, arquivos JavaScript, páginas JSP e seus mapeamentos (para fins de redirecionamentos das requisições do usuário) utilizando ferramentas como o Tiles, por exemplo. Todo esse trabalho se repete em cada projeto de software e representa um processo repetitivo, falível e pouco testável. E mais: não existem ferramentas de testes automatizados realmente boas e fáceis de usar para as camadas de visão e controle, ao contrário da camada de modelo, que conta com a ajuda de ferramentas consolidadas como JUnit e TestNG, por exemplo. Assim, o desenvolvimento de aplicações robustas para a plataforma J2EE pode levar ao uso de diversas ferramentas e repetição de muito código burocrático, tornando essas aplicações bem mais complexas e difíceis de manter, justamente nas camadas menos testáveis da arquitetura MVC.

15 15 3 GERAÇÃO DE CÓDIGO ATUALMENTE Infelizmente, a maioria das ferramentas de geração de código para Java gera apenas classes na camada de negócio e não uma aplicação completa, deixando muito a desejar. Esses frameworks se baseiam na construção da aplicação através de conceitos relacionados a MDA, onde as definições para a geração são feitas em modelos gráficos, similares aos modelos UML [1] [8]. Como exemplos podem-se citar o Constructor, iqgen e algumas ferramentas CASE [8]. A lista completa está em anexo. Paralelamente, existem ferramentas que geram interfaces gráficas de qualidade para aplicações desktop em Java. Elas se baseiam em configurações definidas em arquivos XML. São exemplos o SwiXML e o Thinlet. Muitos geradores produzem programas completos para a plataforma web. Existem ferramentas baseadas em MDA, como AndroMDA e o OptimalJ. Essas ferramentas possuem configurações feitas pelo usuário final em uma interface gráfica ou em arquivos XML para realizar a geração de toda a aplicação web. OpenXava e o JSenna também fazem parte desse último grupo. Outro conjunto de geradores, extremamente elegantes e simples, está surgindo com o crescimento da linguagem Ruby. Ruby-on-rails e Streamlined são exemplos. Ambos são frameworks cuja principal característica é aproveitar a idéia do uso de convenções ao invés de arquivos de configuração. Sua configuração é baseada no esquema da base de dados. Como exemplo, uma tabela chamada user é transformada em uma classe User e esta classe é usada na geração de uma listagem com telas para inclusão, alteração e deleção de registros [9]. O uso de convenções é interessante, pois evita o uso exagerado de XML para configuração, facilitando o desenvolvimento e diminuindo a complexidade das aplicações finais. Percebe-se que muitas dessas ferramentas geram a aplicação por completo, fato que facilita o trabalho com o desenvolvimento e paralelamente prejudica a testabilidade do software final, pois este, depois de gerado, torna-se uma caixa-preta, inviolável. A lógica de negócio, que deveria ser implementada na camada de modelo, acaba por não existir, pois não pode ser gerada automaticamente. A conseqüência disto é que os programas inteiramente

16 16 gerados são, na maioria dos casos, pobres em funcionalidade e pouco complexos, contemplando apenas a funcionalidades básicas, ou CRUD. Pior: como as aplicações geradas, em grande parte, só possuem as funcionalidades básicas, os desenvolvedores são obrigados a alterar o código gerado para adicionar requisitos mais complexos. Ou seja, voltam a desenvolver código burocrático e a conseqüência direta é a queda da produtividade. Assim, com boa parte dessas ferramentas ocorre um ganho de produtividade apenas no início do desenvolvimento.

17 17 4 O JHEAT O JHeat é um framework para a geração automática de aplicações web. Foi desenvolvido como solução alternativa para aos problemas supracitados e segue a mesma ideologia de um outro conjunto de geradores poderosos, como o J2EE Spider, e-gen e GreenBox [10] [11] [12]. A idéia básica por trás desses frameworks é deixar a lógica de negócio para quem melhor pode fazê-la e testá-la, o programador. O código referente às camadas de visão e controle é puramente burocrático e repetitivo, podendo ser gerado automaticamente. No caso do JHeat, a aplicação final é gerada a partir do código do modelo de negócios (camada model do padrão MVC), configurações em arquivos XML e templates JSP. A ferramenta foi criada durante o desenvolvimento do sistema de gestão do plano de saúde IAPEP Saúde, para o IAPEP (Instituto de Assistência a Previdências do Estado do Piauí). O sistema foi entregue em três meses, dentro do prazo, e está em funcionamento desde abril de O JHeat também foi utilizado para criar outros dois sistemas para os planos de saúde: Proteção e Recife Saúde. 4.1 ARQUITETURA Para gerar aplicações robustas e complexas, com muitos requisitos não-funcionais, como segurança, usabilidade e desempenho, o JHeat utiliza cerca de 14 frameworks incluindo Hibernate, Struts, DisplayTags, DWR, Ajax Tags, CeWolf e JfreeChart, Apache Commons, IText, Ant, entre outros. Sem o uso do gerador, o desenvolvedor teria que lidar diretamente com todos esses frameworks e repetiria esse trabalho em cada novo projeto, uma vez que essas ferramentas são necessárias para lidar elegantemente com a complexidade desses sistemas. O JHeat se encarrega de configurar esses componentes e encapsula seu funcionamento, facilitando o trabalho do desenvolvedor e diminuindo drasticamente a complexidade da aplicação final. O JHeat não gera uma aplicação por completo, somente as camadas de controle e visão. A camada de modelo deve ser totalmente desenvolvida pelo

18 18 programador, fato que confere ao framework grande flexibilidade e grande manutenibilidade, uma vez que essa camada pode ser corrigida e incrementada a qualquer momento, gerando-se novamente a aplicação. O JHeat, portanto, é composto de um gerador para a camada de visão e outro para a configuração da camada de controle, além de um framework controlador genérico. A seguir, segue um maior detalhamento da estrutura interna de cada camada gerada e frameworks utilizados CAMADA DE MODELO O modelo é uma das camadas mais importantes de uma aplicação, pois é nele que são codificados quase todos os requisitos e regras de negócio [3]. É nessa camada que o acesso às bases de dados deve ser implementado [6]. Esse último fato acrescenta muita complexidade ao seu desenvolvimento sendo muitas vezes necessário o uso de alguns frameworks como Spring, Hibernate, Toplink e outros para auxilio nas configurações e na codificação das funcionalidades que envolvam acesso às bases de dados. O Hibernate provê diversas facilidades na comunicação entre o código Java contido no modelo e a base de dados [6]. Por ser uma das ferramentas mais utilizadas pelos desenvolvedores, é obrigatório o seu uso na camada de modelo de uma aplicação gerada pelo JHeat, que utiliza essa ferramenta internamente para realizar as operações com a base de dados. Essa é uma das únicas regras a serem observadas para que a aplicação possa ser gerada corretamente com JHeat CAMADA DE VISÃO A camada de visão das aplicações geradas é constituída de arquivos JSP que são baseados em arquivos de template, que utilizam diversas tags customizadas, como as DisplayTags, para paginação, exibição e filtragem de listagens variadas. Conta também com componentes visuais baseados em Ajax e para criação de gráficos, as CeWolf Tags. Os arquivos de template são páginas JSP com todas as definições de layout, cujo conteúdo dinâmico (listagens, campos para pesquisa ou formulário de inclusão/alteração) está representado através de chaves literais. A geração das inúmeras páginas ocorre com a cópia do arquivo de template para cada mapeamento do JHeat (visto com mais detalhes a seguir) e substituição das chaves, de acordo com cada mapeamento. Exemplo: em uma aplicação com mapeamentos para uma classe Usuario e uma

19 19 Cliente, um mesmo arquivo de template de listagem é utilizado para gerar as páginas de listagens para as duas entidades. Nas duas cópias feitas, as chaves são substituídas pelas propriedades mapeadas para cada classe nos arquivos XML. Veja, na figura 2, um esquema que melhor representa a geração da camada de visão. Listagem da classe A Listagem da classe B Template JSP p / listagem Conjunto de chaves para serem substituídas por conteúdo dinâmico 3 2 JHeat Gerador da camada de visão 1 Mapeamento XML da classe A Mapeamento XML da classe B Ordem dos passos da geração da camada de visão Figura 2: esquema da geração da camada de visão Esse é um dos principais mecanismos que conferem ao framework uma grande extensibilidade. Se o desenvolvedor quiser alterar a aparência da aplicação, basta mudar o arquivo de template (existem vários templates para cada área da aplicação gerada, discutidos mais adiante) e gerar novamente a aplicação CAMADA DE CONTROLE O Struts foi o framework MVC escolhido para ser utilizado internamente na camada de controle gerada pelo JHeat. Ele ajuda a simplificar processos de autenticação, redirecionamento, mapeamento de páginas e internacionalização de conteúdo [5]. Foi escolhido por ser um dos mais completos, além de bastante testado e bem documentado. [5] O JHeat possui um conjunto de classes para a camada de controle que utilizam a API de reflexão do Java para realizar inúmeras operações genericamente, de forma que se adaptem a quaisquer classes e atributos mapeados nos arquivos de configuração em XML. Assim, esses servlets genéricos cuidam de operações como controle de acesso, redirecionamento de páginas e controle de transações com a base de dados.

20 UTILIZAÇÃO Para utilizar o framework é necessário entender que a geração das telas foi criada e dividida de acordo com um conjunto de padrões de exibição de conteúdo e funcionalidades. Esses padrões de telas serão detalhados a seguir CADASTROS São telas que agrupam operações simples, CRUD, para cadastro, pesquisa e alteração de registros na base de dados. Foram criadas páginas-padrão para listagem, cadastro/alteração e detalhes das entidades. Para melhor exemplificar, veja a figura abaixo, que mostra também os relacionamentos (links) entre essas páginas. Listagem Pesquisa 1 Cadastro/Alteração Campos Listagem Botões 2 Detalhes Campos 3 Ordem de apresentação das telas Figura 3: organização de telas para CRUD Para exemplificar melhor, serão mostrados trechos de código de uma aplicação para demonstração (o código completo encontra-se em anexo). O primeiro trecho de código referese à classe Usuario do sistema. Veja na figura 4:

21 21 Figura 4: trecho da classe Usuario Logo em seguida, na figura 5, está o mapeamento do JHeat para esta classe.

22 22 Figura 5: trecho do mapeamento JHeat para a classe Usuario Agora as telas finais para listagem, cadastro e detalhamento, geradas a partir dos arquivos de templates. Figura 6: listagem gerada para a classe Usuario

23 23 Figura 7: tela de cadastro/alteração gerada para a classe Usuario Figura 8: tela de detalhes gerada para a classe Usuario FLUXOS SEQUÊNCIAIS COMPLEXOS São operações que geralmente são divididas em vários passos e ocupam várias páginas para serem concluídas [13]. Exemplo: a compra de um produto, que engloba a pesquisa de um item, o cadastro do comprador e a finalização da venda. Cada passo depende de outro e essa dependência é representada através de parâmetros vindos de passos anteriores. No JHeat, cada passo é mapeado para um método de uma classe. Tal método recebe os parâmetros da tela, realiza algum processamento e retorna algum tipo de informação, que será utilizada no próximo passo. Portanto, para que um fluxo seja mapeado é necessária uma classe cujos métodos se referenciam a cada passo e recebem os parâmetros do passo anterior como argumento, de

24 24 modo que possam executar alguma operação. Veja na figura 9 um esquema mostrando como um fluxo se subdivide em vários passos (páginas) para completar uma tarefa qualquer. Classe para o fluxo Método 01 Método 02 Método 03 Fluxo (transação longa) Passo 01 Passo 02 Passo 03 Página 01 Página 02 Página 03 Figura 9: subdivisão de um fluxo em passos gerada. Veja, como exemplo, trechos de um fluxo para alteração da senha do usuário e a tela

25 25 Figura 10: trecho do mapeamento JHeat para o fluxo de alteração de senha

26 26 Figura 11: tela do fluxo de alteração de senha 4.3 FUNCIONAMENTO DA GERAÇÃO Para que a geração da aplicação aconteça é necessário, que a camada de modelo esteja implementada utilizando-se o Hibernate como ferramenta de mapeamento objeto-relacional e corretamente mapeada no JHeat. Também são necessários os arquivos JSP de template (a distribuição do framework, disponível para download, contém um conjunto de templates para exemplo). Cada template é constituído por um conjunto de arquivos JSP cujo conteúdo possui definições de layout e um conjunto de chaves literais que serão substituídas por conteúdo configurado nos arquivos XML, no momento da geração. Essas configurações em XML são utilizadas para gerar tanto as páginas como as configurações do Struts. Os controladores genéricos baseados em reflexão realizam operações com classes, de acordo com os mapeamentos. Exemplo: um cadastro de usuário é feito pelo servlet de cadastro que lê as configurações no mapeamento do JHeat e sabe quais atributos preencher e qual classe salvar. O mesmo servlet pode ser usado em quaisquer outros cadastros, pois, em tempo de execução, sabe a qual mapeamento se refere o determinado cadastro e localiza, nas configurações em XML, dados para realizar essa e outras operações O ARQUIVO PRINCIPAL DE CONFIGURAÇÃO Cada entidade deve possuir seu mapeamento assim como os diversos fluxos. Paralelamente, existem configurações gerais, como login e controle de acesso, que precisam

27 27 ser definidas em um local separado. De mesma análoga ao Hibernate, cujo arquivo principal de configuração é o hibernate.cfg.xml, o JHeat conta com o arquivo jhive.cfg.xml para definir as configurações gerais da aplicação e incluir todos os mapeamentos referentes aos cadastros e fluxos. Veja na figura 12 um exemplo do arquivo e logo em seguida, na figura 13, a tela de login gerada pelo framework: Figura 12: configurações gerais da aplicação

28 28 Figura 13: tela de login gerada pelo JHeat Figura 14: tela inicial, com as abas (sections) Todos os elementos section, declarados no arquivo de configuração, são utilizados para gerar abas para navegação na tela final, como mostra a figura 14. Cada cadastro pertence a apenas uma section (veja um exemplo na figura 5), assim como os fluxos (veja um exemplo na figura 10). No último bloco do arquivo jhive.cfg.xml são definidos quais tipos de usuários podem acessar determinadas sections. O método para autenticação, chamado no exemplo de getroles(), deve retornar uma lista de grupos/tipos a que o usuário pertence. Esses dados são usados para o controle de acessso, definido no final do arquivo como mostra a figura 12. A seguir um esquema geral da arquitetura interna do framework bem como do processo de geração.

29 29 Modelo 1 JHeat A aplicação final usa o JHeat para executar as operações na base de dados Configurações em XML 2 Gerador do Controle Gerador da Visão 4 View da aplicação final 3 Aplicação Final Templates JSP Passos para a geração da aplicação final Figura 15: esquema geral da arquitetura do JHeat e do processo de geração Em seguida, na figura 16, está a estrutura de pastas para a aplicação de exemplo: Pasta para código-fonte da camada de modelo Pasta para as configurações XML do JHeat Pasta para o arquivo de construção ANT* Pasta para os templates JSP* Pasta para as bibliotecas* Pasta para a aplicação gerada * Arquivos fornecidos junto com o JHeat Figura 16: estrutura de pastas para um projeto que use o JHeat

30 30 5 CONCLUSÃO O JHeat surgiu com a idéia de não ser um gerador fullstack (que gera toda a aplicação). Ele cria aplicações robustas e escalávéis através da geração das camadas de visão e controle. A camada de modelo não pode ser gerada, pois é nela que são codificados todos os requisitos funcionais e regras de negócio. Deve, portanto, ser criada pelo desenvolvedor. Esse fato confere ao framework grande escalabilidade e manutenibilidade já que todas as funcionalidades não estão sob o controle do framework e, portanto, não ficam limitadas pelas estratégias de geração da ferramenta. O gerador constrói toda a interface gráfica (camada de visão) e a camada de controle, para prover meios de acesso às funcionalidades codificadas na camada de modelo. O uso de templates JSP facilitou muito a customização das telas da aplicação e evitou um dos principais problemas da geração de código: quando é necessário alterar uma página específica, o arquivo gerado é alterado, impedindo que a aplicação toda possa ser gerada novamente, levando a situações que podem provocar erros e queda de produtividade. Com o JHeat, quando se quer alterar algum elemento na interface gráfica, alteram-se somente os templates e arquivos XML de configuração. Nunca se altera o código gerado. Assim, pode-se gerar a aplicação quantas vezes for necessário, sem que haja perda da produtividade. É a chamada geração incremental [10]. Atualmente novos padrões como Convension Over Configuration regem o modelo de configuração de frameworks como Ruby-on-rails e sua extensão, o Streamlined [9]. Na época em que o JHeat foi criado, esses conceitos ainda não estavam tão difundidos como hoje, portanto, no JHeat as configurações são todas feitas em arquivos XML de forma declarativa. Em versões futuras o JHeat também irá utilizar convenções de alguma forma. Isso minimizará o trabalho para configuração da ferramenta e facilitará a sua adoção. Em suma, a geração de código, ou mesmo de aplicações, realmente aumenta a produtividade no desenvolvimento de software [1]. O framework mostrou-se extremamente estável, rápido e escalável. Evita a repetição de código e conhecimento sobre o uso dos vários frameworks envolvidos. A ferramenta é livre e está sendo disponibilizada para toda a