1. INTRODUÇÃO Neste capítulo é apresentado, primeiramente, a contextualização que envolve o conjunto de circunstâncias para a elaboração do trabalho e a motivação de realizá-lo. Segundo, para um melhor entendimento do trabalho, são apresentados os objetivos. 1.1 Contextualização e Motivação Um dos objetivos da Engenharia de Software é construir sistemas extensíveis e de qualidade. Além disso, a busca da redução de custos e do aumento da produtividade na construção de software é constante. No entanto, com o passar do tempo, a complexidade do software produzido tem aumentado em escala, dificultando ainda mais esses objetivos. Em certas ocasiões para desenvolver um projeto, desenvolvedores aplicam muito tempo na atividade de programação, que poderia ser aplicado em outras atividades do projeto. Então surge a necessidade de pessoas estudarem a geração automática de código, com o objetivo de ajudar os programadores de software.
Em aplicações web, uma atividade que necessita de geração automática de código é o desenvolvimento de interfaces gráficas. Os desenvolvedores, levam muito tempo na implementação delas. Então surge a necessidade de desenvolver ferramentas para esse propósito. Neste contexto, uma ferramenta que ajuda bastante na geração de interfaces gráficas, é a UML (Unified Modeling Language). Uma linguagem para padronizar modelagem de software, com visualização gráfica. Um dos diagramas UML que é mais utilizado, é o diagrama de classes, que podem representar todas as classes de um sistema e com isto representar as informações que são utilizadas na geração de interfaces gráficas. A responsabilidade pelo trabalho de padronização associado ao UML foi entregue ao consórcio OMG (Object Management Group), que reúne, virtualmente todas as grandes empresas da indústria mundial de computação e centenas de empresas pequenas (Object Management Group, 2009). Existem ferramentas que geram automaticamente interfaces gráficas, que utilizam o paradigma MDA (Model Driven Architecture). Por meio da utilização do MDA, constrói-se código rapidamente de forma consistente, bem-arquitetada e autônomo de plataforma, utilizando modelos. Para utilizar o MDA precisa-se definir um processo de software que guie os desenvolvedores na preparação e geração dos modelos MDA. Um processo de software pode ser visto como um conjunto de atividades e resultados associados que levam à confecção de um produto de software. Além disso, um processo MDA requer uma seleção de metamodelos e regras de mapeamentos para geração da cadeia de modelos que levam até o código da aplicação (MARINHO, 2009). É uma ferramenta poderosa, mas quem a utiliza, fica muito preso a seus modelos, tendo que seguir suas regras. Então surge a necessidade de desenvolver uma ferramenta de 2
geração automática de interfaces gráficas sem muitas complicações, não sendo necessário a invenção de um novo modelo ou diagrama. O código gerado será apenas o conteúdo e a informação, a arte sendo feita à parte. 1.2 Objetivos O objetivo do trabalho é desenvolver uma ferramenta para geração automática de interfaces gráficas, a partir de diagramas de classes UML. A partir do diagrama de classes UML, que representa o domínio da aplicação, será criado um novo diagrama, representando a organização da informação obtida. Esse novo diagrama seguirá uma arquitetura pré-definida de interfaces. A interface gerada deverá ser extensível e configurável, aceitando plugins e folhas de estilo. Foi realizado um estudo sobre um gerador de código já construído e foi acrescentado ferramentas nele para chegar ao objetivo principal que é a geração automática de interfaces gráficas. 3
2 Referencial Teórico Neste capítulo são apresentadas todas as informações necessárias para complementar o entendimento da metodologia e da solução proposta neste trabalho. Algumas tecnologias são apresentadas. O JSF (JavaServer Faces), utilizada para facilitar o desenvolvimento de páginas web. O ICEfaces e o RichFaces, componentes JSF que utilizam Ajax, tornando páginas mais dinâmicas e interativas. O Greenbox e o Velocity, em conjunto, utilizados na geração automática de código. 2.1 Tecnologia Ajax Ajax (Asynchronous JavaScript and XML) é uma tecnologia de desenvolvimento web para criar softwares de interação. A tecnologia usa combinações do HTML (HyperText Markup Language), XML (Extensible Markup Language) e CSS (Cascading Style Sheets) para apresentar as informações, trocando dados assincronamente com o servidor web. Ou seja, enquanto o usuário está visualizando ou utilizando algo em algum site, são feitas inúmeras requisições ao servidor sem prévio aviso (VIEIRA, 2009).
Fazendo com que a exibição do site se torne uma visualização em tempo real. Apenas partes do site, que estão sendo requisitadas por algum usuário, são carregados no navegador. Isso se difere de modelos convencionais, em que quando o usuário, manda requisições ao servidor, a página é toda carregada, sem necessidade de carregá-la totalmente. 2.2 MVC MVC (Model View Controller) é um modelo de arquitetura de software. É utilizada por algumas tecnologias de desenvolvimento de páginas web, como JavaServer Faces (seção 2.3), e seus componentes ICEFaces e RichFaces (seção 2.4.1 e 2.4.2). É separada em três camadas para melhor organização de uma aplicação. Ocorre a separação entre os dados (Model), e o layout (View). Então alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout. A camada View inclui elementos de exibição de clientes (arquivos HTML, XML), é a camada de interface com o usuário e é usada para receber a entrada de dados e apresentar o resultado. A camada Model, é o coração da aplicação. Modela os dados e o comportamento por trás do processo de negócios, se preocupa apenas com o armazenamento, manipulação e geração de dados e é um encapsulamento de dados e de comportamento independente da apresentação. A camada Control, determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e lógica (MACORATTI, 2009). 5
2.3 Java Server Faces Este framework é o resultado de um projeto apoiado pela Sun Microsystem e teve sua primeira versão apresentada em setembro de 2002 (GEARYHORSTMANN, 2005). O JavaServer Faces atua principalmente nas camadas de Visão e Controle do modelo MVC (FOWLER, 2003), e tem como principal objetivo facilitar o trabalho dos desenvolvedores na construção das páginas dos sistemas web. Para isso, disponibiliza aos usuários uma biblioteca de componentes prontos para serem utilizados. Além disso, possui um modelo de programação dirigido a eventos, tentando se aproximar das aplicações desktops. Alguns utilitários compõem esse framework para seu funcionamento, são eles : 1) Ciclo de Vida das Requisições JSF : é o caminho percorrido por uma requisição JSF, desde a sua criação, com a realização de um evento, até a renderização da página a ser exibida para o usuário. 2) FacesServlet: recebe todas as requisições do cliente, prepara, determina a operação na aplicação que será executada e redireciona de volta a resposta; 3) Action Handlers e Event Listeners: são os manipuladores dos eventos disparados na interface. Eles são os responsáveis por invocar a execução das implementações que representam cada evento; 6
4)View ID: É uma árvore de informações de todos os componentes de uma página que instanciou uma requisição. 5) FacesContext: Este objeto é o responsável por armazenar as View ID e todas as informações necessárias para o framework JSF gerenciar os componentes de uma página; 6) Component Tree: a representação hierárquica dos componentes da interface gráfica de usuário. Cada página renderizada pelo JSF é representada em uma árvore composta por componentes; 7) Converters: cada componente de uma interface gráfica de usuário pode possuir um conversor de tipos. Eles auxiliam na tradução de tipos complexos para String (e vice-versa ). 8) Validators: os componentes de uma interface gráfica de usuário também possuem validações específicas. O valor associado ao componente é validado de acordo com a configuração do mesmo. 9) Renderers: são responsáveis pela exibição do conjunto dos componentes na resposta do servidor ao cliente, e pela tradução dos mesmos componentes para o controlador no momento na requisição do 7
cliente. 10) Backing Beans: São classes as quais contêm parte ou todas as informações dos valores de uma página (GEARY;HORSTANN, 2005). É a representação do formulário HTML na forma de um objeto Java. 11)Faces-Config.xml: Este é o principal arquivo de configuração do framework JSF, no qual se deve definir todos os backing beans e as regras de navegação das páginas que serão utilizadas na aplicação. Para um melhor entendimento de uma requisição JSF, a Figura 1 mostra uma visão geral do seu funcionamento. Figura 1 Visão geral de uma requisição JSF. 8
Cada requisição JSF, passa pelo FacesServlet, responsável por determinar e preparar as operações de uma requisição. Os Action Handlers e Event Listeners são os responsáveis por invocar a execução das implementações que representam cada evento. Um evento pode ser ações de botões, por exemplo. É montado um Component Tree, uma árvore de componentes de uma GUI (Interface Gráfica do Usuário). Uma GUI pode possuir Converters, Validators e Renderers. Eles são responsáveis pela conversão de tipos, validação de campos e exibição dos componentes JSF de uma GUI, respectivamente. 2.4 Rich Internet Applications RIA (Rich Internet Applications) é mais um passo no processo evolutivo da Internet. Essas aplicações se parecem com as aplicações desktop, fazendo com que o seu uso seja mais facilitado, oferecendo uma interface mais rica aos usuários. (LOOSLEY, 2006). RIA é a revolução das aplicações web, é mais que tecnologia é um conceito. É o uso da Internet e das tecnologias disponíveis para criar uma experiência de uso de aplicação mais intuitiva e eficiente para o usuário. É uma nova forma de pensar e desenvolver sistemas web. É a combinação da interatividade e funcionalidade do desktop com a abrangência e flexibilidade da web (BRIDEE, 2007). Em aplicações RIA, tudo que é interface deve ser processado no cliente e o que for lógica do negócio deve ser processado no servidor (BRIDEE, 2007). 9
Os usuários que interagem com a aplicação, obtêm uma reação imediata da aplicação, quando são solicitados novos dados. Não há necessidade de renderizar a página totalmente. Os dados da aplicação são atualizados sem que a tela fique em branco. A aplicação utiliza alguns controles de interface de usuário mais modernos como menu, menu em árvore, painel de abas, entre outros elementos gráficos de interface que não são utilizados em aplicações web tradicionais. Permite o uso de operações comuns em aplicações desktop, como Drag & Drop, redimensionar, uso de animações, entre outras (BRIDEE, 2007). 2.4.1 Tecnologia ICEfaces É um dos RIA mais populares entre as empresas de desenvolvimento de software. O framework ICEfaces (ICESOFT, 2006) pertence à empresa Rich Web Company que tem como principal foco desenvolver soluções para tornar as aplicações para a web mais ricas em funcionalidades. Esta empresa tem papel importante no mercado mundial de desenvolvimento de componentes que utilizam a tecnologia AJAX. Excedendo sessenta e cinco mil desenvolvedores em mais de trinta e seis cidades no mundo (ICESOFT, 2009). A Figura 2 representa a integração das tecnologias JSF e AJAX utilizada pela biblioteca ICEfaces. 10
Figura 2 - Integração das tecnologias JSF e AJAX utilizada pela biblioteca ICEfaces. Fonte: (ICESOFT, 2006). Esta biblioteca integra a parte de JavaScript no browser do cliente com as camadas de Visão e Controle do modelo MVC do servidor por meio de um módulo ICEfaces chamado de Ajax Bridge. As principais classes da arquitetura ICEfaces são : 1 Persistent Faces Servlet: Todas as requisições iniciais advindas de arquivos *.iceface são encaminhadas para a classe PersistentFacesServlet. Esta fica responsável por repassar a requisição ao servidor que executará todas as etapas do ciclo de vida de uma requisição JSF. 11
2 Blocking Servlet: Depois de a página ser renderizada pela primeira vez, todas as requisições do browser passam pelo AJAX Bridge do cliente e são encaminhadas para AJAX Blocking Bridge Servlet. Esta classe tem a função de repassar a requisição caso esta seja um submit diretamente ao servidor; caso contrário, a requisição deve ser encaminhada ao AJAX Bridge do servidor. 3 D2D View Handler: Classe responsável por estabelecer a renderização direta com o DOM (Document Object Model). O DOM permite uma maneira comum de se acessar e alterar objetos HTML via Javascript. Com isto, navegadores que suportam o DOM, não terão problemas em mostrar os componentes ICEFaces. A classe possui entre outras atividades: a inicialização de um objeto da classe DOM Response Writer e a invocação de um objeto da classe D2DParser na primeira vez em que uma página é renderizada a fim de que seja feito o parser da árvore de componentes JSF. 4 D2D Parser: Cada vez que uma nova página é renderizada um objeto da classe D2D Parser é chamado para que execute o parser do arquivo e construa a árvore de componentes JSF. 5 D2D RenderKit: A principal função dessa classe é renderizar a árvore de componentes dentro do DOM. 12
6 DOM Response Writer: Esta classe é responsável por escrever a árvore de componentes no DOM e encaminhar essas alterações ao DOM Updater. 7 DOM Serializer: A principal função desta classe é a de serializar o objeto DOM para as páginas na primeira vez que é renderizada. 8 DOM Updater: A classe DOM Updater é responsável por capturar o objeto DOM atualizado e enviar esta instância para o AJAX Bridge localizado no browser do cliente para que seja renderizado. Enquanto a tela com a árvore de componentes não for repassada ao AJAX Bridge do browser, o DOM Updater bloqueia qualquer requisição advinda da classe DOM Response Writer. 9 Client-side AJAX Bridge: Esta característica é implementada utilizando-se JavaScript e carregada automaticamente quando o browser renderiza uma página. As principais funções do Client-side AJAX Bridge são: repassar requisições (submit ou Partial submit) para a classe AJAX Bridge Blocking Servlet e receber objetos DOM atualizados para serem renderizados para o usuário. 13
10 Server-side AJAX Bridge: Já as classes que pertencem ao módulo AJAX Bridge que ficam no servidor fazem parte da biblioteca ICEfaces e portanto são desenvolvidas em Java. As principais atividades desenvolvidas por este módulo são: receber as requisições do Client-side AJAX Bridge, como por exemplo, submit e partial submit, que devem ser repassados à aplicação JSF; e obter objetos DOM atualizados que devem ser enviados para o AJAX Bridge do cliente. 2.4.2 - Ajax4jsf O framework Ajax4jsf é um projeto patrocinado pela empresa Exadel (EXADEL, 2006) sediada na cidade de Concord, Califórnia. O diferencial do Ajax4JSF é a facilidade de desenvolvimento de sistemas devido à total integração desse framework com a IDE (Integrated Development Enviroment), chamada de Exadel Studio. Exadel também desenvolveu uma biblioteca de componentes JSF que utilizam a tecnologia AJAX, chamada de RichFaces (EXADEL, 2006), a qual é uma extensão do framework Ajax4jsf. Na Figura 3 representa os principais elementos que pertencem ao framework Ajax4jsf : 14
Figura 3 Representação dos principais elementos da biblioteca Ajax4jsf. Fonte: [EXADEL, 2009]. 1) Ajax Filter : Este tipo de filtro tem como principal função a de receber as requisições e, de acordo com o tipo, encaminhá-las para serem executadas de maneira correta. Caso seja uma requisição JSF, o Ajax Filter deve reconstruir toda a página que deve ser exibida ao usuário; caso seja uma requisição AJAX somente devem ser atualizados os componentes desejados pelo desenvolvedor. 15
2) Ajax Container: É uma interface que contém quais partes da página JSF devem ser renderizadas após a execução de uma requisição. 3) Ajax4jsf JavaScript Engine: Este é o responsável por administrar quais campos da página JSF do cliente deverão sofrer modificações quando uma requisição é executada. 4) Skinability: Esta é uma característica desta biblioteca, que permite que algumas características gráficas sejam definidas com o uso de parâmetros do sistema; com isso o usuário pode definir a cor de fundo, o estilo e a fonte das letras, entre outros atributos, durante a execução do programa. 5) Ajax Action Components: Existem basicamente três componentes que podem enviar requisições AJAX a partir do browser do cliente: AjaxCommandButton, AjaxCommandLink e AjaxSupport. Uma falha encontrada na versão utilizada do Ajax4Jsf é que este framework não está ainda totalmente integrado aos diversos browsers (principalmente Internet Explorer e Mozilla Firefox) considerando que no exemplo desenvolvido os componentes ficam perfeitamente alinhados em um browser, enquanto em outro acontece o desalinhamento. 16
2.5 UML A UML (Unified Modeling Language) é, atualmente, a linguagem para documentação e modelagem de software mais difundida entre os desenvolvedores. Através dos modelos e diagramas encontrados na UML, pode-se obter diferentes visões de um software. O diagrama mais utilizado entre os desenvolvedores e analistas é o diagrama de classes. Esse diagrama é muito útil para um sistema, pois define todas classes que necessita possuir e é a base para a construção dos outro diagramas. As classes correspondentes em um determinado diagrama de classes, podem conter relações como: herança, associações, por exemplo. Isto possui características semelhantes ao modelo relacional em banco de dados, em que as tabelas mantêm relações com outras tabelas. Em alguns sistemas, às vezes fica mais fácil, criarmos apenas classes representando as entidades do sistema, para ficar mais simples quando for modelar as relações entre classes nos diagramas. No MVC essas classes representam a camada Model. A UML é uma linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação. Ela representa uma coleção das melhores experiências na área de modelagem de sistemas orientado a objetos, as quais tem obtido sucesso na modelagem de grandes e complexos sistemas (Furlan, 1998). 17
Segundo (Furlan, 1998), a UML pode ser usada para: a) mostrar as fronteiras de um sistema e suas funções principais utilizando atores e casa de uso; b) ilustrar a realização de casos de uso com diagramas de interação; c) representar uma estrutura estática de um sistema utilizando diagramas de classes; d) modelar o comportamento de objetos com diagramas de transição de estado; e) revelar a arquitetura de implementação física com diagramas de componentes e de implantação; 2.6 Linguagens de descrição de dados Nesta seção é apresentada uma visão geral das linguagens XML e XMI utilizadas para descrever os diagramas de classes UML do projeto. 2.6.1 Extensible Markup Language A Extensive Markup Language (XML) é uma linguagem de marcação de dados (meta markup language) que provê um formato para descrever dados estruturados. Isso facilita declarações mais precisas do conteúdo e resultados mais significativos de busca através de múltiplas plataformas. 18
A XML também permite o surgimento de uma nova geração de aplicações de manipulação e visualização de dados via internet. A XML não é uma simples linguagem de marcação pré-definida, mas sim uma metalinguagem uma linguagem que descreve outras linguagens que permite definir sua própria marcação (Laurent, 1999). De acordo com (Laurent, 1999), alguns pontos fortes da XML são: a) Manutenção: a XML é fácil de manter. Ela contém somente idéias e marcações. Folhas de estilos e links vêm em separado, e não escondidas no documento. Cada um pode ser alterado separadamente quando for preciso com fácil acesso e fáceis mudanças; b) Permite a definição de suas próprias tags conforme a necessidade do usuário; c) Adaptação: a XML é a linguagem mãe de outras linguagens. Marcações personalizadas podem ser criadas para qualquer necessidade; d) Aplicações padronizadas para XML possibilitam que diferentes aplicativos trabalhem em conjunto trocando informações, proporcionando maior interoperabilidade; 2.6.2 XML Metadata Interchange O XMI (XML Metadata Interchange) é uma linguagem baseada em XML e seu principal objetivo é facilitar o intercâmbio de metadados. Com ele conseguimos descrever informações entre ferramentas de 19
modelagem baseadas em UML. XMI baseia-se na tecnologia Meta Object Facility (MOF), que foi adotada pelo Object Management Group (OMG) para a definição de metadados. Como a UML também é baseada na MOF, a XMI se apresenta como um formato de intercâmbio para a UML. A XMI é usada para a troca de dados de modelos entre diferentes ferramentas de desenvolvedores e utiliza a sintaxe XML para descrever os dados. Ela também possibilita a troca de modelos entre ferramentas UML, mas para isso elas precisam saber como importar XMI e misturar partes importadas em um modelo existente. Esta tecnologia pode ser usada como uma etapa intermediária, se falando de geração de definições da XMI a partir da UML ( Daum e Metter, 2002 ). Segundo (Groose, 2002), alguns benefícios imediatos ao uso do XMI, são eles: a) XMI define uma padrão de representação de objetos em XML, viabilizando ainda mais o intercâmbio de definições de modelos e modelos entre ferramentas específicas; b) XMI especifica como criar Schemas a partir de modelos; c) XMI permite a evolução do grau de detalhismo de sua aplicação; d)xmi permite evoluir documentos previamente criados, diminuindo o grau de abstração; e) XMI permite lidar com XML sem se tornar um mestre em XML, porém o desenvolvedor pode se sentir a vontade para melhorar o que foi desenvolvido com o auxílio do XMI utilizando o conhecimento que tiver sobre XML; 20
2.7 Tecnologia Velocity O Velocity é uma ferramenta de desenvolvimento de templates desenvolvido em Java. Templates são arquivos com extensão.vm, que através da sintaxe Velocity embutida dentro desses arquivos, consegue-se gerar qualquer tipo de arquivo, em qualquer linguagem desejada. A tecnologia Velocity possui algumas diretivas que podem compor esses templates, com o objetivo de gerar qualquer tipo de arquivos. Para melhor explicar como o template é, a Figura 4 mostra um exemplo de um template. <!-- imprimir nomes de hoteis de lavras cadastrados <!-- imprimir nomes dos hotéis <HTML> <HEAD> <TITLE>EXEMPLO TEMPLATE VELOCITY</TITLE> </HEAD> <BODY> <TABLE> <tr> #foreach($name in $listnomeshoteis) <td>name : $name </td> #end </tr> </TABLE> </BODY> </HTML> Figura 4 : templateexample.vm 21
Nesta figura é apresentado um arquivo HTML com código do Velocity. Uma diretiva importante da linguagem Velocity, é o #foreach, usado para percorrer elementos de um array. Todas diretivas dessa linguagem, começam com #. Em toda linguagem de programação, para representarmos uma variável, utilizamos alguma letra ou caracter sublinhado. Neste caso, na linguagem Velocity, é utilizado o $. Notamos que inserimos sintaxe do Velocity, dentro de um arquivo HTML. Isso pode ser feito dentro de qualquer tipo de arquivo. Isto quer dizer que é possível gerar qualquer tipo de arquivo com a tecnologia Velocity Neste exemplo, a partir de um arquivo Java, podemos imprimir todos nomes de hotéis de um array preenchidos neste arquivo abaixo apresentado na Figura 5. 22
public class CadastroHoteis { ArrayList hoteis = newarraylist(arrays.aslist(new String[] { })); "Pinguin", "Califórnia", "Otton" VelocityContext context = new VelocityContext(); public void processamento(){ velocity.init(); context.put("listnomeshoteis", hoteis); Template template = velocity.gettemplate(); template.merge(context, output); } Figura 5 CadastroHoteis.java A Figura 5, apresenta uma classe Java contendo métodos correspondentes às variáveis que estão sendo acessadas através do Velocity da Figura 4. Foi criado nesta classe, um array chamado hoteis e inicializamos ele com três nomes. Criamos um objeto da classe VelocityContext, chamado context, para realizar a passagem de informações da classe java para o template. No método processamento, inicilazamos o velocity com o método init(). Com o método put(), colocamos o contexto do array hotéis em listnomeshoteis para ser acessado no template da Figura 4 com este nome. Depois selecionamos um determinado template que será utilizado, que será aquele da Figura 4. Posteriormente o método merge() é 23
utilizado para colocar esse contexto em um arquivo qualquer de saída output, pode ser um arquivo JSP ou texto por exemplo. Neste caso nosso arquivo de saída será HTML, pois queremos gerar um arquivo HTML. Quando esse arquivo for gerado, ficará da sequinte forma : <HTML> <HEAD> <TITLE>EXEMPLO TEMPLATE VELOCITY</TITLE> </HEAD> <BODY> <TABLE> <tr> <td>name : Pinguin </td> <td>name : Califórnia </td> <td>name : Otton </td> </tr> </TABLE> </BODY> </HTML> Figura 6 : exemplo.html Aquele código HTML da Figura 4 que possuía diretivas Velocity, agora possui somente código HTML. Os nomes dos hotéis foram processados do arquivo CadastroHoteis.java e acessados nesse arquivo exemplo.html da Figura 6. O Velocity consegue atribuir objetos Java dentro de qualquer tipo de 24
arquivos. É com isto que conseguimos gerar qualquer tipo de arquivo. 2.8 Geradores de código A geração automática de código define a capacidade de gerar automaticamente um software funcional ou compilável diretamente de uma especificação de projeto. A geração automática do código, integral ou parcial, fornece as seguintes vantagens: redução do tempo de desenvolvimento, pois minimiza a necessidade de codificação manual, e aumento da confiabilidade do código gerado, o qual foi produzido por uma ferramenta depurada e testada (Fisher, 1990). 2.8.1 Greenbox O Greenbox é um framework de geração de códigos, baseado em Velocity e técnicas de Metamodel, permitindo ler modelos estáticos como banco de dados e XMI e gerar códigos para qualquer linguagem. Abaixo, segue a Figura 7, correspondente ao sistema Greenbox. 25
Figura 7 Sistema Greenbox Esse sistema funciona de maneira simples. Com arquivos XMI, ou schemas de banco de dados, que são as entradas desse sistema, o Greenbox consegue processar esses dados juntos com templates Velocity e assim, gerar o código em qualquer linguagem desejada. 26
3. Metodologia Neste capítulo são apresentados os passos para o desenvolvimento do projeto. Primeiramente é abordado o estudo do gerador de código e das tecnologias utilizadas, e o motivo de escolhê-las. Em seguida, é analisada a estrutura de pacotes utilizada para a modelagem das classes. Posteriormente, é analisado como deve ser as relações entre as classes da aplicação. Em seguida, é analisado as interfaces gráficas geradas. Depois, é analisada uma interface utilitária para a escolha dos templates e locais de geração dos arquivos. Posteriormente, é apresentado o desenvolvimento dos templates responsáveis pela geração das interfaces gráficas e de outros arquivos. 3.1 Gerador de Código Foi estudado um gerador de código implementado anteriormente por um grupo de desenvolvedores. Esse gerador já consegue fazer o parser do arquivo XMI obtido por alguma ferramenta de diagramas UML escolhida pelo usuário. Com isso, nomes das classes, o caminho de pacotes pertencentes a cada classe, associações, herança, nomes e tipos de atributos de classes já são obtidos.
Foi utilizado o framework Greenbox como uma ferramenta do gerador de código. Foram acrescentadas ao gerador classes utilitárias para a ajuda na geração de código, tanto da interface pré-definida, quanto para gerar as interfaces gráficas e os outros arquivos, como os backing beans. Foi feito um estudo sobre este gerador, para ser utilizado para a construção dos templates responsáveis par atingir o objetivo do projeto. 3.2 Tecnologias Utilizadas Na construção das interfaces gráficas foi utilizado o framework ICEfaces. Ele é uma ferramenta utilizada por muitas empresas no mundo inteiro. É fácil de utilizar e possui muitas ferramentas que servirão bem para o nosso projeto. Na construção dos templates foi utlizado a ferramenta Velocity. O Greenbox foi utilizado para auziliar na geraçao automática de código. 3.3 Estrutura de Pacotes Todas classes e diagrama de classes criadas por algum usuário, deverão ser modeladas em algum software de gerenciamento UML. Este software deverá conter uma ferramenta para exportar o arquivo XMI 28
correspondente de cada aplicação modelada. Foi inventada, uma estrutura de pacotes hierárquico, para organizar a criação dessas classes. A Figura 8 mostra a estrutura de pacotes escolhida, modelada no software Poseidon. Figura 8 Estrutura de pacotes 29
na Figura 9. A representação hierárquica dessa estrutura de pacotes está ilustrada Figura 9 Representação estrutura de pacotes. O pacote entity engloba todas entidades da aplicação. Essas classes são o modelo de domínio da aplicação. Neste exemplo, possuímos as entidades: Estagiário, Professor e User. O pacote view é criado para representar as telas que serão geradas. Dentro do pacote view, temos as pranchetas, abas, cartões e selos. Neste caso, temos a prancheta empresa e faculdade. A prancheta empresa, possui as abas estagiário e funcionário. A prancheta faculdade, possui a aba professor. A aba estagiário, possui o cartão NewEstagiario. A aba funcionário, possui os cartões NewUser e NewUsers. A aba professor, possui o cartão NewProfessor. Cada cartão corresponde a 30
cada classe criada. Os selos correspondem ao conteúdo de cada cartão. Cada usuário deve utilizar essa estrutura de pacotes para obter as interfaces gráficas desejadas. 3.4 Relações entre as classes Na modelagem do diagrama de classes, cada classe deve possuir uma relação direcionada com as entidades correspondentes. Pois as entidades não tem nada a ver com as interfaces geradas. São as interfaces que representam as entidades. 3.5 Conteúdo de cada cartão O conteúdo de cada cartão vai depender do tipo de relação entre a sua classe e as outras classes do diagrama de classes UML modelado. Na Figura 10, ocorre uma relação direcionada um para um entre a classe X e a entidade Y. 31