lo
U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE
D EPARTAMENTO DE I NFORMÁTICA E M ATEMÁTICA
A PLICADA - DIMA P
Mo
de
T HIAGO P EREIRA DA S ILVA
AutoWebS
Um Ambiente para Modelagem e Geração Automática de
Serviços Web Semânticos
Natal - RN
2012
U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE
D EPARTAMENTO DE I NFORMÁTICA E M ATEMÁTICA
A PLICADA - DIMA P
AUTORIZAÇÃ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 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
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 Universidade Federal do Rio Grande do Norte, como requisito parcial para obtenção do título de Mestre em Sistemas e Computação.
Área de concentração: Engenharia de Software.
Orientadora: Profa. Thaís Vasconcelos Batista
Natal - RN
2012
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 Departamento de Informática e Matemática Aplicada - DIMAp da Universidade
Federal do Rio Grande do Norte como requisito parcial para obtenção
do título de Mestre em Sistemas e Computação, aprovada em 06 de
Agosto de 2012, pela Banca Examinadora constituída pelos professores:
Profa. Thaís Vasconcelos Batista
Departamento de Informática e Matemática Aplicada - DIMAp – UFRN
Presidente da Banca
Prof. Nélio Alessandro Azevedo Cacho
Universidade Federal do Rio Grande do Norte - DIMAp – UFRN
Profa. Flavia Coimbra Delicato
Universidade Federal do Rio de Janeiro - DCC/IM – UFRJ
Prof. Paulo F. Pires
Universidade Federal do Rio de Janeiro - DCC/IM – UFRJ
Agradecimentos
Agradeço a minha orientadora Thais Batista pela dedicação, ensinamentos e
compartilhamento de experiências que me foi dado durante o mestrado.
Agradeço os professores Paulo Pires, Nélio Cacho e Flávia Delicato pelas
sugestões valiosas que contribuiram para o desenvolvimento deste trabalho.
Sou grato aos meus pais, meus irmãos e minha avó pelo amor e carinho que
sempre me deram.
Aos colegas de trabalho, Lidiane, Fred Lopes, Everton Cavalcante, Taniro Rodrigues, Ana Luisa, Gustavo, Eduardo e Lucas Silva agradeço os conselhos, ensinamentos e
companhia.
A CAPES pelo apoio financeiro despendido a este trabalho.
Resumo
da Silva, Thiago Pereira. AutoWebS: Um Ambiente para Modelagem e Geraçã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 interfaces e a falta de descrições semânticas torna a composição de serviços Web uma tarefa
difícil. Para resolver este problema, pode-se usar ontologias para a definição semântica da
interface dos serviços, facilitando a automação da descoberta, publicação, mediação, invocação e composição dos serviços. No entanto, linguagens que permitem se descrever
semanticamente serviços Web utilizando ontologias, como OWL-S, têm construções que
não são fáceis de entender, mesmo para desenvolvedores Web, e as ferramentas existentes
levam aos usuários muitos detalhes que as tornam difíceis de serem manipuladas. Este trabalho apresenta uma ferramenta chamada AutoWebS (Automatic Generation of Semantic
Web Services) para o desenvolvimento de serviços Web semânticos. O AutoWebS usa
uma abordagem baseada em perfis UML e transformações entre modelos para a geração
automática de serviços Web e sua descrição semântica em OWL-S. O AutoWebS disponibiliza um ambiente que oferece recursos para modelar, implementar, compilar e implantar
serviços Web semânticos.
Palavras–chave
MDD, OWL-S, serviço Web semântico, perfil UML, Web semântica
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 interfaces. Due to the lack of semantic descriptions of the Web services, service composition
becomes a difficult task. To solve this problem, Web services can exploit the use of ontologies for the semantic definition of service’s interface, thus facilitating the automation
of discovering, publication, mediation, invocation, and composition of services. However,
ontology languages, such as OWL-S, have constructs that are not easy to understand, even
for Web developers, and the existing tools that support their use contains many details
that make them difficult to manipulate. This paper presents a MDD tool called AutoWebS
(Automatic Generation of Semantic Web Services) to develop OWL-S semantic Web services. AutoWebS uses an approach based on UML profiles and model transformations for
automatic generation of Web services and their semantic description. AutoWebS offers
an environment that provides many features required to model, implement, compile, and
deploy semantic Web services.
Keywords
MDD, OWL-S, semantic Web services, UML profile, semantic Web
Sumário
Lista de Figuras
9
Lista de Tabelas
11
Lista de Códigos de Programas
12
1
13
16
17
Introdução
1.1
1.2
2
Fundamentação Teórica
2.1
2.2
2.3
2.4
3
Serviço Web
Web Semântica
2.2.1
RDF e RDF Schema
2.2.2
Ontologia
2.2.3
OWL
2.2.4
Serviços Web Semânticos
OWL-S
2.3.1
Service Profile
2.3.2
Service Model
2.3.3
Service Grounding
Desenvolvimento de Software Dirigido por Modelos
Mapeamento entre OWL e UML
3.1
3.2
4
Objetivos
Estrutura do Documento
Mapeamento entre as linguagens de especificação de ontologias e a UML
Mapeamento entre OWL e UML
Ambiente para Modelagem e Geração Automática de Serviços Web Semânticos
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Requisitos de uma ferramenta para criação de serviços Web semânticos
Visão Geral da Ferramenta
Arquitetura
Perfil UML
Importação das Ontologias OWL
Metamodelo da Linguagem OWL-S
Implementação das Regras de Mapeamento entre UML e OWL-S
Funcionamento da Ferramenta
19
19
19
21
24
25
29
29
31
33
36
40
43
43
46
50
50
52
54
56
58
60
63
65
5
Estudo de Caso
5.1
5.2
5.3
5.4
6
Sistemas de middleware de provisão de contexto
Ontologia de Domínio
Modelagem do Serviço Web Semântico
Resultados
Experimento Controlado
6.1
6.2
6.3
Ferramentas Avaliadas
Projetos de Serviços Web Semânticos
6.2.1
Serviço Web semântico OilMonitor 1
6.2.2
Serviço Web semântico OilMonitor 2
6.2.3
Serviço Web semântico Book Finder
6.2.4
Serviço Web semântico Zip Code Finder
6.2.5
Serviço Web semântico Latitude Longitude Finder
6.2.6
Serviço Web semântico Barnes and Nobles Price Finder
6.2.7
Serviço Web semântico BabelFish Translator
6.2.8
Serviço Web semântico Currency Converter
Planejamento do Experimento
6.3.1
6.3.2
Objetivos
Questões a serem respondidas e métricas correspondentes
Sobre a ferramenta
67
67
69
71
74
76
77
77
77
78
78
78
78
79
79
79
80
80
80
80
Sobre o grau de dificuldade, tempo e esforço despendido na criação das
diferentes ontologias dos serviços Web
Sobre o uso da ferramenta
6.3.3
Hipóteses
Alternativas
Nulas
6.3.4
Variáveis
Variáveis Independentes
Variáveis Dependentes
Variáveis Controladas
6.4
6.5
6.3.5
Seleção dos Participantes e Treinamento
6.3.6
Local do Experimento e Recursos
6.3.7
Validade
Operação do Experimento
6.4.1
Plano Experimental
6.4.2
Questionário do Perfil do Participante
6.4.3
Questionário para Análise Subjetiva da Ferramenta e do Projeto do Serviço Web
Análise e Interpretação dos Resultados
6.5.1
Apresentação dos Resultados
6.5.2
Teste Estatístico
6.5.3
Análise Qualitativa
6.5.4
Verificação da Hipóteses
81
81
82
82
82
82
82
83
83
83
84
84
84
84
85
86
86
86
88
90
92
7
Trabalhos Relacionados
7.1
7.2
7.3
7.4
7.5
7.6
OWL-S Editor
CODE - CMU’s OWL-S Development Environment
ASSAM - Automated Semantic Service Annotation with Machine Learning
Yang e Chung
Kim e Lee
Comparação entre as ferramentas
95
95
97
98
99
100
101
Contribuições
Limitações
Trabalhos Futuros
105
107
108
108
Referências Bibliográficas
110
A
XSL Transformation
118
Tecnologias dos serviços Web
123
123
127
131
132
8
Conclusão
8.1
8.2
8.3
B
B.1
B.2
B.3
B.4
SOAP
WSDL
UDDI
Apache Axis2
C Tranformação XSLT
133
D Tranformação QVT
147
E
154
154
155
156
Questionários do Experimento Controlado
E.1
E.2
E.3
F
Questionário do Perfil do Participante
Questionário para Análise Subjetiva da Ferramenta e da Atividade
Questionário para o AutoWebS
Quadrados Latino
158
Lista de Figuras
Arquitetura de um serviço Web - retirado de [Wikipedia, 2011]
Principais tecnologias da Web semântica
Exemplo de um grafo em RDF - ilustração retirada de
[Manola and Miller, 2004]
2.4 Dialetos da OWL
2.5 Relação entre classes OWL
2.6 Subontologias da OWL-S - extraído de [Burstein et al., 2004]
2.7 OWL-S Service Profile - extraído de [Burstein et al., 2004]
2.8 Subontologia OWL-S ServiceModel - extraído de [Burstein et al., 2004]
2.9 Grounding OWL-S/WSDL - extraído de [Burstein et al., 2004]
2.10 Classes e propriedades da subontologia OWL-S ServiceGrounding
2.11 Transformações entre modelos
20
20
3.1
Exemplo de mapeamento entre OWL eUML
49
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Visão geral da ferramenta AutoWebS
Arquitetura da ferramenta AutoWebS
Perfil UML usado pela ferramenta AutoWebS
Ontologia BibTex representada como UML
Mapeamento da classe OWL em UML
Metamodelo OWL-S
Transformação de UML para OWL-S
Funcionamento do AutoWebS
53
55
57
59
60
61
64
65
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Arquitetura do OpenCOPI - extraído de [Lopes et al., 2009b]
Ontologia de domínio OilExploration
Trecho da ontologia de domínio OilExploration
Atividades realizadas para o estudo e caso
Trecho da ontologia de domínio OilExploration
Artefatos de códigos gerados
Implementação da regra de negócio do serviço Web
69
70
71
71
72
73
74
6.1
6.2
Tempo de desenvolvimento dos serviços Web semânticos
Valores Críticos W para o teste de Wilcoxon para amostras pequenas extraído de [Lowry, 2012]
Grau de cansaço no desenvolvimento dos serviços Web semânticos
Grau de contribuição da ferramenta para o desenvolvimento dos serviços
Web semânticos
Grau de dificuldade em criar o serviço Web
88
2.1
2.2
2.3
6.3
6.4
6.5
22
25
27
30
33
34
37
38
40
89
90
91
91
6.6
6.7
6.8
Grau de dificuldade em criar a ontologia do serviço Web
Recursos oferecidos pelas ferramentas avaliadas
Contribuição para o desenvolvimento do serviço Web semântico
92
92
93
7.1
7.2
7.3
7.4
Ferramenta OWL-S Editor
Arquitetura da ferramenta CODE - extraído de [Srinivasan et al., 2005]
Ferramenta ASSAM - extraído de [Heß et al., 2004]
Abordagem de Yang e Chung para construção de serviços Web semânticos - extraído de [Yang and Chung, 2006b]
Abordagem de Kim e Lee para construção de serviços Web semânticos extraído de [Kim and Lee, 2007]
96
97
99
7.5
100
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
21
2.1
Mudanças das características da Web semântica
3.1
3.6
3.7
Mapeamento entre UML e os principais conceitos das linguagens para
especificação de ontologias
Mapeamento entre o elemento owl:Ontology e a UML
Mapeamento entre as construções de classes OWL e a UML
Mapeamento entre o elemento owl:Restriction e a UML
Mapeamento entre os elementos owl:ObjectProperty e owl:DatatypeProperty
e a UML
Mapeamento entre alguns elementos da OWL e a UML
Mapeamento dos tipos de dados do Schema XML e a UML
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Distribuição dos Blocos
Réplica l
Réplica 2
Réplica 3
Réplica 4
Resultados obtidos na execução do experimento controlado
Cálculo do teste estatístico de Wilcoxon
7.1
Comparação entre os trabalhos relacionados
3.2
3.3
3.4
3.5
44
46
47
47
48
48
49
85
85
85
86
86
87
89
101
Lista de Códigos de Programas
2.1
2.2
2.3
2.4
2.5
A.1
A.2
A.3
B.1
B.2
B.3
B.4
B.5
B.6
Descrição em RDF/XML das afirmações sobre Eric Miller - extraído de
[Manola and Miller, 2004]
Declaração do cabeçalho de um documento OWL
Declaração de uma classe e suas propriedades em OWL
Instância da classe Regime
Exemplo de uma transformação QVT
Mensagem SOAP
XSLT para a mensagem SOAP
Documento
Exemplo de Mensagem SOAP de Resposta
Exemplo de Mensagem SOAP de Requisição
Definição do tipo complexo subscribeBurdenAssyncService
Definição do elemento message
Definição do elemento portType
Definição do elemento binding
23
26
28
29
41
120
121
122
125
126
127
130
130
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 conceitos definidos em uma ontologia. Os serviços Web semânticos são um prolongamento
da Web semântica [Berners-Lee et al., 2001] para os serviços Web de forma a facilitar a
automatização da descoberta, publicação, mediação, invocação e composição de serviços.
O desenvolvimento de um serviço Web semântico ocorre, basicamente, em duas etapas:
(i) o desenvolvimento do serviço Web e (ii) a criação da ontologia ou descrição semântica
do serviço Web. A ontologia do serviço Web pode utilizar conceitos definidos em outras
14
ontologias como, por exemplo, ontologias para um domínio específico.
Existem várias linguagens que permitem se descrever semanticamente serviços Web utilizando ontologias. Alguns exemplos são OWL-S (Ontology Web Language for Services) [Burstein et al., 2004], WSMO (Web Service Modelling Ontology)
[de Bruijn et al., 2005], WSDL-S (Web Service Semantics) [Akkiraju et al., ] e SAWSDL
(Semantic Annotations for WSDL and XML Schema) [Kopecký et al., 2007]. Essas linguagens apresentam sintaxes distintas, um vocabulário muito extenso e a grande maioria
são baseadas em lógica descritiva ou de primeira ordem. As ferramentas existentes que
apóiam sua utilização levam ao usuário muitos detalhes que as tornam difíceis de serem
manipuladas.
A adoção de descrições semânticas dos serviços Web esbarra nas limitações das
ferramentas e no fato de que criar ontologia demanda tempo e é difícil de ser realizada,
conforme Missikoff [Missikoff et al., 2002] ressalta em seu trabalho. As ferramentas
atuais para a criação da descrição semântica de serviços Web foram projetadas para serem
utilizadas por especialistas da Web semântica, pois seus usos requerem o conhecimento
de muitos conceitos desta área. Brambilla et al. [Brambilla et al., 2007] argumentam que
o maior obstáculo para a ampla adoção dos serviços Web semânticos é a dificuldade
em descrever aplicações Web com tecnologias semânticas. Portanto, para se explorar os
serviços Web semânticos é preciso haver ferramentas que abstraiam detalhes específicos,
relativos a cada linguagem de descrição semântica, que normalmente demandam muito
tempo para a total compreensão e, não deveria demandar tanto tempo quanto a de
implementação da regra de negócio do serviço Web.
Em virtude dos benefícios que os serviços Web semânticos oferecem, as abordagens empregadas pelas ferramentas atuais devem ser repensadas em direção a novas
abordagens que ofereçam um maior nível de abstração sobre a sintaxe das linguagens.
Neste sentido, [Chafle et al., 2007] e [Fonseca et al., 2009] propuseram alguns requisitos
essenciais para o desenvolvimento de uma ferramenta para compor serviços Web. Alguns
destes requisitos podem ser adaptados para uma ferramenta de alto nível de abstração para
a criação de serviços Web semânticos. Estes requisitos adaptados, juntamente com novos
requisitos podem formar um conjunto mínimo de requisitos para uma ferramenta para
criação de serviços Web semânticos acessível a um público maior do que aquele formado
por especialistas da Web semântica.
Os requisitos mínimos de uma ferramenta para criação de serviços Web semânticos devem definir abordagens para abstrair as tecnologias subjacentes usadas no desenvolvimento de serviços Web semânticos, isto é, as tecnologias usadas na especificação
das interfaces dos serviços Web e nas suas ontologias. Também, por se tratar de uma ferramenta de alto nível de abstração, faz-se necessário a especificação de requisitos sobre
a automatização da geração de artefatos de código, pois se deseja abstrair as linguagens
15
envolvidas na criação de serviços Web semânticos. Os requisitos devem prever a integração das funcionalidades necessárias para criação de serviços Web semânticos, sem que
haja a necessidade do usuário usar recursos externos à ferramenta, de forma a diminuir o
tempo de desenvolvimento dos serviços Web semânticos, evitar erros e possíveis conflitos
gerados quando se usa diferentes ferramentas/aplicativos como, por exemplo, conflitos de
versões das linguagens de especificação da interface do serviço Web ou da ontologia do
serviço Web.
Para atender os requisitos mínimos de uma ferramenta para criação de serviços
Web semânticos, o Desenvolvimento de Software Dirigido por Modelos (Model Driven
Development - MDD) [Stahl and Völter, 2006] pode ser utilizado para gerenciar a complexidade inerente do emprego de ontologias para especificação de serviços Web semânticos, pois MDD é uma abordagem de desenvolvimento de software que está centrada na
criação de modelos, em vez de código de programa, permitindo separação de interesses
entre especificação e implementação. Usando-se uma abordagem MDD é possível prover
abstração das tecnologias subjacentes aos serviços Web semânticos através de modelos.
No contexto do MDD a linguagem de modelagem UML (Unified Modeling Language) é amplamente usada para modelagem de sistemas de software e também para
criação de modelos em abordagens MDD. A linguagem UML e as linguagens de especificação de ontologias têm algumas sobreposições e semelhanças, especialmente para
representação estrutural de um software. Alguns elementos das duas linguagens são semelhantes como, por exemplo, classes, associações entre classes, propriedades de classes, generalizações e tipos de dados. Estas semelhanças tornam possível o mapeamento
de alguns elementos das linguagens de especificação de ontologias em elementos de um
modelo UML [Atkinson et al., 2006, Pondrelli, 2005]. Outros elementos das linguagens
de especificação de ontologias que não correspondem diretamente aos elementos primários da linguagem UML podem ser representados com o uso de perfis UML. Um perfil
UML consiste em uma coleção de extensões que personalizam a UML para um domínio
específico. O uso de perfis UML é altamente alinhado à proposta da MDD, pois os perfis
UML definem uma versão especializada da UML para um determinado domínio. Logo,
os modelos criados a partir de perfis UML são modelos UML válidos e podem utilizar as
mesmas ferramentas para modelagem em UML.
Este trabalho apresenta o AutoWebS (Automatic Generation of Semantic Web
Services), uma ferramenta baseada no desenvolvimento dirigido por modelos (MDD Model Driven Development [Stahl and Völter, 2006]) para criação de serviços Web semânticos. O AutoWebS oferece um ambiente gráfico onde é possível importar ontologias
especificadas na linguagem OWL (Web Ontology Language) [Dean and Schreiber, 2004]
e representá-las graficamente utilizando elementos definidos em um perfil UML (Unified
Modeling Language). Estes elementos servem para que a interface de um serviço Web
1.1 Objetivos
16
possa ser modelada. Dessa forma, abstrai-se dos desenvolvedores a sintaxe e algumas
construções da linguagem OWL, tais como especificações de relações entre propriedades e definições de indivíduos, que são desnecessárias para a criação de serviços Web
semânticos.
O AutoWebS integra, em um único ambiente, várias funcionalidades que um
desenvolvedor precisa para modelar, implementar, compilar e fazer o deploy de um
serviço Web semântico. No ambiente oferecido pelo AutoWebS é possível: (i) modelar
a interface do serviço Web, isto é, modelar os inputs e outputs de cada operação do
serviço Web, (ii) realizar as anotações semânticas, ou seja, associar os inputs e outputs
das operações com os elementos de uma ontologia, (iii) criar automaticamente o arquivo
OWL-S que contém a descrição semântica do serviço Web, (iv) gerar automaticamente
o código fonte do serviço Web modelado, (v) estender a funcionalidade da ferramenta
como, por exemplo, incluir suporte a outra linguagem de descrição semântica, com a
inserção de novos plugins. Para a implementação da ferramenta é utilizado o ambiente
Eclipse, juntamente com o EMF (Eclipse Modeling Framework) [Steinberg et al., 2008]
para especificação em Ecore do metamodelo da linguagem OWL- S. O perfil UML define
alguns estereótipos e propriedades para os elementos do diagrama de classes da UML 2.0.
A transformação entre os modelos é realizada através de regras definidas na linguagem
QVT (Query/View/Transformation) [Object Management Group, 2008]. Enquanto que,
para importação da ontologia de domínio, são usadas regras definidas na linguagem XSLT
(XSL Transformations) [w3c, 1999]. Para a transformação de modelo para texto é usado
o Acceleo [Obeo Network, 2007], para geração do código fonte do serviço Web usamos
o middleware Axis2 da Apache [Perera et al., 2006].
1.1
Objetivos
O objetivo principal desse trabalho é a especificação e o desenvolvimento de
uma ferramenta para criação de serviços Web semânticos. Esta ferramenta, chamada
de AutoWebS, deve implementar uma abordagem MDD, com o uso de um conjunto
de estereótipos definidos em perfil UML, um metamodelo para linguagem OWL-S e
transformações automatizadas entre modelos. O AutoWebS deve oferecer um ambiente
gráfico que recebe como entrada uma ontologia de domínio, especificada na linguagem
OWL, e fazer sua transformação para elementos predefinidos em um perfil UML. Neste
ambiente gráfico deve ser possível modelar a interface do serviço Web utilizando os
elementos da ontologia de domínio importada. Desta forma, após a modelagem do serviço
Web, deve ser aplicado um conjunto de regras de transformações para criação automática
da descrição semântica do serviço Web na linguagem OWL-S e, também, para geração
do código fonte do serviço Web.
1.2 Estrutura do Documento
17
Para alcançar o objetivo principal deste trabalho são necessários os seguintes
objetivos específicos:
• Especificar um perfil UML que torne possível a modelagem e representação da interface de serviços Web, bem como a representação de elementos de uma ontologia
OWL que são necessários para criação de um serviço Web semântico;
• Elaborar regras de transformações XSLT para transformar os elementos de uma
ontologia OWL que são necessários para criação de serviços Web semânticos, em
elementos da UML;
• Elaborar um metamodelo em Ecore para a linguagem OWL-S;
• Implementar transformação Modelo para Modelo (M2M) na linguagem QVT para
transformar um modelo UML em um modelo correspondente ao metamodelo
OWL-S;
• Implementar transformação Modelo para Texto (M2T) para que, a partir de um
modelo OWL-S, criar-se um arquivo OWL-S;
• Ilustrar o uso do AutoWebS através de um estudo de caso que consiste na criação
de serviços Web semânticos para os serviços providos por sistemas de middleware
de provisão de contexto que não utilizam a tecnologia de serviços Web;
• Avaliar a ferramenta através de um experimento controlado que confronta o uso
do AutoWebS em relação a uma suíte de aplicativos composta pelo OWL-S Editor
[Elenius et al., 2005] um plugin do software Protégé [Noy et al., 2000] que é amplamente utilizado para criação de ontologias OWL-S, e o plugin Axis2 da IDE
Eclipse, usado para criar serviços Web.
• Validar as descrições semânticas de serviços Web geradas pelo AutoWebS através
da aplicação de validadores sintáticos para a linguagem OWL-S;
1.2
Estrutura do Documento
Este trabalho está estruturado da seguinte forma: O Capítulo 2 apresenta as
tecnologias dos serviços Web, Web semântica e Desenvolvimento de Software Dirigido
por Modelos, que são usadas no desenvolvimento desse trabalho; o Capítulo 3 apresenta
a similaridade entre as linguagens de especificação de ontologias e a linguagem de
modelagem UML, apresentando o mapeamento entre a linguagem OWL e a UML; o
Capítulo 4 apresenta a ferramenta AutoWebS, detalhando sua arquitetura, implementação
e funcionamento; o Capítulo 5 apresenta um estudo de caso que usa a ferramenta; o
Capítulo 6 apresenta um experimento controlado que avalia a ferramenta AutoWebS;
o Capítulo 7 cita os trabalhos relacionados; por fim, no Capítulo 8 são descritas as
considerações finais e a conclusão.
1.2 Estrutura do Documento
18
O Apêndice A apresenta a linguagem XSL Tranformation, usada para converter
documentos XML em outro documento XML ou textual; o Apêndice B apresenta as tecnologias SOAP, WSDL, UDDI e Apache Axis2 usadas pelos serviços Web; o Apêndice C
traz a transformação XSLT; o Apêndice D demonstra o mapeamento QVT; e o Apêndice E
traz os questionários usados na condução do experimento controlado. O Apêndice F traz
uma breve explicação do modelo experimental Quadrado Latino.
CAPÍTULO 2
Fundamentação Teórica
Este capítulo descreve sucintamente as principais tecnologias usadas nesse trabalho. As tecnologias formam a fundamentação teórica para o trabalho e são apresentadas
da seguinte forma: a seção 2.1 discorre a respeito das principais tecnologias usadas pelos
serviços Web e apresenta o middleware para serviços Web da Apache Axis2; a seção 2.2
apresenta a Web Semântica, com enfoque para o framework RDF, também são apresentados os conceitos de ontologias e a linguagem OWL, por fim são apresentados os serviços
Web semânticos; a seção 2.3 apresenta a ontologia OWL-S que é utilizada para descrição
dos serviços Web; a seção 2.4 contém uma rápida descrição das tecnologias do contexto
do Desenvolvimento de Software Dirigido por Modelos (MDD) utilizadas neste trabalho.
2.1
Serviço Web
A W3C define serviço Web [Alonso et al., 2004] como uma tecnologia que provê
meios para comunicação entre diferentes sistemas de software em diferentes plataformas.
Os serviços Web são serviços distribuídos que processam mensagens SOAP (Simple Object Access Protocol) [Mitra, 2003] codificadas em um arquivo XML, mandadas através de protocolos da Internet como, por exemplo, HTTP (Hypertext Transfer Protocol)
e POP (Post Office Protocol). Os serviços Web são descritos em WSDL (Web Services
Description Language) e, normalmente, são registrados em um repositório UDDI (Universal Description Discovery and Integration) para que aplicações possam localizá-las,
conforme ilustrado na Figura 2.1.
O apêndice B apresenta as tecnologias SOAP, WSDL, UDDI e o framework da
Apache Axis2, usadas para construção de serviços Web.
2.2
Web Semântica
A Web semântica [Berners-Lee et al., 2001] propõe a estruturação semântica do
conteúdo da Web a partir da atribuição de um significado a cada elemento publicado na
2.2 Web Semântica
20
Figura 2.1: Arquitetura de um serviço Web - retirado de
[Wikipedia, 2011]
Internet de forma a tornar possível o seu entendimento, tanto pelo humano quanto pelo
computador. A Web Semântica estende a Web tradicional, baseada em redes de hiperlinks,
adicionando 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 ilustrado na Figura 2.2. A primeira tecnologia é a metalinguagem XML, que torna possível
estruturar e organizar conteúdos na Internet de forma customizada através de marcações.
A segunda tecnologia tem como propósito atribuir sentido lógico as informações. Sobre
estas informações aplicam-se esquemas sintáticos como, por exemplo, RDF (Resource
Description Framework) que é um modelo de representação para fazer em XML afirmações a respeito dos recursos disponíveis na Web. A terceira principal tecnologia são as
ontologias, utilizadas para explicitamente representar e definir os conceitos e suas interrelações em domínio.
Figura 2.2: Principais tecnologias da Web semântica
Existem uma série de mudanças em algumas características da Web tradicional
1 dados
estruturados que descrevem a característica de um recurso
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 exemplo, 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 [email protected], 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 possui um tipo Person que está definido no URI
htt p : //www.w3.org/2000/10/swap/pim/contact#Person. Esta afirmação relaciona alguns 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".
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,
[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.
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 indivíduos, classes, atributos e relacionamentos deste domínio. Para (Bruijn [de Bruijn, 2003]
apud Uschold [Uschold and Grüninger, 1996]): “as ontologias fornecem uma maneira
uniforme para a especificação de conceitos chave ou fundamentais, bem como uma quantidade arbitrária de subconceitos e fatos, em conjunto permitindo o compartilhamento e
reutilização de conhecimento contextual em um sistema de computação”. Assim, uma
ontologia define um vocabulário comum para pesquisadores que compartilham informações em um domínio, propicia o reuso do conhecimento deste domínio além de explicitar hipóteses e separar o conhecimento do domínio do conhecimento operacional
[Natalya Fridman Noy, 2001, Tiago Semprebom and Mendonça, 2007].
Segundo Clark [Clark, 1999], ontologia é a materialização do nível do conhecimento. O uso de ontologias é mais visível em aplicações de inteligência artificial, enge-
2.2 Web Semântica
25
nharia de software e sistemas de informação, porém ela pode ser utilizada em qualquer
aplicação que necessite representar e estruturar conhecimento ou a interoperabilidade entre sistemas incompatíveis como, por exemplo, na integração de bases de dados heterogêneas, uma vez que as ontologias não tem dependência com os modelos de dados.
Ontologias são especificadas em linguagens expressivas e com semântica bem
definida, passíveis de inferência. A W3C (World Wide Web Consortium) desenvolve um
conjunto de linguagens que têm como objetivo principal promover a interoperabilidade
entre aplicações na Web. Dentre essas linguagens a OWL (Web Ontology Language) é
utilizada para representar ontologias na Web.
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 determinada classe;
Propriedades são relações binárias entre os indivíduos do domínio de interesse. As
propriedades especificam características das classes e podem possuir capacidades
lógicas tal como transitividade, simetria, inversão e funcional.
Classes são conjuntos que contêm os indivíduos e são construídas a partir de descrições,
as quais especificam as condições que devem ser satisfeitas por um individuo para
que ele possa ser um membro da classe.
As propriedades podem ser do tipo Object Properties, DataType Properties e
Annotation Property. Propriedades do tipo Object Properties conectam um indivíduo
a outro indivíduo, as propriedades DataType Properties definem uma relação entre um
indivíduo e um tipo de dado definido em um Schema XML ou a um literal definido no
Schema RDF. As propriedades Annotation Property associam um indivíduo a um valor
específico.
Um documento OWL inicia-se com a declaração do seu cabeçalho. O cabeçalho
é delimitado pelo elemento <owl:Ontology> e especifica algumas informações a respeito
do autor e a versão do documento. O trecho de Código 2.2 demonstra a sintaxe de um
cabeçalho OWL.
Código 2.2 Declaração do cabeçalho de um documento OWL
1
<?xml version="1.0"?>
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
<owl:Ontology rdf:about="">
11
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
12
13
Comentario</rdfs:comment>
<dc:creator rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
14
15
Autor</dc:creator>
</owl:Ontology>
16
17
...
18
</rdf:RDF>
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
<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">
15
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
16
<rdfs:domain rdf:resource="#Regime"/>
17
</owl:DatatypeProperty>
18
<owl:DatatypeProperty rdf:ID="cpmValue">
19
<rdfs:domain rdf:resource="#Regime"/>
20
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
21
</owl:DatatypeProperty>
22
<owl:DatatypeProperty rdf:ID="idRegime">
23
<rdfs:domain rdf:resource="#Regime"/>
24
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
25
</owl:DatatypeProperty>
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
<Regime rdf:ID="Regime_5">
3
4
5
6
7
8
9
<stemSize rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
25</stemSize>
<burdenValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
59</burdenValue>
<idRegime rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
5</idRegime>
<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, os inputs e outputs de um serviço Web são descritos utilizando-se ontologias.
Desta forma, um cliente de um serviço Web semântico precisa obter informações que
descrevem como um determinado dado pode ser escrito em um documento XML que será
enviado para o serviço e como um documento XML, advindo do serviço Web semântico,
que pode ser interpretado semanticamente.
Os serviços Web semânticos utilizam ontologias para descrever seus serviços.
Neste sentido, os mecanismos oferecidos pela OWL para criação de ontologias, podem
ser reutilizados para os serviços Web. Desta forma, a linguagem OWL-S utiliza os mecanismos da OWL e adicionam outros, como por exemplo, um conjunto de conceitos
para descrição de serviços, para formar um framework que permite a inserção de semântica aos serviços Web de forma a tornar possível o descobrimento, execução e composição de serviços. OWL-S consiste de três subontologias conhecidas por Serviceprofile,
ServiceModel e ServiceGrounding.
2.3
OWL-S
OWL-S é uma ontologia baseada em OWL para descrever semanticamente serviços Web, permitindo aos usuários e agentes de software automaticamente descobrir,
invocar, compor e monitorar os recursos da Web que oferecem serviços, sob restrições
2.3 OWL-S
30
especificadas, por intermédio de uma descrição formal das suas propriedades e capacidades [Burstein et al., 2004]. O último release da especificação OWL-S é a versão 1.2, de
dezembro de 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 expressar ”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 ontologia ServiceModel com as especificações detalhadas dos formatos de mensagens, protocolos, entre outros, expressos no arquivo WSDL. A ontologia ServiceGrounding
pode ser vista como a cola entre as descrições semântica (ontologia) e sintática (WSDL)
[Davies et al., 2006].
Todas as subontologias estão ligados ao conceito de nível superior Service,
que serve como um ponto de referência organizacional para declarar serviços Web e
sempre que um serviço é declarado, uma instância do conceito de Service é criada. A
Figura 2.6 ilustra a relação entre as subontologias e as propriedades presents, describedBy,
e supports de Service.
Figura 2.6: Subontologias
da
OWL-S
[Burstein et al., 2004]
-
extraído
de
Cada instância de Service apresenta (presents) uma descrição ServiceProfi le,
é descrita (describedBy) pela subontologia ServiceModel e suporta (supports) uma
descrição ServiceGrounding.
2 Processo
de busca dos possíveis casamentos entre demandas/requisições e ofertas/serviços, em um
dado domínio de aplicação.
2.3 OWL-S
2.3.1
31
Service Profile
Na subontolgia ServiceProfile a classe ServiceProfile é uma superclasse para
todos os tipos de descrições em alto nível a respeito do serviço. Esta classe contém
as informações básicas necessárias para vincular qualquer instância de Profile, uma
subclasse da subontologia ServiceProfile, com uma instância de Service. O serviço,
definido através de Profile, é modelado em termos de três tipos de informações, detalhados
em seguida:
• As informações da organização que provê o serviço, constituindo-se de informações de contato que se refere à entidade que fornece o serviço. Por exemplo, informações de contato podem se referir ao operador de manutenção, que é responsável
pela execução do serviço, ou para um representante do cliente que podem fornecer
informações adicionais sobre o serviço [Burstein et al., 2004].
• A descrição da funcionalidade do serviço é expressa em termos da transformação
produzida pelo serviço. A descrição funcional inclui as entradas (inputs) requeridas
pelo serviço e as saídas (outputs) geradas; as pré-condições (precondition) requisitadas pelos serviços e os efeitos (effects) esperados da execução do serviço. Por
exemplo, um serviço de vendas pode exigir como pré-condição (precondition) um
cartão de crédito válido e como entrada (input) o número do cartão de crédito e data
de validade. Como saída (output) ele gera um recibo, e como efeito (effect) o cartão
é debitado [Burstein et al., 2004].
• O primeiro tipo de informação especifica a categoria de um determinado serviço,
por exemplo, a categoria do serviço dentro do sistema de classificação de produtos
e serviços para uso em eCommerce. O segundo tipo de informação é a classificação da qualidade do serviço, por exemplo, bom, ruim, tempo de resposta rápido,
confiável, taxa de atualização pequena. O último tipo de informação é uma lista de
parâmetros do serviço que pode conter qualquer tipo de informação, por exemplo,
parâmetros que fornecem uma estimativa do tempo de resposta máximo, a disponibilidade geográfica de um serviço [Burstein et al., 2004]. A classe Profile fornece
um mecanismo para representar tais parâmetros.
As informações que especificam as características do serviço podem ser úteis em
situações em que o solicitante do serviço pretende verificar a qualidade do serviço. Um
serviço pode ter suas informações publicadas em sistemas de classificação de forma que
sua ”qualidade” possa ser publicada. Neste caso, o solicitante do serviço pode usar essa
informação, contida no sistema de classificação, para verificar se o serviço é útil ou não
para a sua necessidade.
A classe Profile contém a especificação de quais funcionalidades o serviço
oferece e as condições que devem ser satisfeitas para sua execução. As funcionalidades e
2.3 OWL-S
32
as condições são representadas a partir de dois aspectos do serviço:
• a transformação da informação (representado por inputs e outputs);
• e a mudança de estado produzido pela execução do serviço (representado por
preconditions e effects).
Para exemplificar, considere o exemplo do cartão de crédito, agora aplicado
a uma livraria virtual. Para concluir a venda, o serviço requer como entrada (input) o
número do cartão de crédito e a data de validade, mas também a condição (precondition)
de que o cartão de crédito é válido e tem crédito. O resultado da venda é a saída (output) de
um recibo que confirma a boa execução da transação e como efeito (effect) o pagamento
(transferência de propriedade) e a transferência física do livro a partir do armazém da
livraria para o endereço do comprador [Burstein et al., 2004].
Nenhum esquema para descrever as instâncias dos Inputs/Outputs/Preconditions/Effects
(IOPEs) é fornecido pela classe Profile. No entanto, este esquema existe na subontologia
ProcessModel. Os IOPEs publicados pela classe Profile são um subconjunto daqueles
publicados pela subontologia ProcessModel, assim, espera-se que a subontologia ProcessModel crie todas as instâncias IOPEs e a instância de Profile simplesmente aponte para
essas instâncias de IOPEs.
A Figura 2.7, ilustra as propriedades da classe Profile que são usadas para referenciar os IOPEs definidos na subontologia ServiceProfile. As seguintes propriedades
são definidas:
hasParameter varia ao longo de uma instância da classe Parameter da subontologia
ServiceModel. Sua principal função é apenas tornar o conhecimento de domínio
explícito. A classe Parameter modela a intuição de que inputs e outputs - que são
os tipos de parâmetros - estão ambos envolvidos na transformação da informação
e, portanto, são diferentes das preconditions e effects. Como consequência, a classe
Parameter não é instanciada.
hasInput varia sobre instâncias da classe Inputs, definida na subontologia
ServiceModel.
hasOutput define instâncias da classe Output, da subontologia ServiceModel.
hasPrecondition especifica uma das pré-condições do serviço e varia ao longo de instâncias da classe Preconditions, definida de acordo com o esquema na subontologia
ServiceModel.
hasResult especifica um dos resultados do serviço, conforme definido pela classe Result
da subontologia ServiceModel. Esta propriedade especifica as condições em que
as saídas (outputs) são geradas. Além disso, a classe Result especifica quais as
mudanças de domínio são produzidos depois da execução do serviço.
2.3 OWL-S
33
Figura 2.7: OWL-S
Service
Profile
[Burstein et al., 2004]
-
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 oferece, descreve o que o serviço requer para funcionar, e indica qualquer informação
adicional que se queira compartilhar com os usuários.
contactInformation fornece um mecanismo para indicar os indivíduos responsáveis pelo
serviço.
Uma instância da classe Profi le pode ter no máximo um nome de serviço e
uma descrição em texto, mas pode ter várias propriedades de informações de contato.
Conforme ilustrado na Figura 2.7, a propriedade contactInformation está relacionada a
classe Actor, defi nida na ontologiaActorDefault.
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), representando as informações que estão sob certas condições (preconditions), necessárias para
iniciar o processo. Processos podem ter qualquer número de saídas (outputs), a informação de que o processo fornece ao solicitante. Inputs e Outputs são representados como
subclasses da classe Parameter. Apesar da Figura 2.8 não ilustrar a relação entre Input,
Output e Parameter, cada Parameter tem um tipo, especificado usando um URI. Pode
existir qualquer número de preconditions, que devem ser satisfeitas para que um processo possa ser iniciado com êxito. Um processo pode ter qualquer número de effects.
Outputs e effects dependem de condições acerca do estado do mundo no momento em
que o processo é realizado. Preconditions e effects são representados como fórmulas
lógicas e podem ser expressos com o uso de linguagens cujo padrão de codificação é
XML, tais como SWRL (Semantic Web Rule Language) [Horrocks et al., 2004] e RDF
[Manola and Miller, 2004], ou literais strings, tal como PDDL (The Planning Domain
Defi nition Language) [Ghallab et al., 1998].
Figura 2.8: Subontologia OWL-S ServiceModel - extraído de
[Burstein et al., 2004]
Para conectar um processo, ou seja, uma instância da classe Process aos seus
IOPEs, as seguintes propriedades são usadas:
hasParticipant que associa instâncias da classe Participant. Um processo envolve pelo
menos duas partes: theClient e theServer. Se existem outros, então eles são listados
usando-se a propriedade hasParticipant.
2.3 OWL-S
35
hasInput especifica as instâncias da classe Input. Um Input especifica a informação que
o processo requer para sua execução. Ele pode vir diretamente do usuário ou de
uma etapa anterior da execução do processo. No último caso, quando o processo é
composto de outros processos, ou seja, uma composição de serviços.
hasOutput especifica instâncias da classe Output. Um Output especifica a informação
que o processo gera após sua execução.
hasExistential Existential é uma variável usada para ser agregada na definição de preconditions e depois ser utilizado para especificar resultados condicionais, effects.
hasPrecondition define uma expressão que deve ser satisfeita para que o processo possa
ser executado.
hasResult a execução do processo pode ter algum effects e, provavelmente, outputs.
Result associa effects e outputs diretamente ao processo.
WSDL permite a especificação de operações como blocos básicos de construção do serviço Web. As operações provêm a estrutura organizacional onde os padrões e
a sintaxe das mensagens de input e output são especificadas. OWL-S provê uma construção análoga, porém mais abstrata conhecida por Atomic Process, que é caracterizada
principalmente em termos dos IOPEs [Martin et al., 2004]. OWL-S define três tipos de
processos:
Atomic Process é um processo que pode ser visto como uma descrição de um serviço
que espera uma mensagem e retorna outra mensagem de resposta. É diretamente
invocável e não contém nenhum subprocesso. Um Atomic Process recebe um input,
faz algum processamento, e depois retornar o output. Para cada Atomic Process deve
existir um grounding (apresentado na seção 2.3.3) que permita a um solicitante do
serviço codificar as mensagens para o processo a partir de seus inputs e decodificar
os outputs.
Composite Process é um processo que define a descrição de uma composição de serviços. Esta composição mantém algum estado e cada mensagem que o cliente envia é
passada para os processos da composição. Corresponde a ações que exigem várias
interações com servidores. Um Composite Process é composto por outros processos, Atomic ou Composite, que são especificados a partir de estruturas de controle
- Sequence, Split, Split + Join, Choice, Any-Order, If-Then-Else, Iterate e RepeatWhile.
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
2.3.3
36
Service Grounding
As subontologias ServiceProfile e ServiceModel descrevem o que o serviço
faz, ou seja, suas capacidades. Porém, para tornar possível que clientes comuniquem-se
com serviços Web, é necessário descrever a interface do serviço Web. A interface de um
serviço Web é especificada em um arquivo WSDL que descreve as mensagens e algumas
especificidades do protocolo da camada de aplicação usado para comunicação. WSDL
modela a interface do serviço como um conjunto de operações e suas mensagens associadas. O conteúdo das mensagens são especificadas de forma abstrata, como declarações
de elementos de um Schema XML.
Um serviço Web Semântico modela suas operações como entidades que trocam dados semânticos. Estes dados semânticos são serializados em mensagens XML
e transportados pela rede encapsulados em protocolo de aplicação. A subontologia
ServiceGrounding fornece os meios para representar os dados semânticos como mensagens XML que são enviadas pela rede e também especifica como o receptor pode interpretar essas mensagem XML e transformá-las novamente para os dados semânticos.
Grounding é um termo em inglês, amplamente utilizado e que não há uma tradução para o português fidedigna e, portanto, optamos por manter o termo em inglês. O
grounding de um serviço Web especifica os detalhes de como acessá-lo, isto é, os detalhes do protocolo e formatos de mensagens, serialização, transporte e endereçamento.
O grounding pode ser visto como um mapeamento da especificação abstrata para uma
concreta dos elementos que compões a descrição do serviço que são necessários para interagir com o serviço - em particular, os inputs e outputs de processos do tipo Atomic
Process. Isto porque as subontologias ServiceProfile e ServiceModel são representações abstratas, somente ServiceGrounding lida com o nível concreto da especificação
[Burstein et al., 2004].
O conceito de grounding em OWL-S assemelha-se ao conceito de binding
em WSDL [Burstein et al., 2004]. Juntos, estes conceitos fornecem a especificação do
grounding OWL-S/WSDL porque OWL-S e WSDL não fazem parte do mesmo espaço
conceptual, mas são complementares.
Os tipos abstratos (abstract types - ver apêndice B), são elementos do WSDL
especificados com uso de Schemas XML e usados para caracterizar os inputs e outputs
dos serviços Web. Em OWL-S a definição de abstract types é feita como classes OWL. No
entanto, WSDL é incapaz de expressar a semântica de uma classe OWL. Da mesma forma,
OWL-S não tem meios para expressar algumas informações do WSDL, por exemplo, as
informações referentes ao binding. Assim, o grounding OWL-S/WSDL usa classes OWL
como os abstract types de partes das mensagens declaradas no arquivo WSDL e se baseia
nas construções de binding do WSDL para especificar a formatação das mensagens.
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
[Burstein et al., 2004]
-
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 tipo Atomic Process com inputs e outputs corresponde a uma
operação do tipo request-response.
• Um processo do tipo Atomic Process com inputs, mas sem outputs corresponde a uma operação do tipo one-way.
• Um processo do tipo Atomic Process com outputs, mas sem inputs corresponde a uma operação do tipo notifi cation.
• Um processo do tipo Composite Process com inputs e outputs sendo que
os outputs são enviados antes da recepção dos inputs, corresponde a uma
operação do tipo solicit-response
2. Os inputs e outputs de um processo do tipo Atomic Process correspondem as
mensagens especificadas no arquivo WSDL. Os inputs OWL-S correspondem às
partes de uma mensagem (message part) de entrada (input message) de uma
operação (operation) do WSDL e os outpust OWL-S correspondem às partes
de uma mensagem (message part) de saída (output message) de uma operação
(operation) do WSDL.
3. Os tipos, ou seja, as classes OWL dos inputs e outputs de um Atomic Process
correspondem a noção extensível WSDL de abstract types.
A Figura 2.10 apresenta as principais classes e propriedades da subontologia
ServiceGrounding.
2.3 OWL-S
38
Figura 2.10: Classes e propriedades da subontologia OWL-S ServiceGrounding
A classe WsdlGrounding é uma subclasse de ServiceGrounding. Seu papel é fornece um mecanismo para que as principais construções do arquivo WSDL possam ser referenciadas em OWL-S. Cada instância da classe WsdlGrounding contém uma lista de instâncias de WsdlAtomicProcessGrounding. Essa relação é representada pela propriedade
hasAtomicProcessGrounding. A propriedade owlsProcess garante que para cada processo
do tipo AtomicProcess exista somente um WsdlAtomicProcessGrounding. Por outro lado
a propriedade wsdlOperation assegura uma relação um-para-um entre o Atomic Process
e a especificação WSDL. WsdlMessageMap é uma superclasse para WsdlInputMessageMap e WsdlOutputMessageMap. WsdlAtomicProcessGrounding utiliza, basicamente, as
seguintes propriedades para referenciar elementos de Atomic Process com a especifi cação
WSDL:
wsdlVersion um URI que indica a versão do WSDL utilizado. A versão 1.1 da OWL-S é
compatível com a versão 1.1 da WSDL enquanto que OWL-S, a versão mais atual,
é compatível com WSDL 1.2. Esta propriedade não aparece na Figura 2.10, pois ela
não relaciona a nenhuma outra classe, ela relaciona com um tipo URI especificado
no XML Schema.
wsdlDocument um URI que indica o documento WSDL ao qual o grounding se refere.
Esta propriedade não é essencial e seu uso é basicamente para documentação. É um
tipo URI especificado no Schema XML.
wsdlOperation é o URI para a operação (operation) especificada no arquivo WSDL ao
qual o Atomic Process corresponde. O valor de wsdlOperation pode ou não identi-
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 restringir os Ports que podem ser utilizadas para um WsdlAtomicProcessGrounding é
necessário especificá-los utilizando as propriedades wsdlService e/ou wsdlPort.
wsdlService é um URI para o elemento Service do WSDL que provê a operação
(operation) com o qual o Atomic Process está associado. Vale ressaltar que um
elemento Service do WSDL é uma coleção de EndPoints.
wsdlPort um URI para o elemento Port do WSDL que provê a operação (operation)
com o qual o Atomic Process está associado. Um Port é endpoint definido como
uma combinação de um binding e um endereço.
wsdlInputMessage um URI para o elemento input message da especificação WSDL que
corresponde aos inputs do Atomic Process.
wsdlInput esta propriedade é utilizada para definir a correspondência entre os inputs
OWL-S e Message Parts do WSDL. Para cada Message Parts de um input
message declarado no WSDL, deve existir uma propriedade wsdlInput. Conforme a Figura 2.10 ilustra, a propriedade wsdlInput associa uma instância de
wsdlAtomicProcessGrounding a uma instância da classe wsdlInputMessageMap
que contém o mapeamento. A instância de wsdlInputMessageMap contém a propriedade wsdlMessagePart que, com um URI identifica a Message Part do WSDL
associado e, também a propriedade owlsParameter ou xsltTransformation. Ambas
representam como derivar a Message Part de um ou mais inputs do Atomic Process.
owlsParameter é utilizado para o caso mais simples, quando existe uma correspondência direta entre o input do Atomic Process e o wsdlMessagePart. Isto
significa que o Message Part WSDL corresponde diretamente ao input e o tipo
do input é usado na especificação do WSDL. Basta colocar o URI do input na
propriedade.
xsltTransformation é utilizado para os outros casos em que a propriedade
owlsParameter não se aplica. A propriedade xsltTransformation adiciona um
script XSLT que gera o Message Part de uma instância de um Atomic Process.
O script pode ser diretamente representado como uma string ou pode ser referenciado por um URI.
wsdlOutputMessage similar à propriedade wsdlInputMessage porém, aplicada aos
outputs.
wsdlOutput Para cada output do Atomic Process deve existir um valor da propriedade
wsdlOutput. É similar à propriedade wsdlInput porém, aplicados a outputs. Ela
3 Port
define o ponto de conexão (EndPoint) com um serviço Web.
2.4 Desenvolvimento de Software Dirigido por Modelos
40
especifica um mapeamento entre um output de Atomic Process, que é representado
pela instância de WsdlOutputMessageMap.
2.4
Desenvolvimento de Software Dirigido por Modelos
O Desenvolvimento de Software Dirigido por Modelos (Model Driven
Development - MDD) [Stahl and Völter, 2006] é uma abordagem top-down de desenvolvimento de software que tem como essência a especificação de modelos e transformações
desses modelos em outros modelos ou artefatos de software, de forma a permitir a comunicação de diferentes fases do desenvolvimento de software. Os modelos são utilizados
como veículos para descrição de sistemas de software, facilitando a comunicação entre
as partes do sistema e, também, associando as diferentes fases do processo de desenvolvimento de software. Segundo Stahl e Voelter [Stahl and Völter, 2006], as principais
características do MDD são: alta produtividade, portabilidade, interoperabilidade e reusabilidade. Além disso, o MDD permite que as transformações entre modelos possam ser
realizadas por ferramentas automatizadas, as quais reduzem os erros de programação e
os custos de desenvolvimento.
As transformações entre os modelos MDD são especificadas em linguagens
que possuem uma sintaxe textual concreta e utilizam metamodelos para criar regras de transformações entre os modelos. Os modelos são descritos por metamodelos e representados normalmente com o padrão XMI (XML Metadata Interchange)
[Object Management Group, 2007]. A Figura 2.11 ilustra o contexto em que essas linguagens estão inseridas.
Figura 2.11: Transformações entre modelos
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 metamodelos; o framework EMF.Edit que inclui classes genéricas reusáveis para construção
de editores para modelos EMF; e o EMF.Codegen que é um gerador de código capaz de
gerar os artefatos necessários para construção de um editor completo para um modelo
EMF.
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 diretamente aos elementos primários da linguagem UML podem ser representados com o uso
de perfis UML. As similaridades entre essas linguagens são fundamentais para a especificação do perfil UML que a ferramenta AutoWebS usa. O restante deste capítulo está
organizado como se segue. A seção 3.1 apresenta o mapeamento entre as linguagens de
especificação de ontologias e a UML. A seção 3.2 mostra os elementos da linguagem
OWL que são diretamente usados e, portanto, necessários para criação de serviços Web
semânticos, apresentando como esses elementos podem ser representados com elementos
da UML.
3.1
Mapeamento entre as linguagens de especificação de
ontologias e a UML
As linguagens de especificação de ontologias como, por exemplo, a linguagem
OWL, e a linguagem UML têm propósitos diferentes, que refletem nos seus elementos
e nas suas expressividades. Modelos UML e ontologias constituem abordagens de modelagem com diferentes propósitos, que os tornam adequados para especificar aspectos diferentes de sistemas de software. Em particular, ontologias são adequadas para
especificar classes usando uma linguagem lógica expressiva, com associação de clas-
3.1 Mapeamento entre as linguagens de especificação de ontologias e a UML
44
ses e definição de propriedades altamente flexíveis e polimórficas, enquanto diagramas
UML são mais adequados para especificar não apenas modelos estáticos, incluindo classes e associações, mas também o comportamento dinâmico de sistemas de software
[Silva Parreiras et al., 2007].
A linguagem UML define uma notação para a modelagem dos artefatos de
software orientado a objetos, enquanto que as linguagens de especificação de ontologias definem uma notação para representação de conhecimento, mas ambas são linguagens de modelagem [Belghiat and Bourahla, 2012]. O mapeamento das construções
das linguagens UML e de especificação de ontologias é possível graças a essas similaridades entre as linguagens [Pondrelli, 2005, Hart et al., 2004, Atkinson et al., 2006,
Gasevic et al., 2006]. Pondrelli [Pondrelli, 2005], em seu trabalho, explana a respeito da
viabilidade de usar métodos baseados em perfis UML e editores UML para construção e
gerenciamento de ontologias, além de apresentar os mapeamentos entre a UML e as principais construções utilizadas por linguagens de especificação de ontologias, conforme
representado na Tabela 3.1.
UML
Packages
Classes
Attributes, associations and classes
Navigable
Note
Multiplicity
Data types
Objects
Construções ontológicas
Ontologies
Classes
Properties
Domain, Range
Comment
Cardinality
Data types
Instances
Tabela 3.1: Mapeamento entre UML e os principais conceitos das
linguagens para especificação de ontologias
No mapeamento entre a UML e uma linguagem de especificação de ontologias, a
definição de ontologias assemelha-se a definição de um package em UML. Uma ontologia
cria um modelo de dados que representa um conjunto de conceitos e seus relacionamentos
dentro de um domínio. Os conceitos podem ser representados por classes UML e as
propriedades que uma classe pode ter especificam suas características e criam relações
entre os conceitos do domínio de interesse. Conforme a Tabela 3.1, as construções das
linguagens de especificação de ontologias Domain e Range, Comment, Cardinality, Data
Type e Instances são diretamente mapeadas para os elementos da UML.
As construções que especificam propriedades (Properties) em uma ontologia podem ter múltiplas representações em UML devido a grande expressividade das linguagens de especificação de ontologias. Por exemplo, na linguagem OWL as propriedades
que especificam restrições (Restriction) do tipo intersectionOf, unionOf e complementOf, são construções para formação de uma classe a partir de uma combinação boole-
3.1 Mapeamento entre as linguagens de especificação de ontologias e a UML
45
ana de classes OWL. Na UML, não existem notações correspondentes as restrições do
tipo intersectionOf, unionOf e complementOf. Uma alternativa para as representações em
UML de construtores de classe OWL é o emprego de estereótipos e dependências UML
para as classes que formam o complemento (complementOf ), parte da união (unionOf )
ou parte do cruzamento (intersectionOf ) de uma classe.
Seguindo a abordagem de perfis UML, a OMG criou a especificação Ontology
Definition MetaModel (ODM) [Object Management Group, 2009], uma especificação
para tornar os conceitos da Arquitetura Dirigida a Modelos (Model-Driven Architecture
- MDA) [Frankel, 2003] aplicáveis à engenharia de ontologias. A especificação
ODM define uma família de metamodelos independentes, perfis UML relacionados
e mapeamentos entre os metamodelos correspondentes a vários padrões para definição de ontologias. A especificação ODM é aplicável a representação do conhecimento, modelagem conceitual e a definição de ontologias. ODM é implementado
em MOF e contém uma especificação formal para perfis UML e para as linguagens
OWL e RDFS. A ODM é uma alternativa viável para se criar ontologias e várias
ferramentas [Silva Parreiras et al., 2007, Sparx Systems, 2000, Brockmans et al., 2006,
Belghiat and Bourahla, 2012, Gaševic et al., 2009] fazem uso da especificação a fim de
se prover abstração sobre as linguagens de especificação de ontologias.
Para especificar a interface de um serviço Web semântico, ou seja, definir os
inputs e outputs do serviço Web e associá-los a conceitos definidos em uma ontologia,
é necessário um subconjunto dos elementos da linguagem OWL. Outros elementos da
OWL, principalmente a parte axiomática, não são diretamente usados na especificação
da interface de um serviço Web semântico, porém esses elementos, normalmente, são
usados por máquinas de inferê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
1 São
sistemas de representação de conhecimento capazes de realizar consultas sobre as ontologias de
modo a deduzir novas informações, geralmente implícitas, a respeito de um domínio preexistente.
3.2 Mapeamento entre OWL e UML
46
propriedades que habilitam a associação dos inputs e outputs de um serviço Web com
conceitos definidos em uma ontologia. No perfil UML também são definidos estereótipos
e propriedades do domínio dos serviços Web, que não são endereçados pela especificação
ODM. O propósito da ferramenta AutoWebS não é propiciar a modelagem de ontologias
usando-se a UML, como se propõe a especificação ODM. O propósito da ferramenta
AutoWebS é proporcionar a modelagem da interface de um serviço Web semântico.
3.2
Mapeamento entre OWL e UML
Kim e Lee [Kim and Lee, 2007, Kim and Lee, 2009] e Falkovych et al.
[Falkovych et al., 2003] apresentam uma série de transformações entre as construções da
linguagem OWL e a UML que serviram como base para especificação dos mapeamentos
utilizados pela ferramenta AutoWebS. Não são todas as construções da linguagem OWL
que são necessárias para criação da descrição semântica do serviço Web. Somente as
construções da OWL que definem classes e subclasses, propriedades de objetos e tipos
de dados são necessárias. Vale ressaltar que, o mapeamento entre a OWL e UML apresentado neste trabalho, não tem como objetivo representar todos os elementos da OWL
em UML. São realizados os mapeamentos somente estre os elementos necessários para
especificação de um serviço Web semântico. Os elementos da OWL que são mapeados
para a UML são apresentados a seguir
O elemento da OWL owl:Ontology é mapeado para um package em UML. Os
mapeamentos possíveis para os elementos que são declarados dentro de owl:Ontology
estão representados na Tabela 3.2. O elemento owl:imports associa uma ontologia a outra
quando são usados conceitos definidos em outra ontologia. O mapeamento deste elemento
dá-se pelo elemento UML package imports.
Construções OWL
owl:Ontology
owl:Ontology owl:versionInfo
owl:Ontology rdfs:comment
owl:Ontology owl:imports
UML
package UML
note UML
note UML
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
Construções OWL
owl:Class
owl:Class rdf:ID
owl:Class rdfs:subClassOf
owl:Class owl:oneOf
owl:Class owl:equivalentClass
owl:Class owl:disjointWith
owl:Class owl:intersectionOf
owl:Class owl:unionOf
owl:Class owl:complementOf
47
UML
classe UML
nome da classe
Generalização de uma classe
define um tipo Enumeration UML
não se aplica
não se aplica
não se aplica
Dependency UML
não se aplica
Tabela 3.3: Mapeamento entre as construções de classes OWL e a
UML
O elemento owl:Restriction define as restrições que são aplicadas sobre uma
classe OWL. As restrições podem estar associadas aos tipos de dados e as propriedades
que uma determinada classe pode ter. O elemento owl:Restriction também define qual
é a cardinalidade das restrições aplicadas sobre uma classe. A Tabela 3.4 ilustra o
mapeamento desta construção para os elementos da UML.
Construções OWL
owl:Restriction
owl:Restriction owl:allValuesFrom
owl:Restriction owl:someValuesFrom
owl:Restriction owl:hasValue
owl:Restriction owl:maxCardinality
owl:Restriction owl:minCardinality
owl:Restriction owl:cardinality
UML
restrições aplicadas em uma classe
não se aplica
não se aplica
não se aplica
multiplicidade
multiplicidade
cardinalidade
Tabela 3.4: Mapeamento entre o elemento owl:Restriction e a
UML
As propriedades que incidem sobre uma determinada classe OWL podem ser
mapeadas para UML como atributos de uma classe a partir de uma associação binária ou unidirecional com outras classes. As propriedades owl:ObjectProperty rdfs:range
e owl:DatatypeProperty rdfs:range definem o tipo do atributo que incide em uma
classe OWL. Os valores possíveis destes atributos são os tipos definidos no Schema
XML ou as classes OWL. A Tabela 3.5 apresenta os mapeamentos para os elementos
owl:ObjectProperty e owl:DatatypeProperty.
As demais construções da linguagem OWL, representadas na Tabela 3.6, não são
aplicadas para especificação da interface de um serviço Web semântico.
Na UML existem apenas quatro tipos primitivos predefinidos de dados: Integer,
Boolean, String e UnlimitedNatural. O tipo UnlimitedNatural representa um elemento
3.2 Mapeamento entre OWL e UML
48
Construções OWL
owl:ObjectProperty
owl:ObjectProperty rdf:ID
owl:ObjectProperty rdfs:range
owl:ObjectProperty rdfs:domain
owl:ObjectProperty rdfs:subPropertyOf
owl:ObjectProperty owl:equivalentProperty
owl:ObjectProperty owl:inverseOf
owl:DatatypeProperty
owl:DatatypeProperty rdf:ID
owl:DatatypeProperty rdfs:domain
owl:DatatypeProperty rdfs:range
construções para indivíduos OWL
UML
atributo de uma classe
nome do atributo
tipo do atributo.
classe que contém o atributo
não se aplica
não se aplica
não se aplica
atributo de uma classe
nome do atributo
classe que contém o atributo
o tipo do atributo
não se aplica
Tabela 3.5: Mapeamento entre os elementos owl:ObjectProperty e
owl:DatatypeProperty e a UML
Construções OWL
owl:FunctionalProperty
owl:InverseFunctionalProperty
owl:TransitiveProperty
owl:SymmetricProperty
owl:AnnotationProperty
owl:backwardCompatibleWith
owl:incompatibleWith
owl:DeprecatedClass
owl:DeprecatedProperty
UML
não se aplica
não se aplica
não se aplica
não se aplica
não se aplica
não se aplica
não se aplica
não se aplica
não se aplica
Tabela 3.6: Mapeamento entre alguns elementos da OWL e a UML
do conjunto dos números inteiros naturais (0, 1, 2, 3, ...). Entretanto, no Schema 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 mapeamento em UML para este trecho de código OWL. As classes OWL Regime e Change foram mapeadas para classes UML. As propriedades do tipo DatatypeProperty foram mape2 http://www.w3.org/2001/XMLSchema
3.2 Mapeamento entre OWL e UML
Schema XML
xsd:integer
xsd:int
xsd:unsignedShort
xsd:boolean
xsd:string
xsd:anySimpleType
xsd:nonNegativeInteger
xsd:positiveInteger
49
UML
Integer
Integer
Integer
Boolean
String
String
UnlimitedNatural
UnlimitedNatural
Tabela 3.7: Mapeamento dos tipos de dados do Schema XML e a
UML
adas para atributos da classe Regime, sendo que os seus tipos, defi nidos no Schema XML
como http://www.w3.org/2001/XMLSchema#string, foram mapeados para o tipo primitivo String da UML. A propriedade do tipo ObjectProperty hasRegime, foi mapeada para
um atributo da classe Change.
Figura 3.1: Exemplo de mapeamento entre OWL eUML
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 utilização; a Seção 4.3 apresenta a arquitetura da ferramenta, explicitando seus componentes
e tecnologias relacionadas; a Seção 4.4 apresenta o perfil UML especificado e implementado por este trabalho, usado para representar elementos da OWL em UML; a Seção 4.5
traz o processo de importação de ontologias OWL, apresentando a transformação XSLT; a
Seção 4.6 apresenta o metamodelo para linguagem OWL-S que este trabalho especificou
e implementou; a Seção 4.7 apresenta as regras de mapeamento entre um modelo UML o
um modelo OWL-S; a Seção 4.8 ilustra o funcionamento da ferramenta.
4.1
Requisitos de uma ferramenta para criação de serviços Web semânticos
Antes do desenvolvimento da ferramenta AutoWebS um conjunto de requisitos
de uma ferramenta para criação de serviços Web semânticos foram estabelecidos. Os requisitos têm como objetivo principal abstrair detalhes específicos, relativos a cada linguagem de descrição semântica, de forma a propiciar o desenvolvimento de ferramentas que
ofereçam um maior nível de abstração sobre a sintaxe das linguagens usadas na criação
da descrição semântica dos serviços Web.
4.1 Requisitos de uma ferramenta para criação de serviços Web semânticos
51
[Chafle et al., 2007] e [Fonseca et al., 2009] propuseram alguns requisitos essenciais para o desenvolvimento de uma ferramenta para compor serviços Web. Alguns destes
requisitos foram adaptados para uma ferramenta de alto nível de abstração para a criação
de serviços Web semânticos. Os requisitos adaptados, juntamente com novos requisitos
formam o conjunto mínimo de requisitos para uma ferramenta para criação de serviços
Web semânticos acessível a um público maior do que um público formado somente por
especialistas da Web semântica. A seguir são apresentados os requisitos:
R0 Disponibilizar um mecanismo para que o usuário possa modelar a interface do serviço
Web semântico sem que ele precise de um profundo conhecimento das tecnologias
Web e Web semântica. Este mecanismo deve usar uma abordagem acessível e que
torne o desenvolvimento de um serviço Web semântico intuitivo e prático, evitandose assim uma curva de aprendizado acentuada;
R1 Realizar a criação automática do código fonte do serviço Web;
R2 Realizar a criação automática da descrição semântica do serviço Web na linguagem
alvo como, por exemplo, OWL-S;
R3 Permitir a utilização de ontologias preexistentes para a criação da descrição semântica
do serviço Web a partir da interligação dos conceitos definidos nestas ontologias
com os elementos do serviço Web;
R4 Oferecer um ambiente de desenvolvimento que integra todas as funcionalidades necessárias para a criação de um serviço Web semântico, sem que haja a necessidade
do uso de recursos ou ferramentas externas;
R5 Gerar artefatos de código (serviço Web e ontologia do serviço Web) sintaticamente
corretos. O código gerado deve ser legível, executável e corresponder às especificações da W3C para serviços Web e serviços Web semânticos;
R6 Permitir a inserção de novas funcionalidades como, por exemplo, o suporte a outra
linguagem para descrição semântica do serviço Web, sem que haja a necessidade
de realizar grandes modificações estruturais na ferramenta.
O requisito R0 diz respeito ao uso de modelos para especificar a interface de um
serviço Web, de forma a abstrair as tecnologias subjacentes usadas para implementação
do serviço Web e também da sua ontologia. Assim, poupa-se do usuário o conhecimento
destas tecnologias e permite-se que o mesmo direcione mais atenção as regras de negócio
do serviço Web. Os requisitos R1 e R2 relacionam-se à automatização da geração de
artefatos de código. Esses são requisitos importantes e complementares ao requisito R0,
pois deseja-se abstrair as linguagens envolvidas na criação de serviços Web semânticos.
O requisito R3 proporciona maior liberdade para criação do serviço Web semântico
e contribui para interoperabilidade, pois podem-se usar ontologias que são bastante
conceituadas e usadas na Internet.
4.2 Visão Geral da Ferramenta
52
O requisito R4 é fundamental para diminuir o tempo de desenvolvimento dos
serviços Web semânticos e, também, evitar erros e possíveis conflitos gerados quando
se usa diferentes ferramentas para construção de um serviço Web semânticos como,
por exemplo, quando se usa uma determinada ferramenta para criação da ontologia de
domínio que usa uma determinada versão da linguagem de especificação de ontologias
que não é compatível com outra ferramenta que dá suporte a criação da descrição
semântica do serviço Web. O requisito R5 tem como objetivo assegurar a corretude
dos artefatos de códigos gerados pela ferramenta, uma vez que, um trecho de código
quando gerado de forma errada, inevitavelmente necessita que o usuário tenha certo grau
de conhecimento da tecnologia para sua correção. Por fim, o requisito R6 proporciona
suporte a manutenção da ferramenta, seja para inserção de novas funcionalidades ou
então para evolução das funcionalidades atuais como, por exemplo, a atualização para
uma versão mais recente da linguagem de descrição semântica do serviço Web.
4.2
Visão Geral da Ferramenta
O AutoWebS é um plugin da IDE Eclipse e relaciona-se com outros plugins
de forma a prover um ambiente que integra as várias funcionalidades necessárias modelagem, implementação, compilação e deploy - para a criação automática de serviços
Web semânticos (requisitos R4 e R6)1 . Através do ambiente oferecido por AutoWebS é
possível i) modelar o serviço Web, isto é, modelar os inputs e outputs de cada operação
do serviço Web, ii) criar a descrição semântica do serviço Web, ou seja, associar os
inputs e outputs de cada operação com os elementos de uma ontologia de domínio, iii)
criar um arquivo OWL-S que contém a descrição semântica do serviço Web e, iv) gerar
automaticamente o código fonte do serviço Web modelado na linguagem Java.
O uso da ferramenta AutoWebS, conforme ilustrado na Figura 4.8, constitui-se
de três principais atividades: (a) importação, (b) design e (c) geração. A ferramenta requer
como entrada ontologias OWL (requisito R3) e fornece como saída um arquivo OWL-S
que contém a ontologia do serviço Web (requisito R2), além do código fonte do serviço
Web na linguagem Java (requisito R1).
A primeira atividade para criação de serviços Web semânticos usando-se a ferramenta AutoWebS é a atividade de importação de ontologias OWL (a). Nesta atividade a
ferramenta faz o mapeamento dos elementos da ontologia OWL para elementos da UML,
de forma que o resultado é um modelo UML (diagrama de classes) que representa a ontologia OWL de entrada. Neste modelo UML estereótipos e propriedades definidas em
um perfil UML asseguram informações suplementares inerentes à ontologia de entrada
1 Rx
indica que o requisito x é atendido por esta decisão de projeto
4.2 Visão Geral da Ferramenta
53
Figura 4.1: Visão geral da ferramenta AutoWebS
e também informações relevantes do contexto dos serviços Web semânticos como, por
exemplo, propriedades que definem a porta onde está o serviço Web, o endPoint e namesapaces.
No ambiente fornecido pelo AutoWebS é possível se definir a interface do
serviço Web semântico usando os elementos do diagrama de classes UML. Do ponto
de vista do projetista do serviço Web semântico a ferramenta assemelha-se a um editor
de diagrama de classes UML (requisito R0). Na atividade (b), modelagem, o projetista
trabalha no nível de modelagem, criando modelos que especificam a interface do serviço
Web semântico ao invés de manusear as linguagens para descrição semântica dos serviços
Web.
Na atividade (c), geração, o modelo UML que especifica a interface do serviço
Web semântico é a entrada para ferramenta AutoWebS usar um conjunto de regras
de transformações QVT e templates Acceleo para gerar automaticamente a descrição
semântica do serviço Web em um documento OWL-S (requisito R2) e um projeto para
IDE Eclipse do serviço Web (requisito R1). O projeto de um serviço Web contém
o documento WSDL, o descritor do serviço Web, o script de build que automatiza
a compilação e empacotamento do serviço Web, além das classes que compõem a
infraestrutura de comunicação SOAP.
Para assegurar que a descrição semântica do serviço Web é válida, alguns validadores disponíveis na Internet e uma API (requisito R5) são utilizados. O validador
RDF [Prod’hommeaux, 2007], disponibilizado pela W3C, é utilizado para validar as construções em RDF da ontologia do serviço Web. O validador OWL [Rager et al., 2004]
é utilizado para validar as construções OWL enquanto que para validar as construções e a sintaxe OWL-S é utilizado o validador OWL-S, disponível na API OWL-S
[Sirin and Parsia, 2004].
4.3 Arquitetura
54
A ferramenta AutoWebS implementa uma abordagem MDD para atender principalmente os requisitos R0, R1, R2 e R3, com a função de gerenciar a complexidade
inerente do emprego de ontologias para especificação de serviços Web semânticos, pois
MDD está centrado na criação de modelos, em vez de código de programa, permitindo
separação de interesses entre especificação e implementação, provendo ao usuário um
maior nível de abstração da linguagem OWL.
O AutoWebS implementa um mecanismo de importação de ontologias de domínio que usa um conjunto de transformações XSLT e um perfil UML (requisito R3). XSLT
é uma linguagem declarativa para transformações de documentos XML que usa um mecanismo de casamento de padrões capaz de selecionar pedaços de documentos XML para
criação de novos documentos com a sintaxe XML ou textual. No processo de importação de ontologias de domínio, alguns elementos da linguagem OWL são mapeados para
elementos da UML (ver Seção 3.2). Este processo não assegura a representação de todos
os elementos da ontologia no modelo UML, pois são mapeados somente os elementos
necessários para modelagem de um serviço Web semântico.
4.3
Arquitetura
O AutorWebS é um plugin para a plataforma Eclipse e fornece um ambiente
composto por um editor UML, um mecanismo de importação de ontologias e um mecanismo para criação automática da descrição semântica do serviço Web e do código fonte a
partir de um modelo UML (requisito R4). Conforme ilustrado na Figura 4.2, o AutoWebS
interage com outros plugins da plataforma Eclipse, com o middleware Axis2 e também
com Ant [Loughran and Hatcher, 2007]. Novas funcionalidades podem ser integradas à
ferramenta com a inserção de novos plugins (requisito R6), usufruindo-se da infraestrutura oferecida pelo Eclipse para o desenvolvimento de aplicações modulares. Ademais,
a abordagem MDD implementada pela ferramenta permiti a inserção de uma nova linguagem de descrição semântica com a criação de um metamodelo para tal linguagem e a
definição do mapeamento entre os elementos definidos no perfil UML com o metamodelo
além, é claro, das transformações model-to-text.
O AutoWebS utiliza o editor gráfico UML Papyrus [Gérard et al., 2007] que é
parte oficial do Eclipse Modeling Project. O Papyrus oferece suporte a perfis UML de
forma a permitir a criação de editores para DSLs (Domain Specific Language) baseados
no padrão UML. A principal característica do Papyrus em relação à criação de editores
para DLSs é um conjunto poderoso de mecanismos de personalização que podem ser
utilizados para criação de perspectivas customizáveis para os editores de DSLs. Assim,
usando o Papyrus e seus mecanismos de personalização, juntamente com o perfil UML,
foi concebido um editor de diagramas de classes UML customizado para o AutoWebS
4.3 Arquitetura
55
Figura 4.2: Arquitetura da ferramenta AutoWebS
(requisito R0). Este editor UML permite a criação de modelos UML que contêm a
interface do serviço Web semântico. Estes modelos UML são exportados pelo editor como
documentos XMI.
Para importação da ontologia é necessária a execução das regras de transformações descritas em XSLT. O componente ImporterModule realiza a execução das regras
XSLT usando o processador XSLT do componente XSL Tools, que faz parte do projeto
Web Tools Platform [Dai et al., 2007]. O plugin QVTo é usado para execução do conjunto
de regras de transformações QVT para geração automática de um modelo OWL-S a partir
de um modelo UML, codificado em um documento XMI. Além do modelo OWL-S, o código fonte em Java do modelo UML (requisito R1) é gerado utilizando o plugin UML to
Java Generator [Obeo Network, 2012]. O código fonte gerado a partir do modelo contém
todos os elementos do modelo UML, inclusive a interface que defi ne o serviço Web e os
elementos da ontologia que foram representados como classes UML.
O componente WebServiceModule é responsável por estender a funcionalidade
do Axis2 a fim de prover não somente a geração do código fonte, mas também a criação
de projetos de serviços Web para plataforma Eclipse (requisito R0) e algumas facilidades
para a compilação, empacotamento e deploy do serviço Web em um contêiner Web. O
projeto de um serviço Web contém o documento WSDL, o descritor do serviço Web,
utilizado para realizar o deploy, além das classes que compõem a infraestrutura de
comunicação SOAP. Todas as facilidades oferecidas por este componente são acessíveis
por botões ou menus na ferramenta.
4.4 Perfil UML
4.4
56
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 estereótipo «owl:Ontology» é aplicado sobre a definição de um elemento Package da UML
e corresponde ao elemento Ontology da OWL. Este estereótipo define o domínio da ontologia e contém informações a respeito da versão da ontologia, autor, comentários, além de
declarações de namespaces. Uma ontologia pode importar conceitos de outras ontologias.
Desta forma, o estereótipo «owl:imports», que tem como metaclasse o elemento da UML
PackageImport, habilita o relacionamento entre os elementos de várias ontologias.
2 São
propriedades que os estereótipos podem ter.
4.4 Perfil UML
57
Figura 4.3: Perfil UML usado pela ferramenta AutoWebS
O estereótipo «owl:Class» representa um conceito que foi modelado como uma
classe. As propriedades DatatypeProperty e ObjectProperty são mapeadas como atributos de uma classe UML estereotipada por «owl:Class». Nestes atributos são aplicados os estereótipos «owl:DatatypeProperty» e «owl:ObjectProperty». O estereótipo
«rdfs:subClassOf» é aplicado sobre a metaclasse UML Generalization e representa generalizações de classes OWL.
Os estereótipos «Text-description» e «Category» estendem a metaclasse UML
Comment e possibilitam a descrição textual do serviço Web semântico e a associação
a uma categoria (ver Seção 2.3.1). Os estereótipos «Pre-condition» e «Effect» estendem a metaclasse UML Constraint com o objetivo de especificar restrições as quais
4.5 Importação das Ontologias OWL
58
devem ser satisfeitas para que o serviço Web seja executado apropriadamente. Na linguagem OWL-S, os elementos preconditions e effects são representados como fórmulas
lógicas e podem ser expressos com o uso de linguagens cujo padrão de codificação é
XML, tais como SWRL (Semantic Web Rule Language) [Horrocks et al., 2004] e RDF
[Manola and Miller, 2004], ou literais strings, tal como PDDL (The Planning Domain
Definition Language) [Ghallab et al., 1998]. Na versão atual da ferramenta AutoWebS o
suporte a visualização e gerenciamento das expressões lógicas é básico. Atualmente as
expressões lógicas são inseridas em um campo de texto do elemento Constraint da UML
e nenhum processamento é realizado pela ferramenta para assegurar a expressividade da
linguagem. Como trabalho futuro pretende-se desenvolver um GUI para prover a gerência
e visualização das expressões lógicas, tal como [Hassanpour et al., 2010] propôs.
O estereótipo «SemanticWebService» é aplicado sobre a definição de um tipo
UML Interface. Na interface em que o estereótipo «SemanticWebService» é aplicado,
são definidas as operações do serviço Web. As operações do serviço Web são modeladas
como métodos. Este estereótipo contém alguns tagged-values que servem para adicionar
informações suplementares ao serviço Web. O tagged-value targetNamespace define
o namespace usado no documento WSDL. O tagged-value URI WSDL determina a
URI do serviço Web. O tagged-value WebService Documentation serve para fins de
documentação enquanto que o tagged-value servicePort especifica a porta em que o
serviço Web executará. O tagged-value endPoint determina o tipo de endPoint utilizado
para comunicação fim-a-fim com serviço Web. No perfil UML é definido um tipo
Enumeration com os valores possíveis para o endPoint. Os valores possíveis para versão
atual da ferramenta são: HttpSoap11; HttpSoap12; e Http.
Os métodos definidos na interface estereotipada por «SemanticWebService» que
representam operações dos serviço Web, são estereotipados por «SWSOperation». O
estereótipo «SWSOperation» define um nome para uma operação e especifica os inputs
e output desta operação, que podem ser definidos como classes, tipos primitivos da
linguagem Java ou então como classes da ontologia de domínio, que estão representadas
no modelo UML pelo estereótipo «owl:Class».
4.5
Importação das Ontologias OWL
No processo de importação da ontologia de domínio, um conjunto de transformações XSLT é usado. Esse conjunto de transformações transforma um documento OWL
em um documento XMI que representa um modelo UML. As transformações XSLT são
aplicadas em alguns elementos da linguagem OWL a fim de se criar um modelo UML correspondente (requisito R3). O Apêndice C traz este conjunto de transformações XSLT.
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
3 http://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 elemento packageElement do tipo uml:Class com o nome Booklet e identificador “_srVUwK60EeGyaLpUewWoVw“. A classe UML Booklet é uma generalização da classe
identificada por “_PSOQQK61EeGyaLpUewWoVw“, a classe Entry. A propriedade OWL
foi mapeada para o documento XMI como um elemento ownedAttribute com o nome
hasTitle e com valores possíveis definido como o tipo String dos tipos primitivos da UML.
Figura 4.5: Mapeamento da classe OWL em UML
4.6
Metamodelo da Linguagem OWL-S
A descrição semântica de um serviço Web associa os parâmetros de entrada
(input) e o retorno (output) das operações de um serviço Web, que estão descritos no
documento WSDL na forma de elementos message, com conceitos definidos em uma
ontologia. O modelo UML criado por intermédio da ferramenta AutoWebS para a especificação da interface do serviço Web contém informações importantes que são utilizadas
para associar os conceitos definidos em ontologias de domínio com os elementos do serviço Web.
Entretanto, apesar do modelo UML conter tais informações, a MDD propõe
a separação de conceitos arquiteturais através de níveis de abstração da arquitetura
de um sistema. Neste sentido, AutoWebS implementa um processo MDD, de forma
que a transformação do modelo UML para um arquivo OWL-S requer um modelo
intermediário, que esteja de acordo com um metamodelo para a linguagem OWL-S.
O metamodelo OWL-S implementado por este trabalho foi descrito em Ecore e
contempla a versão 1.1 da especificação OWL-S. Esta versão da especificação OWL-S
é compatível com o WSDL 1.1 (requisitos R2 e R5). A Figura 4.6 apresenta uma visão
simplificada do metamodelo para linguagem OWL-S.
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). OWLS 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 referenciadas em OWL-S. Cada instância da classe WsdlGrounding contém uma lista de instâncias de WsdlAtomicProcessGrounding. Essa relação é representada pela propriedade
hasAtomicProcessGrounding. A propriedade owlsProcess garante que para cada processo
do tipo AtomicProcess exista somente um WsdlAtomicProcessGrounding. Por outro lado
a propriedade wsdlOperation assegura uma relação um-para-um entre o AtomicProcess e
a especificação WSDL.
4.7
Implementação das Regras de Mapeamento entre
UML e OWL-S
No metamodelo OWL-S são definidos todos os elementos e relacionamentos
que podem ser encontrados nos modelos OWL-S. Na abordagem MDD implementada
pela ferramenta AutoWebS, um modelo UML, que representa a interface de um serviço
Web semântico, é a entrada para um mecanismo que produz um modelo de saída em
conformidade com o metamodelo OWL-S.
A Figura 4.7 ilustra um trecho da transformação em QVT que implementa o mapeamento entre os modelos UML e OWL-S. Esta transformação, chamada de UMLProfile2OWLS, recebe como entra um modelo da UML 2 na versão 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 elementos UML Interface do modelo de entrada. O operador QVT forEach (linha 11) faz uma
iteração sobre estes elementos e o operador QVT if (linha 12) faz uma seleção sobre os
elementos que tem o estereótipo SemanticWebService. A instrução seguinte, na linha 13,
recupera todos os elementos UML Operation - as operações do serviço Web - definidos
no elemento Interface. Ainda na mesma linha, com o operador forEach, é realizado uma
iteração sobre os elementos Operation na busca por aqueles com o estereótipo textitSWSOperation. 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 createOWLS são construídos os elementos do modelo OWL-S. O Apêndice D traz na íntegra a
implementação da transformação em QVT.
O elemento Profile do modelo OWL-S é criado a partir do valor do taggedvalue WSDL Documentation, aplicado ao elemento UML Interface e dos tagged-values do
estereótipo Category. O id do elemento Profile é formado pela concatenação do nome da
operação com a palavra Profile. Desta forma, uma operação com nome subscribe, formará
o id subscribeProfile para o elemento Profile.
Os elementos WsdlGrounding, AtomicProcess e Service do modelo OWL-S são
4.7 Implementação das Regras de Mapeamento entre UML e OWL-S
64
Figura 4.7: Transformação de UML para OWL-S
criados de forma semelhante ao elemento Profile e os valores das suas propriedades são
especificados a medida em que o elemento WsdlAtomicProcessGrounding e os parâmetros
WsdlInputMessage e WsdlOutputMessage são criados.
No elemento WsdlAtomicProcessGrounding do modelo OWL-S, o valor do seu id é formado pela concatenação do nome da operação com a palavra
AtomicProcessGrounding. O valor do atributo wsdlDocument é o valor do taggedvalue URI WSDL Document aplicado no elemento UML Interface. O valor do
atributo wsdlInputMessage é formado pela concatenação do valor do tagged-value
targetNamespace com a caractere #, com nome do serviço e com a palavra Request.
O valor do atributo wsdlOutputMessage é formado pela concatenação do valor do
tagged-value targetNamespace com o caractere #, com nome do serviço e com a palavra Response. O atributo wsdlOperation recebe uma instância de WsdlOperationRef.
No objeto WsdlOperationRef a propriedade portType é formada pela concatenação do
tagged-value URI WSDL Document, com o caractere # e com o valor do tagged-value
textitendPoint. A propriedade operation é formada pela concatenação do tagged-value
URI WSDL Document, com o caractere # e com o nome do serviço.
No elemento OWL-S wsdlAtomicGrounding são especificados os inputs e
outputs do serviço Web semântico através da associação do elemento Message Part do
documento WSDL com um conceito definido como uma classe no documento OWL. Para
os casos em que os inputs e outputs de uma operação do serviço Web não têm uma correspondência direta com os elementos da ontologia de domínio, são necessários representar
como derivar a Message Part de um ou mais inputs ou outputs do Atomic Process.
A propriedade xsltTransformation contém um script XSLT que gera o Message
Part de uma instância de um Atomic Process. O script pode ser diretamente representado
como uma string ou pode ser referenciado por um URI. A transformação QVT, que faz
o mapeamento entre o modelo UML e o modelo OWL-S, cria automaticamente o script
4.8 Funcionamento da Ferramenta
65
XSLT para os casos em que são usados elementos da ontologia de domínio importada
como input ou output para especifi cação de uma operação do serviço Web semântico.
4.8
Funcionamento da Ferramenta
O funcionamento do AutoWebS, ilustrado na Figura 4.8, compreende basicamente três principais atividades que devem realizadas sequencialmente, (i) importação da
ontologia de domínio, (ii) criação do modelo UML e (iii) geração automática do serviço
Web e sua ontologia. A primeira e a última atividade são automatizadas pela ferramenta.
O usuário precisa realizar somente a segunda atividade, a modelagem da interface do
serviço Web semântico.
Figura 4.8: Funcionamento do AutoWebS
A primeira atividade consiste na importação da ontologia de domínio (ver
Seção 4.5) para a criação de um modelo UML. Na primeira atividade a ferramenta usa
o componente ImporterModule para execução das transformações XSLT e criação do
modelo UML. Este modelo UML contém os elementos da ontologia de domínio que
podem ser usados para modelagem da interface de um serviço Web. A segunda atividade
consiste na edição do modelo UML. Na segunda atividade, o usuário pode inserir ou
remover elementos no modelo UML recém criado para modelagem da interface do serviço
Web.
A terceira atividade ocorre após a modelagem da interface do serviço Web.
Neste ponto, o AutoWebS exporta a representação gráfica do modelo UML para um
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 apresentação de sistemas de middleware de provisão de contexto, apresentando o middleware
usado no estudo de caso; a Seção 5.2 apresenta a ontologia de domínio; a Seção 5.3 apresenta o processo de modelagem do serviço Web semântico utilizando-se a ferramenta
AutoWebS; a Seção 5.4 discute os resultados e faz uma análise da execução do estudo de
caso.
5.1
Sistemas de middleware de provisão de contexto
Sistemas de middleware de provisão de contexto são soluções que oferecem uma
infraestrutura que facilita o desenvolvimento de aplicações sensíveis ao contexto em domínios diversos, através da disponibilização de mecanismos de gerenciamento dos dispositivos; modelagem, interpretação e refinamento dos dados de contexto; mecanismos de
distribuição das informações de contexto, etc. Cada plataforma de middleware de provisão de contexto utiliza um modelo para representar os dados de contexto e outro modelo
para comunicação. Existem várias abordagens para modelagem dos dados de contexto
[Strang and Popien, 2004], as mais utilizadas são: Chave-Valor; Markup Schema; Gráfico; Orientado a Objeto; Lógico; e Ontologias. Os modelos de comunicação definem a
arquitetura, como por exemplo, cliente-servidor e P2P (par-to-par), e o estilo, como por
exemplo, RCP (Remote procedure calls), SOA (Service-oriented architecture) e REST
(Representational state transfer), utilizados para oferecer os serviços do middleware sobre uma infraestrutura de rede disponível.
5.1 Sistemas de middleware de provisão de contexto
68
Entretanto, apesar de um middleware de provisão de contexto oferecer soluções que facilitam o desenvolvimento de aplicações sensíveis ao contexto, normalmente,
apenas o uso de um único middleware não é suficiente para atender os requisitos de
uma aplicação. Desta forma, devem-se utilizar serviços de várias plataformas de middleware, tornando o desenvolvimento da aplicação uma tarefa nada trivial para os engenheiros de software e programadores, pois entender os modelos utilizados para representação dos dados de contexto, bem como os modelos de comunicação adotados
por cada middleware e fazer a conversão deles para a representação adotada pela aplicação, são complexidades adicionais que devem ser evitadas. Para endereçar estes problemas, surgiram algumas iniciativas, tais como ReMMoC [Grace et al., 2003], Home
soa [Bottaro and Gérodolle, 2008] e OpenCOPI (OpenCOntext Platform Integration)
[Lopes et al., 2008, Lopes et al., 2009a, Lopes et al., 2009b], com a proposta de assegurar
a interoperabilidade e fazer a integração de sistemas de middleware.
O OpenCOPI (OpenCOntext Platform Integration) é uma plataforma que integra
diferentes sistemas de middleware de provisão de contexto e provê um serviço de contexto
unificado. O OpenCOPI fornece um mecanismo de composição semântica de serviços de
contexto, onde aplicações são clientes de serviços e sistemas de middleware de contexto
são provedores de serviços de contexto e, para prover independência de plataforma e
simplificar a integração com diferentes sistemas de middleware, o OpenCOPI é baseado
em tecnologias SOA e Web semântica. O OpenCOPI utiliza uma ontologia de domínio,
especificada em OWL e organizada em duas camadas, para representar os elementos de
contexto.
No OpenCOPI, a integração de plataformas de middleware de provisão de
contexto que não utilizam a tecnologia dos serviços Web, para prover seus serviços, ou
ontologias para representar os elementos de contexto, é feita por intermédio de drivers.
Os drivers implementam as funcionalidades relacionadas a abstração dos modelos de
comunicação e a conversão dos modelos de contexto, adotados pelos sistemas de
middleware, para os modelos utilizados pelo OpenCOPI. A Figura 5.1 ilustra a arquitetura
do OpenCOPI. Nesta arquitetura, os drivers podem ser vistos sob dois diferentes pontos
de vista: (i) sob o ponto de vista do OpenCOPI e de seu mecanismo de composição e
execução de serviços, os drivers representam um proxy para os sistemas de middleware
subjacentes, sendo responsáveis por repassar as requisições das aplicações aos serviços;
(ii) sob o ponto de vista do middleware subjacente, um driver nada mais é do que um
cliente do middleware.
Os componentes da camada UnderlayIntegrationLayer são responsáveis pela
integração dos sistemas de middleware subjacentes. O driver é responsável por realizar
as consultas e subscrições realizadas pelo OpenCOPI aos middleware de provisão de
contexto subjacentes. Cada driver precisa estender o componente GenericDriver. Esse
5.2 Ontologia de Domínio
Figura 5.1: Arquitetura do OpenCOPI
[Lopes et al., 2009b]
69
-
extraído
de
componente implementa a interface do lado do OpenCOPI e define as operações para a
transformação do modelo de contexto e a comunicação entre OpenCOPI e um middleware
específico [Lopes et al., 2009b].
Entretanto, a criação de um driver é um processo que requer um profundo
conhecimento da API do middleware de provisão de contexto e necessita da recompilação
do OpenCOPI, pois o driver é um componente de software embutido. Além disso,
não existe um padrão ou metodologia bem definida para sua criação. Ademais, as
transformações implementadas em um driver para adequação dos elementos de contexto
entre middleware-OpenCOPI, normalmente não podem ser reaproveitadas para criação de
outros drivers.
Neste estudo de caso usamos a ferramenta AutoWebS para a modelagem e geração automática de serviços Web semânticos para os serviços de sistemas de middleware de
provisão de contexto não baseados em serviços Web e/ou que não utilizam ontologias para
representação dos elementos de contexto. Desta forma, conforme ilustrado na Figura 5.1,
os serviços Web semânticos gerados para os serviços fornecidos por cada middleware de
contexto substituem os drivers e toda complexidade envolvida na sua construção.
5.2
Ontologia de Domínio
O estudo de caso utiliza uma ontologia, chamada de OilExploration, que descreve os conceitos do domínio da indústria de Petróleo. Esses conceitos, ilustrados na
Figura 5.2, são usados como inputs e outputs para os vários serviços que possam estar
relacionados a este domínio. Todos os conceitos desta ontologia foram especificados em
um arquivo OWL.
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, assincronamente, fornece o valor atual da carga de petróleo (burden) em cada UB. O serviço
WellDatabase abstrai um widget do framework Context Toolkit (CT) [Dey et al., 2001]. O
framework CT é um middleware de provisão de contexto que utiliza um modelo de comunicação não baseado nas tecnologias dos serviços Web, porém baseado em um protocolo
XML transportado por HTTP. Esse widget monitora o funcionamento da UB e representa
os elementos de contexto no formato chave-valor.
Desta forma, para o serviço WellDataBase, faz-se necessário a conversão do
modelo de contexto de chave-valor para ontologia e do modelo de comunicação HTTP
para serviços Web. A próxima seção apresenta como procedemos a modelagem e geração
do serviço Web semântico para o serviço WellDataBase.
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 realizar a segunda atividade. Neste estudo de caso, criamos a interface WellDatabase e
aplicamos o estereótipo «semanticWebService». Nesta interface definimos o método
subscribeBurdenAssyncService e aplicamos o estereótipo «SWSOperation». Este método
recebe como parâmetros de entrada (input) os tipos OilWell e PumpUnit, ambos classes
do modelo UML estereotipados por «owl:Class». O retorno do método (output) é uma
classe do tipo Regime, que também foi importada da ontologia de domínio.
Na terceira atividade, após modelado a interface do serviço Web, acionamos na
ferramenta AutoWebS o mecanismo de geração automática do arquivo OWL-S e esqueleto de código fonte do serviço Web. A Figura 5.6 ilustra os artefatos de código gerados
automaticamente pela ferramenta. O arquivo WellDatabase.wsdl contém o documento
WSDL do serviço Web. O descritor de deploy, services.xml, contém a configuração de
execução do serviço Web. A classe Java WellDatabaseMessageReceiverInOut.java
é responsável pela comunicação fim-a-fim do serviço Web com os clientes, enquanto que
as classes Java WellDatabaseSkeleton.java e WellDatabaseStub.java são, respec-
5.3 Modelagem do Serviço Web Semântico
73
tivamente, o skeleton e stub e implementam o protocolo SOAP utilizado para transmissão
das mensagens entre servidor e cliente. O arquivo build.xml descreve o processo de
construção (build) e as dependências do serviço Web. Todos os artefatos foram incluídos
em um projeto Java para plataforma Eclipse.
Figura 5.6: Artefatos de códigos gerados
A quarta atividade consistiu da implementação das regras de negócio do
serviço Web. Nesta atividade foram implementadas as chamadas à API do serviço
WellDatabase, implementado com o framework CT. A Figura 5.7 ilustra o trecho de
código da operação subscribeBurdenAssyncService do serviço Web. No método Java
subscribeBurdenAssyncService são realizadas a conexão ao serviço WellDataBase implementado com CT, a subscrição ao serviço de notificação e o tratamento dos dados
recebidos pelo serviço WellDataBase implementado com o CT. Conforme a Figura 5.7,
os tratamentos dos dados são realizados pelo método getRegime. Neste método, o retorno
que está no formato chave-valor, é convertido para um objeto Regime.
Após ter implementado as regras de negócio do serviço Web, usamos as funcionalidades de compilação e deploy. O projeto Java Eclipse foi compilado utilizando o
script build.xml do Apache Ant. O resultado da compilação é um arquivo com a extensão aar que contém o código fonte do serviço Web e a implementação do protocolo
SOAP, no lado servidor, fornecida pelo Axis2. O processo de deploy é bastante simples.
No deploy, a ferramenta faz uma cópia do arquivo com a extensão aar para no contêiner
Web que tenha instalado o Axis2 Runtime.
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ãoparamétrico de Wilcoxon [Corder and Foreman, 2009].
O restante deste capítulo está estruturado com se segue: A Seção 6.1 apresenta
as ferramentas escolhidas para realização do experimento controlado; a Seção 6.2 apresenta os projetos dos serviços Web semânticos usados na condução do experimento; a
Seção 6.3 descreve o planejamento do experimento; a Seção 6.4 apresenta a execução do
experimento; a Seção 6.5 relata as análises e interpretações dos dados obtidos da execução
do experimento.
6.1 Ferramentas Avaliadas
6.1
77
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 semânticos que foram implementados usando-se o AutoWebS e a suíte de aplicativos. O
projeto de um serviço Web semântico (ou especificação) forne uma descrição textual da
interface do serviço Web e dos conceitos usados nas ontologias OWL para descreve-lo
semanticamente. Para cada projeto são apresentadas as ontologias e a especificação da
interface do serviço Web, detalhando seus inputs, outputs e preconditions, quando existirem. Dentre os projetos usados no experimento controlado, apresentados em seguida, os
dois primeiros projetos usam a ontologia de domínio OilExploration, desenvolvida para
estudos de caso da plataforma OpenCOPI (ver Seção 5). Os demais projetos usam ontologias públicas e de livre acesso, contidas nos exemplos da API OWL-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.
1 http://axis.apache.org/axis2/java/core/
2 http://www.mindswap.org/2004/owl-s/services.shtml
6.2 Projetos de Serviços Web Semânticos
6.2.2
78
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 outra língua. Neste serviço, a operação getTranslation recebe como entrada dois
parâmetros, o texto a ser traduzido, codificado como um String, e um elemento
SupportedLanguage da ontologia BabelFishTranslator, que representa a língua
do texto de entrada e a língua saída desejada. O retorna desta operação é a
palavra traduzida codificada como String e um elemento SupportedLanguage
da ontologia BabelFishTranslator. Neste serviço há um total de nove idiomas
suportados pelo tradutor. A precondição do serviço, o elemento precondition
SupportedLanguagePair definido na ontologia BabelFishTranslator, requer que o
idioma de entrada e o idioma de saída sejam diferentes.
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 definidos os objetivos ou metas (Goals) a serem alcançados com o experimento. Em uma
segunda etapa, são formuladas questões (Questions) que devem ser respondidas para
alcançar os objetivos traçados. Por fim, as métricas (Metrics) são estabelecidas para
tornar possível mensurar as questões levantadas.
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 ferramenta proporciona a menor quantidade de tempo para criação da descrição semântica de um serviço Web?
M4.1 Cronometrar o tempo total para a criação dos serviços Web semânticos.
Q5 Qual das duas ferramentas necessita de um menor esforço despendido para criação
da ontologia de serviços Web?
M5.1 Avaliação subjetiva.
M5.2 Quantidade de problemas reportados.
Sobre o uso da ferramenta
Q6 A abordagem proposta pelo AutoWebS na utilização de UML para a modelagem
de serviços Web semânticos é mais intuitiva do que a abordagem tradicional,
empregada pela ferramenta OWL-S Editor?
M6.1 Avaliação subjetiva.
Q7 A abordagem MDD empregada pela ferramenta AutoWebS é satisfatória do ponto de
vista do usuário?
M7.1 Avaliação subjetiva do usuário.
Q8 A integração das funcionalidades para o desenvolvimento de um serviço Web semântico em uma ferramenta contribui positivamente?
M8.1 Avaliação subjetiva do usuário.
6.3 Planejamento do Experimento
6.3.3
82
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 levantadas. Neste estudo foram definidas as seguintes variáveis dependentes:
1. Quantidade total de erros ou inconsistências no arquivo OWL-S
2. Tempo total para criação dos serviços Web semântico.
3. Satisfação subjetiva do usuário.
A quantidade total de erros ou inconsistências no arquivo OWL-S diz respeito à completude da ontologia OWL-S criada pela ferramenta. Em alguns casos como, por exemplo, quando se necessita de transformações XSLT, algumas ferramentas não criam esses
scripts automaticamente. A variável satisfação subjetiva é medida através de um questionário aplicado após a execução do experimento.
Variáveis Controladas
Dois principais fatores podem afetar a condução do experimento. Duas variáveis
controladas minimizam os efeitos destes fatores no experimento controlado.
1. Complexidade do projeto do serviço Web
2. Nível de conhecimento do participante sobre as tecnologias dos serviços Web
semânticos
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 treinamento teve como objetivo apresentar noções básicas a respeito de cada ferramenta e as
linguagens a fim de nivelar o conhecimento dos indivíduos.
6.4 Operação do Experimento
6.3.6
84
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 conhecimentos básicos a respeito das tecnologias de serviços Web semânticos e conhecem
as principais construções das linguagens OWL e OWL-S, além de dominar a linguagem para modelagem UML. Assim, assume-se que eles são representativos para
a população dos desenvolvedores de serviços Web. Para redução da influência dos
fatores que não são interesse do nosso estudo e, portanto, para aumento da validade
interna do estudo usou-se os dados do questionário do perfil do participante (ver
Seção 6.4.2) para escolha dos participantes que compartilham as mesmas características.
Validade de Conclusão: são aplicados questionários de análise subjetiva sobre as ferramentas. Também, será realizado um teste estatístico dos resultados.
Validade de Construção: o plano experimental e quantidade de participantes e réplicas
são fatores importantes que podem ameaçar a validade deste experimento. Entretanto, adequamos este experimento a nossa realidade e não generalizaremos os resultados.
Validade Externa: os projetos usados no experimento são representativos e amplamente
usados na literatura. A suíte de aplicativos também é amplamente usada pela
comunidade de desenvolvedores de serviços Web semânticos.
6.4
6.4.1
Operação do Experimento
Plano Experimental
Utilizamos o plano experimental Quadrados Latinos (ver Apêndice F), pois existem dois fatores de ruído com influência significante na variável de saída: (i) experiência
do usuário com uso das tecnologias dos serviços Web e a (ii) complexidade dos projetos
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.
Projeto k
Projeto l
Pessoa m
Ferramenta a
Ferramenta b
Pessoa n
Ferramenta b
Ferramenta a
Tabela 6.1: Distribuição dos Blocos
Na Tabela 6.1 m, n, a e b podem assumir os valores 1 ou 2 sendo que a é diferente
de b, m é diferente de n. Já k e l podem assumir os valores entre 1 e 8 e k é diferente de l.
O experimento tem quatro réplicas do quadrado, alternando-se as linhas (Projetos), totalizando oito observações ou repetições. Para definição das configurações de cada
réplica foram realizados sorteios que definiram a ordem dos projetos, pessoas e ferramentas. Para o sorteio usamos a função 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:
Serviço Web Semântico BabelFish Translator
Serviço Web Semântico Book Finder
Pessoa 1
Ferramenta 1 (2)
Ferramenta 2 (1)
Pessoa 2
Ferramenta 2 (1)
Ferramenta 1(2)
Tabela 6.2: Réplica l
Serviço Web Semântico OilMonitor 2
Serviço Web Semântico Barnes and Nobles Price
Pessoa 1
Ferramenta 1 (2)
Ferramenta 2 (1)
Pessoa 2
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
3 http://blog.revolutionanalytics.com/2009/02/how-to-choose-a-random-number-in-r.html
6.5 Análise e Interpretação dos Resultados
Serviço Web Semântico OilMonitor 1
Serviço Web Semântico Zip Code Finder
86
Pessoa 1
Ferramenta 2 (1)
Ferramenta 1 (2)
Pessoa 2
Ferramenta 1 (2)
Ferramenta 2(1)
Tabela 6.4: Réplica 3
Serviço Web Semântico Currency Converter
Serviço Web Semântico Zip Code Finder
Pessoa 1
Ferramenta 1 (1)
Ferramenta 2 (2)
Pessoa 2
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 Projeto do Serviço Web
Este questionário tem como objetivo descobrir as opiniões dos participantes a
respeito das ferramentas usadas no desenvolvimento de cada projeto do experimento
controlado. Este questionário foi aplicado no término de cada desenvolvimento de projeto.
O questionário para análise subjetiva encontra-se no Apêndice E.2.
6.5
6.5.1
Análise e Interpretação dos Resultados
Apresentação dos Resultados
A Tabela 6.6 apresenta os tempos necessários para o desenvolvimento de cada
projeto de serviço Web semântico e a quantidade de erros ou inconsistências na ontologia
de cada serviço Web.
As ontologias dos serviços Web criadas pela ferramenta AutoWebS não apresentaram erros, exceto o serviço Web semântico BabelFish Translator que tem uma
única operação que retorna uma palavra traduzida codificada como String e um elemento
SupportedLanguage da ontologia BabelFishTranslator. Especificamente no serviço Web
6.5 Análise e Interpretação dos Resultados
Projeto
Serviço Web semântico OilMonitor 1
Serviço Web semântico OilMonitor 2
Serviço Web semântico Book Finder
Serviço Web semântico Zip Code Finder
Serviço Web semântico Latitude Longitude Finder
Serviço Web semântico Barnes and Nobles
Serviço Web semântico BabelFish Translator
Serviço Web semântico Currency Converter
87
AutoWebS
tempo erros
12
0
8
0
20
0
5
0
8
0
5
0
15
1
5
0
Suíte
tempo erros
35
1
55
1
35
1
21
1
25
1
20
1
45
1
14
1
Tabela 6.6: Resultados obtidos na execução do experimento controlado
semântico BabelFish Translator foi necessário realizar uma única adaptação na ontologia
do serviço Web, pois o AutoWebS não criou automaticamente o script XSLT para propriedade xsltTransformation. O participante do experimento modelou o retorno do serviço Web como um objeto de uma classe Retorno. Esta classe Retorno encapsula uma
String e o elemento SupportedLanguage da ontologia BabelFishTranslator. Entretanto,
o AutoWebS não cria scripts XSLT para elementos usados nos modelos UML que não
foram importados de uma ontologia de domínio, ou seja, o AutoWebS só cria os scripts
XLT para os elementos que tenham o estereótipo owl:Class.
Em todas as ontologias dos serviços Web criadas pela suíte de aplicativos Axis2
+ OWL-S Editor foram constatados erros ou inconsistências. Nas ontologias foram necessárias adaptações no script XSLT da propriedade xsltTransformation. O processo de
criação das transformações XSLT, mesmo para elementos simples, é suscetível a erros e
quando se usa o Axis2 para criar um serviço Web, sem se especificar configurações adicionais na execução de seus utilitários (wsdl2java e java2wsdl), são gerados namespaces
aleatórios no documento WSDL. Por exemplo, no serviço Web OilMonitor 1 foi gerado
o namespace ax22 enquanto que no serviço Web OilMonitor 2 foi gerado o namespace
ax210.
A Figura 6.1 ilustra o histograma do tempo consumido pelos participantes do
experimento para o desenvolvimento de cada serviço Web semântico. Podemos perceber
uma diferença entre os tempos quando foi usado o AutoWebS e a suíte de aplicativos
para o desenvolvimento dos serviços Web semânticos. Em todos os casos o tempo de
desenvolvimento usando-se o AutoWebS foi inferior ao tempo quando usada à suíte de
aplicativos.
O menor tempo obtido utilizando-se a ferramenta AutoWebS foi de 5 minutos
para o serviço Web semântico Zip Code Finder. O mesmo serviço com a suíte de
aplicativos demandou 21 minutos para ser desenvolvido, uma diferença de 16 minutas em
relação ao AutoWebS. O maior tempo obtido utilizando-se a ferramenta AutoWebS foi de
6.5 Análise e Interpretação dos Resultados
88
Figura 6.1: Tempo de desenvolvimento dos serviços Web semânticos
20 minutos para o serviço Web semântico Book Finder enquanto que este mesmo serviço,
quando desenvolvido com a suíte de aplicativos, demandou 35 minutos, uma diferença de
15 minutos.
A Amplitude máxima dos tempos quando usada a ferramenta AutoWebS foi de
15 minutos para os serviços Web semânticos ZipCode e BookFinder. A Mediana foi
de 8 minutos, a Média aritmética aproximadamente 10 minutos, o Desvio padrão foi
de 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ãoparamétrico chamado método de Wilcoxon [Corder and Foreman, 2009].
A Tabela 6.7 traz a distribuição dos tempos de desenvolvimento dos serviços
Web semânticos e os cálculos do teste estatístico de Wilcoxon. Designamos 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
OilMonitor1
OilMonitor2
BookFinder
ZipCode
LatLong
BarnesAndNobles
BabelFish
Currency
AutoWebS
12
8
20
5
8
5
15
5
89
Suíte
35
55
35
21
25
20
45
14
Diff
23
47
15
16
17
15
30
9
Sinal
+
+
+
+
+
+
+
+
Posto
3
1
6.5
5
4
6.5
2
8
Posto*Diff
3
1
6.5
5
4
6.5
2
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 aplicados no término da execução de cada projeto de serviço Web semântico.
A Figura 6.3 ilustra o grau de cansaço dos participantes durante o desenvolvimento dos serviços Web semânticos. Percebe-se que, quando foi usado o AutoWebS, em
7 casos os usuários assinalaram Sem Cansaço e em apena um caso foi assinalado como
Normal o grau de cansaço. Quando usada a suíte de aplicativos, em quatro oportunidades os participantes avaliaram como Muito Cansativo, em três como Cansativo e em uma
oportunidade como Normal o grau de cansaço.
Figura 6.3: Grau de cansaço no desenvolvimento dos serviços Web
semânticos
Em relação ao grau de contribuição da ferramenta para o desenvolvimento do
serviço Web semântico, ilustrado na Figura 6.4, os participantes assinalaram em sete
oportunidades que a ferramenta AutoWebS Contribuiu Muito e em uma oportunidade que
a ferramenta AutoWebS teve uma contribuição Normal. Com a suíte de aplicativos em
quatro oportunidades os participantes julgaram que os aplicativos Contribuíram Pouco,
em duas oportunidades Não Contribuíram e em outras duas teve uma contribuição
Normal.
Quando perguntados sobre o grau de dificuldade na criação dos serviços Web,
os participantes responderam que quando foi usada a ferramenta AutoWebS em todos
os casos foi Muito Fácil criar o serviço Web. Entretanto, quando foi usada a suíte de
aplicativos os participantes responderam que em três ocasiões foi Difícil criar o serviço
Web, em outras três ocasiões foi Normal o grau de dificuldade enquanto que em outras
6.5 Análise e Interpretação dos Resultados
91
Figura 6.4: Grau de contribuição da ferramenta para o desenvolvimento dos serviços Web semânticos
duas ocasiões foi Fácil. A Figura 6.5 ilustra as respostas dos participantes sobre o grau de
dificuldade na criação dos serviços Web.
Figura 6.5: Grau de dificuldade em criar o serviço Web
Para a criação da ontologia do serviço Web os participantes assinalaram que com
a ferramenta AutoWebS em todos os casos foi Muito Fácil criar a ontologia, conforme
ilustra a Figura 6.6. Porém, com a suíte de aplicativos em quatro oportunidades os usuários
marcaram no questionário Muito Difícil, em três Difícil e em uma Fácil.
Quando perguntados se os recursos oferecidos pelas ferramentas foram suficientes para o desenvolvimento dos serviços Web semânticos, os participantes responderam
que em todos os projetos os recursos do AutoWebS foram suficientes. Enquanto que,
quando usada a suíte de aplicativos, em quatro projetos de serviços Web semânticos os
recursos não foram suficientes. A Figura 6.7 apresenta as respostas dos participantes a
respeitos dos recursos oferecidos pelas ferramentas avaliadas.
Em relação à opinião dos participantes se a abordagem implementada pela ferramenta contribuiu para o desenvolvimento dos projetos de serviços Web semânticos, os
participantes responderam que em todos os casos o AutoWebS contribuiu positivamente.
Entretanto, em apenas uma oportunidade os participantes afirmaram que a abordagem
6.5 Análise e Interpretação dos Resultados
92
Figura 6.6: Grau de dificuldade em criar a ontologia do serviço
Web
Figura 6.7: Recursos oferecidos pelas ferramentas avaliadas
usada pela suíte de aplicativos contribuiu positivamente para o desenvolvimento do projeto de serviço Web semântico. A Figura 6.8 apresenta as respostas dos participantes.
Pelos resultados das análises efetuadas constatou-se que estatisticamente existe
uma diferença significativa na utilização das ferramentas. Assim, existem indícios de que
o AutoWebS contribui positivamente para o desenvolvimento de serviços Web semânticos, uma vez que proporciona menos cansaço e torna a criação do serviço Web e da
ontologia do serviço Web menos difíceis, comparando-se com a suíte de aplicativos.
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 semânticos utilizando a ferramenta AutoWebS é menor do que quando utilizado a suíte de
aplicativos”) pode ser verificada com a resposta da questão Q4 através da métrica M4.1
(tempo total para criação dos serviços Web semânticos). A partir dos dados da Tabela 6.6
podemos concluir que o tempo total para o desenvolvimento (métrica M4.1) dos projetos de serviços Web semânticos quando usada a ferramenta AutoWebS foi menor do que
quando usada a suíte de aplicativos. Portanto, não podemos rejeitar a hipótese alternativa
H2, mas podemos rejeitar a hipótese nula 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 necessárias para criação de serviços Web semânticos contribui significativamente para o seu
desenvolvimento“) usamos as respostas das questões Q5 e Q8 através das métricas M5.1,
M5.2 e M8.1. Conforme análise do grau de contribuição da ferramenta para o desenvolvimento dos serviços Web semânticos, isto é, da criação do serviço Web e da sua ontologia,
além do cansaço e esforço despendido, nos gráficos das Figuras 6.5, 6.6 e 6.3, observamos
que a integração das funcionalidades necessárias para criação de serviços Web semânticos
contribui positivamente para o seu desenvolvimento. Assim, sustentamos a hipótese H3 e
rejeitamos a hipótese nula 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 serviços Web semânticos. Entretanto, para se fazer uma comparação com a ferramenta
AutoWebS, selecionamos alguns principais trabalhos que apresentam abordagens para a
criação de serviços Web semânticos (serviços Web semânticos atômicos). Outros aspectos
dos serviços Web semânticos como, por exemplo, descoberta e composição de serviços
Web e similaridade semântica, fogem do escopo deste trabalho e, portanto, não são alvos
de estudo e comparação com a ferramenta proposta.
Este capítulo está estruturado como se segue. A Seção 7.1 apresenta a ferramenta
OWL-S Editor. A Seção 7.2 apresenta a ferramenta CODE. A Seção 7.3 apresenta
a ferramenta ASSAM. A Seção 7.4 apresenta a abordagem desenvolvida por Yang e
Chung. A Seção 7.5 apresenta a abordagem criada por Kim e Lee. Por fim, a Seção 7.6
apresenta uma comparação entre os trabalhos relacionados e o AutoWebS, levando-se em
consideração os requisitos para uma ferramenta de alto nível de abstração para a criação
de serviços Web semântico levantados na introdução deste trabalho.
7.1
OWL-S Editor
OWL-S Editor [Elenius et al., 2005] é uma ferramenta integrada ao software
Protégé - o principal software para criação de ontologias. OWL-S Editor foi desenvolvido
como um plugin do Protégé e sua principal característica é proporcionar em um mesmo
ambiente, utilitários para a criação de uma ontologia de domínio e, também, para o
desenvolvimento da descrição semântica do serviço Web.
A ferramenta OWL-S Editor proporciona somente a criação da ontologia do
serviço Web a partir de um conjunto de visões (views), cada visão para uma subontologia
OWL-S. Cada visão fornece um conjunto de campos para inserção de valores para os
elementos da subontologia associada, conforme a Figura 7.1 ilustra. As visões requerem
do usuário um profundo conhecimento a respeito da linguagem OWL-S.
A visão associada à subontologia Service Model utiliza um editor visual do
tipo drag-and-drop para criar processos Composite utilizando as estruturas de controle
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.
1 http://semwebcentral.org/projects/wsdl2owl-s/
7.2 CODE - CMU’s OWL-S Development Environment
7.2
97
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 linguagem 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 esqueletos 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 (JAXRPC) para as mensagens, enquanto que o Axis2 também usa o estilo Document (JAXWS). 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 documentos 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 combinaçã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 ontologias 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, consiste 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 limitam 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 ferramenta 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 Tabela 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.
OWL-S Editor
CODE
ASSAM
Yang e Chung
Kim e Lee
AutoWebS
R0
não
sim
não
sim
sim
sim
R1
não
sim
não
não
não
sim
R2
sim
sim
sim
sim
sim
sim
R3
sim
não
sim
não
sim
sim
Requisitos
R4
R5
não
sim
parcialmente parcialmente
não
sim
não
sim
não
parcialmente
sim
sim
R6
parcialmente
sim
não
parcialmente
parcialmente
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 subontologias ServiceProfile e ServiceModel, dessa forma atendendo apenas parcialmente o requisito 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 modelagem 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 preocupando 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 documentos XMI que representam os modelos UML não são compatíveis com outras ferramentas 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 funcionalidades (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 ontologia 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 integra 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 parcialmente, 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 contribuiçõ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ântica 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 é difí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 especificaçã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 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.
Apresentada a fundamentação teórica do trabalho, em seguida iniciou-se a apresentaçã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 questã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ânticos. Ao longo do Capítulo 4 foram apresentadas a arquitetura da ferramenta, explicitando 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 artefatos de códigos gerados pela ferramenta AutoWebS, comparar os tempos de desenvolvimento de serviços Web semânticos obtidos pela ferramenta AutoWebS e pela suíte de aplicativos, 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 integraçã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 controlado 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 serviç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 incompletude 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 implementação de um perfil UML cuja finalidade é permitir a representação de alguns elementos 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 ontologia 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
8.2
108
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 definidos 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 evidenciado 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. Entretanto esta adequação não tira a validade do experimento controlado e a análise estatí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 diagrama 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 implementaçã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, atualmente 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 serviç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.
1 http://metro.java.net
2 http://static.springsource.org/spring-ws/sites/2.0/
3 http://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 MetaModelling (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 statistics: 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 description, 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 Statistics 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&#8482; 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).
message service 1.0.
Soap over java
World Wide Web Consortium, Working Draft WD-soapjms-
20081121.
[Elenius et al., 2005] Elenius, D., Denker, G., Martin, D., Gilham, F., Khouri, J., and Senanayake, 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 Enterprise 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&#39;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
[Kim and Lee, 2009] Kim, I.-W. and Lee, K.-H. (2009).
114
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 Proceedings 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).
Development 101: A Guide to Creating Your First Ontology.
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 Facility (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 Facility (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 definition metamodel (omg) version 1.0. Technical Report formal/2009-05-01, Object Management 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 Stojanovic, 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-0548, 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).
edition.
Addison-Wesley Professional, 2
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: principles, methods, and applications. Knowledge Engineering Review, 11(2):93–155.
[Wikipedia, 2011] Wikipedia (2011). Web service — Wikipedia, the free encyclopedia.
[Online; Ão ltimo 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 formatação de documentos XML. XSL é utilizada para criar estilos (stylesheets) para documentos 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:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
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
<?xml version=’1.0’ encoding=’utf-8’?>
2
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
3
4
5
<soapenv:Body>
<ns:subscribeBurdenAssyncServiceResponse xmlns:ns="http://service/xsd">
<ns:return xmlns:ax29="http://model/xsd"
6
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
7
xsi:type="ax29:Regime">
8
<ax29:burden>0</ax29:burden>
9
<ax29:cpm xsi:nil="true" />
10
<ax29:idRegime xsi:nil="true" />
11
<ax29:stemSize xsi:nil="true" />
12
13
</ns:return>
</ns:subscribeBurdenAssyncServiceResponse>
14
</soapenv:Body>
15
</soapenv:Envelope>
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
<xsl:stylesheet version="1.0"
2
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
3
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4
xmlns:tns1="http://service/xsd"
5
xmlns:tns2="http://model/xsd">
6
<xsl:template match="/">
7
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
8
xmlns:j.0="http://www.example.org/owls/OilMonitor.owl#">
9
<xsl:variable name="x" select="tns1:return" />
10
11
12
13
14
<xsl:element name="j.0:Regime">
<xsl:element name="j.0:idRegime">
<xsl:attribute name="rdf:datatype">
http://www.w3.org/2001/XMLSchema#string</xsl:attribute>
<xsl:value-of select="$x/tns2:idRegime" />
15
</xsl:element>
16
<xsl:element name="j.0:burdenValue">
17
<xsl:attribute name="rdf:datatype">
18
http://www.w3.org/2001/XMLSchema#string</xsl:attribute>
19
<xsl:value-of select="$x/tns2:burden" />
20
</xsl:element>
21
<xsl:element name="j.0:cpmValue">
22
23
24
<xsl:attribute name="rdf:datatype">
http://www.w3.org/2001/XMLSchema#string</xsl:attribute>
<xsl:value-of select="$x/tns2:cpm" />
25
</xsl:element>
26
<xsl:element name="j.0:stemSize">
27
28
29
30
31
32
33
34
<xsl:attribute name="rdf:datatype">
http://www.w3.org/2001/XMLSchema#string</xsl:attribute>
<xsl:value-of select="$x/tns2:stemSize" />
</xsl:element>
</xsl:element>
</rdf:RDF>
</xsl:template>
</xsl:stylesheet>
No documento XSLT a declaração <xsl:template match="/» instrui o processador XSLT
a executar este template no elemento root da árvore do documento XML. O texto que
precede a declaração do template:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
Apêndice A
122
xmlns:j.0="http://www.example.org/owls/OilMonitor.owl#">
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, <xsl:variable/> 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 <xsl:element> 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 é definido 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 stemSize. 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
2
3
4
5
6
7
8
9
10
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:j.0="http://www.example.org/owls/OilMonitor.owl#">
<j.0:Regime>
<j.0:idRegime rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
</j.0:idRegime>
<j.0:burdenValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
0</j.0:burdenValue>
<j.0:cpmValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
</j.0:cpmValue>
<j.0:stemSize rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
11
</j.0:stemSize>
12
</j.0:Regime>
13
</rdf:RDF>
APÊNDICE B
Tecnologias dos serviços Web
B.1
SOAP
SOAP (Simple Object Access Protocol) [Mitra, 2003] é o protocolo de comunicaçã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 elementos:
• 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 autenticaçã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:
<?xml version=’1.0’ encoding=’utf-8’?>
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.
1 Plain
interface
Old Java Object - um objeto Java que contém apenas atributos e não implementa nenhuma
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
<?xml version=’1.0’ encoding=’utf-8’?>
8
<soapenv:Envelope
9
10
11
12
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns:subscribeBurdenAssyncServiceResponse xmlns:ns="http://service/xsd">
<ns:return xmlns:ax29="http://model/xsd"
13
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
14
xsi:type="ax29:Regime">
15
<ax29:burden>0</ax29:burden>
16
<ax29:cpm xsi:nil="true" />
17
<ax29:idRegime xsi:nil="true" />
18
<ax29:stemSize xsi:nil="true" />
19
20
</ns:return>
</ns:subscribeBurdenAssyncServiceResponse>
21
</soapenv:Body>
22
</soapenv:Envelope>
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 namespaces 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 concluir 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
<?xml version="1.0" encoding="UTF-8"?>
13
<soapenv:Envelope
14
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
15
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
16
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
17
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
18
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
19
20
<soapenv:Body>
<subscribeBurdenAssyncService xmlns="http://service/xsd" />
21
</soapenv:Body>
22
</soapenv:Envelope>
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 namespace 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
<wsdl:types>
3
4
<xs:schema xmlns:ax210="http://model/xsd" attributeFormDefault="qualified"
elementFormDefault="qualified" targetNamespace="http://service/xsd">
<xs:element name="subscribeBurdenAssyncService">
5
<xs:complexType>
6
<xs:sequence>
7
<xs:element minOccurs="0" name="well" nillable="true"
8
9
type="ax210:OilWell"/>
<xs:element minOccurs="0" name="unit" nillable="true"
10
11
type="ax210:PumpUnit"/>
</xs:sequence>
12
</xs:complexType>
13
</xs:element>
14
15
</xs:schema>
16
...
17
</wsdl:types>
18
...
Os parâmetros OilWell e PumpUnit de subscribeBurdenAssyncService podem assumir 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 OpenCOPI [Lopes et al., 2008, Lopes et al., 2009a, Lopes et al., 2009b] que utiliza a linguagem 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/operaçã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 requisiçã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 documento WSDL para o serviço Web subscribeBurdenAssyncService. O elemento message
subscribeBurdenAssyncServiceRequest é composto por um elemento part que está definido 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
...
<wsdl:message name="subscribeBurdenAssyncServiceRequest">
<wsdl:part name="parameters" element="ns:subscribeBurdenAssyncService"/>
</wsdl:message>
<wsdl:message name="subscribeBurdenAssyncServiceResponse">
<wsdl:part name="parameters" element="ns:subscribeBurdenAssyncServiceResponse"/>
</wsdl:message>
...
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
5
6
7
8
9
10
...
<wsdl:portType name="WellDatabasePortType">
<wsdl:operation name="subscribeBurdenAssyncService">
<wsdl:input message="axis2:subscribeBurdenAssyncServiceRequest"
wsaw:Action="urn:subscribeBurdenAssyncService"/>
<wsdl:output message="axis2:subscribeBurdenAssyncServiceResponse"
wsaw:Action="urn:subscribeBurdenAssyncServiceResponse"/>
</wsdl:operation>
</wsdl:portType>
...
11
O elemento binding tem dois atributos, name e type. O atributo name define o nome do binding, neste caso WellDatabaseSoap11Binding, enquanto que o atributo 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 mensagens 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
<wsdl:binding name="WellDatabaseSoap11Binding" type="axis2:WellDatabasePortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
3
4
style="document"/>
<wsdl:operation name="subscribeBurdenAssyncService">
5
<soap:operation soapAction="urn:subscribeBurdenAssyncService"
6
7
style="document"/>
<wsdl:input>
8
<soap:body use="literal"/>
9
10
</wsdl:input>
11
<wsdl:output>
<soap:body use="literal"/>
12
</wsdl:output>
13
</wsdl:operation>
14
15
</wsdl:binding>
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 semanticamente 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 à utilizaçã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 <?xml version="1.0" encoding="UTF-8"?>
2 <xsl:stylesheet version="1.0"
3
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
4
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
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
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
10
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
11
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
12
xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"
13
exclude-result-prefixes="owl dc rdf rdfs"
14
xmlns="http://schema.omg.org/spec/XMI/2.1">
15
<xsl:output method="xml" version="1.0" encoding="UTF-8"
16
17
18
indent="yes" />
<xsl:template match="/">
<xsl:apply-templates select="rdf:RDF" />
19
</xsl:template>
20
<xsl:template match="rdf:RDF">
21
<xmi:XMI>
22
<xsl:attribute name="xmi:version">2.1</xsl:attribute>
23
<xsl:attribute name="xsi:schemaLocation">http:///schemas/Profile/
_AUjdELDkEeGj6oQuqPBRyw/30 ../br.ufrn.consiste.owls.uml.profile/
AutoWebS_UMLProfile.profile.uml#_AUkrMLDkEeGj6oQuqPBRyw</xsl:attribute>
24
25
<uml:Model xmi.id="{generate-id()}" name="Model">
<!-- <xsl:attribute name="xmi:id"><xsl:value-of select="generate-id()"></xsl
:value-of></xsl:attribute>
26
<xsl:attribute name="name">Model</xsl:attribute> -->
27
<packageImport xmi:id="_WRKiwcPGEeGmicizUa5VyA">
Apêndice C
28
134
<importedPackage xmi:type="uml:Model" href="pathmap://UML_LIBRARIES/
UMLPrimitiveTypes.library.uml#_0"/>
29
</packageImport>
30
<xsl:apply-templates select="owl:Ontology">
31
</xsl:apply-templates>
32
<profileApplication xmi:id="_aS-yYMPGEeGmicizUa5VyA">
33
<eAnnotations xmi:id="_aTiMAMPGEeGmicizUa5VyA" source="http://www.eclipse
.org/uml2/2.0.0/UML">
34
<references xmi:type="ecore:EPackage" href="../br.ufrn.consiste.owls.
uml.profile/AutoWebS_UMLProfile.profile.uml#_AUkrMLDkEeGj6oQuqPBRyw
"/>
35
</eAnnotations>
36
<appliedProfile href="../br.ufrn.consiste.owls.uml.profile/
AutoWebS_UMLProfile.profile.uml#_6gpcgGicEeGHr6qx6gTkYg"/>
37
</profileApplication>
38
</uml:Model>
39
</xmi:XMI>
40
</xsl:template>
41
<xsl:template match="owl:Ontology">
42
<packagedElement>
43
<xsl:attribute name="xmi:type">Package</xsl:attribute>
44
<xsl:attribute name="xmi:id"><xsl:value-of select="generate-id()"/></xsl:
attribute>
45
<xsl:attribute name="name"><xsl:value-of select="@rdf:ID | @rdf:about"></xsl:
value-of></xsl:attribute>
46
<xsl:apply-templates select="../owl:Class"/>
47
</packagedElement>
48
</xsl:template>
49
<xsl:template match="owl:Class">
50
<packagedElement>
51
<xsl:attribute name="xmi:type">uml:Class</xsl:attribute>
52
<xsl:attribute name="xmi:id"><xsl:value-of select="generate-id()"/></xsl:
attribute>
53
<xsl:attribute name="name"><xsl:value-of select="@rdf:ID | @rdf:about"></xsl:
value-of></xsl:attribute>
54
</packagedElement>
55 <!--
c subclasse de <xsl:apply-templates
<xsl:if test="child::rdfs:subClassOf"> Ã
select="rdfs:subClassOf"/> -->
56 <!--
</xsl:if> -->
57
</xsl:template>
58
<xsl:template match="rdfs:subClassOf">
Apêndice C
59
<xsl:value-of select="owl:Class/@rdf:ID | owl:Class/@rdf:about"></xsl:value-of>
60
</xsl:template>
61
<xsl:template match="UML:Class">
62
63
64
<xsl:variable name="stereotype">
<xsl:value-of
select="./UML:ModelElement.stereotype/UML:Stereotype/@xmi.idref" />
65
</xsl:variable>
66
<xsl:variable name="id">
67
<xsl:value-of select="./@xmi.id" />
68
</xsl:variable>
69
<xsl:variable name="classSterotype">
70
71
135
<xsl:value-of select="key(’stereotypeID’, $stereotype)/@name" />
</xsl:variable>
72
73
<!--Cases when we should convert an OWL Class or some OWL class constraint -->
74
<xsl:if test="$classSterotype = ’ObjectProperty’">
75
<xsl:call-template name="ObjectProperty" />
76
</xsl:if>
77
<xsl:if test="$classSterotype = ’DatatypeProperty’">
78
79
<xsl:call-template name="DatatypeProperty" />
</xsl:if>
80
81
82
<xsl:if
test="($classSterotype = ’OntClass’) or ($classSterotype = ’Union’) or (
$classSterotype = ’Intersection’) or ($classSterotype = ’Enumeration’ or (
$classSterotype = ’allDifferent’))">
83
<xsl:call-template name="Class" />
84
</xsl:if>
85
</xsl:template>
86
87
88
89
<xsl:template name="ObjectProperty">
<xsl:variable name="range">
<xsl:text>Class</xsl:text>
90
</xsl:variable>
91
<xsl:variable name="classID" select="./@xmi.id" />
92
<xsl:element name="owl:ObjectProperty">
93
<xsl:attribute name="rdf:ID"><xsl:value-of select="./@name" /></xsl:attribute>
94
<xsl:call-template name="classDepedencyStereotype">
95
96
97
<xsl:with-param name="stereotype">
<xsl:text>equivalentProperty</xsl:text>
</xsl:with-param>
Apêndice C
98
</xsl:call-template>
99
<xsl:call-template name="taggedValues" />
100
<xsl:call-template name="generalization">
101
<xsl:with-param name="generalizationKind">
102
<xsl:text>rdfs:subPropertyOf</xsl:text>
103
</xsl:with-param>
104
</xsl:call-template>
105
<!--Poziv template-a za complementOf stereotip -->
106
<xsl:call-template name="classDepedencyStereotype">
107
108
<xsl:with-param name="stereotype">
<xsl:text>inverseOf</xsl:text>
109
</xsl:with-param>
110
</xsl:call-template>
111
<xsl:call-template name="attributeDomainRange" />
112
<xsl:call-template name="associationDomainRange">
113
114
115
116
136
<xsl:with-param name="range" select="$range" />
</xsl:call-template>
</xsl:element>
</xsl:template>
117
118
119
120
<xsl:template name="DatatypeProperty">
<xsl:variable name="range">
<xsl:text>DataType</xsl:text>
121
</xsl:variable>
122
<xsl:element name="owl:DatatypeProperty">
123
<xsl:attribute name="rdf:ID"><xsl:value-of select="./@name" /></xsl:attribute>
124
<xsl:call-template name="classDepedencyStereotype">
125
126
<xsl:with-param name="stereotype">
<xsl:text>equivalentProperty</xsl:text>
127
</xsl:with-param>
128
</xsl:call-template>
129
<xsl:call-template name="taggedValues" />
130
<xsl:call-template name="generalization">
131
<xsl:with-param name="generalizationKind">
132
<xsl:text>rdfs:subPropertyOf</xsl:text>
133
</xsl:with-param>
134
</xsl:call-template>
135
<xsl:call-template name="attributeDomainRange" />
136
<xsl:call-template name="associationDomainRange">
137
138
<xsl:with-param name="range" select="$range" />
</xsl:call-template>
Apêndice C
139
140
</xsl:element>
</xsl:template>
141
142
<xsl:template name="xsdType">
143
<xsl:param name="type" />
144
<xsl:variable name="return">
145
146
147
<xsl:choose>
<xsl:when test="$type = ’String’ ">
<xsl:text>http://www.w3.org/2001/XMLSchema#string</xsl:text>
148
</xsl:when>
149
<xsl:when test="$type = ’Integer’ ">
150
<xsl:text>http://www.w3.org/2001/XMLSchema#int</xsl:text>
151
</xsl:when>
152
<xsl:when test="$type = ’Double’">
153
<xsl:text>http://www.w3.org/2001/XMLSchema#double</xsl:text>
154
</xsl:when>
155
<xsl:when test="$type = ’Long’">
156
<xsl:text>http://www.w3.org/2001/XMLSchema#long</xsl:text>
157
</xsl:when>
158
<xsl:when test="$type = ’anyURI’">
159
<xsl:text>http://www.w3.org/2001/XMLSchema#anyURI</xsl:text>
160
</xsl:when>
161
<xsl:when test="$type = ’duration’">
162
<xsl:text>http://www.w3.org/2001/XMLSchema#duration</xsl:text>
163
</xsl:when>
164
<xsl:when test="$type = ’decimal’">
165
<xsl:text>http://www.w3.org/2001/XMLSchema#decimal</xsl:text>
166
</xsl:when>
167
<!--extend here for other datatypes -->
168
<xsl:otherwise>
169
<xsl:text>#</xsl:text>
170
<xsl:value-of select="$type" />
171
172
</xsl:otherwise>
</xsl:choose>
173
</xsl:variable>
174
<xsl:value-of select="$return" />
175
</xsl:template>
176
177
178
179
<xsl:template name="unionOf">
<xsl:element name="owl:unionOf">
137
Apêndice C
180
<xsl:attribute name="rdf:parseType">Collection</xsl:attribute>
181
<xsl:call-template name="collection">
182
<xsl:with-param name="stereotype">
183
<xsl:text>unionOf</xsl:text>
184
</xsl:with-param>
185
</xsl:call-template>
186
187
</xsl:element>
</xsl:template>
188
189
190
191
<xsl:template name="allDifferent">
<xsl:element name="owl:distinctMembers">
192
<xsl:attribute name="rdf:parseType">Collection</xsl:attribute>
193
<xsl:call-template name="distinctMembers">
194
195
<xsl:with-param name="stereotype">
<xsl:text>distinctMembers</xsl:text>
196
</xsl:with-param>
197
</xsl:call-template>
198
199
</xsl:element>
</xsl:template>
200
201
202
<xsl:template name="intersectionOf">
<xsl:element name="owl:intersectionOf">
203
<xsl:attribute name="rdf:parseType">Collection</xsl:attribute>
204
<xsl:call-template name="collection">
205
<xsl:with-param name="stereotype">
206
<xsl:text>intersectionOf</xsl:text>
207
</xsl:with-param>
208
</xsl:call-template>
209
210
</xsl:element>
</xsl:template>
211
212
<xsl:template name="associationDomainRange">
213
<xsl:param name="range" />
214
<xsl:variable name="DomainStereotype"
215
select="key( ’stereotypeName’, ’domain’)[UML:Stereotype.baseClass = ’
Association’]/@xmi.id" />
216
217
<xsl:variable name="RangeStereotype"
select="key( ’stereotypeName’, ’range’)[UML:Stereotype.baseClass = ’
Association’]/@xmi.id" />
218
<xsl:variable name="id" select="./@xmi.id" />
138
Apêndice C
139
219
220
221
222
<xsl:if
test="key( ’associationStereotypeID’, $RangeStereotype) and $range = ’Class’
and (key( ’associationEnd1’, $id) or key( ’associationEnd2’, $id))">
223
224
225
226
227
228
229
<xsl:element name="rdfs:range">
<xsl:element name="owl:Class">
<xsl:element name="owl:unionOf">
<xsl:attribute name="rdf:parseType">
<xsl:text>Collection</xsl:text>
</xsl:attribute>
<xsl:for-each select="key( ’associationStereotypeID’, $RangeStereotype
)">
230
231
<xsl:variable name="type1"
select="./UML:Association.connection/UML:AssociationEnd[1]/UML:
AssociationEnd.participant/UML:Class/@xmi.idref" />
232
233
<xsl:variable name="type2"
select="./UML:Association.connection/UML:AssociationEnd[2]/UML:
AssociationEnd.participant/UML:Class/@xmi.idref" />
234
235
<xsl:variable name="stereotype1"
select="key(’stereotypeID’, key(’classID’, $type1)/UML:
ModelElement.stereotype/UML:Stereotype/@xmi.idref)/@name" />
236
237
<xsl:variable name="stereotype2"
select="key(’stereotypeID’, key(’classID’, $type2)/UML:
ModelElement.stereotype/UML:Stereotype/@xmi.idref)/@name" />
238
239
<xsl:if
test="not(($stereotype1 = ’DataRange’) or ($stereotype2 = ’
DataRange’))">
240
241
242
<xsl:variable name="associationStereotype">
<xsl:value-of
select="./UML:ModelElement.stereotype/UML:Stereotype/@xmi.
idref" />
243
</xsl:variable>
244
<xsl:variable name="associationType">
245
246
247
<xsl:choose>
<xsl:when test="$type1 = $id">
<xsl:value-of select="key( ’dataTypeID’, $type2)/@name" /
>
248
<xsl:value-of select="key( ’classID’, $type2)/@name" />
249
</xsl:when>
250
<xsl:when test="$type2 = $id">
Apêndice C
140
251
<xsl:value-of select="key( ’dataTypeID’, $type1)/@name" /
>
252
<xsl:value-of select="key( ’classID’, $type1)/@name" />
253
</xsl:when>
254
</xsl:choose>
255
</xsl:variable>
256
<xsl:if
257
test="key( ’stereotypeID’, $associationStereotype)/@name = ’
range’ ">
258
<xsl:if test="($type1 = $id) or ($type2 = $id)">
259
<xsl:element name="owl:Class">
260
<xsl:attribute name="rdf:about">
261
<xsl:text>#</xsl:text>
262
<xsl:value-of select="$associationType" />
263
</xsl:attribute>
264
</xsl:element>
265
</xsl:if>
266
</xsl:if>
267
</xsl:if>
268
</xsl:for-each>
269
270
271
272
</xsl:element>
</xsl:element>
</xsl:element>
</xsl:if>
273
274
275
<xsl:if
test="key( ’associationStereotypeID’, $RangeStereotype) and $range = ’DataType
’ and (key( ’associationEnd1’, $id) or key( ’associationEnd2’, $id))">
276
277
278
279
<xsl:element name="rdfs:range">
<xsl:for-each select="key( ’associationStereotypeID’, $RangeStereotype)">
<xsl:variable name="type1"
select="./UML:Association.connection/UML:AssociationEnd[1]/UML:
AssociationEnd.participant/UML:Class/@xmi.idref" />
280
281
<xsl:variable name="type2"
select="./UML:Association.connection/UML:AssociationEnd[2]/UML:
AssociationEnd.participant/UML:Class/@xmi.idref" />
282
283
284
285
286
<xsl:variable name="associationStereotype">
<xsl:value-of
select="./UML:ModelElement.stereotype/UML:Stereotype/@xmi.idref" />
</xsl:variable>
Apêndice C
287
288
141
<xsl:variable name="stereotype1"
select="key(’stereotypeID’, key(’classID’, $type1)/UML:ModelElement.
stereotype/UML:Stereotype/@xmi.idref)/@name" />
289
290
<xsl:variable name="stereotype2"
select="key(’stereotypeID’, key(’classID’, $type2)/UML:ModelElement.
stereotype/UML:Stereotype/@xmi.idref)/@name" />
291
292
293
294
<xsl:variable name="associationType">
<xsl:choose>
<xsl:when test="$type1 = $id">
295
<xsl:value-of select="key( ’dataTypeID’, $type2)/@name" />
296
<xsl:value-of select="key( ’classID’, $type2)/@name" />
297
</xsl:when>
298
<xsl:when test="$type2 = $id">
299
<xsl:value-of select="key( ’dataTypeID’, $type1)/@name" />
300
<xsl:value-of select="key( ’classID’, $type1)/@name" />
301
302
</xsl:when>
</xsl:choose>
303
</xsl:variable>
304
<xsl:if
305
test="key( ’stereotypeID’, $associationStereotype)/@name = ’range’ ">
306
<xsl:if test="($type1 = $id) or ($type2 = $id)">
307
<xsl:choose>
308
<xsl:when
309
test="not(($stereotype1 = ’DataRange’) or ($stereotype2 = ’
DataRange’))">
310
<xsl:attribute name="rdf:resource">
311
<xsl:variable name="xsdType">
312
313
314
<xsl:call-template name="xsdType">
<xsl:with-param name="type" select="$associationType" />
</xsl:call-template>
315
</xsl:variable>
316
<xsl:value-of select="$xsdType" />
317
</xsl:attribute>
318
</xsl:when>
319
<xsl:otherwise>
320
<xsl:call-template name="dataRange">
321
<xsl:with-param name="classID">
322
323
324
<xsl:if test="$stereotype1 = ’DataRange’">
<xsl:value-of select="$type1" />
</xsl:if>
Apêndice C
142
325
<xsl:if test="$stereotype2 = ’DataRange’">
326
<xsl:value-of select="$type2" />
327
</xsl:if>
328
</xsl:with-param>
329
</xsl:call-template>
330
</xsl:otherwise>
331
</xsl:choose>
332
333
</xsl:if>
334
</xsl:if>
335
</xsl:for-each>
336
337
338
</xsl:element>
</xsl:if>
339
340
341
342
343
<xsl:if
test="key( ’associationStereotypeID’, $DomainStereotype) and (key( ’
associationEnd1’, $id) or key( ’associationEnd2’, $id))">
344
345
346
347
348
349
350
<xsl:element name="rdfs:domain">
<xsl:element name="owl:Class">
<xsl:element name="owl:unionOf">
<xsl:attribute name="rdf:parseType">
<xsl:text>Collection</xsl:text>
</xsl:attribute>
<xsl:for-each
351
select="key( ’associationStereotypeID’, $DomainStereotype)">
352
<xsl:variable name="type1"
353
select="./UML:Association.connection/UML:AssociationEnd[1]/UML:
AssociationEnd.participant/UML:Class/@xmi.idref" />
354
355
<xsl:variable name="type2"
select="./UML:Association.connection/UML:AssociationEnd[2]/UML:
AssociationEnd.participant/UML:Class/@xmi.idref" />
356
357
358
<xsl:variable name="associationStereotype">
<xsl:value-of
select="./UML:ModelElement.stereotype/UML:Stereotype/@xmi.
idref" />
359
</xsl:variable>
360
<xsl:if
Apêndice C
143
361
test="key( ’stereotypeID’, $associationStereotype)/@name = ’
domain’ ">
362
<xsl:if test="($type1 = $id)">
363
<xsl:element name="owl:Class">
364
<xsl:attribute name="rdf:about">
365
<xsl:text>#</xsl:text>
366
<xsl:value-of select="key( ’classID’, $type2)/@name" />
367
</xsl:attribute>
368
</xsl:element>
369
</xsl:if>
370
<xsl:if test="($type2 = $id)">
371
<xsl:element name="owl:Class">
372
<xsl:attribute name="rdf:about">
373
<xsl:text>#</xsl:text>
374
<xsl:value-of select="key( ’classID’, $type1)/@name" />
375
</xsl:attribute>
376
</xsl:element>
377
</xsl:if>
378
</xsl:if>
379
</xsl:for-each>
380
381
382
</xsl:element>
</xsl:element>
</xsl:element>
383
</xsl:if>
384
</xsl:template>
385
386
<xsl:template name="enumeration">
387
<xsl:element name="owl:oneOf">
388
<xsl:attribute name="rdf:parseType">Collection</xsl:attribute>
389
<xsl:call-template name="collectionInverse">
390
<xsl:with-param name="stereotype">
391
<xsl:text>instanceOf</xsl:text>
392
</xsl:with-param>
393
</xsl:call-template>
394
395
</xsl:element>
</xsl:template>
396
397
398
399
400
<xsl:template name="generalization">
<xsl:param name="generalizationKind" />
Apêndice C
144
401
<xsl:param name="classOrProperty">
402
<xsl:text>property</xsl:text>
403
</xsl:param>
404
<xsl:if test="./UML:GeneralizableElement.generalization/UML:Generalization">
405
<xsl:for-each
406
select="./UML:GeneralizableElement.generalization/UML:Generalization">
407
<xsl:element name="{$generalizationKind}">
408
<xsl:variable name="generalization">
409
<xsl:value-of select="./@xmi.idref" />
410
</xsl:variable>
411
<xsl:variable name="parent">
412
413
<xsl:value-of
select="key( ’generalizationID’, $generalization)/UML:Generalization
.parent/UML:Class/@xmi.idref" />
414
</xsl:variable>
415
<xsl:variable name="taggedValueAnonymousID">
416
417
<xsl:choose>
<xsl:when test="key( ’classID’, $parent)/UML:ModelElement.
taggedValue">
418
419
<xsl:value-of
select="key( ’classID’,$parent)/UML:ModelElement.taggedValue/
UML:TaggedValue/UML:TaggedValue.type/UML:TagDefinition/@xmi
.idref" />
420
</xsl:when>
421
<xsl:otherwise>
422
423
424
<xsl:text>no</xsl:text>
</xsl:otherwise>
</xsl:choose>
425
</xsl:variable>
426
<xsl:choose>
427
<xsl:when
428
test="$taggedValueAnonymousID != ’no’ and key( ’tagDefinitionID’,
$taggedValueAnonymousID)/@name = ’odm.anonymous’">
429
430
431
432
<xsl:for-each select="key( ’classID’, $parent)">
<xsl:call-template name="Class">
<xsl:with-param name="anon">
<xsl:text>yes</xsl:text>
433
</xsl:with-param>
434
</xsl:call-template>
435
436
</xsl:for-each>
</xsl:when>
Apêndice C
437
145
<xsl:when test="$classOrProperty = ’class’">
438
<xsl:element name="owl:Class">
439
<xsl:attribute name="rdf:about"><xsl:text>#</xsl:text><xsl:valueof
440
select="key( ’classID’, $parent)/@name" /></xsl:attribute>
441
</xsl:element>
442
</xsl:when>
443
<xsl:otherwise>
444
<xsl:attribute name="rdf:resource"><xsl:text>#</xsl:text><xsl:valueof
445
select="key( ’classID’, $parent)/@name" /></xsl:attribute>
446
447
448
449
</xsl:otherwise>
</xsl:choose>
</xsl:element>
</xsl:for-each>
450
</xsl:if>
451
</xsl:template>
452
453
454
455
456
457
<xsl:template name="taggedValues">
<xsl:if test="./UML:ModelElement.taggedValue">
<xsl:for-each select="./UML:ModelElement.taggedValue/UML:TaggedValue">
<xsl:variable name="taggedValueDefinitionID">
<xsl:value-of select="./UML:TaggedValue.type/UML:TagDefinition/@xmi.idref
" />
458
</xsl:variable>
459
<xsl:variable name="taggedValueName"
460
461
462
463
select="key( ’tagDefinitionID’, $taggedValueDefinitionID)/@name" />
<xsl:if test="./UML:TaggedValue.dataValue = ’true’">
<xsl:if
test="$taggedValueName = ’symmetric’ or $taggedValueName = ’functional
’ or $taggedValueName = ’transitive’ or $taggedValueName = ’
inverseFunctional’">
464
<xsl:variable name="propertyType">
465
<xsl:value-of select="$owlPrefix" />
466
<xsl:choose>
467
468
<xsl:when test="$taggedValueName = ’symmetric’">
<xsl:text>SymmetricProperty</xsl:text>
469
</xsl:when>
470
<xsl:when test="$taggedValueName = ’transitive’">
471
472
<xsl:text>TransitiveProperty</xsl:text>
</xsl:when>
Apêndice C
146
473
<xsl:when test="$taggedValueName = ’functional’">
474
<xsl:text>FunctionalProperty</xsl:text>
475
</xsl:when>
476
<xsl:when test="$taggedValueName = ’inverseFunctional’">
477
<xsl:text>InverseFunctionalProperty</xsl:text>
478
</xsl:when>
479
</xsl:choose>
480
</xsl:variable>
481
<xsl:element name="rdf:type">
482
<xsl:attribute name="rdf:resource"><xsl:value-of
483
select="$propertyType" /></xsl:attribute>
484
485
</xsl:element>
</xsl:if>
486
</xsl:if>
487
</xsl:for-each>
488
</xsl:if>
489
</xsl:template>
490
491
492 </xsl:stylesheet>
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
25
26
27
when {self.interface.getAppliedStereotypes()->any(name=’SemanticWebService’)<>null
and self.getAppliedStereotypes()->any(name=’SWSOperation’)<>null} {
init {
log(’Building the OWL-S ’ + self.name + ’ Ontology’);
Apêndice D
28
148
this.namespaceId := getTaggedValue(self.interface, ’SemanticWebService’, ’
targetNamespace’);
29
30
this.serviceName := self.name;
}
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
47
id := this.serviceName + ’Process’;
};
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
63
149
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
87
if(parameter.direction = ParameterDirectionKind::_in) then {
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
96
150
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
128
if(parameter.type.getAppliedStereotypes()->any(name=’owl:Class’)<>null) then {
return getTaggedValue(parameter.type.package,’owl:Ontology’,’xmlns’) + ’/’ +
parameter.type.package.name + ’.owl#’ + parameter.type.name;
129
130
131
132
//http://www.example.org/owls/OilMonitor.owl#OilWell
} else {
if (parameter.type.oclIsKindOf(UML::PrimitiveType)) then {
//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
165
importsSet += object OWLS::Imports{resource := "http://www.daml.org/services/owl-s
/1.1/generic/Expression.owl"};
166
ontologies->forEach(ontology){
167
168
152
importsSet += object OWLS::Imports{resource := ontology};
};
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
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 }
153
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
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
1
2
3
4
Apêndice E
E.2
155
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 desenvolvimento 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 claros 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 desenvolvimento de serviços Web semânticos?
Apêndice E
Muito importante ( ) Nada ( )
11. Alguma observação/comentário a respeito do AutoWebS?
157
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
B C A
C D B
D A C
D
D
A
B
Figura F.1: Exemplo de quadrado latino de tamanho 4
O modelo estatístico para um Quadrado Latino é:


 i = 1, 2, ..., p;
yi jk = µ + αi + τ j + βk + εi jk
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.