II Simpsio de Informtica do CEFET-PI, InfoCEFET2004 infocefet2004

Persistir os Metadados dos Modelos de Objetos de Sistemas Distribudos e Adaptveis.

Warley R. de Almeida, Maurcio G.V. Ferreira Instituto Nacional de Pesquisas Espaciais (INPE) Av. dos Astronautas,1.758 - Jd. Granja - CEP 12227-010 So Jos dos Campos - SP - Brasil
warley@lac.inpe.br, mauricio@ccs.inpe.br

Resumo. Alguns sistemas de informao, por seus domnios estarem se alterando constantemente, requisitam uma arquitetura que permita configurar e adaptar esses sistemas em tempo de execuo. A estrutura e o comportamento dos objetos desses sistemas ao invs de codificados, ficam armazenados em um banco de dados, permitindo modificar o modelo de objetos atravs de alteraes nesse banco de dados, sem a necessidade de recodificar o sistema. Esse estilo arquitetural chamado de Adaptive Object Model (AOM). Em um sistema desenvolvido de acordo com a arquitetura AOM, o modelo de objetos do domnio fica armazenado em um banco de dados e o que deve-se codificar um interpretador para esse modelo de objetos. Uma das dificuldades apresentadas no desenvolvimento de um AOM a de armazenar e recuperar o modelo de objetos em um banco de dados. Este artigo tem como principal objetivo apresentar uma abordagem para a persistncia desses modelos de objetos.

1. Introduo
Alguns sistemas de informao, principalmente devido a caractersticas de seu domnio, podem ser desenvolvidos de uma forma que os tornem mais configurveis e adaptveis. Assim, esses sistemas podem se alterar de uma maneira mais eficiente para satisfazer requisitos do seu domnio de informao, que vierem a surgir (ou se modificar) aps o perodo de desenvolvimento desses sistemas [Yoder et al., 2001]. O Controle de satlites um exemplo de domnio de informao que requisita um sistema configurvel e adaptvel. Cada satlite tem caractersticas prprias, o que significa que um satlite sempre difere de outro, mesmo que s vezes seja uma diferena sutil. Atualmente, a cada lanamento de um novo satlite, deve-se desenvolver um aplicativo especfico para esse satlite e destinar uma mquina ou um conjunto mquinas especficas, para a execuo desse aplicativo, auxiliando no recebimento dos dados do satlite e no monitoramento de seu estado interno. Essas caractersticas, existentes em determinados domnios de informao, aliadas ao desejo crescente de se obter aplicaes que evoluam medida que seus domnios de informao evoluam, fez com que se pensasse em construir sistemas para o controle de satlites mais configurveis, flexveis e adaptveis, permitindo que o sistema consiga se

adaptar de uma maneira mais rpida, mais eficiente e a um custo menor, s novas necessidades do domnio de informao [Thom et al., 2004]. Uma maneira de se conseguir aplicaes mais configurveis armazenar certos aspectos do sistema, como as regras do negcio por exemplo, em um banco de dados, permitindo que se altere essas regras de negcio, sem a necessidade de se alterar o cdigo que as implementam. O modelo resultante, permite que o sistema possa se adaptar mais facilmente s novas necessidades do domnio, atravs de modificaes nos valores armazenados em um banco de dados, ao invs de alteraes no cdigo que implementa o sistema. Uma arquitetura de modelos de objetos adaptveis (Adaptive Object Model Architecture) um tipo particular de arquitetura reflexiva que abrange sistemas orientados a objeto que gerenciam elementos de algum tipo, e que podem ser estendidos para adicionar novos elementos (adaptvel) ou modificar elementos existentes (configurvel). Sistemas que tm esse tipo de arquitetura recebem tambm os nomes de Modelos de Objetos Ativos (Active Object Models) ou Modelos de Objetos Dinmicos (Dynamic Object Models) [Yoder et al., 2001]. Uma abordagem dos modelos de objetos adaptveis no desenvolvimento de sistemas pode amenizar algumas das dificuldades encontradas atualmente pelos desenvolvedores de software, principalmente em relao flexibilidade, evoluo e manuteno do sistema desenvolvido, permitindo uma reduo do custo total tanto no desenvolvimento quanto na manuteno destes sistemas [Ledeczi et al., 2000]. Por exemplo, a partir do momento em que se consiga implementar um sistema adaptvel para o controle de satlites com a capacidade de: (1) armazenar o modelo de objetos do sistema em um banco de dados, (2) permitir ao usurio monitorar qualquer um dos satlites em um determinado instante, (3) manter o modelo de objetos e (4) adaptar o modelo de objetos a um novo satlite. Esse sistema ajudar o programa espacial brasileiro na operao de satlites, pois ter mais flexibilidade para atender os requisitos de software das novas misses. Com a implementao desse sistema adaptvel, o esforo necessrio para se disponibilizar softwares para o controle de novos satlites tende a diminuir. Isso se deve ao fato de que tornar um sistema configurvel e adaptvel para o controle de satlites disponvel para um novo satlite, pode ser realizado em menos tempo e a um custo mais baixo do que desenvolver um novo sistema para o controle desse novo satlite, com todas as etapas de anlise, projeto, implementao e testes. Um sistema baseado nos AOMs fornece a seus usurios, informaes sobre o seu prprio modelo, permitindo assim, que seus usurios alterem o modelo do sistema, de acordo com suas necessidades, em tempo de execuo, atravs da modificao dessas informaes. Essa caracterstica, torna o sistema mais configurvel e adaptvel, em contrapartida, armazenar o modelo de um sistema baseado nesse tipo de arquitetura se torna uma dificuldade, pois um sistema desenvolvido baseado nos AOMs, armazena alm dos valores dos atributos de um objeto, armazena tambm as estruturas desses atributos e ainda armazena os prprios mtodos executados por esse objeto. Projetar a persistncia dos objetos de um sistema uma tarefa difcil e que consome tempo. A qualidade estrutural de um banco de dados, depende sobretudo da

metodologia de projeto usada e da tcnica de projeto utilizada nos passos desta metodologia. O projeto da persistncia dos objetos de um sistema baseado nos AOMs, acrescenta algumas dificuldades, principalmente devido ao fato desses sistemas armazenarem alm dos valores dos atributos dos objetos, armazenarem os prprios atributos e mtodos desses objetos. Essas dificuldades foram uma motivao para este trabalho, cujo objetivo principal estabelecer mtodos e definir um mapeamento para a persistncia dos modelos de objetos de sistemas desenvolvidos baseados nos AOMs. O resultado principal dar aos desenvolvedores desses sistemas, um maior entendimento da arquitetura e um embasamento que os ajudem a desenvolver sistemas mais eficientes e em um menor espao de tempo. Este trabalho tem como estudo de caso, para o mapeamento criado, a proposta de Thom de uma arquitetura de software distribuda configurvel e adaptvel aplicada a vrias misses de controle de satlite.

2. Modelo de Objetos Adaptveis

Um Modelo de Objetos Adaptvel (Adaptive Object Model - AOM) um sistema que apresenta informaes sobre suas classes, atributos e associaes como metadados (Um metadado um dado que descreve outro dado. Um metadado descreve a estrutura e o significado desse outro dado [Foote e Yoder, 1998]). O modelo do sistema baseado nas instncias das classes ao invs das classes. Usurios especialistas no domnio (um usurio com conhecimento sobre desenvolvimento de sistemas, ou apoiado por uma pessoa ou equipe de desenvolvimento de sistemas) modificam os metadados (modelo de objetos) para refletir mudanas no domnio. Essas mudanas modificam a estrutura (atributos de um objeto) e o comportamento (mtodos de um objeto) do sistema. Em outras palavras, o AOM armazena seu modelo de objetos em um banco de dados e em tempo de execuo o interpreta. Conseqentemente, o modelo de objetos adaptvel, pois quando voc o altera, o sistema se adapta imediatamente refletindo a mudana realizada [Yoder et al., 2001]. Dessa forma, os metadados so usados em modelos de objetos adaptveis para descrever o modelo em si (auto-representao, portanto uma arquitetura reflexiva). Desde que o sistema consiga interpretar os metadados para construir e manipular as descries das classes do modelo em tempo de execuo, simplifica-se o processo de adicionar novas classes ao modelo de objetos adaptvel. Simplifica-se tambm o processo de alterar as classes j existentes no modelo, e torn-las imediatamente disponveis para os usurios do sistema[Foote e Yoder, 1998]. O projeto de um sistema baseado na arquitetura AOM envolve trs atividades principais: (1) definir as entidades, regras e associaes do negcio; (2) desenvolver mecanismos para instanciao e manipulao destas entidades de acordo com suas regras e associaes; e (3) desenvolver ferramentas que permitam aos usurios especialistas no domnio modificarem a descrio dessas entidades, regras e associaes (representados como metadados) de acordo com as necessidades do domnio [Yoder et al., 2001].

Essas atividades podem ser realizadas atravs da aplicao de um ou mais padres de projeto, em conjunto com regras de engenharia de software para anlise, projeto e implementao de sistemas. Os padres de projeto Type Object [Johson e Woolf, 1998], Property [Gamma et al., 1995], Strategy [Gamma et al., 1995], o Rule Object [Arsanjani, 2000] e o Composite [Gamma et al., 1995], so freqentemente empregados na a construo de modelos de objetos adaptveis [Yoder et al., 2001]. Os aspectos primrios de implementao que precisam ser abordados no desenvolvimento de sistemas que utilizem modelos de objetos adaptveis so: (1) como armazenar o modelo de objetos no banco de dados, (2) como apresentar o modelo de objetos para o usurio, (3) como dar ao usurio especialista no domnio, condies de realizar alteraes no modelo de objetos [Yoder e Johnson, 2002]. Os AOMs representam seus objetos como metadados, isso significa que seus modelos de objetos podem ser armazenados, como metadados, em algum sistema de gerenciamento de dados, como os bancos de dados orientado a objetos, os bancos de dados relacionais ou como arquivos XML. Independente da maneira escolhida para o armazenamento dos metadados, o sistema deve ter a capacidade de ler os metadados e instanciar o modelo de objetos adaptvel com a configurao correta de suas instncias. Isso pode ser conseguido usando-se construtores (utilizando o padro de projeto Builder [Gamma et al., 1995], por exemplo) e interpretadores dos metadados para a criao e configurao das entidades, atributos, associaes e comportamentos a partir dos metadados.

Figura 1 Armazenando e recuperando Metadados FONTE: adaptado de Yoder et al. (2001).

O modelo de objetos adaptvel pode ficar armazenado tanto em um banco de dados, quanto em arquivos XML. Independentemente da forma como o modelo de objetos for armazenado, ele deve ser instanciado e ficar disponvel no repositrio de metadados para que possa ser utilizado pela aplicao. No caso de se utilizar um banco de dados para armazenar o modelo de objetos, o mecanismo de persistncia e o interpretador de metadados realizam essas tarefas; e no caso do modelo de objetos ficar armazenado em arquivos XML, o XML Parser e o interpretador de metadados realizam essas tarefas.

Pode-se ter uma idia de como isso poderia ser feito observando-se a figura 1. Se houver a necessidade de persistir os objetos do domnio da aplicao, eles podem ser armazenados no banco de dados atravs do mecanismo de persistncia. Alteraes realizadas no modelo de objetos refletem diretamente no comportamento do software, resultando em uma extenso completa em tempo de execuo. Por exemplo, alterar uma classe do sistema e armazenar a nova verso dessa classe faz com que todos os sistemas de software no ambiente, automaticamente utilizem a nova verso dessa classe. Assim, pode-se atualizar os metadados durante a execuo do sistema, e as mudanas resultantes no comportamento e estrutura do sistema tm efeito assim que o modelo de objetos interpretado [Poole, 2001]. Para armazenar o modelo de objetos, como metadados, em um banco de dados ou em arquivos XML, os desenvolvedores tero que definir como representar o modelo, bem como a semntica para descrever as regras do negcio. Deve-se estabelecer um mapeamento para a persistncia do modelo de objetos em um banco de dados, ou em arquivos XML. Alm disso, deve-se desenvolver editores de metadados e ferramentas para auxiliar os usurios especialistas no domnio nas tarefas de criao e manuteno do modelo de objetos[Yoder e Johnson, 2002]. Uma das principais razes para se desenvolver um sistema baseado nos modelos de objetos adaptvel permitir que usurios especialistas no domnio consigam adaptar a estrutura e o comportamento do sistema ao surgimento de novos requisitos no domnio, sem a necessidade de modificar o cdigo do sistema. Pode-se adaptar o sistema definindo novas entidades, associaes e regras ou alterando as j existentes. Para que os usurios especialistas no domnio possam realizar essas adaptaes, com uma menor probabilidade de introduo de erros no sistema e de uma maneira mais intuitiva, preciso oferecer a esses usurios, ferramentas adequadas para que eles possam realizar essas tarefas de uma maneira mais eficiente. Conseqentemente, essencial para um sistema adaptvel, possuir ferramentas para a definio de novas entidades, associaes e regras de forma interativa e ferramentas para apresentar o modelo de objetos a esses usurios, permitindo a modificao de entidades, associaes e regras existentes [Yoder et al., 2001]. Embora computao genrica e os modelos reflexivos j serem utilizados h algum tempo, os modelos de objetos adaptveis ainda so pouco conhecidos, e apresentam, portanto, um grande potencial para ser explorado, especialmente, quando aliados ao conceito de distribuio. Isso acontece porque, apesar de algumas aplicaes baseadas em modelos de objetos adaptveis terem sido desenvolvidas, nenhuma que se tem conhecimento explorou o conceito de distribuio do cdigo genrico. Exemplos de aplicaes j desenvolvidas usando-se os AOMs podem ser encontrados em [Yoder e Johnson, 2002] e [Yoder et al., 2001]. Alm disso, esses artigos no tratam diretamente a questo da persistncia dos modelos de objetos adaptveis criados por usurios especialistas do domnio, qual sistema de gerenciamento de dados utilizar e como representar o modelo de objetos como metadados nesses sistemas de gerenciamento de dados. Nesses trabalhos os modelos de objetos so tratados na memria, e no so persistidos para que suas configuraes no sejam perdidas. Este trabalho espera dar um passo na direo de facilitar a persistncia dos modelos de objetos adaptveis.

Para este trabalho foi desenvolvido trs prottipos de um sistema baseado nos AOMs, tendo como origem a proposta de Thom de uma arquitetura para sistemas aplicados ao controle de satlites. O primeiro prottipo persiste o modelo de objetos em um SGBDOO (Sistema Gerenciador de Banco de Dados Orientado a Objeto), o segundo em um SGBDR ( SGBD Relacional) e o terceiro armazena o modelo de objetos em arquivos XML, utilizando um banco de dados de XML nativo. No desenvolvimento desses prottipos foi implementado editores de metadados, para a criao de: entidades, propriedades, regras (mtodos) que podem ser associados s entidades criadas pelos usurios especialistas no domnio do sistema, alm de associaes entre as entidades. Os trs prottipos foram desenvolvidos na linguagem Java e seguindo a arquitetura J2EE. A linguagem Java pode ser considerada muito mais do que apenas uma linguagem de programao. Java consiste tambm de um ambiente de desenvolvimento e execuo de sistemas, com caractersticas marcantes como interoperabilidade, independncia de plataforma e orientao a objetos. A linguagem Java oferece uma srie de APIs (Application Program Interface) que so interfaces entre a aplicao e a plataforma que a processa [Java, 2004]. A linguagem Java apropriada para a implementao de sistemas baseados na arquitetura AOM por oferecer suporte a vrios tipos de dados utilizados no desenvolvimento desses sistemas (Exemplos: As classes Vector, HashTable e Class), fornece tambm APIs para a manipulao de arquivos XML (Exemplos: JMI, XMLDecoder, XMLEncoder), alm de APIs para conexes com diversos SGBDs relacionais e orientados a objetos (JDBC). A linguagem Java tambm possui a API Reflection, utilizada para o desenvolvimento de aplicaes dinmicas. A API Reflection fornece suporte para a execuo dinmica de mtodos [Java, 2004]. A reflexo habilita uma aplicao descobrir informaes sobre os campos, mtodos e construtores de objetos em tempo de execuo, e permite tambm refletir em um outro objeto, os campos, mtodos e construtores de um determinado objeto, tornando possvel a sua execuo. Voc pode necessitar da API de reflexo em Java, quando estiver trabalhando no desenvolvimento de ferramentas como debuggers, browsers de classes e construtores de GUIs (Graphical User Interface) [Java, 2004]. Atualmente, uma das arquiteturas utilizadas para o desenvolvimento de sistemas distribudos a arquitetura J2EE (Java 2 Enterprise Edition). A arquitetura J2EE permite aos desenvolvedores a criao de robustas aplicaes em trs camadas (tambm chamada de N camadas), atravs do fornecimento de servios da camada middleware para comunicar com uma variedade de clientes e servios back end (Notadamente os servidores de banco de dados). A arquitetura J2EE, fornecer o suporte necessrio para a distribuio dos objetos da aplicao, facilitando assim a implementao dos prottipos para a edio dos metadados que representam os modelos de objetos [Gabrick e Weiss, 2002].

3. Persistir os Modelos de Objetos Adaptveis

Uma das maneiras de facilitar a persistncia e a instanciao dos modelos de objetos adaptveis, a criao de um mapeamento. Um mapeamento pode ser entendido como um conjunto de regras a serem seguidas para se obter um resultado. Pode-se criar um mapeamento para a persistncia do modelos de objetos em banco de dados e um outro mapeamento para a persistncia do modelo de objetos em arquivos XML. Para

formalizar um mapeamento, pode-se utilizar mecanismos de extenso da UML, como por exemplo os esteretipos, na criao dos modelos de objetos. Assim cria-se esteretipos especficos para representar o modelo adaptvel, e adicionar as semnticas necessrias para a sua persistncia [Witthawaskul e Johnson, 2003].
Tabela 1 Esteretipos para o metamodelo. Esteretipo Entidade TipoEntidade Propriedade TipoPropriedade TipoRelacionamento Relacionamento Regra Descrio Representa as entidades do negcio. Representa os tipos de entidades do negcio. Representa as propriedades de uma entidade do negcio. Representa tipos de propriedades que uma entidade do negcio pode ter. Representa tipos de associaes que podem existir entre tipos de entidades do negcio. Representa associaes entre as entidades do negcio. Representa a classe que armazena as regras que podem ser associadas as entidades do negcio.

O desenvolvimento de um sistema baseado na arquitetura dos AOMs, implica na criao de um metamodelo, que ir definir as regras para a criao de modelos especficos para o domnio, em tempo de execuo. Para facilitar a formalizao do mapeamento da persistncia dos modelos de objetos adaptveis criados em tempo de execuo, definiu-se alguns esteretipos, que so inseridos nas classes do metamodelo, indicando qual o papel dessas classes nos padres de projeto utilizados. A tabela 1 mostra esses esteretipos e suas descries.

Uma vez criado o metamodelo do sistema, deve-se adicionar ao metamodelo os esteretipos corretamente. Um esteretipo em uma classe, indica qual padro de projeto foi utilizado para a criao dessa classe no metamodelo (alm da funo dessa classe no padro de projeto) e para cada classe, o desenvolvedor deve seguir o mapeamento criado para persistncia dessa classe, de acordo com o gerenciador de dados escolhido (Banco de dados orientados a objeto, banco de dados relacional ou arquivos XML) [Gabrick e Weiss, 2002]. 3.1 Persistir as propriedades Para persistir as propriedades do Modelo de Objetos, precisamos estabelecer um mapeamento para persistir as classes criadas pela aplicao dos padres de projeto Type Object e Property. Os tipos das propriedades, podem ser armazenados como strings, e durante a execuo do sistema, as propriedades podem ser criadas e validadas pela API Reflection da linguagem Java, especialmente pelo mtodo forName da classe Class. A persistncia das propriedades, compreende a persistncia das classes marcadas com os esteretipos Propriedade e TipoPropriedade. A classe TipoPropriedade estar associada a todas as classes marcadas com o esteretipo TipoEntidade do metamodelo, ento essas associaes devem ser tratadas no mapeamento. Uma das formas de se tratar as associaes entre a classe do metamodelo com o esteretipo TipoPropriedade e as classes do metamodelo marcadas com o esteretipo TipoEntidade criar na classe TipoPropriedade uma referncia para cada classe marcada com o esteretipo TipoEntidade no metamodelo. Dessa forma um tipo de propriedade sempre vai pertencer a apenas um tipo de entidade.

Outra maneira de realizar a persistncia das propriedades considerar que um tipo de propriedade pode ser utilizado por vrios tipos de entidade. Dessa forma, as classes marcadas com o esteretipo TipoEntidade devem possuir uma lista ou um vetor de referncias para instncias da classe marcada com o esteretipo TipoPropriedade do metamodelo. Essa segunda forma de persistir as propriedades parece mais condizente com os padres de projeto Type Object e Property, onde a classe TipoPropriedade, se apresenta como um banco de propriedades, onde as classes marcadas com o esteretipo TipoEntidade possuiriam um subconjunto das instncias dessas classes. Inclusive a propriedade Nome da classe TipoPropriedade nessa abordagem seria nico o que no ocorre na primeira abordagem. Persistir as propriedades em um banco de dados orientado a objeto, segundo a primeira abordagem citada anteriormente, consiste na criao duas classes: (1) TipoPropriedade com os atributos do tipo string: Nome e Tipo, alm de uma referncia para cada classe do metamodelo marcada com o esteretipo TipoEntidade. (2) Propriedade com o atributo Valor do tipo string, com uma referncia para a Classe TipoPropriedade e mais uma referncia para cada classe marcada com o esteretipo Entidade existente no metamodelo. 3.2 Persistir as Associaes As associaes podem ser consideradas como atributos de uma classe cujo valor seja outra classe. Alm disso, as associaes so bidirecionais, por exemplo se a classe A est associada com a classe B, ento a classe B tambm est associada com a classe A. Para permitir que o usurio especialista no domnio, crie e altere associaes entre as classes do metamodelo marcadas com o esteretipo TipoEntidade, sem a necessidade de alterar o cdigo do sistema, deve-se armazenar estas associaes no sistema de gerenciamento de dados utilizado. Persistir as associaes, compreende persistir as classes do metamodelo marcadas com os esteretipos Relacionamento e TipoRelacionamento, mostrados na tabela 1. Alm do fato das associaes serem bidirecionais, cada classe pertencente a associao, possuiu uma cardinalidade diferente. Por isso, uma associao, ser persistida como duas instncias, uma para cada sentido da associao. Persistir as associaes em um banco de dados orientado a objetos, consiste na criao de duas classes, a classe TipoRelacionamento e a classe Relacionamento. A classe TipoRelacionamento ir conter as informaes sobre os tipos de associaes (com outra classe) que uma determinada classe marcada com o esteretipo TipoEntidade pode participar. Ento a classe TipoRelacionamento deve armazenar informaes sobre a multiplicidade dessa classe na associao e tambm a referncia da outra classe na associao. A Classe Relacionamento deve conter a instncia da classe TipoRelacionamento a qual est associada, e ir associar instncias das classes marcadas com o esteretipo Entidade. A classe TipoRelacionamento, possuir os atributos Multiplicidade1 e Multiplicidade2, o atributo Nome, mais dois atributos (para armazenar referncias) para cada classe marcada com o esteretipo TipoEntidade existente no metamodelo. O nome desses

atributos podem ser o nome da classe marcada com o esteretipo TipoEntidade acrescido dos sufixos 1 ou 2. A classe Relacionamento possuir um atributo para armazenar uma referncia ao seu TipoRelacionamento mais dois atributos (para armazenar referncias) para cada classe marcada com o esteretipo Entidade existente no metamodelo. O nome desses atributos podem ser o nome da classe marcada com o esteretipo Entidade acrescido dos sufixos 1 ou 2. 3.3 Persistir as Regras O desenvolvimento de um sistema baseado nos AOMs ser fortemente ditado pelas caractersticas do domnio de informao ao qual esse sistema se destina. Obter um grande dinamismo nas regras do negcio do domnio, pode significar a criao de uma linguagem de alto nvel especfica para o domnio, o que implica criao de gramticas, parsers e compiladores. Isso seria de uma complexidade maior, saindo do escopo deste trabalho. Se o domnio de informao para o qual se desenvolve um sistema baseado nos AOMs no requisitar um amplo dinamismo nas regras do negcio, certamente no compensar o esforo despendido para obter tal caracterstica. Neste trabalho, apenas a utilizao do padro de projeto Strategy foi formalizada no mapeamento e implementada nos prottipos. A utilizao do padro de projeto Rule Object fica para um trabalho futuro. Os prottipos desenvolvidos, baseados no padro de projeto Strategy, implementaram para cada mtodo disponvel uma srie de variaes, e forneceu formas de o usurio especialista no domnio associar esses mtodos a alguma classe marcada com o esteretipo Entidade e escolher qual das variaes do mtodo essa classe ir utilizar. Persistir as regras do modelo, consiste em persistir a classe marcada com o esteretipo Regra e suas associaes com as classes marcadas com o esteretipo TipoEntidade e com o esteretipo TipoPropriedade. Criou-se a classe Regra, que armazena todas as regras do negcio disponveis, o nico atributo dessa classe o atributo Nome. O prottipo fornece condies ao usurio especialista no domnio de associar essas regras s instncias criadas das classes com o esteretipo TipoEntidade. A associao entre a classe Regra e as classes com o esteretipo TipoEntidade no metamodelo M:N. Com o intuito de aumentar o dinamismo na execuo dos mtodos, criou-se a possibilidade de associar uma determinada regra, um conjunto de propriedades. As Regras podem utilizar os valores dessas propriedades tanto para indicar qual variao da regra deve ser utilizada, quanto para sua prpria execuo. Dessa forma, o usurio especialista no domnio pode por exemplo, associar uma regra uma classe marcada com o esteretipo TipoEntidade. Em seguida, ele pode determinar que um ou mais dos tipos de propriedades definidos para essa classe seja utilizado por essa regra durante sua execuo. Durante a execuo de uma regra, o sistema deve verificar se existe alguma propriedade associada a essa regra. Se o usurio especialista no domnio associou alguma propriedade a essa regra, ento o sistema deve buscar o seu valor na classe Propriedade, e fornec-lo a regra antes de sua execuo.

Na implementao das regras no prottipo foi utilizada a API Reflection da linguagem Java, citada na seo 2 deste trabalho. Esta API fornece condies de localizar classes e executar mtodos, cujos nomes s se tornem conhecidos em tempo de execuo. Exatamente o que ocorre em sistemas desenvolvidos baseados nos AOMs. Nos prottipos foi implementado em Java uma classe chamada Regras.java, que cuida da execuo dos mtodos, de acordo com o nome do mtodo. Nessa classe foi implementada diversas variaes para um mesmo mtodo. O nome do mtodo a ser executado fica persistido, em um dos sistemas de gerenciamento de dados escolhido, na classe Regra. Durante a execuo de um mtodo, os prottipos verificam se existem propriedades associadas para a execuo deste mtodo. Caso existam, os prottipos buscam os valores destas propriedades associadas e os fornecem ao mtodo que ser executado. A figura 2 ilustra o mtodo mais importante da classe Regras.java, chamado executarRegra. Esse mtodo possui trs parmetros: (1) o nome da regra, (2) os possveis parmetros dessa regra e (3) os tipos dos possveis parmetros dessa regra. Esses possveis parmetros so as propriedades da classe com o esteretipo TipoEntidade que foram associadas pelo usurio especialista no domnio classe Regra. A primeira linha recupera um objeto Class para a classe Regras.java, onde esto codificados todos os mtodos. A segunda linha recupera o mtodo desejado, a terceira linha cria uma instncia da classe Regras.java, necessria como parmetro na quarta linha. Finalmente a quarta linha executa o mtodo.
public static void executarRegra(String nomeregra, Class partType[], Object arglist[]){ try { Class cls = Class.forName("User.Regras"); Method meth = cls.getMethod(nomeregra, partType); Regras regra = new Regras(); Object retobj = meth.invoke(regra, arglist); } catch (Throwable e ) { System.err.println(e); } }

Figura 2 Listagem do mtodo executarRegra.

4. O prottipo
O prottipo desenvolvido, exemplifica a capacidade que um sistema desenvolvido baseado nos AOMs, fornece aos seus usurios de configurar e adaptar o seu sistema a mudanas no domnio de informao. Foi desenvolvido editores de metadados, onde o usurio especialista do domnio pode criar novas classes, criar atributos para essas classes, criar associaes entre as classes e atribuir regras a essas novas classes. Como todas essas informaes so persistidas como metadados, na sua inicializao, o prottipo busca essas informaes e instancia o modelo de objetos com a configurao definida pelo usurio especialista no domnio. A Figura 3 ilustra a mesma tela do prottipo mostrando trs classes diferentes criadas pelo usurio especialista no domnio em tempo de execuo. Embora todas as trs sejam instncias de uma mesma classe elas possuem atributos diferentes. A figura 3 ilustra tambm um editor de atributos, onde o usurio especialista no domnio pode criar, excluir e modificar atributos para uma classe. O prottipo tambm implementou editores de associaes e editores de regras que no so mostrados neste artigo. Maiores detalhes sobre o domnio de informao do prottipo podem ser encontrados em Thom.

Figura 3 Telas do prottipo desenvolvido.

5. Concluses
O principal objetivo deste trabalho estabelecer um mapeamento para a persistncia dos modelos de objetos de sistemas distribudos, configurveis e adaptveis, desenvolvidos baseados na arquitetura dos AOMs. Este trabalho, tem como origem, motivao e estudo de caso a arquitetura proposta em Thom para o controle de satlites. Este trabalho utiliza trs sistemas de gerenciamento de dados, os SGBDs Relacionais, os SGBDs Orientados a Objetos e arquivos XML. Para isso, criou-se um mapeamento para a persistncia dos modelos de objetos do sistema em cada um desses sistemas de gerenciamento de dados. O prottipo implementou editores para os metadados que representam os modelos de objetos, para facilitar a sua manuteno pelos usurios especialistas no domnio. Independente da maneira com qual os metadados que descrevem o modelo de objetos, fiquem armazenados, o sistema deve ter a capacidade de ler esses metadados e instanciar o modelo de objetos adaptvel correspondente. Alm de manter a configurao correta da estrutura e comportamento desse modelo. Ao trmino deste trabalho, espera-se colaborar para facilitar o desenvolvimento de sistemas distribudos, configurveis e adaptveis para uso geral, mas utilizando como estudo de caso e focando principalmente em sistemas para o controle de satlites. Esses sistemas so um importante passo na direo da economicidade e reusabilidade, pois

futuras misses de satlites podero aproveitar todo o investimento de hardware e software j feito em misses anteriores. A contribuio principal fornecer um embasamento para a persistncia dos modelos de objetos desses sistemas. Diminuindo assim, o tempo e o esforo necessrio para atender os requisitos de software das novas misses espaciais e contribuindo para o sucesso do programa espacial brasileiro.

6. Referncias
[Arsanjani, 2000] ARSANJANI, A. Rule Object: A Pattern Language for Adaptive and Scalable Business Rule Construction. In: Conference on Patterns Languages of Programs (PloP2000). Proceedings. Washington University Departament of Computer Science. October of 2000. [Foote e Yoder, 1998] FOOTE, B.;YODER, J.W. Metadata and Active Object Models. In: Technical Report#WUCS-97-34 (PLoP98). Dept. of Computer Cience, Washington University, 1998. [Gabrick e Weiss, 2002] GABRICK, A. K.; WEISS, D. B. J2EE and XML development. Manning publications company, April 2002. [Gamma et al., 1995] GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [Java, 2004] JAVA TUTORIAL. Reflection. Disponvel em: <http://java.sun.com/docs/books/tutorial/index.html>. ltima atualizao 11/03/2004. Acessado em 10/09/2004. [Johson e Woolf, 1998] JOHNSON, R.; WOOLF, B. Type Object. In: Pattern Languages of Program Design 3. Addison-Wesley, 1998. Page 47-66. [Ledeczi et al., 2000] LEDECZI, A.; KARSAI, G.; BAPTY, T. Synthesis of selfadaptive software. IEEE Aerospace Conference Proceedings. USA. V 4, pg. 501507. 2000. [Poole, 2001] POOLE, J. D. Model-Driven Architecture: Vision, Standards And Emerging Technologies. In: ECOOP2001 Workshop on Metamodeling and Adaptive Object Models. April 2001. [Thom et al., 2004] THOM, A. C.; FERREIRA, M.G.V.; CUNHA, J.B.S. Uma Arquitetura de Software Reflexiva Baseada em Modelos de Objetos Adaptveis. In: Object-Oriented Programming, System, Languages, and Applications (OOPSLA04), Vancouver, Canad, Outubro, 2004. [Witthawaskul e Johnson, 2003] WITTHAWASKUL W.; JOHNSON, R. Specifying Persistence in Platform Independent Models. In: Workshop in Software Model Engineering at The Sixth International Conference on the Unified Modeling Language, UML 2003, San Francisco, California, USA October 20-24, 2003. [Yoder e Johnson, 2002] YODER, J.W.; JOHNSON R. The Adaptive Object-Model Architectural Style. In: IEEE/IFIP Conference on Software Architecture 2002 (WICSA302) Canada. August of 2002. [Yoder et al., 2001] YODER, J.W.; BALAGUER F.; JOHNSON R. Architecture and design of Adaptive Object Models. ACM Sigplan Notices. Vol 36, Fasc. 12, pg. 5060, December 2001.