AutoWebS: um Ambiente para Modelagem e Geração Automática de ServiçosWeb Semânticos

(1)

Modelo

U

NIVERSIDADE

F

EDERAL DO

R

IO

G

RANDE DO

N

ORTE

DEPARTAMENTO DE

INFORMÁTICA E

MATEMÁTICA

A

PLICADA

- DIMA

P

THIAGO

PEREIRA DA

S

ILVA

AutoWebS

Um Ambiente para Modelagem e Geração Automática de

Serviços Web Semânticos

(2)

(3)

(4)

U

NIVERSIDADE

F

EDERAL DO

R

IO

G

RANDE DO

N

ORTE

D

EPARTAMENTO DE

I

NFORMÁTICA E

M

ATEMÁTICA

APLICADA

- DIMAP

A

UTORIZAÇÃO PARA

P

UBLICAÇÃO DE

D

ISSERTAÇÃO

EM

F

ORMATO

E

LETRÔ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 n}o _{9610/98 de 10/02/1998, a obra abaixo especificada, sem que me seja} devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação da produção acadêmica gerada pela Universidade, a partir desta data.

Título:AutoWebS – Um Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos

Autor(a):Thiago Pereira da Silva

Natal - RN, 06 de Agosto de 2012.

Thiago Pereira da Silva – Autor

(5)

T

HIAGO

P

EREIRA DA

S

ILVA

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

(6)

T

HIAGO

P

EREIRA DA

S

ILVA

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

(7)

Agradecimentos

Agradeço a minha orientadora Thais Batista pela dedicação, ensinamentos e compartilhamento de experiências que me foi dado durante o mestrado.

Agradeço os professores Paulo Pires, Nélio Cacho e Flávia Delicato pelas sugestões valiosas que contribuiram para o desenvolvimento deste trabalho.

Sou grato aos meus pais, meus irmãos e minha avó pelo amor e carinho que sempre me deram.

Aos colegas de trabalho, Lidiane, Fred Lopes, Everton Cavalcante, Taniro Rodri-gues, Ana Luisa, Gustavo, Eduardo e Lucas Silva agradeço os conselhos, ensinamentos e companhia.

(8)

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. Dissertação de Mestrado. Departamento de Informática e Matemática Aplicada -DIMAp, Universidade Federal do Rio Grande do Norte.

Tipicamente serviços Web contêm apenas informações sintáticas que descrevem suas 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

(9)

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

(10)

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

(11)

5 Estudo de Caso 67

5.1 Sistemas demiddlewarede 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

(12)

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

(13)

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

(14)

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

(15)

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

(16)

Lista de Códigos de Programas

2.1 Descrição em RDF/XML das afirmações sobre Eric Miller - extraído de

[Manola and Miller, 2004] 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 classeRegime 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 complexosubscribeBurdenAssyncService 127

B.4 Definição do elementomessage 130

B.5 Definição do elementoportType 130

(17)

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.

(18)

14

ontologias como, por exemplo, ontologias para um domínio específico.

Existem várias linguagens que permitem se descrever semanticamente servi-ços Web utilizando ontologias. Alguns exemplos são OWL-S (Ontology Web 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.

(19)

15

envolvidas na criação de serviços Web semânticos. Os requisitos devem prever a integra-ção das funcionalidades necessárias para criaintegra-çã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 desoftwareque 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.

(20)

1.1 Objetivos 16

possa ser modelada. Dessa forma, abstrai-se dos desenvolvedores a sintaxe e algumas construções da linguagem OWL, tais como especificações de relações entre proprieda-des e definições de indivíduos, que são proprieda-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 inputse 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 omiddlewareAxis2 da Apache [Perera et al., 2006].

1.1 Objetivos

(21)

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 demiddleware 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 plugindo 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

(22)

(23)

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 omiddlewarepara serviços Web da Apache Axis2; a seção 2.2 apresenta a Web Semântica, com enfoque para oframeworkRDF, também são apresenta-dos os conceitos de ontologias e a linguagem OWL, por fim são apresentaapresenta-dos 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 desoftwareem 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 oframework da Apache Axis2, usadas para construção de serviços Web.

2.2 Web Semântica

(24)

Figura 2.1:Arquitetura de um serviço Web - retirado de

[Wikipedia, 2011]

Internet de forma a tornar possível o seu entendimento, tanto pelo humano quanto pelo computador. A Web Semântica estende a Web tradicional, baseada em redes dehiperlinks, 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 aﬁrma-ções a respeito dos recursos disponíveis na Web. A terceira principal tecnologia são as

ontologias, utilizadas para explicitamente representar e deﬁnir 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

(25)

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 desoftware 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 dobrokerpode 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. Opredicadorepresenta aspectos, características ou propriedade do recurso e expressa uma relação entre o sujeitoe oobjeto.

(26)

“there is a Person identifi ed byhttp://www.w3.org/People/EM/contact#me, whose name is Eric Miller, whose email address [email protected], andwhose title isDr.”

Esta aﬁrmaçã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 osujeitoRDF

é o recurso

"http://www.w3.org/People/EM/contact#me", ou seja, um URI. O sujeito RDF

pos-sui um tipoPersonque está deﬁnido no URI

htt p://www.w3.org/2000/10/swap/pim/contact#Person. Esta aﬁrmação relaciona

al-guns objetos:

Eric Miller que possui o predicado "whose name is"; [email protected] com o predicado "whose email address is"; Dr. com o predicado "whose title is".

Ospredicadosda aﬁrmação estão associados às seguintes URIs:

whose name is http://www.w3.org/2000/10/swap/pim/contact#fullName

(27)

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, [email protected]

Para armazenar e compartilhar as afirmações descritas em RDF, é usado uma linguagem baseada em XML chamada de RDF/XML. O trecho de Código 2.1 demonstra em RDF/XML o grafo correspondente a Figura 2.3.

Código 2.1 Descrição em RDF/XML das afirmações sobre Eric Miller - extraído de [Manola and Miller, 2004]

1 <?xml version="1.0"?>

2 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

3 xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">

4

5 <contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">

6 <contact:fullName>Eric Miller</contact:fullName>

7 <contact:mailbox rdf:resource="mailto:[email protected]"/>

8 <contact:personalTitle>Dr.</contact:personalTitle>

9 </contact:Person>

10

11 </rdf:RDF>

O objetivo da RDF é definir um mecanismo para descrição de recursos que não faça nenhuma suposição ou premissa sobre o domínio de uma aplicação. Desta forma, modelos RDF podem ser reutilizados para vários domínios. O Schema RDF define um modelo orientado a objeto para os tipos de dados em RDF através da definição dos conceitos de classes, relações entre classes e propriedades.

(28)

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, umatagdonamespacedo 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çãordfs: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 tipoPersonpode ter somente ummailbox.

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].

(29)

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 pelaUS 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

(30)

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<owl:Ontology>e especifica algumas informações a respeito do autor e a versão do documento. O trecho de Código 2.2 demonstra a sintaxe de um cabeçalho OWL.

Código 2.2Declaração do cabeçalho de um documento OWL 1 <?xml version="1.0"?>

2 <rdf:RDF

3 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

4 xmlns="http://www.example.org/owls/OilMonitor.owl#"

5 xmlns:owl="http://www.w3.org/2002/07/owl#"

6 xmlns:dc="http://purl.org/dc/elements/1.1/"

7 xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

8 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

9 xml:base="http://www.example.org/owls/OilMonitor.owl">

10

11 <owl:Ontology rdf:about="">

12 <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

13 Comentario</rdfs:comment>

14 <dc:creator rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

15 Autor</dc:creator>

16 </owl:Ontology>

17 ...

(31)

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

(32)

Código 2.3Declaração de uma classe e suas propriedades em OWL 1 ...

2 ...

3 <owl:Class rdf:ID="Regime"/>

4

5 <owl:ObjectProperty rdf:ID="hasRegime">

6 <rdfs:domain rdf:resource="#Change"/>

7 <rdfs:range rdf:resource="#Regime"/>

8 </owl:ObjectProperty>

9

10 <owl:DatatypeProperty rdf:ID="stemSize">

11 <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>

12 <rdfs:domain rdf:resource="#Regime"/>

13 </owl:DatatypeProperty>

14 <owl:DatatypeProperty rdf:ID="burdenValue">

18 <owl:DatatypeProperty rdf:ID="cpmValue">

22 <owl:DatatypeProperty rdf:ID="idRegime">

26 ...

27 ...

(33)

2.3 OWL-S 29

Código 2.4Instância da classeRegime 1 ...

2 <Regime rdf:ID="Regime_5">

3 <stemSize rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

4 25</stemSize>

5 <burdenValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

6 59</burdenValue>

7 <idRegime rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

8 5</idRegime>

9 <cpmValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

10 50</cpmValue>

11 </Regime>

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, osinputseoutputsde 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 umframeworkque 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 porServiceprofile, ServiceModeleServiceGrounding.

2.3 OWL-S

(34)

2.3 OWL-S 30

especiﬁcadas, por intermédio de uma descrição formal das suas propriedades e

capacida-des [Burstein et al., 2004]. O últimorelease da especiﬁcaçã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 ontologiaServiceGrounding deﬁne os mapeamentos entre as construções da

ontolo-gia ServiceModel com as especiﬁcaçõ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 Figura2.6ilustra a relação entre as subontologias e as propriedadespresents,describedBy, esupportsdeService.

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çãoServiceGrounding.

2_{Processo de busca dos possíveis casamentos entre demandas/requisições e ofertas/serviços, em um}

(35)

2.3 OWL-S 31

2.3.1 Service Profile

Na subontolgiaServiceProfilea classeServiceProfileé 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 deProfile, é 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].

• Adescriçã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 Profilefornece 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.

(36)

2.3 OWL-S 32

as condições são representadas a partir de dois aspectos do serviço:

• a transformação da informação (representado porinputseoutputs);

• e a mudança de estado produzido pela execução do serviço (representado por preconditionseeffects).

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 dosInputs/Outputs/Preconditions/Effects (IOPEs) é fornecido pela classeProfile. No entanto, este esquema existe na subontologia ProcessModel. Os IOPEs publicados pela classe Profile são um subconjunto daqueles publicados pela subontologiaProcessModel, assim, espera-se que a subontologia Proces-sModelcrie todas as instâncias IOPEs e a instância deProfilesimplesmente aponte para essas instâncias de IOPEs.

A Figura 2.7, ilustra as propriedades da classeProfileque são usadas para refe-renciar os IOPEs definidos na subontologiaServiceProfile. 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 Parametermodela a intuição de queinputseoutputs - que são os tipos de parâmetros - estão ambos envolvidos na transformação da informação e, portanto, são diferentes daspreconditionseeffects. Como consequência, a classe Parameternão é instanciada.

hasInput varia sobre instâncias da classe Inputs, definida na subontologia ServiceModel.

hasOutput define instâncias da classeOutput, da subontologiaServiceModel.

hasPrecondition especifica uma das pré-condições do serviço e varia ao longo de ins-tâncias da classePreconditions, definida de acordo com o esquema na subontologia ServiceModel.

(37)

2.3 OWL-S 33

Figura 2.7:OWL-S Service Proﬁle - extraído de

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 um mecanismo para indicar os indivíduos responsáveis pelo serviço.

Uma instância da classe Profi lepode 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 classeActor, defi nida na ontologiaActorDefault.

2.3.2 Service Model

A subontologia ServiceProfile descreve apenas o funcionamento global do

(38)

2.3 OWL-S 34

o serviço Web. Em OWL-S, processos não são necessariamente programas a serem

executados, mas sim uma especiﬁcaçã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 classeParameter. Apesar da Figura 2.8 não ilustrar a relação entre Input, Output e Parameter, cada Parameter tem um tipo, especiﬁcado 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 propro-cesso 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 codiﬁcaçã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

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:theClientetheServer. Se existem outros, então eles são listados

(39)

2.3 OWL-S 35

hasInput especifica as instâncias da classeInput. UmInputespecifica 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-conditionse 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. Resultassociaeffectseoutputsdiretamente 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. UmAtomic Processrecebe uminput, faz algum processamento, e depois retornar ooutput. Para cadaAtomic Processdeve existir umgrounding(apresentado na seção 2.3.3) que permita a um solicitante do serviço codificar as mensagens para o processo a partir de seusinputse decodificar osoutputs.

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. UmComposite Processé composto por outros proces-sos, AtomicouComposite, que são especificados a partir de estruturas de controle -Sequence, Split, Split + Join, Choice, Any-Order, If-Then-Else, Iterate e Repeat-While.

(40)

2.3 OWL-S 36

2.3.3 Service Grounding

As subontologiasServiceProfileeServiceModeldescrevem 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 subontologiasServiceProfile e ServiceModelsão represen-tações abstratas, somenteServiceGroundinglida 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.

(41)

2.3 OWL-S 37

Conforme a Figura 2.9 ilustra, o grounding OWL-S/WSDL é baseado em três

correspondências entre OWL-S e WSDL:

Figura 2.9:Grounding OWL-S/WSDL - extraído de

1. Um processo do tipo Atomic Process pode corresponder aos seguintes tipos de

operações (operation) descritas no arquivo WSDL:

• Um processo do tipoAtomic Processcominputseoutputscorresponde a uma operação do tiporequest-response.

• Um processo do tipo Atomic Process com inputs, mas sem outputs corres-ponde a uma operação do tipoone-way.

• Um processo do tipo Atomic Process com outputs, mas sem inputs corres-ponde a uma operação do tiponotifi 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 tiposolicit-response

2. Os inputs e outputs de um processo do tipo Atomic Process correspondem as

mensagens especiﬁcadas 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 deabstract types.

A Figura 2.10 apresenta as principais classes e propriedades da subontologia

(42)

2.3 OWL-S 38

Figura 2.10:Classes e propriedades da subontologia OWL-S

Ser-viceGrounding

A classeWsdlGroundingé uma subclasse deServiceGrounding. Seu papel é

for-nece um mecanismo para que as principais construções do arquivo WSDL possam ser re-ferenciadas em OWL-S. Cada instância da classeWsdlGroundingcontém uma lista de ins-tâncias de WsdlAtomicProcessGrounding. Essa relação é representada pela propriedade hasAtomicProcessGrounding. A propriedadeowlsProcessgarante que para cada processo do tipoAtomicProcessexista somente umWsdlAtomicProcessGrounding. Por outro lado a propriedadewsdlOperation assegura uma relação um-para-um entre o Atomic Process

e a especiﬁcação WSDL. WsdlMessageMapé uma superclasse para WsdlInputMessage-Map eWsdlOutputMessageMap. WsdlAtomicProcessGroundingutiliza, basicamente, as seguintes propriedades para referenciar elementos deAtomic Processcom a especifi cação

WSDL:

wsdlVersion um URI que indica a versão do WSDL utilizado. A versão 1.1 da OWL-S é

compatível com a versão 1.1 da WSDL enquanto que OWL-S, a versão mais atual, é compatível com WSDL 1.2. Esta propriedade não aparece na Figura2.10, pois ela

não relaciona a nenhuma outra classe, ela relaciona com um tipo URI especiﬁcado

no XML Schema.

wsdlDocument um URI que indica o documento WSDL ao qual o groundingse refere. Esta propriedade não é essencial e seu uso é basicamente para documentação. É um

tipo URI especiﬁcado no Schema XML.

(43)

identi-2.3 OWL-S 39

ficar umPort3específico, definido no WSDL. Se houver váriosPortspara a mesma operação (operation), oengineOWL-S pode escolher qualquer umPort. Para res-tringir osPortsque podem ser utilizadas para umWsdlAtomicProcessGroundingé necessário especificá-los utilizando as propriedadeswsdlServicee/ouwsdlPort. 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 elementoServicedo WSDL é uma coleção deEndPoints.

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 umbindinge um endereço.

wsdlInputMessage um URI para o elementoinput messageda especificação WSDL que corresponde aosinputsdoAtomic 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-priedadewsdlMessagePartque, com um URI identifica aMessage Partdo WSDL associado e, também a propriedadeowlsParameter ouxsltTransformation. Ambas representam como derivar aMessage Partde um ou maisinputsdoAtomic Process.

owlsParameter é utilizado para o caso mais simples, quando existe uma corres-pondência direta entre oinputdo Atomic Process e owsdlMessagePart. Isto significa que oMessage PartWSDL corresponde diretamente aoinpute o tipo doinputé usado na especificação do WSDL. Basta colocar o URI doinputna propriedade.

xsltTransformation é utilizado para os outros casos em que a propriedade owlsParameternão se aplica. A propriedadexsltTransformationadiciona um script XSLT que gera oMessage Partde uma instância de umAtomic Process. O script pode ser diretamente representado como umastringou pode ser refe-renciado por um URI.

wsdlOutputMessage similar à propriedade wsdlInputMessage porém, aplicada aos outputs.

wsdlOutput Para cada output doAtomic Process deve existir um valor da propriedade wsdlOutput. É similar à propriedadewsdlInput porém, aplicados a outputs. Ela

(44)

especifica um mapeamento entre umoutputdeAtomic Process, que é representado pela instância deWsdlOutputMessageMap.

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 abordagemtop-downde desenvol-vimento desoftwareque tem como essência a especificação de modelos e transformações desses modelos em outros modelos ou artefatos desoftware, 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.

(45)

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 metamodeloMMaenquanto que o metamodelo do modeloMbé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 chamadaAtoBque recebe como entrada um elementoAe cria um elementoB. 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 deA. Assim, na linha 4, a instruçãoa.map AtoB()especifica que o elemento A, referenciado pela variável a, será entrada para a função de mapeamento AtoB.

Código 2.5Exemplo 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 }

(46)

(47)

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 umsoftware. 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

(48)

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 umpackageem 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 ontologiasDomaineRange,Comment,Cardinality,Data TypeeInstancessão diretamente mapeadas para os elementos da UML.