Modelo. AutoWebS UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA - DIMAP THIAGO PEREIRA DA SILVA

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA - DIMAP THIAGO PEREIRA DA SILVA AutoWebS Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos Modelo Natal - RN 2012

2

3

4 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA - DIMAP AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO EM FORMATO ELETRÔNICO Na qualidade de titular dos direitos de autor, AUTORIZO o Departamento de Informática e Matemática Aplicada - DIMAp da Universidade Federal do Rio Grande do Norte UFRN a reproduzir, inclusive em outro formato ou mídia e através de armazenamento permanente ou temporário, bem como a publicar na rede mundial de computadores (Internet) e na biblioteca virtual da UFRN, entendendo-se os termos reproduzir e publicar conforme definições dos incisos VI e I, respectivamente, do artigo 5 o da Lei n o 9610/98 de 10/02/1998, a obra abaixo especificada, sem que me seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação da produção acadêmica gerada pela Universidade, a partir desta data. Título: AutoWebS Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos Autor(a): Thiago Pereira da Silva Natal - RN, 06 de Agosto de Thiago Pereira da Silva Autor Thaís Vasconcelos Batista Orientadora

5 THIAGO PEREIRA DA SILVA AutoWebS Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos Dissertação apresentada ao Programa de Pós Graduação em Sistemas e Computação - PPgSC do Departamento de Informática e Matemática Aplicada - DIMAp da Universidade Federal do Rio Grande do Norte, como requisito parcial para obtenção do título de Mestre em Sistemas e Computação. Área de concentração: Engenharia de Software. Orientadora: Profa. Thaís Vasconcelos Batista Natal - RN 2012

6 THIAGO PEREIRA DA SILVA AutoWebS Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos Dissertação defendida no Programa de Pós Graduação do Departamento de Informática e Matemática Aplicada - DIMAp da Universidade Federal do Rio Grande do Norte como requisito parcial para obtenção do título de Mestre em Sistemas e Computação, aprovada em 06 de Agosto de 2012, pela Banca Examinadora constituída pelos professores: Profa. Thaís Vasconcelos Batista Departamento de Informática e Matemática Aplicada - DIMAp UFRN Presidente da Banca Prof. Nélio Alessandro Azevedo Cacho Universidade Federal do Rio Grande do Norte - DIMAp UFRN Profa. Flavia Coimbra Delicato Universidade Federal do Rio de Janeiro - DCC/IM UFRJ Prof. Paulo F. Pires Universidade Federal do Rio de Janeiro - DCC/IM UFRJ

7 Agradecimentos Agradeço a minha orientadora Thais Batista pela dedicação, ensinamentos e compartilhamento de experiências que me foi dado durante o mestrado. Agradeço os professores Paulo Pires, Nélio Cacho e Flávia Delicato pelas sugestões valiosas que contribuiram para o desenvolvimento deste trabalho. Sou grato aos meus pais, meus irmãos e minha avó pelo amor e carinho que sempre me deram. Aos colegas de trabalho, Lidiane, Fred Lopes, Everton Cavalcante, Taniro Rodrigues, Ana Luisa, Gustavo, Eduardo e Lucas Silva agradeço os conselhos, ensinamentos e companhia. A CAPES pelo apoio financeiro despendido a este trabalho.

8 Resumo da Silva, Thiago Pereira. AutoWebS: Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos. Natal - RN, p. Dissertação de Mestrado. Departamento de Informática e Matemática Aplicada - DIMAp, Universidade Federal do Rio Grande do Norte. Tipicamente serviços Web contêm apenas informações sintáticas que descrevem suas interfaces e a falta de descrições semânticas torna a composição de serviços Web uma tarefa difícil. Para resolver este problema, pode-se usar ontologias para a definição semântica da interface dos serviços, facilitando a automação da descoberta, publicação, mediação, invocação e composição dos serviços. No entanto, linguagens que permitem se descrever semanticamente serviços Web utilizando ontologias, como OWL-S, têm construções que não são fáceis de entender, mesmo para desenvolvedores Web, e as ferramentas existentes levam aos usuários muitos detalhes que as tornam difíceis de serem manipuladas. Este trabalho apresenta uma ferramenta chamada AutoWebS (Automatic Generation of Semantic Web Services) para o desenvolvimento de serviços Web semânticos. O AutoWebS usa uma abordagem baseada em perfis UML e transformações entre modelos para a geração automática de serviços Web e sua descrição semântica em OWL-S. O AutoWebS disponibiliza um ambiente que oferece recursos para modelar, implementar, compilar e implantar serviços Web semânticos. Palavras chave MDD, OWL-S, serviço Web semântico, perfil UML, Web semântica

9 Abstract da Silva, Thiago Pereira. AutoWebS: Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos. Natal - RN, p. MSc. Dissertation. Departamento de Informática e Matemática Aplicada - DIMAp, Universidade Federal do Rio Grande do Norte. Typically Web services contain only syntactic information that describes their interfaces. Due to the lack of semantic descriptions of the Web services, service composition becomes a difficult task. To solve this problem, Web services can exploit the use of ontologies for the semantic definition of service s interface, thus facilitating the automation of discovering, publication, mediation, invocation, and composition of services. However, ontology languages, such as OWL-S, have constructs that are not easy to understand, even for Web developers, and the existing tools that support their use contains many details that make them difficult to manipulate. This paper presents a MDD tool called AutoWebS (Automatic Generation of Semantic Web Services) to develop OWL-S semantic Web services. AutoWebS uses an approach based on UML profiles and model transformations for automatic generation of Web services and their semantic description. AutoWebS offers an environment that provides many features required to model, implement, compile, and deploy semantic Web services. Keywords MDD, OWL-S, semantic Web services, UML profile, semantic Web

10 Sumário Lista de Figuras 9 Lista de Tabelas 11 Lista de Códigos de Programas 12 1 Introdução Objetivos Estrutura do Documento 17 2 Fundamentação Teórica Serviço Web Web Semântica RDF e RDF Schema Ontologia OWL Serviços Web Semânticos OWL-S Service Profile Service Model Service Grounding Desenvolvimento de Software Dirigido por Modelos 40 3 Mapeamento entre OWL e UML Mapeamento entre as linguagens de especificação de ontologias e a UML Mapeamento entre OWL e UML 46 4 Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos Requisitos de uma ferramenta para criação de serviços Web semânticos Visão Geral da Ferramenta Arquitetura Perfil UML Importação das Ontologias OWL Metamodelo da Linguagem OWL-S Implementação das Regras de Mapeamento entre UML e OWL-S Funcionamento da Ferramenta 65

11 5 Estudo de Caso Sistemas de middleware de provisão de contexto Ontologia de Domínio Modelagem do Serviço Web Semântico Resultados 74 6 Experimento Controlado Ferramentas Avaliadas Projetos de Serviços Web Semânticos Serviço Web semântico OilMonitor Serviço Web semântico OilMonitor Serviço Web semântico Book Finder Serviço Web semântico Zip Code Finder Serviço Web semântico Latitude Longitude Finder Serviço Web semântico Barnes and Nobles Price Finder Serviço Web semântico BabelFish Translator Serviço Web semântico Currency Converter Planejamento do Experimento Objetivos Questões a serem respondidas e métricas correspondentes 80 Sobre a ferramenta 80 Sobre o grau de dificuldade, tempo e esforço despendido na criação das diferentes ontologias dos serviços Web 81 Sobre o uso da ferramenta Hipóteses 82 Alternativas 82 Nulas Variáveis 82 Variáveis Independentes 82 Variáveis Dependentes 83 Variáveis Controladas Seleção dos Participantes e Treinamento Local do Experimento e Recursos Validade Operação do Experimento Plano Experimental Questionário do Perfil do Participante Questionário para Análise Subjetiva da Ferramenta e do Projeto do Serviço Web Análise e Interpretação dos Resultados Apresentação dos Resultados Teste Estatístico Análise Qualitativa Verificação da Hipóteses 92

12 7 Trabalhos Relacionados OWL-S Editor CODE - CMU s OWL-S Development Environment ASSAM - Automated Semantic Service Annotation with Machine Learning Yang e Chung Kim e Lee Comparação entre as ferramentas Conclusão Contribuições Limitações Trabalhos Futuros 108 Referências Bibliográficas 110 A XSL Transformation 118 B Tecnologias dos serviços Web 123 B.1 SOAP 123 B.2 WSDL 127 B.3 UDDI 131 B.4 Apache Axis2 132 C Tranformação XSLT 133 D Tranformação QVT 147 E Questionários do Experimento Controlado 154 E.1 Questionário do Perfil do Participante 154 E.2 Questionário para Análise Subjetiva da Ferramenta e da Atividade 155 E.3 Questionário para o AutoWebS 156 F Quadrados Latino 158

13 Lista de Figuras 2.1 Arquitetura de um serviço Web - retirado de [Wikipedia, 2011] Principais tecnologias da Web semântica Exemplo de um grafo em RDF - ilustração retirada de [Manola and Miller, 2004] Dialetos da OWL Relação entre classes OWL Subontologias da OWL-S - extraído de [Burstein et al., 2004] OWL-S Service Profile - extraído de [Burstein et al., 2004] Subontologia OWL-S ServiceModel - extraído de [Burstein et al., 2004] Grounding OWL-S/WSDL - extraído de [Burstein et al., 2004] Classes e propriedades da subontologia OWL-S ServiceGrounding Transformações entre modelos Exemplo de mapeamento entre OWL euml Visão geral da ferramenta AutoWebS Arquitetura da ferramenta AutoWebS Perfil UML usado pela ferramenta AutoWebS Ontologia BibTex representada como UML Mapeamento da classe OWL em UML Metamodelo OWL-S Transformação de UML para OWL-S Funcionamento do AutoWebS Arquitetura do OpenCOPI - extraído de [Lopes et al., 2009b] Ontologia de domínio OilExploration Trecho da ontologia de domínio OilExploration Atividades realizadas para o estudo e caso Trecho da ontologia de domínio OilExploration Artefatos de códigos gerados Implementação da regra de negócio do serviço Web Tempo de desenvolvimento dos serviços Web semânticos Valores Críticos W para o teste de Wilcoxon para amostras pequenas - extraído de [Lowry, 2012] Grau de cansaço no desenvolvimento dos serviços Web semânticos Grau de contribuição da ferramenta para o desenvolvimento dos serviços Web semânticos Grau de dificuldade em criar o serviço Web 91

14 6.6 Grau de dificuldade em criar a ontologia do serviço Web Recursos oferecidos pelas ferramentas avaliadas Contribuição para o desenvolvimento do serviço Web semântico Ferramenta OWL-S Editor Arquitetura da ferramenta CODE - extraído de [Srinivasan et al., 2005] Ferramenta ASSAM - extraído de [Heß et al., 2004] Abordagem de Yang e Chung para construção de serviços Web semânticos - extraído de [Yang and Chung, 2006b] Abordagem de Kim e Lee para construção de serviços Web semânticos - extraído de [Kim and Lee, 2007] 101 A.1 Transformação em XSLT 119 B.1 Elementos do WSDL F.1 Exemplo de quadrado latino de tamanho 4 158

15 Lista de Tabelas 2.1 Mudanças das características da Web semântica Mapeamento entre UML e os principais conceitos das linguagens para especificação de ontologias Mapeamento entre o elemento owl:ontology e a UML Mapeamento entre as construções de classes OWL e a UML Mapeamento entre o elemento owl:restriction e a UML Mapeamento entre os elementos owl:objectproperty e owl:datatypeproperty e a UML Mapeamento entre alguns elementos da OWL e a UML Mapeamento dos tipos de dados do Schema XML e a UML Distribuição dos Blocos Réplica l Réplica Réplica Réplica Resultados obtidos na execução do experimento controlado Cálculo do teste estatístico de Wilcoxon Comparação entre os trabalhos relacionados 101

16 Lista de Códigos de Programas 2.1 Descrição em RDF/XML das afirmações sobre Eric Miller - extraído de [Manola and Miller, 2004] Declaração do cabeçalho de um documento OWL Declaração de uma classe e suas propriedades em OWL Instância da classe Regime Exemplo de uma transformação QVT 41 A.1 Mensagem SOAP 120 A.2 XSLT para a mensagem SOAP 121 A.3 Documento 122 B.1 Exemplo de Mensagem SOAP de Resposta 125 B.2 Exemplo de Mensagem SOAP de Requisição 126 B.3 Definição do tipo complexo subscribeburdenassyncservice 127 B.4 Definição do elemento message 130 B.5 Definição do elemento porttype 130 B.6 Definição do elemento binding 131

17 Introdução CAPÍTULO 1 Serviços Web [Alonso et al., 2004] fornecem meios para comunicação entre diferentes sistemas de software em diferentes plataformas, tornando-se um paradigma efetivo da computação distribuída na Internet. Entretanto, apesar dos esforços da W3C (World Wide Web Consortium) em padronizar as tecnologias utilizadas pelos serviços Web, a fim de facilitar a interoperabilidade, o uso desses serviços, em muitas situações, necessita da intervenção humana, uma vez que os serviços Web carecem da definição semântica da interface dos seus serviços. Por exemplo, no processo de busca por serviços relevantes que podem ser combinados para atender a uma determinada aplicação. Outro exemplo que evidencia a ausência de definição semântica dos serviços Web é o UDDI (Universal Description Discovery and Integration) [Bloehdorn and Moschitti, ], que não utiliza semântica para descrição dos serviços e seu uso é praticamente desnecessário, uma vez que, em geral, as aplicações invocam diretamente os arquivos WSDL (Web Service Definition Language) [Christensen et al., 2001] em detrimento à utilização de APIs (Application Programm Interface) baseadas em palavra-chave que realizam busca sintáticas no UDDI. Os resultados dessas buscas são passíveis de ambiguidade. Já os arquivos WSDL somente descrevem a interface dos serviços, ou seja, fornecem uma descrição sintática, e informações úteis para composição e interoperação entre serviços Web, ou seja, as informações semânticas não são fornecidas, como por exemplo, o comportamento do serviço e sua relação com elementos de uma ontologia. Para preencher essa lacuna surgiram os serviços Web semânticos [McIlraith et al., 2001], que tratam a questão da definição semântica dos serviços através do uso de ontologias. As ontologias proporcionam uma descrição do serviço interpretável computacionalmente através da associação dos elementos do serviço Web com os conceitos definidos em uma ontologia. Os serviços Web semânticos são um prolongamento da Web semântica [Berners-Lee et al., 2001] para os serviços Web de forma a facilitar a automatização da descoberta, publicação, mediação, invocação e composição de serviços. O desenvolvimento de um serviço Web semântico ocorre, basicamente, em duas etapas: (i) o desenvolvimento do serviço Web e (ii) a criação da ontologia ou descrição semântica do serviço Web. A ontologia do serviço Web pode utilizar conceitos definidos em outras

18 14 ontologias como, por exemplo, ontologias para um domínio específico. Existem várias linguagens que permitem se descrever semanticamente serviços Web utilizando ontologias. Alguns exemplos são OWL-S (Ontology Web Language for Services) [Burstein et al., 2004], WSMO (Web Service Modelling Ontology) [de Bruijn et al., 2005], WSDL-S (Web Service Semantics) [Akkiraju et al., ] e SAWSDL (Semantic Annotations for WSDL and XML Schema) [Kopecký et al., 2007]. Essas linguagens apresentam sintaxes distintas, um vocabulário muito extenso e a grande maioria são baseadas em lógica descritiva ou de primeira ordem. As ferramentas existentes que apóiam sua utilização levam ao usuário muitos detalhes que as tornam difíceis de serem manipuladas. A adoção de descrições semânticas dos serviços Web esbarra nas limitações das ferramentas e no fato de que criar ontologia demanda tempo e é difícil de ser realizada, conforme Missikoff [Missikoff et al., 2002] ressalta em seu trabalho. As ferramentas atuais para a criação da descrição semântica de serviços Web foram projetadas para serem utilizadas por especialistas da Web semântica, pois seus usos requerem o conhecimento de muitos conceitos desta área. Brambilla et al. [Brambilla et al., 2007] argumentam que o maior obstáculo para a ampla adoção dos serviços Web semânticos é a dificuldade em descrever aplicações Web com tecnologias semânticas. Portanto, para se explorar os serviços Web semânticos é preciso haver ferramentas que abstraiam detalhes específicos, relativos a cada linguagem de descrição semântica, que normalmente demandam muito tempo para a total compreensão e, não deveria demandar tanto tempo quanto a de implementação da regra de negócio do serviço Web. Em virtude dos benefícios que os serviços Web semânticos oferecem, as abordagens empregadas pelas ferramentas atuais devem ser repensadas em direção a novas abordagens que ofereçam um maior nível de abstração sobre a sintaxe das linguagens. Neste sentido, [Chafle et al., 2007] e [Fonseca et al., 2009] propuseram alguns requisitos essenciais para o desenvolvimento de uma ferramenta para compor serviços Web. Alguns destes requisitos podem ser adaptados para uma ferramenta de alto nível de abstração para a criação de serviços Web semânticos. Estes requisitos adaptados, juntamente com novos requisitos podem formar um conjunto mínimo de requisitos para uma ferramenta para criação de serviços Web semânticos acessível a um público maior do que aquele formado por especialistas da Web semântica. Os requisitos mínimos de uma ferramenta para criação de serviços Web semânticos devem definir abordagens para abstrair as tecnologias subjacentes usadas no desenvolvimento de serviços Web semânticos, isto é, as tecnologias usadas na especificação das interfaces dos serviços Web e nas suas ontologias. Também, por se tratar de uma ferramenta de alto nível de abstração, faz-se necessário a especificação de requisitos sobre a automatização da geração de artefatos de código, pois se deseja abstrair as linguagens

19 15 envolvidas na criação de serviços Web semânticos. Os requisitos devem prever a integração das funcionalidades necessárias para criação de serviços Web semânticos, sem que haja a necessidade do usuário usar recursos externos à ferramenta, de forma a diminuir o tempo de desenvolvimento dos serviços Web semânticos, evitar erros e possíveis conflitos gerados quando se usa diferentes ferramentas/aplicativos como, por exemplo, conflitos de versões das linguagens de especificação da interface do serviço Web ou da ontologia do serviço Web. Para atender os requisitos mínimos de uma ferramenta para criação de serviços Web semânticos, o Desenvolvimento de Software Dirigido por Modelos (Model Driven Development - MDD) [Stahl and Völter, 2006] pode ser utilizado para gerenciar a complexidade inerente do emprego de ontologias para especificação de serviços Web semânticos, pois MDD é uma abordagem de desenvolvimento de software que está centrada na criação de modelos, em vez de código de programa, permitindo separação de interesses entre especificação e implementação. Usando-se uma abordagem MDD é possível prover abstração das tecnologias subjacentes aos serviços Web semânticos através de modelos. No contexto do MDD a linguagem de modelagem UML (Unified Modeling Language) é amplamente usada para modelagem de sistemas de software e também para criação de modelos em abordagens MDD. A linguagem UML e as linguagens de especificação de ontologias têm algumas sobreposições e semelhanças, especialmente para representação estrutural de um software. Alguns elementos das duas linguagens são semelhantes como, por exemplo, classes, associações entre classes, propriedades de classes, generalizações e tipos de dados. Estas semelhanças tornam possível o mapeamento de alguns elementos das linguagens de especificação de ontologias em elementos de um modelo UML [Atkinson et al., 2006, Pondrelli, 2005]. Outros elementos das linguagens de especificação de ontologias que não correspondem diretamente aos elementos primários da linguagem UML podem ser representados com o uso de perfis UML. Um perfil UML consiste em uma coleção de extensões que personalizam a UML para um domínio específico. O uso de perfis UML é altamente alinhado à proposta da MDD, pois os perfis UML definem uma versão especializada da UML para um determinado domínio. Logo, os modelos criados a partir de perfis UML são modelos UML válidos e podem utilizar as mesmas ferramentas para modelagem em UML. Este trabalho apresenta o AutoWebS (Automatic Generation of Semantic Web Services), uma ferramenta baseada no desenvolvimento dirigido por modelos (MDD - Model Driven Development [Stahl and Völter, 2006]) para criação de serviços Web semânticos. O AutoWebS oferece um ambiente gráfico onde é possível importar ontologias especificadas na linguagem OWL (Web Ontology Language) [Dean and Schreiber, 2004] e representá-las graficamente utilizando elementos definidos em um perfil UML (Unified Modeling Language). Estes elementos servem para que a interface de um serviço Web

20 1.1 Objetivos 16 possa ser modelada. Dessa forma, abstrai-se dos desenvolvedores a sintaxe e algumas construções da linguagem OWL, tais como especificações de relações entre propriedades e definições de indivíduos, que são desnecessárias para a criação de serviços Web semânticos. O AutoWebS integra, em um único ambiente, várias funcionalidades que um desenvolvedor precisa para modelar, implementar, compilar e fazer o deploy de um serviço Web semântico. No ambiente oferecido pelo AutoWebS é possível: (i) modelar a interface do serviço Web, isto é, modelar os inputs e outputs de cada operação do serviço Web, (ii) realizar as anotações semânticas, ou seja, associar os inputs e outputs das operações com os elementos de uma ontologia, (iii) criar automaticamente o arquivo OWL-S que contém a descrição semântica do serviço Web, (iv) gerar automaticamente o código fonte do serviço Web modelado, (v) estender a funcionalidade da ferramenta como, por exemplo, incluir suporte a outra linguagem de descrição semântica, com a inserção de novos plugins. Para a implementação da ferramenta é utilizado o ambiente Eclipse, juntamente com o EMF (Eclipse Modeling Framework) [Steinberg et al., 2008] para especificação em Ecore do metamodelo da linguagem OWL- S. O perfil UML define alguns estereótipos e propriedades para os elementos do diagrama de classes da UML 2.0. A transformação entre os modelos é realizada através de regras definidas na linguagem QVT (Query/View/Transformation) [Object Management Group, 2008]. Enquanto que, para importação da ontologia de domínio, são usadas regras definidas na linguagem XSLT (XSL Transformations) [w3c, 1999]. Para a transformação de modelo para texto é usado o Acceleo [Obeo Network, 2007], para geração do código fonte do serviço Web usamos o middleware Axis2 da Apache [Perera et al., 2006]. 1.1 Objetivos O objetivo principal desse trabalho é a especificação e o desenvolvimento de uma ferramenta para criação de serviços Web semânticos. Esta ferramenta, chamada de AutoWebS, deve implementar uma abordagem MDD, com o uso de um conjunto de estereótipos definidos em perfil UML, um metamodelo para linguagem OWL-S e transformações automatizadas entre modelos. O AutoWebS deve oferecer um ambiente gráfico que recebe como entrada uma ontologia de domínio, especificada na linguagem OWL, e fazer sua transformação para elementos predefinidos em um perfil UML. Neste ambiente gráfico deve ser possível modelar a interface do serviço Web utilizando os elementos da ontologia de domínio importada. Desta forma, após a modelagem do serviço Web, deve ser aplicado um conjunto de regras de transformações para criação automática da descrição semântica do serviço Web na linguagem OWL-S e, também, para geração do código fonte do serviço Web.

21 1.2 Estrutura do Documento 17 Para alcançar o objetivo principal deste trabalho são necessários os seguintes objetivos específicos: Especificar um perfil UML que torne possível a modelagem e representação da interface de serviços Web, bem como a representação de elementos de uma ontologia OWL que são necessários para criação de um serviço Web semântico; Elaborar regras de transformações XSLT para transformar os elementos de uma ontologia OWL que são necessários para criação de serviços Web semânticos, em elementos da UML; Elaborar um metamodelo em Ecore para a linguagem OWL-S; Implementar transformação Modelo para Modelo (M2M) na linguagem QVT para transformar um modelo UML em um modelo correspondente ao metamodelo OWL-S; Implementar transformação Modelo para Texto (M2T) para que, a partir de um modelo OWL-S, criar-se um arquivo OWL-S; Ilustrar o uso do AutoWebS através de um estudo de caso que consiste na criação de serviços Web semânticos para os serviços providos por sistemas de middleware de provisão de contexto que não utilizam a tecnologia de serviços Web; Avaliar a ferramenta através de um experimento controlado que confronta o uso do AutoWebS em relação a uma suíte de aplicativos composta pelo OWL-S Editor [Elenius et al., 2005] um plugin do software Protégé [Noy et al., 2000] que é amplamente utilizado para criação de ontologias OWL-S, e o plugin Axis2 da IDE Eclipse, usado para criar serviços Web. Validar as descrições semânticas de serviços Web geradas pelo AutoWebS através da aplicação de validadores sintáticos para a linguagem OWL-S; 1.2 Estrutura do Documento Este trabalho está estruturado da seguinte forma: O Capítulo 2 apresenta as tecnologias dos serviços Web, Web semântica e Desenvolvimento de Software Dirigido por Modelos, que são usadas no desenvolvimento desse trabalho; o Capítulo 3 apresenta a similaridade entre as linguagens de especificação de ontologias e a linguagem de modelagem UML, apresentando o mapeamento entre a linguagem OWL e a UML; o Capítulo 4 apresenta a ferramenta AutoWebS, detalhando sua arquitetura, implementação e funcionamento; o Capítulo 5 apresenta um estudo de caso que usa a ferramenta; o Capítulo 6 apresenta um experimento controlado que avalia a ferramenta AutoWebS; o Capítulo 7 cita os trabalhos relacionados; por fim, no Capítulo 8 são descritas as considerações finais e a conclusão.

22 1.2 Estrutura do Documento 18 O Apêndice A apresenta a linguagem XSL Tranformation, usada para converter documentos XML em outro documento XML ou textual; o Apêndice B apresenta as tecnologias SOAP, WSDL, UDDI e Apache Axis2 usadas pelos serviços Web; o Apêndice C traz a transformação XSLT; o Apêndice D demonstra o mapeamento QVT; e o Apêndice E traz os questionários usados na condução do experimento controlado. O Apêndice F traz uma breve explicação do modelo experimental Quadrado Latino.

23 Fundamentação Teórica CAPÍTULO 2 Este capítulo descreve sucintamente as principais tecnologias usadas nesse trabalho. As tecnologias formam a fundamentação teórica para o trabalho e são apresentadas da seguinte forma: a seção 2.1 discorre a respeito das principais tecnologias usadas pelos serviços Web e apresenta o middleware para serviços Web da Apache Axis2; a seção 2.2 apresenta a Web Semântica, com enfoque para o framework RDF, também são apresentados os conceitos de ontologias e a linguagem OWL, por fim são apresentados os serviços Web semânticos; a seção 2.3 apresenta a ontologia OWL-S que é utilizada para descrição dos serviços Web; a seção 2.4 contém uma rápida descrição das tecnologias do contexto do Desenvolvimento de Software Dirigido por Modelos (MDD) utilizadas neste trabalho. 2.1 Serviço Web A W3C define serviço Web [Alonso et al., 2004] como uma tecnologia que provê meios para comunicação entre diferentes sistemas de software em diferentes plataformas. Os serviços Web são serviços distribuídos que processam mensagens SOAP (Simple Object Access Protocol) [Mitra, 2003] codificadas em um arquivo XML, mandadas através de protocolos da Internet como, por exemplo, HTTP (Hypertext Transfer Protocol) e POP (Post Office Protocol). Os serviços Web são descritos em WSDL (Web Services Description Language) e, normalmente, são registrados em um repositório UDDI (Universal Description Discovery and Integration) para que aplicações possam localizá-las, conforme ilustrado na Figura 2.1. O apêndice B apresenta as tecnologias SOAP, WSDL, UDDI e o framework da Apache Axis2, usadas para construção de serviços Web. 2.2 Web Semântica A Web semântica [Berners-Lee et al., 2001] propõe a estruturação semântica do conteúdo da Web a partir da atribuição de um significado a cada elemento publicado na

24 2.2 Web Semântica 20 Figura 2.1: Arquitetura de um serviço Web - retirado de [Wikipedia, 2011] Internet de forma a tornar possível o seu entendimento, tanto pelo humano quanto pelo computador. A Web Semântica estende a Web tradicional, baseada em redes de hiperlinks, adicionando metadados 1 sobre os conteúdos e como eles estão relacionados. Para prover a estruturação semântica do conteúdo da Internet, a Web semântica utiliza três principais tecnologias: XML; esquemas sintáticos; e ontologias; conforme ilustrado na Figura 2.2. A primeira tecnologia é a metalinguagem XML, que torna possível estruturar e organizar conteúdos na Internet de forma customizada através de marcações. A segunda tecnologia tem como propósito atribuir sentido lógico as informações. Sobre estas informações aplicam-se esquemas sintáticos como, por exemplo, RDF (Resource Description Framework) que é um modelo de representação para fazer em XML afirmações a respeito dos recursos disponíveis na Web. A terceira principal tecnologia são as ontologias, utilizadas para explicitamente representar e definir os conceitos e suas interrelações em domínio. Figura 2.2: Principais tecnologias da Web semântica Existem uma série de mudanças em algumas características da Web tradicional 1 dados estruturados que descrevem a característica de um recurso

25 2.2 Web Semântica 21 em relação à Web semântica, devido a descrição formal dos conceitos, termos e relações dos elementos da Web. Sollazzo et al.[sollazzo et al., 2002] sintetizam algumas dessas mudanças, representadas na Tabela 2.1. Características Mudanças Web Tradicional Web Semântica Serviços Web Simples Composto Requisitante Humanos Agentes de software Broker Principal entidade Apenas um facilitador Descrição do serviço Taxonomia Ontologia Elementos descritivos Fechados Abertos Troca de mensagens Estrutura sintática Estrutura semântica Tabela 2.1: Mudanças das características da Web semântica A Web semântica permite a descrição mais rica dos serviços Web sendo que o papel fundamental do broker pode desaparecer. Ele ainda pode ser viável como motor de pesquisa para serviços Web, mas ele vai perder o seu papel fundamental de repositório para registro de serviços e documentos, porque com a Web semântica qualquer pessoa pode publicar descrições semânticas de seus serviços ou dados para que outras possam encontrá-los. Na Web semântica, agentes inteligentes assumem o papel de solicitante de serviços Web ao invés do usuário humano e serviços podem ser obtidos a partir da composição de outros serviços. As tecnologias que compõem os pilares da Web semântica são apresentadas nas próximas subseções RDF e RDF Schema RDF (Resource Description Framework) [Lassila et al., 1998] é uma linguagem que oferece um modelo de representação para fazer em XML afirmações a respeito dos recursos disponíveis na Web. RDF é usado para representar metadados dos recursos disponíveis na Web a partir de afirmações. Cada afirmação em RDF é formada por uma tripla sujeito-predicado-objeto, onde o sujeito representa um determinado recurso, que pode ser qualquer coisa que contenha um URI (Uniform Resource Identifier), incluindo as páginas da Web assim como elementos de um documento XML, figuras, serviços, etc. O predicado representa aspectos, características ou propriedade do recurso e expressa uma relação entre o sujeito e o objeto. Para exemplificar o poder de expressividade da RDF considere a seguinte exemplo, retirado da W3C Recommendation [Manola and Miller, 2004].

26 2.2 Web Semântica 22 there is a Person identifi ed byhttp:// whose name is Eric Miller, whose address is em@w3.org, and whose title is Dr. Esta afirmação pode ser também visualizada como um grafo RDF, conforme ilustrado na Figura 2.3. Figura 2.3: Exemplo de um grafo em RDF - ilustração retirada de [Manola and Miller, 2004] Na afi rmação ilustrada na Figura2.3 é possível identifi car que osujeito RDF é o recurso " ou seja, um URI. O sujeito RDF possui um tipo Person que está definido no URI htt p : // Esta afirmação relaciona alguns objetos: Eric Miller que possui o predicado "whose name is"; em@w3.org com o predicado "whose address is"; Dr. com o predicado "whose title is". Os predicados da afirmação estão associados às seguintes URIs: whose name is whose address is whose title is

27 2.2 Web Semântica 23 Desta forma, utilizando as URIs, podemos expressar as seguintes triplas RDFs: Eric Miller Dr Para armazenar e compartilhar as afirmações descritas em RDF, é usado uma linguagem baseada em XML chamada de RDF/XML. O trecho de Código 2.1 demonstra em RDF/XML o grafo correspondente a Figura 2.3. Código 2.1 Descrição em RDF/XML das afirmações sobre Eric Miller - extraído de [Manola and Miller, 2004] 1 <?xml version="1.0"?> 2 <rdf:rdf xmlns:rdf=" 3 xmlns:contact=" <contact:person rdf:about=" 6 <contact:fullname>eric Miller</contact:fullName> 7 <contact:mailbox rdf:resource="mailto:em@w3.org"/> 8 <contact:personaltitle>dr.</contact:personaltitle> 9 </contact:person> 11 </rdf:rdf> O objetivo da RDF é definir um mecanismo para descrição de recursos que não faça nenhuma suposição ou premissa sobre o domínio de uma aplicação. Desta forma, modelos RDF podem ser reutilizados para vários domínios. O Schema RDF define um modelo orientado a objeto para os tipos de dados em RDF através da definição dos conceitos de classes, relações entre classes e propriedades. As classes definidas no Schema RDF podem ser organizadas em uma hierarquia, semelhante a sistemas orientados a objeto. O Schema RDF suporta herança múltipla e a maior diferença entre ele e linguagens orientadas a objeto é que todas as classes em RDF

28 2.2 Web Semântica 24 podem ser sobrepostas. A herança múltipla permite também que instâncias mudem seus tipos durante seu ciclo de vida. As propriedades RDF são entidades autônomas que podem ser definidas de forma independente de uma classe específica. As propriedades RDF podem ser utilizadas em várias outras classes. Isto faz com que seja possível reutilizar a mesma propriedade em vários arquivos. Para associar uma propriedade a uma classe é utilizado a declaração rdfs:domain, uma tag do namespace do Schema RDF. RDF define os tipos de dados a partir de um Schema XML. Alguns valores dos tipos de dados são xsd:string e xsd:float. É possível limitar os tipos que um valor de uma propriedade pode ter usando a declaração rdfs:range. Uma propriedade pode assumir valores definidos em um Schema XML ou uma classe. Propriedades que possuem classes podem ser comparadas a relacionamentos em linguagens orientadas a objeto. O Schema RDF define uma linguagem de modelagem de domínio similar a linguagens orientadas a objetos. RDF é útil para muitos propósitos, porém em alguns domínios a expressividade do Schema RDF é insuficiente. Por exemplo, RDF não pode expressar restrições de cardinalidade, desta forma, no grafo RDF ilustrado na Figura 2.3, um tipo Person pode ter somente um mailbox. Devido as restrições de RDF e do Schema RDF, eles não são suficientes para implementar a Web semântica. Desta forma, algumas linguagens, dentre elas a OWL, estenderam o Schema RDF e adicionaram mecanismos para expressar mais informações a respeito de características das propriedades, classes e relações entre classes Ontologia Ontologia é um modelo de dados que representa um conjunto de conceitos e os relacionamentos entre estes dentro de um domínio. Normalmente é criado a partir do conhecimento de especialistas do domínio e é usado para realizar inferência sobre os indivíduos, classes, atributos e relacionamentos deste domínio. Para (Bruijn [de Bruijn, 2003] apud Uschold [Uschold and Grüninger, 1996]): as ontologias fornecem uma maneira uniforme para a especificação de conceitos chave ou fundamentais, bem como uma quantidade arbitrária de subconceitos e fatos, em conjunto permitindo o compartilhamento e reutilização de conhecimento contextual em um sistema de computação. Assim, uma ontologia define um vocabulário comum para pesquisadores que compartilham informações em um domínio, propicia o reuso do conhecimento deste domínio além de explicitar hipóteses e separar o conhecimento do domínio do conhecimento operacional [Natalya Fridman Noy, 2001, Tiago Semprebom and Mendonça, 2007]. Segundo Clark [Clark, 1999], ontologia é a materialização do nível do conhecimento. O uso de ontologias é mais visível em aplicações de inteligência artificial, enge-

29 2.2 Web Semântica 25 nharia de software e sistemas de informação, porém ela pode ser utilizada em qualquer aplicação que necessite representar e estruturar conhecimento ou a interoperabilidade entre sistemas incompatíveis como, por exemplo, na integração de bases de dados heterogêneas, uma vez que as ontologias não tem dependência com os modelos de dados. Ontologias são especificadas em linguagens expressivas e com semântica bem definida, passíveis de inferência. A W3C (World Wide Web Consortium) desenvolve um conjunto de linguagens que têm como objetivo principal promover a interoperabilidade entre aplicações na Web. Dentre essas linguagens a OWL (Web Ontology Language) é utilizada para representar ontologias na Web OWL OWL (Web Ontology Language) [Dean and Schreiber, 2004] é uma linguagem baseada nas linguagens DAML (DARPA Agent Markup Language) e OIL (Ontology Inference Layer ou Ontology Interchange Language) e surgiu dos esforços da união de dois grupos. A linguagem OIL é uma evolução da RDF e foi desenvolvida por um grupo Europeu, no escopo do projeto IST OntoKnowledge. A linguagem DAML é uma extensão da RDF e foi desenvolvido por um grupo nos Estados Unidos, financiado pela US Defense Advanced Research Projects Agency. OWL subdivide-se em três linguagens ou dialetos que se diferem pelo nível de expressividade que representam, conforme a Figura 2.4 ilustra. A OWL-Lite é a linguagem menos expressiva e destina-se as situações em que apenas são necessárias restrições e uma hierarquia de classes simples. A OWL-Full é a mais expressiva e apropriada para situações onde alta expressividade é mais importante do que garantir a decidibilidade ou completeza da linguagem, pois não é possível realizar inferências. A expressividade da OWL-DL está entre as duas, ela é baseada em lógica descritiva, um fragmento de Lógica de Primeira Ordem, passível, portanto de raciocínio automático [Horridge et al., 2004]. Figura 2.4: Dialetos da OWL A OWL-DL é constituída de três elementos básicos:

30 2.2 Web Semântica 26 Indivíduos representam objetos no domínio de interesse. São instâncias de uma determinada classe; Propriedades são relações binárias entre os indivíduos do domínio de interesse. As propriedades especificam características das classes e podem possuir capacidades lógicas tal como transitividade, simetria, inversão e funcional. Classes são conjuntos que contêm os indivíduos e são construídas a partir de descrições, as quais especificam as condições que devem ser satisfeitas por um individuo para que ele possa ser um membro da classe. As propriedades podem ser do tipo Object Properties, DataType Properties e Annotation Property. Propriedades do tipo Object Properties conectam um indivíduo a outro indivíduo, as propriedades DataType Properties definem uma relação entre um indivíduo e um tipo de dado definido em um Schema XML ou a um literal definido no Schema RDF. As propriedades Annotation Property associam um indivíduo a um valor específico. Um documento OWL inicia-se com a declaração do seu cabeçalho. O cabeçalho é delimitado pelo elemento <owl:ontology> e especifica algumas informações a respeito do autor e a versão do documento. O trecho de Código 2.2 demonstra a sintaxe de um cabeçalho OWL. Código 2.2 Declaração do cabeçalho de um documento OWL 1 <?xml version="1.0"?> 10 2 <rdf:rdf 3 xmlns:rdf=" 4 xmlns=" 5 xmlns:owl=" 6 xmlns:dc=" 7 xmlns:xsd=" 8 xmlns:rdfs=" 9 xml:base=" 11 <owl:ontology rdf:about=""> 12 <rdfs:comment rdf:datatype=" 13 Comentario</rdfs:comment> 14 <dc:creator rdf:datatype=" 15 Autor</dc:creator> 16 </owl:ontology> </rdf:rdf>

31 2.2 Web Semântica 27 Para efeito de ilustração considere duas classes OWL, Regime e Change, que estão associadas por uma propriedade do tipo Object Property, chamada hasregime. A Figura 2.5 ilustra este caso. Figura 2.5: Relação entre classes OWL O Código 2.3 ilustra a declaração da classe Regime, de uma propriedade do tipo Object Property que tem como domínio instâncias da classe Change e valores possíveis instâncias da classe Regime. Também é possível visualizar a definição das propriedades stemsize, burdenvalue, cpmvalue e idregime, todas do tipo Datatype Property.

32 2.2 Web Semântica 28 Código 2.3 Declaração de uma classe e suas propriedades em OWL <owl:class rdf:id="regime"/> 4 5 <owl:objectproperty rdf:id="hasregime"> 6 <rdfs:domain rdf:resource="#change"/> 7 <rdfs:range rdf:resource="#regime"/> 8 </owl:objectproperty> 9 10 <owl:datatypeproperty rdf:id="stemsize"> 11 <rdfs:range rdf:resource=" 12 <rdfs:domain rdf:resource="#regime"/> 13 </owl:datatypeproperty> 14 <owl:datatypeproperty rdf:id="burdenvalue"> 15 <rdfs:range rdf:resource=" 16 <rdfs:domain rdf:resource="#regime"/> 17 </owl:datatypeproperty> 18 <owl:datatypeproperty rdf:id="cpmvalue"> 19 <rdfs:domain rdf:resource="#regime"/> 20 <rdfs:range rdf:resource=" 21 </owl:datatypeproperty> 22 <owl:datatypeproperty rdf:id="idregime"> 23 <rdfs:domain rdf:resource="#regime"/> 24 <rdfs:range rdf:resource=" 25 </owl:datatypeproperty> O Código 2.4 ilustra a declaração de uma instância da classe Regime. Esta instância é identificada por Regime_5.

33 2.3 OWL-S 29 Código 2.4 Instância da classe Regime <Regime rdf:id="regime_5"> 3 <stemsize rdf:datatype=" 4 25</stemSize> 5 <burdenvalue rdf:datatype=" 6 59</burdenValue> 7 <idregime rdf:datatype=" 8 5</idRegime> 9 <cpmvalue rdf:datatype=" </cpmValue> 11 </Regime> Serviços Web Semânticos Os serviços Web utilizam mensagens SOAP para se comunicarem com os clientes. As mensagens SOAP são documentos XML descritos por Schemas XML e encapsulam os inputs e outputs das operações do serviço Web. Entretanto, no nível semântico, os inputs e outputs de um serviço Web são descritos utilizando-se ontologias. Desta forma, um cliente de um serviço Web semântico precisa obter informações que descrevem como um determinado dado pode ser escrito em um documento XML que será enviado para o serviço e como um documento XML, advindo do serviço Web semântico, que pode ser interpretado semanticamente. Os serviços Web semânticos utilizam ontologias para descrever seus serviços. Neste sentido, os mecanismos oferecidos pela OWL para criação de ontologias, podem ser reutilizados para os serviços Web. Desta forma, a linguagem OWL-S utiliza os mecanismos da OWL e adicionam outros, como por exemplo, um conjunto de conceitos para descrição de serviços, para formar um framework que permite a inserção de semântica aos serviços Web de forma a tornar possível o descobrimento, execução e composição de serviços. OWL-S consiste de três subontologias conhecidas por Serviceprofile, ServiceModel e ServiceGrounding. 2.3 OWL-S OWL-S é uma ontologia baseada em OWL para descrever semanticamente serviços Web, permitindo aos usuários e agentes de software automaticamente descobrir, invocar, compor e monitorar os recursos da Web que oferecem serviços, sob restrições

34 2.3 OWL-S 30 especificadas, por intermédio de uma descrição formal das suas propriedades e capacidades [Burstein et al., 2004]. O último release da especificação OWL-S é a versão 1.2, de dezembro de Entretanto, este documento apresenta a versão 1.1 que é compatível com o WSDL 1.1, usado neste trabalho. A ontologia OWL-S consiste de três inter subontologias, ServiceProfile, ServiceModel e ServiceGrounding. A ontologia ServiceProfile é usada para expressar o que o serviço faz, para fi ns de publicidade, construção de requisições do serviço, e matchmaking 2 ; a ontologia ServiceModel descreve como funciona, para permitir a invocação, a criação, composição, monitoramento e recuperação; e, por fi m, a ontologia ServiceGrounding define os mapeamentos entre as construções da ontologia ServiceModel com as especificações detalhadas dos formatos de mensagens, protocolos, entre outros, expressos no arquivo WSDL. A ontologia ServiceGrounding pode ser vista como a cola entre as descrições semântica (ontologia) e sintática (WSDL) [Davies et al., 2006]. Todas as subontologias estão ligados ao conceito de nível superior Service, que serve como um ponto de referência organizacional para declarar serviços Web e sempre que um serviço é declarado, uma instância do conceito de Service é criada. A Figura 2.6 ilustra a relação entre as subontologias e as propriedades presents, describedby, e supports de Service. Figura 2.6: Subontologias da OWL-S - extraído de [Burstein et al., 2004] Cada instância de Service apresenta (presents) uma descrição ServiceProfi le, é descrita (describedby) pela subontologia ServiceModel e suporta (supports) uma descrição ServiceGrounding. 2 Processo de busca dos possíveis casamentos entre demandas/requisições e ofertas/serviços, em um dado domínio de aplicação.

35 2.3 OWL-S Service Profile Na subontolgia ServiceProfile a classe ServiceProfile é uma superclasse para todos os tipos de descrições em alto nível a respeito do serviço. Esta classe contém as informações básicas necessárias para vincular qualquer instância de Profile, uma subclasse da subontologia ServiceProfile, com uma instância de Service. O serviço, definido através de Profile, é modelado em termos de três tipos de informações, detalhados em seguida: As informações da organização que provê o serviço, constituindo-se de informações de contato que se refere à entidade que fornece o serviço. Por exemplo, informações de contato podem se referir ao operador de manutenção, que é responsável pela execução do serviço, ou para um representante do cliente que podem fornecer informações adicionais sobre o serviço [Burstein et al., 2004]. A descrição da funcionalidade do serviço é expressa em termos da transformação produzida pelo serviço. A descrição funcional inclui as entradas (inputs) requeridas pelo serviço e as saídas (outputs) geradas; as pré-condições (precondition) requisitadas pelos serviços e os efeitos (effects) esperados da execução do serviço. Por exemplo, um serviço de vendas pode exigir como pré-condição (precondition) um cartão de crédito válido e como entrada (input) o número do cartão de crédito e data de validade. Como saída (output) ele gera um recibo, e como efeito (effect) o cartão é debitado [Burstein et al., 2004]. O primeiro tipo de informação especifica a categoria de um determinado serviço, por exemplo, a categoria do serviço dentro do sistema de classificação de produtos e serviços para uso em ecommerce. O segundo tipo de informação é a classificação da qualidade do serviço, por exemplo, bom, ruim, tempo de resposta rápido, confiável, taxa de atualização pequena. O último tipo de informação é uma lista de parâmetros do serviço que pode conter qualquer tipo de informação, por exemplo, parâmetros que fornecem uma estimativa do tempo de resposta máximo, a disponibilidade geográfica de um serviço [Burstein et al., 2004]. A classe Profile fornece um mecanismo para representar tais parâmetros. As informações que especificam as características do serviço podem ser úteis em situações em que o solicitante do serviço pretende verificar a qualidade do serviço. Um serviço pode ter suas informações publicadas em sistemas de classificação de forma que sua qualidade possa ser publicada. Neste caso, o solicitante do serviço pode usar essa informação, contida no sistema de classificação, para verificar se o serviço é útil ou não para a sua necessidade. A classe Profile contém a especificação de quais funcionalidades o serviço oferece e as condições que devem ser satisfeitas para sua execução. As funcionalidades e

36 2.3 OWL-S 32 as condições são representadas a partir de dois aspectos do serviço: a transformação da informação (representado por inputs e outputs); e a mudança de estado produzido pela execução do serviço (representado por preconditions e effects). Para exemplificar, considere o exemplo do cartão de crédito, agora aplicado a uma livraria virtual. Para concluir a venda, o serviço requer como entrada (input) o número do cartão de crédito e a data de validade, mas também a condição (precondition) de que o cartão de crédito é válido e tem crédito. O resultado da venda é a saída (output) de um recibo que confirma a boa execução da transação e como efeito (effect) o pagamento (transferência de propriedade) e a transferência física do livro a partir do armazém da livraria para o endereço do comprador [Burstein et al., 2004]. Nenhum esquema para descrever as instâncias dos Inputs/Outputs/Preconditions/Effects (IOPEs) é fornecido pela classe Profile. No entanto, este esquema existe na subontologia ProcessModel. Os IOPEs publicados pela classe Profile são um subconjunto daqueles publicados pela subontologia ProcessModel, assim, espera-se que a subontologia ProcessModel crie todas as instâncias IOPEs e a instância de Profile simplesmente aponte para essas instâncias de IOPEs. A Figura 2.7, ilustra as propriedades da classe Profile que são usadas para referenciar os IOPEs definidos na subontologia ServiceProfile. As seguintes propriedades são definidas: hasparameter varia ao longo de uma instância da classe Parameter da subontologia ServiceModel. Sua principal função é apenas tornar o conhecimento de domínio explícito. A classe Parameter modela a intuição de que inputs e outputs - que são os tipos de parâmetros - estão ambos envolvidos na transformação da informação e, portanto, são diferentes das preconditions e effects. Como consequência, a classe Parameter não é instanciada. hasinput varia sobre instâncias da classe Inputs, definida na subontologia ServiceModel. hasoutput define instâncias da classe Output, da subontologia ServiceModel. hasprecondition especifica uma das pré-condições do serviço e varia ao longo de instâncias da classe Preconditions, definida de acordo com o esquema na subontologia ServiceModel. hasresult especifica um dos resultados do serviço, conforme definido pela classe Result da subontologia ServiceModel. Esta propriedade especifica as condições em que as saídas (outputs) são geradas. Além disso, a classe Result especifica quais as mudanças de domínio são produzidos depois da execução do serviço.

37 2.3 OWL-S 33 Figura 2.7: OWL-S Service Profile - extraído de [Burstein et al., 2004] Complementarmente as informações de IOPEs, algumas propriedades da classe Profi lefornecem informação legíveis aos humanos que são pouco prováveis que sejam processadas automaticamente. São elas: servicename refere-se ao nome do serviço que está sendo oferecido. Pode ser usado como um identifi cador do serviço. textdescription fornece uma breve descrição do serviço. Ele resume o que o serviço oferece, descreve o que o serviço requer para funcionar, e indica qualquer informação adicional que se queira compartilhar com os usuários. contactinformation fornece um mecanismo para indicar os indivíduos responsáveis pelo serviço. Uma instância da classe Profi le pode ter no máximo um nome de serviço e uma descrição em texto, mas pode ter várias propriedades de informações de contato. Conforme ilustrado na Figura 2.7, a propriedade contactinformation está relacionada a classe Actor, defi nida na ontologiaactordefault Service Model A subontologia ServiceProfile descreve apenas o funcionamento global do serviço provido. Uma perspectiva detalhada sobre como interagir com o serviço é provido pela classe Process, uma subclasse de ServiceModel. Para efeito de entendimento, uma instância de Process pode ser visto como um processo que defi ne a interação com

38 2.3 OWL-S 34 o serviço Web. Em OWL-S, processos não são necessariamente programas a serem executados, mas sim uma especificação das maneiras que um cliente pode interagir com um serviço. Qualquer processo pode ter qualquer número de entradas (inputs), representando as informações que estão sob certas condições (preconditions), necessárias para iniciar o processo. Processos podem ter qualquer número de saídas (outputs), a informação de que o processo fornece ao solicitante. Inputs e Outputs são representados como subclasses da classe Parameter. Apesar da Figura 2.8 não ilustrar a relação entre Input, Output e Parameter, cada Parameter tem um tipo, especificado usando um URI. Pode existir qualquer número de preconditions, que devem ser satisfeitas para que um processo possa ser iniciado com êxito. Um processo pode ter qualquer número de effects. Outputs e effects dependem de condições acerca do estado do mundo no momento em que o processo é realizado. Preconditions e effects são representados como fórmulas lógicas e podem ser expressos com o uso de linguagens cujo padrão de codificação é XML, tais como SWRL (Semantic Web Rule Language) [Horrocks et al., 2004] e RDF [Manola and Miller, 2004], ou literais strings, tal como PDDL (The Planning Domain Defi nition Language) [Ghallab et al., 1998]. Figura 2.8: Subontologia OWL-S ServiceModel - extraído de [Burstein et al., 2004] Para conectar um processo, ou seja, uma instância da classe Process aos seus IOPEs, as seguintes propriedades são usadas: hasparticipant que associa instâncias da classe Participant. Um processo envolve pelo menos duas partes: theclient e theserver. Se existem outros, então eles são listados usando-se a propriedade hasparticipant.

39 2.3 OWL-S 35 hasinput especifica as instâncias da classe Input. Um Input especifica a informação que o processo requer para sua execução. Ele pode vir diretamente do usuário ou de uma etapa anterior da execução do processo. No último caso, quando o processo é composto de outros processos, ou seja, uma composição de serviços. hasoutput especifica instâncias da classe Output. Um Output especifica a informação que o processo gera após sua execução. hasexistential Existential é uma variável usada para ser agregada na definição de preconditions e depois ser utilizado para especificar resultados condicionais, effects. hasprecondition define uma expressão que deve ser satisfeita para que o processo possa ser executado. hasresult a execução do processo pode ter algum effects e, provavelmente, outputs. Result associa effects e outputs diretamente ao processo. WSDL permite a especificação de operações como blocos básicos de construção do serviço Web. As operações provêm a estrutura organizacional onde os padrões e a sintaxe das mensagens de input e output são especificadas. OWL-S provê uma construção análoga, porém mais abstrata conhecida por Atomic Process, que é caracterizada principalmente em termos dos IOPEs [Martin et al., 2004]. OWL-S define três tipos de processos: Atomic Process é um processo que pode ser visto como uma descrição de um serviço que espera uma mensagem e retorna outra mensagem de resposta. É diretamente invocável e não contém nenhum subprocesso. Um Atomic Process recebe um input, faz algum processamento, e depois retornar o output. Para cada Atomic Process deve existir um grounding (apresentado na seção 2.3.3) que permita a um solicitante do serviço codificar as mensagens para o processo a partir de seus inputs e decodificar os outputs. Composite Process é um processo que define a descrição de uma composição de serviços. Esta composição mantém algum estado e cada mensagem que o cliente envia é passada para os processos da composição. Corresponde a ações que exigem várias interações com servidores. Um Composite Process é composto por outros processos, Atomic ou Composite, que são especificados a partir de estruturas de controle - Sequence, Split, Split + Join, Choice, Any-Order, If-Then-Else, Iterate e Repeat- While. Simple Process é um processo que fornece um mecanismo de abstração para prover múltiplas visões do mesmo processo. Ele não é invocável e não está associado a nenhum elemento Grounding.

40 2.3 OWL-S Service Grounding As subontologias ServiceProfile e ServiceModel descrevem o que o serviço faz, ou seja, suas capacidades. Porém, para tornar possível que clientes comuniquem-se com serviços Web, é necessário descrever a interface do serviço Web. A interface de um serviço Web é especificada em um arquivo WSDL que descreve as mensagens e algumas especificidades do protocolo da camada de aplicação usado para comunicação. WSDL modela a interface do serviço como um conjunto de operações e suas mensagens associadas. O conteúdo das mensagens são especificadas de forma abstrata, como declarações de elementos de um Schema XML. Um serviço Web Semântico modela suas operações como entidades que trocam dados semânticos. Estes dados semânticos são serializados em mensagens XML e transportados pela rede encapsulados em protocolo de aplicação. A subontologia ServiceGrounding fornece os meios para representar os dados semânticos como mensagens XML que são enviadas pela rede e também especifica como o receptor pode interpretar essas mensagem XML e transformá-las novamente para os dados semânticos. Grounding é um termo em inglês, amplamente utilizado e que não há uma tradução para o português fidedigna e, portanto, optamos por manter o termo em inglês. O grounding de um serviço Web especifica os detalhes de como acessá-lo, isto é, os detalhes do protocolo e formatos de mensagens, serialização, transporte e endereçamento. O grounding pode ser visto como um mapeamento da especificação abstrata para uma concreta dos elementos que compões a descrição do serviço que são necessários para interagir com o serviço - em particular, os inputs e outputs de processos do tipo Atomic Process. Isto porque as subontologias ServiceProfile e ServiceModel são representações abstratas, somente ServiceGrounding lida com o nível concreto da especificação [Burstein et al., 2004]. O conceito de grounding em OWL-S assemelha-se ao conceito de binding em WSDL [Burstein et al., 2004]. Juntos, estes conceitos fornecem a especificação do grounding OWL-S/WSDL porque OWL-S e WSDL não fazem parte do mesmo espaço conceptual, mas são complementares. Os tipos abstratos (abstract types - ver apêndice B), são elementos do WSDL especificados com uso de Schemas XML e usados para caracterizar os inputs e outputs dos serviços Web. Em OWL-S a definição de abstract types é feita como classes OWL. No entanto, WSDL é incapaz de expressar a semântica de uma classe OWL. Da mesma forma, OWL-S não tem meios para expressar algumas informações do WSDL, por exemplo, as informações referentes ao binding. Assim, o grounding OWL-S/WSDL usa classes OWL como os abstract types de partes das mensagens declaradas no arquivo WSDL e se baseia nas construções de binding do WSDL para especificar a formatação das mensagens.

41 2.3 OWL-S 37 Conforme a Figura 2.9 ilustra, o grounding OWL-S/WSDL é baseado em três correspondências entre OWL-S e WSDL: Figura 2.9: Grounding OWL-S/WSDL - extraído de [Burstein et al., 2004] 1. Um processo do tipo Atomic Process pode corresponder aos seguintes tipos de operações (operation) descritas no arquivo WSDL: Um processo do tipo Atomic Process com inputs e outputs corresponde a uma operação do tipo request-response. Um processo do tipo Atomic Process com inputs, mas sem outputs corresponde a uma operação do tipo one-way. Um processo do tipo Atomic Process com outputs, mas sem inputs corresponde a uma operação do tipo notifi cation. Um processo do tipo Composite Process com inputs e outputs sendo que os outputs são enviados antes da recepção dos inputs, corresponde a uma operação do tipo solicit-response 2. Os inputs e outputs de um processo do tipo Atomic Process correspondem as mensagens especificadas no arquivo WSDL. Os inputs OWL-S correspondem às partes de uma mensagem (message part) de entrada (input message) de uma operação (operation) do WSDL e os outpust OWL-S correspondem às partes de uma mensagem (message part) de saída (output message) de uma operação (operation) do WSDL. 3. Os tipos, ou seja, as classes OWL dos inputs e outputs de um Atomic Process correspondem a noção extensível WSDL de abstract types. A Figura 2.10 apresenta as principais classes e propriedades da subontologia ServiceGrounding.

42 2.3 OWL-S 38 Figura 2.10: Classes e propriedades da subontologia OWL-S ServiceGrounding A classe WsdlGrounding é uma subclasse de ServiceGrounding. Seu papel é fornece um mecanismo para que as principais construções do arquivo WSDL possam ser referenciadas em OWL-S. Cada instância da classe WsdlGrounding contém uma lista de instâncias de WsdlAtomicProcessGrounding. Essa relação é representada pela propriedade hasatomicprocessgrounding. A propriedade owlsprocess garante que para cada processo do tipo AtomicProcess exista somente um WsdlAtomicProcessGrounding. Por outro lado a propriedade wsdloperation assegura uma relação um-para-um entre o Atomic Process e a especificação WSDL. WsdlMessageMap é uma superclasse para WsdlInputMessage- Map e WsdlOutputMessageMap. WsdlAtomicProcessGrounding utiliza, basicamente, as seguintes propriedades para referenciar elementos de Atomic Process com a especifi cação WSDL: wsdlversion um URI que indica a versão do WSDL utilizado. A versão 1.1 da OWL-S é compatível com a versão 1.1 da WSDL enquanto que OWL-S, a versão mais atual, é compatível com WSDL 1.2. Esta propriedade não aparece na Figura 2.10, pois ela não relaciona a nenhuma outra classe, ela relaciona com um tipo URI especificado no XML Schema. wsdldocument um URI que indica o documento WSDL ao qual o grounding se refere. Esta propriedade não é essencial e seu uso é basicamente para documentação. É um tipo URI especificado no Schema XML. wsdloperation é o URI para a operação (operation) especificada no arquivo WSDL ao qual o Atomic Process corresponde. O valor de wsdloperation pode ou não identi-

43 2.3 OWL-S 39 ficar um Port 3 específico, definido no WSDL. Se houver vários Ports para a mesma operação (operation), o engine OWL-S pode escolher qualquer um Port. Para restringir os Ports que podem ser utilizadas para um WsdlAtomicProcessGrounding é necessário especificá-los utilizando as propriedades wsdlservice e/ou wsdlport. wsdlservice é um URI para o elemento Service do WSDL que provê a operação (operation) com o qual o Atomic Process está associado. Vale ressaltar que um elemento Service do WSDL é uma coleção de EndPoints. wsdlport um URI para o elemento Port do WSDL que provê a operação (operation) com o qual o Atomic Process está associado. Um Port é endpoint definido como uma combinação de um binding e um endereço. wsdlinputmessage um URI para o elemento input message da especificação WSDL que corresponde aos inputs do Atomic Process. wsdlinput esta propriedade é utilizada para definir a correspondência entre os inputs OWL-S e Message Parts do WSDL. Para cada Message Parts de um input message declarado no WSDL, deve existir uma propriedade wsdlinput. Conforme a Figura 2.10 ilustra, a propriedade wsdlinput associa uma instância de wsdlatomicprocessgrounding a uma instância da classe wsdlinputmessagemap que contém o mapeamento. A instância de wsdlinputmessagemap contém a propriedade wsdlmessagepart que, com um URI identifica a Message Part do WSDL associado e, também a propriedade owlsparameter ou xslttransformation. Ambas representam como derivar a Message Part de um ou mais inputs do Atomic Process. owlsparameter é utilizado para o caso mais simples, quando existe uma correspondência direta entre o input do Atomic Process e o wsdlmessagepart. Isto significa que o Message Part WSDL corresponde diretamente ao input e o tipo do input é usado na especificação do WSDL. Basta colocar o URI do input na propriedade. xslttransformation é utilizado para os outros casos em que a propriedade owlsparameter não se aplica. A propriedade xslttransformation adiciona um script XSLT que gera o Message Part de uma instância de um Atomic Process. O script pode ser diretamente representado como uma string ou pode ser referenciado por um URI. wsdloutputmessage similar à propriedade wsdlinputmessage porém, aplicada aos outputs. wsdloutput Para cada output do Atomic Process deve existir um valor da propriedade wsdloutput. É similar à propriedade wsdlinput porém, aplicados a outputs. Ela 3 Port define o ponto de conexão (EndPoint) com um serviço Web.

44 2.4 Desenvolvimento de Software Dirigido por Modelos 40 especifica um mapeamento entre um output de Atomic Process, que é representado pela instância de WsdlOutputMessageMap. 2.4 Desenvolvimento de Software Dirigido por Modelos O Desenvolvimento de Software Dirigido por Modelos (Model Driven Development - MDD) [Stahl and Völter, 2006] é uma abordagem top-down de desenvolvimento de software que tem como essência a especificação de modelos e transformações desses modelos em outros modelos ou artefatos de software, de forma a permitir a comunicação de diferentes fases do desenvolvimento de software. Os modelos são utilizados como veículos para descrição de sistemas de software, facilitando a comunicação entre as partes do sistema e, também, associando as diferentes fases do processo de desenvolvimento de software. Segundo Stahl e Voelter [Stahl and Völter, 2006], as principais características do MDD são: alta produtividade, portabilidade, interoperabilidade e reusabilidade. Além disso, o MDD permite que as transformações entre modelos possam ser realizadas por ferramentas automatizadas, as quais reduzem os erros de programação e os custos de desenvolvimento. As transformações entre os modelos MDD são especificadas em linguagens que possuem uma sintaxe textual concreta e utilizam metamodelos para criar regras de transformações entre os modelos. Os modelos são descritos por metamodelos e representados normalmente com o padrão XMI (XML Metadata Interchange) [Object Management Group, 2007]. A Figura 2.11 ilustra o contexto em que essas linguagens estão inseridas. Figura 2.11: Transformações entre modelos

45 2.4 Desenvolvimento de Software Dirigido por Modelos 41 O metamodelo representa a sintaxe abstrata da linguagem e descreve todos os conceitos que podem ser utilizados em um modelo. O metamodelo deve estar em conformidade com o seu metametamodelo. O MOF (OMG s MetaObject Facility) [Object Management Group, 2006], é uma especificação definida como um padrão da OMG. O Ecore [Steinberg et al., 2008], introduzido com o Eclipse Modelling Framework (EMF) [Steinberg et al., 2008], é uma implementação da especificação MOF. QVT (Query/View/Transformation) [Object Management Group, 2008] é uma linguagem padronizada pela OMG e tem como principal objetivo transformar um modelo de entrada, que está em conformidade com um metamodelo, em outro modelo de saída, em conformidade com outro metamodelo. O trecho de Código 2.5 apresenta o código em QVT de uma transformação chamada de MMaToMMb entre dois modelos, Ma e Mb. O modelo Ma tem como metamodelo MMa enquanto que o metamodelo do modelo Mb é MMb. Na transformação MMaToMMb a instrução Ma.rootObjects![A] (linha 3) associa o conjunto de todos os elementos A do modelo Ma a variável a. A linha 6 declara um função de mapeamento chamada AtoB que recebe como entrada um elemento A e cria um elemento B. Na função de mapeamento é possível acessar as propriedades e relações do elemento de entrada A. Desta forma, possibilitando a criação do elemento B utilizando-se os valores das propriedades ou relações de A. Assim, na linha 4, a instrução a.map AtoB() especifica que o elemento A, referenciado pela variável a, será entrada para a função de mapeamento AtoB. Código 2.5 Exemplo de uma transformação QVT 1 transformation MMaToMMb(in Ma : MMa, out Mb : MMb); 2 main() { 3 var a := Ma.rootObjects![A]; 4 a.map AtoB(); 5 } 6 mapping A::AtoB() : B { } O objetivo do MDD, muitas vezes, é a criação de código fonte em uma linguagem alvo como, por exemplo, Java, C++ ou XML. A especificação Model-to-text, padronizada pela OMG, determina um padrão para linguagens de transformação de modelo para texto. O Acceleo [Obeo Network, 2007] é um gerador de código livre que implementa a especificação Model-to-text e utiliza uma abordagem baseada em templates para criação de código fonte em uma determinada linguagem a partir de modelos.

46 2.4 Desenvolvimento de Software Dirigido por Modelos 42 O Eclipse Modeling Framework (EMF) é um framework de modelagem e geração de código que compõe o projeto Eclipse Modeling. O EMF consiste de três pedaços fundamentais: O framework Core EMF Ecore que tem como propósito a criação de metamodelos; o framework EMF.Edit que inclui classes genéricas reusáveis para construção de editores para modelos EMF; e o EMF.Codegen que é um gerador de código capaz de gerar os artefatos necessários para construção de um editor completo para um modelo EMF.

47 Mapeamento entre OWL e UML CAPÍTULO 3 Este capítulo apresenta a similaridade entre as linguagens de especificação de ontologias e a linguagem de modelagem UML. A linguagem de modelagem UML é amplamente usada para modelagem de sistemas de software e também para criação de modelos em abordagens MDD. A linguagem UML e as linguagens de especificação de ontologias têm algumas sobreposições e semelhanças, especialmente para representação estrutural de um software. Alguns elementos das duas linguagens são semelhantes como, por exemplo, classes, associações entre classes, propriedades de classes, generalizações e tipos de dados. Estas semelhanças tornam possível o mapeamento de alguns elementos das linguagens de especificação de ontologias em elementos da linguagem UML. Outros elementos das linguagens de especificação de ontologias que não correspondem diretamente aos elementos primários da linguagem UML podem ser representados com o uso de perfis UML. As similaridades entre essas linguagens são fundamentais para a especificação do perfil UML que a ferramenta AutoWebS usa. O restante deste capítulo está organizado como se segue. A seção 3.1 apresenta o mapeamento entre as linguagens de especificação de ontologias e a UML. A seção 3.2 mostra os elementos da linguagem OWL que são diretamente usados e, portanto, necessários para criação de serviços Web semânticos, apresentando como esses elementos podem ser representados com elementos da UML. 3.1 Mapeamento entre as linguagens de especificação de ontologias e a UML As linguagens de especificação de ontologias como, por exemplo, a linguagem OWL, e a linguagem UML têm propósitos diferentes, que refletem nos seus elementos e nas suas expressividades. Modelos UML e ontologias constituem abordagens de modelagem com diferentes propósitos, que os tornam adequados para especificar aspectos diferentes de sistemas de software. Em particular, ontologias são adequadas para especificar classes usando uma linguagem lógica expressiva, com associação de clas-

48 3.1 Mapeamento entre as linguagens de especificação de ontologias e a UML 44 ses e definição de propriedades altamente flexíveis e polimórficas, enquanto diagramas UML são mais adequados para especificar não apenas modelos estáticos, incluindo classes e associações, mas também o comportamento dinâmico de sistemas de software [Silva Parreiras et al., 2007]. A linguagem UML define uma notação para a modelagem dos artefatos de software orientado a objetos, enquanto que as linguagens de especificação de ontologias definem uma notação para representação de conhecimento, mas ambas são linguagens de modelagem [Belghiat and Bourahla, 2012]. O mapeamento das construções das linguagens UML e de especificação de ontologias é possível graças a essas similaridades entre as linguagens [Pondrelli, 2005, Hart et al., 2004, Atkinson et al., 2006, Gasevic et al., 2006]. Pondrelli [Pondrelli, 2005], em seu trabalho, explana a respeito da viabilidade de usar métodos baseados em perfis UML e editores UML para construção e gerenciamento de ontologias, além de apresentar os mapeamentos entre a UML e as principais construções utilizadas por linguagens de especificação de ontologias, conforme representado na Tabela 3.1. UML Packages Classes Attributes, associations and classes Navigable Note Multiplicity Data types Objects Construções ontológicas Ontologies Classes Properties Domain, Range Comment Cardinality Data types Instances Tabela 3.1: Mapeamento entre UML e os principais conceitos das linguagens para especificação de ontologias No mapeamento entre a UML e uma linguagem de especificação de ontologias, a definição de ontologias assemelha-se a definição de um package em UML. Uma ontologia cria um modelo de dados que representa um conjunto de conceitos e seus relacionamentos dentro de um domínio. Os conceitos podem ser representados por classes UML e as propriedades que uma classe pode ter especificam suas características e criam relações entre os conceitos do domínio de interesse. Conforme a Tabela 3.1, as construções das linguagens de especificação de ontologias Domain e Range, Comment, Cardinality, Data Type e Instances são diretamente mapeadas para os elementos da UML. As construções que especificam propriedades (Properties) em uma ontologia podem ter múltiplas representações em UML devido a grande expressividade das linguagens de especificação de ontologias. Por exemplo, na linguagem OWL as propriedades que especificam restrições (Restriction) do tipo intersectionof, unionof e complementof, são construções para formação de uma classe a partir de uma combinação boole-

49 3.1 Mapeamento entre as linguagens de especificação de ontologias e a UML 45 ana de classes OWL. Na UML, não existem notações correspondentes as restrições do tipo intersectionof, unionof e complementof. Uma alternativa para as representações em UML de construtores de classe OWL é o emprego de estereótipos e dependências UML para as classes que formam o complemento (complementof ), parte da união (unionof ) ou parte do cruzamento (intersectionof ) de uma classe. Seguindo a abordagem de perfis UML, a OMG criou a especificação Ontology Definition MetaModel (ODM) [Object Management Group, 2009], uma especificação para tornar os conceitos da Arquitetura Dirigida a Modelos (Model-Driven Architecture - MDA) [Frankel, 2003] aplicáveis à engenharia de ontologias. A especificação ODM define uma família de metamodelos independentes, perfis UML relacionados e mapeamentos entre os metamodelos correspondentes a vários padrões para definição de ontologias. A especificação ODM é aplicável a representação do conhecimento, modelagem conceitual e a definição de ontologias. ODM é implementado em MOF e contém uma especificação formal para perfis UML e para as linguagens OWL e RDFS. A ODM é uma alternativa viável para se criar ontologias e várias ferramentas [Silva Parreiras et al., 2007, Sparx Systems, 2000, Brockmans et al., 2006, Belghiat and Bourahla, 2012, Gaševic et al., 2009] fazem uso da especificação a fim de se prover abstração sobre as linguagens de especificação de ontologias. Para especificar a interface de um serviço Web semântico, ou seja, definir os inputs e outputs do serviço Web e associá-los a conceitos definidos em uma ontologia, é necessário um subconjunto dos elementos da linguagem OWL. Outros elementos da OWL, principalmente a parte axiomática, não são diretamente usados na especificação da interface de um serviço Web semântico, porém esses elementos, normalmente, são usados por máquinas de inferência 1 (reasoners) que provêem mecanismos que permitem verificar a consistência de ontologias e validar a classificação de seus conceitos assim, permitindo que ferramentas que fazem matching, possam realizar buscas com base nos inputs e outputs de um serviço Web semântico. Os elementos que não são diretamente usados na especificação da interface de um serviço Web semântico podem fazer parte de uma ontologia do serviço Web entretanto, estes elementos não podem ser associados aos inputs e outputs de um serviço Web, mas eles podem fornecer restrições importantes ao domínio do serviço Web como, por exemplo, definir relações entre propriedades e conceitos que podem facilitar o processo de desambiguação semântica. Este trabalho especifica e implementamos um perfil UML para representar os elementos da linguagem OWL que são usados no processo de modelagem da interface de um serviço Web semântico. O perfil UML define um conjunto de estereótipos e 1 São sistemas de representação de conhecimento capazes de realizar consultas sobre as ontologias de modo a deduzir novas informações, geralmente implícitas, a respeito de um domínio preexistente.

50 3.2 Mapeamento entre OWL e UML 46 propriedades que habilitam a associação dos inputs e outputs de um serviço Web com conceitos definidos em uma ontologia. No perfil UML também são definidos estereótipos e propriedades do domínio dos serviços Web, que não são endereçados pela especificação ODM. O propósito da ferramenta AutoWebS não é propiciar a modelagem de ontologias usando-se a UML, como se propõe a especificação ODM. O propósito da ferramenta AutoWebS é proporcionar a modelagem da interface de um serviço Web semântico. 3.2 Mapeamento entre OWL e UML Kim e Lee [Kim and Lee, 2007, Kim and Lee, 2009] e Falkovych et al. [Falkovych et al., 2003] apresentam uma série de transformações entre as construções da linguagem OWL e a UML que serviram como base para especificação dos mapeamentos utilizados pela ferramenta AutoWebS. Não são todas as construções da linguagem OWL que são necessárias para criação da descrição semântica do serviço Web. Somente as construções da OWL que definem classes e subclasses, propriedades de objetos e tipos de dados são necessárias. Vale ressaltar que, o mapeamento entre a OWL e UML apresentado neste trabalho, não tem como objetivo representar todos os elementos da OWL em UML. São realizados os mapeamentos somente estre os elementos necessários para especificação de um serviço Web semântico. Os elementos da OWL que são mapeados para a UML são apresentados a seguir O elemento da OWL owl:ontology é mapeado para um package em UML. Os mapeamentos possíveis para os elementos que são declarados dentro de owl:ontology estão representados na Tabela 3.2. O elemento owl:imports associa uma ontologia a outra quando são usados conceitos definidos em outra ontologia. O mapeamento deste elemento dá-se pelo elemento UML package imports. Construções OWL UML owl:ontology package UML owl:ontology owl:versioninfo note UML owl:ontology rdfs:comment note UML owl:ontology owl:imports package imports UML Tabela 3.2: Mapeamento entre o elemento owl:ontology e a UML As construções usadas para criar classes ou que expressam relações hierárquicas entre classes OWL podem ser representadas por generalização em UML conforme a Tabela 3.3 monstra. A construção owl:oneof pode ser mapeada para um tipo Enumeration UML enquanto que a construção owl:unionof pode ser mapeada em UML como relações de dependências de uma classe sobre outras, usando-se o elemento Dependency da UML. Os demais elementos não se aplicam.

51 3.2 Mapeamento entre OWL e UML 47 Construções OWL owl:class owl:class rdf:id owl:class rdfs:subclassof owl:class owl:oneof owl:class owl:equivalentclass owl:class owl:disjointwith owl:class owl:intersectionof owl:class owl:unionof owl:class owl:complementof UML classe UML nome da classe Generalização de uma classe define um tipo Enumeration UML não se aplica não se aplica não se aplica Dependency UML não se aplica Tabela 3.3: Mapeamento entre as construções de classes OWL e a UML O elemento owl:restriction define as restrições que são aplicadas sobre uma classe OWL. As restrições podem estar associadas aos tipos de dados e as propriedades que uma determinada classe pode ter. O elemento owl:restriction também define qual é a cardinalidade das restrições aplicadas sobre uma classe. A Tabela 3.4 ilustra o mapeamento desta construção para os elementos da UML. Construções OWL owl:restriction owl:restriction owl:allvaluesfrom owl:restriction owl:somevaluesfrom owl:restriction owl:hasvalue owl:restriction owl:maxcardinality owl:restriction owl:mincardinality owl:restriction owl:cardinality UML restrições aplicadas em uma classe não se aplica não se aplica não se aplica multiplicidade multiplicidade cardinalidade Tabela 3.4: Mapeamento entre o elemento owl:restriction e a UML As propriedades que incidem sobre uma determinada classe OWL podem ser mapeadas para UML como atributos de uma classe a partir de uma associação binária ou unidirecional com outras classes. As propriedades owl:objectproperty rdfs:range e owl:datatypeproperty rdfs:range definem o tipo do atributo que incide em uma classe OWL. Os valores possíveis destes atributos são os tipos definidos no Schema XML ou as classes OWL. A Tabela 3.5 apresenta os mapeamentos para os elementos owl:objectproperty e owl:datatypeproperty. As demais construções da linguagem OWL, representadas na Tabela 3.6, não são aplicadas para especificação da interface de um serviço Web semântico. Na UML existem apenas quatro tipos primitivos predefinidos de dados: Integer, Boolean, String e UnlimitedNatural. O tipo UnlimitedNatural representa um elemento

52 3.2 Mapeamento entre OWL e UML 48 Construções OWL owl:objectproperty owl:objectproperty rdf:id owl:objectproperty rdfs:range owl:objectproperty rdfs:domain owl:objectproperty rdfs:subpropertyof owl:objectproperty owl:equivalentproperty owl:objectproperty owl:inverseof owl:datatypeproperty owl:datatypeproperty rdf:id owl:datatypeproperty rdfs:domain owl:datatypeproperty rdfs:range construções para indivíduos OWL UML atributo de uma classe nome do atributo tipo do atributo. classe que contém o atributo não se aplica não se aplica não se aplica atributo de uma classe nome do atributo classe que contém o atributo o tipo do atributo não se aplica Tabela 3.5: Mapeamento entre os elementos owl:objectproperty e owl:datatypeproperty e a UML Construções OWL owl:functionalproperty owl:inversefunctionalproperty owl:transitiveproperty owl:symmetricproperty owl:annotationproperty owl:backwardcompatiblewith owl:incompatiblewith owl:deprecatedclass owl:deprecatedproperty UML não se aplica não se aplica não se aplica não se aplica não se aplica não se aplica não se aplica não se aplica não se aplica Tabela 3.6: Mapeamento entre alguns elementos da OWL e a UML do conjunto dos números inteiros naturais (0, 1, 2, 3,...). Entretanto, no Schema XML 2 existem muito mais tipos de dados, de tal maneira que os quatro tipos primitivos da UML não são suficientes para representá-los. A Tabela 3.7 mostra os possíveis mapeamentos entre os tipos de dados (Data types) do Schema XML e os tipos primitivos da UML. Para exemplificar os mapeamentos entre a OWL e a UML, considere o trecho de Código 2.3 onde são declarados a classe Regime e propriedades do tipo ObjectProperty e DatatypeProperty. O trecho de código define uma propriedade do tipo Object Property que tem como domínio instâncias da classe Change e valores possíveis de instâncias da classe Regime. Também define propriedades da classe Regime, stemsize, burdenvalue, cpmvalue e idregime, todas do tipo DatatypeProperty. A Figura 3.1 representa o mapeamento em UML para este trecho de código OWL. As classes OWL Regime e Change foram mapeadas para classes UML. As propriedades do tipo DatatypeProperty foram mape- 2

53 3.2 Mapeamento entre OWL e UML 49 Schema XML xsd:integer xsd:int xsd:unsignedshort xsd:boolean xsd:string xsd:anysimpletype xsd:nonnegativeinteger xsd:positiveinteger UML Integer Integer Integer Boolean String String UnlimitedNatural UnlimitedNatural Tabela 3.7: Mapeamento dos tipos de dados do Schema XML e a UML adas para atributos da classe Regime, sendo que os seus tipos, defi nidos no Schema XML como foram mapeados para o tipo primitivo String da UML. A propriedade do tipo ObjectProperty hasregime, foi mapeada para um atributo da classe Change. Figura 3.1: Exemplo de mapeamento entre OWL euml

54 Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos CAPÍTULO 4 Este capítulo apresenta os requisitos mínimos de uma ferramenta para criação de serviços Web semânticos e também apresenta o AutoWebS (Automatic Generation of Semantic Web Services), uma ferramenta que oferece um ambiente que integra várias funcionalidades necessárias para modelar, implementar, compilar e fazer o deploy de serviços Web semânticos. O restante deste capítulo está organizado como se segue: a Seção 4.1 apresenta os requisitos mínimos de uma ferramenta para criação de serviços Web semânticos; a Seção 4.2 apresenta a ferramenta em função dos seus inputs, outputs e processo de utilização; a Seção 4.3 apresenta a arquitetura da ferramenta, explicitando seus componentes e tecnologias relacionadas; a Seção 4.4 apresenta o perfil UML especificado e implementado por este trabalho, usado para representar elementos da OWL em UML; a Seção 4.5 traz o processo de importação de ontologias OWL, apresentando a transformação XSLT; a Seção 4.6 apresenta o metamodelo para linguagem OWL-S que este trabalho especificou e implementou; a Seção 4.7 apresenta as regras de mapeamento entre um modelo UML o um modelo OWL-S; a Seção 4.8 ilustra o funcionamento da ferramenta. 4.1 Requisitos de uma ferramenta para criação de serviços Web semânticos Antes do desenvolvimento da ferramenta AutoWebS um conjunto de requisitos de uma ferramenta para criação de serviços Web semânticos foram estabelecidos. Os requisitos têm como objetivo principal abstrair detalhes específicos, relativos a cada linguagem de descrição semântica, de forma a propiciar o desenvolvimento de ferramentas que ofereçam um maior nível de abstração sobre a sintaxe das linguagens usadas na criação da descrição semântica dos serviços Web.

55 4.1 Requisitos de uma ferramenta para criação de serviços Web semânticos 51 [Chafle et al., 2007] e [Fonseca et al., 2009] propuseram alguns requisitos essenciais para o desenvolvimento de uma ferramenta para compor serviços Web. Alguns destes requisitos foram adaptados para uma ferramenta de alto nível de abstração para a criação de serviços Web semânticos. Os requisitos adaptados, juntamente com novos requisitos formam o conjunto mínimo de requisitos para uma ferramenta para criação de serviços Web semânticos acessível a um público maior do que um público formado somente por especialistas da Web semântica. A seguir são apresentados os requisitos: R0 Disponibilizar um mecanismo para que o usuário possa modelar a interface do serviço Web semântico sem que ele precise de um profundo conhecimento das tecnologias Web e Web semântica. Este mecanismo deve usar uma abordagem acessível e que torne o desenvolvimento de um serviço Web semântico intuitivo e prático, evitandose assim uma curva de aprendizado acentuada; R1 Realizar a criação automática do código fonte do serviço Web; R2 Realizar a criação automática da descrição semântica do serviço Web na linguagem alvo como, por exemplo, OWL-S; R3 Permitir a utilização de ontologias preexistentes para a criação da descrição semântica do serviço Web a partir da interligação dos conceitos definidos nestas ontologias com os elementos do serviço Web; R4 Oferecer um ambiente de desenvolvimento que integra todas as funcionalidades necessárias para a criação de um serviço Web semântico, sem que haja a necessidade do uso de recursos ou ferramentas externas; R5 Gerar artefatos de código (serviço Web e ontologia do serviço Web) sintaticamente corretos. O código gerado deve ser legível, executável e corresponder às especificações da W3C para serviços Web e serviços Web semânticos; R6 Permitir a inserção de novas funcionalidades como, por exemplo, o suporte a outra linguagem para descrição semântica do serviço Web, sem que haja a necessidade de realizar grandes modificações estruturais na ferramenta. O requisito R0 diz respeito ao uso de modelos para especificar a interface de um serviço Web, de forma a abstrair as tecnologias subjacentes usadas para implementação do serviço Web e também da sua ontologia. Assim, poupa-se do usuário o conhecimento destas tecnologias e permite-se que o mesmo direcione mais atenção as regras de negócio do serviço Web. Os requisitos R1 e R2 relacionam-se à automatização da geração de artefatos de código. Esses são requisitos importantes e complementares ao requisito R0, pois deseja-se abstrair as linguagens envolvidas na criação de serviços Web semânticos. O requisito R3 proporciona maior liberdade para criação do serviço Web semântico e contribui para interoperabilidade, pois podem-se usar ontologias que são bastante conceituadas e usadas na Internet.

56 4.2 Visão Geral da Ferramenta 52 O requisito R4 é fundamental para diminuir o tempo de desenvolvimento dos serviços Web semânticos e, também, evitar erros e possíveis conflitos gerados quando se usa diferentes ferramentas para construção de um serviço Web semânticos como, por exemplo, quando se usa uma determinada ferramenta para criação da ontologia de domínio que usa uma determinada versão da linguagem de especificação de ontologias que não é compatível com outra ferramenta que dá suporte a criação da descrição semântica do serviço Web. O requisito R5 tem como objetivo assegurar a corretude dos artefatos de códigos gerados pela ferramenta, uma vez que, um trecho de código quando gerado de forma errada, inevitavelmente necessita que o usuário tenha certo grau de conhecimento da tecnologia para sua correção. Por fim, o requisito R6 proporciona suporte a manutenção da ferramenta, seja para inserção de novas funcionalidades ou então para evolução das funcionalidades atuais como, por exemplo, a atualização para uma versão mais recente da linguagem de descrição semântica do serviço Web. 4.2 Visão Geral da Ferramenta O AutoWebS é um plugin da IDE Eclipse e relaciona-se com outros plugins de forma a prover um ambiente que integra as várias funcionalidades necessárias - modelagem, implementação, compilação e deploy - para a criação automática de serviços Web semânticos (requisitos R4 e R6) 1. Através do ambiente oferecido por AutoWebS é possível i) modelar o serviço Web, isto é, modelar os inputs e outputs de cada operação do serviço Web, ii) criar a descrição semântica do serviço Web, ou seja, associar os inputs e outputs de cada operação com os elementos de uma ontologia de domínio, iii) criar um arquivo OWL-S que contém a descrição semântica do serviço Web e, iv) gerar automaticamente o código fonte do serviço Web modelado na linguagem Java. O uso da ferramenta AutoWebS, conforme ilustrado na Figura 4.8, constitui-se de três principais atividades: (a) importação, (b) design e (c) geração. A ferramenta requer como entrada ontologias OWL (requisito R3) e fornece como saída um arquivo OWL-S que contém a ontologia do serviço Web (requisito R2), além do código fonte do serviço Web na linguagem Java (requisito R1). A primeira atividade para criação de serviços Web semânticos usando-se a ferramenta AutoWebS é a atividade de importação de ontologias OWL (a). Nesta atividade a ferramenta faz o mapeamento dos elementos da ontologia OWL para elementos da UML, de forma que o resultado é um modelo UML (diagrama de classes) que representa a ontologia OWL de entrada. Neste modelo UML estereótipos e propriedades definidas em um perfil UML asseguram informações suplementares inerentes à ontologia de entrada 1 Rx indica que o requisito x é atendido por esta decisão de projeto

57 4.2 Visão Geral da Ferramenta 53 Figura 4.1: Visão geral da ferramenta AutoWebS e também informações relevantes do contexto dos serviços Web semânticos como, por exemplo, propriedades que definem a porta onde está o serviço Web, o endpoint e namesapaces. No ambiente fornecido pelo AutoWebS é possível se definir a interface do serviço Web semântico usando os elementos do diagrama de classes UML. Do ponto de vista do projetista do serviço Web semântico a ferramenta assemelha-se a um editor de diagrama de classes UML (requisito R0). Na atividade (b), modelagem, o projetista trabalha no nível de modelagem, criando modelos que especificam a interface do serviço Web semântico ao invés de manusear as linguagens para descrição semântica dos serviços Web. Na atividade (c), geração, o modelo UML que especifica a interface do serviço Web semântico é a entrada para ferramenta AutoWebS usar um conjunto de regras de transformações QVT e templates Acceleo para gerar automaticamente a descrição semântica do serviço Web em um documento OWL-S (requisito R2) e um projeto para IDE Eclipse do serviço Web (requisito R1). O projeto de um serviço Web contém o documento WSDL, o descritor do serviço Web, o script de build que automatiza a compilação e empacotamento do serviço Web, além das classes que compõem a infraestrutura de comunicação SOAP. Para assegurar que a descrição semântica do serviço Web é válida, alguns validadores disponíveis na Internet e uma API (requisito R5) são utilizados. O validador RDF [Prod hommeaux, 2007], disponibilizado pela W3C, é utilizado para validar as construções em RDF da ontologia do serviço Web. O validador OWL [Rager et al., 2004] é utilizado para validar as construções OWL enquanto que para validar as construções e a sintaxe OWL-S é utilizado o validador OWL-S, disponível na API OWL-S [Sirin and Parsia, 2004].

58 4.3 Arquitetura 54 A ferramenta AutoWebS implementa uma abordagem MDD para atender principalmente os requisitos R0, R1, R2 e R3, com a função de gerenciar a complexidade inerente do emprego de ontologias para especificação de serviços Web semânticos, pois MDD está centrado na criação de modelos, em vez de código de programa, permitindo separação de interesses entre especificação e implementação, provendo ao usuário um maior nível de abstração da linguagem OWL. O AutoWebS implementa um mecanismo de importação de ontologias de domínio que usa um conjunto de transformações XSLT e um perfil UML (requisito R3). XSLT é uma linguagem declarativa para transformações de documentos XML que usa um mecanismo de casamento de padrões capaz de selecionar pedaços de documentos XML para criação de novos documentos com a sintaxe XML ou textual. No processo de importação de ontologias de domínio, alguns elementos da linguagem OWL são mapeados para elementos da UML (ver Seção 3.2). Este processo não assegura a representação de todos os elementos da ontologia no modelo UML, pois são mapeados somente os elementos necessários para modelagem de um serviço Web semântico. 4.3 Arquitetura O AutorWebS é um plugin para a plataforma Eclipse e fornece um ambiente composto por um editor UML, um mecanismo de importação de ontologias e um mecanismo para criação automática da descrição semântica do serviço Web e do código fonte a partir de um modelo UML (requisito R4). Conforme ilustrado na Figura 4.2, o AutoWebS interage com outros plugins da plataforma Eclipse, com o middleware Axis2 e também com Ant [Loughran and Hatcher, 2007]. Novas funcionalidades podem ser integradas à ferramenta com a inserção de novos plugins (requisito R6), usufruindo-se da infraestrutura oferecida pelo Eclipse para o desenvolvimento de aplicações modulares. Ademais, a abordagem MDD implementada pela ferramenta permiti a inserção de uma nova linguagem de descrição semântica com a criação de um metamodelo para tal linguagem e a definição do mapeamento entre os elementos definidos no perfil UML com o metamodelo além, é claro, das transformações model-to-text. O AutoWebS utiliza o editor gráfico UML Papyrus [Gérard et al., 2007] que é parte oficial do Eclipse Modeling Project. O Papyrus oferece suporte a perfis UML de forma a permitir a criação de editores para DSLs (Domain Specific Language) baseados no padrão UML. A principal característica do Papyrus em relação à criação de editores para DLSs é um conjunto poderoso de mecanismos de personalização que podem ser utilizados para criação de perspectivas customizáveis para os editores de DSLs. Assim, usando o Papyrus e seus mecanismos de personalização, juntamente com o perfil UML, foi concebido um editor de diagramas de classes UML customizado para o AutoWebS

59 4.3 Arquitetura 55 Figura 4.2: Arquitetura da ferramenta AutoWebS (requisito R0). Este editor UML permite a criação de modelos UML que contêm a interface do serviço Web semântico. Estes modelos UML são exportados pelo editor como documentos XMI. Para importação da ontologia é necessária a execução das regras de transformações descritas em XSLT. O componente ImporterModule realiza a execução das regras XSLT usando o processador XSLT do componente XSL Tools, que faz parte do projeto Web Tools Platform [Dai et al., 2007]. O plugin QVTo é usado para execução do conjunto de regras de transformações QVT para geração automática de um modelo OWL-S a partir de um modelo UML, codificado em um documento XMI. Além do modelo OWL-S, o código fonte em Java do modelo UML (requisito R1) é gerado utilizando o plugin UML to Java Generator [Obeo Network, 2012]. O código fonte gerado a partir do modelo contém todos os elementos do modelo UML, inclusive a interface que defi ne o serviço Web e os elementos da ontologia que foram representados como classes UML. O componente WebServiceModule é responsável por estender a funcionalidade do Axis2 a fim de prover não somente a geração do código fonte, mas também a criação de projetos de serviços Web para plataforma Eclipse (requisito R0) e algumas facilidades para a compilação, empacotamento e deploy do serviço Web em um contêiner Web. O projeto de um serviço Web contém o documento WSDL, o descritor do serviço Web, utilizado para realizar o deploy, além das classes que compõem a infraestrutura de comunicação SOAP. Todas as facilidades oferecidas por este componente são acessíveis por botões ou menus na ferramenta.

60 4.4 Perfil UML Perfil UML A UML, por si só, sem o uso de perfis UML, não tem expressividade suficiente para representar todos os elementos da linguagem OWL. Entretanto, um perfil UML consiste em uma coleção de extensões que personalizam a UML para um domínio específico. Desta forma, este trabalho especifica e implementa um perfil UML cuja finalidade é permitir a representação de alguns elementos da linguagem OWL em UML para a modelagem de serviços Web semânticos. O perfil UML definido e implementado pelo AutoWebS contém um conjunto de estereótipos e tagged-values 2 que são aplicados nos elementos do modelo UML para representar seu significado e adicionar informações relacionadas ao domínio da aplicação que são necessárias para enriquecer o modelo UML e também para as transformações que este modelo será submetido. A Figura 4.3 ilustra o perfil UML implementado neste trabalho. Neste perfil o estereótipo «owl:ontology» é aplicado sobre a definição de um elemento Package da UML e corresponde ao elemento Ontology da OWL. Este estereótipo define o domínio da ontologia e contém informações a respeito da versão da ontologia, autor, comentários, além de declarações de namespaces. Uma ontologia pode importar conceitos de outras ontologias. Desta forma, o estereótipo «owl:imports», que tem como metaclasse o elemento da UML PackageImport, habilita o relacionamento entre os elementos de várias ontologias. 2 São propriedades que os estereótipos podem ter.

61 4.4 Perfil UML 57 Figura 4.3: Perfil UML usado pela ferramenta AutoWebS O estereótipo «owl:class» representa um conceito que foi modelado como uma classe. As propriedades DatatypeProperty e ObjectProperty são mapeadas como atributos de uma classe UML estereotipada por «owl:class». Nestes atributos são aplicados os estereótipos «owl:datatypeproperty» e «owl:objectproperty». O estereótipo «rdfs:subclassof» é aplicado sobre a metaclasse UML Generalization e representa generalizações de classes OWL. Os estereótipos «Text-description» e «Category» estendem a metaclasse UML Comment e possibilitam a descrição textual do serviço Web semântico e a associação a uma categoria (ver Seção 2.3.1). Os estereótipos «Pre-condition» e «Effect» estendem a metaclasse UML Constraint com o objetivo de especificar restrições as quais

62 4.5 Importação das Ontologias OWL 58 devem ser satisfeitas para que o serviço Web seja executado apropriadamente. Na linguagem OWL-S, os elementos preconditions e effects são representados como fórmulas lógicas e podem ser expressos com o uso de linguagens cujo padrão de codificação é XML, tais como SWRL (Semantic Web Rule Language) [Horrocks et al., 2004] e RDF [Manola and Miller, 2004], ou literais strings, tal como PDDL (The Planning Domain Definition Language) [Ghallab et al., 1998]. Na versão atual da ferramenta AutoWebS o suporte a visualização e gerenciamento das expressões lógicas é básico. Atualmente as expressões lógicas são inseridas em um campo de texto do elemento Constraint da UML e nenhum processamento é realizado pela ferramenta para assegurar a expressividade da linguagem. Como trabalho futuro pretende-se desenvolver um GUI para prover a gerência e visualização das expressões lógicas, tal como [Hassanpour et al., 2010] propôs. O estereótipo «SemanticWebService» é aplicado sobre a definição de um tipo UML Interface. Na interface em que o estereótipo «SemanticWebService» é aplicado, são definidas as operações do serviço Web. As operações do serviço Web são modeladas como métodos. Este estereótipo contém alguns tagged-values que servem para adicionar informações suplementares ao serviço Web. O tagged-value targetnamespace define o namespace usado no documento WSDL. O tagged-value URI WSDL determina a URI do serviço Web. O tagged-value WebService Documentation serve para fins de documentação enquanto que o tagged-value serviceport especifica a porta em que o serviço Web executará. O tagged-value endpoint determina o tipo de endpoint utilizado para comunicação fim-a-fim com serviço Web. No perfil UML é definido um tipo Enumeration com os valores possíveis para o endpoint. Os valores possíveis para versão atual da ferramenta são: HttpSoap11; HttpSoap12; e Http. Os métodos definidos na interface estereotipada por «SemanticWebService» que representam operações dos serviço Web, são estereotipados por «SWSOperation». O estereótipo «SWSOperation» define um nome para uma operação e especifica os inputs e output desta operação, que podem ser definidos como classes, tipos primitivos da linguagem Java ou então como classes da ontologia de domínio, que estão representadas no modelo UML pelo estereótipo «owl:class». 4.5 Importação das Ontologias OWL No processo de importação da ontologia de domínio, um conjunto de transformações XSLT é usado. Esse conjunto de transformações transforma um documento OWL em um documento XMI que representa um modelo UML. As transformações XSLT são aplicadas em alguns elementos da linguagem OWL a fim de se criar um modelo UML correspondente (requisito R3). O Apêndice C traz este conjunto de transformações XSLT.

63 4.5 Importação das Ontologias OWL 59 Para efeito de exemplificação do funcionamento da importação das ontologias OWL e sua representação em UML, considere a ontologia Bibtex 3 que representa os conceitos e relacionamentos destes conceitos no domínio da linguagem BibTex para o gerenciamento e formatação de referências bibliográficas. A ontologia BibTex define 15 classes OWL: Entry, Booklet, Book, Inproceedings, Proceedings, Manual, Inbook, Article, Incollection, Misc, Unpublished, Masterthesis, PhdThesis, Techreport e Conference. Todas as classes são definidas como subclasses de Entry. A classe Entry possui a propriedade do tipo DatatypeProperty hasisbn que é herdada por todas as outras classes. As demais classes diferenciam-se pelo nome e quantidade de propriedades. Por exemplo, a classe Book possui as propriedades do tipo DatatypeProperty haspublisher, hastitle, hasyear e humancreator enquanto que a classe Article possui as propriedades do tipo DatatypeProperty hasauthor, hasjournal, hastitle e hasyear. O resultado do processo de importação da ontologia BibTex está ilustrado na Figura 4.4. As transformações XSLT criam um diagrama de classes UML com os elementos da ontologia BibTex. Na importação, as classes OWL são transformadas em classes UML e as propriedades OWL do tipo DatatypeProperty são mapeadas para atributos de classes UML. Figura 4.4: Ontologia BibTex representada como UML A Figura 4.5 demonstra como a classe OWL Booklet é convertida para uma classe UML. O lado direiro da Figura 4.5 ilustra o trecho de código que especifica a classe OWL enquanto que o lado direito ilustra a classe UML correspondente. A classe OWL 3

64 4.6 Metamodelo da Linguagem OWL-S 60 Booklet é uma subclasse de Entry e contém uma propriedade do tipo DatatypeProperty chamada de hastitle. A classe OWL Booklet é mapeada para a UML como um elemento packageelement do tipo uml:class com o nome Booklet e identificador _sr- VUwK60EeGyaLpUewWoVw. A classe UML Booklet é uma generalização da classe identificada por _PSOQQK61EeGyaLpUewWoVw, a classe Entry. A propriedade OWL foi mapeada para o documento XMI como um elemento ownedattribute com o nome hastitle e com valores possíveis definido como o tipo String dos tipos primitivos da UML. Figura 4.5: Mapeamento da classe OWL em UML 4.6 Metamodelo da Linguagem OWL-S A descrição semântica de um serviço Web associa os parâmetros de entrada (input) e o retorno (output) das operações de um serviço Web, que estão descritos no documento WSDL na forma de elementos message, com conceitos definidos em uma ontologia. O modelo UML criado por intermédio da ferramenta AutoWebS para a especificação da interface do serviço Web contém informações importantes que são utilizadas para associar os conceitos definidos em ontologias de domínio com os elementos do serviço Web. Entretanto, apesar do modelo UML conter tais informações, a MDD propõe a separação de conceitos arquiteturais através de níveis de abstração da arquitetura de um sistema. Neste sentido, AutoWebS implementa um processo MDD, de forma que a transformação do modelo UML para um arquivo OWL-S requer um modelo intermediário, que esteja de acordo com um metamodelo para a linguagem OWL-S. O metamodelo OWL-S implementado por este trabalho foi descrito em Ecore e contempla a versão 1.1 da especificação OWL-S. Esta versão da especificação OWL-S é compatível com o WSDL 1.1 (requisitos R2 e R5). A Figura 4.6 apresenta uma visão simplificada do metamodelo para linguagem OWL-S.

65 4.6 Metamodelo da Linguagem OWL-S 61 Figura 4.6: Metamodelo OWL-S No metamodelo, a classe ServiceProfi leé uma superclasse para todos os tipos de descrições em alto nível a respeito do serviço Web. Ela contém as informações básicas necessárias para vincular qualquer instância de Profi le, uma subclasse de ServiceProfi le, com uma instância de Service. O serviço Web, definido através da classe Profi le, é

66 4.6 Metamodelo da Linguagem OWL-S 62 modelado em termos de dois tipos de informações: (i) informações da organização que provê o serviço, que são informações de contato da entidade fornecedora do serviço e a (ii) descrição funcional, que inclui os inputs e outputs do serviço, as pré-condições (precondition) requisitadas e os efeitos (effects) esperados da execução do serviço. O elemento ServiceProfile descreve apenas o funcionamento global do serviço Web. Uma perspectiva detalhada sobre como interagir com o serviço Web é provida pela classe Process, uma subclasse de ServiceModel. Uma instância de Process é um processo que define a interação com o serviço Web. Em OWL-S processos não são necessariamente programas a serem executados, mas sim uma especificação das formas com que um cliente pode interagir com um serviço. Qualquer processo pode ter qualquer quantidade de inputs, representando as informações que estão sob certas condições (preconditions), necessárias para iniciar o processo. Processos podem ter qualquer número de outputs, as quais representam as informações que o processo fornece ao solicitante. Inputs e Outputs são representados como subclasses da classe Parameter e cada Parameter tem um tipo, especificado usando um URI. Pode existir qualquer número de preconditions, que devem ser satisfeitas para que um processo possa ser iniciado com êxito. Em um documento WSDL as operações do serviço Web são especificadas como blocos básicos de construção do serviço Web. As operações fornecem a estrutura e a sintaxe das mensagens de input e output. OWL-S provê uma construção para cada operação do serviço Web. Esta construção chama-se AtomicProcess e é caracterizada principalmente em termos dos inputs, outputs, preconditions e effects (IOPE). OWL- S define três tipos de processos: (i) AtomicProcess é um processo que pode ser visto como uma descrição de um serviço que espera uma mensagem e retorna uma resposta, ou seja, recebe um input, faz algum processamento, e depois retorna o output. Para cada AtomicProcess, existe um elemento WsdlAtomicProcessGrounding que permite a um solicitante do serviço codificar as mensagens para o processo a partir de seus inputs e decodificar os outputs; (ii) CompositeProcess é um processo que define a descrição de uma composição de serviços e corresponde as ações que exigem várias interações com servidores. Um CompositeProcess é composto por outros processos do tipo AtomicProcess ou CompositeProcess. Os processos que fazem parte da composição são especificados a partir de estruturas de controle, tais como Sequence, Split, Choice, If-Then-Else, Iterate e Repeat-While (ver Seção 2.3.2); (iii) SimpleProcess é um processo que fornece um mecanismo de abstração para prover múltiplas visões de um mesmo processo. Ele não é invocável e não está associado a nenhum elemento Grounding. O elemento ServiceGrounding permite se representar os dados semânticos como mensagens XML que são enviadas pela rede e também especifica como o receptor pode interpretar essas mensagens XML e transformá-las novamente para os dados semânticos. A classe WsdlGrounding é uma subclasse de ServiceGrounding e seu papel é fornecer

67 4.7 Implementação das Regras de Mapeamento entre UML e OWL-S 63 mecanismos para que as principais construções do arquivo WSDL possam ser referenciadas em OWL-S. Cada instância da classe WsdlGrounding contém uma lista de instâncias de WsdlAtomicProcessGrounding. Essa relação é representada pela propriedade hasatomicprocessgrounding. A propriedade owlsprocess garante que para cada processo do tipo AtomicProcess exista somente um WsdlAtomicProcessGrounding. Por outro lado a propriedade wsdloperation assegura uma relação um-para-um entre o AtomicProcess e a especificação WSDL. 4.7 Implementação das Regras de Mapeamento entre UML e OWL-S No metamodelo OWL-S são definidos todos os elementos e relacionamentos que podem ser encontrados nos modelos OWL-S. Na abordagem MDD implementada pela ferramenta AutoWebS, um modelo UML, que representa a interface de um serviço Web semântico, é a entrada para um mecanismo que produz um modelo de saída em conformidade com o metamodelo OWL-S. A Figura 4.7 ilustra um trecho da transformação em QVT que implementa o mapeamento entre os modelos UML e OWL-S. Esta transformação, chamada de UMLProfile2OWLS, recebe como entra um modelo da UML 2 na versão e cria um modelo OWL-S de acordo com o metamodelo OWL-S. No método main (linha 9), a instrução inuml.objectsoftype(uml::interface) (linha 11) recupera uma lista de todos os elementos UML Interface do modelo de entrada. O operador QVT foreach (linha 11) faz uma iteração sobre estes elementos e o operador QVT if (linha 12) faz uma seleção sobre os elementos que tem o estereótipo SemanticWebService. A instrução seguinte, na linha 13, recupera todos os elementos UML Operation - as operações do serviço Web - definidos no elemento Interface. Ainda na mesma linha, com o operador foreach, é realizado uma iteração sobre os elementos Operation na busca por aqueles com o estereótipo textitsw- SOperation. Para cada operação do serviço Web, um modelo OWL-S é criado. A instrução map (linha 16) faz uma chamada ao mapeamento createowls. No mapeamento create- OWLS são construídos os elementos do modelo OWL-S. O Apêndice D traz na íntegra a implementação da transformação em QVT. O elemento Profile do modelo OWL-S é criado a partir do valor do taggedvalue WSDL Documentation, aplicado ao elemento UML Interface e dos tagged-values do estereótipo Category. O id do elemento Profile é formado pela concatenação do nome da operação com a palavra Profile. Desta forma, uma operação com nome subscribe, formará o id subscribeprofile para o elemento Profile. Os elementos WsdlGrounding, AtomicProcess e Service do modelo OWL-S são

68 4.7 Implementação das Regras de Mapeamento entre UML e OWL-S 64 Figura 4.7: Transformação de UML para OWL-S criados de forma semelhante ao elemento Profile e os valores das suas propriedades são especificados a medida em que o elemento WsdlAtomicProcessGrounding e os parâmetros WsdlInputMessage e WsdlOutputMessage são criados. No elemento WsdlAtomicProcessGrounding do modelo OWL-S, o valor do seu id é formado pela concatenação do nome da operação com a palavra AtomicProcessGrounding. O valor do atributo wsdldocument é o valor do taggedvalue URI WSDL Document aplicado no elemento UML Interface. O valor do atributo wsdlinputmessage é formado pela concatenação do valor do tagged-value targetnamespace com a caractere #, com nome do serviço e com a palavra Request. O valor do atributo wsdloutputmessage é formado pela concatenação do valor do tagged-value targetnamespace com o caractere #, com nome do serviço e com a palavra Response. O atributo wsdloperation recebe uma instância de WsdlOperationRef. No objeto WsdlOperationRef a propriedade porttype é formada pela concatenação do tagged-value URI WSDL Document, com o caractere # e com o valor do tagged-value textitendpoint. A propriedade operation é formada pela concatenação do tagged-value URI WSDL Document, com o caractere # e com o nome do serviço. No elemento OWL-S wsdlatomicgrounding são especificados os inputs e outputs do serviço Web semântico através da associação do elemento Message Part do documento WSDL com um conceito definido como uma classe no documento OWL. Para os casos em que os inputs e outputs de uma operação do serviço Web não têm uma correspondência direta com os elementos da ontologia de domínio, são necessários representar como derivar a Message Part de um ou mais inputs ou outputs do Atomic Process. A propriedade xslttransformation contém um script XSLT que gera o Message Part de uma instância de um Atomic Process. O script pode ser diretamente representado como uma string ou pode ser referenciado por um URI. A transformação QVT, que faz o mapeamento entre o modelo UML e o modelo OWL-S, cria automaticamente o script

69 4.8 Funcionamento da Ferramenta 65 XSLT para os casos em que são usados elementos da ontologia de domínio importada como input ou output para especifi cação de uma operação do serviço Web semântico. 4.8 Funcionamento da Ferramenta O funcionamento do AutoWebS, ilustrado na Figura 4.8, compreende basicamente três principais atividades que devem realizadas sequencialmente, (i) importação da ontologia de domínio, (ii) criação do modelo UML e (iii) geração automática do serviço Web e sua ontologia. A primeira e a última atividade são automatizadas pela ferramenta. O usuário precisa realizar somente a segunda atividade, a modelagem da interface do serviço Web semântico. Figura 4.8: Funcionamento do AutoWebS A primeira atividade consiste na importação da ontologia de domínio (ver Seção 4.5) para a criação de um modelo UML. Na primeira atividade a ferramenta usa o componente ImporterModule para execução das transformações XSLT e criação do modelo UML. Este modelo UML contém os elementos da ontologia de domínio que podem ser usados para modelagem da interface de um serviço Web. A segunda atividade consiste na edição do modelo UML. Na segunda atividade, o usuário pode inserir ou remover elementos no modelo UML recém criado para modelagem da interface do serviço Web. A terceira atividade ocorre após a modelagem da interface do serviço Web. Neste ponto, o AutoWebS exporta a representação gráfica do modelo UML para um

70 4.8 Funcionamento da Ferramenta 66 documento XMI. Então, no documento XMI é aplicado um conjunto de regras de transformações QVT para geração automática de um modelo OWL-S. Também, sobre o mesmo documento XMI, é aplicado um template Acceleo, chamado UML to Java, para criação do código fonte na linguagem Java dos elementos contidos no modelo UML que define a interface do serviço Web. Depois de criado o modelo OWL-S, outro template Acceleo é utilizado para criar o documento OWL-S. Após esta atividade de geração de artefatos, são produzidos o código fonte do serviço Web e o documento OWL-S correspondente. Para geração do código fonte do serviço Web a descrição das operações do serviço Web, que são representadas através de métodos públicos em uma interface Java, é submetida ao componente WebServiceModule. Este componente, por intermédio do subcomponente Factory, faz chamadas à API do Engine do Axis2 para realizar as seguintes tarefas: 1. Criar o documento WSDL associado ao serviço Web; 2. Gerar o código fonte para implementação do serviço Web, isto é, os artefatos de código que compõem a infraestrutura do serviço Web; 3. Criar o script Ant build.xml para o projeto do serviço Web. Os principais artefatos de código gerados são: i) o descritor de deploy services.xml, que contém a configuração de execução do serviço Web, ii) o MessageReceiver, que é responsável pelo comunicação fim-a-fim, iii) Skeletons e Stubs que implementam qual protocolo utilizado para transmissão das mensagens no lado servidor e cliente, iv) o arquivo build.xml, que descreve o processo de construção (build) e as dependências do projeto do serviço Web com APIs de terceiros. O arquivo build.xml é utilizado pelo Apache Ant [Loughran and Hatcher, 2007] para automatizar a construção do serviço Web a medida que automatiza o processo de build das classes e o empacotamento para o formato aar que é o formato usado para deploy em contêineres Web. O componente WebServiceModule agrega o documento WSDL e os artefatos de código do serviço Web em um projeto para plataforma Eclipse para que o usuário possa programar as regras de negócio do serviço Web, ou seja, implementar as chamadas aos métodos de APIs, incluir bibliotecas de terceiros, etc. Após ter implementado as regras de negócio do serviço Web, o usuário pode usar as funcionalidades de compilação e deploy oferecidas pelos subcomponentes Deployer e Compiler. O subcomponente Compiler compila o projeto utilizando o script build.xml do Apache Ant. O resultado da compilação é um arquivo com a extensão aar que contém o código fonte do serviço Web e a implementação do protocolo SOAP, no lado servidor, fornecida pelo Axis2. Através de alguns parâmetros, que podem estar pré-definidos em um arquivo de configuração, o subcomponente Deployer pode fazer o deploy do serviço Web em um contêiner Web que tenha instalado o Axis2 Runtime.

71 Estudo de Caso CAPÍTULO 5 Este capítulo apresenta um estudo de caso onde o AutoWebS é usado na criação de serviços Web semânticos para os serviços providos por sistemas de middleware de provisão de contexto [Kjaer, 2007] que não utilizem a tecnologia de serviços Web para oferecer seus serviços e/ou ontologias para representar os elementos de contexto. Este estudo de caso tem dois principais objetivos: mostrar o uso da ferramenta na criação de serviços Web semânticos e descobrir/identificar possíveis limitações da ferramenta e pontos de melhorias. Este capítulo está organizado como se segue. A Seção 5.1 faz uma breve apresentação de sistemas de middleware de provisão de contexto, apresentando o middleware usado no estudo de caso; a Seção 5.2 apresenta a ontologia de domínio; a Seção 5.3 apresenta o processo de modelagem do serviço Web semântico utilizando-se a ferramenta AutoWebS; a Seção 5.4 discute os resultados e faz uma análise da execução do estudo de caso. 5.1 Sistemas de middleware de provisão de contexto Sistemas de middleware de provisão de contexto são soluções que oferecem uma infraestrutura que facilita o desenvolvimento de aplicações sensíveis ao contexto em domínios diversos, através da disponibilização de mecanismos de gerenciamento dos dispositivos; modelagem, interpretação e refinamento dos dados de contexto; mecanismos de distribuição das informações de contexto, etc. Cada plataforma de middleware de provisão de contexto utiliza um modelo para representar os dados de contexto e outro modelo para comunicação. Existem várias abordagens para modelagem dos dados de contexto [Strang and Popien, 2004], as mais utilizadas são: Chave-Valor; Markup Schema; Gráfico; Orientado a Objeto; Lógico; e Ontologias. Os modelos de comunicação definem a arquitetura, como por exemplo, cliente-servidor e P2P (par-to-par), e o estilo, como por exemplo, RCP (Remote procedure calls), SOA (Service-oriented architecture) e REST (Representational state transfer), utilizados para oferecer os serviços do middleware sobre uma infraestrutura de rede disponível.

72 5.1 Sistemas de middleware de provisão de contexto 68 Entretanto, apesar de um middleware de provisão de contexto oferecer soluções que facilitam o desenvolvimento de aplicações sensíveis ao contexto, normalmente, apenas o uso de um único middleware não é suficiente para atender os requisitos de uma aplicação. Desta forma, devem-se utilizar serviços de várias plataformas de middleware, tornando o desenvolvimento da aplicação uma tarefa nada trivial para os engenheiros de software e programadores, pois entender os modelos utilizados para representação dos dados de contexto, bem como os modelos de comunicação adotados por cada middleware e fazer a conversão deles para a representação adotada pela aplicação, são complexidades adicionais que devem ser evitadas. Para endereçar estes problemas, surgiram algumas iniciativas, tais como ReMMoC [Grace et al., 2003], Home soa [Bottaro and Gérodolle, 2008] e OpenCOPI (OpenCOntext Platform Integration) [Lopes et al., 2008, Lopes et al., 2009a, Lopes et al., 2009b], com a proposta de assegurar a interoperabilidade e fazer a integração de sistemas de middleware. O OpenCOPI (OpenCOntext Platform Integration) é uma plataforma que integra diferentes sistemas de middleware de provisão de contexto e provê um serviço de contexto unificado. O OpenCOPI fornece um mecanismo de composição semântica de serviços de contexto, onde aplicações são clientes de serviços e sistemas de middleware de contexto são provedores de serviços de contexto e, para prover independência de plataforma e simplificar a integração com diferentes sistemas de middleware, o OpenCOPI é baseado em tecnologias SOA e Web semântica. O OpenCOPI utiliza uma ontologia de domínio, especificada em OWL e organizada em duas camadas, para representar os elementos de contexto. No OpenCOPI, a integração de plataformas de middleware de provisão de contexto que não utilizam a tecnologia dos serviços Web, para prover seus serviços, ou ontologias para representar os elementos de contexto, é feita por intermédio de drivers. Os drivers implementam as funcionalidades relacionadas a abstração dos modelos de comunicação e a conversão dos modelos de contexto, adotados pelos sistemas de middleware, para os modelos utilizados pelo OpenCOPI. A Figura 5.1 ilustra a arquitetura do OpenCOPI. Nesta arquitetura, os drivers podem ser vistos sob dois diferentes pontos de vista: (i) sob o ponto de vista do OpenCOPI e de seu mecanismo de composição e execução de serviços, os drivers representam um proxy para os sistemas de middleware subjacentes, sendo responsáveis por repassar as requisições das aplicações aos serviços; (ii) sob o ponto de vista do middleware subjacente, um driver nada mais é do que um cliente do middleware. Os componentes da camada UnderlayIntegrationLayer são responsáveis pela integração dos sistemas de middleware subjacentes. O driver é responsável por realizar as consultas e subscrições realizadas pelo OpenCOPI aos middleware de provisão de contexto subjacentes. Cada driver precisa estender o componente GenericDriver. Esse

73 5.2 Ontologia de Domínio 69 Figura 5.1: Arquitetura do OpenCOPI - extraído de [Lopes et al., 2009b] componente implementa a interface do lado do OpenCOPI e define as operações para a transformação do modelo de contexto e a comunicação entre OpenCOPI e um middleware específico [Lopes et al., 2009b]. Entretanto, a criação de um driver é um processo que requer um profundo conhecimento da API do middleware de provisão de contexto e necessita da recompilação do OpenCOPI, pois o driver é um componente de software embutido. Além disso, não existe um padrão ou metodologia bem definida para sua criação. Ademais, as transformações implementadas em um driver para adequação dos elementos de contexto entre middleware-opencopi, normalmente não podem ser reaproveitadas para criação de outros drivers. Neste estudo de caso usamos a ferramenta AutoWebS para a modelagem e geração automática de serviços Web semânticos para os serviços de sistemas de middleware de provisão de contexto não baseados em serviços Web e/ou que não utilizam ontologias para representação dos elementos de contexto. Desta forma, conforme ilustrado na Figura 5.1, os serviços Web semânticos gerados para os serviços fornecidos por cada middleware de contexto substituem os drivers e toda complexidade envolvida na sua construção. 5.2 Ontologia de Domínio O estudo de caso utiliza uma ontologia, chamada de OilExploration, que descreve os conceitos do domínio da indústria de Petróleo. Esses conceitos, ilustrados na Figura 5.2, são usados como inputs e outputs para os vários serviços que possam estar relacionados a este domínio. Todos os conceitos desta ontologia foram especificados em um arquivo OWL.

74 5.2 Ontologia de Domínio 70 Figura 5.2: Ontologia de domínio OilExploration Na Figura 5.2, as elipses mais escuras representam tarefas (tasks). Para cada uma das tarefas deve existir, pelo menos, um serviço Web correspondente. A Figura 5.3 ilustra um trecho da ontologia OilExploration que define o conceito PumpUnit que representa uma unidade de bombeio mecânico (UB) e foi definido como uma classe OWL. A classe PumpUnit possui como superclasse Equipment e tem três propriedades: minburdenvalue e maxburdenvalue, propriedades DatatypeProperty, definidas como tipo String do Schema XML; e actualregime, uma propriedade ObjecProperty, uma referência à classe Regime que indica o regime atual de operação da UB. Maiores detalhes da ontologia OilExploration podem ser encontrado no site fred/opencopi/case_studies.html. Na ontologia de domínio, a tarefa subscribe, existe um serviço chamado WellDatabase. Este serviço provê informações sobre os poços de petróleo e, assincronamente, fornece o valor atual da carga de petróleo (burden) em cada UB. O serviço WellDatabase abstrai um widget do framework Context Toolkit (CT) [Dey et al., 2001]. O framework CT é um middleware de provisão de contexto que utiliza um modelo de comunicação não baseado nas tecnologias dos serviços Web, porém baseado em um protocolo XML transportado por HTTP. Esse widget monitora o funcionamento da UB e representa os elementos de contexto no formato chave-valor. Desta forma, para o serviço WellDataBase, faz-se necessário a conversão do modelo de contexto de chave-valor para ontologia e do modelo de comunicação HTTP para serviços Web. A próxima seção apresenta como procedemos a modelagem e geração do serviço Web semântico para o serviço WellDataBase.

75 5.3 Modelagem do Serviço Web Semântico 71 Figura 5.3: Trecho da ontologia de domínio OilExploration 5.3 Modelagem do Serviço Web Semântico Para criar o serviço Web semântico para o serviço WellDatabase usamos a ferramenta AutoWebS e realizamos cinco atividades, conforme demonstra a Figura 5.4. Figura 5.4: Atividades realizadas para o estudo e caso 1. Importação da ontologia de domínio; 2. Modelagem da interface do serviço Web; 3. Acionamento do mecanismo de geração automática do arquivo OWL-S e esqueleto de código fonte do serviço Web; 4. Implementação da regra de negócio do serviço Web; 5. Deploy do serviço Web. A primeira atividade consiste em selecionar o arquivo OWL que contém a ontologia de domínio e repassá-la para o AutoWebS. Desta forma, a ferramenta cria um modelo UML (diagrama de classes) representando alguns elementos desta ontologia. Conforme ilustrado na Figura 5.5, o AutoWebS cria uma representação dos conceitos da ontologia especificados como classes OWL em classes UML.

76 5.3 Modelagem do Serviço Web Semântico 72 Figura 5.5: Trecho da ontologia de domínio OilExploration Os elementos do modelo UML, criados a partir da ontologia de domínio, foram usados para especificação da interface do serviço Web, ou seja, para realizar a segunda atividade. Neste estudo de caso, criamos a interface WellDatabase e aplicamos o estereótipo «semanticwebservice». Nesta interface definimos o método subscribeburdenassyncservice e aplicamos o estereótipo «SWSOperation». Este método recebe como parâmetros de entrada (input) os tipos OilWell e PumpUnit, ambos classes do modelo UML estereotipados por «owl:class». O retorno do método (output) é uma classe do tipo Regime, que também foi importada da ontologia de domínio. Na terceira atividade, após modelado a interface do serviço Web, acionamos na ferramenta AutoWebS o mecanismo de geração automática do arquivo OWL-S e esqueleto de código fonte do serviço Web. A Figura 5.6 ilustra os artefatos de código gerados automaticamente pela ferramenta. O arquivo WellDatabase.wsdl contém o documento WSDL do serviço Web. O descritor de deploy, services.xml, contém a configuração de execução do serviço Web. A classe Java WellDatabaseMessageReceiverInOut.java é responsável pela comunicação fim-a-fim do serviço Web com os clientes, enquanto que as classes Java WellDatabaseSkeleton.java e WellDatabaseStub.java são, respec-

77 5.3 Modelagem do Serviço Web Semântico 73 tivamente, o skeleton e stub e implementam o protocolo SOAP utilizado para transmissão das mensagens entre servidor e cliente. O arquivo build.xml descreve o processo de construção (build) e as dependências do serviço Web. Todos os artefatos foram incluídos em um projeto Java para plataforma Eclipse. Figura 5.6: Artefatos de códigos gerados A quarta atividade consistiu da implementação das regras de negócio do serviço Web. Nesta atividade foram implementadas as chamadas à API do serviço WellDatabase, implementado com o framework CT. A Figura 5.7 ilustra o trecho de código da operação subscribeburdenassyncservice do serviço Web. No método Java subscribeburdenassyncservice são realizadas a conexão ao serviço WellDataBase implementado com CT, a subscrição ao serviço de notificação e o tratamento dos dados recebidos pelo serviço WellDataBase implementado com o CT. Conforme a Figura 5.7, os tratamentos dos dados são realizados pelo método getregime. Neste método, o retorno que está no formato chave-valor, é convertido para um objeto Regime. Após ter implementado as regras de negócio do serviço Web, usamos as funcionalidades de compilação e deploy. O projeto Java Eclipse foi compilado utilizando o script build.xml do Apache Ant. O resultado da compilação é um arquivo com a extensão aar que contém o código fonte do serviço Web e a implementação do protocolo SOAP, no lado servidor, fornecida pelo Axis2. O processo de deploy é bastante simples. No deploy, a ferramenta faz uma cópia do arquivo com a extensão aar para no contêiner Web que tenha instalado o Axis2 Runtime.

78 5.4 Resultados Resultados Figura 5.7: Implementação da regra de negócio do serviço Web A ferramenta AutoWebS proporcionou a criação do serviço Web semântico para o serviço WellDataBase usando os conceitos definidos em uma ontologia OWL. Os conceitos definidos como classes na ontologia foram mapeados para classes em um modelo UML. Tais classes UML foram usadas para criar a interface do serviço Web semântico. Durante o processo de modelagem da interface do serviço Web semântico a ferramenta abstraiu a sintaxe da linguagem OWL e o uso da UML tornou mais claro e intuitivo a criação do serviço Web semântico. Com a ferramenta AutoWebS foi possível criar os serviços Web semânticos que abstraem o modelo de comunicação usado pelo CT e também realizam a conversão da representação dos elementos de contexto de chave-valor para ontologia. O serviço Web semântico foi implantado em um contêiner Web e testado a partir de uma aplicação cliente desenvolvida com a API OWL-S. Com o estudo de caso podemos demonstrar o uso da ferramenta e descobrir alguns erros/inconsistências que foram corrigidos. Os principais erros apresentados pela ferramenta estavam presentes nas transformações entre os modelos UML e OWL-S. Os erros foram corrigidos e os artefatos de código gerados pela ferramenta foram analisados sintaticamente com validadores disponíveis na Internet. O estudo de caso em questão apresenta algumas limitações. Dentre as limitações do estudo de caso está o fato de não existirem expressões lógicas que especificam condições que determinam a funcionalidade do serviço Web como, por exemplo, as précondições (precondition) requisitadas pelo serviço e os efeitos (effects) esperados da execução do serviço. As condições precondition e effects são representadas no modelo UML como elementos Constraints.

79 5.4 Resultados 75 Após o estudo de caso constatou-se a necessidade de uma avaliação mais elaborada sobre a ferramenta. Desta forma, conduzimos um experimento controlado que avalia a ferramenta AutoWebS no processo de criação de um conjunto de serviços Web semânticos, confrontando-a com uma suíte de aplicativos que se propõe a realizar as mesmas atividades que o AutoWebS. O experimento controlado é apresentado no Capítulo 6.

80 Experimento Controlado CAPÍTULO 6 Este capítulo apresenta um experimento controlado que avalia o AutoWebS em relação a uma suíte de aplicativos composta pelo OWL-S Editor [Elenius et al., 2005], um plugin do software Protégé [Noy et al., 2000] que é amplamente utilizado para criação de ontologias OWL-S, e o plugin Axis2 da IDE Eclipse, usado para criar serviços Web. Os objetivos deste experimento controlado são: (i) obter um indicativo da qualidade dos artefatos de códigos gerados pela ferramenta AutoWebS; (ii) comparar os tempos de desenvolvimento de serviços Web semânticos obtidos pela ferramenta AutoWebS e pela suíte de aplicativos; (iii) mensurar o esforço despendido e a dificuldade no uso da ferramenta AutoWebS e na suíte de aplicativos OWL-S Editor e Axis2; (iv) verificar se abordagem de integração de ferramentas para criação de serviços Web semânticos é mais eficiente do que a abordagem tradicional. O experimento contou com a participação de dois participantes com perfis semelhantes, ou seja, os participantes apresentam o mesmo conhecimento a respeito das tecnologias de serviços Web semânticos. Os participantes conhecem bem a linguagem UML e já tiveram algum contato com a linguagem OWL e OWL-S. O experimento foi aplicado separadamente em cada indivíduo e utilizou o plano experimental quadrados latinos [Fang et al., 2006], pois existem dois fatores de ruído com influência significante na variável de saída: (i) experiência do usuário com as tecnologias dos serviços Web semânticos e (ii) a complexidade das tarefas envolvidas na execução do experimento. Para execução do experimento foram usados oito projetos de serviços Web semânticos que foram implementados usando-se o AutoWebS e a suíte de aplicativos, totalizando 16 execuções do experimento. Para análise dos resultados foi usado o teste estatístico nãoparamétrico de Wilcoxon [Corder and Foreman, 2009]. O restante deste capítulo está estruturado com se segue: A Seção 6.1 apresenta as ferramentas escolhidas para realização do experimento controlado; a Seção 6.2 apresenta os projetos dos serviços Web semânticos usados na condução do experimento; a Seção 6.3 descreve o planejamento do experimento; a Seção 6.4 apresenta a execução do experimento; a Seção 6.5 relata as análises e interpretações dos dados obtidos da execução do experimento.

81 6.1 Ferramentas Avaliadas Ferramentas Avaliadas O experimento avaliou a ferramenta AutoWebS (ver Seção 4) e uma suíte de ferramentas composta pelos plugins Axis2 para IDE Eclipse 1 e OWL-S Editor do software Protégé. Juntos, os plugins Axis2 e OWL-S Editor, tradicionalmente são usados para o desenvolvimento de um serviço Web semântico da seguinte forma: (i) primeiramente cria-se o serviço Web com o uso do plugin Axis2 para IDE Eclipse e (ii) depois cria-se a ontologia ou descrição semântica do serviço Web através do OWL-S Editor do Protégé. Desta forma, para este experimento controlado, consideramos a suíte de aplicativos formada pelos plugins OWL-S Editor do Protégé e Axis2 da IDE Eclipse. 6.2 Projetos de Serviços Web Semânticos Para execução do experimento foram usados oito projetos de serviços Web semânticos que foram implementados usando-se o AutoWebS e a suíte de aplicativos. O projeto de um serviço Web semântico (ou especificação) forne uma descrição textual da interface do serviço Web e dos conceitos usados nas ontologias OWL para descreve-lo semanticamente. Para cada projeto são apresentadas as ontologias e a especificação da interface do serviço Web, detalhando seus inputs, outputs e preconditions, quando existirem. Dentre os projetos usados no experimento controlado, apresentados em seguida, os dois primeiros projetos usam a ontologia de domínio OilExploration, desenvolvida para estudos de caso da plataforma OpenCOPI (ver Seção 5). Os demais projetos usam ontologias públicas e de livre acesso, contidas nos exemplos da API OWL-S 2. Nas próximas seções são apresentados os projetos de serviço Web semânticos.estão representadas em documentos OWL Serviço Web semântico OilMonitor 1 Ontologia de Domínio A ontologia de domínio é a OilExploration (ver Seção 5) que representa os conceitos do domínio de Petróleo e Gás. Serviço Web O serviço Web chamado de WellDatabase fornece informações sobre os poços de petróleo. Esta serviço é responsável por fornecer o valor atual da carga de petróleo em cada unidade de bombeio mecânico (UB) através da operação subscribeburdenassyncservice. Esta operação tem como parâmetros de entrada OilWell e PumpUnit da ontologia OilExploration. O retorno da operação é um tipo Regime da ontologia OilExploration

82 6.2 Projetos de Serviços Web Semânticos Serviço Web semântico OilMonitor 2 Ontologia de Domínio A ontologia de domínio é a OilExploration (ver Seção 5) que representa os conceitos do domínio de Petróleo e Gás. Serviço Web O serviço Web HRDabase fornece informações sobre os funcionários como, por exemplo, quais funcionários estão em serviço em um determinado momento. Esse serviço tem duas operações: searchresponsibleengineerservice com o parâmetro de entrada Field da ontologia OilExploration e o retorno Engineer da ontologia OilExploration; e a operação searchavailableemployeeservice, com o parâmetro de entrada Field da ontologia OilExploration e retorno Employee da ontologia OilExploration Serviço Web semântico Book Finder Ontologia de Domínio Este projeto utiliza a ontologia de domínio BibTex que representa os conceitos e relacionamentos destes conceitos no domínio da linguagem BibTex para o gerenciamento e formatação de referencias bibliográficas. Serviço Web O serviço Web LookyBookService retorna as informações de um livro a partir de um título. O serviço contém uma operação chamada de DoKeywordSearch que usa uma busca baseada em palavra chave a partir da sequência de entrada, codificado como um String, e retorna um tipo Book da ontologia BibTex. Nas classes OWL Book estão definidas as informações do livro contendo o número ISBN, nome do autor e informações do editor Serviço Web semântico Zip Code Finder Ontologia de Domínio Este projeto utiliza a ontologia de domínio Zip Code que define os conceitos relacionados ao domínio de código de endereçamento postal. Serviço Web O serviço Web ZipCode retorna o código postal para uma cidade/estado. Se houver mais de um código postal associado a uma determinada cidade, apenas o primeiro é retornado. O serviço contém uma operação chamada de ListByCity que recebe como entrada o nome da cidade e do estado, codificados como duas Strings. O retorno da operação é um elemento ZipCode da ontologia Zip Code Serviço Web semântico Latitude Longitude Finder Ontologias de Domínio Este projeto usa as ontologias Zip Code e FactBook. A ontologia Zip Code define os conceitos relacionados ao domínio de códigos de endereçamento postal. A ontologia FactBook define os conceitos do domínio de localização e posicionamento geográfico.

83 6.2 Projetos de Serviços Web Semânticos 79 Serviço Web O serviço Web ZipcodeLookupService retorna a latitude e longitude de um determinado código postal. A operação ZipToLatLong recebe como parâmetro de entrada um elemento ZipCode da ontologia Zip Code e retorna um elemento LatLong da ontologia FactBook Serviço Web semântico Barnes and Nobles Price Finder Ontologias de Domínio Este projeto usa as ontologias BibTex e Concepts. A ontologia BibTex representa os conceitos e relacionamentos destes conceitos no domínio da linguagem BibTex para o gerenciamento e formatação de referencias bibliográficas. A ontologia Concepts define os conceitos monetários e de transações financeiras. Serviço Web O serviço Web BNPrice retorna o preço de um livro. A operação GetBNQuote recebe como entrada um elemento Book da ontologia BibTex e retorna o seu preço como um elemento Price da ontologia Concepts. O preço é devolvido em dólares e se o ISBN dado não é encontrado em estoque, então o valor de -1 é retornado Serviço Web semântico BabelFish Translator Ontologia de Domínio Este projeto usa a ontologia BabelFishTranslator. Esta ontologia define os conceitos relacionados às diferentes línguas e traduções entre línguas. Serviço Web O serviço Web TranslatorService converte textos de uma língua para outra língua. Neste serviço, a operação gettranslation recebe como entrada dois parâmetros, o texto a ser traduzido, codificado como um String, e um elemento SupportedLanguage da ontologia BabelFishTranslator, que representa a língua do texto de entrada e a língua saída desejada. O retorna desta operação é a palavra traduzida codificada como String e um elemento SupportedLanguage da ontologia BabelFishTranslator. Neste serviço há um total de nove idiomas suportados pelo tradutor. A precondição do serviço, o elemento precondition SupportedLanguagePair definido na ontologia BabelFishTranslator, requer que o idioma de entrada e o idioma de saída sejam diferentes Serviço Web semântico Currency Converter Ontologias de Domínio Este projeto usa as ontologias Concepts e Currency. A ontologia Concepts define os conceitos monetários e de transações financeiras. A ontologia Currency define os conceitos monetários e moedas. Serviço Web O serviço Web CurrencyConverterService converte um determinado preço para outra moeda. A operação convertprice recebe como entrada os elementos

84 6.3 Planejamento do Experimento 80 Price da ontologia Concepts e Currency da ontologia Currency. O retorno desta operação é um elemento Price da ontologia Concepts. 6.3 Planejamento do Experimento O planejamento do experimento controlado seguiu a abordagem GQM (Goal/Question/Metric) [Basili et al., 1994]. Nesta abordagem, primeiramente são definidos os objetivos ou metas (Goals) a serem alcançados com o experimento. Em uma segunda etapa, são formuladas questões (Questions) que devem ser respondidas para alcançar os objetivos traçados. Por fim, as métricas (Metrics) são estabelecidas para tornar possível mensurar as questões levantadas Objetivos Os objetivos deste experimento controlado são: 1. Obter um indicativo da qualidade dos artefatos de códigos gerados pela ferramenta AutoWebS; 2. Comparar os tempos de desenvolvimento de serviços Web semânticos obtidos pela ferramenta AutoWebS e pela suíte de aplicativos; 3. Mensurar o esforço despendido e a dificuldade no uso da ferramenta AutoWebS e na suíte de aplicativos OWL-S Editor e Axis2; 4. Verificar se abordagem de integração de ferramentas para criação de serviços Web semânticos é mais eficiente do que a abordagem tradicional (desenvolvimento a partir de duas etapas, (i) criação do serviço Web e (ii) criação da ontologia do serviço Web) Questões a serem respondidas e métricas correspondentes Sobre a ferramenta Q1 Qual ferramenta é mais eficiente sob o ponto de vista da criação da ontologia do serviço Web? M1.1 Quantidade de problemas reportados durante a execução do experimento. M1.2 Correture da ontologia do serviço Web gerada pelas ferramentas. Sobre corretude entende-se a quantidade de elementos na ontologia do serviço Web que estão errados ou inconsistentes. Q2 Qual ferramenta gera a descrição semântica do serviço Web (ontologia do serviço Web) com a menor quantidade de erros?

85 6.3 Planejamento do Experimento 81 M2.1 Comparação da ontologia do serviço Web com um gabarito (ontologia previamente criada e validada para o serviço Web). Diferença entre o valor encontrado e o valor de referência (gabarito). Sobre o grau de dificuldade, tempo e esforço despendido na criação das diferentes ontologias dos serviços Web Q3 As ferramentas apresentaram variação expressiva quanto ao grau de dificuldade para criação das diferentes ontologias dos serviços Web? Qual ferramenta apresenta maior grau de dificuldade para criação das diferentes ontologias dos serviços Web? M3.1 Avaliação subjetiva realizada a partir de questionários. Q4 O uso da abordagem empregada pelo AutoWebS torna a criação de serviços Web semânticos mais rápida ao se comparar com a abordagem tradicional? Qual ferramenta proporciona a menor quantidade de tempo para criação da descrição semântica de um serviço Web? M4.1 Cronometrar o tempo total para a criação dos serviços Web semânticos. Q5 Qual das duas ferramentas necessita de um menor esforço despendido para criação da ontologia de serviços Web? M5.1 Avaliação subjetiva. M5.2 Quantidade de problemas reportados. Sobre o uso da ferramenta Q6 A abordagem proposta pelo AutoWebS na utilização de UML para a modelagem de serviços Web semânticos é mais intuitiva do que a abordagem tradicional, empregada pela ferramenta OWL-S Editor? M6.1 Avaliação subjetiva. Q7 A abordagem MDD empregada pela ferramenta AutoWebS é satisfatória do ponto de vista do usuário? M7.1 Avaliação subjetiva do usuário. Q8 A integração das funcionalidades para o desenvolvimento de um serviço Web semântico em uma ferramenta contribui positivamente? M8.1 Avaliação subjetiva do usuário.

86 6.3 Planejamento do Experimento Hipóteses As seguintes hipóteses deverão ser verificadas com os resultados do experimento: Alternativas H1 A ontologia do serviço Web criada com o auxílio do plugin OWL-S do Protégé apresenta menor quantidade de elementos errados ou inconsistentes do que a ontologia do serviço Web criada com o AutoWebS. H2 O tempo total necessário para criação de serviços Web semânticos utilizando a ferramenta AutoWebS é menor do que quando utilizado a suíte de aplicativos (Eclipse com Axis2 e plugin OWL-S do Protégé). H3 A integração das várias funcionalidades necessárias para criação de serviços Web semânticos contribui significativamente para o seu desenvolvimento. H4 A representação de ontologias como classes de um diagrama de classes da UML e, também, a representação da interface de um serviço Web e suas operações como um tipo interface da UML, torna sua compreensão mais fácil para usuários com conhecimento técnico não muito elevado sobre as tecnologias da Web semântica. Nulas H1 0 A ontologia do serviço Web criada com o auxílio do plugin OWL-S do Protégé não contribui para um número menor de elementos errados ou inconsistentes no arquivo OWL-S. H2 0 Não existe diferenças perceptíveis no tempo necessário para criação de serviços Web semânticos quando utilizado o AutoWebS. H3 0 A integração das várias funcionalidades necessárias para criação de serviços Web semânticos não contribui significativamente para o seu desenvolvimento. H4 0 O uso do perfil UML não torna a compreensão da ontologia de domínio e tão pouco da interface de um serviço Web, mais fáceis Variáveis Variáveis Independentes Existem duas variáveis independentes para este experimento: 1. Ferramenta 1 - AutoWebS 2. Ferramenta 2 - Eclipse com Axis2 + plugin OWL-S Protégé

87 6.3 Planejamento do Experimento 83 Não é interesse deste experimento a investigação do efeito das diferentes complexidades dos projetos de serviços Web semânticos, nem mesmo a investigação dos níveis de conhecimentos dos usuários. Desta forma, parte-se do pressuposto que os oito projetos utilizados na condução do experimento apresentam a mesma complexidade e que os usuários possuem o mesmo nível de conhecimento das tecnologias dos serviços Web semânticos. Variáveis Dependentes As variáveis dependentes foram estabelecidas para mensurar as questões levantadas. Neste estudo foram definidas as seguintes variáveis dependentes: 1. Quantidade total de erros ou inconsistências no arquivo OWL-S 2. Tempo total para criação dos serviços Web semântico. 3. Satisfação subjetiva do usuário. A quantidade total de erros ou inconsistências no arquivo OWL-S diz respeito à completude da ontologia OWL-S criada pela ferramenta. Em alguns casos como, por exemplo, quando se necessita de transformações XSLT, algumas ferramentas não criam esses scripts automaticamente. A variável satisfação subjetiva é medida através de um questionário aplicado após a execução do experimento. Variáveis Controladas Dois principais fatores podem afetar a condução do experimento. Duas variáveis controladas minimizam os efeitos destes fatores no experimento controlado. 1. Complexidade do projeto do serviço Web 2. Nível de conhecimento do participante sobre as tecnologias dos serviços Web semânticos Seleção dos Participantes e Treinamento O experimento controlado teve a participação de dois indivíduos. Os indivíduos, na época do experimento, possuíam conhecimentos básicos a respeito das tecnologias de serviços Web semânticos, conheciam as principais construções das linguagens OWL e OWL-S e dominavam a linguagem para modelagem UML. Foi oferecido um treinamento aos participantes do experimento sobre as ferramentas e linguagens utilizadas. O treinamento teve como objetivo apresentar noções básicas a respeito de cada ferramenta e as linguagens a fim de nivelar o conhecimento dos indivíduos.

88 6.4 Operação do Experimento Local do Experimento e Recursos Os experimentos foram realizados em dois computadores, durante dois dias. Os recursos necessários também estavam disponíveis a todos os participantes. O mecanismo utilizado para cronometragem do tempo foi um timer instalado nos computadores. Este timer era acionado no início de cada execução do experimento e parado no seu término. Para verificar a quantidade de erros e inconsistências no arquivo OWL-S foi usado um gabarito, um arquivo OWL-S previamente criado e validado para cada projeto do serviço Web semântico Validade Validade Interna: como mencionado na Seção 6.3.5, para o experimento controlado se propõe a utilização de dois alunos da área de Computação que possuem conhecimentos básicos a respeito das tecnologias de serviços Web semânticos e conhecem as principais construções das linguagens OWL e OWL-S, além de dominar a linguagem para modelagem UML. Assim, assume-se que eles são representativos para a população dos desenvolvedores de serviços Web. Para redução da influência dos fatores que não são interesse do nosso estudo e, portanto, para aumento da validade interna do estudo usou-se os dados do questionário do perfil do participante (ver Seção 6.4.2) para escolha dos participantes que compartilham as mesmas características. Validade de Conclusão: são aplicados questionários de análise subjetiva sobre as ferramentas. Também, será realizado um teste estatístico dos resultados. Validade de Construção: o plano experimental e quantidade de participantes e réplicas são fatores importantes que podem ameaçar a validade deste experimento. Entretanto, adequamos este experimento a nossa realidade e não generalizaremos os resultados. Validade Externa: os projetos usados no experimento são representativos e amplamente usados na literatura. A suíte de aplicativos também é amplamente usada pela comunidade de desenvolvedores de serviços Web semânticos. 6.4 Operação do Experimento Plano Experimental Utilizamos o plano experimental Quadrados Latinos (ver Apêndice F), pois existem dois fatores de ruído com influência significante na variável de saída: (i) experiência do usuário com uso das tecnologias dos serviços Web e a (ii) complexidade dos projetos

89 6.4 Operação do Experimento 85 dos serviços Web. Este plano experimental ameniza a influências destes ruídos de forma a não comprometer os resultados do experimento. Neste plano experimental, os blocos possíveis são a combinação dos dois fatores de ruído do experimento, representados na Tabela 6.1. Pessoa m Pessoa n Projeto k Ferramenta a Ferramenta b Projeto l Ferramenta b Ferramenta a Tabela 6.1: Distribuição dos Blocos Na Tabela 6.1 m, n, a e b podem assumir os valores 1 ou 2 sendo que a é diferente de b, m é diferente de n. Já k e l podem assumir os valores entre 1 e 8 e k é diferente de l. O experimento tem quatro réplicas do quadrado, alternando-se as linhas (Projetos), totalizando oito observações ou repetições. Para definição das configurações de cada réplica foram realizados sorteios que definiram a ordem dos projetos, pessoas e ferramentas. Para o sorteio usamos a função sample 3 do software R [Zuur et al., 2009]. Atribuímos um valor numérico a cada projeto de acordo com sua apresentação neste documento. O mesmo acorreu para as pessoas e ferramentas. Logo em seguida os resultados dos sorteios para os projetos e pessoas: sample(1:8, 8, replace=f) [1] sample(1:2, 2, replace=f) [1] 1 2 Para cada réplica foram sorteadas as ferramentas e a ordem de execução. As réplicas são apresentadas a seguir: Pessoa 1 Pessoa 2 Serviço Web Semântico BabelFish Translator Ferramenta 1 (2) Ferramenta 2 (1) Serviço Web Semântico Book Finder Ferramenta 2 (1) Ferramenta 1(2) Tabela 6.2: Réplica l Pessoa 1 Pessoa 2 Serviço Web Semântico OilMonitor 2 Ferramenta 1 (2) Ferramenta 2 (1) Serviço Web Semântico Barnes and Nobles Price Ferramenta 2 (1) Ferramenta 1(2) Tabela 6.3: Réplica Questionário do Perfil do Participante Este questionário traça o perfil dos participantes do experimento e foi submetido previamente a todos os pretendentes do experimento. As informações presentes em 3

90 6.5 Análise e Interpretação dos Resultados 86 Pessoa 1 Pessoa 2 Serviço Web Semântico OilMonitor 1 Ferramenta 2 (1) Ferramenta 1 (2) Serviço Web Semântico Zip Code Finder Ferramenta 1 (2) Ferramenta 2(1) Tabela 6.4: Réplica 3 Pessoa 1 Pessoa 2 Serviço Web Semântico Currency Converter Ferramenta 1 (1) Ferramenta 2 (2) Serviço Web Semântico Zip Code Finder Ferramenta 2 (2) Ferramenta 1(1) Tabela 6.5: Réplica 4 cada questionário serviram para escolha dos dois participantes. A escolha levou em consideração a semelhança dos perfis dos candidatos e a suas disponibilidades de horário. O questionário do perfil do participante encontra-se no Apêndice E.1. Os dois participantes selecionados para o experimento controlado possuem grau de conhecimento intermediário a respeito das tecnologias de serviços Web, UML e perfis UML, linguagem Java e IDE Eclipse; conhecimento básico sobre Axis2, Web semântica, serviços Web semânticos, Ontologias, linguagem OWL, linguagem OWL-S, software Protege e linguagem XSLT; e nenhum conhecimento a respeito do plugin OWL-S Editor do Protege Questionário para Análise Subjetiva da Ferramenta e do Projeto do Serviço Web Este questionário tem como objetivo descobrir as opiniões dos participantes a respeito das ferramentas usadas no desenvolvimento de cada projeto do experimento controlado. Este questionário foi aplicado no término de cada desenvolvimento de projeto. O questionário para análise subjetiva encontra-se no Apêndice E Análise e Interpretação dos Resultados Apresentação dos Resultados A Tabela 6.6 apresenta os tempos necessários para o desenvolvimento de cada projeto de serviço Web semântico e a quantidade de erros ou inconsistências na ontologia de cada serviço Web. As ontologias dos serviços Web criadas pela ferramenta AutoWebS não apresentaram erros, exceto o serviço Web semântico BabelFish Translator que tem uma única operação que retorna uma palavra traduzida codificada como String e um elemento SupportedLanguage da ontologia BabelFishTranslator. Especificamente no serviço Web

91 6.5 Análise e Interpretação dos Resultados 87 AutoWebS Suíte Projeto tempo erros tempo erros Serviço Web semântico OilMonitor Serviço Web semântico OilMonitor Serviço Web semântico Book Finder Serviço Web semântico Zip Code Finder Serviço Web semântico Latitude Longitude Finder Serviço Web semântico Barnes and Nobles Serviço Web semântico BabelFish Translator Serviço Web semântico Currency Converter Tabela 6.6: Resultados obtidos na execução do experimento controlado semântico BabelFish Translator foi necessário realizar uma única adaptação na ontologia do serviço Web, pois o AutoWebS não criou automaticamente o script XSLT para propriedade xslttransformation. O participante do experimento modelou o retorno do serviço Web como um objeto de uma classe Retorno. Esta classe Retorno encapsula uma String e o elemento SupportedLanguage da ontologia BabelFishTranslator. Entretanto, o AutoWebS não cria scripts XSLT para elementos usados nos modelos UML que não foram importados de uma ontologia de domínio, ou seja, o AutoWebS só cria os scripts XLT para os elementos que tenham o estereótipo owl:class. Em todas as ontologias dos serviços Web criadas pela suíte de aplicativos Axis2 + OWL-S Editor foram constatados erros ou inconsistências. Nas ontologias foram necessárias adaptações no script XSLT da propriedade xslttransformation. O processo de criação das transformações XSLT, mesmo para elementos simples, é suscetível a erros e quando se usa o Axis2 para criar um serviço Web, sem se especificar configurações adicionais na execução de seus utilitários (wsdl2java e java2wsdl), são gerados namespaces aleatórios no documento WSDL. Por exemplo, no serviço Web OilMonitor 1 foi gerado o namespace ax22 enquanto que no serviço Web OilMonitor 2 foi gerado o namespace ax210. A Figura 6.1 ilustra o histograma do tempo consumido pelos participantes do experimento para o desenvolvimento de cada serviço Web semântico. Podemos perceber uma diferença entre os tempos quando foi usado o AutoWebS e a suíte de aplicativos para o desenvolvimento dos serviços Web semânticos. Em todos os casos o tempo de desenvolvimento usando-se o AutoWebS foi inferior ao tempo quando usada à suíte de aplicativos. O menor tempo obtido utilizando-se a ferramenta AutoWebS foi de 5 minutos para o serviço Web semântico Zip Code Finder. O mesmo serviço com a suíte de aplicativos demandou 21 minutos para ser desenvolvido, uma diferença de 16 minutas em relação ao AutoWebS. O maior tempo obtido utilizando-se a ferramenta AutoWebS foi de

92 6.5 Análise e Interpretação dos Resultados 88 Figura 6.1: Tempo de desenvolvimento dos serviços Web semânticos 20 minutos para o serviço Web semântico Book Finder enquanto que este mesmo serviço, quando desenvolvido com a suíte de aplicativos, demandou 35 minutos, uma diferença de 15 minutos. A Amplitude máxima dos tempos quando usada a ferramenta AutoWebS foi de 15 minutos para os serviços Web semânticos ZipCode e BookFinder. A Mediana foi de 8 minutos, a Média aritmética aproximadamente 10 minutos, o Desvio padrão foi de minutos e a Variância de minutos. Com a suíte de aplicativos, a Amplitude dos tempos foi de 41 minutos para os serviços Web semânticos Currency e OilMonitor2. A Mediana foi de 30 minutos, a Média aritmética foi de minutos, o Desvio padrão foi de minutos e a Variância de minutos Teste Estatístico Analisando-se para as médias dos tempos de desenvolvimento, têm-se à primeira vista, a impressão de que os tempos obtidos pela ferramenta AutoWebS (10 minutos) é menor do que quando usada a suíte de aplicativos (31,25 minutos). Contudo, pode não existir evidência estatística suficiente para tirar tal conclusão. Neste caso, para obtermos uma resposta com certo nível de confiança realizamos um teste estatístico nãoparamétrico chamado método de Wilcoxon [Corder and Foreman, 2009]. A Tabela 6.7 traz a distribuição dos tempos de desenvolvimento dos serviços Web semânticos e os cálculos do teste estatístico de Wilcoxon. Designamos D 1 e D 2 as distribuições dos tempos relativos às duas ferramentas, D 1 para AutoWebS e D 2 para suíte de aplicativos. Logo, temos como passos do método Wilcoxon, os seguintes: Hipótese nula H 0 : D 1 e D 2 não são iguais. D 1 encontra-se desviada para a esquerda de D 2 ou D 1 encontra-se desviada para direita de D 2. Hipótese alternativa H a : D 1 e D 2 são idênticas. Isto é, as duas distribuições de tempos são idênticas.

93 6.5 Análise e Interpretação dos Resultados 89 AutoWebS Suíte Diff Sinal Posto Posto*Diff OilMonitor OilMonitor BookFinder ZipCode LatLong BarnesAndNobles BabelFish Currency Tabela 6.7: Cálculo do teste estatístico de Wilcoxon Na Tabela 6.7, Diff representa o valor absoluto da diferença entre as amostras, Sinal denota o sinal desta diferença (+ ou -), Posto é o ranqueamento dos valores de Diff. Para estas amostras, temos que a estatística T + = 36, onde T + é a soma dos postos positivos, enquanto que T = 0, a soma dos postos negativos. O teste estatístico W é igual ao menor dos dois valores absolutos. Desta forma, o teste estatístico W, por conseguinte, é igual a T = 0. Utilizando a distribuição exata da estatística de Wilcoxon para uma única amostra, ilustrada na Figura 6.2, temos que, para α = 5% (α = 0.05), o valor crítico para W é 6 (seis) para uma amostra de tamanho 8 (8 pares de dados, n = 8). Figura 6.2: Valores Críticos W para o teste de Wilcoxon para amostras pequenas - extraído de [Lowry, 2012] Como no teste estatístico W(0) é menor que o W Crítico(6), podemos aceitar a Hipótese Nula H 0 e afirmar com pelo menos 95% de certeza que D 1 e D 2, as distribuições de tempos, não são iguais. Desta forma D 1 encontra-se desviada para a direita de D 2, ou seja, os tempos obtidos com a ferramenta AutoWebS foram inferiores aos tempos obtidos pela suíte de aplicativos OWL-S Editor e Axis2. O mesmo teste estatístico aplicado às distribuições de erros ou inconsistências nas ontologias OWL-S resultará em uma conclusão semelhante, ou seja, a quantidade

94 6.5 Análise e Interpretação dos Resultados 90 de erros ou inconsistências nas ontologias dos serviços Web geradas pela ferramenta AutoWebS é menor do que as ontologias geradas pela suíte de aplicativos. Nas distribuições de tempo e erros os valores obtidos para suíte de aplicativos foram sempre maiores ou iguais aos obtidos pelo AutoWebS Análise Qualitativa Para verificar a satisfação subjetiva do usuário em relação à ferramenta AutoWebS foi feita a análise qualitativa a partir do resultado dos questionários aplicados no término da execução de cada projeto de serviço Web semântico. A Figura 6.3 ilustra o grau de cansaço dos participantes durante o desenvolvimento dos serviços Web semânticos. Percebe-se que, quando foi usado o AutoWebS, em 7 casos os usuários assinalaram Sem Cansaço e em apena um caso foi assinalado como Normal o grau de cansaço. Quando usada a suíte de aplicativos, em quatro oportunidades os participantes avaliaram como Muito Cansativo, em três como Cansativo e em uma oportunidade como Normal o grau de cansaço. Figura 6.3: Grau de cansaço no desenvolvimento dos serviços Web semânticos Em relação ao grau de contribuição da ferramenta para o desenvolvimento do serviço Web semântico, ilustrado na Figura 6.4, os participantes assinalaram em sete oportunidades que a ferramenta AutoWebS Contribuiu Muito e em uma oportunidade que a ferramenta AutoWebS teve uma contribuição Normal. Com a suíte de aplicativos em quatro oportunidades os participantes julgaram que os aplicativos Contribuíram Pouco, em duas oportunidades Não Contribuíram e em outras duas teve uma contribuição Normal. Quando perguntados sobre o grau de dificuldade na criação dos serviços Web, os participantes responderam que quando foi usada a ferramenta AutoWebS em todos os casos foi Muito Fácil criar o serviço Web. Entretanto, quando foi usada a suíte de aplicativos os participantes responderam que em três ocasiões foi Difícil criar o serviço Web, em outras três ocasiões foi Normal o grau de dificuldade enquanto que em outras

95 6.5 Análise e Interpretação dos Resultados 91 Figura 6.4: Grau de contribuição da ferramenta para o desenvolvimento dos serviços Web semânticos duas ocasiões foi Fácil. A Figura 6.5 ilustra as respostas dos participantes sobre o grau de dificuldade na criação dos serviços Web. Figura 6.5: Grau de dificuldade em criar o serviço Web Para a criação da ontologia do serviço Web os participantes assinalaram que com a ferramenta AutoWebS em todos os casos foi Muito Fácil criar a ontologia, conforme ilustra a Figura 6.6. Porém, com a suíte de aplicativos em quatro oportunidades os usuários marcaram no questionário Muito Difícil, em três Difícil e em uma Fácil. Quando perguntados se os recursos oferecidos pelas ferramentas foram suficientes para o desenvolvimento dos serviços Web semânticos, os participantes responderam que em todos os projetos os recursos do AutoWebS foram suficientes. Enquanto que, quando usada a suíte de aplicativos, em quatro projetos de serviços Web semânticos os recursos não foram suficientes. A Figura 6.7 apresenta as respostas dos participantes a respeitos dos recursos oferecidos pelas ferramentas avaliadas. Em relação à opinião dos participantes se a abordagem implementada pela ferramenta contribuiu para o desenvolvimento dos projetos de serviços Web semânticos, os participantes responderam que em todos os casos o AutoWebS contribuiu positivamente. Entretanto, em apenas uma oportunidade os participantes afirmaram que a abordagem

96 6.5 Análise e Interpretação dos Resultados 92 Figura 6.6: Grau de dificuldade em criar a ontologia do serviço Web Figura 6.7: Recursos oferecidos pelas ferramentas avaliadas usada pela suíte de aplicativos contribuiu positivamente para o desenvolvimento do projeto de serviço Web semântico. A Figura 6.8 apresenta as respostas dos participantes. Pelos resultados das análises efetuadas constatou-se que estatisticamente existe uma diferença significativa na utilização das ferramentas. Assim, existem indícios de que o AutoWebS contribui positivamente para o desenvolvimento de serviços Web semânticos, uma vez que proporciona menos cansaço e torna a criação do serviço Web e da ontologia do serviço Web menos difíceis, comparando-se com a suíte de aplicativos Verificação da Hipóteses A partir das análises estatísticas e qualitativas dos resultados, podemos procurar respostas as questões levantadas (Q1, Q2, Q3, Q4, Q5, Q6, Q7 e Q8) e sustentar ou não as hipóteses. Para verificar a hipótese H1 ( A ontologia do serviço Web criada com o auxílio do plugin OWL-S do Protégé apresenta menor quantidade de elementos errados ou inconsistentes do que quando a ontologia criada com o AutoWebS ) usamos as respostas

97 6.5 Análise e Interpretação dos Resultados 93 Figura 6.8: Contribuição para o desenvolvimento do serviço Web semântico das questões Q1 e Q2 através das métricas M1.1, M1.2 e M2.1. As métricas determinam a quantidade de erros ou inconsistências nas ontologias dos serviços Web e as suas acurácias - as diferenças entre os valores encontrados e os valores de referência. A partir dos dados da Tabela 6.6 podemos concluir que para todos os projetos de serviços Web semânticos os valores das métricas M2.1 para ferramenta AutoWebS foram menores ou iguais quando se usada a suíte de aplicativos. Desta forma, rejeitamos a hipótese alternativa H1 e aceitamos a hipótese nula H1 0. A hipótese H2 ( O tempo total necessário para criação de serviços Web semânticos utilizando a ferramenta AutoWebS é menor do que quando utilizado a suíte de aplicativos ) pode ser verificada com a resposta da questão Q4 através da métrica M4.1 (tempo total para criação dos serviços Web semânticos). A partir dos dados da Tabela 6.6 podemos concluir que o tempo total para o desenvolvimento (métrica M4.1) dos projetos de serviços Web semânticos quando usada a ferramenta AutoWebS foi menor do que quando usada a suíte de aplicativos. Portanto, não podemos rejeitar a hipótese alternativa H2, mas podemos rejeitar a hipótese nula H2 0, uma vez que existem dados estatísticos que indicam a diferença de tempo. Para verificar a hipótese H3 ( A integração das várias funcionalidades necessárias para criação de serviços Web semânticos contribui significativamente para o seu desenvolvimento ) usamos as respostas das questões Q5 e Q8 através das métricas M5.1, M5.2 e M8.1. Conforme análise do grau de contribuição da ferramenta para o desenvolvimento dos serviços Web semânticos, isto é, da criação do serviço Web e da sua ontologia, além do cansaço e esforço despendido, nos gráficos das Figuras 6.5, 6.6 e 6.3, observamos que a integração das funcionalidades necessárias para criação de serviços Web semânticos contribui positivamente para o seu desenvolvimento. Assim, sustentamos a hipótese H3 e rejeitamos a hipótese nula H3 0. A hipótese H4 ( A representação de ontologias como classes de um diagrama de classes da UML e, também, a representação da interface de um serviço Web e suas

98 6.5 Análise e Interpretação dos Resultados 94 operações como um tipo interface da UML, torna sua compreensão mais fácil para usuários com conhecimento técnico não muito elevado sobre as tecnologias da Web semântica ) pode ser analisada a partir das respostas das questões Q3, Q6, Q5 e Q7. A questão Q3 pode ser respondida através da métrica M3.1 e, conforme apresentado no gráfico da Figura 6.3, o grau de esforço despendido para o desenvolvimento dos serviços Web semânticos quando usada a suíte de aplicativos foi sempre maior do que quando usado o AutoWebS. Para as questões Q6 e Q7 existem as métricas M6.1 e M7.1 que avaliam a satisfação subjetiva do usuário quanto ao uso das ferramentas. A métrica M6.1 diz respeito a abordagem implementada pela ferramenta e, conforme mostra o gráfico da Figura 6.8, em todos os projetos os participantes afirmaram que a abordagem usada pela ferramenta AutoWebS foi suficiente, enquanto que em apenas um caso os participantes afirmaram que a abordagem usada pela suíte de aplicativos é mais intuitiva. Sobre a métrica M7.1 que mede a satisfação do participante em relação a abordagem empregada pelas ferramentas, podemos inferir dos gráficos da Figura 6.8 e da Figura 6.7 que o AutoWebS é mais satisfatório do ponto de vista do usuário do a suíte de aplicativos. A partir dessas métricas podemos manter a hipótese H4 e rejeitar a hipótese nula H4 0.

99 Trabalhos Relacionados CAPÍTULO 7 Na literatura existem vários trabalhos que exploram diversos aspectos dos serviços Web semânticos. Entretanto, para se fazer uma comparação com a ferramenta AutoWebS, selecionamos alguns principais trabalhos que apresentam abordagens para a criação de serviços Web semânticos (serviços Web semânticos atômicos). Outros aspectos dos serviços Web semânticos como, por exemplo, descoberta e composição de serviços Web e similaridade semântica, fogem do escopo deste trabalho e, portanto, não são alvos de estudo e comparação com a ferramenta proposta. Este capítulo está estruturado como se segue. A Seção 7.1 apresenta a ferramenta OWL-S Editor. A Seção 7.2 apresenta a ferramenta CODE. A Seção 7.3 apresenta a ferramenta ASSAM. A Seção 7.4 apresenta a abordagem desenvolvida por Yang e Chung. A Seção 7.5 apresenta a abordagem criada por Kim e Lee. Por fim, a Seção 7.6 apresenta uma comparação entre os trabalhos relacionados e o AutoWebS, levando-se em consideração os requisitos para uma ferramenta de alto nível de abstração para a criação de serviços Web semântico levantados na introdução deste trabalho. 7.1 OWL-S Editor OWL-S Editor [Elenius et al., 2005] é uma ferramenta integrada ao software Protégé - o principal software para criação de ontologias. OWL-S Editor foi desenvolvido como um plugin do Protégé e sua principal característica é proporcionar em um mesmo ambiente, utilitários para a criação de uma ontologia de domínio e, também, para o desenvolvimento da descrição semântica do serviço Web. A ferramenta OWL-S Editor proporciona somente a criação da ontologia do serviço Web a partir de um conjunto de visões (views), cada visão para uma subontologia OWL-S. Cada visão fornece um conjunto de campos para inserção de valores para os elementos da subontologia associada, conforme a Figura 7.1 ilustra. As visões requerem do usuário um profundo conhecimento a respeito da linguagem OWL-S. A visão associada à subontologia Service Model utiliza um editor visual do tipo drag-and-drop para criar processos Composite utilizando as estruturas de controle

100 7.1 OWL-S Editor 96 Figura 7.1: Ferramenta OWL-S Editor da linguagem OWL-S. A ferramenta também oferece um mecanismo para importar um documento WSDL e gerar um esqueleto da descrição semântica em OWL-S. Este esqueleto pode então, ser incrementalmente associado a conceitos de ontologias de domínio. O mecanismo de importação utiliza o transformador WSDL2OWLS 1 da API OWL-S da Mindswap. A ferramenta OWL-S Editor não oferece um mecanismo eficiente para a criação do mapeamento em XSLT entre os inputs e outputs do serviço Web, definidos como tipos complexos no Schema XML do documento WSDL, e os conceitos definidos como classes no documento OWL. Dessa forma, esses mapeamentos, que não são fáceis e intuitivos de serem desenvolvidos, devem ser escritos manualmente. A arquitetura da ferramenta Protégé provê um suporte básico à integração de novas funcionalidades. O código fonte do plugin OWL-S Editor está disponível sobre a licença Mozilla Public License 1.1 e seu último release, a versão build26, data de agosto de