OWLtoAspectJ: Uma Ferramenta para Transformação de Regras Conceituais de Domínio em Aspectos

Transcrição

1 OWLtoAspectJ: Uma Ferramenta para Transformação de Regras Conceituais de Domínio em Aspectos Jaguaraci Batista Silva Departamento de Computação Universidade Federal da Bahia (UFBA) Av Adhemar de Barros s/n, Ondina Salvador BA Brazil Abstract. The axioms are rules or affirmations of the truth on concepts and its creation is essential to carry through inferences on ontology. The axioms when generated for a programming language provoke one high coupling degree, making impracticable its reuse of the rules in other models. This work aims at to separate the axioms of the platform specific model. A tool was constructed to transform the axioms from OWL format to aspects. Thus, the business rules can be reused in other MDA specific models within the Java platform automatically. Resumo. Os axiomas são regras ou afirmações da verdade sobre conceitos e a sua criação é imprescindível para realizar inferências em uma ontologia. Os axiomas quando gerados para uma linguagem de programação, provocam um alto grau de acoplamento, inviabilizando o reuso das regras em outros modelos. Este trabalho visa separar os axiomas do modelo específico de plataforma. Foi construída uma ferramenta para transformar os axiomas no formato OWL em aspectos. Assim, as regras de negócio podem ser reutilizadas em outros modelos MDA específicos da plataforma Java automaticamente. 1. Introdução As regras de negócios são semânticas, peculiares e, entre tantos atributos, precisam aderir de forma coesa a um conceito. Abstraindo um pouco questões de paradigmas, pois são apenas metodologias, as regras dão o sentido a existência de um conceito. A modelagem de um domínio de aplicação com uma aproximação á ontologia, permite utilizar-se de mecanismos para abstrair paradigmas (e.g. POO, POA, POM). Mesmo a UML (Unified Modeling Language) [Booch et al, 1999] ou qualquer linguagem de representação de paradigma, não oferece condições de prova formal de que um objeto ou aspecto é a realização de um conceito, pois seria necessário verificar a semântica do modelo e nenhuma dessas linguagens de representação fornece tal grau de formalidade [Freitas, 2003]. Mesmo com a utilização de aspectos, que priva pela separação de interesses transversais, não é possível garantir se semântica das regras conceituais adere de forma coesa a sua implementação. Criar sistemas críticos que controlam robôs, fornos industriais ou aviões são bastante complexos. São nesses tipos de aplicações, que se

2 pode obter grandes vantagens na utilização da verificação formal de uma ontologia de domínio. A verificação formal pode ser feita de forma fácil e rápida, devido ao uso combinado de um editor de ontologias com interface gráfica (e.g. Protêgê, OntoEdit) e um reasoner (e.g. Racer) [Haarslev, 2004] [Silva et al, 2006], facilitando a adequação do uso dessas técnicas na indústria. Muitos trabalhos vistos na literatura utilizam as aproximações entre MDA (Model-Driven Architecture) e ontologias [Djuric et al, 2004] ou MDA e AOP (Aspect- Oriented Programming) [Dhondt et al, 2008]. Em [Djuric et al, 2004] é possível observar as referências de forma cronológica sobre os seus trabalhos. Em resumo, os seus projetos preocupam-se em utilizar as definições de metamodelos para a criação de um perfil UML para ontologia. Assim, uma ontologia poderá ter classes, atributos e propriedades, com o objetivo de facilitar a sua transformação ou utilização junto aos outros perfils e\ou modelos UML. Já [Dhondt et al, 2008] são pioneiros quando se trata da utilização de aspectos e representação de conhecimento. Em um dos seus trabalhos, Dhondt [Dhondt et al, 2006] utiliza a programação orientada a aspectos para implementar as regras de negócio em forma de aspectos a partir de modelos conceituais de alto nível. Esse trabalho utiliza a construção de aspectos a partir de modelos conceituais formalizados utilizando lógica de descrições [Horrocks et al, 1999]. Foi construída uma ferramenta para gerar automaticamente modelos específicos de plataforma utilizando as restrições construídas na linguagem OWL (Ontology Web Language) [W3C, 2008] transformando-as em aspectos [Chavez, 2004]. Para apresentação do trabalho, o mesmo foi divido em 5 seções. A primeira é a introdução deste trabalho. A segunda fornece uma breve apresentação sobre os níveis de abstrações utilizando modelos MDA. A terceira apresenta uma visão geral sobre a linguagem OWL e de que forma são representadas as regras de negócio nessa linguagem. Na quarta seção são mostrados os elementos que compões a linguagem de programação orientada a aspectos. A forma de construção da ferramenta e sua utilização estão descritas na seção 5. E por fim, as conclusões e referências utilizadas estão na parte final deste trabalho. 2. Modelos e níveis de abstrações em MDA A MDA, arquitetura orientada a modelos, propõe a criação de modelos em diferentes níveis de abstração, separando os interesses de implementação de uma arquitetura específica do modelo conceitual de uma aplicação. A MDA é baseada na arquitetura MOF, que conceitua quatro níveis de modelos: M3, M2, M1, e MO. A figura 1 mostra um exemplo do uso de metaníveis em MDA, uma Conta (MO) é um exemplo da classe conta (M1) que implementou a classe Classe (M2), por sua vez, sendo uma instância da classe Classe em MOF (M3). Cada metamodelo proposto deve ter, no mínimo, uma implementação, de forma que sua realização pode ter um ou mais modelos. Um modelo de diagramas UML, por exemplo, é capturado por um metamodelo UML, que descreve como podem ser estruturados modelos UML, os elementos que eles contêm, bem como as propriedades de uma plataforma particular. Os modelos poderão relacionar-se usando mapeamentos, os quais podem ser realizados automática ou manualmente.

3 Figura 1. Exemplo de níveis de modelos MDA (Mellor, 2003, P. 48) Em um mapeamento existem regras que são chamadas regras de mapeamento, as quais definem basicamente a aceitação de um ou mais modelos - que são as origens - e um modelo de destino a ser gerado. Essas regras são escritas em nível de metamodelos e aplicáveis a todos os modelos de origem que obedecem às especificações de seu metamodelo. Para que seja possível a utilização de mapeamentos em modelos UML é necessário importar o modelo em uma ferramenta MDA, através do arquivo XMI (XML Metadata Interchange), que é um artefato gerado a partir das linguagens XML (Extensible Markup Language), UML e MOF (Meta Object Facility) que utiliza DTD (Definição de Tipo de Documento), nos quais são descritas regras de sintaxe dos elementos usados no modelo MDA. A declaração de um DTD pode ser feita interna ou externamente ao documento, em que são definidas e ordenadas através de tags. O XMI combina os benefícios da XML para definição, validação e compartilhamento de formatos de documentos com os benefícios da linguagem de modelagem visual UML para especificação, visualização, construção e documentação. Onde o seu principal objetivo é facilitar o intercâmbio de metadados, entre ferramentas de modelagem baseadas na linguagem UML e MOF especificadas pela OMG. 3. Uma Visão geral sobre a OWL As pesquisas no campo da representação do conhecimento englobam definições formais utilizando um raciocínio automático para a validação de um conceito sobre um determinado domínio e, segundo [Guizzard, 2002], é melhor realizada quando esta é descrita em uma linguagem fundamentada em um modelo matemático. Nesta linguagem, em contraste com a linguagem natural, existem símbolos não ambíguos e formulações exatas, portanto, a clareza e a correção de uma dedução podem ser testadas. Assim como XMI, a linguagem OWL (Ontology Web Language) é uma linguagem XML. É possível expressar a estrutura dos conceitos, relacionamentos e descrever características especiais sobre estes, através de axiomas lógicos para formar uma ontologia. As Lógicas de Descrições ou DLs (Description Logics) são uma evolução dos formalismos de representação do conhecimento baseados em objetos (redes semânticas e frames), ao qual corresponde um subconjunto estruturado da lógica de primeira ordem [Santos et al, 2005]. A OWL, baseada na lógica de descrição e estruturada pela XML, é formada por três sub-linguagens diferentes [Santos et al, 2005]: OWL Lite, OWL-DL e OWL Full; e cada uma corresponde a uma lógica de descrição diferente.

4 Uma interpretação de um conceito A, representada por A 1, pode ser definida como o conjunto de valores que torna este conceito verdadeiro. O conceito mais geral do qual todos os outros conceitos são subconceitos é representado por D 1 e é equivalente ao Verdadeiro (True). O Verdadeiro e o Falso são representados, respectivamente, pelos símbolos T e. Supondo que A e B sejam nomes de conceitos, P um nome de papel (propriedade) pode-se ter os seguintes construtores básicos (Santos et al, 2005): Conjunção (A Π B). Representa a interseção entre as interpretações dos conceitos que fazem parte da conjunção. Disjunção A U B (U). Representa a união entre as interpretações dos conceitos que fazem parte da disjunção. Quantificação Universal P.A. Determina que, através da propriedade P, todos os indivíduos do conceito declarado devem se relacionar com indivíduos da classe determinada pela quantificação universal (conceito A). Desta forma, a propriedade P não pode ser usada para relacionar elementos de outras classes. Quantificação Existencial P.A (E). Determina que, através da propriedade P, deve existir pelo menos um indivíduo do conceito declarado que se relaciona com indivíduos da classe determinada pela quantificação existencial (conceito A). Os indivíduos do conceito declarado podem se relacionar com outras classes através desta mesma propriedade P. Negação A (C). Representa a interpretação de D 1 menos a de A 1. Restrição de Número =< n.p e => n.p (N). Determinam o número máximo (=<) ou mínimo (=>) de relacionamentos que devem ser realizados através da propriedade P. Todos os elementos criados na ontologia podem ser gerados para a linguagem OWL (Ontology Web Language) através de um editor de ontologia. A tabela 1 apresenta um trecho do arquivo OWL gerado pelo editor de ontologia protêgê [Protêgê, 2008]. A geração do arquivo OWL é necessária, pois será utilizado um motor de inferências para verificar a satisfação dos conceitos criados na ontologia de domínio. Razão a qual será possível afirmar que o domínio criado está correto. Tabela 1. Exemplo de uma Regra de Negócio Representada no Arquivo OWL. <owl:restriction> <owl:somevaluesfrom> <owl:class rdf:id="forno"/> </owl:somevaluesfrom> <owl:onproperty> <owl:objectproperty rdf:id="#e_carregado_por_operador "/> <owl:restriction> <owl:objectproperty rdf:about="# E_carregado_por_Operador "> <rdfs:domain rdf:resource="#forno"/> <rdfs:range rdf:resource="#operador"/> <owl:inverseof rdf:resource="#carrega_forno"/> </owl:objectproperty> As regras de negócio são representadas pelas tags owl:restriction no formato XML (Extend Markup Language). Todas as restrições são formadas pelo conjunto de informações sobre os conceitos, o predicado e tipo de restrição. No trecho apresentado na Tabela 1, os conceitos são descritos pelas tags rdfs:domain rdf:resource e rfds:range rdf:resource, o predicado por owl:objectproperty rdf:id e o tipo de

5 restrição owl:maxcardinality. Significa que apenas o operador pode realizar o abastecimento de insumos, conforme uma das regras de negócio da aplicação de abastecimento de fornos utilizada no estudo de caso. 4. A programação orientada a aspectos A POA ou programação orientada a aspectos (Aspect-Oriented Programing) [AOSD, 2005] é a tecnologia mais recente utilizada para separar requisitos não-funcionais do domínio da aplicação. Chavez [Chavez, 2004] cita que o paradigma de orientação a aspectos deve suportar: componentes, pontos de combinação, crosscutting, processo de combinação, quantificação, transparência e os próprios aspectos, além da separação do que é aspectos e componentes através de uma dicotomia aspecto-base. Para conceituar o paradigma, Chavez cria um framework conceitual formado por quatro modelos: o modelo de componentes, o modelo de pontos de combinação, o modelo de processo de combinação e o modelo principal ou core. O modelo de componentes (component model), é responsável pela decomposição dos problemas que irá resolver, existindo ainda para cada tipo de problema seus princípios, mecanismos de composição e um componente conceitual. O modelo de pontos de combinação (join point model), irá descrever os tipos de combinação para cada interesse e as restrições de seu uso. Um ponto de combinação pode ser: estático, quando é um local na estrutura de um componente, dinâmico, quando se refere a um comportamento, e ainda possuir uma sombra estática, que é um ponto de combinação dinâmico em uma região de um componente. No paradigma de orientação a objetos, são exemplos de pontos de combinação estáticos as classes, os métodos e atributos. As execuções dos métodos, instanciações de classes, chamadas de métodos construtores e referências a campos em tempo de execução são exemplos de pontos de combinação dinâmicos. O modelo principal (core model) é usado para descrever os aspectos, usando os mecanismos de aspecto e crosscutting. Os aspectos são as propriedades do sistema que afetam os componentes, conceituados por [Chavez, 2004] como:...uma entidade nomeável de primeira classe que oferece uma representação modular para um concern transversal. As características transversais utilizam os pontos de combinação para tratar as melhorias, sejam estruturais (static join point) ou comportamentais (dynamic join point). O crosscutting é um fenômeno que ocorre quando duas propriedades programadas e coordenadas compõemse de forma diferente, estabelecendo uma relação de um aspecto com um ou mais componentes. E por fim, o modelo de processo de combinação (weaving model), compõe os aspectos e componentes relacionados, usando o fenômeno de crosscutting em pontos de combinação específicos. Os princípios mais importantes da programação orientada a aspectos são: a separação de concerns, a modularidade, a dicotomia-base, a transparência e a quantificação. A separação de concerns é a distinção entre um aspecto e um componente. A modularidade é a decomposição de concerns em aspectos. A dicotomiabase trata justamente dessa separação, quando conseguimos fazer tais distinções, temos os sistemas decompostos em componentes e aspectos, onde: aspectos modularizam concerns transversais e os componentes concerns funcionais, os aspectos devem ser

6 separados dos componentes e de outros aspectos [Chavez, 2004]. A transparência faz o uso do princípio da inversão de dependência, onde os componentes e programadores não precisam saber da existência dos aspectos. A quantificação proporciona a capacidade, através de uma linguagem orientada a aspectos, de escrever condições para que os aspectos possam afetar vários componentes. Uma linguagem orientada a aspectos ou AOL (Aspect-oriented Language), deve prover a capacidade de suporte aos modelos citados e suas características, bem como, todos os princípios do paradigma. Uma AOL deve ser estruturada independente de framework e expressar testes padrões de integração entre componentes e aspectos em uma aplicação Um exemplo de linguagem orientada a aspectos é a AspectJ [Laddad, 2003]. 5. Geração automática do Modelo PSM para as regras de negócio A Figura 2 apresenta o processo de transformação. O modelo PIM (Platform Independent Model) criado a partir de uma ontologia, deve ser uma instância do metamodelo MOF. Este modelo, representado pelo arquivo OWL, também poderá utilizar algum perfil da UML como o ODM (Ontology Definition Metamodel) (Djuric et al, 2004) para a geração de outros modelos a partir de uma ontologia ou a criação de um perfil próprio. A sua implementação é uma demonstração de uma das principais vantagens da criação de modelos usando a MDA, que é a geração e o intercâmbio de modelos usando a linguagem XML. A transformação do PIM para o PSM (Platform Specific Model) contém a definição do conjunto de classes, atributos e relacionamentos que serão gerados para uma plataforma específica. Figura 2. Transformação do PIM em PSM e Implementação das Regras usando AOP. Para a transformação das regras de negócio representadas na linguagem OWL (Tabela 1) em aspectos (Tabela 2), foi construída uma ferramenta utilizando a linguagem Java [Sun, 2008] e a API Jena [Jena, 2008]. A API Jena permite que o arquivo OWL seja lido com facilidade. A Figura 3 mostra a ferramenta construída. Ela permite a transformação do modelo conceitual formalizado usando lógica de descrições [Silva et al, 2006] para artefatos em aspectos utilizando a linguagem AspectJ [AspectJ,

7 2008]. Um trecho de uma regra gerada para AspectJ pode ser vista na tabela 2. Cada regra foi transformada em um Aspect, significando que cada uma unidade de aspecto gerada representa um modelo PSM derivado do metamodelo UML para AspectJ [Han et al, 2005]. É realizada a leitura de cada restrição no formato OWL, de acordo com os tipos suportados pela linguagem axiomática PAL [Noy et al, 2000], durante a transformação do modelo PIM para o PSM em AspectJ. Após, são associados os elementos de cada linguagem usando a API Jena para capturar os dados dos elementos em OWL utilizados para a criação dos aspectos. A tabela 1 (Seção 3) exibe os elementos a serem lidos pela ferramenta para geração do modelo PSM. Foi criada uma padronização com a finalidade de incorporar os elementos da OWL usando a transformação automática, sem a necessidade de intervenção humana. Figura 3. Ferramenta Construída para Transformar as Restrições de OWL para AspectJ. Durante a criação de um aspecto com a capacidade de implementar as regras de negócio da aplicação, foram criados: advices e pointcuts (Seção 4) de acordo com as relações entre os conceitos, inclusive para os relacionados inversamente. No nome do poitncut foi indicado o conceitos ou classe ao qual o aspecto deve agir representado em OWL pela tag rdfs:domain rdf:resource, seguido da informação do conceito relacionado obtido com a informação do elemento rdfs:range rdf:resource. Como o modelo PSM para os aspectos deve ser adaptado automaticamente, o método a ser interceptado, deverá ter o nome da classe relacionada ao conceito em sua assinatura (e.g. Operador.carregaForno(), Receita.insereInsumo()). Assim, poderá ser utilizado um designador (e.g. execution, call, Get, Set) para o pointcut com o nome da classe associada, para não necessitar a escrita da assinatura completa do método. O elemento owl:objectproperty rdf:id repesentará o nome da regra de negócio, portanto foi utilizado para nomear o aspecto, facilitando a identificação de artefatos. As regras que fazem referência a restrições por tipos de objetos (e.g. owl:allvaluesfrom, owl:hasvaluesfrom e owl:somevaluesfrom) farão o uso do operador instaceof na composição da estrutura condicional, enquanto as de cardinalidade serão utilizados os operadores padrões da linguagem Java (e.g. >=, <= e = = ) [Sun, 2008].

8 A Tabela 2, mostra a regra de negócio E_carregado_por_Operador transformada para a linguagem AspectJ. Segundo o documento de especificação dos requisitos, um administrador não pode realizar o abastecimento em fornos. Uma vez que existe a regra de negócio, esta deve ser seguida, independente de um erro de programação, pois nesse caso, não são admitidos erros dessa natureza em sistemas críticos. Com a utilização da programação orientada a aspectos, as regras estão fortemente ligadas aos conceitos, mesmo sendo desacopladas dos modelos. Neste exemplo exibido na Figura 4, foi detectado antes da realização do abastecimento do forno que um administrador tentou burlar a regra de negócio. Mesmo sendo forçado o erro na implementação de um método que não deveria existir no nível de uma linguagem de programação (Tabela 3). package businessrules; Tabela 2. Regra de Negócio Transformada em AspectJ. import abastecimento.operador; public aspect FornoE_carregado_por_Operador { public pointcut Operador() : call(* *.*Forno(..)) && (!(call(* *.getforno(*)) call(* *.setforno(*)))); before():operador() { Object obj = thisjoinpoint.gettarget(); } if (!(obj instanceof Operador)){ System.out.print("\n Exception Rule: FornoE_carregado_por_Operador"); } } A fim de possibilitar a verificação da satisfatibilidade das regras de negócio, foram implementadas as classes Java, utilizando dois modelos PSM. O primeiro para a criação dos conceitos, atributos e suas relações e o segundo gerado automaticamente através ferramenta OWLtoAspectJ representando as regras de negócio. Após a realização da transformação do modelo PIM no formato XMI para o PSM na plataforma Java. Foram implementados comportamentos manualmente, sem as regras de negócio. Após, foram criadas as instâncias para realizar as ações descritas nos caso de usos do sistema: o cadastramento de insumos, silos, receitas de produtos contendo os insumos necessários para sua fabricação, os produtos a serem fabricados nos fornos, as fábricas e seus respectivos fornos e os usuários do sistema. Na Tabela 3, é possível vislumbrar as ações de cadastro, através do trecho de código exibido. Nesta tabela também é possível ver a simulação da tentativa de abastecimento de um forno por um administrador do sistema.

9 Tabela 3. Trecho de Código Utilizado para Verificar as Regras. Fabrica fabrica = new Fabrica(); fabrica.cadastrarforno(forno1); System.out.print(fabrica); fabrica.cadastrarforno(forno2); System.out.print(fabrica); Operador operador = new Operador(); operador.setmatricula(0); operador.setnome("nome"); operador.setsenha("senha"); operador.carregarforno(forno1, insumo); System.out.print(operador); Administrador administrador = new Administrador(); administrador.setmatricula(0); administrador.setnome("nome"); administrador.setsenha("senha"); administrador.carregarforno(forno1, insumo); System.out.print(administrador); Neste trecho foram criadas as instâncias das classes Forno, Fabrica, Operador e Administrador. A Figura 4 representa o momento da verificação da regra de negócio (Tabela 2), ao executar a ação de abastecer um forno com um insumo, é exibida a mensagem de que houve uma violação de regra de negócio e qual foi a regra violada. A utilização do modelo PSM para regras de negócio após a geração feita pela ferramenta OWLtoAspectJ construída neste trabalho reduziu o tempo de desenvolvimento da aplicação. Além disso, as regras geradas usando a linguagem AspectJ [AspectJ, 2008] podem ser reutilizadas em outras plataformas (e.g. CORBA e RMI). Um exemplo pode ser implementando utilizando uma arquitetura cliente & servidor, onde as regras de negócio podem estar em qualquer um desses componentes. Um exemplo de implementação que utiliza o RMI pode ser visto no trabalho de Soares [Soares et al, 2002].

10 Figura 4. Validação da Regras de Negócio em Tempo de Execução. Conclusão A criação automática dos aspectos possibilita, além de separar as regras dos modelos específicos de plataforma, uma diminuição no tempo de desenvolvimento. Uma vez que não é necessário escrever o código para as regras de negócio nos métodos da classe, pois os aspectos irão encontrá-los dinamicamente. Ao avaliar a oportunidade de automatizar a geração de modelos MDA separados das regras de negócio, criou-se uma ferramenta e um modelo de processo para este propósito. A criação automática das regras de negócios em aspectos possibilitou, além de separar as regras dos modelos específicos de plataforma, uma diminuição no tempo de desenvolvimento e sua reutilização em outros produtos de uma linha de produtos de software. Alguns trabalhos utilizam a relação MDA e Ontologia ou MDA e AOP, porém neste trabalho foi possível utilizar todas as tecnologias emergentes que tratam a separação de interesses, sejam de plataformas, regras de negócio ou requisitos não-funcionais de forma inédita. Espera-se em um trabalho futuro, avaliar a concorrência entre aspectos, sob o ponto de vista de sobreposição das regras de negócio e melhorar a ferramenta OWLtoAspectJ para que se possa padronizar as mensagens de violação de regras sem que se haja a necessidade de intervenção ao modelo PSM formalizado. Referências AOSD Europe (2005). Survey of Aspect-oriented Middleware. Acessado em Abril de AspectJ. AspectJ Java Aspect-Oriented Programming. Acessado em Abril de Booch, G., Jacobson, I., Rumbaugh, J. (1999). Unified Modeling Language User s Guide. Addison-Wesley. Chavez, C.V.G. (2004). Um enfoque baseado em modelos para o design orientado a aspectos. Tese de doutorado, Pontifícia Universidade Católica do Rio de Janeiro, p Dhondt, M., Streten, R. V. D. Programme Inria Equipes Associées. Acessado em: abril de Dhondt, M. Cibrán, M. A.. (2006) A Slice of MDE with AOP: Transforming High- Level Business Rules to Aspects. ACM/IEEE 9th International Conference on Model Driven Engineering Languages and Systems (Models 2006), Genova, Itália. Djuric, D. Gasevic, D. Devedzic, V MDA-Based Ontology Infrastructure. Internacional Conference on Web Engineering, Munich, Alemanha. Freitas, F Ontologias e Websemântica. IV ENIA Encontro Nacional de Inteligência Artificial, Campinas, Minicurso. In Anais do XXIII Congresso da Sociedade Brasileira de Computação, 52 p.

11 Guizzard, Giancarlo.. (2000) Uma abordagem metodológica de desenvolvimento para e com reuso, baseada em ontologias formais de domínio. Programa de Mestrado em Informática Universidade Federal do Espírito Santo, Vitória, Julho. Haarslev, V., Muller, R.. (2004) Racer s User Guide and Reference Manual. Versão Han, Y., Kniesel, G., Cremers, A.B. (2005). Towards Visual AspectJ by a Meta Model and Modeling Notation. Annual Aspect-Oriented Software Development Conference (AOSD 2005). Horrocks, I., Sattler, U., Tobies, S.. Reasoning with Individuals for the Description Logics SHIQ. Proc. of the 17th Int. Conf. on Automated Deduction (CADE 2000), volume 1831 of Lecture Notes in Computer Science, pages Springer, Jena. A Semantic Web Framework for Java. Acessado em Abril de Laddad, R. (2003). AspectJ in Action, Practical Aspect-Oriented Programming. Manning, ISBN Mellor, J. Stephen et al (2003). MDA Destilada: Princípios da Arquitetura Orientada por Modelos. Editora Ciência Moderna Ltda., p Noy, N., Fergerson, R., Musen., M The knowledge model of Protege-2000: Combining interoperability and flexibility. 2th International Conference on Knowledge Engineering and Knowledge Management (EKAW'2000), Juan-les-Pins, France. Protégé. Ontology Editor and knowledge-base framework. Acessado em Abril de Santos, D. A., Vieira, Renata, Santana, M. R., Silva, D. M.. (2005) Web Semântica: Ontologias, Lógica de Descrições e Inferências. Anais do Webmídia 2005: Desafios e Soluções. 1 ed. Porto Alegre: SBC, v. 1, p Silva, J.B., Pezzin J. (2007). The formal verification of an applications conceptual models using MDA and OWL. World Congress on Engineering and Computer Science WCECS 2007, San Francisco. Soares, S. Borba, P. Programação Orientada a Aspectos em Java. VI Simpósio Brasileiro de Linguagens de Programação, Rio de Janeiro, Sun. Sun Microsystems (2008). Java Technology. Abril. W3C. World Wide Web Consortium (2008). OWL Web Ontology Language Guide. Abril.