5. MODELAGEM E IMPLEMENTAÇÃO DO FRAMEWORK
5.2. O ARQUIVO DE C ONFIGURAÇÃO
5.2.1 A tag <tabela>
Esta tag possui três propriedades, que são mapeadas para a classe Tabela da seguinte forma:
nome: representa o nome da tabela à qual representa e mapeia o atributo nome da classe Tabela. Este atributo equivale ao atributo descritor, que
deve ser armazenado nos objetos que herdam as classes ValueObject e
CompositeEntity, exibidas na figura 14.
chave-primaria: como o framework engloba apenas tabelas que possuem chave primária simples, só haverá um campo para armazenar esta chave. Esta propriedade mapeia o atributo chavePrimaria da classe Tabela. nome-atributo: esta propriedade mapeia o atributo nomeAtributo na classe Tabela. Ele armazena o nome do atributo que representa um objeto
em uma classe que implementa a classe CompositeEntity. Porém, deve-
se ter cautela na utilização desta propriedade. Ela representa o nome de um objeto no contexto de um composite. Segundo os casos que este framework
aborda, um composite pode conter instâncias que estendem ValueObject
ou mesmo CompositeEntity, ou seja, pode conter tanto entidades simples quanto outro composite, ou uma lista deles. Para a utilização do framework é necessário que os objetos contidos em um composite possuam o sufixo VO quando esses representam ValueObject, e o sufixo CE quando representam entidades CompositeEntity. Esta propriedade da tag deve conter o nome do atributo sem este sufixo, pois dentro do contexto de um composite, um representação de uma tabela pode tanto ser um objeto
simples (ValueObject) quanto um composite (CompositeEntity).
5.2.2
A tag <campo>
Esta tag sempre estará contida dentro de uma tag <tabela>, pois ela representa uma chave estrangeira contida na tabela que sua tag pai descreve. Obrigatoriamente esta tag deve conter outra tag <tabela> que deve descrever a tabela a qual esta chave estrangeira está referenciando, lembrando que somente campos que fazem referência para outras tabelas devem ser configurados em tags <campo>.
A tag <campo> é mapeada pela classe Campo descrita na figura 16. Possui apenas a propriedade multiplo. Esta propriedade deve ser atribuída com o valor N , caso o relacionamento da tabela pai com a tabela filha seja do tipo 1 para 1, ou S caso o relacionamento seja do tipo 1 para muitos.
5.3.
Implementação do Protótipo
A parte lógica da implementação, mostrada na figura 17, concentra-se
basicamente em três classes: ParserXML, BeanUtilReflexao e Verificador.
Figura 17 Principais classes do framework
Este diagrama de classe mostra apenas os principais métodos utilizados para verificar o estado dos objetos de negócio.
A classe ParserXML tem a função de ler o arquivo de configuração e criar os objetos que mapeiam as tags como explicado na sessão 5.2. O método getTabela
pesquisa nas tags <tabela> do primeiro nível, ou seja, as tags <tabela> que se encontram ligas diretamente à tag raiz <tabelas>, aquela cuja propriedade nome desta tag é igual ao parâmetro fornecido no método. Se encontrar, retorna um objeto do tipo
Tabela, com seus respectivos atributos segundo o que for encontrado no arquivo de
configuração, e se não encontrar retorna uma exceção do tipo
TabelaNaoEncontradaException.
Os atributos são acessados com a utilização da API de reflexão da tecnologia Java. Maiores detalhes sobre esta API podem ser encontrados em (SHACHOR e
CHACE e RYDIN, 2000). A classe BeanUtilReflexao implementa o método
executaMetodoGet que permite invocar por reflexão um método que retorne um resultado pelo nome do método. Outra restrição do framework é de que os objetos de negócio sigam o modelo JavaBean, onde cada atributo da classe deve possuir um método get e set para sua manipulação. Desta forma, uma classe que possui um atributo
declarado como atributo deve possuir os métodos getAtributo e setAtributo, seguindo este padrão onde a primeira letra do atributo deve ser em maiúscula. O atributo do objeto de negócio é acessado com base na propriedade nome-atributo da tag <tabela>, como explicado na sessão 5.2.1.
A classe Verificador permite tanto fazer a verificação de objetos de granulação grossa (CompositeEntity), que é o foco central deste projeto, quanto objetos de granulação fina (ValueObject). Para isso implementa três métodos
principais: checaEstadoVO, que recebe como parâmetro um objeto do tipo
ValueObject; checaEstadoComposite, que verifica o estado dos objetos de negócio contidos neste, segundo o que for solicitado no arquivo de configuração; e
incrementaNumeroVersao, que aumenta de um o número da versão do objeto de negócio e armazena as alterações no objeto e em um meio secundário de armazenamento, onde as versões dos objetos estão sendo guardadas, por exemplo, como uma tabela de banco de dados. Caso um dos métodos de verificação detectem o objeto
desatualizado, retornam uma exceção do tipo VersaoDesatualizadaException.
Para recuperar os dados no arquivo de configuração, o método utiliza o valor armazenado no atributo descritor do objeto de negócio. Este descritor é utilizado pela classe ParserXML para buscar as informações através do método getTabela, ou seja, o atributo descritor representa a propriedade nome da tag <tabela>.
O framework não implementa um método para armazenar as informações com o número da versão do objeto de negócio. Isto fica a critério do programador, mas deve seguir um padrão. Uma proposta para armazenar a identificação e a versão do objeto seria em uma tabela de um banco de dados qualquer, contendo três colunas:
Tabela: deve armazenar o nome da tabela que o objeto de negócio implementa. Representa o atributo descritor das classes ValueObject e
CompositeEntity, que é o equivalente à propriedade nome da tag <tabela>.
Chave Primária: guarda o valor da chave primária do objeto de negócio. É necessário apenas uma coluna para armazenar o identificador do objeto, pois este framework trata apenas de objetos que representam tabelas de chave primária simples.
A figura 18 apresenta o diagrama de seqüência para fazer a verificação de um
objeto de negócio do tipo ValueObject. Neste diagrama apenas a classe
InterfaceDB não está implementada. Isso se deve ao fato do framework deixar a critério do programador a maneira de armazenar os dados para o controle de concorrência. O cliente solicita a um objeto da classe Verificador para checar o estado do ValueObject. Através do nome descritor contido neste, o objeto solicita a
ParserXML as configurações para fazer as verificações para aquele descritor. Com as configurações é possível saber qual é a chave primária do objeto. Esse atributo do objeto de negócio é recuperado com a invocação de um método por meio de reflexão, que está implementado na classe ReflexaoUtil. Uma vez tendo o nome do descritor e a chave primária do objeto, o número da versão atual do objeto é recuperada através da classe InterfaceDB. O passo final é fazer a comparação das versões. Se elas não
coincidirem uma exceção do tipo VersaoDesatualizadaException é disparada,
caso contrário nada acontecerá.
Figura 18 Diagrama de seqüência para verificar ValueObject
A figura 19 mostra o diagrama de seqüência para verificar o estado de um objeto de negócio do tipo CompositeEntity. A lógica é similar ao o procedimento utilizado para verificar um objeto do tipo ValueObject, com exceção do método
verificaComposite, que é recursivo, pois dentro de um composite pode haver outro composite.
Figura 19 Diagrama de seqüência para verificar um CompositeEntity
A figura 20 apresenta o diagrama de seqüência para incrementar o número da versão do objeto de negócio do tipo ValueObject. O número incrementado é armazenado em um meio secundário e também guardado no objeto de negócio passado por parâmetro. A forma de armazenamento em um meio secundário deve ser definido pelo analista.
Tanto o método de busca quanto de incremento do número de versão de um objeto são sincronizados, ou seja, estes métodos só podem ser executados seqüencialmente. Duas incrementações não podem ser executadas paralelamente. Esta etapa deve ser tratada, pois aqui também pode haver um problema de concorrência com o número de versão dos objetos.
A decisão de não implementar o meio de armazenamento se deu em função de deixar o aplicativo mais flexível ao programador, desprovendo o framework de um vínculo com algum banco de dados, por exemplo, onde é necessário a configuração do driver do banco. Isso também permite que o programador armazene a versão do objeto da maneira mais conveniente para o contexto da sua aplicação.
5.4.
Exemplo de Aplicação
Esta sessão apresenta um exemplo de uma modelagem de objetos que pode ser aplicada com a utilização do framework. O diagrama de classes apresentado na figura 21 descreve uma modelagem de objetos de negócio que seguem os padrões para poder fazer a verificação do estado do objeto.
Este diagrama está incompleto, sendo que a finalidade dele é destacar os pontos principais para a utilização do framework. As classes cujo nome possuem o sufixo
VO são sub-classes de ValueObject, e as classes com terminação CE são sub-
classes de CompositeEntity. O arquivo de configuração apresentado na figura 15 pode ser utilizado para verificar os objetos de negócio apresentados neste exemplo.
Como apresentado no diagrama, a classe Tabela1CE é composta por mais dois composites, Tabela2CE e Tabela4CE, e um objeto simples, Tabela1VO. Porém, ao invés de ter uma lista de objetos do tipo Tabela2CE, Tabela1CE também poderia conter uma lista de objetos de granulação fina, ou seja, ValueObject, que representassem a mesma tabela ( TABELA2 , neste caso). A mesma observação se aplica ao objeto do tipo Tabela4CE, contida na classe principal.
Outro ponto a ser destacado aqui é sobre o objeto tabela4CE contido na classe
Tabela1CE. Este objeto não será verificado, pois não está registrado no arquivo de configuração no escopo de TABELA1 .
6.
Considerações Finais
6.1.
Dificuldades Encontradas
Trabalhar com a tecnologia J2EE já é um desafio. É uma arquitetura em constante avanço, com um vasto campo de recursos, o que pode em muito induzir o usuário ao erro com suas soluções. Tratar de um problema específico para este ambiente aumenta ainda mais a necessidade de um conhecimento mais aprofundado do tema.
Esta dificuldade foi amenizado pelo fato do autor deste projeto já estar trabalhando com a área que envolve este problema. Além do estudo apurado da tecnologia, também foi necessário uma visão de alto nível, através do estudo de padrões que estão sendo aplicados para esta tecnologia, a fim de enquadrar o projeto com padrões de projeto já difundidos entre usuários desta arquitetura.
Outro ponto, não menos importante, foi a pesquisa de um componente para ler o arquivo de configuração, sendo que existem muitos atualmente, assim como do formato do arquivo para que melhor se adequasse à necessidade do framework desenvolvido.
6.2.
Conclusão
Sistemas distribuídos sempre requerem um grande volume de conhecimento para se trabalhar com esta área. O programador, assim como o analista de sistemas, precisar tratar de problemas que muitas vezes passam despercebidas por olhos menos atentos. A arquitetura J2EE descreve um conjunto de especificações para se trabalhar em ambientes distribuídos. Isto traz muitas vantagens, porém, a descentralização do processamento dos dados acarreta grandes riscos para a consistência das informações.
Em conseqüência da maturidade da tecnologia, vários padrões de projetos são desenvolvidos, tanto para contornar problemas como para otimizar o processo da aplicação. Estes padrões ganham maior importância quando utilizados no desenvolvimento de um framework. O desenvolvimento de um framework exige muita coerência na aplicação dos padrões, a fim de englobar o maior numero possível de aplicações em um determinado contexto.
Inicialmente este trabalho visava resolver um problema para aplicações em ambientes distribuídos. Porém, com o avanço do projeto, observou-se que a aplicação final se tornou mais genérica que o objetivo inicial. Este modelo pode ser aplicado em qualquer ambiente com concorrência entre multi-usuários, salvo as restrições do framework. A vantagem disso reflete na ampliação do contexto de aplicações que o projeto pode ser aplicado, em contrapartida, não será possível fazer otimizações para um contexto mais específico.
No decorrer do desenvolvimento deste projeto houve uma grande evolução na visão da tecnologia adotada. A solidificação dos conceitos aplicados neste trabalho foram adquiridos através de discussões com vários usuários que também compartilham destes problemas.
6.3.
Trabalhos Futuros
O projeto já dispõe de um grande recurso, que é verificar o estado de um objeto tanto de granulação fina quanto de granulação grossa. Mas isto ainda pode ser melhorado.
Além de verificação por número de versão, há ainda mais duas formas de verificação: Timestamp e comparação de estado. O primeiro é similar ao aplicado neste projeto. A diferença está no fato de guarda o horário da alteração ao invés do número de versão. Já a comparação de estado é mais complexa. Cada atributo do objeto de negócio é comparado com a versão atual para ver se houve alguma alteração prévia. Isto torna o custo da aplicação maior, pois ela deverá manter uma cópia inalterada do objeto para fazer a comparação.
Outra funcionalidade que poderia ser estendida ainda é a sincronização dos objetos. Este recurso, além de verificar o estado do objeto, retornaria o objeto com a versão atualizada. Em determinados ambientes pode ser oferecido ao usuário a opção de, mesmo que o estado do objeto esteja desatualizado, sobrescrever ou não as alterações
Este framework trata da verificação do estado de objetos de granulação grossa cujos componentes possuem dependências entre si. Porém, é comum o uso do padrão de projeto Value Object Assembler, que também contextualiza objetos compostos, mas não precisam necessariamente ter algum vínculo, o que cria uma interdependência entre eles.
Referências Bibliográficas
AKBAR-HUSAIN, Yasmin e LANE Eoin. Optimistic Locking pattern for EJBs
Deploy transactionally safe EJB code. Julho/2001. Disponível em:
http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.html. Acesso em: 01/10/2003.
ALUR, Deepak e CRUPI, John e MALKS, Dan. Core J2EE Patterns. As melhores práticas e estratégias de design. Editora Campus, 2002.
BECK, Kent e CUNNINGHAM, Ward. Using Pattern Languages for Object-Oriented Programs, Technical Report nº CR-87-43, 1987, disponível em: http://c2.com/doc/oopsla87.html. Acesso em: 15/12/2003.
BODOFF, Stephanie e GREEN, Dale e HAASE, Kim e JENDROCK, Eric e PAWLAN, Monica e STEARNS, Beth. Tutorial do J2EE. Editora Campus, 2002.
BROEMMER, Darren. J2EE Best Practices - Java Design Patterns, Automation and Performance. Addison-Wesley, 2003.
CAMPO, Marcelo e PRICE, Roberto Tom e TEYSEYRE, Alfredo. Uma Abordagem 3D para a Visualização de Padrões de Projeto. Outubro/1997. Porto Alegre.
DATE, C. J. Bancos de Dados Tópicos Avançados. Editora Campus Ltda, 1988.
FIELDS, Duane K. e KOLB, Mark Desenvolvendo na Web com JavaServer Pages. Editora Ciência Moderna, 2000.
GAMMA, Erich e HELM, Richard e JOHNSON, Ralph e VLISSIDES, John. Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
GOMES, Alexandre. Design Patterns J2EE. Outubro/2002. Disponível em: http://www.mundooo.com.br/php/modules.php?name=News&file=article&sid=474.
Acesso em: 19/12/2003.
GUIMARÃES, José de Oliveira. Frameworks. São Paulo, nov. 2000. Disponível em: http://www.dc.ufscar.br/~jose/courses/oc/apostilas-patterns.zip . Data de Acesso: 14/12/2003.
LARMAN, Graig. Applying UML and Patterns As Introduction to Object- Oriented Analysis and Design and the Unified Process. Segunda Edição. PH PRT, 2002.
MACORATTI, José Carlos. Redes Programas Multiusuários. Agosto/2002. Disponível em: http://www.macoratti.net/redes.htm. Acesso em: 09/01/2004.
MALDONADO, José Carlos et al. Padrões e Frameworks de software. Local: São Paulo: Universidade de São Paulo, ano de apresentação não disponível. Disponível em: http://www.icmc.sc.usp.br/~rtvb/apostila.pdf . Data de acesso: 14/12/2003.
MARINESCU, Floyd. EJB Design Patterns - Advanced Patterns, Processes, and Idioms. 2002.
MCCLANAHAN, Craig et. al. DIGESTER. Disponível em:
http://jakarta.apache.org/commons/digester/index.html. Acesso em:24/01/2004.
ROMAN, Ed e AMBLER, Scott e JEWELL, Tyler. Mastering Enterprise JavaBeans. Segunda Edição. John Wiley and Sons, Inc., 2002.
SHACHOR, Gal e CHACE, Adam e RYDIN, Magnus. JavaServer Pages Bibliotecas de Tags. Editora Ciência Moderna, 2000.
SILVA, Ricardo Pereira e. Suporte ao desenvolvimento e uso de frameworks e componentes. Porto Alegre, 2000.
SINGH, Inderjeet e STEARNS, Beth e JOHNSON, Mark. Desinging Enterprise Applications with J2EE Platform. Segunda Edição. Addison-Wesley, 2002.
SOUZA, Carlos Magno Carvalho de e MENEZES, Fabíola de Lima e TOGNERI, Denise Franzotti. Padrões de Projeto. FAESA - Faculdades Integradas Espírito Santenses, ano de apresentação não disponível. Disponível em:
http://www.oodesign.com.br/forum/index.php?act=Attach&type=post&id=51. Data de Acesso: 01/12/2003.
Sun Microsystems. Java 2 Platform, Enterprise Edition (J2EE). http://java.sun.com/j2ee/. Acesso em 10/11/2003.
XEXEO, Geraldo. Anti-patterns. Abril/2000. Disponível em: http://c2.com/cgi/wiki?AntiPatterns . Acesso em: 16/12/2003.
W3C World Wide Web Consortium. http://www.w3c.org. Acesso em 10/11/2003.
Anexo 1
Artigo
Framework para Controle de Concorrência
aplicado a Objetos Compostos
Adriano Ferlin
Ciências da Computação, 2004.
Departamento de Informática e Estatística INE
Universidade Federal de Santa Catarina (UFSC), Brasil, 88040-970. Fone: (048) 9123-3809
ferlin@inf.ufsc.br
Resumo:
A demanda por aplicações voltadas para a web está crescendo notoriamente. Parte deste crescimento é devido à flexibilidade para atualizações e à facilidade de disponibilizar informações. Entretanto, aplicações deste tipo necessitam de controles adicionais quando comparadas a aplicações cliente-servidor. Neste sentido, este projeto foi desenvolvido na área de aplicações distribuídas, fundamentada na plataforma J2EE. O propósito deste trabalho é suprir uma deficiência de aplicações inseridas neste contexto.
Em aplicativos que possuem vários usuários realizando tarefas simultâneas, é necessário que seja permitido o compartilhamento e a manipulação de informações comuns. Considerando que existe uma camada de persistência de dados (EJB), as alterações são armazenadas de modo assíncrono. Em função disso, algumas informações desatualizadas podem ser salvas, gerando uma inconsistência das informações. Sendo assim, este projeto procura contribuir com uma proposta de framework para o controle de concorrência, tanto para objetos de granulação fina quanto de granulação grossa.
Inicialmente, é feita uma contextualização do tema tratado. Após esta breve introdução, é apresentada uma revisão bibliográfica sobre as tecnologias envolvidas e sobre o problema principal. Em seguida, é apresentada uma proposta de tratamento do controle de concorrência utilizando objetos de valor. Ao final, são apresentados os resultados obtidos e as conclusões são discutidas.
Palavras-chaves: Controle de Concorrência, Aplicação Distribuída, Padrão de Projeto, Framework, J2EE.
Abstract:
The demand for applications directed toward web is growing notoriously. Part of this growth is due to flexibility for updates and to the easiness to dispose information.
However, applications of this type need additional controls when compared to the client-server applications. In this direction, this project was developed in the area of distributed applications, based on J2EE platform. The intention of this work is to supply a deficiency of applications in this context.
In applications with simultaneously tasks and some users carrying through, it is necessary that it is allowed to the sharing and the manipulation of common information. Considering that a layer of persistence of data exists (EJB), the alterations are stored in asynchronous way. In function of this, some outdated information can be stored, generating an inconsistency of the information. In this way, this project try to contribute with a proposal of framework for the concurrency control, to both fine and thick granularity objects.
Initially, an overview of the treat subject is made. After that, it is presented a proposal of treatment of the concurrency control having used value objects. In the end, the gotten results are presented and the conclusions are argued.
Key-words: Control of Concurrency, Distributed Applications, Design Patterns, Framework, J2EE.
Introdução
Ao longo dos anos, o processo de desenvolvimento de sistemas tem mudado constantemente, elevando significativamente a maturidade desta área.
A tecnologia de interconexão entre computadores evoluiu, permitindo o
compartilhamento de dados entre
terminais. Usuários precisavam ter acesso