Construção de Modelos Semânticos para Sistemas: uma abordagem orientada a modelos auxiliada por ontologias.

Transcrição

1 Construção de Modelos Semânticos para Sistemas: uma abordagem orientada a modelos auxiliada por ontologias. Resumo Autoria: Richarlyson Alves D'Emery, Fernando da Fonseca de Souza Nos últimos anos, a produção de software vem passando por mudanças e desencadeando o surgimento de novas necessidades e serviços, cada vez mais especializados e independentes da interferência humana. Pesquisas direcionam ao consenso de que para alcançar esse patamar, as aplicações devem possuir mecanismos que ofereçam um suporte semântico às informações, viabilizando a comunicação e o compartilhamento dessas informações entre sistemas. Então surgiu o seguinte questionamento: como representar semanticamente as informações de um sistema de maneira a serem utilizadas por uma plataforma específica?. Neste artigo apresenta-se uma abordagem MDA auxiliada pelo uso de ontologias. Palavras-chave: desenvolvimento de software orientado a modelos, modelagem semântica e ontologia.

2 Introdução No processo de desenvolvimento de software (PDS), costumeiramente, percebe-se a utilização de modelos que elevam o nível de abstração, separando os detalhes de implementação da arquitetura a ser seguida, auxiliando, principalmente, a fase de planejamento. A ideia consiste em trabalhar sob um alto nível de abstração, sem o comprometimento com tecnologias específicas de implementação, nível este em que somente os aspectos do domínio de aplicação estejam mapeados. Assim sendo, caso haja uma mudança de tecnologia, o mapeamento não será afetado. É uma abordagem que se destaca em pesquisas envolvendo Model-Driven Software Development (MDSD). Comumente na etapa de modelagem em um PDS utiliza-se Unified Modeling Language (UML). Por exemplo, Object Management Group (OMG) recomenda a utilização da UML em sua versão 2.0 para representar modelos no desenvolvimento dos sistemas com Model Driven Architecture (MDA), a qual coloca a modelagem no centro do PDS (OMG, 2014). A utilização de modelagem de propósito geral para capturar detalhes de um sistema, pode produzir uma descrição das informações em menor grau de fidelidade. Mas sua utilização decorre do fato de que na indústria de software a maioria dos profissionais possui especialização no paradigma de programação orientado a objetos (OO), e tal paradigma é um fator limitador quando se espera que as informações de um sistema possuam características semânticas. A representação semântica, geralmente, utiliza modelos declarativos, dificultando o desenvolvimento de software devido à escassez de profissionais com esse tipo conhecimento. Semântica de dados é, atualmente, uma característica inerente à produção de algumas famílias de produtos de software que visam atender aos anseios da Web Semântica (W3C, 2009). São diversas as tentativas atuais para a produção de sistemas semânticos (D'Aquin, 2008; El-G., El-D., & Sherief, 2009; Sowa, 2011; Isern, Moreno, S Anchez, Hajnal, Pedone, & Varga, 2011; D Emery, 2012), mas são escassas as pesquisas na literatura que permitam realizar tal modelagem no contexto de produção de software em MDSD. Verifica-se que a maioria das pesquisas e tecnologias existentes isolam a representação semântica do sistema da tecnologia da informação e, para serem bem sucedidos, pesquisadores da área deveriam encontrar maneiras de simplificar as ferramentas de desenvolvimento e integrá-las em aplicativos. Dessa maneira, adveio o seguinte questionamento: como representar semanticamente as informações de um sistema de maneira a serem utilizadas por uma plataforma específica? Este artigo discute a utilização de ontologias para representação de informações de um sistema na etapa de modelagem no PDS, e, consequentemente, possam ser utilizadas no contexto de produção de software por MDA. Para investigar tal questionamento, o presente artigo apresenta, a seguir, as seções de Revisão de literatura, Resultados e Considerações finais. Revisão de literatura A presente seção explorará os temas do contexto de produção de software, visando trazer à discussão e reflexão sobre as características presentes em abordagens consolidadas e atuais. Model-Driven Software Development As abordagens relacionadas à produção de software, que utilizem algum processo de automatização para geração de código, são denominadas generative programming (Czarnecki & Eisenecker, 2000). Dentre as abordagens está o paradigma MDSD, que segundo Frankel (2004) é diferenciado da produção de software clássica, porque viabiliza um desenvolvimento ágil. Para Greenfield e Short (2003), uma das vantagens do MDSD é a geração de códigos em quantidade ao invés do uso de práticas tradicionais de desenvolvimento de software, que geralmente são 2

3 manuais. Em MDSD após a definição de um modelo, este será transformado em código, geralmente com o auxílio de ferramentas. A Figura 1 ilustra uma visão dessa transformação. Figura 1. Modelos para geração de código. Fonte: Adaptada de Greenfield, J., & Short, K. (2003). Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools (p. 20). Proceedings of the Companion of the 18th annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 03). Na Figura 1(a), um modelo é convertido em código a partir de uma ferramenta de plataforma específica. Essa abordagem utiliza vocabulários próprios e devido à complexidade do mapeamento entre a geração de código e as linguagens que representam o modelo, torna o processo de codificação e decodificação trabalhoso, podendo levar a um abandono do modelo. Na proposta da Figura 1(b), a utilização de framework e padrões de linguagens visa auxiliar a geração de código. Utiliza-se a modelagem do domínio da aplicação, para descrever seus conceitos, ou seja, um framework é especificado por meio de um modelo, que pode conter elementos UML, o qual representa os requisitos de sistemas de um mesmo domínio. Como apontado, a utilização de modelagens de propósito geral para capturar detalhes do domínio, produz-se uma descrição das informações do domínio em menor grau de fidelidade. A Figura 1(c) indica que as abstrações podem ser executadas por uma série de modelos, no intuito de permitir o aprimoramento da abstração, como, por exemplo, a utilização de MDA. Espera-se uma única projeção do modelo do sistema, mas permitindo transformações até que ofereça uma correta especificação do sistema, mas claro, com o mapeamento para uma determinada plataforma. Por fim, estes modelos são transformados em artefatos de software. Model Driven Architecture MDA, além de recomendar o uso de modelos como artefato principal, indica a automatização na geração de código. Códigos esses considerados como a principal representação do sistema de software a ser produzido. Probst (2012) aponta que a chave para esse processo está na máxima automatização das etapas de geração dos códigos fonte. 3

4 Trata-se de um padrão arquitetural que objetiva isolar a lógica de negócio da aplicação, da evolução e manutenção da tecnologia utilizada. É evidenciada a separação entre o modelo e plataforma, visando à independência entre a solução computacional e a tecnologia na qual é implementada. Essa abordagem melhora a portabilidade, interoperabilidade e reusabilidade (Gasevic, Djuric, & Devedzic, 2009). Também viabiliza características de PDS como reutilização de modelos de projetos e de código. Para promover as características apresentadas, faz-se necessário a compreensão sobre modelo e os metaníveis de MDA. Modelo é tema de Model Driven Engineering (MDE), área da Engenharia de Software desenvolvida em paralelo com a Web Semântica (Mellor, Scott, Uhl, & Weise, 2005 como citado em Gasevic et al., 2009). MDE baseia-se no princípio de que "tudo é um modelo". A abordagem de MDE para desenvolvimento de software sugere primeiramente que se proponha um modelo para o sistema, o qual será, posteriormente, transformado em um software executável. Nesse sentido, MDA é a pesquisa de maior relevância nessa área. A maioria das definições diz que um modelo é uma visão simplificada da realidade, ou mais formalmente, um conjunto de elementos que descreve um sistema com um grau de abstração maior do que o sistema (Mellor et al., 2005). Linguagens como UML utilizam metamodelos, os quais definem a estrutura, a semântica e as restrições para um grupo de modelos (modelos que compartilham uma sintaxe e uma semântica comuns) (UML, 2014). O metamodelo UML é composto por muitos modelos (OMG, 2011). Mellor et al. (2005) apresenta um subconjunto do metamodelo UML, a saber: modelo para Classe, Propriedade, Operação, Classificador, Associação e Generalização. A Figura 2 apresenta o relacionamento dos modelos do subconjunto do metamodelo UML. Figura 2. Subconjunto do metamodelo UML Fonte: Mellor, S. J., Scott, K., Uhl, A., & Weise, D. (2005). MDA Destilada: princípios de arquitetura orientada por modelos. Rio de Janeiro: Ciência Moderna. Na Figura 2, o subconjunto UML possui o modelo Classe que pode ter diversas operações e propriedades. É uma especialização do modelo Classificador, permitindo ter muitas Associações. Através do subconjunto é possível realizar a modelagem dos modelos a serem usados na metodologia MDA. O metamodelo da UML é uma instância Meta-Object Facility (MOF) (UML, 2014), que fornece um framework de gerenciamento de metadados e um conjunto de serviços para permitir o desenvolvimento de interoperabilidade para sistemas orientados a modelos e metadados. Em seu objetivo primário, o framework gerencia metadados independentes de plataforma para MDA, cuja notação de classe da UML é utilizada para representar os metamodelos MOF, considerado, portanto, como um meta-metamodelo (OMG, 2014). Em um diagrama de classes, por exemplo, é possível criar elementos como classes com atributos e métodos. Também é possível relacioná-las com outras classes (a exemplo de herança), definir interfaces, fazer uma classe realizar uma interface, dentre outros. Cada um destes elementos é um metadado representado em MOF. 4

5 MDA é composta por quatro metaníveis (camadas) de modelagem, usadas como padrão de arquitetura para os padrões definidos pela OMG (2014). A Figura 3 ilustra os metaníveis. Figura 3. Exemplo de níveis de modelos MDA Fonte: Adaptada de Mellor, S. J., Scott, K., Uhl, A., & Weise, D. (2005). MDA Destilada: princípios de arquitetura orientada por modelos. Rio de Janeiro: Ciência Moderna. Nos metaníveis da Figura 3, "umaconta" (metanível M0) é um exemplo de instância da classe "Conta" (M1). Conta utiliza os modelos "Classe", "Atributo" e "Instância" da UML (M2), e esses, por sua vez, utilizam o metamodelo "Classe" do meta-metamodelo MOF (M3). A camada M0 é compreendida pelo sistema de software, no qual são criadas as instâncias de um modelo. A partir de uma linguagem de programação, inúmeras instâncias podem existir e serem criadas. Vale ressaltar que ao modelar um domínio e não o software, as instâncias de M0 são os elementos do domínio. Entretanto, quando se está modelando um software, as instâncias são as representações do software, como, por exemplo, a versão virtual para Conta. Tendo por base as Figuras 2 e 3, a Figura 4 apresenta a relação entre duas instâncias de Disciplina (camada M0) e o respectivo modelo do sistema pertencente à camada M1. O modelo da camada M1 da Figura 4 representa uma disciplina que pode conter os atributos nome e código e tem como instâncias duas disciplinas: Web Semântica de código CCMP50 e Programação com o código CCMP30. Nessa camada estão dispostos os modelos, os quais descrevem os elementos do sistema de software da camada M0, como, por exemplo, o conceito de Disciplina pode ser definido pelas propriedades nome e código. Há uma relação definida entre as camadas M1 e M0, na qual os elementos de M1 são classificações ou categorizações das instâncias de M0, assim como cada elemento de M0 são instâncias de um elemento de M1. 5

6 Figura 4. Relações entre as camadas de MDA A UML é um metamodelo localizado na camada M2. Cada elemento de um metamodelo classifica ou categoriza um elemento da camada M1, ou seja, um elemento de um modelo, por isso é denominada de camada de metamodelagem. Portanto, como cada modelo criado em M2 é um modelo para descrever outros modelos (presentes em M1), podem ser chamados de metamodelos. Ainda na Figura 4, verifica-se que o modelo "Disciplina" é representado pelo atributo "Name" pertencente ao modelo "UML Class" do metamodelo UML. Já os atributos de Disciplina são representados pelo atributo "Name" do modelo "UML Attribute" (elemento do metamodelo UML). No quarto metanível de MDA encontra-se o meta-metamodelo MOF, que fornece serviços para sistemas orientados a modelos, como, por exemplo, a UML. Cada camada de MDA serve de base para a modelagem de uma camada inferior. A Figura 5 apresenta um quadro comparativo entre os metaníveis de MDA. Apesar de OMG estabelecer quatro metaníveis para MDA (OMG, 2014), o número de metaníveis poderia ser maior, no qual um próximo nível passaria a representar o metametamodelo MOF, por exemplo. Mas, o essencial entre os metaníveis da arquitetura MDA é a relação de instanciação que existe entre eles, ou seja, elementos de um metanível inferior são instâncias de elementos categorizados ou classificados do modelo do metanível superior (Kleppe, Warmer, & Bast, 2003). A importância da metamodelagem em MDA está no fato de ser um meio formal de representação de modelos, tendo em vista o processo de desenvolvimento de MDA ser baseado na transformação entre modelos. Outra importância está na utilização de regras de transformação que definem o mapeamento entre um elemento de um modelo-fonte em outro elemento pertencente a um modelo-alvo. Em outras palavras, pode-se dizer que as regras de transformações são definidas em termos de mapeamento entre elementos das linguagens dos modelos fonte e alvo. 6

7 Figura 5. Comparação entre os metaníveis de MDA Czarnecki e Simon (2003) classificam as transformações de MDA em duas categorias: modelo para modelo (M2M) ou modelo para código (M2C). Em ambas, as informações de um sistema são representadas no modelo, que poderá ser construído independente de uma tecnologia ou levar em considerações aspectos dessa tecnologia. Tais características tratam-se do Platform Independent Model (PIM) e Platform Specific Model (PSM), respectivamente. PIM é uma especificação do sistema com um alto nível de abstração e utiliza uma linguagem de modelagem genérica. Contém os detalhes computacionais do sistema de acordo com suas funcionalidades e comportamentos, deixando de lado os aspectos relativos à plataforma de implementação. Em outras palavras, o PIM é um modelo assumido para ser executado sobre uma máquina virtual que independe de tecnologia. Em MDA o PIM é transformado em um ou mais PSM. Esse processo é, geralmente, auxiliado por alguma ferramenta para geração automática de código. O resultado é uma visão do sistema, mas com características voltadas para uma plataforma específica, como, por exemplo, Java. Para realizar a transformação, é desenvolvido um mapeamento para a plataforma definida, usando um Platform Model (PM). O PM provê um conjunto de conceitos técnicos sobre a plataforma e seus serviços, bem como conceitos para os diferentes tipos de elementos a serem usados ao especificar uma plataforma. Existem cinco abordagens para a transformação de modelos: marcações, transformações de metamodelos, transformação de modelos utilizando tipos, aplicações de padrões e união de modelos (OMG, 2014). As transformações de MDA utilizam regras de mapeamento, as quais estabelecem a relação entre os elementos do modelo fonte e os elementos do modelo alvo. Na utilização de marcações associam-se marcas do modelo com algum compilador, que interpreta as marcações e gera um PSM. Um compilador de modelos consiste numa ferramenta que recebe como entrada um modelo, realiza um processamento nos dados de entrada em busca de algumas marcações neles aplicadas e gera como saída outro modelo. Um compilador de modelos pode estar presente em ferramentas CASE (Computer-Aided Software Engineering) com suporte a plataforma escolhida. Vale destacar que em M2C o mapeamento pode ser realizado através de templates, que cotem marcações que especificam como um modelo deve ser transformado, como, por exemplo, marcações para um modelo de sistemas Web ou stand alone. Ontologia A primeira referência ao termo na Ciência da Computação foi observada em 1991, cunhada pelo grupo de pesquisa DARPA Knowledge Sharing Effort, com a ideia de reutilização de componentes como forma de construir sistemas baseados em conhecimento (Neches & Fikes, 7

8 1991). Desde então, ontologias vêm ganhando destaque na Ciência da Computação. Em uma simples busca na Web i pelo termo ontology, observa-se um resultado de mais de 1 milhão de páginas, sendo as primeiras páginas de citações relacionadas à Ciência da Computação, e dessas, cerca de citações referem-se a Gruber (1993), o qual afirma: An ontology is an explicit specification of a conceptualization. A partir de Gruber (1993), Borst (1997) modificou a definição tornando-a mais adequada aos tempos atuais, traduzindo a ideia do autor para Uma ontologia é uma especificação formal e explícita de uma conceitualização compartilhada. Na definição o termo "formal significa legível para computadores; "especificação explícita" diz respeito a conceitos, propriedades, relações, funções, restrições e axiomas, explicitamente definidos; "compartilhado" quer dizer conhecimento consensual por uma comunidade; e "conceitualização" se refere a um modelo abstrato de algum fenômeno do mundo real. Então, o termo passou a ser utilizado na ideia de catalogar e classificar dados a serem interpretados tanto por máquinas quanto por seres humanos. Conclui-se que na Ciência da Computação, uma ontologia é a catalogação de um contexto do mundo real utilizando regras explícitas de propriedades, comportamento e relacionamentos em grupos de contextos similares, chamado de domínio. A ideia de domínio busca referenciar certa aproximação entre as entidades que o compõem, relacionando grupos e consequentemente seus membros. Resulta na proximidade do comportamento real do contexto utilizado, limitando o contexto em domínios importantes para o seu uso, excluindo o que é supérfluo para o problema e obtendo um resultado mais apurado para um cenário trabalhado. Gómez-P. (2002) define que uma ontologia é composta de cinco componentes: conceitos, relações, funções, axiomas e instâncias. Um conceito é uma abstração de qualquer informação que componha o cenário a ser utilizado na ontologia. É uma entidade simples ou composta, abstrata ou concreta, real ou fictícia. Por relação entende-se a interação entre conceitos de um domínio. Já em função uma relação pode gerar um novo conceito. Os conceitos e relações formam a base de uma ontologia, mas uma de suas características importantes é a definição de axioma. Este deve prover a definição semântica dos termos, especificando restrições entre conceitos que possibilitam uma sequência de regras a ser seguida. Por último, o componente instância representa um elemento de um conceito, relação, função e axioma. Na prática, o termo ontologia pode ser tratado como um artefato computacional composto de um vocabulário de conceitos, definições e possíveis propriedades; um modelo que permite definir possíveis relações entre os conceitos e um conjunto de axiomas formais que restringem a interpretação dos conceitos e relações, representando de maneira clara e não ambígua o conhecimento do domínio. Portanto, os componentes de uma ontologia a serem utilizados neste artigo derivam de Gómez-P. (2002): conceitos são entidades que representam uma informação de algum fenômeno do mundo real. Uma entidade é a representação concreta de um conceito e servirá de modelo para a criação de indivíduos. Os indivíduos não são explicitados na ontologia de domínio e cabe ao sistema gerá-los, ou seja, sua existência dependerá do processo de instancialização, como na criação de um objeto na visão do paradigma OO, por exemplo. Propriedades são informações que caracterizam um indivíduo, ou seja, são os atributos (na visão do paradigma OO) de uma entidade. Relacionamentos estabelecem uma interação entre conceitos de um domínio. E por último os termos proveem semânticas que descrevem características relevantes para as demais definições. Permitem configurar regras a serem seguidas, como, por exemplo, axiomas e restrições, entre outros. 8

9 Por que usar ontologia em sistemas end-to-end? São diversas as áreas que necessitam de conhecimento para realizarem seus trabalhos, seja na indústria ou na academia. Um pesquisador geralmente utiliza algum tipo de conhecimento préexistente para fazer inferências sobre um assunto de interesse. Ao tempo em que novos conhecimentos são criados ou modificados, estes são armazenados em algum tipo de repositório de dados e precisam de algum mecanismo para recuperar suas informações. Ontologias implicam em modelos concensuados que evitam que diferentes definições ocupem um mesmo repositório, como, por exemplo, pensemos num produto que é disponibilizado por sistemas com diversos serviços de fabricantes e utilizado por vários serviços de lojas de revenda. Através da representação em uma linguagem de ontologia, como, por exemplo, RDF, poderia se padronizar que, ao descrever um produto, cada serviço de fabricante desse produto deveria associar ao seu nome a sua descrição, mas como ficaria o conteúdo dessa descrição? Cada fabricante descreveria seus produtos de forma independente? Certamente, não. Quando pensado em integração de serviços completamente automatizada é indispensável que exista um entendimento semântico comum sobre as informações manipuladas. É através desses modelos que sistemas utilizam o conhecimento dos especialistas de domínios que ajudaram na construção do modelo. Esse consenso de domínio permite que aplicações possam se comunicar ou compartilhar informações. A partir disso, surge o questionamento: Como esse conhecimento pode ser compartilhado entre pessoas e máquinas? A resposta está na utilização de ontologias. Ontologias fornecem um vocabulário comum para anotação de base de dados, facilitando a documentação, compreensão, manutenção e o compartilhamento como já explicitado. Em banco de dados, as buscas são formuladas por perguntas (queries) que precisam estar bem formuladas, principalmente quanto ao que se quer buscar. Apesar de um desenvolvedor de software estar certo sobre o que se quer buscar em uma pergunta, o conhecimento poderá estar representado de outras formas, não favorecendo a pesquisas por um termo exato. Para exatidão na construção de tais perguntas o desenvolvedor terá de ter participado da elaboração da construção do modelo conceitual do banco de dados. Se a aplicação compartilhar diversos bancos de dados, sua modelagem conceitual deve estar alinhada com a estrutura e conteúdo de cada banco utilizado, pois um conceito pode não ser necessariamente simétrico quando mapeado para outro banco. Se existir n bancos de dados, então poderá haver n (n - 1) possibilidades de integração, mas se utilizada uma ontologia como modelo único de conceitualização desses n banco de dados, o esforço de integração é reduzido para n, uma vez que cada banco de dados será mapeado para essa ontologia. Com isso uma solução computacional poderia utilizar e inferir os conceitos de qualquer banco para a ontologia e da ontologia para qualquer outro banco de dados. Apesar de banco de dados e ontologias representar conceitualizações, a principal distinção está no fato da reutilização da conceitualização de uma ontologia. Como discutido, uma ontologia, em especial de domínio, tem fundamental papel nessa reutilização. O compromisso ontológico está na tentativa de tornar o quanto melhor a separação das dependências de uma ontologia para que decorra numa melhor reutilização dos seus conceitos. São diversas as ontologias utilizadas por comunidades de pesquisa para prover conhecimento a banco de dados e aplicações, como, por exemplo, na educação (Amorim, Lama, Sánchez, Riera, & Vila, 2006), na medicina (Gonçalves, Guizzardi, & Pereira, 2009), entre outras. No desenvolvimento de software, uma ontologia de domínio pode ser vista como um tipo particular de modelo conceitual. Em particular, um modelo conceitual deve satisfazer o requisito adicional de servir como uma representação de consenso (modelo de referência) de uma 9

10 conceituação compartilhada. Esta atividade de modelagem em tal processo de desenvolvimento pode ser comparada à análise de requisitos e as etapas do projeto em Engenharia de Software tradicional (Knublauch, Oberle, Tetlow, & Wallace, 2006). No contexto Web, a maior parte do seu conteúdo é tradicionalmente voltada a seres humanos. Na visão da Web Semântica (W3C, 2009), um conteúdo deve ser legível por máquinas para que possa ser analisado por agentes de software e compartilhado entre os seus serviços. Para este propósito, a W3C (W3C, 2014) recomenda linguagens para estruturar tais informações, como, por exemplo, em RDF uma classe Produto possui uma propriedade tempreço que armazena valores do tipo double, assim como se pode definir uma classe Compra com a propriedade temproduto que relaciona uma compra com um ou mais produtos. Auxiliada por modelos de domínio em qualquer linguagem de ontologia, as aplicações Web poderiam carregar suas informações da mesma maneira como é realizado em HTML. Por exemplo, uma página HTML que exibe um produto pode codificar metadados para relacionar esse produto a uma entidade (conceito) em um modelo RDF ou OWL, para que todas as aplicações que entendam o que é um produto possam entender o seu significado fora do contexto Web. A Figura 6 ilustra um típico cenário de aplicações Web que compartilham informações. Na Figura 6, uma aplicação end-to-end (Loja, por exemplo) usando o compartilhamento de informações por ontologia pode explorar modelos de domínio e serviços Web. Em cada aplicação é ilustrada a definição de conceitos, em notação UML, os quais são compreendidos e utilizados pelas diferentes aplicações. Figura 6. Exemplificação da utilização de ontologia por sistemas Web Fonte: Adaptada de Knublauch, H., Oberle, D., Tetlow, P., & Wallace, E. (Ed.). (2006). A Semantic Web Primer for Object- Oriented Software Developers. W3C World Wide Web Consortium, Retrieved April 02, 2014, from O mesmo exemplo poderia ser desenvolvido por abordagens tradicionais utilizando XML e linguagens de programação OO, por exemplo. Entretanto, as informações do domínio das aplicações dificilmente serão consensuadas, enquanto uma aplicação de comércio eletrônico poderia utilizar o conceito para Consumidor, o sistema de uma loja poderia utilizar Cliente, e sem um mapeamento semântico, as aplicações não saberão que se trata de conceitos equivalentes. 10

11 Uma vez que um recurso é identificado por um Uniform Resource Identifier (URI) único, pode ser estabelecidas ligações entre os diversos modelos existentes. Logo, se um modelo de um domínio for publicado, outros modelos serão potencialmente capazes de utilizá-lo. Ao reutilizar um modelo existente, diferentes aplicações com tarefas similares podem compartilhar resultados e dados com muito mais facilidade. Por exemplo, sistemas do tipo comércio eletrônico que utilizam serviços de "carrinho de compras" e de cartão de crédito. Nesse sentido, em MDSD a criação de modelos precisam levar em consideração tal discussão, partindo do princípio que informações de sistemas podem ser compartilhadas e precisam ser consensuadas. Resultados Apesar de MDA envolver diversas etapas, o objetivo dessa pesquisa é conduzir a discussão da utilização de ontologias na construção M2M, ou seja, do PIM e PSM, sendo este último destinado à plataforma Java. Entretanto, apresenta-se uma solução para a geração da codificação a partir do PSM. Proposta de PIM com conceitos de Ontologia Apesar de PIM ser uma especificação do sistema com um alto nível de abstração e independente de plataforma, geralmente, utiliza-se uma linguagem de modelagem genérica, como, por exemplo, UML, a qual não considera as relações semânticas proporcionadas por ontologias. É decorrente dessa característica que se levantou o questionamento da pesquisa sobre o ponto de vista da utilização de ontologias por profissionais de desenvolvimento de software. Para a modelagem faz-se necessário relacionar o metamodelo de UML com as informações a serem modeladas. Podem-se utilizar apenas alguns dos recursos de UML, um subconjunto que supra as necessidades da modelagem do sistema. Para esta discussão serão utilizados os conceitos de Classe, Propriedade, Operação, Classificador e Associação (subconjunto derivado de Mellor et al. (2005)). A partir dos elementos que compõem uma ontologia e do subconjunto de modelos UML, é proposta a modelagem do PIM (Figura 7). Através do modelo conceitual podem-se extrair as informações de uma ontologia: Entidade, Atributo, Relacionamento e Termos. Entidades poderão ser comportas por Atributos e Relacionamentos. Tanto as Entidades quanto os Relacionamentos podem conter Termos que darão semântica às suas informações. Figura 7. Modelo conceitual A Figura 8 apresenta a associação entre os modelos do PIM, os elementos conceituais de uma ontologia e os termos que compõem a linguagem de ontologia OWL. 11

12 Figura 8. Quadro associativo para os conceitos do PIM, ontologia e linguagem OWL. Vale destacar que os termos devem ser tratados em regras de negócio, uma vez que devem seguir as especificações OWL (Mcguinness & Harmelen, 2009). Por exemplo, o termo inverseof deve ser aplicado a instâncias do modelo Relacionamento, assim como equivalentclass é aplicado ao modelo Entidade, e assim sucessivamente. Proposta de PSM com conceitos de Ontologia A partir da especificação do PIM contendo os componentes de uma ontologia, especificase um PSM para uma plataforma específica. Os conceitos apresentados na Figura 8 permitem a construção do PSM. Portanto, na transformação M2M tem-se um metamodelo envolvendo características da plataforma Java. A Figura 9 apresenta o PSM proposto. Na Figura 9 são apresentados os metamodelos que representam as informações sobre Entidade, Atributo, Relacionamento, Ontologia e Coleção, sendo este último um aperfeiçoamento do PSM que servirá de artefato para utilização de padrões de projetos que permitem implementar as abstrações definidas. Figura 9. PSM destinado à plataforma Java. A modelagem do PSM proposto permite a expansão das informações relacionadas aos termos do PIM, uma vez que os modelos explicitam a expressividade semântica através de termos, como, por exemplo, características de herança (superclasse), disjunção (disjunta) e equivalência (equivalente) em Entidade; e inversão (inversode) para Relacionamento. Vale destacar que a escolha da plataforma Java implica na diminuição de expressividade semântica da ontologia, pois as hierarquias entre classes deverá utilizar herança simples. Então, os domínios de um sistema deverão ser modelados respeitando essa característica da tecnologia, como, por exemplo, a impossibilidade da utilização de herança múltipla. 12

13 Quando pensada em uma linguagem de ontologia como RDF a definição de um conceito (entidade, relacionamento ou propriedade) é dada por um namespace único, referenciando um conceito na ontologia. Dessa maneira, para que uma instância do modelo Entidade do PSM possa ser identificada na ontologia, o seu atributo "uri" deverá ser vinculado a uma informação única. Essa atribuição permitirá a identificação semântica da instância e uma aplicação conseguirá realizar buscas nas instâncias do modelo Entidade por esse atributo identificador. A definição para termos semânticos permitem a representação de relacionamentos como, por exemplo, configurar hierarquia (subclassof de RDF e OWL), configurar igualdade (equivalentclass de OWL), características de propriedade (inverseof de OWL), axiomas (disjointwith de OWL), entre outros. A escolha por RDF ou OWL, por exemplo, permite que um modelo de representação de uma ontologia destinado à plataforma Java, possua termos que flexibilizem a expressividade semântica e assimilem os elementos do paradigma OO (classes, atributos e relacionamentos). Entre os termos estão DatatypeProperty e ObjectProperty, os quais podem ser associados aos conceitos de atributo e métodos do paradigma OO, respectivamente. DatatypeProperty define o tipo de dado de um atributo ou relacionamento, enquanto ObjectProperty define os relacionamentos entre entidades, tendo como resposta uma referência a uma entidade. Apesar de RDF proporcionar a utilização de conceitos (classe, subclasse, propriedades de domínio e contradomínio (range)) que permitiria uma também associação ao paradigma OO, a utilização dos termos DatatypeProperty e ObjectProperty de OWL tem como vantagem a identificação da natureza da propriedade sem ter que analisar o tipo de range definido (característica RDF que denota os valores possíveis a uma propriedade). Outras duas características relacionadas à OWL são: (i) permitir a definição de restrições, as quais não só definem valores possíveis para uma propriedade, mas também podem ser utilizadas para definir condições que permitem ao motor de inferência concluir se determinado indivíduo é instância de uma classe; e (ii) possui o termo FunctionalProperty que permite caracterizar um indivíduo como único. Em especial, essas características são de fundamental importância para sistemas que terão em sua base de dados instâncias para os modelos do domínio da ontologia, que além da necessidade da identificação, precisam ser únicas. Análise da proposta Considerando a proposta do PSM apresentado na Figura 9 em continuidade ao emprego da metodologia MDA, necessita-se definir um processo para abordagem M2C para geração da codificação do sistema a partir do PSM. A transformação M2C é tida como um caso especial de M2M, através da utilização de um metamodelo para a linguagem de programação pretendida. Uma estratégia está na utilização de mapeamentos auxiliados por templates para a linguagem de programação Java (PM do sistema), os quais contêm marcações para os conceitos presentes nos modelos do PSM realizada através de arquivos.vm (templates Velocity Template Language) (Velocity, 2010), por exemplo. A Figura 10 ilustra as marcas do template que mapeiam as informações dos modelos do PSM proposto Na Figura 10 observam-se as marcas $atributo.nome e $relacionamento.nome para mapear as informações do atributo "nome" dos modelos Atributo e Relacionamento do PSM, respectivamente. 13

14 Figura10. PM contendo marcas para geração de código na plataforma Java Vale ressaltar que para viabilizar essa infraestrutura, soluções precisam ser capazes de instanciar as classes de um modelo definido, para que possam ser utilizadas em aplicações, mas separando o interesse da informação, como, por exemplo, na interface gráfica do sistema que irá exibi-lá ou na lógica de controle de regras de negócio desenvolvida por programadores. A Figura 11 ilustra um exemplo de regra de negócio. Figura 11. Regra de negócio para transformação do PSM em código Nesta regra de negócio, observa-se o comando context.put("atributos", atributos)do Velocity relacionando a marca "atributos" para os atributos do modelo Entidade do PSM. Essa marca está destacada no processo de mapeamento ilustrado na Figura 10. Como o objetivo final de MDA está na geração de código através da transformação de modelos. A Figura 12 ilustra as etapas desse processo, ou seja, desde o modelo conceitual PIM até a geração da codificação final. 14

15 Figura 12. Etapas da metodologia MDA proposta Na Figura 12 percebe-se que o PSM utiliza a plataforma exemplificada (Java) e suas informações serão utilizadas na geração da codificação do sistema através da transformação mapeada nas marcações dos templates (PM do sistema). Considerações finais A partir do questionamento que guiou essa pesquisa, conclui-se que a utilização de ontologia permite a modelagem consensual do domínio de um sistema entre profissionais. No contexto de PDS, MDA fundamenta a teoria e prática para construção de modelos semânticos que viabilize a geração da codificação de um sistema. Entretanto, a escolha de uma ontologia é um processo político, já que nenhuma ontologia pode ser totalmente adequada a todos os indivíduos. Ontologias não são estacionárias, i.e., necessitam evoluir e sua evolução não é dada por um processo direto. Ontologias desenvolvidas independentemente não se integrar efetivamente com outras por vários motivos, desde similaridade de vocabulário até visões conflitantes do mundo. Auxiliado por MDSD, a definição de PIM permite que as informações de uma ontologia (entidade, atributo, relacionamento e termos) se relacionem ao paradigma OO aproximando, consequentemente, de profissionais de desenvolvimento de software que, geralmente, não possuem conhecimento nas especificações de linguagens de ontologia. Entretanto a escolha de uma determinada plataforma para o PSM pode implicar numa possível perda de expressividade semântica, como, por exemplo, Java que não permite a utilização de herança múltipla. A utilização de marcações no processo M2C de MDA decorre em vantagens e desvantagens. A desvantagem dessa alternativa é que cada modelo é autossuficiente. Nesse caso, está se construindo uma solução personalizada, o que acarretaria na perda de portabilidade proporcionada pela utilização de um modelo genérico. Mas as tecnologias podem entrar em consonância, assumindo que a utilização do Velocity, por exemplo, retrate apenas a codificação final do sistema a partir das definições (conceitos) contidas no PSM. Uma vez consolidada, serão minimizados eventuais erros no sistema, consequentemente, aumentado à taxa de sucesso. Se utilizadas boas práticas de padrão de projetos, os templates retratarão especificidades do sistema e eventuais erros poderão ser corrigidos pontualmente, uma vez que uma das vantagens de MDA está na máxima automatização do processo de geração de código. Por exemplo, as marcas do template permitem a criação de classes que representam os conceitos do domínio de uma ontologia, assim como da manipulação das instâncias dos conceitos através de operações CRUD de banco de dados. Essas características estão presentes em padrões de Java 2 platform, Enterprise Edition, em especial ao padrão de arquitetura Data Access Object,e.g. Comparada com o reuso de componentes de código, a reutilização de infraestruturas de domínio insere no processo inúmeras vantagens, sendo as principais delas ligadas à comunicação e o entendimento do domínio em questão, a captura da experiência de casos similares e, no caso de um processo formal de desenvolvimento, a obtenção de uma estrutura estável, confiável, robusta e com alto grau de mantenabilidade. Referências 15

16 Borst, W. N. (1997) Construction of engineering ontologies. Tese de doutorado, Universiteit Twente. Enschede, Países Baixos. Czarnecki, K., & Eisenecker, U. W. (2000). Generative Programming: Methods, Tools, and Applications. Bonton: Addison-Wesley. Czarnecki, K., & Simon, H. (2003). Classification of Model Transformation Approaches. Proceedings of the Workshop on Generative Techniques in the Context of Model-Driven Architecture (OOPSLA 03). D'aquin, M. et al. (2008). Toward a New Generation of Semantic Web Applications. Proceedings of the IEEE Intelligent Systems, (23), D Emery R. A. (2012). OntologiaZ: Um Framework Gerador de Código baseado em MDA para Construção de Aplicações End-to-End que utilizam Ontologias e Agentes. Tese de doutorado, Universidade Federal de Pernambuco. Recife, PE, Brasil. El-G., S. M., El-D., A. I., & Sherief, M. (2009). Dynamic ontology mapping for communication in distributed multiagent intelligent system Networking and Media Convergence. Proceedings of de ICNM, Frankel, D. S. (2004). Model Driven Software Development. Business Process Trends Journal in MDA. Gasevic, D., Djuric, D., & Devedzic, V. (2009). Model Driven Engineering and Ontology Development (2a ed.). Heidelberg: Springer. Gómez-P., A., & Corcho, O. (2002). Ontology Languagens for the Semantic Web. Proceedings of the IEEE Inteligente Systems, (13), Gonçalves, B., Guizzardi, G., Pereira, J. G. (2007). An electrocardiogram (ECG) domain ontology. Proceedings of the Workshop on Ontologies and Metamodels for Software and Data Engineering, João Pessoa, PB, Brasil, 2. Greenfield, J., & Short, K. (2003, October). Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. Proceedings of the Companion of the 18th annual ACM SIGPLAN Conference on Object- Oriented Programming, Systems, Languages, and Applications (OOPSLA 03), Anaheim, CA, USA, 18. Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition. (5)2, IMS. IMS Learning Design Information Model - Version 1.0 Final Specification IMS Global Learning Consortium. In: Amorim, R. R., Lama, M., Sánchez, E., Riera, A., & Vila X.A. (2006). A Learning Design Ontology based on the IMS Specification. Educational Technology & Society, (9)1, Kleppe, A., Warmer, J., & Bast, W. (2003). MDA Explained - The Model Driven Architecture: Practice and Promise, Canada: Addison-Wesley. Knublauch, H., Oberle, D., Tetlow, P., & Wallace, E. (Ed.). (2006). A Semantic Web Primer for Object-Oriented Software Developers. W3C World Wide Web Consortium, Retrieved April 02, 2014, from López, M. F., Gómez-P., A., Sierra, J. P., & Sierra, A. P. (1999). Building a chemical ontology using Methontology and the Ontology Design Environment. Intelligent Systems and their Applications, IEEE, (12)1, Mcguinness, D. L., & Harmelen, F. V. (Ed.). (2009, November). OWL Web Ontology Language Overview. W3C World Wide Web Consortium, Retrieved April 02, 2014, from Mellor, S. J., Scott, K.; Uhl, A., & Weise, D. (2005). MDA Destilada: princípios de arquitetura orientada por modelos (1a ed.). Rio de Janeiro: Ciência Moderna. Neches, R., & Fikes, R. E. (1991). Enabling Technology for Knowledge Sharing. AI Magazine, (12)3, OMG. (2014, February). MDA Specifications - The Architecture of Choice for a Changing World. Retrieved April 01, 2014, from OMG. (2011). OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. Retrieved April 01, 2014, from Probst, R. (2012, March). The Architecture of Choice for a Changing World: OMG Model Driven Architecture. Retrieved April 02, 2014, from Sowa, J. F. Future directions for semantic systems. In: Tolk, A., & Jain, L. C. (Ed.). (2011). Intelligence-based Systems Engineering. (1a ed.). Berlin: Springer-Verlag. Cap. 2, Velocity. The Apache Velocity Project. (2010, November). Retrieved April 02, 2014, from W3C. W3C Semantic Web Frequently Asked Questions. (2009, November). Retrieved April 02, 2014, from i Pesquisa realizada a partir de Google Scholar ( recuperado em 10, abril, 2014) 16