Framework para Acesso Web Automático a Objetos em Bancos de Dados via GWT

Transcrição

1 UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA Framework para Acesso Web Automático a Objetos em Bancos de Dados via GWT Paulo Abelha Ferreira Orientador Prof. Dr. Angelo Ernani Maia Ciarlini RIO DE JANEIRO, RJ BRASIL Fevereiro de 2011

2 Agradecimentos Agradeço à minha família por todo o apoio dado durante minha graduação, aos colegas e professores que me proporcionaram debates e momentos valiosos e ao meu orientador que sempre me inspira e estimula a planejar com calma e corretude antes de abordar os problemas; seja na computação, seja na vida. 2

3 ABELHA, Paulo. Framework para Acesso Web Automático a Objetos em Bancos de Dados via GWT. UNIRIO, páginas. Projeto de Graduação. Escola de Informática Aplicada, UNIRIO. Resumo Este projeto descreve o modelo e a implementação de um framework cujo propósito é gerar automaticamente uma interface web Google Web Toolkit orientada a objetos para acessar um banco de dados. O framework permite que os desenvolvedores implementem suas aplicações em Java sem ter de lidar com os detalhes de uma interface web. Formulários, definidos como classes Java, são utilizados para especificar a estrutura dos objetos da aplicação armazenados no banco de dados. A interface, baseada nestes formulários, executa em web browsers de maneira assíncrona, fornecendo boa performance e flexibilidade. Para ter uma aplicação Web funcional, basta ao desenvolvedor criar o banco de dados e definir o mapeamento para o mesmo. Palavras-chave: Framework; Aplicação Web 3

4 Sumário 1. Introdução Comparação com alternativas existentes JavaServer Faces Struts Django Ruby on Rails Comparação das alternativas com o framework proposto Modelo de dados Arquitetura Interface Lista das classes independentes Tela Classe Tela Objeto Campos Tela de nova referência única Tela de nova referência múltipla Tela de descrição de um objeto Gerenciador de contextos RPC Acesso ao banco de dados Implementação Passos Para Criação de uma Aplicação Utilizando o Framework Exemplo de aplicação Conclusões Trabalhos futuros Referências

5 Lista de Figuras 1 Arquitetura Geral do Framework Tela de classe Tela de objeto Tela de nova referência única Tela de nova referência múltipla Tela de descrição de um objeto Diagrama do Gerenciador de Contextos Diagrama do Módulo de Acesso ao Banco de Dados Snapshot da Implementação da Classe FormClienteContaCorretora Snapshot da Implementação da Classe FormExtratoAplicacao TelaClasse e TelaNovoObjetoDescricao TelaObjeto e TelaNovaRefUnica TelaNovaRefMultipla da Classe OperacaoVista TelaObjeto da Classe Extrato Exclusão de um Objeto Empresa

6 1. Introdução As aplicações web têm tido uma importância cada vez maior. Suas vantagens principais em relação a outros tipos de aplicação são a compatibilidade com diferentes plataformas (já que basta ao usuário possuir um browser compatível), a centralização dos dados, a facilidade de instalação, a rápida atualização no lado cliente e a redução de custos. Nas primeiras aplicações web, havia o problema de espera para a atualização das informações em cada página. No modelo destas aplicações, o usuário realizava uma chamada e tinha de aguardar pela resposta do servidor antes de realizar qualquer nova chamada. A solução Ajax [1], termo cunhado por Jesse James Garret em 2005, apareceu como alternativa à lentidão das aplicações web. Tal solução busca eliminar a espera que ocorre no modelo antigo ao introduzir um mecanismo intermediário entre o cliente e o servidor. Ao invés de carregar uma página web no início da sessão, o browser carrega um mecanismo Ajax cujo objetivo é renderizar a interface para o usuário e realizar a comunicação com o servidor quando solicitado. Qualquer chamada que normalmente requisitaria uma página integral HTTP ao servidor, toma agora a forma de uma chamada JavaScript ao mecanismo Ajax. Com o Ajax é possível atualizar diretamente porções da página sem ter que recarregar o conteúdo integral da mesma. Ele permite que a aplicação realize chamadas assíncronas ao servidor, melhorando sua eficiência e a experiência do usuário. O principal problema com a solução Ajax no desenvolvimento de aplicações complexas é a programação em JavaScript. Tende-se a gerar um código de difícil manutenção e teste devido à propria estrutura da linguagem, que não é orientada a objetos, e à dificuldade de integração com a linguagem do núcleo da aplicação, normalmente orientada a objetos. O GWT (Google Web Toolkit) [2], um conjunto de bibliotecas e padronizações para gerar páginas web a partir de um código Java, oferece uma solução a esse problema ao realizar a compilação cruzada de Java para Java Script. Ele permite que o desenvolvedor escreva o seu código em Java, dando suporte à maioria da semântica e sintaxe, e compile-o para JavaScript. O GWT oferece a possibilidade de escrever, depurar e organizar o código em Java, o que é essencial para projetos mais complexos. Além disso, ele é projetado para dar suporte aos principais browsers existentes. A escolha do GWT como parte deste projeto foi essencial por permitir uma programação orientada a objetos. A programação orientada a objetos já é padrão para o desenvolvimento de aplicações. Ela oferece diversas vantagens como abstração e encapsulamento de dados, facilidade para modularização, herança, polimorfismo, extensibilidade e reutilização de código. Entretanto, quando uma aplicação orientada a objetos acessa um banco de dados estritamente relacional, há dificuldades geradas pelo que é conhecido como descasamento de impedância [3]. Uma solução utilizada é o mapeamento, automático ou não, das classes da aplicação para as relações do banco. Outra solução utilizada é o armazenamento dos objetos em banco de dados orientados a objetos ou objetorelacionais. Esta segunda solução é mais eficiente para aplicações com estruturas de dados complexas, principalmente em bancos de dados completamente orientados a objetos. Todavia, a utilização de tais bancos não está estabelecida como padrão no mercado, o que leva a uma constante busca por melhorias na primeira solução. 6

7 Para um desenvolvimento eficiente e eficaz de aplicações web com estruturas de dados complexas, propomos um framework desenvolvido em Java para acesso e apresentação dos objetos automaticamente por meio de formulários diretamente mapeáveis para um banco de dados. O framework aqui proposto gera a interface automaticamente a partir do modelo de dados. A interface gerada é uniforme e intuitiva, resultante da abstração das interações possíveis com objetos de um modelo de dados. Tal interface pode ainda ser customizada para casos específicos. Além disso, qualquer modificação no modelo de dados atualiza a interface instantaneamente. Nas próximas seções são discutidas as alternativas existentes, o modelo de dados, a arquitetura, a interface gerada, uma aplicação web criada com o framework, as conclusões e os trabalhos futuros. A seção 2 compara as principais características das alternativas existentes com a proposta. A seção 3 detalha e explica o modelo de dados. A seção 4 descreve a arquitetura geral de cada módulo. A seção 5 dá uma visão geral da implementação do framework. A seção 6 mostra os passos necessários à criação de uma aplicação funcional. A seção 7 apresenta uma aplicação web criada a partir do framework. A seção 8 trata das conclusões. A seção 9 discute trabalhos futuros para melhoria e extensão do framework. O anexo 1 contém a primeira parte do diagrama de classes da aplicação AssetManager criada com o framework e o anexo 2 contém a segunda parte, referente ao cálculo dos extratos dos clientes. O diagrama do anexo 2 repete algumas classes do anexo 1 a fim de tornar a visualização mais clara. Ambos os diagramas seguem a notação UML e foram criados utilizando a ferramenta StarUML [19]. 2. Comparação com alternativas existentes Como visto na seção anterior, há a necessidade de soluções para um desenvolvimento eficaz e eficiente de aplicações web com estruturas de dados complexas. Nesta seção discutiremos as principais alternativas existentes e as compararemos com o framework proposto aqui. O objetivo desta seção não é listar e descrever todos os frameworks existentes mas sim dar uma visão geral dos principais, ressaltando as características importantes para fins de comparação. Para uma visão detalhada, ler [4]. Cada subseção a seguir dará uma visão geral da alternativa e a última tratará da comparação. 2.1 JavaServer Faces Java Server Faces é um framework baseado em componentes [4] desenvolvido pelo programa Java Community Process sob o processo JSR 314 [5]. Ela inclui um conjunto de APIs para representar e controlar seus componentes, gerenciar eventos, validar informações, definir a navegação entre páginas e dar suporte a internacionalização e acessibilidade. Também possui duas bibliotecas de tags para expressar uma interface JavaServer Faces dentro de uma página JavaScript e para conectar componentes com objetos do lado servidor. O desenvolvimento de uma aplicação JavaServer Faces requer quatro principais passos [6]: O mapeamento de servlet [7] (código Java residente no servidor que cuida do recebimento e resposta das chamadas), a criação das páginas da interface em JavaScript, a definição do controle de navegação entre as páginas e o desenvolvimento dos JavaBeans [8] (classes para objetos serializáveis normalmente ligados à visualização) para comunicar eventos da interface e guardar dados de objetos para envio ao servidor. 7

8 O principal benefício do JavaServer Faces é ser uma tecnologia pautada na arquitetura MVC (Model-View-Controler) [9] o que leva à organização e ao escalonamento no desenvolvimento da aplicação. 2.2 Struts Apache Struts é um framework open-source baseado em ações [4] desenvolvido pelo The Apache Struts Project sob a licença Apache License [10]. Ele também utiliza a arquitetura MVC. Os três principais componentes oferecidos pelo framework são: um gerenciador de chamadas (request handler) para mapear chamadas a URIs padrões, um gerenciador de respostas (response handler) para transferir o controle a outro recurso que termina de cuidar da resposta e uma biblioteca de tags para criar aplicações baseadas em formulários [11]. 2.3 Django Django é um framework para facilitar a criação de aplicações web voltadas a banco de dados [12]. Ele utiliza a linguagem Python, a arquitetura MVC e tem um modelo de dados orientado a objetos. Os passos básicos necessários à criação de uma aplicação são: Criar as classes do modelo de dados (o Django vem com uma ferramenta para criar um esquema em um banco de dados relacional a partir da definição das classes), Criar as URLs e o controle através das views e criar a apresentação através dos templates HTML. 2.4 Ruby on Rails Ruby on Rails também é um framework para facilitar a criação de aplicações web voltadas a banco de dados [13]. Ele utiliza a linguagem Ruby, a arquitetura MVC e tem um modelo de dados orientado a objetos. Ele se baseia no paradigma CoC (Convention over Configuration), que busca diminuir o número de decisões que o desenvolvedor tem que tomar para criar a aplicação. Os passos básicos para a criação de uma aplicação utilizando o Ruby on Rails são: Criar a base de dados, o controle da aplicação e a apresentação. Ele praticamente gera uma aplicação pronta para uso a partir da definição dos dados mas ainda necessita de configuração para o controle e desenvolvimento dos componentes HTML para apresentação. 2.5 Comparação das alternativas com o framework proposto Os frameworks apresentados acima fornecem bibliotecas e padronizações para que o usuário crie a interface, o controle e o modelo de dados da aplicação. O desenvolvedor tem grande flexibilidade na aparência e lógica final da sua aplicação. As alternativas que mais se aproximam da proposta aqui apresentada são o Django e o Ruby on Rails, ambos apoiando o desenvolvimento de aplicações web voltadas a bases de dados. Entretanto, mesmo tendo um foco em um modelo de dados orientado a objetos, eles não geram o controle e a interface imediatos, exigindo do desenvolvedor a definição do controle e da apresentação. O nosso framework fornece automaticamente uma interface e controle prontos para utilização a partir do mapeamento para um banco de dados. Com isso, ele exige menos conhecimento técnico do desenvolvedor e permite rápida criação de aplicações web. Além disso, a aplicação criada tem uma interface intuitiva e homogênea devido à definição abstrata da apresentação e controle dos objetos no framework. 8

9 3. Modelo de dados O modelo de dados do framework é um modelo orientado a objetos. Seu objetivo é oferecer suporte a estruturas de dados complexas e possuir homogeneidade no tratamento do acesso e alteração dos dados. Tal homogeneidade é obtida através de mecanismos definidos de maneira abstrata, tornando fácil a integração de novos dados. Além disso, há mecanismos para a geração automática de uma nova interface para abarcar a interação como os novos dados uma vez que estes pertençam ao modelo. As entidades do domínio são modeladas através de classes do domínio cujos objetos são denominados objetos do domínio. Daqui em diante, os objetos do domínio serão denominados objetos a não ser que explicitamente dito o contrário. Todos os objetos possuem um identificar único (oid) gerado pelo framework no momento de sua criação. O oid é um numero inteiro de oito bytes, onde os cinco primeiros bytes dizem respeito ao número do objeto, o sexto e o sétimo à sua classe e o oitavo ao número do banco de dados ao qual o objeto pertence. Isto significa que o framework suporta interação com até 256 bancos e, para cada um destes, classes e por fim, para cada uma destas, objetos. Qualquer objeto do domínio pode ser acessado diretamente a partir do seu oid. Um objeto pode ser de três tipos diferentes: dependente, independente ou exclusivo. Um objeto dependente é aquele cuja existência depende de outro objeto. No momento de sua criação, é necessário indicar o objeto ao qual ele pertence. Um objeto independente não tem sua existência atrelada a outros objetos. Um objeto dependente tem sua existência atrelada a um outro objeto e podem ser referenciados por outros objetos. Além disso, um objeto dependente só pode ser excluído caso não seja referenciado por nenhum outro objeto. Um objeto exclusivo é tem sua existência atrelada a outro objeto e não pode ser referenciados por outros objetos. Um objeto só pode ser de um dos tipos supramencionados. Os atributos possíveis de um objeto são: o Campos simples: Número inteiro, número real, número financeiro, string (cadeia de caracteres), escolha enumerável (lista ordenada de strings) e data. o Campos complexos: Objeto exclusivo: Representa um objeto exclusivo. Objeto dependente: Representa um objeto dependente. Referência única: Representa uma referência a um único objeto dependente ou independente. Lista de referências: Representa uma lista de referências a objetos dependentes ou independentes de uma mesma classe. Lista de objetos exclusivos: Representa uma lista de objetos exclusivos. Lista de objetos dependentes: Representa uma lista de objetos dependentes. Toda classe do domínio tem especificados os seus campos descritivos. Estes são aqueles que representam a descrição de um objeto quando este se encontra listado. Tais campos podem representar um tipo simples ou uma referência única. Além disso, toda classe do 9

10 domínio também tem a opção de especificar um campo ordenador. Este campo será utilizado na ordenação da visualização dos objetos em uma lista. Quando não especificado um campo ordenador, a ordenação é feita segundo a ordem de inserção no banco de dados. 4. Arquitetura Figura 1. Arquitetura geral do framework. A figura acima representa a arquitetura geral do framework. O módulo de interface é a parte da aplicação que define o modo como os objetos são visualizados. O gerenciador de contextos é o módulo responsável pelo controle da mudança dos elementos da interface. O módulo RPC é o responsável pela definição das chamadas possíveis ao servidor. O módulo de acesso ao banco de dados é o responsável pela execução das consultas de leitura e escrita ao banco de dados. O módulo de mapeamento é o responsável pela definição das classes e formulários que existirão na aplicação. As subseções abaixo detalharão cada um dos módulos, explicando a relação entre estes. 4.1 Interface O módulo da interface é composto pela definição da visualização e da lógica da apresentação dos objetos para o usuário. Nesta seção, trataremos dos conceitos do modelo de interface. As figuras representando cada um dos conceitos serão mostradas na seção 7, referente à aplicação criada. A lógica da apresentação é baseada em cinco principais conceitos: Uma classe do domínio, que representa o mapeamento do banco de dados para um modelo orientado a objetos. A descrição de uma classe, que representa as informações necessárias à manipulação das classes do domínio na interface. Um campo, que representa um atributo ou um relacionamento entre classes do domínio. Um formulário, que representa uma lista de campos onde todos são referentes a uma só classe do domínio. 10

11 Um objeto do domínio, que representa um objeto de uma classe do domínio. A tela apresentada na interface contém sempre uma lista das classes principais no topo, e, abaixo, ou uma tela listando objetos de uma mesma classe ou uma tela apresentando um formulário. Existem também janelas popups para inserção de objetos e referências. Os elementos da interface serão detalhados nas subseções seguintes. Um formulário pode ser editável ou não. Se ele não for editável, o usuário fica impedido de realizar qualquer alteração em seus campos e nos dos demais objetos dependentes do objeto representado pelo formulário Lista das classes independentes A lista é mostrada o tempo todo no topo da tela corrente e contém todas as classes que o desenvolvedor definiu como principais na sua descrição. A partir de tal lista, há a possibilidade de navegação para uma classe. A ordenação dos elementos nesta lista se dá pela ordem da definição das classes principais pelo desenvolvedor. Não é possível para o usuário adicionar ou remover uma classe desta lista Tela de classe Esta tela diz respeito à visualização dos objetos de uma mesma classe através de uma tabela. Seus componentes são: O nome descritivo da classe. Uma tabela na qual as linhas são objetos listados e as colunas são os campos descritivos da classe. Um botão de inserção a partir do qual é possível inserir um objeto. Um botão de exclusão a partir do qual é possível excluir um ou mais objetos. Se a classe tiver subclasses, a tabela mostrará os objetos de todas as suas subclasses. A ordenação dos objetos se dá pelo nome da coluna ordenadora definida no mapeamento. Esta pode ser definida como uma coluna específica ou como modo default, o que fará com que os objetos sejam ordenados segundo a ordem de inserção no banco. 11

12 Figura 2. Uma tela de classe listando objetos que representam clientes no domínio da aplicação AssetManager criada com o framework Tela de objeto Esta tela diz respeito à visualização dos campos de um formulário. Seus componentes são: O caminho completo de uma classe independente até o objeto mostrado. A cada acesso feito seguidamente, a descrição do objeto é concatenada ao caminho. Os campos do objeto, um abaixo do outro. Para cada campo, há o seu título à esquerda e o seu componente de interface à direita. A ordenação dos campos se dá pelo atributo definido (ou default) como ordenador da classe do domínio. Esta tela também pode mostrar os objetos somente em modo não editável. Isto impede qualquer alteração no conteúdo dos campos porém ainda permite navegação e acesso. 12

13 Figura 3. Uma tela de objeto mostrando um objeto que representa uma fatura no domínio da aplicação AssetManager criada com o framework Campos Os Campos representam os atributos possíveis de um objeto do modelo de dados. A seguir seguem os tipos de campo disponíveis: CampoData: Representa um tipo temporal. CampoEscolha: Representa um tipo enumerável. CampoTextBox: Representa um tipo que pode ser representado somente por uma textbox. o CampoTextBoxString: Representa um tipo string (cadeia de caracteres). o CampoTextBoxInt: Representa um tipo número inteiro. o CampoTextBoxReal: Representa um tipo número real. o CampoTextBoxDinheiro: Representa um tipo valor financeiro. CampoRefUnica: Representa uma referência a um objeto. CampoListaRef: Representa uma lista de referências. CampoListaObjDependentes: Representa uma lista de objetos dependentes. CampoListaObjExclusivos: Representa uma lista de objetos exclusivos. Os componentes de interface default para cada campo são: CampoData: Uma caixa de texto mostrando a data e um ícone para abrir um calendário a partir do qual o usuário pode editá-la. No caso de ser não editável, mostra somente um texto. CampoEscolha: Uma caixa mostrando o valor atual e a possibilidade de abrir uma lista para mostrar os valores possíveis e editar o campo. No caso de ser não editável, mostra somente um texto. 13

14 CampoTextBox: Uma caixa de texto para mostrar o valor. No caso de ser não editável, mostra somente um texto. o CampoTextBoxString: Aceita qualquer caractere e pode ter a opção de limitar o número máximo de caracteres. o CampoTextBoxInt: Aceita somente algarismos e os caracteres. e -. o CampoTextBoxReal: Aceita somente algarismos e os caracteres.,, e -. o CampoTextBoxDinheiro: Aceita somente algarismos e os caracteres.,, e -. CampoRefUnica: Um texto em negrito e sublinhado, contendo a descrição do objeto referenciado. No caso de ser não editável, mostra somente um texto. CampoListaRef: Uma tabela com as colunas sendo os campos descritivos e as linhas os objetos listados. O usuário pode navegar a partir de uma célula da tabela se a sua coluna for referente a uma referência a outro objeto. Abaixo da tabela, há dois botões um para inserção e outro para exclusão de objetos. No caso de ser não editável, mostra somente a tabela sem os botões abaixo. CampoListaObjDependentes: Componente igual ao do CampoListaRef. Entretanto, a tabela contém uma coluna a mais chamada Detalhe. Todas as células têm, nesta coluna, o conteúdo.... A partir de uma célula desta coluna, o usuário pode acessar o objeto listado. CampoListaObjExclusivos: Componente igual ao do CampoListaObjDependentes Tela de nova referência única Esta tela diz respeito à visualização da escolha de uma nova referência a um objeto em um CampoRefUnica. Ela é uma janela modal (impede o acesso a outros componentes da interface até que seja fechada) e os seus componentes são: Uma tabela na qual as linhas são objetos listados e as colunas, os campos descritivos da classe. Um botão de confirmação. Um botão de cancelamento. 14

15 Figura 4. Uma tela de nova referência única para inserção de uma nova referência a um objeto que representa uma corretora no domínio da aplicação AssetManager criada com o framework Tela de nova referência múltipla Esta tela diz respeito à visualização da escolha de uma ou mais novas referências a objetos em um CampoTabelaRef ou CampoTabelaRefComAtributos. Ela é uma janela modal (impede o acesso a outros componentes da interface até que seja fechada) e os seus componentes são: Uma tabela na qual as linhas são objetos listados e as colunas, os campos descritivos da classe. Um botão de confirmação. Um botão de cancelamento. Figura 5. Uma tela de nova referência múltipla para inserção de novas referências a objetos que representam operações de papéis à vista. 15

16 4.1.7 Tela de descrição de um objeto Esta é uma tela de transição entre a requisição da inserção de um objeto e sua inserção no banco. Ela diz respeito à visualização do preenchimento dos campos de descrição obrigatórios da Classe do formulário referente ao objeto a ser inserido. A tela é uma janela modal (impede o acesso a outros componentes da interface até que seja fechada) e os seus componentes são: Um formulário com somente os Campos descritivos. Um botão de confirmação. Um botão de cancelamento. Figura 6. Uma tela de descrição de um objeto para definir o valor dos campos que descrevem o cliente a ser inserido. 16

17 4.2 Gerenciador de contextos Figura 7. Diagrama do gerenciador de contextos. O gerenciador de contextos é o módulo responsável pelo controle de fluxo das telas e do histórico da aplicação. As ações possíveis são: listar os objetos de uma classe, detalhar um objeto independente, navegar, acessar, alterar, inserir e excluir. Listar os objetos de uma classe: A ação de ir para uma tela de classe a fim de visualizar os objetos de uma classe. Detalhar um objeto independente: A ação de ir para uma tela de objeto a fim de visualizar um objeto independente listado em uma tela de classe. Navegar: A ação de ir para uma tela de objeto a fim de visualizar um objeto dependente ou independente a partir de uma referência a ele. Acessar: A ação ir para uma tela de objeto a fim de visualizar um objeto exclusivo. Inserir: Excluir: o Um objeto: A ação de inserir um objeto a partir de uma tela de classe. o Uma referência a um objeto: A ação de inserir uma referência a um objeto a partir de um CampoRefUnica em uma TelaObjeto ou em uma TelaObjetoDescricao. o Um objeto interno: A ação de inserir um objeto interno a partir de um CampoMultObjInternos em uma TelaObjeto. o Múltiplas referências a objetos: A ação de inserir uma ou mais referências a partir de um CampoRefMultipla ou CampoRefMultiplaComAtributos em uma TelaObjeto. o Um ou mais objetos: A ação de excluir um ou mais objetos a partir de uma TelaClasse ou CampoMultObjInternos. o Uma referência única: A ação de excluir uma referência única a partir de um CampoRefUnica em uma TelaObjeto. 17

18 4.3 RPC o Múltiplas referências: A ação de excluir uma ou mais referências a partir de um CampoRefMultipla ou um CampoRefMultiplaComAtributos em uma TelaObjeto. O módulo RPC é o responsável pela definição das chamadas possíveis ao servidor. As chamadas possíveis são: Inicializar o servidor, consultar todos os objetos de uma classe, consultar um objeto, consultar a descrição das classes principais, consultar a descrição de um caminho, atualizar um objeto, inserir um objeto, excluir objetos e finalizar o servidor. 4.4 Acesso ao banco de dados Figura 8. Diagrama do módulo de acesso ao banco de dados. O módulo de acesso ao banco de dados implementa as funções definidas no módulo RPC. Atualmente ele só tem o dialeto PostgreSQL implementado. As consultas ao banco para obter um formulário passam antes pelo Tratador de Campos. Ele verifica qual o tipo do campo e o inicializa de acordo com a necessidade. Da mesma maneira, a atualização de um formulário chama o tratador de campos para atualizar cada campo seu. Na inserção de um formulário, o módulo recebe o formulário com os campos obrigatórios já preenchidos da interface e o insere no banco. 4.5 Mapeamento Para que seja possível a manipulação dos dados segundo um modelo de dados orientado a objetos, se faz necessário um mapeamento para o tipo de banco de dados escolhido. A partir do mapeamento, tem-se uma interface default completa pronta para acesso e alteração dos dados. O mapeamento é feito através das classes do domínio. Estas são as classes dos objetos do domínio. Dentre outras coisas, elas definem a independência, dependência ou exclusividade de seus objetos. 5. Implementação Nesta seção daremos uma visão geral da implementação do framework em contraste ao modelo proposto. O objetivo desta seção não é representar uma documentação do código mas sim apresentar os conceitos envolvidos em cada um dos seus módulos. 18

19 A implementação do Framework foi feita em Java, utilizando o GWT. A parte de apresentação utiliza também o SmartGWT. Este é um conjunto de APIs para o GWT, bibliotecas para Java e servlets compatível com o GWT. O SmartGWT é distribuído sob a licença Lesser GNU Public License, version 3. A sua escolha para o projeto se deu por ele oferecer componentes de interface estética e funcionalmente melhores do que o GWT puro. A visualização é definida através dos componentes de interface disponíveis na biblioteca do SmartGWT. Só há suporte ao mapeamento para bancos de dados objeto-relacionais A função create_basics(), que gera as tabelas e funções básicas para o funcionamento do mapeamento, só tem versão escrita em PostgreSQL. Portanto, esta seção se dividirá em duas subseções, uma para a implementação em Java e a outra para a implementação em PostgreSQL. 5.1 Implementação em Java Os detalhes da implementação serão tratados nas subseções abaixo, que representam os pacotes através dos quais foi organizado o código. org.cliente: Este pacote e todos os seus subpacotes contém a parte do código que fica no lado cliente da aplicação. Num primeiro nível, ele contém a classe EntryPointClient que cuida do recebimento de chamadas do browser como acesso direto por bookmark, back, forward e fechamento da janela. Tais chamadas são repassadas ao módulo de controle, que tem acesso ao histórico da aplicação. org.cliente.apresentacao: Este pacote contém as classes referentes à apresentação. Num primeiro nível, ele tem as classes ClassesCliente e DescricaoClasse. A classe DescricaoClasse define os atributos de descrição das classes do domínio necessários ao lado cliente. A classe ClassesCliente contém uma lista de classes DescricaoClasse, uma para cada classe do domínio. org.cliente.apresentacao.campo: Este pacote contém as classes referentes à definição dos atributos e comportamento necessários ao funcionamento dos campos no lado cliente. Nestas classes são definidos os componentes de interface utilizados em cada tipo de campo. A classe da qual todas herdam é a classe Campo. Esta classe contém: o Um título o O nome da coluna à qual este campo se refere no banco de dados (no caso de campos do tipo simples ou de referência única). o O nome da classe à qual este campo faz referência (no caso de um campo de tipo lista de objetos). o Indicação se é navegável. o Indicação se é editável. o Indicação se é descritivo. O que determina se a sua referência pode ser apagada ou apenas editada o Indicação se a sua descrição deve ser buscada na classe à qual faz referência ou se será explicitada pelo desenvolvedor (no caso de um campo de tipo lista de referências ou de objetos). 19

20 org.cliente.apresentacao.form: Este pacote contém a classe Form, referente à definição do conceito de formulário. A classe Java Form contém a indicação de sua classe do domínio, de um título, se ele é editável, se o objeto que ele representa deve poder ser visualizado, e uma lista de campos. Um Form editável implica na renderização de seus campos como componentes de interface para edição de valores; já um Form não editável implica na renderização de componentes de interface para leitura somente. Um Form pode ter a indicação de descrição suficiente. Isto significa que ao inserir um objeto presentado por ele, o usuário permanece na mesma tela sem acessá-lo. Do contrário, ao inserir o objeto, o usuário é levado a uma nova tela onde lhe é apresentado o formulário do objeto inserido. org.cliente.apresentacao.tela: Este pacote contém as classes referentes à definição e controle dos diferentes tipos de tela. A classe da qual todas as classes deste pacote herdam é a classe Tela. Ela contém as definições de design que são aplicadas como default a todas as suas subclasses que chamam seu construtor ao serem inicializadas. org.cliente.controle.exceptions: Este pacote contém as classes referentes à definição dos diferentes tipos de exceções. Existem duas exceções criadas: DataBaseException, para exceções causadas pela interação com o banco de dados, e FormatoCampoException, para quando o usuário edita o campo de uma maneira não permitida. org.cliente.controle.historico: Este pacote contém as classes referentes ao controle de histórico da aplicação. A classe Historico mantém um mapeamento de strings para contextos da aplicação. Um contexto da aplicação é definido na classe Contexto e contém informações como o tipo de tela mostrado, o oid do objeto, indicação se o contexto é somente de leitura, dentre outras. O mapeamento permite a recuperação de um contexto através de uma string do URL. Além disso, quando o usuário acessa a aplicação por bookmark, o framework tenta acessar o objeto pedido e, caso não consiga, retrocede para o objeto pai até que chegue a uma classe. org.cliente.controle.rpc: Este pacote contém as classes referentes à definição das diferentes chamadas possíveis ao servidor. org.cliente.util: Este pacote contém as classes referentes à definição de funções e componentes de uso geral. A classe Translator contém as funcionalidades para troca do idioma das mensagens de alerta do framework de inglês para português ou vice versa e dá suporte para inserção de mais idiomas. A classe Util contém funções para obter o número de uma classe a partir do oid de um objeto pertencente a ela, gerar uma janela de alerta com a mensagem passada e também funções para formatação de números. org.server: Este pacote contém as classes do lado servidor da aplicação. Num primeiro nível, ele contém as classes referentes à definição das funções que implementam todas as chamadas possíveis do lado cliente. org.server.mapeamento: Este pacote contém as classes referentes ao mapeamento dos dados. Num primeiro nível, ele contém as classes referentes ao mapeamento para as tabelas do banco de dados. Na classe Java ClasseDominio deste pacote, há uma função recursiva para consulta dos campos descritivos da classe do domínio. Como uma classe do domínio pode ser descrita por um 20

21 campo que é uma referência a outra classe do domínio, criou-se a função recursiva para poder navegar e obter a consulta necessária à obtenção dos campos descritivos. Além disso, a função anota nos resultados da consulta o tipo do campo para que a interface possa saber como lidar com ele na tabela. Também há funções para consultas a todos ou a um objeto específico da classe do domínio. org.server.mapeamento.form: Este pacote contém as classes referentes ao mapeamento dos formulários. Todas as classes deste pacote herdam da classe Form, definida no pacote org.client.apresentacao.form. Abaixo segue uma figura demonstrando o mapeamento de um formulário, definido na classe FormClienteContaCorretora referente à classe do domínio ClienteContaCorretora: Figura 9. Snapshot da Implementação da Classe FormClienteContaCorretora. Figura 10. Snapshot da Implementação da Classe FormExtratoAplicacao. Atente para o campo de referência única Conta que não permite que sua referência seja apagada através da indicação Campo.RESTRICT_REF. org.server.relatorio: Este pacote contém as classes referentes à implementação do cálculo dos relatórios existentes. 21

22 org.server.tratcampo: Este pacote contém as classes referentes ao tratamento das modificações feitas nos campos de um formulário. A classe da qual todas herdam é a classe TratCampo. Esta classe tem somente duas funções: preenchevalor e gravavalor. A primeira preenche um campo com os valores obtidos do banco de dados e a segunda grava o valor do campo no banco de dados. Toda vez que um formulário chega do cliente ao servidor devido a uma inserção ou alteração, cada campo que foi alterado é tratado pelo seu tratador de campo específico que grava os dados no banco de dados. No caso de um pedido de acesso a um objeto, é criado um formulário onde cada campo é preenchido pelo seu tratador de campo específico. 5.2 Implementação em PostgreSQL Esta seção contém uma visão geral da implementação feita em PostgreSQL. Para dar suporte ao mapeamento, foram criadas tabelas, funções e gatilhos. As funções criadas servem para: Alocar e desalocar blocos de objetos no banco de dados. Funcionalidade criada para o caso em que uma aplicação tem geração de diversos objetos ligados a um único (como no caso do relatório de Extrato). Como a criação de um objeto recebe um oid sequencial, a alocação e desalocação permite um reaproveitamento de oids. Obter o nome de uma classe a partir do seu número. Criar um novo objeto. A função recebe a classe, as colunas e uma lista de valores a serem inseridos. Os gatilhos criados servem para: Gerenciar a desalocação de blocos dos objetos exclusivos de um objeto excluído. Gerenciar a integridade referencial de tabelas que representam heranças. O gatilho foi criado porque o PostgreSQL, até a data da redação deste documento, não dava suporte a restrições de unicidade e chave estrangeira em tabelas que utilizem a funcionalidade de herança [15]. As tabelas criadas são: blocos_obj_alocados: Contém uma referência ao objeto dono do bloco, o oid do primeiro objeto do bloco e o tamanho do bloco (fixado em 100 pela função de alocar blocos de objetos). Necessária para o reaproveitamento de oids como visto na explicação das funções para alocar e desalocar objetos. blocos_obj_livres: Contém o oid inicial e o tamanho dos blocos livres de objetos. Necessária para o reaproveitamento de oids como visto na explicação das funções para alocar e desalocar objetos. classes: Contém o número e o nome das tabelas que representam classes do domínio. A partir desta tabela, pode-se obter o nome de uma tabela através de seu número o que aumenta a eficiência ao evitar a necessidade de manipulação de strings. db_inf: Contém o oid do último objeto inserido e o número do banco de dados. Essas informações podem ser utilizadas quando o framework estiver trabalhando com mais de um banco de dados. 22

23 obj: Contém uma coluna oid. Todas as tabelas que representem uma classe do domínio devem herdar desta; assegurando a coluna oid em todas elas. ref_extras: Contém o oid de origem e o oid de referência para armazenar as referências feitas a tabelas que representam heranças. Existe para o caso de banco de dados objeto-relacional que não dêem suporte à manutenção de integridade referencial em tabelas que representam heranças (como é o caso do PostgreSQL). 6. Passos Para Criação de uma Aplicação Utilizando o Framework Após uma visão geral de como são definidos os conceitos e o comportamento do framework, iremos explicar os passos necessários para a criação de uma aplicação funcional de maneira ordenada nas subseções abaixo. Os passos são a criação de um banco de dados e o mapeamento da aplicação para ele. 6.1 Criação do banco de dados Primeiramente, o desenvolvedor deverá criar o esquema dos seus dados em um banco de dados relacional. Na implementação atual, há a necessidade de que o esquema do banco de dados siga uma certa padronização e seja feito no PostgreSQL. Para isso, existe uma função create_basics() que deve ser executada primeiramente pelo desenvolvedor no esquema em criação. Então, para cada relação ou relacionamento, o desenvolvedor deverá criar um registro na tabela classes mapeando um número inteiro para o nome da tabela e fazê-la herdar da tabela obj. Além disso, no caso de uma classe de objetos exclusivos, o desenvolvedor deverá criar uma coluna origem que seja uma chave estrangeira para a classe que contém os objetos exclusivos. 6.2 Mapeamento para o banco de dados Após criar o banco de dados, o desenvolvedor deverá mapear a posição da Classe na lista de ClasseDominio presente na classe ListaClasses com o número correspondente da tabela básica classes no banco de dados. Para criar seus formulários, o desenvolvedor deverá criar uma classe que herde da classe Form e dentro dela determinar os Campos a partir dos tipos de Campo disponíveis. Os formulários também podem ter a opção de indicação de que podem gerar um relatório. Um relatório é por si também um objeto que é criado por meio de uma função que cria outros objetos que o comporão. Ao pedir a inserção de um objeto que gera relatório, módulo ativa a função que, ao terminar, gera o objeto. O desenvolvedor pode também criar o seu próprio tipo de Campo, bastando criar uma classe que herde da classe Campo e implemente suas funções obrigatórias. 7. Exemplo de aplicação Como exemplo, temos uma aplicação que foi criada para gerência de carteiras de investimento no mercado financeiro. Tal aplicação é utilizada atualmente por uma empresa. Na aplicação, há o objeto Extrato que gera relatório. Para o cálculo desse relatório, utiliza-se o Hibernate para obter os objetos do banco e realizá-lo de maneira eficiente. Hibernate é um framework, criado por Gavin King em 2001, para persistências de dados que fornece uma camada de abstração orientada a objetos para lidar com banco de dados relacionais [14]. 23

24 No mapeamento feito, temos as classes do domínio principais e secundárias. Uma classe principal é aquela que é mostrado na lista de classes na interface, já uma secundária, não. 3 principais: Cliente, Corretora e Empresa. 31 secundárias, dentre as quais: Conta, Endereco, Telefone, Fatua, Operacao, PapelAVista, PapelOpcao, Aplicacao, Resgate, Taxa, PagamentosPerformance, OperacaoVista, Operacao,Opcao, Extrato, ExtratoMovimentacaoAplicacao, ExtratoMovimentacaoBonificacao e ExtratoSituacaoInicialConta. 1 Form para cada classe do domínio, sendo que um deles pode gerar relatório (FormExtrato). Três exemplos de herança: Papel (PapelAVista e PapelOpcao), Operacao (OperacaoVista, OperacaoOpcao) e ExtratoMovimentacao (ExtratoMovimentacaoAplicacao, ExtratoMovimentacaoBonificacao...). O diagrama de classes se encontra no anexo 1. Abaixo seguem snapshots das telas do sistema: Figura 11. TelaClasse e TelaNovoObjetoDescricao. Na Figura 6 temos, à esquerda, uma TelaClasse de Cliente e à direita, uma TelaNovoObjetoDescricao de Cliente (Nome e CPF são campos descritivos de Cliente). 24

25 Figura 12. TelaObjeto e TelaNovaRefUnica. Na Figura 7, temos, à direita, a TelaObjeto de Fatura. No detalhe, o caminho completo da Classe independente (Cliente) até o objeto sendo visualizado. À esquerda, temos a TelaNovaRefUnica de Corretora. Figura 13. TelaNovaRefMultipla da Classe OperacaoVista. 25

26 Figura 14. TelaObjeto da Classe Extrato. Na figura acima, temos o campo Movimentações. Este inclui diversas subclasses da classe ExtratoMovimentacao em uma mesma tabela. Atentar para o fato de que este é um Form não editável portanto seus Campos são só para visualização e o componentes de interface mudam (exemplo: CampoData é somente um texto e não mais uma caixa editável de texto com calendário acoplado). O objeto Extrato mostrado acima, é um exemplo de relatório. Ao criar um extrato, uma função é chamada que processa diversos outros objetos e cria um objeto Extrato como resultado. 26

27 Figura 15. Exclusão de um Objeto Empresa. Na figura acima, a tentativa de excluir um objeto de Empresa falha pois ainda existem objetos no banco que são dependentes dele. Em todas as telas sempre estava sendo mostrada no topo a lista de classes Independentes, com as classes Cliente, Corretora e Empresa. 8. Conclusões O framework apresentado aqui tem o objetivo de ser uma solução para criação de aplicações web de maneira eficaz e eficiente. Isto se torna possível com a eliminação das etapas de programação do controle e da interface da aplicação e foco na modelagem de dados. Além disso, através de definições abstratas, pautadas no paradigma de orientação a objetos, o framework consegue criar uma interface homogênea e intuitiva para os usuários. Existem inúmeras opções de framework para aplicações web. As principais diferenças entre o framework apresentado aqui e os demais são o foco na modelagem de dados e a completa automatização default do controle e apresentação da aplicação. A aplicação criada com o framework e utilizada para fins comerciais e mostra que ele tem potencial para criar aplicações reais. 27

28 9. Trabalhos futuros Os trabalhos futuros se dividem em quatro principais frentes: Maior separação dos componentes de interface e sua lógica de controle, maior separação entre o modelo de dados, uma extensão do mapeamento para se poder trabalhar com outros bancos de dados objeto-relacionais além do PostgreSQL e uma automatização no mapeamento. A separação entre apresentação, controle, modelo de dados e mapeamento é essencial para uma melhor manutenção do código e maior escalabilidade do framework. Cada subseção abaixo tratará de uma frente diferente. 9.1 Separação entre os Componentes de Interface e sua Lógica Esta separação implicaria numa maior facilidade de mudança dos componentes de interface para cada elemento de apresentação. O desenvolvedor deve ter a possibilidade de criar os componentes de interface sem precisar compreender toda a lógica do controle. Isto poderia ser feito com a criação de interfaces Java para funcionar como definição das comunicações possíveis entre as classes. 9.2 Separação entre o Modelo de Dados e o Mapeamento Esta separação implicaria na possibilidade do desenvolvedor criar suas classes do domínio de maneira totalmente orientada a objetos sem se preocupar com o tipo banco de dados utilizado. Isto poderia ser feito com a redefinição da classe ClasseDominio para conter somente atributos relativos ao modelo e não ao mapeamento. Além disso, criar diferentes grupos de classe com a lógica necessária para acesso a cada tipo de banco de dados. Para isso, seriam criadas interfaces Java definindo a comunicação que ClasseDominio teria que ter com o mapeamento e classes para representar tal comunicação. 9.3 Extensão do Mapeamento A extensão do mapeamento implicaria numa maior flexibilidade do framework para trabalhar com diferentes tipos de banco de dados como XML, uma linguagem de marcação para armazenamento de dados [16] e banco de dados puramente orientado a objetos por exemplo. Isto poderia ser feito somente a partir da separação do modelo de dados do mapeamento. Existindo tal separação, seria necessário criar diferentes grupos de classes para cada tipo de banco de dados. No caso de XML, teria que ser feito um estudo de como manter o controle de oids e referências na aplicação. Também seria interessante manter uma organização de diretórios ou tags para facilitar a organização em classes. 9.4 Automatização do Mapeamento A automatização do mapeamento implicaria numa maior eficiência na criação da aplicação. O desenvolvedor precisaria somente criar o seu modelo de classes do domínio e então o framework faria o mapeamento, criando o esquema de dados para o tipo de banco de dados escolhido. Isto poderia ser feito com a implementação de classes para percorrer as classes do domínio e através de Annotations nestas, decidir sobre o mapeamento na hora da criação do banco de dados que a aplicação acessará. Annotations são parte da sintaxe da linguagem Java que não influenciam diretamente na semântica do código do qual fazem parte [17]. Elas servem como comentário de trechos de código ou como base de decisão 28

29 em tempo de compilação ou interpretação. Além das Annotations, seria necessário implementar um arquivo de configuração onde o desenvolvedor definisse o tipo de banco de dados que deseja utilizar. 10. Referências [1] Garret, Jesse James. (2005) AJAX: A New Approach to Web Applications, February. [2] Google Inc. (2010) GWT Product Overview, January. [3] Woodfield, Scott N. (1997) The Impedance Mismatch Between Conceptual Models and Implementation Environments, Computer Science Department, Brigham Young University. [4] Darwin, Ian F., French, Cathy. (2004) Java Web MVC Frameworks: Background, Taxonomy and Examples, Unpublished; submitted for partial credit towards the degree of Master of Science at Staffordshire University. [5] Java Community Process. (2011) JSR 314, [6] Mahmoud, Qusay H (2005) Developing Web Applications with JavaServer Faces, Oracle Technology Network, August. [7] Oracle (2011) Java Servlet Technology, [8] Oracle (2011). JavaBeans API Specifications, [9] Reenskaug, Trygve (2003) The Model-View-Controller (MVC) Its Past and Present, University of Oslo. [10] The Apache Software Foundation (2011). Struts, [11] Roughley, Ian (2006) Starting Struts 2, C4Media, published in InfoQ.com. [12] Django Software Foundation (2011) Django, [13]David Heinemeier Hansson (2011) Ruby on Rails, [14] King, Gavin (2011) Hibernate, [15] PostgreSQL (2011) PostgreSQL Inheritance, [16] W3C (2011) XML Technology, [17] Oracle (2011) Java Annotations, 29

30 Anexo 1 Primeira Parte do Diagrama de Classes da Aplicação AssetManager 30

31 Anexo 2 Segunda parte do Diagrama de Classes Referente ao Cálculo de Extratos da Aplicação AssetManager 31