M od el oUNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTEDEPARTAMENTO DE INFORMÁTICA E MATEMÁTICAAPLICADA - DIMAPTHIAGO PEREIRA DA SILVA AutoWebS Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos Natal - RN 2012                                 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 5o da Lei no 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 2012. Thiago Pereira da Silva – Autor Thaís Vasconcelos Batista – Orientadora 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 Universi- dade Federal do Rio Grande do Norte, como requisito par- cial para obtenção do título de Mestre em Sistemas e Com- putação. Área de concentração: Engenharia de Software. Orientadora: Profa. Thaís Vasconcelos Batista Natal - RN 2012 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 Departa- mento 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 professo- res: 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 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 Rodri- gues, Ana Luisa, Gustavo, Eduardo e Lucas Silva agradeço os conselhos, ensinamentos e companhia. A CAPES pelo apoio financeiro despendido a este trabalho. Resumo da Silva, Thiago Pereira. AutoWebS: Um Ambiente para Modelagem e Ge- ração Automática de Serviços Web Semânticos. Natal - RN, 2012. 159p. Dis- sertaçã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 in- terfaces 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, in- vocaçã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 tra- balho 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 disponi- biliza 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 Abstract da Silva, Thiago Pereira. AutoWebS: Um Ambiente para Modelagem e Gera- ção Automática de Serviços Web Semânticos. Natal - RN, 2012. 159p. 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 interfa- ces. 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 on- tologies 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 ser- vices. 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 Sumário Lista de Figuras 9 Lista de Tabelas 11 Lista de Códigos de Programas 12 1 Introdução 13 1.1 Objetivos 16 1.2 Estrutura do Documento 17 2 Fundamentação Teórica 19 2.1 Serviço Web 19 2.2 Web Semântica 19 2.2.1 RDF e RDF Schema 21 2.2.2 Ontologia 24 2.2.3 OWL 25 2.2.4 Serviços Web Semânticos 29 2.3 OWL-S 29 2.3.1 Service Profile 31 2.3.2 Service Model 33 2.3.3 Service Grounding 36 2.4 Desenvolvimento de Software Dirigido por Modelos 40 3 Mapeamento entre OWL e UML 43 3.1 Mapeamento entre as linguagens de especificação de ontologias e a UML 43 3.2 Mapeamento entre OWL e UML 46 4 Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos 50 4.1 Requisitos de uma ferramenta para criação de serviços Web semânticos 50 4.2 Visão Geral da Ferramenta 52 4.3 Arquitetura 54 4.4 Perfil UML 56 4.5 Importação das Ontologias OWL 58 4.6 Metamodelo da Linguagem OWL-S 60 4.7 Implementação das Regras de Mapeamento entre UML e OWL-S 63 4.8 Funcionamento da Ferramenta 65 5 Estudo de Caso 67 5.1 Sistemas de middleware de provisão de contexto 67 5.2 Ontologia de Domínio 69 5.3 Modelagem do Serviço Web Semântico 71 5.4 Resultados 74 6 Experimento Controlado 76 6.1 Ferramentas Avaliadas 77 6.2 Projetos de Serviços Web Semânticos 77 6.2.1 Serviço Web semântico OilMonitor 1 77 6.2.2 Serviço Web semântico OilMonitor 2 78 6.2.3 Serviço Web semântico Book Finder 78 6.2.4 Serviço Web semântico Zip Code Finder 78 6.2.5 Serviço Web semântico Latitude Longitude Finder 78 6.2.6 Serviço Web semântico Barnes and Nobles Price Finder 79 6.2.7 Serviço Web semântico BabelFish Translator 79 6.2.8 Serviço Web semântico Currency Converter 79 6.3 Planejamento do Experimento 80 6.3.1 Objetivos 80 6.3.2 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 81 6.3.3 Hipóteses 82 Alternativas 82 Nulas 82 6.3.4 Variáveis 82 Variáveis Independentes 82 Variáveis Dependentes 83 Variáveis Controladas 83 6.3.5 Seleção dos Participantes e Treinamento 83 6.3.6 Local do Experimento e Recursos 84 6.3.7 Validade 84 6.4 Operação do Experimento 84 6.4.1 Plano Experimental 84 6.4.2 Questionário do Perfil do Participante 85 6.4.3 Questionário para Análise Subjetiva da Ferramenta e do Projeto do Serviço Web 86 6.5 Análise e Interpretação dos Resultados 86 6.5.1 Apresentação dos Resultados 86 6.5.2 Teste Estatístico 88 6.5.3 Análise Qualitativa 90 6.5.4 Verificação da Hipóteses 92 7 Trabalhos Relacionados 95 7.1 OWL-S Editor 95 7.2 CODE - CMU’s OWL-S Development Environment 97 7.3 ASSAM - Automated Semantic Service Annotation with Machine Learning 98 7.4 Yang e Chung 99 7.5 Kim e Lee 100 7.6 Comparação entre as ferramentas 101 8 Conclusão 105 8.1 Contribuições 107 8.2 Limitações 108 8.3 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 Lista de Figuras 2.1 Arquitetura de um serviço Web - retirado de [Wikipedia, 2011] 20 2.2 Principais tecnologias da Web semântica 20 2.3 Exemplo de um grafo em RDF - ilustração retirada de [Manola and Miller, 2004] 22 2.4 Dialetos da OWL 25 2.5 Relação entre classes OWL 27 2.6 Subontologias da OWL-S - extraído de [Burstein et al., 2004] 30 2.7 OWL-S Service Profile - extraído de [Burstein et al., 2004] 33 2.8 Subontologia OWL-S ServiceModel - extraído de [Burstein et al., 2004] 34 2.9 Grounding OWL-S/WSDL - extraído de [Burstein et al., 2004] 37 2.10 Classes e propriedades da subontologia OWL-S ServiceGrounding 38 2.11 Transformações entre modelos 40 3.1 Exemplo de mapeamento entre OWL eUML 49 4.1 Visão geral da ferramenta AutoWebS 53 4.2 Arquitetura da ferramenta AutoWebS 55 4.3 Perfil UML usado pela ferramenta AutoWebS 57 4.4 Ontologia BibTex representada como UML 59 4.5 Mapeamento da classe OWL em UML 60 4.6 Metamodelo OWL-S 61 4.7 Transformação de UML para OWL-S 64 4.8 Funcionamento do AutoWebS 65 5.1 Arquitetura do OpenCOPI - extraído de [Lopes et al., 2009b] 69 5.2 Ontologia de domínio OilExploration 70 5.3 Trecho da ontologia de domínio OilExploration 71 5.4 Atividades realizadas para o estudo e caso 71 5.5 Trecho da ontologia de domínio OilExploration 72 5.6 Artefatos de códigos gerados 73 5.7 Implementação da regra de negócio do serviço Web 74 6.1 Tempo de desenvolvimento dos serviços Web semânticos 88 6.2 Valores Críticos W para o teste de Wilcoxon para amostras pequenas - extraído de [Lowry, 2012] 89 6.3 Grau de cansaço no desenvolvimento dos serviços Web semânticos 90 6.4 Grau de contribuição da ferramenta para o desenvolvimento dos serviços Web semânticos 91 6.5 Grau de dificuldade em criar o serviço Web 91 6.6 Grau de dificuldade em criar a ontologia do serviço Web 92 6.7 Recursos oferecidos pelas ferramentas avaliadas 92 6.8 Contribuição para o desenvolvimento do serviço Web semântico 93 7.1 Ferramenta OWL-S Editor 96 7.2 Arquitetura da ferramenta CODE - extraído de [Srinivasan et al., 2005] 97 7.3 Ferramenta ASSAM - extraído de [Heß et al., 2004] 99 7.4 Abordagem de Yang e Chung para construção de serviços Web semânti- cos - extraído de [Yang and Chung, 2006b] 100 7.5 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 1.1 128 F.1 Exemplo de quadrado latino de tamanho 4 158 Lista de Tabelas 2.1 Mudanças das características da Web semântica 21 3.1 Mapeamento entre UML e os principais conceitos das linguagens para especificação de ontologias 44 3.2 Mapeamento entre o elemento owl:Ontology e a UML 46 3.3 Mapeamento entre as construções de classes OWL e a UML 47 3.4 Mapeamento entre o elemento owl:Restriction e a UML 47 3.5 Mapeamento entre os elementos owl:ObjectProperty e owl:DatatypeProperty e a UML 48 3.6 Mapeamento entre alguns elementos da OWL e a UML 48 3.7 Mapeamento dos tipos de dados do Schema XML e a UML 49 6.1 Distribuição dos Blocos 85 6.2 Réplica l 85 6.3 Réplica 2 85 6.4 Réplica 3 86 6.5 Réplica 4 86 6.6 Resultados obtidos na execução do experimento controlado 87 6.7 Cálculo do teste estatístico de Wilcoxon 89 7.1 Comparação entre os trabalhos relacionados 101 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] 23 2.2 Declaração do cabeçalho de um documento OWL 26 2.3 Declaração de uma classe e suas propriedades em OWL 28 2.4 Instância da classe Regime 29 2.5 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 CAPÍTULO 1 Introdução 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 con- ceitos 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 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 Lan- guage 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 lin- guagens 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 abor- dagens 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ân- ticos devem definir abordagens para abstrair as tecnologias subjacentes usadas no desen- volvimento 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 fer- ramenta 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 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 com- plexidade inerente do emprego de ontologias para especificação de serviços Web semân- ticos, 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 Lan- guage) é 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 espe- cificaçã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 se- melhantes como, por exemplo, classes, associações entre classes, propriedades de clas- ses, 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 se- mâ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 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 proprieda- des 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. 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 in- terface 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 é am- plamente 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. 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 tec- nologias 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. CAPÍTULO 2 Fundamentação Teórica Este capítulo descreve sucintamente as principais tecnologias usadas nesse tra- balho. 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 apresenta- dos 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 Ob- ject Access Protocol) [Mitra, 2003] codificadas em um arquivo XML, mandadas atra- vé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 (Uni- versal 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 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. AWeb Semântica estende aWeb tradicional, baseada em redes de hiperlinks, adicionando metadados1 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 ilus- trado 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 inter- relaçõ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 1dados estruturados que descrevem a característica de um recurso 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. 2.2.1 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 exem- plo, retirado da W3C Recommendation [Manola and Miller, 2004]. 2.2 Web Semântica 22 “there is a Person identifi ed byhttp://www.w3.org/People/EM/contact#me, whose name is Eric Miller, whose email 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 "http://www.w3.org/People/EM/contact#me", ou seja, um URI. O sujeito RDF pos- sui um tipo Person que está definido no URI htt p : //www.w3.org/2000/10/swap/pim/contact#Person. Esta afirmação relaciona al- guns objetos: Eric Miller que possui o predicado "whose name is"; em@w3.org com o predicado "whose email address is"; Dr. com o predicado "whose title is". Os predicados da afirmação estão associados às seguintes URIs: whose name is http://www.w3.org/2000/10/swap/pim/contact#fullName whose email address is http://www.w3.org/2000/10/swap/pim/contact#mailbox whose title is http://www.w3.org/2000/10/swap/pim/contact#personalTitle 2.2 Web Semântica 23 Desta forma, utilizando as URIs, podemos expressar as seguintes triplas RDFs: • http://www.w3.org/People/EM/contact#me, http://www.w3.org/2000/10/swap/pim/contact#fullName, Eric Miller • http://www.w3.org/People/EM/contact#me, http://www.w3.org/2000/10/swap/pim/contact#personalTitle, Dr. • http://www.w3.org/People/EM/contact#me, http://www.w3.org/1999/02/22-rdf-syntax-ns#type, http://www.w3.org/2000/10/swap/pim/contact#Person • http://www.w3.org/People/EM/contact#me, http://www.w3.org/2000/10/swap/pim/contact#mailbox, em@w3.org 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 2 4 5 6 Eric Miller 7 8 Dr. 9 10 11 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 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. 2.2.2 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 indi- ví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 quan- tidade 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 infor- mações em um domínio, propicia o reuso do conhecimento deste domínio além de ex- plicitar 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 conheci- mento. O uso de ontologias é mais visível em aplicações de inteligência artificial, enge- 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 en- tre 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. 2.2.3 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: 2.2 Web Semântica 26 Indivíduos representam objetos no domínio de interesse. São instâncias de uma determi- nada 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 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 2 10 11 12 13 Comentario 14 15 Autor 16 17 ... 18 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. 2.2 Web Semântica 28 Código 2.3 Declaração de uma classe e suas propriedades em OWL 1 ... 2 ... 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ... 27 ... O Código 2.4 ilustra a declaração de uma instância da classe Regime. Esta instância é identificada por Regime_5. 2.3 OWL-S 29 Código 2.4 Instância da classe Regime 1 ... 2 3 4 25 5 6 59 7 8 5 9 10 50 11 12 ... 2.2.4 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 me- canismos 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ân- tica 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 ser- viç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 2.3 OWL-S 30 especificadas, por intermédio de uma descrição formal das suas propriedades e capacida- des [Burstein et al., 2004]. O último release da especificação OWL-S é a versão 1.2, de dezembro de 2008. 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 ex- pressar ”o que o serviço faz“, para fi ns de publicidade, construção de requisições do serviço, e matchmaking2; 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 ontolo- gia ServiceModel com as especificações detalhadas dos formatos de mensagens, pro- tocolos, 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. 2Processo de busca dos possíveis casamentos entre demandas/requisições e ofertas/serviços, em um dado domínio de aplicação. 2.3 OWL-S 31 2.3.1 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, infor- maçõ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) requi- sitadas 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 disponi- bilidade 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 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 Proces- sModel 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 refe- renciar 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 ins- tâ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. 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 ofe- rece, 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 ummecanismo 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. 2.3.2 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 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), represen- tando 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 pro- cesso 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. 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 pre- conditions 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 cons- truçã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 proces- sos, 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. 2.3 OWL-S 36 2.3.3 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 associ- adas. 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 tro- cam 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 men- sagens XML que são enviadas pela rede e também especifica como o receptor pode inter- pretar 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 tra- duçã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 de- talhes 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 in- teragir 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 represen- taçõ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. 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 corres- ponde a uma operação do tipo one-way. • Um processo do tipo Atomic Process com outputs, mas sem inputs corres- ponde 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. 2.3 OWL-S 38 Figura 2.10: Classes e propriedades da subontologia OWL-S Ser- viceGrounding A classeWsdlGrounding é uma subclasse de ServiceGrounding. Seu papel é for- nece um mecanismo para que as principais construções do arquivo WSDL possam ser re- ferenciadas emOWL-S. Cada instância da classeWsdlGrounding contém uma lista de ins- tâ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 comWSDL 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- 2.3 OWL-S 39 ficar um Port3 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 res- tringir 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. Con- forme 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 pro- priedade 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 corres- pondê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 refe- renciado 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 3Port define o ponto de conexão (EndPoint) com um serviço Web. 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 desenvol- vimento 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 comu- nicaçã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 desen- volvimento de software. Segundo Stahl e Voelter [Stahl and Völter, 2006], as principais características do MDD são: alta produtividade, portabilidade, interoperabilidade e reu- sabilidade. 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 re- gras de transformações entre os modelos. Os modelos são descritos por metamode- los 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 lin- guagens estão inseridas. Figura 2.11: Transformações entre modelos 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 { 7 ... 8 } 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. 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 me- tamodelos; 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. CAPÍTULO 3 Mapeamento entre OWL e UML 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 direta- mente 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 espe- cificaçã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 mo- delagem com diferentes propósitos, que os tornam adequados para especificar aspec- tos 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- 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 clas- ses 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 ontolo- gias definem uma notação para representação de conhecimento, mas ambas são lin- guagens 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 simi- laridades 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 prin- cipais construções utilizadas por linguagens de especificação de ontologias, conforme representado na Tabela 3.1. UML Construções ontológicas Packages Ontologies Classes Classes Attributes, associations and classes Properties Navigable Domain, Range Note Comment Multiplicity Cardinality Data types Data types Objects 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 po- dem ter múltiplas representações em UML devido a grande expressividade das lingua- gens de especificação de ontologias. Por exemplo, na linguagem OWL as propriedades que especificam restrições (Restriction) do tipo intersectionOf, unionOf e complemen- tOf, são construções para formação de uma classe a partir de uma combinação boole- 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 defi- nição de ontologias. A especificação ODM é aplicável a representação do conhe- cimento, 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ência1 (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 1Sã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. 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 apre- sentado 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. 3.2 Mapeamento entre OWL e UML 47 Construções OWL UML owl:Class classe UML owl:Class rdf:ID nome da classe owl:Class rdfs:subClassOf Generalização de uma classe owl:Class owl:oneOf define um tipo Enumeration UML owl:Class owl:equivalentClass não se aplica owl:Class owl:disjointWith não se aplica owl:Class owl:intersectionOf não se aplica owl:Class owl:unionOf Dependency UML owl:Class owl:complementOf 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 UML owl:Restriction restrições aplicadas em uma classe owl:Restriction owl:allValuesFrom não se aplica owl:Restriction owl:someValuesFrom não se aplica owl:Restriction owl:hasValue não se aplica owl:Restriction owl:maxCardinality multiplicidade owl:Restriction owl:minCardinality multiplicidade owl:Restriction owl:cardinality 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 3.2 Mapeamento entre OWL e UML 48 Construções OWL UML owl:ObjectProperty atributo de uma classe owl:ObjectProperty rdf:ID nome do atributo owl:ObjectProperty rdfs:range tipo do atributo. owl:ObjectProperty rdfs:domain classe que contém o atributo owl:ObjectProperty rdfs:subPropertyOf não se aplica owl:ObjectProperty owl:equivalentProperty não se aplica owl:ObjectProperty owl:inverseOf não se aplica owl:DatatypeProperty atributo de uma classe owl:DatatypeProperty rdf:ID nome do atributo owl:DatatypeProperty rdfs:domain classe que contém o atributo owl:DatatypeProperty rdfs:range o tipo do atributo construções para indivíduos OWL não se aplica Tabela 3.5: Mapeamento entre os elementos owl:ObjectProperty e owl:DatatypeProperty e a UML Construções OWL UML owl:FunctionalProperty não se aplica owl:InverseFunctionalProperty não se aplica owl:TransitiveProperty não se aplica owl:SymmetricProperty não se aplica owl:AnnotationProperty não se aplica owl:backwardCompatibleWith não se aplica owl:incompatibleWith não se aplica owl:DeprecatedClass não se aplica owl:DeprecatedProperty 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 XML2 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 mapea- mento em UML para este trecho de código OWL. As classes OWL Regime e Change fo- ram mapeadas para classes UML. As propriedades do tipo DatatypeProperty foram mape- 2http://www.w3.org/2001/XMLSchema 3.2 Mapeamento entre OWL e UML 49 Schema XML UML xsd:integer Integer xsd:int Integer xsd:unsignedShort Integer xsd:boolean Boolean xsd:string String xsd:anySimpleType String xsd:nonNegativeInteger UnlimitedNatural xsd:positiveInteger 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 http://www.w3.org/2001/XMLSchema#string, foram mapeados para o tipo primi- tivo 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 CAPÍTULO 4 Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos 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 utili- zaçã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 implemen- tado 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 re- quisitos têm como objetivo principal abstrair detalhes específicos, relativos a cada lingua- gem 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. 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 essen- ciais 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, evitando- se 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 ne- cessá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. 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 ferra- menta 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 on- tologia OWL de entrada. Neste modelo UML estereótipos e propriedades definidas em um perfil UML asseguram informações suplementares inerentes à ontologia de entrada 1Rx indica que o requisito x é atendido por esta decisão de projeto 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 name- sapaces. 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 va- lidadores 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 cons- truçõ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]. 4.3 Arquitetura 54 A ferramenta AutoWebS implementa uma abordagem MDD para atender prin- cipalmente 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 me- canismo 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 meca- nismo 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 infraestru- tura oferecida pelo Eclipse para o desenvolvimento de aplicações modulares. Ademais, a abordagem MDD implementada pela ferramenta permiti a inserção de uma nova lin- guagem 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 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çoWeb 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. 4.4 Perfil UML 56 4.4 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-values2 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 es- tereó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 onto- logia 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. 2São propriedades que os estereótipos podem ter. 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 atri- butos de uma classe UML estereotipada por «owl:Class». Nestes atributos são apli- cados os estereótipos «owl:DatatypeProperty» e «owl:ObjectProperty». O estereótipo «rdfs:subClassOf» é aplicado sobre a metaclasse UML Generalization e representa ge- neralizaçõ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» esten- dem a metaclasse UML Constraint com o objetivo de especificar restrições as quais 4.5 Importação das Ontologias OWL 58 devem ser satisfeitas para que o serviço Web seja executado apropriadamente. Na lin- guagem 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 transfor- maçõ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 cor- respondente (requisito R3). O Apêndice C traz este conjunto de transformações XSLT. 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 Bibtex3 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 3http://purl.org/net/nknouf/ns/bibtex 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 ele- mento 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 espe- cificaçã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 ser- viç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. 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, é 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 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 referen- ciadas em OWL-S. Cada instância da classe WsdlGrounding contém uma lista de ins- tâ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 ma- peamento entre os modelos UML e OWL-S. Esta transformação, chamada de UMLPro- file2OWLS, recebe como entra um modelo da UML 2 na versão 3.0.0 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 elemen- tos 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 tagged- value 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 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 va- lor do seu id é formado pela concatenação do nome da operação com a palavra AtomicProcessGrounding. O valor do atributo wsdlDocument é o valor do tagged- value 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 pa- lavra 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 corres- pondê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 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 basica- mente 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 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. CAPÍTULO 5 Estudo de Caso 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 apre- sentaçã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 apre- senta 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 do- mínios diversos, através da disponibilização de mecanismos de gerenciamento dos dispo- sitivos; modelagem, interpretação e refinamento dos dados de contexto; mecanismos de distribuição das informações de contexto, etc. Cada plataforma de middleware de provi- sã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 so- bre uma infraestrutura de rede disponível. 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 mid- dleware, tornando o desenvolvimento da aplicação uma tarefa nada trivial para os en- genheiros de software e programadores, pois entender os modelos utilizados para re- presentaçã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 apli- cação, são complexidades adicionais que devem ser evitadas. Para endereçar estes pro- blemas, 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 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 des- creve 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. 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 http://www.ppgsc.ufrn.br/∼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, assincro- namente, 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 comu- nicaçã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. 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. 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 reali- zar 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 esque- leto 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- 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 im- plementado 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 funci- onalidades 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 ex- tensã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. 5.4 Resultados 74 Figura 5.7: Implementação da regra de negócio do serviço Web 5.4 Resultados 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. 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. CAPÍTULO 6 Experimento Controlado 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ão- paramé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 apre- senta 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. 6.1 Ferramentas Avaliadas 77 6.1 Ferramentas Avaliadas O experimento avaliou a ferramenta AutoWebS (ver Seção 4) e uma suíte de ferramentas composta pelos plugins Axis2 para IDE Eclipse1 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 se- mâ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 existi- rem. 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 onto- logias públicas e de livre acesso, contidas nos exemplos da API OWL-S2. Nas próximas seções são apresentados os projetos de serviço Web semânticos.estão representadas em documentos OWL. 6.2.1 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. 1http://axis.apache.org/axis2/java/core/ 2http://www.mindswap.org/2004/owl-s/services.shtml 6.2 Projetos de Serviços Web Semânticos 78 6.2.2 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. 6.2.3 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. 6.2.4 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. 6.2.5 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. 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. 6.2.6 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. 6.2.7 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 ou- tra 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. 6.2.8 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 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 defi- nidos 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. 6.3.1 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). 6.3.2 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? 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 ferra- menta proporciona a menor quantidade de tempo para criação da descrição semân- tica 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ân- tico em uma ferramenta contribui positivamente? M8.1 Avaliação subjetiva do usuário. 6.3 Planejamento do Experimento 82 6.3.3 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 H10 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. H20 Não existe diferenças perceptíveis no tempo necessário para criação de serviços Web semânticos quando utilizado o AutoWebS. H30 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. H40 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. 6.3.4 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é 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 levan- tadas. 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 à com- pletude da ontologia OWL-S criada pela ferramenta. Em alguns casos como, por exem- plo, 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 questio- ná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 6.3.5 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 treina- mento 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. 6.4 Operação do Experimento 84 6.3.6 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. 6.3.7 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 conheci- mentos 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 lin- guagem 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 caracte- rísticas. Validade de Conclusão: são aplicados questionários de análise subjetiva sobre as ferra- mentas. 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. Entre- tanto, adequamos este experimento a nossa realidade e não generalizaremos os re- sultados. 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 6.4.1 Plano Experimental Utilizamos o plano experimental Quadrados Latinos (ver Apêndice F), pois exis- tem 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 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 (Proje- tos), 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 ferramen- tas. Para o sorteio usamos a função sample3 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] 7 3 2 6 1 5 8 4 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 2 6.4.2 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 3http://blog.revolutionanalytics.com/2009/02/how-to-choose-a-random-number-in-r.html 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. 6.4.3 Questionário para Análise Subjetiva da Ferramenta e do Pro- jeto 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.2. 6.5 Análise e Interpretação dos Resultados 6.5.1 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 apre- sentaram 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 6.5 Análise e Interpretação dos Resultados 87 AutoWebS Suíte Projeto tempo erros tempo erros Serviço Web semântico OilMonitor 1 12 0 35 1 Serviço Web semântico OilMonitor 2 8 0 55 1 Serviço Web semântico Book Finder 20 0 35 1 Serviço Web semântico Zip Code Finder 5 0 21 1 Serviço Web semântico Latitude Longitude Finder 8 0 25 1 Serviço Web semântico Barnes and Nobles 5 0 20 1 Serviço Web semântico BabelFish Translator 15 1 45 1 Serviço Web semântico Currency Converter 5 0 14 1 Tabela 6.6: Resultados obtidos na execução do experimento con- trolado 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 pro- priedade xsltTransformation. O participante do experimento modelou o retorno do ser- viç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 ne- cessá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 adi- cionais 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 6.5 Análise e Interpretação dos Resultados 88 Figura 6.1: Tempo de desenvolvimento dos serviços Web semânti- cos 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 5.14174 minutos e a Variância de 26.43750 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 31.25 minutos, o Desvio padrão foi de 12.98798 minutos e a Variância de 168.68750 minutos. 6.5.2 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ão- paramé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 D1 e D2 as distribuições dos tempos relativos às duas ferramentas, D1 para AutoWebS e D2 para suíte de aplicativos. Logo, temos como passos do método Wilcoxon, os seguintes: Hipótese nula H0: D1 e D2 não são iguais. D1 encontra-se desviada para a esquerda de D2 ou D1 encontra-se desviada para direita de D2. Hipótese alternativa Ha: D1 e D2 são idênticas. Isto é, as duas distribuições de tempos são idênticas. 6.5 Análise e Interpretação dos Resultados 89 AutoWebS Suíte Diff Sinal Posto Posto*Diff OilMonitor1 12 35 23 + 3 3 OilMonitor2 8 55 47 + 1 1 BookFinder 20 35 15 + 6.5 6.5 ZipCode 5 21 16 + 5 5 LatLong 8 25 17 + 4 4 BarnesAndNobles 5 20 15 + 6.5 6.5 BabelFish 15 45 30 + 2 2 Currency 5 14 9 + 8 8 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 H0 e afirmar com pelo menos 95% de certeza que D1 e D2, as distribuições de tempos, não são iguais. Desta forma D1 encontra-se desviada para a direita de D2, 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 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. 6.5.3 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 aplica- dos 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 desenvolvi- mento 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 oportunida- des 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 6.5 Análise e Interpretação dos Resultados 91 Figura 6.4: Grau de contribuição da ferramenta para o desenvol- vimento 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 suficien- tes 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 fer- ramenta 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 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 pro- jeto 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ân- ticos, 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. 6.5.4 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 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 H10. A hipótese H2 (“O tempo total necessário para criação de serviços Web se- mâ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 proje- tos 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 H20, 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 neces- sá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 desenvolvi- mento 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 H30. 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 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 H40. CAPÍTULO 7 Trabalhos Relacionados Na literatura existem vários trabalhos que exploram diversos aspectos dos ser- viç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 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 WSDL2OWLS1 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 2006. 1http://semwebcentral.org/projects/wsdl2owl-s/ 7.2 CODE - CMU’s OWL-S Development Environment 97 7.2 CODE - CMU’s OWL-S Development Environment CODE (CMU’s OWL-S Development Environment) [Srinivasan et al., 2005] é uma IDE desenvolvida como um plugin da plataforma Eclipse. O principal objetivo desta ferramenta é oferecer um ambiente de desenvolvimento unificado para a criação de servi- ços OWL-S. Com esta ferramenta, desenvolvedores podem escrever código fonte na lin- guagem Java, usando-se o editor Java da IDE Eclipse, e executar o utilitário Java2WSDL, do framework Axis da Apache [Basha and Irani, 2002], para criar o documento WSDL. CODE disponibiliza um conversor, chamado WSDL2OWL-S Converter, para gerar esque- letos da descrição semântica de serviços Web em OWL-S, além de publicar o serviço Web em repositórios UDDI. A Figura 7.2 ilustra a arquitetura da ferramenta CODE. Figura 7.2: Arquitetura da ferramenta CODE - extraído de [Srinivasan et al., 2005] A ferramenta CODE possui quatro editores que suportam a edição das quatro subontologias OWL-S, Service Profile, Service Model, Service Grounding e Service. Os editores são baseados em formulários, que devem ser preenchidos com os dados da ontologia do serviço Web, assim, necessitando do usuário o conhecimento a respeito dos elementos que formam a ontologia OWL-S. A ferramenta não tem mecanismos para importar os conceitos definidos em uma ontologia de domínio. Desta forma, o arquivo OWL-S gerado por esta ferramenta não é relacionado a nenhum conceito de uma ontologia OWL. Além disso, a ontologia OWL-S é gerada de forma incompleta, necessitando do processamento manual para completar as subontologias ServiceProfile e ServiceModel, pois a especificação destas subontologias, 7.3 ASSAM - Automated Semantic Service Annotation with Machine Learning 98 que foram feitas pelo utilitário WSDL2OWLS, não apresenta as descrições semânticas dos inputs e outputs do serviço Web, uma vez que o documento WSDL não fornece qualquer descrição semântica. A ferramenta é limitada na representação gráfica das composições de serviços, a qual é feita utilizando árvores e formulários, o que torna difícil uma visualização mais completa e intuitiva para o usuário. Outra limitação da ferramenta dá-se pelo uso do Axis para criação do documento WSDL, pois o Axis usa somente o estilo RPC (JAX- RPC) para as mensagens, enquanto que o Axis2 também usa o estilo Document (JAX- WS). O Axis também dá suporte apenas a interações síncronas do tipo request-response, onde o Endpoint da operação do serviço Web recebe uma mensagem de requisição e sempre retorna uma mensagem de resposta. Outro aspecto limitante da ferramenta CODE é a ausência de um mecanismo para criação automática das transformações em XSLT (xsltTransformation). 7.3 ASSAM - Automated Semantic Service Annotation with Machine Learning ASSAM (Automated Semantic Service Annotation with Machine Learning) [Heß et al., 2004] é uma ferramenta Open Source desenvolvida com a linguagem Java. Esta ferramenta oferece uma interface gráfica baseada em visões e utiliza um processo semi-automático onde o usuário define os mapeamentos entre conceitos de uma ontologia de domínio, especificados em documentos OWL, e os elementos definidos no Schema XML do documento WSDL de um serviço Web. A ferramenta ASSAM importa docu- mentos WSDL e ontologias OWL e permite o usuário anotar os documentos WSDL com os conceitos das ontologias a partir de uma interface do tipo point-and-click, conforme a Figura 7.3 ilustra. Tal ferramenta utiliza um algoritmo de aprendizado no qual, à medida que o usuário realiza as anotações, o programa oferece algumas sugestões de quais classes de ontologias podem ser associadas aos elementos do WSDL. O algoritmo de aprendizagem usado pelo ASSAM [Heß and Kushmerick, 2004b, Heß and Kushmerick, 2004a] usa as relações prévias que o usuário fez com os elementos para sugerir novos conceitos, assim limitando os conceitos à algumas possibilidades ao invés de todos os conceitos de uma ontologia. O processo semi-automático gera toda a ontologia OWL-S do serviço Web, inclusive as transformações em XSLT (propriedade xsltTransformation da OWL-S) para os casos em que os inputs e os outputs do serviço Web não têm uma correspondência direta com os elementos da ontologia de domínio. 7.4 Yang e Chung 99 Figura 7.3: Ferramenta ASSAM - extraído de [Heß et al., 2004] 7.4 Yang e Chung Yang e Chung [Yang and Chung, 2006b, Yang and Chung, 2006a] criaram uma metodologia para geração automática de ontologias de serviços Web em OWL-S a partir de informações extraídas de diagramas de classe e de estados da UML. Nesta metodologia, o processo de geração da ontologia do serviço Web é dividido em dois subprocessos: as informações relacionadas ao serviço Web e suas propriedades, tal como IOPE (Input, Output, Precondition, e Effects), são extraídas de diagramas de classe para criação de Atomic Process e os diagramas de estados da UML são usados para modelar o comportamento e a composição de serviços Web. A Figura 7.4 apresenta um exemplo da abordagem de Yang e Chung, onde o diagrama de classe da UML é usado para modelar um serviço de viagem (travel service) composto de três serviços Web atômicos: AirlineTicketing, CarRental e HotelReservation. A abordagem desenvolvida por Yang e Chung usa um perfil UML que define as transições estereotipadas do diagrama de estados da UML para representar as construções de controle da OWL-S. Nesta abordagem, transformações pré-definidas em XSLT são aplicadas sobre os arquivos XMI (cada arquivo XMI representa um dos modelos UML) para gerar o arquivo OWL-S. As condições (preconditions e effects) são representadas usando-se uma GUI, ao invés de construções OCL (Object Constraint Language) nos modelos UML. Yang e Chung não implementaram nenhuma ferramenta para auxiliar a constru- ção dos modelos UML. Eles utilizaram uma ferramenta CASE UML para a criação dos modelos UML e também para a geração dos arquivos XMI. A metodologia não contempla 7.5 Kim e Lee 100 Figura 7.4: Abordagem de Yang e Chung para constru- ção de serviços Web semânticos - extraído de [Yang and Chung, 2006b] a criação automática de serviços Web e a importação de uma ontologia de domínio em OWL. Entretanto a abordagem define um processo de validação da ontologia do serviço a partir de validadores RDF, OWL e OWL-S. 7.5 Kim e Lee Kim e Lee [Kim and Lee, 2007] definiram uma abordagem que usa uma combi- nação de diagramas da UML - diagrama de classe, atividade e sequência - para capturar propriedades semânticas para modelar serviços Web semânticos atômicos e composição de serviços Web. Nesta abordagem, diagramas de classe da UML representam as ontolo- gias de domínio e diagramas de sequência ou atividade da UML modelam as interações entre múltiplos processos em uma composição de serviços Web. É definido um perfil UML para representar as características da OWL-S nos modelos UML e transformações XSLT são usadas para transformar o documento XMI, resultante dos modelos UML, para um documento OWL-S. A metodologia implementada por Kim e Lee, representado na Figura 7.5, con- siste basicamente de três atividades: modelagem da ontologia, representado por ontology modeling; modelagem da composição dos serviços Web, representado por process modeling; e transformações (transformation). Primeiramente uma ontologia é importada e representada em um diagrama de classes. Após isto, em um segundo passo, através do uso de perfis UML, diagramas de sequência ou atividade da UML são usados para expressar o comportamento e a composição de serviços Web. Finalmente, um arquivo XMI é ex- 7.6 Comparação entre as ferramentas 101 Figura 7.5: Abordagem de Kim e Lee para construção de serviços Web semânticos - extraído de [Kim and Lee, 2007] traído dos diagramas UML para que transformações em XSLT possam criar o documento OWL-S. 7.6 Comparação entre as ferramentas As ferramentas supracitadas apresentam abordagens distintas. Algumas se limi- tam a criação de ontologias de serviços Web enquanto outras, além da ontologia, criam o serviço Web. Para efeito de comparação dos trabalhos relatados supracitados com a fer- ramenta 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ânticos, sumarizamos na Ta- bela 7.1 uma comparação entre elas. Na Tabela 7.1, sim significa que a ferramenta atende integralmente o requisito correspondente e não é o caso contrário, quando a ferramenta não atende ao requisito. Quando assinalado parcialmente, a ferramenta em questão não atende completamente o requisito correspondente. Requisitos R0 R1 R2 R3 R4 R5 R6 OWL-S Editor não não sim sim não sim parcialmente CODE sim sim sim não parcialmente parcialmente sim ASSAM não não sim sim não sim não Yang e Chung sim não sim não não sim parcialmente Kim e Lee sim não sim sim não parcialmente parcialmente AutoWebS sim sim sim sim sim sim sim Tabela 7.1: Comparação entre os trabalhos relacionados O plugin OWL-S Editor [Elenius et al., 2005] requer que o usuário entenda o ambiente Protégé, o que pode levar a uma curva de aprendizado acentuada. Portanto, não atende o requisito R0. A ferramenta também não atende requisito R1, pois o seu propósito não é a criação de serviços Web, seu propósito é a criação da ontologia do serviço Web 7.6 Comparação entre as ferramentas 102 (requisito R2), usando ontologias pré-existentes (requisito R3). Esta ferramenta também não implementa o requisito R4, pois não oferece um ambiente de desenvolvimento que integra todas as funcionalidades necessárias para a criação de um serviço Web semântico, uma vez que são necessários o uso de recursos externos como, por exemplo, o Axis2 para criação do serviço Web. Em relação ao requisito R5, podemos afirmar que a ferramenta o implementa. Entretanto, tanto os requisitos R2 e R5 merecem uma ressalva, pois para as transformações XSLT não é oferecido na ferramenta nenhum mecanismo para criá-las. Quanto ao requisito R6, a arquitetura da ferramenta Protégé provê um suporte básico à integração de novas funcionalidades. Assim, classificamos como parcialmente implementado tal requisito. A ferramenta CODE [Srinivasan et al., 2005] provê um mecanismo para abstra- ção da linguagem OWL-S e também para criação do serviços Web através dos utilitários Java2WSDL e WSDL2OWL-S. Estes utilitários realizam as transformações automáticas e proporcionam certo nível de abstração, desta forma atendendo os requisitos R0 e R1. Na ferramenta, a ontologia OWL-S é gerada automaticamente (requisito R2), entretanto de forma incompleta, necessitando do processamento manual para completar as subontolo- gias ServiceProfile e ServiceModel, dessa forma atendendo apenas parcialmente o requi- sito R5, pois o código OWL-S resultante não é completo e executável. Na ferramenta não existem mecanismos para importar os conceitos definidos em uma ontologia para mode- lagem do serviço Web, ou seja, não atende aos requisitos R3 e R4. Esta ferramenta se beneficia da plataforma Eclipse, pois novos módulos que provêem novas funcionalidades podem ser integrados à ferramenta, evidenciando sua conformidade com o requisito R6. A ferramenta ASSAM [Heß et al., 2004] não está em conformidade com o requisito R0, pois exige do usuário um profundo conhecimento sobre os Schemas XML usados na definição dos elementos da interface do serviço Web, definidos no documento WSDL, e, também, da linguagem OWL. O conhecimento sobre os Schemas XML e OWL são necessários para à construção dos mapeamentos entre os inputs e outputs do serviço Web e as ontologias pré-existentes (requisito R3). Além disso, a associação manual entre os conceitos de uma ontologia e os elementos WSDL pode ser difícil de ser realizada, uma vez que o número de combinações possíveis pode ser grande. Esta ferramenta tem como propósito a criação da ontologia do serviço Web (requisito R2), porém não está integrada a um ambiente de desenvolvimento e não oferece funcionalidades para criação do código fonte do serviço Web muito menos do documento WSDL, evidenciando sua inconformidade com os requisitos R1 e R4. A ontologia do serviço Web é gerada sintaticamente e semântica correta (requisito R5), entretanto a arquitetura da ferramenta não provê suporte a integração de novas funcionalidades, portanto não atende o requisito R6. A abordagem implementada por Yang e Chung [Yang and Chung, 2006b, 7.6 Comparação entre as ferramentas 103 Yang and Chung, 2006a] contempla apenas a criação da ontologia OWL-S, não se pre- ocupando com o serviço Web, ou seja, não atende o requisito R1. Esta abordagem usa a linguagem UML que é amplamente usada como linguagem de modelagem, tornando-a acessível e prática, sem a necessidade de uma curva de aprendizagem acentuada, portanto implementando o requisito R0. A abordagem, através de transformações XSLT aplicadas nos modelos UML, cria automaticamente a ontologia OWL-S (requisito R2). Entretanto, nesta abordagem não é possível usar conceitos definidos em uma ontologia de domínio para descrever semanticamente os elementos do serviço Web. Assim, não contemplando o requisito R3. Em relação ao requisito R4, podemos afirmar que ele não é implementada pela abordagem de Yang e Chung, pois não existe um ambiente de desenvolvimento que integra todas as funcionalidades necessárias para a criação de um serviço Web semântico. Mas os artefatos de código, neste caso somente a ontologia do serviço Web, são validados através de um processo de validação (requisito R5). Yang e Chung implementaram sua abordagem usando uma ferramenta CASE UML proprietária. Isto significa que os docu- mentos XMI que representam os modelos UML não são compatíveis com outras ferra- mentas UML. Por se tratar de uma ferramenta proprietária e com o código fonte fechado, não é possível fazer extensões. Assim, não permitindo a inserção de novas funcionalida- des (requisito R6) na ferramenta CASE UML. Entretanto, a especificação da abordagem é independente de ferramenta e, portanto, ela pode ser implementada em outra ferramenta como, por exemplo, o perfil UML pode ser criado usando-se a infraestrutura do Eclipse Modeling. Assim, consideramos que esta abordagem atente parcialmente o requisito R6. O trabalho de Kim e Lee [Kim and Lee, 2007], igualmente ao trabalho de Yange e Chung, contempla apenas a criação da ontologia OWL-S, não se preocupando com a implementação do serviço Web, ou seja, não atende o requisito R1. A abordagem faz uso dos diagramas da UML e especifica um método de três passos para construção da ontolo- gia OWL-S (requisito R0). O documento XMI que representa os modelos UML - classes, sequência ou atividade - é transformado automaticamente no documento OWL-S através de transformações XSLT (requisito R2). Para modelagem dos serviços Web é permitido usar conceitos definidos em uma ontologia de domínio. Esta ontologia, em um primeiro passo da metodologia desenvolvida, é importada e representada usando-se os elementos do diagrama de classes da UML (requisito R3). O requisito R4 não é implementado na abordagem de Kim e Lee, pois não existe um ambiente de desenvolvimento que inte- gra todas as funcionalidades necessárias para a criação de um serviço Web semântico. O requisito R5, que diz respeito aos artefatos de códigos gerados, é atendido parcial- mente, pois a abordagem é capaz de gerar a ontologia OWL-S sem a subontologia Service Grounding. Já em relação ao requisito R6, mantemos a mesma justificativa do trabalho de Yang e Chung, pois a abordagem foi implementada em uma ferramenta CASE UML e existem alguns desafios de interoperabilidade, principalmente os relacionados à especi- 7.6 Comparação entre as ferramentas 104 ficação da UML. Desta forma, consideramos que esta abordagem atente parcialmente o requisito R6. CAPÍTULO 8 Conclusão Neste capítulo encerra-se esta dissertação. Em seguida apresentamos uma síntese dos temas abordados nos capítulos anteriores e tecemos alguns comentários que julgamos oportunos para conclusão deste trabalho. Apresentamos na Seção 8.1 as principais con- tribuições desta dissertação. Na Seção 8.2 ressaltamos algumas limitações da abordagem proposta e apontamos, na Seção 8.3, alguns melhorias e trabalhos futuros. Este trabalho apresentou uma ferramenta MDD para a criação de serviços Web semânticos. Esta ferramenta implementa um processo MDD - com o uso de um perfil UML, um metamodelo para linguagem OWL-S e transformações entre modelos e texto - para tornar o desenvolvimento de um serviço Web semântico mais intuitivo e prático. Iniciou-se esta dissertação apresentando a dificuldade em se criar serviços Web semânticos, abordando desde as linguagens de baixo nível usadas para descrição semân- tica dos serviços Web como, por exemplo, a linguagem OWL-S, até as limitações das principais ferramentas. Devido a complexidade da gramática da linguagem OWL-S é di- fícil construir manualmente uma ontologia do serviço Web e a curva de aprendizado desta linguagem é acentuada. Em seguida, no Capítulo 2, foram apresentadas as principais características, conceitos e tecnologias dos serviços Web semânticos, bem como as tecnologias do MDD usados para gerenciar a complexidade inerente dos serviços Web semânticos. No Capítulo 3 foram apresentadas as similaridades entre as linguagens de es- pecificação de ontologias e a linguagem de modelagem UML. As similaridades entre as linguagens são fundamentais para a especificação do perfil UML que a ferramenta AutoWebS usa. Mostrou-se também os elementos da linguagem OWL que são direta- mente usados e, portanto, necessários para criação de serviços Web semânticos, apresen- tando como esses elementos podem ser representados com elementos da UML. Apresentada a fundamentação teórica do trabalho, em seguida iniciou-se a apre- sentação da ferramenta proposta e dos requisitos fundamentais para uma ferramenta de alto nível de abstração para a criação de serviços Web semânticos. A ferramenta em ques- tão emprega uma abordagem MDD para a geração de serviços Web semânticos a partir de modelos UML. A ferramenta oferece um ambiente que integra várias funcionalidades 106 necessárias para modelar, implementar, compilar e fazer o deploy de serviços Web semân- ticos. Ao longo do Capítulo 4 foram apresentadas a arquitetura da ferramenta, explici- tando seus componentes e tecnologias relacionadas, o perfil UML usado para representar elementos da OWL em UML, o processo de importação de ontologias OWL através de transformações XSLT, o metamodelo para linguagem OWL-S, as regras de mapeamento QVT usadas para transformar um modelo UML em um modelo OWL-S e, por fim, o funcionamento da ferramenta. A abordagem implementada pela ferramenta proporciona aos desenvolvedores dos serviços Web semânticos concentrar seus esforços na criação de modelos em vez de escrever códigos ou criar descrições semânticas. Associado a isto, o fato de que os modelos criados a partir de perfis UML são modelos UML válidos e devido a ampla utilização da UML como linguagem de modelagem, esta abordagem torna a ferramenta AutoWebS acessível a um público maior do que aquele formado por especialistas da área da Web semântica. A dissertação apresentou um estudo de caso no Capítulo 5 que demonstra o uso do AutoWebS na criação de um serviço Web semântico para um serviço provido por uma plataforma de middleware de contexto que não utiliza a tecnologia dos serviços Web semânticos. Neste estudo de caso evidenciamos a utilidade e praticidade do AutoWebS, apresentando como a ferramenta foi usada para criar um serviço Web semântico usando os conceitos definidos em uma ontologia de domínio OWL, abstraindo o modelo de comunicação usado pela plataforma de middleware de contexto e, também, realizando a conversão da representação dos elementos de contexto de chave-valor para ontologia. No Capítulo é apresentado um experimento controlado que avalia o AutoWebS em relação a uma suíte de aplicativos composta pelo OWL-S Editor e o plugin Axis2 da IDE Eclipse. O experimento tem como objetivos obter indicativos da qualidade dos arte- fatos de códigos gerados pela ferramenta AutoWebS, comparar os tempos de desenvolvi- mento de serviços Web semânticos obtidos pela ferramenta AutoWebS e pela suíte de apli- cativos, mensurar o esforço despendido e a dificuldade no uso da ferramenta AutoWebS e na suíte de aplicativos OWL-S Editor e Axis2, além de verificar se abordagem de inte- gração de ferramentas para criação de serviços Web semânticos é mais eficiente do que a abordagem tradicional. Os resultados obtidos do experimento controlado são promissores e demonstram que os tempos obtidos com a ferramenta AutoWebS para criação dos servi- ços Web semânticos foram inferiores aos tempos obtidos pela suíte de aplicativos OWL-S Editor e Axis2. Os serviços Web gerados pelas duas ferramentas no experimento contro- lado são semelhantes, uma vez que usam o mesmo middleware para criação de serviços Web, o middleware Axis2. Já as ontologias dos serviços Web diferiram. Quando usado o AutoWebS obteve-se um número menor de erros ou inconsistências na ontologia do serviço Web do que quando foi usada a suíte de aplicativos. A análise qualitativa mostrou 8.1 Contribuições 107 que a ferramenta AutoWebS contribuiu positivamente para o diminuição do cansaço e do tempo de desenvolvimento dos serviços Web semânticos. 8.1 Contribuições Recentemente muitos pesquisadores têm voltado seus esforços para criação de abordagens para composição de serviços Web. Essas abordagens, a maioria, partem do pressuposto que os serviços Web estão desenvolvidos e suas ontologias especificadas em alguma linguagem de descrição semântica. Também existem outras abordagens que tratam a questão da composição somente para serviços Web que usam tipos primitivos nos parâmetros de suas operações, negligenciando os tipos complexos definidos em Schemas XML e/ou conceitos definidos em ontologias. A criação de um serviço Web semântico atômico, isto é, a implementação do ser- viço Web e a especificação da sua ontologia, ainda é um problema recorrente que merece atenção, pois a maioria das ferramentas não suporta todas as etapas do desenvolvimento de um serviço Web semântico. As poucas ferramentas que suportam todas as etapas falham em algum ponto, seja na qualidade dos artefatos gerados como, por exemplo, a incom- pletude da ontologia do serviço Web criada a partir de conversores WSDL2OWLS, ou no layout e apresentação da ferramenta como, por exemplo, a ferramenta OWL-S Editor que necessita de uma curva de aprendizado muito acentuada. A principal contribuição dessa dissertação é a especificação e o desenvolvimento de uma ferramenta, denominada AutoWebS, para criação de serviços Web semânticos que implementa uma abordagem MDD. O AutoWebS oferece ao usuário um ambiente gráfico onde é possível usar os conceitos definidos em uma ontologia de domínio para modelar a interface de serviços Web semânticos. A ferramenta AutoWebS cria automaticamente a ontologia do serviço Web e o esqueleto de código fonte a partir de modelos UML. Utilizando a ferramenta, é possível modelar serviços Web semânticos de uma forma independente de plataforma através da UML. Outras contribuições importantes desta dissertação são: a especificação e imple- mentação de um perfil UML cuja finalidade é permitir a representação de alguns ele- mentos da linguagem OWL em UML e também permitir a modelagem de serviços Web semânticos; as regras de transformações XSLT para transformar os elementos de uma on- tologia OWL que são necessários para criação de serviços Web semânticos, em elementos da UML; a especificação e implementação do metamodelo em Ecore para a linguagem OWL-S; a especificação e implementação da transformação Modelo para Modelo (M2M) na linguagem QVT para transformar um modelo UML em um modelo correspondente ao metamodelo OWL-S; e a transformação Modelo para Texto (M2T) para que, a partir de um modelo OWL-S, criar-se um arquivo OWL-S. 8.2 Limitações 108 8.2 Limitações A ferramenta AutoWebS apresenta algumas limitações, porém as limitações não inviabilizam o seu uso. As limitações atuais do AutoWebS são: • A ferramenta AutoWebS propõe-se a criação de serviços Web semânticos atômicos, limitando-se a criação de serviços Web e seu ontologia. • A versão atual do algoritmo para criação do script XSLT para o elemento xsltTransformation da ontologia do serviço Web limita-se a criação de scripts XSLT para conceitos de ontologias que possuem propriedade dos tipos primitivos defini- dos no Schema XML ou outros conceitos definidos como classes OWL. Para os casos mais complexos como, por exemplo, definições de listas, tal algoritmo não consegue fazer sua interpretação corretamente e, portanto, não é capaz de gerar o scrip XSLT. • Na importação da ontologia de domínio um conjunto de transformações XSLT criam um modelo UML em arquivo XMI com a extensão .uml. Entretanto, o editor UML usado pelo AutoWebS, o editor Papyrus, não renderiza o digrama UML automaticamente na interface gráfica da ferramenta. O Papyrus usa dois outros arquivos auxiliares para renderizar o diagrama UML. Os arquivos com a extensão .di e .notation definem as coordenadas de cada elemento do modelo UML. Sem esses arquivos o editor Papyrus não renderiza os elementos do modelo UML, necessitando que o usuário faça este trabalho. Para modelos com poucos elementos este trabalho é fácil, porém quando o modelo é grande, este trabalho torna-se árduo e cansativo. • A interface gráfica da ferramenta é outro ponto que merece atenção e foi eviden- ciado na avaliação subjetiva da ferramenta durante o experimento controlado. A disposição dos botões e menus e o acesso as funcionalidades precisam ser revistos. • Em um experimento controlado, a quantidade de participantes e réplicas são fatores importantes que podem ameaçar a sua validade (ver Seção 6.3.7). No experimento controlado aplicado a ferramenta AutoWebS foi necessário adequar o seu projeto de forma que apenas dois participantes e dezesseis execuções foram realizadas. Entre- tanto esta adequação não tira a validade do experimento controlado e a análise esta- tística dos resultados pode ser realizada usando-se o método estatístico Wilconxon para amostrar pequenas [Corder and Foreman, 2009, Berenson and Levine, 1996]. 8.3 Trabalhos Futuros Como trabalho futuro propõe-se, com base nos desenvolvimentos realizados neste trabalho, evoluir a ferramenta AutoWebS com a criação de outro conjunto de es- 8.3 Trabalhos Futuros 109 tereótipos, propriedades e restrições UML para proporcionar a criação de composição de serviços Web. Um novo perfil UML aplicado a elementos do diagrama de estados ou di- agrama de sequência podem ser usados para modelar o comportamento e a composição de serviços Web, semelhante aos trabalhos de Yang e Chung [Yang and Chung, 2006b, Yang and Chung, 2006a] e Kim e Lee [Kim and Lee, 2007]. Além da definição e imple- mentação do perfil UML será necessário a criação de novas regras de transformações modelo para modelo e modelo para texto, mas não será necessário alterar o metamodelo OWL-S, uma vez que ele está bem definido e atende a toda especificação da linguagem OWL-S. Propõe-se também a criação de uma GUI para a especificação de condições (Preconditions, Effects e Results) que são usados nas ontologias dos serviços Web. Atualmente tais condições são especificadas por intermédio de comentários no modelo UML (elemento Comment da UML). As limitações atuais da ferramenta devem ser supridas. Pretende-se melhorar o algoritmo para geração dos scripts XSLT para o elemento xsltTransformation da ontologia do serviço Web. É previsto também uma evolução da interface gráfica da ferramenta e principalmente a maneira como as funcionalidades são acessadas através dos botões e menus. Para geração automática dos artefatos de código fonte do serviço Web, atual- mente a ferramenta faz uso do framework da Apache Axis2. Entretanto, a arquitetura da ferramenta possibilita o uso de outros mecanismos para geração dos artefatos do ser- viço Web como, por exemplo, os frameworks Metro1, Spring WS2 e CXF3. Dessa forma, espera-se integrar esses frameworks a ferramenta AutoWebS. Finalmente, espera-se aumentar o grau de avaliação da ferramenta através da realização de novos estudos de caso e experimentos controlados. 1http://metro.java.net 2http://static.springsource.org/spring-ws/sites/2.0/ 3http://cxf.apache.org/ Referências Bibliográficas [w3c, 1999] (1999). XSL transformations (XSLT), W3C recommendation. [Akkiraju et al., ] Akkiraju, R., Farell, J., Miller, J. A., Nagarajan, M., Sheth, A., and Verma, K. Web Service Semantics - WSDL-S. [Alonso et al., 2004] Alonso, G., Casati, F., Kuno, H., and Machiraju, V. (2004). Web Services: Concepts, Architectures and Applications. Springer-Verlag, ISBN 3-540- 44008-9. [Atkinson et al., 2006] Atkinson, C., Gutheil, M., and Kiko, K. (2006). On the relationship of ontologies and models. In Proceedings of the 2nd International Workshop on Meta- Modelling (WoMM 2006), pages 47–60, Karlsruhe, Germany. [Basha and Irani, 2002] Basha, S. and Irani, R. (2002). AXIS: the next generation of Java SOAP. Programmer to Programmer. Wrox Press Ltd., Birmingham, UK, UK, 1st edition. [Basili et al., 1994] Basili, V., Caldiera, G., and Rombach, D. H. (1994). The goal question metric approach. In Marciniak, J., editor, Encyclopedia of Software Engineering. Wiley. [Belghiat and Bourahla, 2012] Belghiat, A. and Bourahla, M. (2012). Article: An approach based atom3 for the generation of owl ontologies from uml diagrams. International Journal of Computer Applications, 41(3):41–46. Published by Foundation of Computer Science, New York, USA. [Berenson and Levine, 1996] Berenson, M. and Levine, D. (1996). Basic business statis- tics: concepts and applications. Prentice Hall. [Berners-Lee et al., 2001] Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The semantic web : a new form of web content that is meaningful to computers will unleash a revolution of new possibilities. Scientific American. [Bloehdorn and Moschitti, ] Bloehdorn, S. and Moschitti, R. Uddi project — universal des- cription, discovery and integration. In Advances in Information Retrieval - Proceedings of the 29th European Conference on Information Retrieval (ECIR 2007. Referências Bibliográficas 111 [Bottaro and Gérodolle, 2008] Bottaro, A. and Gérodolle, A. (2008). Home soa -: facing protocol heterogeneity in pervasive applications. In Proceedings of the 5th international conference on Pervasive services, ICPS ’08, pages 73–80, New York, NY, USA. ACM. [Brambilla et al., 2007] Brambilla, M., Ceri, S., Facca, F. M., Celino, I., Cerizza, D., and Valle, E. D. (2007). Model-driven design and development of semantic web service applications. ACM Trans. Internet Technol., 8. [Brockmans et al., 2006] Brockmans, S., Colomb, R. M., Haase, P., Kendall, E. F., Wallace, E. K., Welty, C., and Xie, G. T. (2006). A model driven approach for building owl dl and owl full ontologies. In In Proceedings of the 5th International Semantic Web Conference (ISWC’06. [Burstein et al., 2004] Burstein, M., Hobbs, J., Lassila, O., Mcdermott, D., Mcilraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N., and Sycara, K. (2004). OWL-S: Semantic Markup for Web Services. Website. [Chafle et al., 2007] Chafle, G., Das, G., Dasgupta, K., Kumar, A., Mittal, S., Mukherjea, S., and Srivastava, B. (2007). An integrated development environment for web service composition. In Web Services, 2007. ICWS 2007. IEEE International Conference on, pages 839 –847. [Christensen et al., 2001] Christensen, E., Curbera, F., Meredith, G., and Weerawarana, S. (2001). Web Service Definition Language (WSDL). Technical report. [Clark, 1999] Clark, D. (1999). Mad cows, metathesauri, and meaning. IEEE Intelligent Systems, 14:75–77. [Corder and Foreman, 2009] Corder, G. and Foreman, D. (2009). Nonparametric Statis- tics for Non-Statisticians: A Step-By-Step Approach. Wiley. [Dai et al., 2007] Dai, N., Mandel, L., and Ryman, A. (2007). Eclipse Web Tools Platform: Developing Java™ Web Applications. Addison-Wesley Professional, first edition. [Davies et al., 2006] Davies, J., Studer, R., and Warren, P., editors (2006). Semantic Web Technologies: Trends and Research in Ontology-Based Systems. John Wiley & Sons, Chichester, UK. [de Bruijn, 2003] de Bruijn, J. (2003). Using Ontologies - Enabling Knowledge Sharing and Reuse on the Semantic Web. Technical Report DERI-2003-10-29, DERI. [de Bruijn et al., 2005] de Bruijn, J., Bussler, C., Domingue, J., Fensel, D., Hepp, M., Keller, U., Kifer, M., König-Ries, B., Kopecky, J., Lara, R., Lausen, H., Oren, E., Polleres, A., Referências Bibliográficas 112 Roman, D., Scicluna, J., and Stollberg, M. (2005). Web service modeling ontology (wsmo). W3C member submission. [Dean and Schreiber, 2004] Dean, M. and Schreiber, G. (2004). OWL web ontology language reference. W3C recommendation, W3C. [Dey et al., 2001] Dey, A., Salber, D., and Abowd, G. (2001). A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. [Easton et al., 2008] Easton, P., Mehta, B., and Merrick, R. (2008). Soap over java message service 1.0. World Wide Web Consortium, Working Draft WD-soapjms- 20081121. [Elenius et al., 2005] Elenius, D., Denker, G., Martin, D., Gilham, F., Khouri, J., and Sena- nayake, R. (2005). The owl-s editor - a development tool for semantic web services. In In Proceedings of the Second European Semantic Web Conference, pages 78–92. Springer. [Falkovych et al., 2003] Falkovych, K., Sabou, M., and Stuckenschmidt, H. (2003). UML for the Semantic Web: Transformation-Based Approaches. In Omelayenko, B. and Klein, M., editors, Knowledge Transformation for the Semantic Web, pages 92–106. IOS Press. [Fang et al., 2006] Fang, K., ze Li, R., and Sudjianto, A. (2006). Design and modeling for computer experiments. Computer science and data analysis series. Chapman & Hall/CRC. [Fonseca et al., 2009] Fonseca, A., Claro, D. B., and Lopes, D. C. P. (2009). Gerenciando o desenvolvimento de uma composição de serviços web semânticos através do owl-s composer. [Frankel, 2003] Frankel, D. S. (2003). Model Driven Architecture: Applying MDA to Enter- prise Computing. Wiley. [Gasevic et al., 2006] Gasevic, D., Djuric, D., and Devedzic, V. (2006). The mda-based ontology infrastructure. In Model Driven Architecture and Ontology Development, pages 173–179. Springer Berlin Heidelberg. [Gaševic et al., 2009] Gaševic, D., Djuric, D., and Devedžic, V. (2009). Model Driven Engineering and Ontology Development. Springer, Berlin, 2. edition. [Gérard et al., 2007] Gérard, S., Dumoulin, C., Tessier, P., and Selic, B. (2007). Papyrus: A uml2 tool for domain-specific language modeling. In Model-Based Engineering of Embedded Real-Time Systems, pages 361–368. Referências Bibliográficas 113 [Ghallab et al., 1998] Ghallab, M., Isi, C. K., Penberthy, S., Smith, D. E., Sun, Y., and Weld, D. (1998). PDDL - The Planning Domain Definition Language. Technical report, CVC TR-98-003/DCS TR-1165, Yale Center for Computational Vision and Control. [Grace et al., 2003] Grace, P., Blair, G., and Samuel, S. (2003). Remmoc: A reflective middleware to support mobile client interoperability. In Meersman, R., Tari, Z., and Schmidt, D., editors, On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE, volume 2888 of Lecture Notes in Computer Science, pages 1170–1187. Springer Berlin / Heidelberg. [Hart et al., 2004] Hart, L., Emery, P., Colomb, B., Raymond, K., Taraporewalla, S., Chang, D., Ye, Y., Kendall, E., and Dutra, M. (2004). OWL Full and UML 2.0 Compared. Technical report. [Hassanpour et al., 2010] Hassanpour, S., O'Connor, M. J., and Das, A. K. (2010). A software tool for visualizing, managing and eliciting swrl rules. In Proceedings of the 7th international conference on The Semantic Web: research and Applications - Volume Part II, ESWC’10, pages 381–385, Berlin, Heidelberg. Springer-Verlag. [Heß et al., 2004] Heß, A., Johnston, E., and Kushmerick, N. (2004). Assam: A tool for semi-automatically annotating semantic web services. In 3rd International Semantic Web Conference, pages 320–334. Springer. [Heß and Kushmerick, 2004a] Heß, A. and Kushmerick, N. (2004a). Iterative ensemble classification for relational data: A case study of semantic web services. In ECML, pages 156–167. [Heß and Kushmerick, 2004b] Heß, A. and Kushmerick, N. (2004b). Machine learning for annotating semantic web services. In In AAAI Spring Symposium on Semantic Web Services. [Horridge et al., 2004] Horridge, M., Knublauch, H., Rector, A., Stevens, R., and Wroe, C. (2004). A practical guide to building owl ontologies using the protégé-owl plugin and co-ode tools. The University Of Manchester, 27:0–117. [Horrocks et al., 2004] Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., and Dean, M. (2004). SWRL: A Semantic Web Rule Language Combining OWL and RuleML. Technical report, World Wide Web Consortium. [Kim and Lee, 2007] Kim, I.-W. and Lee, K.-H. (2007). Describing semantic web services: From uml to owl-s. Web Services, IEEE International Conference on, 0:529–536. Referências Bibliográficas 114 [Kim and Lee, 2009] Kim, I.-W. and Lee, K.-H. (2009). A model-driven approach for describing semantic web services: from uml to owl-s. Trans. Sys. Man Cyber Part C, 39(6):637–646. [Kjaer, 2007] Kjaer, K. E. (2007). A survey of context-aware middleware. In Proceedings of the 25th conference on IASTED International Multi-Conference: Software Engineering, pages 148–155, Anaheim, CA, USA. ACTA Press. [Kopecký et al., 2007] Kopecký, J., Vitvar, T., Bournez, C., and Farrell, J. (2007). Sawsdl: Semantic annotations for wsdl and xml schema. IEEE Internet Computing, 11:60–67. [Lassila et al., 1998] Lassila, O., Swick, R. R., Wide, W., and Consortium, W. (1998). Resource Description Framework (RDF) Model and Syntax Specification. [Lopes et al., 2008] Lopes, F., Delicato, F., Batista, T., and Cacho, N. (2008). On the integration of context-based heterogeneous middleware for ubiquitous computing. In Proceedings of the 6th international workshop on Middleware for pervasive and ad-hoc computing, MPAC ’08, pages 31–36, New York, NY, USA. ACM. [Lopes et al., 2009a] Lopes, F., Delicato, F., Batista, T., and Pires, P. (2009a). A platform based on web services for context middleware integration. In Proceedings of the XV Brazilian Symposium on Multimedia and the Web, WebMedia ’09, pages 13:1–13:8, New York, NY, USA. ACM. [Lopes et al., 2009b] Lopes, F., Delicato, F. C., Batista, T., and Pires, P. F. (2009b). Context-based heterogeneous middleware integration. In Proceedings of the 2009 Workshop on Middleware for Ubiquitous and Pervasive Systems, WMUPS ’09, pages 13–18, New York, NY, USA. ACM. [Loughran and Hatcher, 2007] Loughran, S. and Hatcher, E., editors (2007). Ant in Action. Second Edition of Java Development with Ant. 2 edition. [Lowry, 2012] Lowry, R. (2012). Concepts and Applications of Inferential Statistics. http: //faculty.vassar.edu/lowry/webtext.html. [Manola and Miller, 2004] Manola, F. and Miller, E., editors (2004). RDF Primer. W3C Recommendation. World Wide Web Consortium. [Martin et al., 2004] Martin, D., Paolucci, M., McIlraith, S., Burnstein, M., McDermott, D., McGuinness, D., Parsia, B., Payne, T. R., Sabou, M., Solanki, M., Srinivasan, N., and Sycara, K. (2004). Bringing semantics to web services: The owl-s approach. In Cardoso, J. and Sheth, A., editors, First International Workshop on Semantic Web Services and Referências Bibliográficas 115 Web Process Composition (SWSWPC 2004), volume 3387 of LNCS, pages 26–42. Springer. [McIlraith et al., 2001] McIlraith, S. A., Son, T. C., and Zeng, H. (2001). Semantic web services. IEEE Intelligent Systems. Special Issue on the Semantic Web, 16(2):46–53. [Microsystems, 1998] Microsystems, I. S. (1998). Java message service, version 1.0.2 (jms specification). Technical report, Sun Microsystems, Inc. [Missikoff et al., 2002] Missikoff, M., Navigli, R., and Velardi, P. (2002). The usable ontology: An environment for building and assessing a domain ontology. In In Pro- ceedings of the International Semantic Web Conference (ISWC, volume 2342, pages 39–53. Springer-Verlag. [Mitra, 2003] Mitra, N. (2003). SOAP version 1.2 Part 0: Primer W3C Recommendation. [Montgomery, 2009] Montgomery, D. C. (2009). Design and Analysis of Experiments. John Wiley & Sons, Inc., 7 edition. [Natalya Fridman Noy, 2001] Natalya Fridman Noy, D. L. M. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05, Knowledge Systems, AI Laboratory, Stanford University. Stanford Medical Informatics Technical Report SMI-2001-0880. [Noy et al., 2000] Noy, N. F., Fergerson, R. W., and Musen, M. A. (2000). The knowledge model of protégé-2000: Combining interoperability and flexibility. In Proceedings of the 12th European Workshop on Knowledge Acquisition, Modeling and Management, EKAW ’00, pages 17–32, London, UK. Springer-Verlag. [Obeo Network, 2007] Obeo Network (2007). Acceleo Generator. http://www.acceleo.org. [Obeo Network, 2012] Obeo Network (2012). Uml to java generator 1.0.0. [Object Management Group, 2006] Object Management Group (2006). Meta Object Faci- lity (MOF) Core Specification Version 2.0. [Object Management Group, 2007] Object Management Group (2007). XML Metadata Interchange (XMI). Object Management Group. [Object Management Group, 2008] Object Management Group (2008). Meta Object Faci- lity (MOF) 2.0 Query/View/Transformation Specification Version 1.0. http://www.omg. org/spec/QVT/1.0/PDF/. Referências Bibliográficas 116 [Object Management Group, 2009] Object Management Group (2009). Ontology defini- tion metamodel (omg) version 1.0. Technical Report formal/2009-05-01, Object Mana- gement Group. [Perera et al., 2006] Perera, S., Herath, C., Ekanayake, J., Chinthaka, E., Ranabahu, A., Jayasinghe, D., Weerawarana, S., and Daniels, G. (2006). Axis2, middleware for next generation web services. In Proceedings of the IEEE International Conference on Web Services, pages 833–840, Washington, DC, USA. IEEE Computer Society. [Pondrelli, 2005] Pondrelli, L. (2005). An mdd annotation methodology for semantic enhanced service oriented architectures. In Proc. CEUR Workshop, pages –1–1. [Prod’hommeaux, 2007] Prod’hommeaux, E. (2007). W3C RDF validation service. http://www.w3.org/RDF/Validator/. [Rager et al., 2004] Rager, D., Self, T., and Lerner, J. (2004). Owl validator. http://projects.semwebcentral.org/projects/vowlidator/. [Silva Parreiras et al., 2007] Silva Parreiras, F., Staab, S., and Winter, A. (2007). Twouse: Integrating uml models and owl ontologies. Technical Report 16/2007, Institut für Informatik, Universitãt Koblenz-Landau. Technical Report. [Sirin and Parsia, 2004] Sirin, E. and Parsia, B. (2004). The owl-s java api. In Proceedings of the Third International Semantic Web Conference. [Sollazzo et al., 2002] Sollazzo, T., Handschuh, S., Staab, S., Frank, M. R., and Stojano- vic, N. (2002). Semantic web service architecture – evolving web service standards toward the semantic web. In Proceedings of the Fifteenth International Florida Artificial Intelligence Research Society Conference, pages 425–429. AAAI Press. [Sparx Systems, 2000] Sparx Systems (2000). Enterprise Architect. Sparx Systems. [Srinivasan et al., 2005] Srinivasan, N., Paolucci, M., and Sycara, K. (2005). CODE: A Development Environment for OWL-S Web services. Technical Report CMU-RI-TR-05- 48, Robotics Institute, Carnegie Mellon University, Pittsburgh, PA. [Stahl and Völter, 2006] Stahl, T. and Völter, M. (2006). Model-Driven Software Development: Technology, Engineering, Management. Wiley, Chichester, UK. [Steinberg et al., 2008] Steinberg, D., Budinsky, F., Paternostro, M., and Merks, E. (2008). EMF: Eclipse Modeling Framework (2nd Edition). Addison-Wesley Professional, 2 edition. Referências Bibliográficas 117 [Strang and Popien, 2004] Strang, T. and Popien, C. L. (2004). A context modeling survey. In UbiComp 1st International Workshop on Advanced Context Modelling, Reasoning and Management, pages 31–41, Nottingham. [Tiago Semprebom and Mendonça, 2007] Tiago Semprebom, M. Y. C. and Mendonça, I. (2007). Ontologias e protégé. Technical report, Universidade Federal de Santa Catarina. [Uschold and Grüninger, 1996] Uschold, M. and Grüninger, M. (1996). Ontologies: princi- ples, methods, and applications. Knowledge Engineering Review, 11(2):93–155. [Wikipedia, 2011] Wikipedia (2011). Web service — Wikipedia, the free encyclopedia. [Online; Ãoltimo acesso em 22 de Novembro de 2011]. [Yang and Chung, 2006a] Yang, J.-H. and Chung, I.-J. (2006a). Automatic Generation of Service Ontology from UML Diagrams for Semantic Web Services. pages 523–529. [Yang and Chung, 2006b] Yang, J.-H. and Chung, I.-J. (2006b). A method for automatic generation of owl-s service ontology. JIPS, 2(2):114–123. [Zuur et al., 2009] Zuur, A. F., Ieno, E. N., and Meesters, E. (2009). A Beginner’s Guide to R. Springer. ISBN: 978-0-387-93836-3. APÊNDICE A XSL Transformation XSL (EXtensible Stylesheet Language) é uma família de linguagens para forma- tação de documentos XML. XSL é utilizada para criar estilos (stylesheets) para documen- tos XML da mesma forma que CSS (Cascading Style Sheets) cria estilos para documentos HTML. Com XSL é possível converter um documento XML descrito por um determinado DTD ou Schema XML em outro documento XML descrito por um DTD ou Schema XML diferente. Isto é bastante útil para serviços Web, pois um determinado serviço Web pode utilizar uma formatação das mensagens SOAP diferente daquela que o requisitante está apto a trabalhar. XSL pode também filtrar ou ordenar os elementos de um documento XML. XSL é dividida em três partes: XSL Transformation (XSLT) uma linguagem XML para transformação de documentos XML. XML Path Language (XPath) uma linguagem não XML usada pela XSLT para navegar sobre partes de documentos XML. XSL Formatting Objects (XSL-FO) uma linguagem para especificação da formatação visual de documentos XML. XSLT é uma linguagem declarativa que cria stylesheets para transformação de documentos XML. Um stylesheet contém um conjunto de templates e expressões. Um template descreve a saída a ser gerada baseada em certos critérios. Uma expressão determina em qual elemento XML deve ser aplicada a transformação. O princípio de funcionamento do XSLT é bastante simples, conforme podemos observar na Figura A.1. Processadores XSLT recebem como entrada documentos XML e stylesheets XSLT para então produzir um novo documento XML baseado nas regras de templates definidas no stylesheet XSLT. O documento original não é modificado, mas o novo documento pode ser criado com sintaxe XML ou qualquer outro formato, tal como HTML ou SQL. XSLT utiliza um poderoso mecanismo de casamento de padrões para selecionar pedaços dos documentos XML para transformação. As regras de templates dos stylesheets XSLT são definidas para serem aplicadas em padrões, que podem ser elementos ou atributos XML. Os padrões são definidos utilizando a linguagem XPath. Apêndice A 119 Figura A.1: Transformação em XSLT O processador XSLT constrói representações em árvore para o documento XML de entrada e o documento de saída. O processador XSLT começa o processamento da representação em árvore do documento XML a partir do elemento root, procurando no stylesheet XSLT se existe algum casamento para este nó, se existir o casamento ele verifica o template que deve ser aplicado. Os templates definidos no XSLT direcionam o processador para criar novos nós na árvore de saída ou então processar outros nós da árvore do documento XML da mesma forma que o nó root. Ao final do processamento a árvore de saída estará montada e o documento de saída será derivado a partir dela. Uma característica interessante do XSLT é que ele pode ser especificado dentro do documento XML ao qual ele será aplicado. Para adicionar o XSLT stylesheet no documento XML basta inserir a seguinte instrução após a declaração XML: XSLT utiliza várias declarações de elementos e funções pré-estabelecidas para criar os stylesheets. O poder de expressão das declarações e a vasta quantidade de funções tornam esta linguagem bastante poderosa. O propósito deste documento não é apresenta toda a linguagem XSLT, apenas estamos interessados em demonstrar sua funcionalidade e os principais elementos e funções. Uma referência completa para XSLT pode ser obtida em [w3c, 1999]. Para efeito de exemplificação considere a mensagem SOAP representada no trecho de Código A.1. Uma mensagem SOAP é um documento XML, portanto XSLT pode ser utilizado para transformá-la em outro documento. Apêndice A 120 Código A.1 Mensagem SOAP 1 2 3 4 5 8 0 9 10 11 12 13 14 15 A mensagem SOAP representa o retorno de um serviço Web. O conteúdo desta mensagem que é interpretado pela aplicação está dentro do elemento ns:subscribeBurdenAssyncService. O Código A.2 ilustra o documento XLST definido para transformar a mensagem SOAP em outro documento XML. Apêndice A 121 Código A.2 XSLT para a mensagem SOAP 1 6 7 9 10 11 12 13 http://www.w3.org/2001/XMLSchema#string 14 15 16 17 18 http://www.w3.org/2001/XMLSchema#string 19 20 21 22 23 http://www.w3.org/2001/XMLSchema#string 24 25 26 27 28 http://www.w3.org/2001/XMLSchema#string 29 30 31 32 33 34 No documento XSLT a declaração será automaticamente colocada no documento de saída. Este texto não é uma declaração XSLT, pois não tem o prefixo xsl. A declaração seguinte, define uma variável identificada por x com o valor "tns1:return". Esta variável será utilizada no restante do documento XSLT para referenciar seu valor com a seguinte sintaxe: $x. Prosseguindo com a análise, a declaração define um elemento XML para o documento de saída. O primeiro elemento definido tem o nome j.0:idRegime e possui um atributo chamado rdf:datatype com o valor especificado pelo texto http://www.w3.org/2001/XMLSchema#string O valor deste elemento é o mesmo valor do elemento "$x/tns2:idRegime"do documento de entrada. A expressão "$x/tns2:idRegime"é uma expressão XPath, onde / é um seletor para subdiretórios. Desta forma esta expressão representa o elemento idRegime que é de- finido no namespace tns2 que, por sua vez está definido dentro do namespace identificado pela variável $x. Conforme podemos observar no Código A.1 o elemento ns:return está definido dentro do namespace "http://service/xsd"que é o valor da variável x. As outras declarações XSLT especificam mais três elementos, burdenValue, burdenValue e stem- Size. Dessa forma o documento XML criado a partir das transformações XSLT terá a seguinte forma, ilustrado no Código A.3: Código A.3 Documento 1 3 4 5 6 7 0 8 9 10 11 12 13 APÊNDICE B Tecnologias dos serviços Web B.1 SOAP SOAP (Simple Object Access Protocol) [Mitra, 2003] é o protocolo de comu- nicação, baseado em XML e padronizado pela W3C, utilizado pelos serviços Web para codificar as mensagens entre o serviço Web e o cliente. Pelo fato de ser baseado em XML ele é independente de plataforma e linguagem de programação. SOAP tem uma sintaxe simples e flexível, normalmente é encapsulado em uma mensagem HTTP, porém pode ser utilizado em conjunto com outros protocolos como JMS (Java Message Service) [Microsystems, 1998] e SMTP (Simple Mail Transport Protocol) [Easton et al., 2008]. SOAP pode ser transmitido facilmente pela Internet sem que o desenvolvedor preocupe-se com os bloqueios impostos por alguns firewalls e proxys. Entretanto, por causa do formato XML, SOAP pode ser consideravelmente mais lento do que outras tecnologias como CORBA. Porém, quando um número reduzido de mensagens ou mensagens pequenas são transmitidas, este problema é minimizado. Uma mensagem SOAP é um documento XML que contém os seguintes elemen- tos: • Um elemento Envelope que identifica o documento XML como uma mensagem SOAP; • Um elemento Header que contém informações de cabeçalho da mensagem SOAP, normalmente específicas da aplicação, como por exemplo, informações de auten- ticação. O elemento Header de uma mensagem SOAP é opcional e se ele estiver presente na mensagem, ele deve ser o primeiro filho do elemento Envelope; • Um elemento Body que contém informações de chamadas e respostas dos pares envolvidos na comunicação, ou seja, o cliente e o serviço Web; • Um elemento Fault que pode conter informações de erros e status. Para efeito de demonstração considere o seguinte método na linguagem Java que representa a assinatura de uma operação de um serviço Web: public Regime subscribeBurdenAssyncService(OilWell well, Apêndice B 124 PumpUnit unit); O retorno do método subscribeBurdenAssyncService é definido como um objeto Regime. Este objeto é um POJO1 que contém os atributos burden, cpm, idRegime e stemSize, todos do tipo String. O trecho de Código B.1 ilustra a mensagem SOAP de resposta a uma requisição ao serviço Web subscribeBurdenAssyncService. As linhas 1 a 5 determinam o cabeçalho da mensagem do protocolo HTTP e, logo em seguida, na linha 6 existe uma linha em branco que separa o cabeçalho do corpo da mensagem HTTP. A mensagem SOAP é encapsulada dentro do corpo da mensagem HTTP, conforme podemos observar a partir da linha 7 até o fim do documento. A mensagem SOAP inicia-se com a seguinte declaração XML: que identifica o documento como um documento XML com o tipo de codificação UTF-8 Unicode. O atributo xmlns, do XML Schema, é usado para declarar ligações de namespace com prefixos, conforme o caso do prefixo ns na linha 11. Dessa forma,os atributos xmlns:soapenv e soapenv:encodingStyle do elemento Envelope são utilizados para declarar, respectivamente os namespaces para o Envelope SOAP e os tipos de dados (data types). No trecho de Código B.1 temos apenas a declaração do namespace para o elemento Envelope, representado da linha 9. O namespace para os tipos de dados pode ser declarado em qualquer elemento da mensagem SOAP, sendo que sua visibilidade será para o conteúdo do elemento e para seus filhos. 1Plain Old Java Object - um objeto Java que contém apenas atributos e não implementa nenhuma interface Apêndice B 125 Código B.1 Exemplo de Mensagem SOAP de Resposta 1 HTTP/1.1 200 OK 2 Server: Apache-Coyote/1.1 3 Content-Type: text/xml;charset=utf-8 4 Date: Mon, 31 Oct 2011 02:25:25 GMT 5 Connection: close 6 7 8 10 11 12 15 0 16 17 18 19 20 21 22 O elemento Body inicia-se na linha 10 e termina na linha 21 do trecho de Código B.1. O elemento Body contém um subelemento (linha 11) ns:subscribeBurdenAssyncServiceResponse, onde é declarado o namespace http://service/xsd que está associado ao prefixo ns. Todos os elementos dos names- paces http://service/xsd e http://model/xsd estão definidos no arquivo WSDL do serviço Web. Nas linhas 12 e 13 existem duas outras declarações de namespaces, http://model/xsd e http://www.w3.org/2001/XMLSchema-instance, respectivamente associados aos prefixos ax29 e xsi. Esses namespaces possuem visibilidade em cima do elemento ns:return e seus filhos. Na linha 14 o atributo xsi:type é usado para identificar tipos complexos derivados. Ele aponta para uma referência do Schema que define o seu tipo. Neste caso, ax29:Regime corresponde ao identificador http://model/xsd/Regine. Logo, pode-se con- cluir que, ns:return é um tipo http://model/xsd/Regime que está declarado no documento WSDL do serviço Web. As linhas 15 a 18 contêm os elementos burden, cpm, idRegime e stemSize. O Apêndice B 126 valor associado para o elemento burden é 0 enquanto que para os demais não existe valor associado, porém a mensagem SOAP continua válida, pois um elemento da mensagem SOAP que não contém conteúdo pode ser válido se ele tem o atributo xsi:nil com o valor true. As linhas 19 e 20 definem as marcações XML para fechar a especificação dos elementos ns:return e ns:subscribeBurdenAssyncServiceResponse. Já na linha 21 e 22 os elementos Body e Envelope da mensagem SOAP são fechados. A mensagem SOAP associada a requisição do serviço pode ser visualizada no trecho de Código B.2. Código B.2 Exemplo de Mensagem SOAP de Requisição 1 POST /axis2/services/WellDatabase.WellDatabaseHttpSoap11Endpoint/ HTTP/1.0 2 Content-Type: text/xml; charset=utf-8 3 Accept: application/soap+xml, application/dime, multipart/related, text/* 4 User-Agent: Axis/1.4 5 Host: localhost:8081 6 Cache-Control: no-cache 7 Pragma: no-cache 8 SOAPAction: "urn:subscribeBurdenAssyncService" 9 Content-Length: 444 10 X-Forwarded-For: 127.0.0.1 11 12 13 19 20 21 22 23 A primeira linha do trecho de Código B.2 ilustra a requisição do protocolo HTTP. A mensagem SOAP foi encapsulada dentro de uma requisição HTTP do tipo POST para o EndPoint do serviço Web. A declaração dos elementos e a estrutura da mensagem SOAP de requisição é semelhante a mensagem SOAP de resposta. Na linha 18 a declaração do atributo so- Apêndice B 127 apenv:encodingStyle estabelece o namespace para os tipos de dados (data types) do elemento Envelope. Na linha 20 é definido o elemento subscribeBurdenAssyncService. Ele é o parâmetro para o serviço Web e sua estrutura está definida no names- pace http://service/xsd que foi especificado no arquivo WSDL. O trecho de Có- digo B.3 ilustra uma parte do documento WSDL que define o tipo complexo subscribeBurdenAssyncService. Código B.3 Definição do tipo complexo subscribeBurdenAssyncService 1 ... 2 3 5 6 7 8 10 12 13 14 15 16 ... 17 18 ... Os parâmetros OilWell e PumpUnit de subscribeBurdenAssyncService podem as- sumir valores null. Desta forma, conforme podemos observar na mensagem de requisição SOAP, nenhum valor é especificado para estes atributos. B.2 WSDL WSDL (Web Service Definition Language) é a linguagem baseada em XML utilizada para descrever o serviço Web. WSDL define um contrato entre o requisitante do serviço e o seu provedor a partir da descrição de quatro aspectos relacionados ao serviço Web: Interface fornece informações que descrevem as funções/operações do serviço; Apêndice B 128 Data type são informações que descrevem os tipos de dados para todas as mensagens de requisição ou resposta; Binding descreve o tipo de protocolo de transporte a ser utilizado; Address contém informações para localizar um determinado serviço. A versão atual da especificação WSDL é a 1.2, renomeada para 2.0 devido às diferenças substancias para a versão 1.1. Entretanto, várias ferramentas e frameworks ainda adotam a versão 1.1. Neste trabalho utilizaremos a versão 1.1 da especificação WSDL por motivos de compatibilidade com nosso estudo de caso, a plataforma Open- COPI [Lopes et al., 2008, Lopes et al., 2009a, Lopes et al., 2009b] que utiliza a lingua- gem OWL-S na versão 1.1, que é compatível somente com a especificação WSDL 1.1. WSDL é dividida em oito principais elementos: Definition, Types, Message, Operation, Port Type, Binding, Port, Service. A Figura B.1 ilustra os elementos da WSDL e suas relações. Figura B.1: Elementos do WSDL 1.1 Definition É o elemento WSDL root que engloba todos os demais elementos. Nele é declarado todos os namespaces utilizados no documento WSDL. Types É um contêiner para os tipos de dados definidos e utilizados pelos clientes e o serviço Web. WSDL utiliza a especificação do Schema XML W3C como o sistema de tipos padrão. Isto significa que para um determinado serviço Web que utiliza apenas tipos definidos no Schema XML, como por exemplo, os tipos String e Integer, o elemento types da especificação deste serviço Web não é necessário. Apêndice B 129 Message Define quais são as mensagens que serão transmitidas entre o cliente e o serviço Web. Um elemento message contém informações necessárias para executar uma operação do serviço Web. O elemento message tem um nome único, definido pela propriedade name, que é utilizado para identificar unicamente cada mensagem. O elemento message pode ser composto por zero ou mais elementos do tipo part, que referenciam os parâmetros ou retorno das mensagens. Cada elemento part oferece uma descrição lógica de uma parte do conteúdo de um elemento message e também contém um identificador único, definido pela propriedade name . Operation Oferece uma descrição abstrata de uma ação suportada pelo serviço. Quando estiver dentro do elemento portType ele especifica a “assinatura” do método/ope- ração do serviço Web. Já quando está dentro do elemento binding ele define como as mensagens SOAP serão codificadas. As mensagens podem ser do tipo RPC ou Document. O elemento operation também define a natureza da operação e o seu comportamento com o Endpoint associado. Existem quatro possíveis tipos: one-way o Endpoint da operação pode receber uma mensagem de requisição porém não retorna nenhuma mensagem; request-response o Endpoint da operação pode receber uma mensagem de requi- sição e sempre retorna uma mensagem de resposta; solicit-response o Endpoint da operação pode enviar uma mensagem de requisição e irá esperar por uma resposta; notification o Endpoint da operação pode enviar uma mensagem, mas não irá esperar por uma resposta. Port Type Este elemento WSDL oferece uma abstração das operações suportadas pelos Endpoints definidos pelo serviço Web. O elemento portType combina múltiplos elementos message para formar todas as mensagens possíveis envolvidas em uma operação do serviço Web. Por exemplo, em uma operação do tipo request-response o elemento portType combina um elemento message para a requisição e outro para a resposta. Binding Oferece o protocolo e a especificação do formato dos dados para um elemento portType em particular. Ele determina como as mensagens podem ser transmitidas a partir da especificação do estilo das mensagens SOAP (RPC ou Document) e do protocolo de aplicação utilizado para o transporte da mensagem SOAP, normalmente HTTP. Port Este elemento define o endereço de um EndPoint do serviço Web. Normalmente ele é representado por um URL HTTP, combinando o binding e o protocolo a ser utilizado. Service É uma coleção de elementos do tipo port. O elemento service expõe a localização de todos os EndPoints do serviço Web. Apêndice B 130 Um documento WSDL pode conter outros elementos além desses especificados. Por exemplo, no caso de operações do tipo solicit-response ou notification é necessário especificar extensões do elemento binding para permitir sua utilização. O propósito desse documento não é apresentar toda especificação WSDL, somente os conceitos mais importantes e relevantes para condução do trabalho. A especificação completa do WSDL pode ser obtida em [Christensen et al., 2001]. O trecho de Código B.4 apresenta a definição dos elementos message do docu- mento WSDL para o serviço Web subscribeBurdenAssyncService. O elemento message subscribeBurdenAssyncServiceRequest é composto por um elemento part que está defi- nido pelo tipo complexo subscribeBurdenAssyncService, ilustrado no Código B.3. Código B.4 Definição do elemento message 1 ... 2 3 4 5 6 7 8 ... 9 O elemento portType do serviço Web têm o nome WellDatabasePortType e está ilustrado no trecho de Código B.5. O elemento portType juntamente com operation especificam a operação subscribeBurdenAssyncService utilizando os elementos message que foram definidos anteriormente. A operação em questão é do tipo request-response. Código B.5 Definição do elemento portType 1 ... 2 3 4 6 8 9 10 ... 11 O elemento binding tem dois atributos, name e type. O atributo name de- fine o nome do binding, neste caso WellDatabaseSoap11Binding, enquanto que o atri- buto type aponta para o elemento portType WellDatabasePortType. O elemento interno Apêndice B 131 soap:binding define que o protocolo HTTP será utilizado para transportar as mensa- gens SOAP que estão codificadas com o estilo document, conforme o Código B.6 ilustra. É possível observar também que o elemento binding exporta qual é a opera- ção subscribeBurdenAssyncService e define o tipo de codificação para os seus inputs e outputs. Código B.6 Definição do elemento binding 1 ... 2 3 5 6 8 9 10 11 12 13 14 15 16 ... 17 WSDL especifica a interface de um serviço Web, mas se não existir meios para alcançá-lo, o serviço não será utilizado. Uma solução para o compartilhamento de serviços Web é o UDDI, apresentado na próxima seção. B.3 UDDI Universal Description Discovery and Integration (UDDI) é a especificação de um diretório de serviços onde é possível registrar e buscar serviços Web. O UDDI é baseado em XML, utiliza o protocolo SOAP para comunicação e WSDL para descrição dos serviços Web. O UDDI Business Registry é uma implementação da especificação UDDI que permite busca por dados UDDI e também o registro de organizações e seus serviços. Os dados de registro de cada organização são divididos em três principais categorias: Apêndice B 132 White Pages inclui informações gerais de uma organização tais como endereço, nome da empresa, descrição do negócio da empresa, etc; Yellow Pages inclui dados de classificação gerais, baseados em uma taxonomia padrão para cada organização ou serviço oferecido; Green Pages contêm informações técnicas sobre os serviços expostos pelas organiza- ções. O UDDI somente categoriza seus registros. Ele não estrutura os registros seman- ticamente a partir da atribuição de um significado a cada registro. Esta é a sua grande desvantagem. Aplicações invocam diretamente os arquivos WSDL em detrimento à utili- zação das APIs (Application Programm Interface) baseadas em palavra-chave para busca no UDDI. B.4 Apache Axis2 Axis2 [Perera et al., 2006] é um framework Open Source desenvolvimento pela Apache para criação de serviços Web. O framework contém várias APIs e utilitários que ajudam o desenvolvimento de serviços Web. Dentre as funcionalidades providas pelo Axis2 duas delas são usadas diretamente neste trabalho: java2wsdl - um mecanismo para transformar os métodos públicos de uma classe Java em operações de um serviço Web. Este mecanismo automaticamente deriva os tipos complexos do arquivo WSDL a partir da assinatura dos métodos. wsdl2java - um mecanismo para criar implementação de classes para comunicação com o serviço descrito em um documento WSDL. Axis2 implementa a especificação SOAP e cria stubs e skeletons para o serviço Web automaticamente. No contexto deste trabalho Axis2 é utilizado para criar serviços Web. Desta forma, a especificação da interface do serviço Web modelada a partir do profile UML deve ser transformada para uma classe Java e enviada para o framework Axis2 para que ele gere o serviço Web correspondente. APÊNDICE C Tranformação XSLT 1 2 15 17 18 19 20 21 22 2.1 23 http:///schemas/Profile/ _AUjdELDkEeGj6oQuqPBRyw/30 ../br.ufrn.consiste.owls.uml.profile/ AutoWebS_UMLProfile.profile.uml#_AUkrMLDkEeGj6oQuqPBRyw 24 25 27 Apêndice C 134 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Package 44 45 46 47 48 49 50 51 uml:Class 52 53 54 55 56 57 58 Apêndice C 135 59 60 61 62 63 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 83 84 85 86 87 88 89 Class 90 91 92 93 94 95 96 equivalentProperty 97 Apêndice C 136 98 99 100 101 102 rdfs:subPropertyOf 103 104 105 106 107 108 inverseOf 109 110 111 112 113 114 115 116 117 118 119 120 DataType 121 122 123 124 125 126 equivalentProperty 127 128 129 130 131 132 rdfs:subPropertyOf 133 134 135 136 137 138 Apêndice C 137 139 140 141 142 143 144 145 146 147 http://www.w3.org/2001/XMLSchema#string 148 149 150 http://www.w3.org/2001/XMLSchema#int 151 152 153 http://www.w3.org/2001/XMLSchema#double 154 155 156 http://www.w3.org/2001/XMLSchema#long 157 158 159 http://www.w3.org/2001/XMLSchema#anyURI 160 161 162 http://www.w3.org/2001/XMLSchema#duration 163 164 165 http://www.w3.org/2001/XMLSchema#decimal 166 167 168 169 # 170 171 172 173 174 175 176 177 178 179 Apêndice C 138 180 Collection 181 182 183 unionOf 184 185 186 187 188 189 190 191 192 Collection 193 194 195 distinctMembers 196 197 198 199 200 201 202 203 Collection 204 205 206 intersectionOf 207 208 209 210 211 212 213 214 216 218 Apêndice C 139 219 220 221 223 224 225 226 227 Collection 228 229 230 232 234 236 238 240 241 243 244 245 246 247 248 249 250 Apêndice C 140 251 252 253 254 255 256 258 259 260 261 # 262 263 264 265 266 267 268 269 270 271 272 273 274 276 277 278 280 282 283 285 286 Apêndice C 141 287 289 291 292 293 294 295 296 297 298 299 300 301 302 303 304 306 307 308 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 Apêndice C 142 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 344 345 346 347 348 Collection 349 350 352 354 356 357 359 360 362 363 364 365 # 366 367 368 369 370 371 372 373 # 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 Collection 389 390 391 instanceOf 392 393 394 395 396 397 398 399 400 Apêndice C 144 401 402 property 403 404 405 407 408 409 410 411 412 414 415 416 417 418 420 421 422 no 423 424 425 426 427 429 430 431 432 yes 433 434 435 436 Apêndice C 145 437 438 439 # 441 442 443 444 # 446 447 448 449 450 451 452 453 454 455 456 457 458 459 461 462 464 465 466 467 468 SymmetricProperty 469 470 471 TransitiveProperty 472 Apêndice C 146 473 474 FunctionalProperty 475 476 477 InverseFunctionalProperty 478 479 480 481 482 484 485 486 487 488 489 490 491 492 APÊNDICE D Tranformação QVT 1 modeltype OWLS "strict" uses OWLS(’br.ufrn.consiste.owls’); 2 modeltype UML "strict" uses uml(’http://www.eclipse.org/uml2/3.0.0/UML’); 3 4 transformation UMLProfile2OWLS(in inUML:UML, out outOWLS:OWLS); 5 6 property namespaceId : String = "namespace"; 7 property serviceName : String = "name"; 8 9 main() { 10 //Procura todas as interfaces com o estereotipo SemanticWebService 11 inUML.objectsOfType(UML::Interface)->forEach(swsInterface) { 12 if(swsInterface.getAppliedStereotypes()->any(name=’SemanticWebService’)<>null) then { 13 swsInterface.getOperations()->forEach(operation) { 14 //Para cada Operation cria-se uma modelo OWL-S 15 if(operation.getAppliedStereotypes()->any(name=’SWSOperation’)<>null) then { 16 operation.map createOWLS(); 17 }endif; 18 }; 19 }endif; 20 }; 21 } 22 23 mapping UML::Operation::createOWLS() : OWLS::OwlsOntology 24 when {self.interface.getAppliedStereotypes()->any(name=’SemanticWebService’)<>null 25 and self.getAppliedStereotypes()->any(name=’SWSOperation’)<>null} { 26 init { 27 log(’Building the OWL-S ’ + self.name + ’ Ontology’); Apêndice D 148 28 this.namespaceId := getTaggedValue(self.interface, ’SemanticWebService’, ’ targetNamespace’); 29 this.serviceName := self.name; 30 } 31 32 has_namespaceDeclaration := createNamespaceDeclarations();// OK 33 has_ontologyImports := createOntologyImports(getDomainOntologies(self.interface)) ;//FIXME: verificar pq não consegue pegar uma lista de String 34 35 var serviceProfile := object OWLS::Profile { 36 id := this.serviceName + ’Profile’; 37 textDescription := getTaggedValue(self.interface, ’SemanticWebService’, ’WSDL Documentation’); 38 serviceName := this.serviceName; 39 serviceClassification := ’’; 40 serviceProduct := ’’; 41 }; 42 var serviceGrounding := object OWLS::WsdlGrounding { 43 id := this.serviceName + ’Grounding’; 44 }; 45 var serviceModel := object OWLS::AtomicProcess { 46 id := this.serviceName + ’Process’; 47 }; 48 49 var service := object OWLS::Service { 50 id := this.serviceName; 51 presents := serviceProfile; 52 describes := serviceModel; 53 supports := serviceGrounding; 54 }; 55 56 var wsdlAtomicGrounding:= object WsdlAtomicProcessGrounding { 57 id := this.serviceName + ’AtomicProcessGrounding’; 58 owlProcess := serviceModel; 59 wsdlDocument := getTaggedValue(self.interface, ’SemanticWebService’, ’URI WSDL Document’); 60 //wsdlDocument=http://localhost:8080/axis2/services/WellDatabase?wsdl 61 wsdlInputMessage := getTaggedValue(self.interface, ’SemanticWebService’, ’ targetNamespace’) + ’#’ + serviceName + ’Request’; 62 // wsdlInputMessage="http://service/#subscribeBurdenAssyncServiceRequest" Apêndice D 149 63 wsdlOutputMessage := getTaggedValue(self.interface, ’SemanticWebService’, ’ targetNamespace’) + ’#’ + serviceName + ’Response’; 64 // wsdlOutputMessage="http://service/#subscribeBurdenAssyncServiceResponse" 65 wsdlOperation := object WsdlOperationRef { 66 portType := getTaggedValue(self.interface, ’SemanticWebService’, ’URI WSDL Document’) + ’#’+ self.interface.getValue(self.interface. getAppliedStereotypes()->any(name = ’SemanticWebService’), ’endPoint’). oclAsType(EnumerationLiteral).name + ’EndPoint’; 67 //http://localhost:8080/axis2/services/WellDatabase?wsdl# WellDatabaseHttpSoap11Endpoint 68 operation := getTaggedValue(self.interface, ’SemanticWebService’, ’URI WSDL Document’) + ’#’ + serviceName; 69 //http://localhost:8080/axis2/services/WellDatabase?wsdl# subscribeBurdenAssyncService 70 }; 71 }; 72 73 serviceProfile.presentedBy := service; 74 serviceGrounding.supportedBy := service; 75 serviceGrounding.hasAtomicProcessGrounding := wsdlAtomicGrounding; 76 serviceModel.describedBy := service; 77 78 has_serviceProfile := serviceProfile; 79 has_serviceGrounding := serviceGrounding; 80 has_serviceModel := serviceModel; 81 has_service := service; 82 has_wsdlAtomicProcessGrounding += wsdlAtomicGrounding; 83 84 //TODO: criar WsdlInputMessage e WsdlOutputMessage 85 self.ownedParameter->forEach(parameter) { 86 if(parameter.direction = ParameterDirectionKind::_in) then { 87 var input := object OWLS::Input{ 88 id := this.serviceName + parameter.type.name; 89 label := parameter.name; 90 parameterType := getParameterType(parameter); 91 }; 92 serviceProfile.hasInput += input; 93 serviceModel.hasInput += input; 94 95 wsdlAtomicGrounding.wsdlInput += object WsdlInputMessageMap { Apêndice D 150 96 wsdlMessagePart := getTaggedValue(parameter.operation.interface, ’ SemanticWebService’, ’targetNamespace’) + ’#’ + parameter.name; 97 //"http://localhost:8080/axis2/services/WellDatabase?wsdl#pumpUnit" 98 owlsParameter := input; 99 xsltTransformationString := buildXsltTransformation(); 100 }; 101 }endif; 102 103 if(parameter.direction = ParameterDirectionKind::_return) then { 104 var output := object OWLS::Output{ 105 id := this.serviceName + parameter.type.name; 106 label := ’return’; 107 parameterType := getParameterType(parameter); 108 }; 109 serviceProfile.hasOutput += output; 110 serviceModel.hasOutput += output; 111 wsdlAtomicGrounding.wsdlOutput += object WsdlOutputMessageMap { 112 owlsParameter := output; 113 wsdlMessagePart := getTaggedValue(parameter.operation.interface, ’ SemanticWebService’, ’targetNamespace’) + ’#’ + parameter.name; 114 //"http://localhost:8080/axis2/services/WellDatabase?wsdl#return" 115 xsltTransformationString := buildXsltTransformation(); 116 } 117 }endif; 118 }; 119 } 120 query buildXsltTransformation() : String {...} 121 122 /** 123 Retorna o tipo de um parametro. 124 Um parametro pode ser um tipo primitivo UML, um tipo definido no XML Schema ou uma classe definida em uma ontologia. 125 **/ 126 query getParameterType(in parameter: UML::Parameter) : String { 127 if(parameter.type.getAppliedStereotypes()->any(name=’owl:Class’)<>null) then { 128 return getTaggedValue(parameter.type.package,’owl:Ontology’,’xmlns’) + ’/’ + parameter.type.package.name + ’.owl#’ + parameter.type.name; 129 //http://www.example.org/owls/OilMonitor.owl#OilWell 130 } else { 131 if (parameter.type.oclIsKindOf(UML::PrimitiveType)) then { 132 //TODO: Refatorar este trecho Apêndice D 151 133 return ’http://www.w3.org/2001/XMLSchema#’ + parameter.type.name.toLower(); 134 //http://www.w3.org/2001/XMLSchema#string 135 } else { 136 }endif; 137 }endif; 138 } 139 140 /** 141 Recupera o valor do tagged-value ontologies. Retorna na forma de um Set do tipo String 142 FIXME: https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&id=298020 143 **/ 144 query getDomainOntologies(in inter: UML::Interface) : Set(String) { 145 var ontologies = inter.getValue(inter.getAppliedStereotypes()->any(name=’ SemanticWebService’), ’ontologies’)->asSet(); 146 var setString : Set(String) = object Set(String){}; 147 ontologies->forEach(aux) { 148 setString += aux.repr(); 149 }; 150 return setString; 151 } 152 153 query getTaggedValue(in inter: UML::Element, stereotypeName: String, taggedValue: String): String{ 154 return inter.getValue(inter.getAppliedStereotypes()->any(name=stereotypeName), taggedValue).repr(); 155 } 156 157 query createOntologyImports(ontologies:Set(String)) : OWLS::Ontology { 158 var importsSet: OrderedSet(OWLS::Imports); 159 importsSet += object OWLS::Imports{resource := "http://www.w3.org/2003/11/swrlb"}; 160 importsSet += object OWLS::Imports{resource := "http://www.w3.org/2003/11/swrl"}; 161 importsSet += object OWLS::Imports{resource := "http://www.daml.org/services/owl-s /1.1/Profile.owl"}; 162 importsSet += object OWLS::Imports{resource := "http://www.daml.org/services/owl-s /1.1/Grounding.owl"}; 163 importsSet += object OWLS::Imports{resource := "http://www.daml.org/services/owl-s /1.1/Service.owl"}; 164 importsSet += object OWLS::Imports{resource := "http://www.daml.org/services/owl-s /1.1/Process.owl"}; Apêndice D 152 165 importsSet += object OWLS::Imports{resource := "http://www.daml.org/services/owl-s /1.1/generic/Expression.owl"}; 166 ontologies->forEach(ontology){ 167 importsSet += object OWLS::Imports{resource := ontology}; 168 }; 169 170 var ontologyImport: OWLS::Ontology; 171 ontologyImport := object OWLS::Ontology { 172 id := this.serviceName; 173 imports := importsSet; 174 }; 175 return ontologyImport; 176 } 177 178 query createNamespaceDeclarations() : OrderedSet(OWLS::Namespace) { 179 var namespaceDeclaration: OrderedSet(OWLS::Namespace); 180 namespaceDeclaration += object OWLS::Namespace{ 181 name :="rdf"; 182 value :="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; 183 }; 184 namespaceDeclaration += object OWLS::Namespace{ 185 name :="rdfs"; 186 value :="http://www.w3.org/2000/01/rdf-schema#"; 187 }; 188 namespaceDeclaration += object OWLS::Namespace{ 189 name :="owl"; 190 value :="http://www.w3.org/2002/07/owl#"; 191 }; 192 namespaceDeclaration += object OWLS::Namespace{ 193 name :="swrl"; 194 value :="http://www.w3.org/2003/11/swrl#"; 195 }; 196 namespaceDeclaration += object OWLS::Namespace{ 197 name :="daml"; 198 value :="http://www.daml.org/2001/03/daml+oil#"; 199 }; 200 namespaceDeclaration += object OWLS::Namespace{ 201 name :="expression"; 202 value :="http://www.daml.org/services/owl-s/1.1/generic/Expression.owl#"; 203 }; 204 namespaceDeclaration += object OWLS::Namespace{ Apêndice D 153 205 name :="service"; 206 value :="http://www.daml.org/services/owl-s/1.1/Service.owl#"; 207 }; 208 namespaceDeclaration += object OWLS::Namespace{ 209 name :="profile"; 210 value :="http://www.daml.org/services/owl-s/1.1/Profile.owl#"; 211 }; 212 namespaceDeclaration += object OWLS::Namespace{ 213 name :="grounding"; 214 value :="http://www.daml.org/services/owl-s/1.1/Grounding.owl#"; 215 }; 216 namespaceDeclaration += object OWLS::Namespace{ 217 name :="process"; 218 value :="http://www.daml.org/services/owl-s/1.1/Process.owl#"; 219 }; 220 return namespaceDeclaration; 221 } APÊNDICE E Questionários do Experimento Controlado E.1 Questionário do Perfil do Participante Identificação Nome: E-mail: Formação Graduação ( ) Especialização ( ) Mestrado ( ) Doutorado ( ) Área de atuação da última formação: Conhecimento a respeito das tecnologias Assinale a opção que melhor representa o grau de conhecimento com as tecnologias listadas a seguir: 1-nenhum; 2-básico; 3-intermediário; 4-avançado. No Tecnologia 1 2 3 4 1 serviços Web 2 Axis2 3 Web semântica 4 serviços Web semânticos 5 Ontologia 6 linguagem OWL 7 linguagem OWL-S 8 Protege 9 plugin OWL-S Editor do Protege 10 linguagem XSLT 11 UML 12 perfil UML 13 linguagem Java 14 IDE Eclipse Apêndice E 155 E.2 Questionário para Análise Subjetiva da Ferramenta e da Atividade Identificação Nome do participante: Nome da atividade: Ferramenta usada na atividade: AutoWebS( ) Axis2 + OWL-S Editor( ) Tempo de realização da atividade: Em uma escala de 1 a 5 respondas as seguintes perguntas: Sobre a Atividade 1. Quão cansativa foi realizar a atividade? 1-Muito cansativo ( ) 2-Cansativo ( ) 3-Normal ( ) 4-Pouco Cansaço () 5- Sem Cansaço ( ) 2. Em sua opinião, a ferramenta contribuiu positivamente para realização da atividade? 1-Não contribuiu ( ) 2-Contribuiu Pouco ( ) 3-Normal ( ) 4-Contribuiu ( ) 5-Contribuiu muito ( ) 3. Você acredita que a ferramenta contribuiu para a sua confusão? 1-Não contribuiu ( ) 2-Contribuiu Pouco ( ) 3-Normal ( ) 4-Contribuiu ( ) 5-Contribuiu muito ( ) 4. Durante o desenvolvimento da atividade, você se sentiu confuso? 1-Nunca ( ) 2-Poucas Vezes ( ) 3-Normal ( ) 4-Algumas Vezes ( ) 5-Sempre ( ) 5. Quão complexo foi a atividade? 1-Muito Fácil ( ) 2-Fácil ( ) 3-Normal ( ) 4-Difícil ( ) 5-Muito Difícil ( ) 6. Você precisou recorrer a fontes de conhecimentos (livros, artigos, sites, etc) para realização desta atividade? Com qual frequência? 1-Nunca ( ) 2-Poucas Vezes ( ) 3-Normal ( ) 4-Algumas Vezes ( ) 5-Sempre ( ) 7. O objetivo da atividade foi o que você esperava? 1-Sim ( ) 2-Não ( ) 8. Quão difícil foi criar o serviço Web? 1-Muito Fácil ( ) 2-Fácil ( ) 3-Normal ( ) 4-Difícil ( ) 5-Muito Difícil ( ) 9. Quão difícil foi criar a ontologia do serviço Web? 1-Muito Fácil ( ) 2-Fácil ( ) 3-Normal ( ) 4-Difícil ( ) 5-Muito Difícil ( ) 10. Você tem alguma observação a fazer a respeito da atividade? 1-Sim ( ) 2-Não ( ) Quais: Sobre a Ferramenta 11. Os recursos oferecidos pela ferramenta foram suficientes para realização desta atividade? 1-Sim ( ) 2-Não ( ) 12. Os recursos oferecidos pela ferramenta que foram usados por você para a realização desta atividade, comportaram-se como esperado? 1-Sim ( ) 2-Não ( ) Apêndice E 156 13. O quão fácil foi encontrar esses recursos na ferramenta? 1-Muito Fácil ( ) 2-Fácil ( ) 3-Normal ( ) 4-Difícil ( ) 5-Muito Difícil ( ) 14. Você acha que a abordagem implementada pela ferramenta contribuiu para o desenvolvi- mento desta atividade? 1-Sim ( ) 2-Não ( ) 15. Você identificou algum erro ou bug na ferramenta? Se sim, quais? 1-Sim ( ) 2-Não ( ) 16. Você tem alguma observação a fazer sobre a ferramenta usada na realização desta atividade? 17. Você tem alguma observação a fazer sobre a respeito da atividade? E.3 Questionário para o AutoWebS Identificação Nome do participante: Atividade: 1. Você aprova o layout da ferramenta? 1-Sim ( ) 2-Não ( ) 2. Você tem alguma sugestão para melhorar o layout da ferramenta? 3. Quão fácil foi usa a ferramenta? 1-Muito Fácil ( ) 2-Fácil ( ) 3-Normal ( ) 4-Difícil ( ) 5-Muito Difícil ( ) 4. Existem alguma funcionalidade da ferramenta que você propõe alterações? Se a resposta for sim, então especifique. 5. Você propõe a adição de funcionalidades na ferramenta? 6. Apos realizar esta atividade, você consegue imaginar alguma outra atividade que não possa ser realizada a partir do recursos oferecidos pela ferramenta? 7. Na sua opinião, quão fácil é o entendimento de um modelo UML que representa uma ontologia? 1-Muito Fácil ( ) 2-Fácil ( ) 3-Normal ( ) 4-Difícil ( ) 5-Muito Difícil ( ) 8. Você acha que os elementos (Estereótipos e propriedades) definidos no perfil UML são cla- ros do ponto de vista semântico? Se a resposta for "não"ou "Parcialmente"então justifique sua escolha. 1-Sim ( ) 2-Parcialmente ( ) 3-Não ( ) justificativa: 9. Você consegue imaginar alguma ontologia de domínio que não pode ser representada como um diagrama de classes UML e com o perfil UML usado pelo AutoWebS? Se a resposta for não, então descreva a ontologia ou partes da ontologia que não podem ser representadas. descrição: 10. Na sua opinião, quão importante é a integração das funcionalidades usadas para o desen- volvimento de serviços Web semânticos? Apêndice E 157 Muito importante ( ) Nada ( ) 11. Alguma observação/comentário a respeito do AutoWebS? APÊNDICE F Quadrados Latino Segundo Montgomery [Montgomery, 2009], o modelo experimental Quadrado Latino é um modelo que utiliza o princípio de blocagem. Quando a fonte de perturbação de variabilidade é conhecida e controlável, o modelo é chamado blocagem, e é usada para eliminar sistematicamente seu efeito sobre comparações estatísticas entre tratamentos. É usado para eliminar duas fontes de perturbação de variabilidade, isto é, permite sistematicamente fazer blocagem em duas direções. Em geral, um quadrado latino para p fatores (também chamado de p× p), contém p linhas e p colunas. Cada célula contém uma das p letras que correspondem aos tratamentos, e cada letra ocorre somente uma vez em cada linha e coluna. O arranjo quadrado de tratamentos (ou formulações) foi denotado inicialmente por letras latinas, por isto o nome Quadrado Latino. Veja a Figura ??, um exemplo de um quadrado latino de tamanho 4. 4×4 A B C D B C A D C D B A D A C B Figura F.1: Exemplo de quadrado latino de tamanho 4 O modelo estatístico para um Quadrado Latino é: yi jk = µ+αi + τ j +βk + εi jk  i = 1,2, ..., p; j = 1,2, ..., p; k = 1,2, ..., p; (F-1) onde yi jk é a observação da i-ésima linha e da j-ésima coluna para o k-ésimo tratamento, µ é a média total, αi é a i-ésima linha, τ j é o j-ésimo tratamento, βk a k-ésimo coluna, e εi jk é o erro aleatório. Neste modelo, não há interação entre as colunas, linhas e tratamentos, porque só existe uma observação única em cada célula. A análise da variância consiste no particionamento da soma total dos quadrados de N = p2 observações em componentes para linhas, colunas, tratamentos e erros. Por exemplo: SST = SSLinhas +SSColunas +SSTratamentos +SSE , (F-2) Apêndice F 159 com o respectivos graus de liberdade: p2−1 = p−1+ p−1+ p−1+(p−2)(p−1). (F-3) Supondo que εi jk é NID(0,s2), s2 é a variância. Cada soma dos quadrados do lado direito da equação F-2, dividindo por s2, é uma variável aleatória qui-quadrada distribuída independente. Esta técnica pode ser útil em situações onde linhas e colunas representam fatores que se deseja estudar e investigar onde não estão as restrições aleatórias. Desta forma, três fatores (linhas, colunas e letras), com p níveis, podem ser investigados com somente p2 execuções. O modelo assume que não há interação entre os fatores.