UNIVERSIDADE ESTADUAL PAULISTA
“Júlio de Mesquita Filho”
Pós-Graduação em Ciência da Computação
Lilian Passos Scatalon
Empacotamento de Experimentos Controlados em
Engenharia de Software: Uma Abordagem Baseada em
Ontologia
UNESP
2013
Lilian Passos Scatalon
Empacotamento de Experimentos Controlados em
Engenharia de Software: Uma Abordagem Baseada em
Ontologia
Orientador: Prof. Dr. Rogério Eduardo Garcia
Dissertação apresentada ao Instituto de Biociências, Letras e Ciências Exatas (IBILCE –
Unesp – São José do Rio Preto) como parte dos
requisitos para a obtenção do título de mestre
em Ciência da Computação.
UNESP
2013
i
“Tá pronto.”
iii
Dedico este trabalho aos meus pais, Nete e Ademar,
à minha irmã Aline e à memória do meu irmão Junior.
iv
Agradecimentos
A Deus, pela segunda chance. Pela terceira, pela quarta, pela enésima. Muito obrigada por todo
o aprendizado repleto de amor que recebi durante esse período e por ter colocado todas essas pessoas
em meu caminho!
Aos meus pais (Nete e Ademar), pelos cuidados comigo e incentivo. Eu me preparei a minha vida
inteira para fazer isso, sem nem me dar conta. E vocês são os responsáveis por todo tipo de apoio que
eu tive.
À minha irmã (Aline), por me alimentar e cuidar de mim durante esse período, principalmente
nos últimos meses tensos, porque fui uma roommate muito relapsa. Ainda bem que tenho uma irmã
que é uma leoa.
À minha família, por ser uma família com a qual sempre podemos contar. Um agradecimento
especial à tia Givalda, que me levou para a entrevista do processo seletivo em Rio Preto.
Ao Rogério, pela paciência, pela orientação e, acima de tudo, pela formação que me proporcionou. Obrigada por cada pergunta que me fez pensar para responder. A maioria dessas respostas
não estavam no rumo certo, mas você foi direcionando. Com isso aprendi muito como aluna e como
pessoa também. Obrigada por ter assistido aquele primeiro seminário do TCC e, mesmo depois disso,
me aceitar como aluna de mestrado. Tá pronto! Tá pronto! Tá pronto! Tá pronto! Tá pronto!
Aos irmãos Álvaro, Fer, Jorge, Neto e Helton e à prima Vanessa, pelos momentos que vivemos
juntos na sala 13, na senzala, no café e durante as viagens a Bauru, Rio Preto e Rio Claro.
À Fer, por compartilhar todas as emoções deste mestrado comigo: trabalhos das disciplinas, viagens a Bauru, prazos vencendo, artigos aceitos. Na alegria e na tristeza estávamos passando por
tudo sempre juntas. Obrigada por levar a nossa amizade além da fronteira das nossas atividades no
mestrado, por se importar de verdade comigo e por dizer muitas coisas que me ﬁzeram parar para
pensar na vida.
Ao Jorge, por chegar quase um ano depois e mesmo assim se tornar uma das pessoas mais importantes nisso tudo. Obrigada pelas muitas vezes que ajudou a me organizar e a ter bom senso enquanto
eu surtava. Por cada carona, cada conversa, cada vez que me ajudou com as disciplinas da graduação.
E claro, não posso deixar de mencionar: obrigada por ser o DJ das nossas viagens para o workshop.
Quando você for o diretor da FCT, lembre-se daquela promessa.
À Patrícia Nunes, por me acolher em sua casa durante o período das disciplinas. Estendo o
agradecimento à Adriana e à Priscila. Encontrar rostos amigos lá em Bauru todas as quintas de noite
v
foi muito bom.
À Andrika e ao Balbino, pela paciência, pela prontidão, pela amizade e por terem me acolhido em
São Carlos. Na última vez que estive com vocês, quase passei de visita para agregada, me desculpem.
À Cida, à Marisa e ao Ricardo, pelo carinho e pelos sábados muito agradáveis que passei com
vocês durante esse período.
À Aline Sandra e à Fer Hondo, pela amizade e torcida. Aline, nem sei se você lembra, mas quando
eu estava escrevendo o projeto de pesquisa para enviar à Fapesp, você acreditou mais do que eu que
seria aceito e me incentivou bastante. Obrigada!
Ao Hadil, pelo empurrão para ingressar na vida acadêmica e por todo o apoio durante o primeiro
ano.
Ao pessoal do Pós-MAC, por nos emprestar um cantinho em sua sala de permanência. Um agradecimento especial para a Patrícia, a Camila, a Larissa, o Diego, o Clóvis, o Merejolli, a Marília, a
Renata, o Verri, o Zé e a Daiane, por fazerem parte da nossa rotina. Tudo era mais divertido naquela
sala 13! Foram muitos almoços agradáveis na companhia de vocês.
A todos que de alguma maneira me ajudaram lá em São Carlos nas vezes que estive lá. Ao Rubens,
pelo apoio moral no dia da quali. Ao pessoal do Labic e à professora Solange, por terem me recebido
tão bem e pelas contribuições ao meu trabalho. Em especial, agradeço ao Rafael Giusti pelas dicas
passadas de veterano para aspirante a aluna do ICMC. Ao Renan, pela torcida e pela companhia nos
almoços. Ao Balbino e à Andrika, porque algumas pessoas precisam ser citadas muitas vezes entre
os agradecimentos.
Aos professores Ronaldo, Milton, Celso e Danilo, por sempre estarem dispostos a ajudar. Obrigada pelas contribuições a este trabalho, pelas palavras de incentivo, pela parceria em outros trabalhos
e pelo auxílio nas minhas atividades como professora de primeira viagem (aproveito para agradecer
novamente ao Rogério por esse motivo também).
Ao Balbino e ao Rafael Giusti, pela gentileza de providenciar e entregar as cópias da quali e da
dissertação para a banca.
Às professoras Solange e Ellen, pelas muitas contribuições e por terem gentilmente aceito participar da banca da quali e da defesa. A colaboração de vocês foi muito importante para aprimorar o
trabalho.
À Unesp, como instituição, pelo ensino que recebi na graduação e no mestrado (inclusive com a
provisão necessária desde o começo) e por me empregar nos últimos meses como professora substituta
do curso em que me formei. São mais de 7 anos passando por aquele caminho dos eucaliptos!
À PROPG-Unesp e à FAPESP pelo apoio ﬁnanceiro. Do meu ponto de vista, me deram a oportunidade e vocês possibilitaram a realização de um sonho.
vi
Índice
Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
xi
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
1
2
Introdução
1
1.1
1.2
1.3
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formulação do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
1.4
Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Experimentos controlados em Engenharia de Software
2.1 Experimentos controlados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
2.2
2.3
2.4
2.5
3
Processo de experimentação . . . . . . . . . . . . . . .
2.2.1 Deﬁnição . . . . . . . . . . . . . . . . . . . . .
2.2.2 Planejamento . . . . . . . . . . . . . . . . . . .
2.2.3 Operação . . . . . . . . . . . . . . . . . . . . .
2.2.4 Análise e interpretação . . . . . . . . . . . . . .
2.2.5 Empacotamento . . . . . . . . . . . . . . . . . .
Replicações . . . . . . . . . . . . . . . . . . . . . . . .
Transferência de conhecimento . . . . . . . . . . . . . .
2.4.1 Pacotes de laboratório e artigos cientíﬁcos . . . .
2.4.2 Diretrizes para reportar experimentos controlados
Considerações ﬁnais . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ontologia
3.1 Visão geral sobre ontologia . . . . . . . . . . . . . . . . . . . . . . .
3.2 Ontologias para experimentos controlados em Engenharia de Software
3.3 EXP ER Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Evolução de ontologias . . . . . . . . . . . . . . . . . . . . . . . . .
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
8
9
10
10
11
13
14
14
18
.
.
.
.
20
20
22
24
26
Matching de ontologias/esquemas . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Processo de matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Técnicas de matching por tipo de entrada . . . . . . . . . . . . . . . . . . .
29
30
Considerações ﬁnais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Workﬂow para empacotar experimentos controlados
4.1 Deﬁnição do comportamento do workﬂow . . . . . . . . . . . . . . . . . . . . . . .
33
33
Atividade de Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.1.2 Atividades de Instanciação, Resolução e Evolução . . . . . . . . . . . . . .
Instância do workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
38
4.2.1
4.2.2
Entradas do workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Atividade de matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
40
4.2.3
Atividade de instanciação . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.2.4
Atividades de resolução e evolução . . . . . . . . . . . . . . . . . . . . . .
43
Considerações ﬁnais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.5
3.5.1
3.5.2
3.6
4
4.1.1
4.2
4.3
5
6
Avaliação do workﬂow
45
5.1
5.2
Ferramenta PontoLab++ . . . .
Execução do workﬂow proposto
5.2.1 Pré-processamento . . .
5.2.2 Execução do workﬂow .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
48
48
50
5.3
Considerações ﬁnais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Conclusões
6.1 Contribuições e limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
57
6.2
6.3
58
58
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Produção bibliográﬁca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referências Bibliográﬁcas
59
viii
Lista de Figuras
2.1
Relação causal avaliada em um experimento controlado (Wohlin et al., 2000) . . . .
6
2.2
Variáveis independentes e dependentes de um experimento controlado (Wohlin et al.,
2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
2.4
Processo de experimentação (Wohlin et al. (2000); Garcia (2006)) . . . . . . . . . .
Processo de experimentação - fase de empacotamento (Wohlin et al. (2000); Amaral
e Travassos (2003)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
11
2.5
2.6
2.7
Papel da replicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Ciclos do FIRE (Mendonça et al., 2008) . . . . . . . . . . . . . . . . . . . . . . . . 12
Modelo de compartilhamento de conhecimento em experimentação (Shull et al., 2004) 13
3.1
Domínio de recursos humanos, adaptado de Guarino et al. (2009) . . . . . . . . . . .
21
3.2
3.3
Conceituação do domínio de recursos humanos . . . . . . . . . . . . . . . . . . . .
Processo de desenvolvimento de uma ontologia (Goméz-Pérez, 1999) . . . . . . . .
21
22
3.4
Ontologia da estrutura de um estudo experimental em Engenharia de Software (Biolchini et al., 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Ambiente de Engenharia de Software Experimental com um repositório de conhecimento (Lopes e Travassos, 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 EXP ER Ontology - conceitos de experimentos controlados (Garcia et al., 2008) . . .
3.7 EXP ER Ontology - conceitos de um pacote de laboratório (Garcia et al., 2008) . . . .
3.8 Processo de evolução de ontologia (Stojanovic, 2004) . . . . . . . . . . . . . . . . .
3.9 Introdução de inconsistências após a realização de uma mudança . . . . . . . . . . .
3.10 Matching de esquemas/ontologias, representado como uma operação com entradas e
saída (Euzenat e Shvaiko, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 Processo de matching de esquemas (Rahm, 2011) . . . . . . . . . . . . . . . . . . .
4.1
4.2
4.3
4.4
4.5
Integração de pacotes de laboratório usando ontologia . . . . . . . . . . . . . . . .
Empacotamento com ontologia - situação ideal . . . . . . . . . . . . . . . . . . .
Empacotamento com ontologia - situação em que sobram elementos de informação
Diagrama com todas as atividades do workﬂow e suas respectivas entradas e saídas
Atividade de matching do workﬂow . . . . . . . . . . . . . . . . . . . . . . . . .
ix
.
.
.
.
.
23
23
24
25
26
27
29
29
34
34
34
35
36
4.6
Atividade de instanciação do workﬂow . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.7
4.8
Atividade de resolução do workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . .
Atividade de evolução do workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37
Trecho de um pacote de laboratório em documento XML . . . . . . . . . . . . . . .
4.10 Instantâneo da EXP ER Ontology no editor Protégé . . . . . . . . . . . . . . . . . . .
4.11 Ontologias de instâncias e a EXP ER Ontology . . . . . . . . . . . . . . . . . . . . .
38
39
42
5.1
5.2
PontoLab++ - Interface inicial com os ajustes para a execução do workﬂow . . . . .
PontoLab++ - Interface com os demais ajustes para a execução do workﬂow . . . . .
46
46
5.3
PontoLab++ - Interface com o conjunto de elementos de informação casados . . . .
47
5.4
5.5
PontoLab++ - Interface com o conjunto de elementos de informação não casados . .
PontoLab++ - Interface de resolução e evolução . . . . . . . . . . . . . . . . . . . .
47
48
5.6
Extração de elementos de informação do texto . . . . . . . . . . . . . . . . . . . . .
49
5.7
5.8
Extração de um elemento de informação do texto . . . . . . . . . . . . . . . . . . .
Interface da ferramenta de pré-processamento . . . . . . . . . . . . . . . . . . . . .
49
50
4.9
x
Lista de Tabelas
2.1
Visão geral das diretrizes para reportar experimentos controlados (Jedlitschka et al.,
2.2
2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diretrizes propostas por Jedlitschka et al. (2007) . . . . . . . . . . . . . . . . . . . .
15
15
3.1
Mudanças elementares a uma ontologia (Stojanovic, 2004) . . . . . . . . . . . . . .
27
3.2
3.3
Distância de edição entre nomes dos conceitos (Euzenat e Shvaiko, 2007) . . . . . .
Distância entre nomes de conceitos calculada com o apoio de um tesauro (Euzenat e
Shvaiko, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
30
3.4
Matriz resultante da combinação dos resultados (Euzenat e Shvaiko, 2007) . . . . . .
30
4.1
Impacto de mudanças de adição de conceitos em uma ontologia (Abgaz et al., 2011) .
44
5.1
5.2
Amostra do conjunto de correspondências . . . . . . . . . . . . . . . . . . . . . . .
Conjunto de elementos não-casados . . . . . . . . . . . . . . . . . . . . . . . . . .
51
54
xi
Resumo
Engenharia de Software Experimental visa a avaliar e medir o desempenho de métodos, técnicas
e ferramentas aplicadas em atividades de desenvolvimento de software. A meta é criar um corpo de
conhecimento validado experimentalmente para apoiar as tomadas de decisões no domínio de Engenharia de Software. Construir esse corpo de conhecimento requer a condução de experimentos
controlados e suas replicações a ﬁm de generalizar os resultados obtidos. As informações e o conhecimento gerados por um experimento são registrados em seu pacote de laboratório, que deve ser
revisado por um eventual grupo de pesquisa com a intenção de replicá-lo. Entretanto, pesquisadores enfrentam diﬁculdades ao revisar os pacotes de laboratório disponíveis. Um dos fatores desse
problema é a falta de padronização dos pacotes de laboratório. Os experimentos são reportados com
diferentes conjuntos de informações, o que também se constitui em uma barreira para a integração dos
estudos em um corpo comum. Nesse contexto, considerando que compartilhamento e integração de
conhecimento são aplicações recorrentes de ontologias, neste trabalho é proposto um workﬂow para
aplicar uma ontologia ao empacotamento de experimentos controlados em Engenharia de Software.
Para avaliar essa abordagem, foi implementada a ferramenta PontoLab++, que corresponde a uma
instância do workﬂow que adota como padrão a EXP ER Ontology, uma ontologia para experimentos
controlados.
xii
Abstract
Experimental Software Engineering attempts to assess the performance of methods, techniques
and tools applied on software development activities. The goal is to build a body of experimentally
validated knowledge in order to support decision making on Software Engineering domain. Building
this body of knowledge requires to run controlled experiments and their replications in order to generalize the obtained results. The information and the knowledge generated by an experiment are
registered in the so-called lab package, which must be reviewed by an eventual research group with
the intention to replicate it. However, researchers face difﬁculties while reviewing the available lab
packages. One of the factors that leads to this problem is the lab packages lack of standardization.
The experiments are reported with different information sets, what is also a barrier to integrate studies
in a common body. In this context, considering that knowledge sharing and integration are recurring
applications of ontologies, in this work is proposed a workﬂow that applies an ontology to package
controlled experiments in Software Engineering. In order to evaluate this approach, the tool PontoLab++ was implemented, which corresponds to a workﬂow instance that adopts EXP ER Ontology, an
ontology for controlled experiments.
xiii
C APÍTULO
1
Introdução
A Engenharia de Software Experimental tem por objetivo a realização de estudos que avaliem
métodos, técnicas e ferramentas envolvidos no desenvolvimento de software. Para atingir seus objetivos, os engenheiros de software precisam entender e escolher tecnologias apropriadas que apóiem
o desenvolvimento de seus projetos. Nessa perspectiva, estudos experimentais vêm sendo realizados,
contribuindo para a formação de uma base de conhecimento sobre Engenharia de Software que pode
ajudar em tomadas de decisão (Basili et al. (1999); Basili (2006)).
Em um experimento controlado elabora-se um modelo similar a proﬁssionais construindo software. Os participantes, que os representam, aplicam a tecnologia sob investigação. Os dados produzidos pela execução permitem que o desempenho seja avaliado, medido e comparado, considerando as
condições sob as quais o experimento foi executado (Juristo e Moreno (2001); Wohlin et al. (2000)).
A partir dos resultados de estudos experimentais é construído um corpo de conhecimento, que além
de prover um alicerce cientíﬁco para a disciplina de Engenharia de Software, favorece a sua respectiva
aplicação no mercado, apoiando em tomadas de decisão (Basili e Zelkowitz, 2007).
Entretanto, apenas experimentos isolados não são suﬁcientes para o estabelecimento desse corpo
de conhecimento, por isso é preciso realizar replicações para fundamentar as conclusões obtidas com
um nível maior de conﬁança (Shull et al. (2008); Brooks et al. (2008)). Quando outros pesquisadores
replicam um experimento com sucesso, a conﬁança é construída nos procedimentos e nos resultados
(Brooks et al., 2008).
Realizar uma replicação, que não seja de maneira completamente independente do grupo de pesquisa responsável pelo experimento original (Kitchenham, 2008), requer o acesso ao seu respectivo
pacote de laboratório. O pacote de laboratório é um artefato que contém a descrição dos procedimentos adotados, o conhecimento gerado, os resultados e as conclusões (Shull et al., 2002).
Revisando essas informações, replicadores podem compreender como o experimento foi projetado, conduzido e analisado. Portanto, o pacote de laboratório consiste em um meio de transferência
de conhecimento entre grupos de pesquisa de Engenharia de Software.
1
1.1 Motivação
1.1
Motivação
Uma barreira para integrar os resultados dos estudos em um corpo comum de conhecimento é
a falta de padronização de suas informações (Jedlitschka et al., 2008). Além disso, pesquisadores
enfrentam diﬁculdades em entender e revisar pacotes de laboratório. As principais diﬁculdades estão
relacionadas ao entendimento dos conceitos das técnicas sob estudo e em dominar o conhecimento
envolvido na execução do experimento. (Shull et al., 2002).
Para lidar com diﬁculdades na transferência de conhecimento entre pesquisadores, Mendonça et
al. (2008) propuseram o arcabouço FIRE (Framework for Improving the Replication of Experiments),
que trata de questões de compartilhamento de conhecimento dentro de um mesmo grupo de pesquisa
(intragrupo) e entre grupos de pesquisa distintos (intergrupos). O arcabouço é composto de atividades
que enfatizam, entre outras práticas, a importância de padronizar pacotes de laboratório, compartilhar
e promover o entendimento do conhecimento gerado por cada estudo experimental.
Shull et al. (2004) apontaram que os pacotes de laboratório são ferramentas importantes para
apoiar replicações e, se forem bem projetados, facilitam replicações. Logo, deve ser promovida uma
representação bem projetada para o conhecimento expresso em um pacote de laboratório.
Compartilhar conhecimento é uma das metas mais comuns em se desenvolver ontologias (Gruber
(1995); Noy e McGuinness (2001)). Além disso, ontologias vêm sendo utilizadas em Engenharia de
Software com a ﬁnalidade de modelar conceitos de um domínio (Kitchenham et al. (1999); Falbo
et al. (2005); Barbosa et al. (2006); Biolchini et al. (2007)). Nesse contexto, Garcia et al. (2008)
apresentaram uma ontologia para o domínio de experimentos controlados – a EXP ER Ontology – que
ajuda a esclarecer seus conceitos e relações.
Ontologias são um meio para prover o entendimento compartilhado da estrutura da informação
que modelam (Noy e McGuinness, 2001). Portanto, para facilitar o entendimento do conteúdo dos
pacotes de laboratório, uma ontologia pode ser usada como um padrão semântico das informações
geradas por um experimento.
1.2
Formulação do problema
Vários experimentos têm sido conduzidos e seus resultados publicados, entretanto cada pesquisador publica um conteúdo diferente sobre o experimento realizado, em relação ao conjunto de informações e ao nível de detalhes (Jedlitschka et al., 2008). A falta de padronização das informações
geradas pelos experimentos é uma grande diﬁculdade para sua integração em um corpo de conhecimento comum (Jedlitschka et al., 2008).
Assim, não apenas o uso de uma ontologia para empacotar o conjunto de informações de experimentos deve ser considerado, mas também a prática de publicação atual, uma vez que é comum haver
pacotes de laboratório contendo diferentes conjuntos de informação. É necessário lidar com diferentes conjuntos de informação para acomodá-los de acordo com a ontologia, que pode ser utilizada para
integrar as diferentes perspectivas sobre o que deve conter um pacote de laboratório. Uma vez que há
a necessidade de uma padronização que considere a irregularidade dos conjuntos de informação dos
experimentos publicados (Carver, 2010), a ontologia adotada deve lidar com as diferentes maneiras
que a execução de um experimento pode ser registrada.
2
1.3 Objetivos
1.3
Objetivos
O principal objetivo é instanciar pacotes de laboratório de acordo com os conceitos de uma ontologia, a ﬁm de padronizá-los. Considerando uma padronização que acomode diferentes conjuntos
de informação, a ontologia adotada deve ser capaz de lidar com as diferentes maneiras nas quais as
informações do experimento são registradas. Isso sugere que a ontologia deve evoluir, incorporando
novos conceitos.
De uma maneira geral, há o objetivo lidar com os problemas de integração e transferência do
conhecimento gerado por experimentos controlados em Engenharia de Software. Conforme pode ser
observado no arcabouço FIRE (Mendonça et al., 2008), um importante fator que permeia a transferência de conhecimento entre grupos de pesquisa é o empacotamento das informações de cada
experimento.
Para atingir os objetivos, neste trabalho de mestrado foi proposto um workﬂow de empacotamento
de experimentos controlados com base em uma ontologia. Uma vez que as deﬁnições da ontologia
não são necessariamente estáticas, o workﬂow permite que a ontologia absorva novos conceitos, conforme pacotes de laboratório contendo diferentes conjuntos de informação são instanciados. Adicionalmente, foi implementada uma instância do workﬂow, que adota a EXP ER Ontology como ontologia
de entrada – a ferramenta PontoLab++.
1.4
Organização
Para contextualizar e apresentar a proposta de trabalho, o restante desta dissertação está organizado como segue:
• No Capítulo 2 são dadas deﬁnições gerais sobre experimentos controlados e o processo de experimentação é detalhado, a ﬁm de fornecer uma visão geral sobre quais informações devem ser
registradas em um pacote de laboratório. Também são apresentados alguns aspectos relativos
à importância de se realizar replicações e problemas relacionados à transferência de conhecimento entre grupos de pesquisa.
• No Capítulo 3, é dada uma visão geral sobre ontologia e então são apresentados trabalhos
relacionados, que elaboram ou aplicam ontologias no contexto de experimentos controlados em
Engenharia de Software. Dentre esses trabalhos, a EXP ER Ontology é apresentada em detalhes.
Também são apresentados processos auxiliares que foram identiﬁcados neste trabalho como
necessários para compor uma solução que aplique a ontologia para lidar com problemas de
transferência de conhecimento: evolução e matching de ontologias/esquemas.
• No Capítulo 4 é proposto o workﬂow para empacotar experimentos controlados em Engenharia
de Software que adota uma ontologia como o padrão das informações do pacote de laboratório
gerado. Além de fornecer a deﬁnição de um conjunto de atividades, neste capítulo é apresentada
uma instância do workﬂow, considerando a EXP ER Ontology como ontologia adotada e algumas
escolhas de implementação.
3
1.4 Organização
• No Capítulo 5 é mostrada uma avaliação da proposta. Para isso, é apresentada a implementação
(i) da instância do workﬂow (ferramenta PontoLab++) e (ii) de um pré-processamento para permitir a execução usando um conjunto de artigos como representantes dos pacotes de laboratório
a serem padronizados. Por ﬁm, é fornecida uma demonstração da execução do workﬂow por
meio da ferramenta PontoLab++.
• No Capítulo 6 são apresentadas as conclusões acerca do trabalho desenvolvido, destacando suas
contribuições e limitações, e são indicados trabalhos futuros. Também é apresentada a produção
bibliográﬁca obtida ao longo de seu desenvolvimento.
4
C APÍTULO
2
Experimentos controlados em Engenharia
de Software
Grupos de pesquisa isolados têm diﬁculdades em prover o ambiente de laboratório necessário para
aprender sobre variações nos efeitos das tecnologias em múltiplos ambientes e fatores de inﬂuência.
Logo, com replicações realizadas em diferentes grupos de pesquisa é possível tratar diferentes conjuntos de condições a que a aplicação de uma técnica, método ou ferramenta está sujeita, para que as
conclusões obtidas atinjam um contexto abrangente e, então, seja possível consolidar conhecimento
em Engenharia de Software.
Neste capítulo é enfatizada a importância do estabelecimento de um corpo de conhecimento por
meio de experimentos e suas replicações por diversos grupos de pesquisa. Também são apresentados
os problemas na transferência de conhecimento entre esses grupos. Na Seção 2.1 são apresentados
conceitos básicos sobre experimentos controlados. Na Seção 2.2 são apresentadas as fases do processo para estabelecer e executar um experimento. Na Seção 2.3 argumenta-se sobre a importância
da realização de replicações de experimentos para formar um corpo de conhecimento em Engenharia
de Software e é ressaltada a consequente necessidade de transferir conhecimento entre grupos de pesquisa. Na Seção 2.4 aborda-se sobre a transferência de conhecimento entre grupos de pesquisa e são
apontados alguns problemas observados.
2.1
Experimentos controlados
Em um experimento controlado é construído e avaliado um modelo que representa a aplicação
de métodos, técnicas e ferramentas (os objetos de estudo) durante atividades de desenvolvimento de
software. Assim, os participantes selecionados os aplicam sob condições controladas, produzindo
resultados cuja análise permite obter conclusões a respeito dessa aplicação.
Para avaliar o objeto de estudo em um experimento, é preciso isolar os fatores que o inﬂuenciam e,
de alguma maneira, captar os efeitos obtidos com a sua aplicação. Assim, o ponto de partida é a ideia
de uma relação de causa e efeito em teoria (Wohlin et al., 2000). Essa relação é formalizada em uma
5
2.1 Experimentos controlados
hipótese (ou um conjunto de hipóteses), que é testada durante o processo. A relação causal (expressa
na hipótese) é avaliada por meio da execução do experimento, como pode ser visto na Figura 2.1.
Objetivo do experimento
Teoria
construção
causa-efeito
construção
da causa
Observação
construção
do efeito
construção
tratamentoresultado
tratamentos
resultados
Variável dependente
Variável independente
Execução do experimento
Figura 2.1: Relação causal avaliada em um experimento controlado (Wohlin et al., 2000)
Os elementos que inﬂuenciam a aplicação do objeto de estudo são as váriáveis independentes.
Um experimento estuda o efeito da mudança de uma ou mais variáveis independentes, os fatores
(Wohlin et al., 2000). Os valores que um fator pode assumir são os tratamentos. Por exemplo, considerando um experimento cujo objetivo é analisar técnicas de Veriﬁcação e Validação (Basili e Selby,
1987), podem ser isolados os fatores tipo de técnica de teste aplicada e experiência dos participantes. Para o fator tipo de técnica, os tratamentos podem ser: leitura de código, teste estrutural e teste
funcional.
Conforme a atribuição de tratamentos, o efeito obtido pela execução varia. O efeito é representado
por meio da variável dependente, cujos valores correspondem aos resultados da execução de um
experimento. No exemplo, a variável dependente pode ser o número de defeitos encontrados por um
participante utilizando uma determinada técnica de teste. Assim como está esquematizado na Figura
2.2, as variáveis independentes são as entradas para a execução do experimento. E, de acordo com os
valores que assumem, o efeito das mudanças reﬂete no valor da variável dependente.
…
Variáveis
independentes
Processo
Variável
dependente
Figura 2.2: Variáveis independentes e dependentes de um experimento controlado (Wohlin et al.,
2000)
Os tratamentos são aplicados a uma combinação de objetos e participantes. Um objeto pode
6
2.1 Experimentos controlados
ser, por exemplo, os programas em que devem ser aplicadas as técnicas de teste. Os participantes
são as pessoas que aplicam os tratamentos. A execução do experimento consiste na execução de um
conjunto de testes (trials), em que cada teste é uma combinação de tratamento, participante e objeto
(Wohlin et al., 2000). Por exemplo, um teste pode ser a pessoa N (participante) aplicar uma técnica
T (tratamento) para inspecionar o programa P (objeto). A partir da execução dos testes, são coletados
os resultados do experimento.
2.2
Processo de experimentação
Há uma sequência de passos para estabelecer e analisar um modelo que reﬂita o relacionamento
causa-efeito em termos de fatores, variáveis dependentes e objetos. Uma abordagem sistemática, aqui
descrita como um processo de experimentação, deve ser adotada com a ﬁnalidade de alcançar o nível
de controle que um experimento requer. De acordo com a Figura 2.3, o processo sugerido por Wohlin
et al. (2000) é composto pelas fases: deﬁnição, planejamento, operação, análise e interpretação e
apresentação e empacotamento.
,GHLDSDUDR
([SHULPHQWR
'HILQLomRGR([SHULPHQWR
'RFXPHQWRGH'HILQLomR
3URMHWR([SHULPHQWDO
3ODQHMDPHQWR
2SHUDomR
'DGRV&ROHWDGRV
$QiOLVHH,QWHUSUHWDomR
'DGRV&ROHWDGRV
$SUHVHQWDomRH
(PSDFRWDPHQWR
5HODWyULRGR([SHULPHQWR
Figura 2.3: Processo de experimentação (Wohlin et al. (2000); Garcia (2006))
A deﬁnição estabelece o escopo do experimento, que é deﬁnido em termos dos objetivos e metas.
No planejamento, as hipóteses são formalizadas e o projeto é determinado (o arranjo de quais participantes devem aplicar quais tratamentos). A operação é a execução do experimento propriamente
dita. Nessa fase as medidas dos resultados são coletadas e então avaliadas na fase de análise e interpretação. Por ﬁm, os procedimentos adotados, resultados e conclusões obtidos são armazenados na
fase de apresentação e empacotamento.
7
2.2 Processo de experimentação
2.2.1
Deﬁnição
A fase de deﬁnição fornece a descrição geral do experimento, estabelecendo o seu escopo, suas
metas e, consequentemente, a base para a formulação das hipóteses. As metas do experimento podem
ser deﬁnidas de acordo com o seguinte modelo:
Analisar <Objeto(s) do estudo>
com o propósito de <Propósito>
com respeito a <Foco de qualidade>
do ponto de vista de <Perspectiva>
no contexto de <Contexto>
O objeto do estudo é a entidade que é estudada no experimento, que pode ser uma técnica, um
método, um modelo, uma ferramenta ou um processo, por exemplo. O propósito do experimento
deﬁne o objetivo em termos gerais. Pode ser, por exemplo, comparar diferentes técnicas. O Foco de
qualidade é o efeito sob estudo no experimento. Alguns exemplos são efetividade, custo e conﬁabilidade. A perspectiva revela o ponto de vista do qual os resultados são interpretados (desenvolvedor,
gerente de projeto, cliente ou pesquisador). Por ﬁm, o contexto é o composto pela caracterização dos
participantes (experiência, tamanho de equipe, etc) e dos objetos, ou seja, dos artefatos que devem ser
usados no experimento (complexidade, tamanho, domínio de aplicação, etc).
2.2.2
Planejamento
A fase de planejamento estabelece como o experimento deve ser conduzido. A partir da deﬁnição
das metas do estudo, tem-se como produto o projeto experimental, em que tratamentos, objetos e
participantes são arranjados de modo a organizar como os testes devem ser executados.
Em primeiro lugar, o contexto do experimento (que foi apontado na fase de deﬁnição) deve ser
reﬁnado. É preciso decidir se o experimento vai ser executado em um ambiente real ou simulado e
se os participantes devem ser proﬁssionais ou estudantes, por exemplo. Tais decisões envolvem uma
análise dos riscos e custos envolvidos.
Em seguida, as hipóteses que expressam a relação de causa e efeito a ser estudada são formuladas.
Em geral, uma hipótese estatística é formulada unicamente com o propósito de não ser aceita (Juristo
e Moreno, 2001). Portanto, se a meta é comparar uma nova técnica de inspeção em relação a uma
técnica já existente, a hipótese nula (H0 ) poderia aﬁrmar que não há diferença na média de defeitos
encontrados por meio de ambas (H0 : μNe = μNn ). Essa é a hipótese que o experimentador quer
garantir que não seja aceita com o maior nível de conﬁança possível. Uma hipótese alternativa (Ha )
é a favor de que a hipótese nula não seja aceita. No exemplo dado, a hipótese alternativa aﬁrmaria
que a nova técnica encontra em média mais defeitos do que a técnica antiga (Ha : μNe < μNn ).
Uma vez que a relação sob estudo tenha sido expressa formalmente por meio das hipóteses, as
variáveis que representam a causa e o efeito são selecionadas. Entre as variáveis independentes,
algumas são mantidas a níveis ﬁxos e outras (os fatores) podem receber diferentes valores (os tratamentos), que também devem ser determinados durante essa fase. Quanto à variável dependente,
8
2.2 Processo de experimentação
deve ser derivada diretamente da hipótese e a medida escolhida para representá-la deve ser determinada. Por exemplo, a eﬁcácia de uma técnica de inspeção pode ser medida pela média de defeitos
encontrados pelos participantes.
Os participantes devem ser selecionados como uma amostra representativa da população à qual
se deseja generalizar os resultados do experimento. Aspectos como o tamanho da amostra e a aleatoriedade devem ser considerados. Quanto maior e mais aleatória a amostra de pessoas selecionadas, o
erro ao generalizar os resultados se torna menor.
Após selecionar as variáveis e os participantes, é possível elaborar o projeto experimental. O
projeto descreve como os testes devem ser organizados e executados durante a fase de operação do
experimento. No projeto também é estabelecida a quantidade de testes necessários para garantir que
o efeito dos tratamentos seja visível.
Antes da execução, também é feita a instrumentação do experimento, em que as instruções, os
objetos do experimento, as ferramentas e os formulários necessários são preparados. Por exemplo,
no caso de um experimento que investiga técnicas de inspeção, os defeitos devem ser inseridos nos
objetos a serem inspecionados. Instruções são necessárias para guiar os participantes ao longo do
experimento (além de um treinamento nas técnicas a serem aplicadas).
Por ﬁm, é importante considerar a validade dos resultados que serão obtidos com o experimento. É
preciso planejar para obter um experimento que apresente uma validade adequada dos seus resultados,
ou seja, as ameaças à validade devem ser analisadas desde antes da execução. Os resultados têm uma
validade adequada se são válidos à população para qual se deseja generalizá-los. De acordo com
Wohlin et al. (2000), há quatro tipos de validade: de conclusão, interna, de construção e externa.
A validade de conclusão, cuja ameaça pode ser a escolha de um teste estatístico inadequado, é
relacionada à habilidade de se chegar a uma conclusão correta a partir da relação entre os conjuntos
de tratamentos e os resultados do experimento. A validade interna garante que os resultados sejam
inﬂuenciados apenas por fatores que sejam controlados e medidos. A validade de construção conﬁrma
a coerência entre a teoria e a observação, ou seja, a relação causa-efeito está bem representada pelas
variáveis escolhidas. A validade externa se refere à capacidade de se generalizar os resultados para a
população de interesse, o que implica que os participantes do experimento devem ser selecionados de
forma a constituírem uma amostra representativa de tal população. Uma lista de ameaças à validade
de um experimento é dada em Wohlin et al. (2000) e pode ser usada como uma checklist durante a
fase de planejamento.
2.2.3
Operação
A fase de operação abrange a execução do experimento de fato. Como os estudos em Engenharia
de Software lidam com pessoas, grande parte do esforço envolvido nessa fase diz respeito a motivá-las
para se empenharem nas atividades, com o intuito de garantir resultados válidos com a execução.
Durante a operação os participantes devem ser selecionados e informados a respeito dos procedimentos. É importante que as pessoas estejam motivadas e dispostas a participar ao longo do experimento. Todos os instrumentos devem estar prontos: as instruções devem ser passadas e os formulários
entregues aos participantes.
A execução do experimento pode ser realizada em reuniões em que os participantes aplicam os
9
2.2 Processo de experimentação
tratamentos e geram dados. Esses resultados são coletados manualmente em formulários, com o apoio
de ferramentas ou por meio de entrevistas.
2.2.4
Análise e interpretação
Nessa fase os resultados da execução do experimento são analisados para que seja possível obter
conclusões sobre a técnica, método ou ferramenta em estudo. Os dados podem ser interpretados em
três passos: estatística descritiva, redução do conjunto de dados e teste da hipótese.
Após coletar os dados, a estatística descritiva pode ser usada para apresentar aspectos dos dados,
como a tendência central e a dispersão. Alguns gráﬁcos que podem ser utilizados são: gráﬁco de dispersão (scatter plot), histograma e gráﬁco de setores. A partir dos gráﬁcos gerados, é possível detectar
distorções (outliers), ou seja, pontos de dados que divergem muito dos outros. Quando outliers são
identiﬁcados, é preciso analisar as razões que os ocasionaram para decidir se devem ser eliminados
ou não. Em seguida, veriﬁca-se a validade da hipótese estabelecida na fase de planejamento. O teste
da hipótese tem o objetivo de rejeitar a hipótese nula, H0 , com base na amostra de resultados obtida
na execução. A escolha do teste estatístico depende de como o experimento foi projetado.
Por ﬁm, se a hipótese nula for descartada é possível obter conclusões sobre a inﬂuência das variáveis independentes nas variáveis dependentes, considerando que o experimento é válido (com base
na análise da validade dos resultados). Após descartar a hipótese nula, tira-se conclusões gerais sobre
a relação causa-feito sob estudo, considerando a validade externa do experimento. Se o experimento
não pôde rejeitar a hipótese nula não é possível aﬁrmar algo sobre a relação entre as variáveis.
2.2.5
Empacotamento
A fase de empacotamento tem como objetivo documentar todo o processo de experimentação, gerando como produto um pacote de laboratório. Uma documentação completa e detalhada é necessária
para, além de apresentar os resultados do estudo, facilitar a sua replicação.
Conforme o esquema da Figura 2.4, a melhor abordagem para a fase de empacotamento é que
seja executada ao longo do processo de experimentação e não apenas como etapa ﬁnal (Amaral e
Travassos, 2003), o que aumenta a ﬁdelidade do pacote de laboratório à condução do experimento
(Garcia, 2006).
O pacote de laboratório transmite o conhecimento que deve ser transferido entre pesquisadores a
ﬁm de reportar os resultados experimentais e permitir que sejam feitas replicações, o que contribui
para o avanço da disciplina de Engenharia de Software e para a sua respectiva aplicação no mercado
(Basili e Zelkowitz, 2007).
A realização de replicações pode ser estimulada pela disponibilidade de pacotes de laboratório
(Shull et al., 2002). Além disso, dada a quantidade de esforço requerido para conduzir um experimento, é razoável facilitar o reuso de artefatos experimentais providenciando um pacote de laboratório
(Brooks et al., 2008). A partir da revisão de pacotes de laboratório, os pesquisadores têm acesso a
como os estudos já realizados foram conduzidos.
10
2.3 Replicações
Definição
Planejamento
Operação
?
Análise &
Interpretação
?
Empacotamento
Pacote de
Laboratório
Figura 2.4: Processo de experimentação - fase de empacotamento (Wohlin et al. (2000); Amaral e
Travassos (2003))
2.3
Replicações
Um experimento está sujeito a diversas variações, como o ambiente cultural em que é executado
ou a habilidade e experiência dos participantes selecionados (Basili et al. (1999); Shull et al. (2003);
Mendonça et al. (2008)). As condições impostas durante a execução de um estudo limitam a população à qual se aplicam as conclusões obtidas (ver Figura 2.5). Por exemplo: se foram selecionados
alunos de graduação como participantes de um estudo para avaliar técnicas de teste, as conclusões
obtidas não podem se aplicar diretamente a proﬁssionais de Engenharia de Software. Apenas a replicação de experimentos em diferentes contextos torna possível veriﬁcar a validade de uma hipótese
com um nível de conﬁança maior (Miller (2005); Shull et al. (2008)).
Ambiente
cultural
Background pessoal
e experiência
Diferentes condições
durante a execução
conclusões
sobre a técnica
Figura 2.5: Papel da replicação
Idealmente, os resultados experimentais devem ser reproduzíveis externamente e, portanto, a inﬂuência dessas variações deve ser estudada. Por meio de outros pesquisadores reproduzindo com
sucesso um experimento, a conﬁança nos resultados se constrói (Brooks et al., 2008). A ﬁm de
11
2.3 Replicações
possibilitar a condução de replicações e o uso do conhecimento adquirido em cada experimento é
fundamental registrar de forma precisa todo o procedimento de condução do experimento no pacote
de laboratório (Garcia, 2006). O pacote de laboratório deve ser um artifício para lidar com a evolução
do experimento através de múltiplos estudos.
Entretanto, Shull et al. (2002) apontaram que, apesar de os pacotes de laboratório estarem disponíveis, pesquisadores enfrentam diﬁculdades em entendê-los e revisá-los. As principais diﬁculdades
consistem em entender os conceitos das técnicas sob estudo e dominar o conhecimento envolvido na
execução de um experimento (Shull et al., 2002). Em geral, os replicadores pertencem a um contexto
diferente daquele dos projetistas do experimento original, têm uma perspectiva diferente. Essa diferença de contextos pode diﬁcultar o entendimento do pacote de laboratório. Por outro lado, o fato
de pesquisadores de contextos diferentes replicarem um estudo contribui para a capacidade de generalização de resultados obtidos, o que é fundamental para estender as conclusões do estudo a uma
população cada vez mais abrangente.
Ao notar problemas de transferência de conhecimento como entraves à realização de replicações,
Mendonça et al. (2008) propuseram o FIRE (Framework for Improving the Replication of Experiments), um arcabouço composto pelos dois ciclos de atividades ilustrados na Figura 2.6. O ciclo
interno representa a execução de um estudo dentro de um grupo de pesquisa. No ciclo externo,
inter-grupos, estão as atividades que se encarregam de integrar o conhecimento gerado pelo estudo
do ciclo interno num corpo comum, de tal maneira que seu pacote de laboratório possa ser efetivamente revisado por eventuais replicadores de outro grupo de pesquisa. O framework trata de questões
como a padronização e o entendimento de pacotes de laboratório, que contribuem na transferência de
conhecimento a grupos de outros contextos, dispostos a replicar o estudo.
Ciclo Externo
padronizar
pacotes
compartilhar
conhecimento
criar/evoluir
corpo de
conhecimento
criar/evoluir
pacote e
armazenar
experiência
Ciclo Interno
analisar e
integrar
dados
executar
experimento
definir
objetivos do
experimento
projetar
experimento,
identificar
participantes, e
obter/adaptar
artefatos
planejar e
coordenar
iniciativas
compreender
experimentos e
pacotes de
laboratório
Figura 2.6: Ciclos do FIRE (Mendonça et al., 2008)
A atividade de criar/evoluir o pacote de laboratório, no ciclo interno, inﬂuencia na atividade de
compartilhar conhecimento, no ciclo externo. Da mesma maneira, no outro ponto em que os ciclos
12
2.3 Replicações
se interceptam, compreender os experimentos e os pacotes de laboratório é fundamental para se
deﬁnir os objetivos de uma nova replicação. Pode-se perceber, portanto, que o pacote de laboratório
representa a saída do ciclo interno portando consigo as informações de um estudo e também a entrada
do ciclo interno de uma possível replicação, uma vez que os pesquisadores devem revisá-lo e entender
a execução do experimento original.
2.4
Transferência de conhecimento
Compartilhar conhecimento experimental entre grupos de pesquisa é inerente à experimentação
em Engenharia de Software (Mendonça et al., 2008). Apoiar a realização de replicações requer a
transferência de conhecimento entre os pesquisadores responsáveis pelo experimento original – fornecedores do conhecimento – e os replicadores – usuários do conhecimento.
Conforme pode ser visto na Figura 2.7, a transferência de conhecimento apresenta quatro fases:
• Socialização entre replicadores, que involve o diálogo sobre a escolha do projeto experimental,
variáveis, métodos de coleta de dados e procedimentos para a análise dos dados;
• Exteriorização, em que é feito o registro de anotações, dicas, projeto experimental, dados brutos, análises e resultados;
• Combinação, em que as informações que devem compor o pacote de laboratório são selecionadas e
• Internalização do conhecimento por replicadores, com a leitura, abstração e interpretação das
informações que compõem o pacote de laboratório.
conhecimento tácito
conhecimento tácito
Exteriorização
anotações
dados brutos
conhecimento explícito
conhecimento tácito
documentos
Pacote de
Laboratório
Pacote de
Laboratório
Internalização
o
conhecimento explícito
conhecimento tácito
Socialização entre replicadores
Combinação
conhecimento explícito
conhecimento explícito
Figura 2.7: Modelo de compartilhamento de conhecimento em experimentação (Shull et al., 2004)
13
2.4 Transferência de conhecimento
Há dois tipos de conhecimento que pode ser transferido entre os pesquisadores: conhecimento tácito e conhecimento explícito. O conhecimento explícito se refere às informações que compõem o pacote de laboratório. Por meio de sua revisão, replicadores podem adquirir esse tipo de conhecimento.
O conhecimento tácito se refere às informações que são importantes para entender o experimento,
mas não estão especiﬁcadas explicitamente (Shull et al., 2004). A ﬁm de que o conhecimento tácito
relativo à execução de um experimento seja transferido a replicadores de outros grupos de pesquisa é
preciso que se torne explícito no pacote de laboratório.
A transferência de conhecimento entre grupos de pesquisa se conﬁgura nas atividades de interface
entre os ciclos do FIRE e é um ponto chave para possibilitar melhores replicações. Mendonça et al.
(2008) salientam que o foco não pode ser dado apenas ao ciclo interno, pois há o risco de os estudos
se tornarem isolados. É preciso integrá-los em um corpo comum de conhecimento. Um dos fatores
que contribuem com a transferência de conhecimento proveniente de um estudo é a padronização
do conjunto de informações gerado, como pode ser observado nas atividades que compõem o ciclo
externo do FIRE.
2.4.1
Pacotes de laboratório e artigos cientíﬁcos
O pacote de laboratório é o artefato que contém as informações geradas por um estudo e, portanto, se constitui em um meio de transferir conhecimento entre diferentes grupos de pesquisa. Cada
fase do processo de experimentação gera informações sobre os procedimentos adotados. Essas informações e o conhecimento ganho ao longo do experimento devem compor o pacote de laboratório.
Assim, de maneira a compartilhar conhecimento e favorecer um melhor entendimento dos pacotes
de laboratório no ciclo externo do FIRE, o modo com que as suas informações devem ser representadas é de extrema importância, o que se conﬁrma também pela atividade de padronização de pacotes.
Disponibilizar pacotes de laboratório ampara a realização de mais replicações, mas pacotes bem projetados são cruciais para a realização de melhores replicações (Shull et al., 2004). Portanto, deve ser
promovida uma melhor representação ao gerar o seu conteúdo.
Uma outra maneira de transferir conhecimento acerca de um experimento controlado é por meio
da publicação de um artigo, apresentando os procedimentos adotados, resultados e conclusões obtidos. Artigos devem ser publicados na literatura de Engenharia de Software Experimental para que os
experimentos tenham um valor cientíﬁco comparável ao de estudos em outras áreas (Carver, 2010).
2.4.2
Diretrizes para reportar experimentos controlados
Assim como os pacotes de laboratório, os artigos sobre experimentos também apresentam a necessidade de serem padronizados. É preciso haver diretrizes para apoiar pesquisadores, revisores e
meta-analistas durante o projeto, condução e avaliação de experimentos (Kitchenham et al., 2002).
Algumas diretrizes foram propostas para se reportar estudos experimentais em Engenharia de Software, visando a padronizar o conjunto de informações gerado por um experimento. Jedlitschka et al.
(2008) organizaram uma comparação entre elas, que é apresentada na Tabela 2.1.
Na primeira linha da Tabela 2.1 são identiﬁcadas as propostas de Singer (1999), Wohlin et al.
(2000), Kitchenham et al. (2002), Juristo e Moreno (2001) e Jedlitschka et al. (2007). No restante das
linhas são listados os elementos (seções) de todas as diretrizes propostas, mapeando-as à estrutura da
14
2.4 Transferência de conhecimento
proposta apresentada em Jedlitschka et al. (2007).
Para cada conjunto de diretrizes proposto, a sua respectiva entrada na Tabela 2.1 fornece os elementos que devem compor a estrutura de um artigo de experimento. Na Tabela 2.2, os elementos da
proposta de Jedlitschka et al. (2007) são detalhados em termos de conteúdo, escopo e prioridade, o que
permite identiﬁcar quais informações acerca do experimento devem ser relatadas e a sua organização
no artigo.
Tabela 2.1: Visão geral das diretrizes para reportar experimentos controlados (Jedlitschka et al., 2008)
Singer (1999)
*
*
resumo
*
introdução
introdução
método
procedimento
resultados
Wohlin
et
al.
(2000)
*
*
*
*
introdução
declaração do problema
planejamento do
experimento
declaração do problema
planejamento do
experimento
operação do experimento
análise de dados
Kitchenham et al.
(2002)
*
*
*
*
*
contexto
experimental
contexto
experimental
projeto experimental
condução do experimento e coleta de
dados
análise
Juristo e Moreno
(2001)
*
*
*
*
deﬁnição de metas
Jedlitschka et al.
(2007)
título
autores
resumo estruturado
palavras-chave
introdução
deﬁnição de metas
background
projeto
planejamento
experimento
execução
execução do experimento
do
análise experimen- análise
tal
discussão
interpretação de re- interpretação de re- análise experimen- discussão
sultados
sultados
tal
discussão
discussão e conclu- *
análise experimen- conclusões e trabasão
tal
lhos futuros
agradecimentos
referências
referências
*
*
referências
apêndices
apêndice
*
*
apêndices
Os asteriscos (*) indicam que os elementos são implicitamente requeridos, apesar de não serem explicitamente mencionados.
Tabela 2.2: Diretrizes propostas por Jedlitschka et al. (2007)
Seção
Título
Conteúdo
Escopo
Prioridade
<título> + “um experimento controlado”; É infor-
Requerido
mativo e inclui os principais tratamentos e variáveis
dependentes?
(continuação na próxima página)
15
2.4 Transferência de conhecimento
Tabela 2.2: Diretrizes propostas por Jedlitschka et al. (2007) (continuação)
Seção
Conteúdo
Autores
Escopo
Prioridade
Inclui informações de contato, por exemplo, um
Requerido
e-mail válido?
Resumo
Background
Por que essa pesquisa é importante?
Requerido
estruturado
Objetivo
Qual é a questão abordada com essa pesquisa?
Requerido
Métodos
Qual é o contexto estatístico e quais os métodos apli-
Requerido
cados?
Resultados
Quais são as principais descobertas? Implicações
Requerido
práticas?
Limitações
Quais são os pontos fracos dessa pesquisa?
Conclusões
Qual é a conclusão?
Requerido
Áreas de pesquisa dos tratamentos, variáveis depen-
Pode ser reque-
dentes e tipo de estudo
rido pelo editor
Qual é o problema? Onde ocorre? Quem o obser-
Requerido
Palavras-chave
Introdução
Declaração
vou?
do problema
Por que é importante que seja resolvido?
Objetivo da
Qual é a questão de pesquisa a ser respondida por
pesquisa
este estudo? Exemplo usando o modelo GQM:
Requerido
Analisar <objeto(s) do estudo>
com o propósito de <propósito>
com respeito a <foco de qualidade>
do ponto de vista de <perspectiva>
no contexto de <contexto>
Contexto
Qual informação é necessária para compreender se a
Requerido
pesquisa se relaciona a uma situação especíﬁca (ambiente)?
Background
Tecnologia
O que é necessário que o leitor saiba sobre a tecno-
Necessário
sob investi-
logia para reproduzir sua aplicação?
não
gação
se
estiver
publicado
em
outro lugar
Tecnologias
Como essa pesquisa se relaciona a tecnologias alter-
Requerido
alternativas
nativas? Qual é o tratamento de controle?
Estudos rela-
Como essa pesquisa se relaciona aos estudos já exis-
cionados
tentes? Quais foram os resultados desses estudos?
Relevância
Como se relaciona ao estado da prática?
Se disponível
Formalização das metas, reﬁnamento das constru-
Requerido
Se disponível
na prática
Planejamento
do experimento
Metas
ções importantes (por exemplo, foco na qualidade)
das metas do experimento
(continuação na próxima página)
16
2.4 Transferência de conhecimento
Tabela 2.2: Diretrizes propostas por Jedlitschka et al. (2007) (continuação)
Seção
Conteúdo
Escopo
Prioridade
Unidades
De qual população as amostras serão tiradas? Como
Requerido
experimen-
os grupos serão formados (atribuição aos tratamen-
tais
tos)? Qualquer tipo de aleatoriedade ou blinding
deve ser descrito
Material ex-
Quais objetos são selecionados e por quê?
Requerido
Tarefas
Quais tarefas devem ser realizadas pelos indivíduos?
Requerido
Hipóteses,
Quais são as construções e sua operacionalização?
Necessário (um
parâmetros e
Elas devem ser derivadas da questão de pesquisa e
estudo explora-
variáveis
da meta do experimento
tivo pode não
perimental
ter hipóteses)
Projeto
Execução
Que tipo de projeto experimental foi escolhido?
Requerido
Procedimento Como o experimento será realizado (por exemplo,
Pode ser inte-
coleta de dados)? Quais instrumentos, materiais,
grado à execu-
ferramentas serão usados e como?
ção
Procedimento Como os dados serão analisados?
Pode ser inte-
da análise
grado à análise
Preparação
O que foi feito para preparar a execução do experimento (por exemplo, horários, treinamento)
Desvios
Descreve qualquer desvio do planejado, por exemplo, como a coleta de dados foi realizada de fato?
Análise
Estatística
Quais são os resultados de estatística descritiva?
Requerido
descritiva
Preparação
O que foi feito para preparar o conjunto de dados,
do conjunto
como e por quê?
de dados
Discussão
Teste da hi-
Como os dados foram avaliados e como o modelo de
pótese
análise foi validado?
Avaliação
Explicar os resultados e a relação dos resultados de
dos
pesquisa anterior, especialmente o que foi mencio-
resul-
tados
e
nado na seção Background
implicações
Ameaças
validade
à
Como a validade dos resultados experimentais é ga-
Requerido
rantida? Como os dados foram validados de fato?
Devem ser discutidas as ameaças que podem ter um
impacto na validade dos resultados (por exemplo,
variáveis de confusão, viés, a extensão em que a hipótese captura os objetivos, a generalização dos resultados)
(continuação na próxima página)
17
2.4 Transferência de conhecimento
Tabela 2.2: Diretrizes propostas por Jedlitschka et al. (2007) (continuação)
Seção
Conteúdo
Escopo
Prioridade
Inferências
Inferências obtidas a partir dos dados em direção a
Requerido
condições mais gerais
Conclusões
e
Lições
Qual experiência foi adquirida ao longo do experi-
aprendidas
mento
Resumo
Resumo conciso da pesquisa e de seus resultados
trabalhos
futuros
Recomendado
Requerido
como apresentado nas seções anteriores
Impacto
Descrição dos impactos com relação aos custos, cronograma e qualidade, circunstâncias sob as quais a
abordagem pode não trazer os benefícios esperados
Trabalhos
Quais outros experimentos podem ser executados
futuros
para investigar os resultados obtidos ou para evoluir
Requerido
o corpo de conhecimento
Agradecimentos
Agências de fomento, participantes e colaboradores
Se for necessá-
que não cumprem os requisitos para a autoria devem
rio
ser mencionados
Referências
A literatura citada deve ser apresentada no formato
Requerido
requerido pelo editor
Apêndices
Materiais do experimento, os dados brutos e as aná-
Podem ser dis-
lises detalhadas, o que pode ser útil para outros pes-
ponibilizados
quisadores desenvolverem seus trabalhos
em
relatórios
técnicos ou em
páginas da Web
Em geral, os pesquisadores não adotam um padrão para reportar os experimentos, apesar de haver
as diretrizes propostas para isso. Cada autor usa a sua própria maneira de organizar o artigo (Carver,
2010). A irregularidade das maneiras de reportar os experimentos controlados em Engenharia de
Software é um grande problema encontrado para integrar os respectivos resultados em um corpo
comum, o que indica a necessidade de padronização (Jedlitschka et al., 2008).
2.5
Considerações ﬁnais
Neste capítulo foi apresentada uma visão geral sobre experimentos controlados e suas replicações, identiﬁcando alguns problemas na transferência de conhecimento entre grupos de pesquisa de
Engenharia de Software. Um dos fatores desses problemas é a falta de padronização dos pacotes de
laboratório. Não há um padrão amplamente adotado para reportar experimentos, apesar de diretrizes
terem sido propostas nesse sentido.
Essas questões sugerem o estabelecimento de uma estrutura para pacotes de laboratório. Nesse
sentido, uma ontologia pode ser usada para descrever o modelo das informações que compõem um
pacote de laboratório, visando a prover um padrão e favorecer um melhor entendimento.
Segundo Uschold e Gruninger (1996), pesquisadores de campos de pesquisa diferentes, mas relacionados, não conseguem usar facilmente os resultados uns dos outros. Isso acontece porque os
pesquisadores têm uma perspectiva diferente ou usam termos diferentes para descrever as mesmas
18
2.5 Considerações ﬁnais
ideias subjacentes. Para resolver este problema, deve-se reduzir confusão conceitual e terminológica e obter um entendimento compartilhado das informações trocadas (Uschold e Gruninger (1996);
Uschold e Gruninger (2004)).
Nesse contexto, ontologias podem ser proveitosas para lidar com o problema na transferência de
conhecimento. Ontologias deﬁnem vocabulários comuns para pesquisadores que precisam compartilhar informação acerca de um domínio (Noy e McGuinness, 2001). Assim, no capítulo seguinte
é fornecida a fundamentação teórica necessária para investigar a aplicação de uma ontologia como
padrão do conjunto de informações contido em um pacote de laboratório.
19
C APÍTULO
3
Ontologia
Ontologias podem ser utilizadas para permitir que pesquisadores tenham acesso a fontes de informação heterogêneas que são expressas usando vocabulários diversos ou formatos inacessíveis (Biolchini et al., 2007). Considerando o papel de ontologias em representação e compartilhamento de
conhecimento (Gruber (1995); Noy e McGuinness (2001)), o objetivo principal deste capítulo é investigar a aplicação de uma ontologia para lidar com os problemas relativos a integração e transferência
de conhecimento em Engenharia de Software Experimental.
Na Seção 3.1 é dada uma introdução sobre ontologias. Na Seção 3.2 são apontados trabalhos
que propõem a aplicação de ontologias em Engenharia de Software Experimental. Dentre eles, a
EXP ER Ontology, uma ontologia para experimentos controlados, é apresentada em detalhes na Seção
3.3. Por ﬁm, são apresentados os processos de evolução de ontologias (Seção 3.4) e de matching de
ontologias/esquemas (Seção 3.5). Esses processos podem ser necessários para compor uma solução
que aplique ontologias para resolver problemas de entendimento compartilhado.
3.1
Visão geral sobre ontologia
Em Ciência da Computação, uma ontologia é um artefato que contém um modelo da estrutura
de um domínio, ou seja, entidades e relações que emergem de sua observação (Pretorius (2004);
Guarino et al. (2009)). Uma deﬁnição mais completa seria: “uma ontologia é uma especiﬁcação
formal e explícita de uma conceituação compartilhada” (Gruber (1995), Studer et al. (1998)).
Uma conceituação é uma visão abstrata e simpliﬁcada do mundo que se deseja representar para
algum propósito (Guarino et al., 2009). Tal visão é constituída de conceitos desse mundo e suas
relações (ver exemplo na Figura 3.1). Ao elaborar a conceituação (ver Figura 3.2), obtém-se uma
captura dos conceitos do domínio que devem compor a ontologia. A ideia do que vem a ser o domínio
de interesse ﬁca expressa de maneira explícita sob a forma de conceitos e relações entre eles.
Adicionalmente, deve haver uma especiﬁcação formal dos conceitos, em um formato que seja
legível por máquinas. Para isso, uma ontologia é formalizada por meio de alguma linguagem, que
proveja a restrição da interpretação de seus conceitos por meio de axiomas lógicos. Uma ontologia
20
3.1 Visão geral sobre ontologia
pode ser considerada como um conjunto de tais axiomas.
Gerente (João)
Programador (Julia)
Programador (Pedro)
Figura 3.1: Domínio de recursos humanos, adaptado de Guarino et al. (2009)
Pessoa
1..* Programador
Gerente
reportaA
1..*
1
1..*
trabalhaCom
Figura 3.2: Conceituação do domínio de recursos humanos
Um axioma do domínio de exemplo, em Lógica de Primeira Ordem, que deﬁne o vínculo entre
dois programadores que trabalham juntos é dado por:
(∀p1 , p2 )trabalhaCom(p1 , p2 ) → reportaA(p1 , g) ∧ reportaA(p2 , g)
em que p1 e p2 representam programadores e g o gerente ao qual p1 e p2 estão subordinados. Por se
tratar de uma representação formal, uma ontologia permite a inferência de informações adicionais às
que estão declaradas.
Uma especiﬁcação formal de uma conceituação não é, necessariamente, uma especiﬁcação de uma
conceituação compartilhada (Guarino et al., 2009). A ﬁm de que o conhecimento seja compartilhado
entre as partes que utilizam a ontologia, deve haver concordância sobre o que está sendo comunicado.
O conhecimento deve ser consensual entre as partes.
Portanto, pode-se aﬁrmar que uma ontologia é uma especiﬁcação de conhecimento consensual
sobre um modelo abstrato de domínio, deﬁnida explicitamente em termos de conceitos e seus relacionamentos por meio de axiomas, possibilitando, assim, que seja legível por máquinas.
Desenvolver uma ontologia envolve uma sequência de fases, conforme pode ser visto na Figura
3.3. Em termos gerais, é preciso adquirir conhecimento sobre o domínio e elaborar a sua conceituação, ou seja, descrever um modelo conceitual. Em seguida, é feita a formalização do signiﬁcado dos
21
3.1 Visão geral sobre ontologia
conceitos estabelecidos por meio de axiomas lógicos. Implementar uma ontologia requer a escolha
de uma linguagem para representá-la. Depois de implementada, durante a manutenção, a ontologia
pode ser corrigida ou atualizada conforme houver mudanças no domínio.
Aquisição de
conhecimento
Conceituação
Formalização
Implementação
Manutenção
Figura 3.3: Processo de desenvolvimento de uma ontologia (Goméz-Pérez, 1999)
Cada linguagem de representação de conhecimento provê diferentes habilidades para expressar
ontologias. O mais recente desenvolvimento em linguagem padrão é OWL1 (Web Ontology Language), uma recomendação W3C (World Wide Web Consortium). Ontologias OWL podem ser vistas
como um conjunto de sentenças lógicas (em Lógica Descritiva), que declaram e relacionam os componentes básicos da linguagem: classes, propriedades e instâncias.
As classes são organizadas em uma hierarquia e cada classe é deﬁnida por meio de restrições
de propriedade. Horridge (2009) apresenta um tutorial detalhado sobre a implementação de uma
ontologia em OWL, deﬁnindo de maneira mais detalhada os componentes e recursos da linguagem ao
longo do processo. Em termos práticos, uma ontologia OWL consiste em um documento com sintaxe
XML.
3.2
Ontologias para experimentos controlados em Engenharia de Software
Com o objetivo de lidar com as problemas na transferência de conhecimento entre grupos de pesquisa (ver Seção 2.3), uma ontologia pode ser aplicada como um padrão que favorece o entendimento
das informações do pacote de laboratório. Segundo Noy e McGuinness (2001), algumas das razões
para elaborar uma ontologia são compartilhar entendimento comum da estrutura da informação entre
pessoas ou agentes de software, permitir o reuso do conhecimento e tornar explícitas as suposições
sobre o domínio.
1
http://www.w3.org/TR/owl-guide/
22
3.2 Ontologias para experimentos controlados em Engenharia de Software
Biolchini et al. (2007) elaboraram uma ontologia para Engenharia de Software Experimental com
o objetivo de apoiar a condução de revisões sistemáticas (Kitchenham, 2004). Os conceitos referentes a experimentos controlados podem ser vistos na Figura 3.4. Nessa ontologia os conceitos são
deﬁnidos em um alto nível de abstração e, portanto, se for considerada a necessidade de transferir o
conhecimento gerado por um experimento, não são adequados para instanciar as informações de um
pacote de laboratório.
Primary
Study
Element
Structure of
Study
Problem
Hypothesis
Quality
of Study
Intervention
Control
Measurement
Outcome
Unit
of
Study
Figura 3.4: Ontologia da estrutura de um estudo experimental em Engenharia de Software (Biolchini
et al., 2007)
Ainda de uma perspectiva de alto nível, Lopes e Travassos (2009) propuseram a construção de
um repositório de conhecimento de experimentação, composto por ontologias elaboradas a partir
do trabalho de Biolchini et al. (2007). Conforme pode ser observado na Figura 3.5, as ontologias
deﬁnidas no repositório devem auxiliar o a infraestrutura eSEE (experimental Software Engineering
Environment) a instanciar ambientes para apoiar a condução de estudos experimentais.
Repositório de Conhecimento
de Experimentação em ES
Glossário
de Termos
(Dicionário)
Modelos
Conceituais
(Ontologias)
consulta
consulta
Pesquisador
eSEE
instancia
Ambiente de Experimentação
Figura 3.5: Ambiente de Engenharia de Software Experimental com um repositório de conhecimento
(Lopes e Travassos, 2009)
23
3.2 Ontologias para experimentos controlados em Engenharia de Software
Sob outra perspectiva, Garcia et al. (2008) estabeleceram uma ontologia especíﬁca para experimentos controlados, a EXP ER Ontology, que descreve os conceitos que devem compor um pacote de
laboratório. A EXP ER Ontology tem o propósito de padronizar conceitos e facilitar o compartilhamento de pacotes de laboratório (Garcia et al., 2008).
3.3
EXP ER Ontology
A EXP ER Ontology foi elaborada para esclarecer os conceitos associados a experimentos controlados e seus relacionamentos (Garcia et al., 2008). A conceituação da ontologia está dividida em dois
níveis de reﬁnamento. O primeiro nível, na Figura 3.6, contém os principais conceitos de experimentos controlados. O segundo nível, na Figura 3.7 se refere ao reﬁnamento do conceito de pacote de
laboratório.
<<concept>>
Original experiment
generates
1
1..*
1 has
1
<<concept>>
Lab package
1
is basis for
1
0..*
1
<<concept>>
Replication
1
<<concept>>
Validity
has
1
1..*
1..*
1
0..*
generates
designs
conducts
<<concept>>
Replicator
1..*
<<concept>>
Designer
influences
1
has
1
is recorded
Figura 3.6:
EXP ER Ontology
1..*
<<concept>>
Experimenter Profile
0..1
1
has
1
1
- conceitos de experimentos controlados (Garcia et al., 2008)
Para formalizar a ontologia, foram criados axiomas de Lógica de Primeira Ordem. Por exemplo,
o predicado Design que associa tratamentos a cada participante do experimento é dado por:
Design(s, SetOf T reat)
em que s representa os participantes e SetOf T reat são os valores que os fatores podem assumir
(conjunto de tratamentos). Fatores, seus possíveis tratamentos e um conjunto de tratamentos são
deﬁnidos por:
F actor(f1 , . . . , fn )
∀f ∈ F actor, ∃T reatment(f ) = v1 , . . . , vn , n ≥ 2
dom(T reatment) = Artif act ∪ T echnology
SetOf T reat = (vf1 , . . . , vfn )|∀f, vfn ∈ T reatment(fn )
em que f deﬁne um fator do experimento, e vfn são tratamentos atribuídos para cada fn . A partir do
24
3.3 EXP ER Ontology
<<concept>>
Object of study
<<concept>>
Context
Statistical analysis
<<concept>>
Confirmatory analysis
1..*
- Technique : String
<<concept>>
Quality focus
<<concept>>
Purpose
<<concept>>
Exploratory analysis
is basis for
<<concept>>
Initial hypothesis
is basis for
generates 1
<<concept>>
Dependent variable
is defined from
1..*
1..* 1..*
1..*
is basis for
1..*
1
<<concept>>
Hypothesis formalised
1..* 1..*
<<concept>>
Independent variable
is defined from
- Null hypothesis : char
- Alternative hypothesis : char
1..*
uses as factor
1..*
1..*
1
1
can be a value of 1
1..*
is defined from
1..*
1
1
<<concept>>
Experimental design
uses as treatment
1
1..*
<<concept>>
Experiment object
<<concept>>
Technique
teaches in
1
1
1
1..*
<<concept>>
Technology
1..*
follows
1
1
<<concept>>
Execution Plan
1
<<concept>>
Training
1
<<concept>>
Analysis
is basis for
1..*
1..*
1
1..*
follows
1..*
1
is applied in
<<concept>>
Method
is obtained applying a
1..*
<<concept>>
Result
1..*
<<concept>>
Artifact
uses
1..*
1..*
Is obtained using in a
1..*
0..*
1..*
1
can use
1
0..*
<<concept>>
Subject
is obtained by
1..*
<<concept>>
Tool
1..*
1..*
1..*
1
is obtained during a
can be
1..*
<<concept>>
Task
- Period : int
has
1
<<concept>>
Document
<<concept>>
Questionnaire
<<concept>>
Form
1
Figura 3.7:
<<concept>>
Profile
EXP ER Ontology
describes
<<concept>>
Task planned
<<concept>>
Task performed
1..*
- conceitos de um pacote de laboratório (Garcia et al., 2008)
predicado Design é estabelecido o plano para a condução do experimento, o qual é detalhado em um
conjunto de tarefas:
(∀s, SetOf T reat)(Execution(s, SetOf T reat) → T ask(ta1 ) ∧ . . . ∧ T ask(tan ))
em que tan deﬁne as tarefas que devem ser seguidas durante a fase de operação. Por sua vez, cada
tarefa é deﬁnida como:
T ask(tan ) → (T raining(s, tr , a, p) ∨ Applying(s, te , a, p))
em que o predicado T raining indica que um participante s pode ser treinado em uma tecnologia tr
usando o artefato a durante um período de tempo p. De maneira semelhante, Applying indica que um
25
3.3 EXP ER Ontology
participante s aplica a tecnologia tr no artefato a durante um período de tempo p.
Na EXP ER Ontology são deﬁnidos conceitos de todo o processo de experimentação (Wohlin et
al., 2000), desde a deﬁnição até a análise dos resultados. Assim, as informações de um experimento
controlado que compõem o pacote de laboratório podem ser dadas pelos conceitos da ontologia instanciados. Contextualizando no processo de desenvolvimento de ontologias da Figura 3.3, Garcia et
al. (2008) apresentaram a Conceituação (conceitos e relacionamentos) e a Formalização (um conjunto
de axiomas) da EXP ER Ontology.
3.4
Evolução de ontologias
Uma ontologia pode contribuir na transferência de conhecimento ao ser adotada como o padrão
de informações trocadas. Entretanto, ontologias não podem ser concebidas como um modelo estático.
Uma ontologia é tão requerida para a troca de conhecimento quanto a troca de conhecimento pode
inﬂuenciar e modiﬁcar as deﬁnições da ontologia (Fensel, 2001). Evoluir ao longo do tempo é um
requisito essencial para que uma ontologia seja útil (Fensel, 2001).
A evolução de uma ontologia é a adaptação de suas deﬁnições ao longo do tempo para incorporar
mudanças em conjunto com a propagação consistente dessas mudanças aos artefatos dependentes
(Stojanovic et al. (2002)). O processo de evolução de ontologias proposto por Stojanovic (2004)
pode ser visto na Figura 3.8.
Representa
-ção
Semântica
da mudança
Implementação
Propagação
Processo de evolução de ontologia
Requisição
para uma
mudança
Mudança
requerida
Mudanças
requeridas
e derivadas
Modificação
de artefatos
dependentes
Ontologia
modificada
Figura 3.8: Processo de evolução de ontologia (Stojanovic, 2004)
Na primeira fase, representação, a requisição de uma mudança (em alto nível) é expressa em
termos de mudanças elementares à estrutura da ontologia. Um conjunto de mudanças elementares é
dado na Tabela 3.1. Se o usuário deseja remover um conceito do domínio, por exemplo, é preciso
expressar essa requisição em duas mudanças elementares: remover o relacionamento de herança que
existe da classe com a sua superclasse (RemoveSubConcept) e, então, fazer a remoção propriamente
dita da classe (RemoveConcept).
Em seguida, na fase de semântica da mudança, deve ser garantida a consistência do restante da
ontologia diante das mudanças a serem realizadas. No exemplo da Figura 3.9, a classe Technology
tem a propriedade isAppliedIn relacionando-a com a classe Artifact. As classes Method, Technique
e Tool são subclasses de Technology. Por serem subclasses, herdam a propriedade isAppliedIn
relacionando-as a Artifact.
Desse modo, SoftVizOAH , uma instância de Tool, apresenta uma instância da propriedade isAppliedIn. Entretanto, se a classe Technology é removida, a classe Tool deixa de herdar as suas pro26
3.4 Evolução de ontologias
Tabela 3.1: Mudanças elementares a uma ontologia (Stojanovic, 2004)
Entidades
Adicionar
Remover
Conceito
AddConcept
RemoveConcept
Hierarquia de conceitos
AddSubConcept
RemoveSubConcept
Propriedade
AddProperty
RemoveProperty
Hierarquia de propriedades
AddSubProperty
RemoveSubProperty
Domínio de propriedade
AddPropertyDomain
RemovePropertyDomain
Contradomínio de propriedade AddPropertyRange
RemovePropertyRange
Propriedade simétrica
AddPropertySymmetric RemovePropertySymmetric
Propriedade transitiva
AddPropertyTransitive RemovePropertyTransitive
Propriedade inversa
AddPropertyInverse
RemovePropertyInverse
Cardinalidade máxima
AddMaxCardinality
RemoveMaxCardinality
Cardinalidade mínima
AddMinCardinality
RemoveMinCardinality
Instância de classe
AddInstanceOf
RemoveInstanceOf
Instância de propriedade
AddPropertyInstance
RemovePropertyInstance
Artifact
Artifact
isAppliedIn
isAppliedIn
Technology
Method
GanttProject
Technique
Tool
isAppliedIn
SoftVizOAH
Method
GanttProject
Technique
Tool
isAppliedIn
SoftVizOAH
(b) Ontologia inconsistente após deletar o conceito Technology
(a) Ontologia consistente
Figura 3.9: Introdução de inconsistências após a realização de uma mudança
priedades, fazendo com que a instância ﬁque inconsistente com a deﬁnição da classe. Uma mudança
pode engatilhar muitas outras a ﬁm de manter a ontologia consistente. Portanto, o papel da fase de
semântica da mudança é a resolução de maneira sistemática de mudanças induzidas.
Na fase de propagação das mudanças é preciso apontar automaticamente todos os artefatos e
programas dependentes da ontologia que serão afetados pelas mudanças. Na última fase, implementação, todas as mudanças (requeridas e derivadas) são de fato aplicadas.
O ponto do processo de evolução que merece especial atenção é a derivação de mudanças adicionais àquela que o usuário solicitou, seja às deﬁnições da ontologia ou aos artefatos dependentes. É
preciso garintir que o processo de evolução seja realizado de maneira consistente (Haase e Stojanovic,
2005).
27
3.5 Matching de ontologias/esquemas
3.5 Matching de ontologias/esquemas
Um dos pricipais objetivos em se adotar uma ontologia é compartilhar entendimento comum da
estrutura da informação entre pessoas ou agentes de software que se comunicam (Noy e McGuinness,
2001). Entretanto, a informação a ser trocada entre diversas partes pode ser modelada de acordo com
a estrutura adotada por cada um. Quando esquemas distintos são elaborados para um mesmo domínio,
quase sempre são diferentes uns dos outros (Halevy, 2005). Para haver de fato entendimento comum
da estrutura da informação é preciso identiﬁcar similaridades entre os elementos dos esquemas de
cada um (Hakimpour e Geppert, 2001).
O matching de esquemas/ontologias é um processo de encontrar correspondências entre fragmentos de informação, que são modelados usando diferentes estruturas e formatos, como esquemas
de banco de dados, documentos XML ou ontologias (Rahm, 2011). São tomados como entrada dois
esquemas, cada um consistindo de um conjunto de entidades (por exemplo: tabelas, elementos XML,
classes, propriedades, regras, predicados) e determina-se como saída as correspondências que existem
entre essas entidades (Shvaiko e Euzenat, 2005).
A deﬁnição de uma correspondência estabelecida entre duas entidades e e e de dois esquemas/ontologias o e o , respectivamente, pode ser formalizada pela estrutura (Euzenat e Shvaiko, 2007):
e, e , r, n
em que:
• e e e são entidades (como classes e propriedades) de o e o respectivamente;
• r é uma relação (como equivalência (≡), subsunção (), disjunção (⊥)) que existe entre e e e ;
• n é uma medida de conﬁança (tipicamente do intervalo [0, 1]) para a correspondência entre e e
e .
A correspondência e, e , r, n declara que a relação r existe entre as entidades e e e com um nível
de conﬁança n. Um exemplo simples de correspondência é:
Experiment =0.8 ControlledExperiment
que declara a relação de equivalência (r) com conﬁança de 0.8 (n) entre as conceitos Experiment (e)
e ControlledExperiment (e ).
Ao realizar o matching, um conjunto de correspondências deve ser encontrado, provavelmente
considerando o produto cartesiano dos conjuntos de entidades a serem comparadas dos esquemas o e
o . Esse conjunto de correspondências é chamado de alinhamento e consiste na saída do processo de
matching. Um exemplo de alinhamento seria:
Experiment =0.8 ControlledExperiment
Person ≥1.0 Subject
Participant =1.0 Subject
28
3.5 Matching de ontologias/esquemas
Na Figura 3.10 é dada uma visão geral do matching: é determinado um alinhamento A para um
par de esquemas/ontologias o e o (Euzenat e Shvaiko (2007); Shvaiko e Euzenat (2012)). Há algumas
outras entradas opcionais que podem estender essa deﬁnição, como: (i) parâmetros para as técnicas
de matching (pesos, thresholds) e (ii) recursos externos (por exemplo, um vocabulário especíﬁco do
domínio de ambos os esquemas).
recursos
O
Matching
A'
O'
parâmetros
Figura 3.10: Matching de esquemas/ontologias, representado como uma operação com entradas e
saída (Euzenat e Shvaiko, 2007)
3.5.1
Processo de matching
Em um nível maior de detalhes, pode-se considerar o matching como um processo, composto de
várias etapas, conforme é apresentado na Figura 3.11. Na etapa de pré-processamento, os elementos
dos esquemas são postos em condições de serem analisados. Em seguida, técnicas de matching são
executadas e estabelecem as similaridades entre as entidades dos esquemas. Depois, os resultados de
cada técnica são combinados e é gerado um conjunto preliminar de correspondências. Por ﬁm, há a
seleção de correspondências que devem compor o alinhamento resultante. Uma das maneiras mais
comuns de selecionar correspondências é aplicar um threshold às medidas de conﬁança (n).
Esquemas
de entrada
S1
Préprocessamento
Execução do
Matcher
Combinação
de resultados
do matcher
Seleção de
correspondências
Alinhamento
Resultante
S2
Figura 3.11: Processo de matching de esquemas (Rahm, 2011)
Durante a execução propriamente dita, as técnicas têm o objetivo de encontrar as relações entre
os elementos. Em geral, essas relações são descobertas por meio da medida de similaridade entre
29
3.5 Matching de ontologias/esquemas
os elementos dos esquemas/ontologias (Euzenat e Shvaiko, 2007) (que faz o papel de medida de
conﬁança na estrutura de uma correspondência).
As técnicas escolhidas para serem executadas dependem do tipo dos elementos dos esquemas de
entrada, mais especiﬁcamente, das características que esses elementos oferecem para serem comparadas entre si. Para realizar o matching de duas classes de uma ontologia, por exemplo, algumas
características que podem ser comparadas são os identiﬁcadores (nomes) das classes, os atributos
(propriedades) de cada uma ou os relacionamentos mantidos com as outras classes.
Cada uma dessas técnicas pode ser representada como uma função (σ), que toma como entrada
duas entidades, uma de cada esquema (O1 e O2 ), e calcula a medida de similaridade (ou distância)
entre elas:
σ :E×E →R
em que E = E1 ∪ E2 , sendo E1 o conjunto de entidades do esquema O1 e E2 o conjunto de entidades
de O2 . Algumas técnicas calculam uma medida de dissimilaridade entre as entidades, por meio de
uma função de distância (δ). Vale ressaltar que a similaridade normalizada (σ) no intervalo [0, 1]
corresponde a dissimilaridade normalizada (δ) de acordo com a equação δ = 1 − σ.
Nas tabelas 3.2 e 3.3 há duas matrizes com os resultados que foram obtidos ao aplicar duas técnicas distintas aos identiﬁcadores dos conceitos de dois esquemas. Para fazer a combinação desses
resultados, um dos métodos que podem ser aplicados é manter a distância mínima (ou similaridade
máxima) entre dois elementos correspondentes da matriz, o que resulta na matriz da Tabela 3.4.
Tabela 3.2: Distância de edição entre nomes dos conceitos (Euzenat e Shvaiko, 2007)
Book Translator Publisher Writer
Product 0.86
0.8
0.89
0.86
Provider 0.88
0.8
0.56
0.5
Creator 0.86
0.5
0.89
0.57
Tabela 3.3: Distância entre nomes de conceitos calculada com o apoio de um tesauro (Euzenat e
Shvaiko, 2007)
Book Translator Publisher Writer
Product 0.82
0.88
0.88
0.85
Provider 0.83
0.89
0.76
0.71
Creator 0.82
0.53
0.88
0.85
Tabela 3.4: Matriz resultante da combinação dos resultados (Euzenat e Shvaiko, 2007)
Book Translator Publisher Writer
Product 0.82
0.8
0.88
0.85
Provider 0.83
0.8
0.56
0.5
Creator 0.82
0.5
0.88
0.57
3.5.2
Técnicas de matching por tipo de entrada
Calcula-se a similaridade entre elementos dos esquemas por meio de uma análise das características fornecidas pelos elementos dos esquemas. Portanto, o tipo de entrada do processo de matching
30
3.5 Matching de ontologias/esquemas
inﬂuencia na determinação do conjunto de técnicas que podem ser utilizadas. De acordo com os
levantamentos bibliográﬁcos de Rahm e Bernstein (2001), Shvaiko e Euzenat (2005) e Euzenat e Shvaiko (2007), os tipos de entradas fornecidas ao processo de matching podem ser categorizados em
termos, estruturas (interna e relacional), instâncias e modelo semântico.
As técnicas baseadas em termos (nomes) podem indicar a similaridade entre entidades dos esquemas pela comparação de seus identiﬁcadores, labels, ou até mesmo comentários. Ao extrair os
termos referentes às entidades de um esquema, as técnicas podem interpretá-los de duas maneiras
durante o cálculo da similaridade: simplesmente como strings (sequências de caracteres) ou como
palavras (entradas em um dicionário).
Técnicas baseadas em strings consideram os termos como uma sequência de caracteres. A possibilidade mais simples para determinar a similaridade entre duas strings s e t é o teste de igualdade
entre elas:
σ(s, t) =
⎧
⎨0
se s = t
⎩1
se s = t
Pode-se testar a igualdade após realizar alguma normalização sintática, como transformar todos
os caracteres em letras minúsculas (caixa baixa) e eliminação de pontuação. Por exemplo, C.D. se
torna cd. Essa abordagem não considera que strings com estruturas similares (e não idênticas) podem
se referir a conceitos similares e, portanto, caso as strings comparadas apresentem qualquer caractere
diferente, mesmo que seja apenas um, o teste de igualdade resulta em 0.
Por essa razão, existem técnicas mais tolerantes nesse sentido. Duas strings podem ser consideradas similares quando uma é substring da outra, por exemplo. Desse modo, pode ser calculada a
similaridade de substring, que expressa a proporção da sequência de caracteres em comum entre duas
strings. Seja S o conjunto de todas as strings, |x| o comprimento da string x e t a maior substring
comum entre x e y, a similaridade de substring é deﬁnida pela função σ : S × S → [0, 1] tal que
∀x, y ∈ S:
σ(x, y) =
2|t|
|x| + |y|
Por outro lado, se os termos são considerados como palavras, são utilizados recursos linguísticos
externos, como dicionários, tesauros e terminologias. Assim, conceitos como Participant e Subject,
que contêm estruturas muito diferentes entre si, podem ser identiﬁcados como similares se for usada
uma terminologia em que essas entradas constem como sinônimos.
Terminologias são vocabulários de domínio especíﬁco e tendem a ser menos ambíguos do que
dicionários e tesauros. As entradas de uma terminologia são mais adequadas quando os textos ou esquemas a serem casados dizem respeito ao mesmo domínio, por reterem acepções mais especializadas
ou até mesmo acepções que não existem na linguagem cotidiana.
Além de comparar os termos, pode-se comparar a estrutura das entidades contidas em um esquema: tanto a estrutura individual de uma entidade (estrutura interna), quanto a estrutura formada
pelos relacionamentos entre as entidades (estrutura relacional). As estruturas internas de duas enti-
31
3.5 Matching de ontologias/esquemas
dades podem ser comparadas com base nos atributos que elas possuem. Compara-se os seus tipos
de dados e seus identiﬁcadores (utilizando as técnicas baseadas em termos). Quando há estruturas
relacionais, compara-se os grafos ou as árvores hierárquicas que as entidades e os relacionamentos
formam.
As técnicas baseadas em instâncias comparam as informações instanciadas a ﬁm de indicar o
relacionamento que existe entre as entidades do esquema que as modela. A ideia é que se dois
conceitos compartilham o mesmo conjunto de instâncias, pode-se presumir que são similares. Essas
técnicas são aplicadas quando as informações relativas ao esquema são limitadas ou em situações em
que os esquemas não são fornecidos junto aos dados.
A aplicação de uma técnica baseada em um modelo semântico restringe-se a ontologias, pois
depende da presença de um conjunto de axiomas lógicos que descrevam as entidades. Como primeiro
passo, são estabelecidas âncoras ou correspondências semente (que podem ser informadas pelo usuário ou obtidas por meio das demais técnicas). Em seguida, são utilizados sistemas capazes de inferir
os relacionamentos entre as entidades (reasoners).
3.6
Considerações ﬁnais
Neste capítulo foi apresentada uma introdução a ontologias e noções gerais sobre processos de
evolução e matching, que podem ser utilizados para aplicá-las em soluções de software cujo objetivo
é lidar com a falta de entendimento compartilhado. Também foram apresentados trabalhos relacionados, que propõem a aplicação de ontologias em Engenharia de Software Experimental. Dentre
esses trabalhos, a EXP ER Ontology (Garcia et al., 2008) é uma ontologia que pode ser utilizada para
padronizar pacotes de laboratório.
Com essa abordagem, é possível apoiar as atividades do FIRE (Mendonça et al., 2008) que focam
na transferência de conhecimento: criar/evoluir pacote (ciclo interno), compartilhar conhecimento,
padronizar pacotes, criar/evoluir corpo de conhecimento e compreender experimentos e pacotes de
laboratório (ciclo externo). Isso motivou a deﬁnição de um workﬂow de empacotamento de experimentos controlados em Engenharia de Software, que usa uma ontologia como estrutura para instanciar
as informações, apresentado no capítulo seguinte.
32
C APÍTULO
4
Workﬂow para empacotar experimentos
controlados
Muitos experimentos em Engenharia de Software vêm sendo conduzidos e seus resultados publicados, mas cada pesquisador publica o conjunto de informações que julga ser mais importante
(Carver, 2010). Não há um padrão amplamente adotado para as informações que devem ser geradas
em um pacote de laboratório. Nesse contexto, uma ontologia pode ser adotada como o modelo para
instanciar as informações, a ﬁm de padronizá-las e facilitar o seu entendimento.
Entretanto, acomodar os diferentes conjuntos de informação que um pacote de laboratório pode
conter sugere que a ontologia adotada como padrão deve evoluir, incorporando novos conceitos. Assim, além de utilizar a ontologia para instanciar as informações, é preciso considerar a prática atual
dos pesquisadores ao reportar um experimento.
A ﬁm de lidar com essas necessidades identiﬁcadas, neste trabalho de mestrado é proposto um
workﬂow de empacotamento de experimentos controlados usando como base uma ontologia. Na
Seção 4.1 são descritos de maneira geral os requisitos que o workﬂow deve cumprir e são identiﬁcadas
as suas atividades. Em seguida, na Seção 4.2, as atividades identiﬁcadas são instanciadas com a
escolha de opções para implementá-las.
4.1
Deﬁnição do comportamento do workﬂow
Devido à necessidade de estabelecer um padrão que seja capaz de incorporar diferentes conjuntos
de informação, é preciso lidar com as diferentes perspectivas sobre o que deve conter um pacote de
laboratório. A meta, ilustrada na Figura 4.1, é contribuir na integração de estudos isolados em um
corpo comum com base na padronização por meio de uma ontologia.
Nesse sentido, para empacotar as informações de um estudo, é preciso identiﬁcar qual conceito
deﬁnido na ontologia corresponde a cada elemento de informação do pacote de laboratório a ser
padronizado. Em uma situação ideal, assim como está representado na Figura 4.2, para cada elemento
de informação existe um conceito deﬁnido na ontologia e, assim, todos os elementos de informação
33
4.1 Deﬁnição do comportamento do workﬂow
pacotes de laboratório
…
ontologia
Figura 4.1: Integração de pacotes de laboratório usando ontologia
ontologia
pacote de laboratório
Figura 4.2: Empacotamento com ontologia - situação ideal
são instanciados.
Na Figura 4.3 está representada uma outra situação, que tem grande probabilidade de acontecer
devido à falta de padronização dos pacotes de laboratório: alguns elementos de informação ﬁcam sem
conceito correspondente deﬁnido. Esses elementos que sobram podem sugerir conceitos que devem
ser inseridos na ontologia a ﬁm de habilitá-la para acomodar o pacote de laboratório satisfatoriamente.
ontologia
pacote de laboratório
Figura 4.3: Empacotamento com ontologia - situação em que sobram elementos de informação
O empacotamento de acordo com a ontologia envolve uma sequência de atividades embutidas nas
situações descritas. Para modelar o seu comportamento, neste trabalho é proposta a identiﬁcação e a
organização dessas atividades em um workﬂow, que recebe como entradas a ontologia (contendo os
conceitos de experimentos controlados) e um pacote de laboratório (contendo as informações de um
experimento) e devolve como saída um pacote de laboratório padronizado de acordo com a ontologia.
Integrando todas as atividades do workﬂow e as entradas e saídas de cada uma, obtém-se o diagrama da Figura 4.4. A partir do pacote de laboratório de entrada, a atividade de matching do
34
4.1 Deﬁnição do comportamento do workﬂow
workﬂow determina os elementos de informação que casam com os conceitos (correspondências) e os
que não casam. Assim, são fornecidas as entradas das demais atividades.
Os elementos não casados precisam ser resolvidos pelo usuário, o que possivelmente requer a
evolução da ontologia. Quando o usuário associa um elemento a um conceito, esse par se torna uma
correspondência também. Todas as correspondências, estabelecidas automaticamente pelo matching
ou manualmente pelo usuário, são instanciadas em um novo pacote de laboratório, sob o formato de
uma ontologia.
Pacote de
Laboratório
Matching
Ontologia
Elementos
não casados
Correspondências
Evolução
Instanciação
apoio do
usuário
Pacote de
Laboratório
Padronizado
Resolução
Figura 4.4: Diagrama com todas as atividades do workﬂow e suas respectivas entradas e saídas
4.1.1
Atividade de Matching
A atividade de matching, representada na Figura 4.5, toma como entradas a ontologia e o pacote
de laboratório e deve retornar as correspondências e os elementos para os quais não foram encontrados
conceitos correspondentes. Uma vez que o pacote de laboratório seja ao menos semiestruturado, é
possível aplicar técnicas de matching de esquemas/ontologias, conforme discutido na Seção 3.5.
De uma maneira geral, matching de esquemas é o meio para se resolver a heterogeneidade semântica entre esquemas (Halevy, 2005). No caso dos repositórios de conhecimento de Engenharia
de Software Experimental, os grupos de pesquisa de Engenharia de Software empacotam estudos de
acordo com esquemas distintos, sendo que esses pacotes de laboratório precisam ser integrados em
um corpo comum. Integração de informação é uma das classes de aplicações mais recorrentes em que
o matching é visto como uma solução plausível (Euzenat e Shvaiko, 2007).
É nesse sentido que uma ontologia pode ser utilizada como padrão para integrar os estudos com
diferentes conjuntos de informação. Pode ser feito o matching dos esquemas dos pacotes (proveni35
4.1 Deﬁnição do comportamento do workﬂow
entes de grupos de pesquisa distintos) com a ontologia, no intuito de instanciá-los em uma mesma
estrutura de informação.
Pacote de
Laboratório
Ontologia
Matching
Elementos
não casados
Correspondências
Figura 4.5: Atividade de matching do workﬂow
4.1.2
Atividades de Instanciação, Resolução e Evolução
A partir da atividade de matching do workﬂow, são obtidas:
• as correspondências, que associam os elementos de informação do pacote de laboratório aos
respectivos conceitos da ontologia e
• os elementos não casados, aos quais não foram encontrados conceitos deﬁnidos.
O conjunto de correspondências é a entrada da atividade de instanciação do workﬂow (Figura
4.6). Para cada par elemento-conceito, é gerada uma instância no pacote de laboratório de saída, que
é dado no formato de uma ontologia.
Correspondências
Instanciação
Pacote de
Laboratório
Padronizado
Figura 4.6: Atividade de instanciação do workﬂow
Quanto aos elementos de informação não casados, é preciso ter a intervenção do usuário para decidir qual o conceito correspondente em que cada elemento deve ser instanciado. Assim, na atividade
36
4.1 Deﬁnição do comportamento do workﬂow
de resolução (Figura 4.7), as entradas são os elementos de informação que sobraram da atividade de
matching e os conceitos da ontologia e as saídas são as correspondências estabelecidas pelo usuário.
Elementos
não casados
Ontologia
Resolução
apoio do
usuário
Correspondências
Figura 4.7: Atividade de resolução do workﬂow
Um elemento de informação sobra da atividade de matching por um dos seguintes motivos: o
processo de matching não foi capaz de determinar uma correspondência com um nível de conﬁança
suﬁciente ou realmente não há um conceito deﬁnido na ontologia que seja adequado para instanciar o
elemento. Ambos os casos são tratados na atividade de resolução.
Entretanto, o segundo caso requer que, antes da resolução, o conceito faltante seja inserido na
ontologia. Assim, na atividade de evolução (Figura 4.8), o usuário analisa os elementos de informação
não casados e, caso seja necessário, adequa as deﬁnições da ontologia para possibilitar a instanciação.
A requisição de uma mudança pelo usuário nas deﬁnições da ontologia é cumprida ao longo de um
processo de evolução, conforme exposto na Seção 3.4.
Elementos
não casados
apoio do
usuário
Evolução
Ontologia
Figura 4.8: Atividade de evolução do workﬂow
37
4.2 Instância do workﬂow
4.2
Instância do workﬂow
Na seção anterior, o funcionamento geral das atividades do workﬂow foi apresentado. Entretanto,
não foi determinado o modo como devem ser implementadas. Dessa maneira, determinando de maneira concreta os métodos para implementá-las e como devem ser as entradas e saídas, é obtida uma
instância do workﬂow de empacotamento da Figura 4.4.
4.2.1
Entradas do workﬂow
O workﬂow toma como entradas um pacote de laboratório e a ontologia. Existem diversos formatos em que o pacote de laboratório de entrada pode estar representado. Entre os formatos possíveis,
pode-se citar os estruturados (tais como as bases de dados), os semiestruturados (os documentos
XML, por exemplo) e os não estruturados (documentos escritos em linguagem natural). Diante disso,
é preciso que seja estabelecido um formato padrão para o pacote de laboratório de entrada.
Assim, é possível determinar quais técnicas são adequadas para aplicação na atividade de matching. Mesmo que não seja padronizado, o pacote de laboratório de entrada deve ser ao menos semiestruturado, de modo a fornecer como entrada ao workﬂow um conjunto de elementos de informação
para ser equiparado ao conjunto de conceitos deﬁnidos na ontologia.
Para conseguir estabelecer uma solução que permita abranger desde formatos estruturados até não
estruturados, pode-se adotar como formato padrão a linguagem XML. Dessa maneira, os pacotes de
laboratório de entrada devem ser mapeados para um documento XML (como o exemplo da Figura
4.9) a ﬁm de se tornar uma entrada do workﬂow.
<OriginalExperiment title="An experimental comparison of ER
and UML class diagrams for data modelling">
<LabPackage>
<InitialHypothesis>
<Description> Analysing whether UML class diagrams
are more comprehensible than ER diagrams
</Description>
<ObjectOfStudy> ER and UML class diagrams </ObjectOfStudy>
<Purpose> Compare ER and UML class diagrams </Purpose>
<QualityFocus> Comprehension support </QualityFocus>
<Context> University students </Context>
</InitialHypothesis>
<FormalizedHypothesis>
<NullHypothesis> There is no difference between the support
provided by ER and UML class diagrams when performing
comprehension tasks on data models
</NullHypothesis>
<AlternativeHypothesis> ComprehensionSupport(UML) >
ComprehensionSupport(ER)
</AlternativeHypothesis>
</FormalizedHypothesis>
Figura 4.9: Trecho de um pacote de laboratório em documento XML
No caso de uma base de dados, por exemplo, pode ser feito um mapeamento direto para o formato XML, uma vez que as informações se encontram segmentadas em elementos de informação
(tabelas com seus respectivos atributos). Já um documento em linguagem natural, como um artigo,
não apresenta as informações de modo segmentado. Não obstante, os elementos de informação estão
38
4.2 Instância do workﬂow
presentes no documento. Apesar de não estarem estruturados, estão dispersos em meio ao texto. A
extração desses elementos requer uma atividade adicional de pré-processamento para mapeá-los a
elementos XML.
Quanto à ontologia, a EXP ER Ontology pode ser adotada, pois apresenta conceitos referentes
às informações que um pacote de laboratório deve conter (vide Seção 3.3). Garcia et al. (2008)
apresentaram a conceituação e a formalização da ontologia. Portanto, a ﬁm de poder utilizá-la de
maneira concreta como entrada do workﬂow, é preciso implementá-la. No contexto do processo de
desenvolvimento de ontologias da Figura 3.3, é preciso realizar a fase de Implementação. Para isso,
foi adotada a linguagem OWL para expressar os conceitos, relacionamentos e axiomas da ontologia.
A implementação da EXP ER Ontology foi realizada neste trabalho com o auxílio da ferramenta
Protégé1 , um editor de ontologias. A ferramenta auxilia a modelagem de uma ontologia e gera o
arquivo OWL com as deﬁnições dos conceitos, seus relacionamentos e os axiomas lógicos (que restringem a interpretação do signiﬁcado). Dessa maneira, obteve-se as deﬁnições dos conceitos da
ontologia disponíveis para possibilitar o matching.
No instantâneo da Figura 4.10 é possível ver a deﬁnição da classe InitialHypothesis. O painel
da esquerda mostra a hierarquia de classes da ontologia e o da direita exibe detalhes da deﬁnição da
classe selecionada com as respectivas restrições de propriedade.
Figura 4.10: Instantâneo da EXP ER Ontology no editor Protégé
1
http://protege.stanford.edu
39
4.2 Instância do workﬂow
4.2.2
Atividade de matching
Deﬁnidos os formatos das entradas, é possível escolher quais técnicas de matching podem ser
aplicadas (vide Seção 3.5.2). A ontologia fornece vários tipos de entrada para o matching: termos
(nomes das classes e das propriedades), a estrutura formada pela hierarquia de classes, a estrutura do
grafo formado pelos relacionamentos entre classes e o modelo semântico dos axiomas. Entretanto,
duas entidades de dois esquemas distintos são comparadas por meio de características que apresentam
em comum.
Logo, só podem ser usadas características que tanto as entidades da ontologia quanto do pacote de
laboratório apresentem para serem comparadas. Sendo a linguagem XML o formato padrão do pacote
de laboratório, o máximo que se pode garantir é que o conteúdo de cada elemento de informação
tenha um identiﬁcador (tag). Apesar de a linguagem XML permitir a organização hierárquica dos
elementos, é possível que todos os elementos estejam no mesmo nível, não garantindo, portanto, uma
estrutura para ser analisada.
Nesse caso, a similaridade dos pares conceito-elemento pode ser calculada apenas por meio da
comparação entre os seus respectivos identiﬁcadores (o nome do conceito e a tag do elemento de
informação). Portanto, considerando que e, e , r, n é a estrutura de uma correspondência, a similaridade n entre os elementos e e e pode ser dada por técnicas baseadas em termos, sendo que os termos
podem ser considerados como strings (apenas a estrutura do termo) ou como palavras (entradas em
um dicionário).
Com apenas técnicas baseadas em strings, a atividade de matching do workﬂow seria capaz de
casar apenas elementos de informação identiﬁcados com os mesmos termos usados nos conceitos
da EXP ER Ontology (ou termos com estrutura muito parecida, como Hypothesis e Hypotheses).
Contudo, os termos usados pelos pesquisadores para reportar os experimentos controlados não são
padronizados, a terminologia da área é confusa (Sjøberg et al., 2005). Portanto, há uma grande
possibilidade de que elementos possam ser referentes a conceitos expressos na ontologia, mas estejam identiﬁcados por termos sinônimos dentro do contexto de Engenharia de Software Experimental
(como Subject e Participant).
Diante disso, é preciso aumentar a capacidade do workﬂow de gerar correspondências de maneira
automática por meio do matching. A ﬁm de lidar com essa situação, é possível usar como apoio ao
matching um recurso externo que relacione os identiﬁcadores dos conceitos com os seus sinônimos.
Nesse sentido, foi adotada a estratégia de utilizar uma terminologia como recurso externo, uma vez
que deﬁne relações entre termos de um domínio especíﬁco (Euzenat e Shvaiko, 2007).
As entradas da terminologia são os identiﬁcadores dos conceitos deﬁnidos na EXP ER Ontology.
Cada entrada contém um conjunto de termos similares (possivelmente vazio). Por exemplo, para o
conceito NullHypothesis da ontologia, a entrada correspondente na terminologia é:
<NullHypothesis>
<SimilarTerms> H0 </SimilarTerms>
</NullHypothesis>
Considerando o formato das entradas do workﬂow e as técnicas de matching escolhidas, a estratégia adotada para realizar o matching entre os conceitos da ontologia e os elementos de informação
40
4.2 Instância do workﬂow
é apresentada no Algoritmo 1. As principais entradas são os conjuntos de conceitos (O) e de elementos de informação (E). As demais entradas são o recurso externo de apoio, a terminologia de
Engenharia de Software Experimental (T ), e o parâmetro de entrada, um threshold (α) a ser aplicado
nas similaridades calculadas. As saídas são os conjuntos de correspondências e de elementos não
casados.
Algoritmo 1: Estratégia adotada para a atividade de matching
Input:
E: conjunto de elementos de informação
O: conjunto de conceitos da EXP ER Ontology
T : Terminologia
α: threshold de similaridade mínima exigida
Output:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
M : conjunto de correspondências
E: conjunto de elementos não casados
M =∅
forall the e ∈ E do
matched = f alse
simmax = max(termSimilarity(e.name,ci .name)), ci ∈ O
if simmax > α then
cmatched = ci
matched = true
else
matched = f alse
simmax = max(termSimilarity(e.name,tj )), tj ∈ termEntry(T ,ci ), ci ∈ O
if simmax > α then
cmatched = ci
matched = true
end if
19:
end if
if matched = true then
retira e de E
cria uma correspondência m = e, cmatched , =, simmax insere m em M
20:
end if
21:
end forall
16:
17:
18:
Dado um elemento de informação (e), são calculados os valores da similaridade entre o nome do
elemento (e.name) e os nomes dos conceitos da ontologia (ci .name). Se o maior valor de similaridade
encontrado (simmax ) exceder o threshold (α), o respectivo conceito é selecionado (cmatched ).
Caso o maior valor não exceda o threshold (α), é feita a compação com os termos da terminologia (tj .name). São calculados os valores de similaridade entre o nome do elemento (e.name) e
41
4.2 Instância do workﬂow
os termos similares de cada conceito (tj .name ∈ termEntry(T, ci ). De maneira similar, se o maior
valor encontrado (simmax ) exceder o threshold (α), o conceito da ontologia (ci ) cujo termo similar
(tj ) apresentou a maior similaridade é selecionado (cmatched ).
Por ﬁm, se algum conceito foi selecionado, é estabelecida a correspondência (m) entre ele e o
elemento de informação, com nível de conﬁança igual ao maior valor de similaridade encontrado.
O elemento de informação é retirado do conjunto de entrada (E) e a correspondência é inserida no
conjunto de saída (M ).
4.2.3
Atividade de instanciação
Cada pacote de laboratório de saída do workﬂow é representado como uma ontologia individual
de instâncias (em OWL). Para que as deﬁnições da EXP ER Ontology ﬁquem acessíveis às ontologias
que contêm os pacotes de laboratório instanciados, a EXP ER Ontology é importada em cada uma
delas. Uma ontologia OWL pode importar outra ontologia a ﬁm de ganhar acesso a suas entidades e
axiomas, o que provê a capacidade básica de modularização (W3C, 2009). A importação permite que
cada pacote de laboratório seja representado em uma ontologia distinta que contém as instâncias dos
conceitos da EXP ER Ontology, como o esquema da Figura 4.11.
PL1.owl
PL2.owl
import
EXPEROntology.owl
PL3.owl
…
PLn.owl
Figura 4.11: Ontologias de instâncias e a EXP ER Ontology
A ontologia gerada com a ferramenta Protégé (vide Seção 4.2.1) contém a deﬁnição dos conceitos
da EXP ER Ontology, cujo papel é servir de modelo para o conhecimento gerado por cada experimento
controlado. A ferramenta Protégé também possibilita a criação de instâncias, além da deﬁnição de
classes e propriedades. Entretanto, as instâncias do pacote de laboratório devem ser criadas automaticamente a partir das correspondências identiﬁcadas, o que requer que a instanciação seja implementada de modo a tomar como entrada o conjunto de correspondências e devolver como saída uma
ontologia composta de instâncias dos conceitos da EXP ER Ontology.
Portanto, na atividade de instanciação é gerada uma ontologia OWL para o pacote de laboratório
padronizado, que importa as deﬁnições da EXP ER Ontology. Em seguida, para cada correspondência,
é criada e adicionada uma instância do conceito indicado na estrutura da correspondência.
42
4.2 Instância do workﬂow
4.2.4
Atividades de resolução e evolução
Nas atividades de resolução e evolução, o usuário é responsável por lidar com os elementos de
informação não casados. Na resolução, após analisar um elemento, o usuário escolhe um conceito
deﬁnido na EXP ER Ontology para estabelecer uma correspondência.
Estabelecer a correspondência de maneira manual requer que o usuário analise os conceitos deﬁnidos na ontologia e tenha o apoio da terminologia de Engenharia de Software Experimental (utilizada
como recurso externo do matching). A terminologia fornece os termos similares de cada conceito, o
que ajuda a identiﬁcar um conceito referente ao elemento de informação.
Além disso, o usuário pode contribuir na melhoria desse recurso com a adição de mais termos
similares aos conceitos da ontologia. Dessa maneira, a terminologia vai sendo preenchida conforme
o workﬂow é executado. Essa abordagem implica em melhorias para as próximas vezes em que a
resolução e o matching forem executados.
Caso não esteja deﬁnido um conceito adequado para instanciar um determinado elemento de informação, por meio da atividade de evolução o usuário é capaz de solicitar mudanças à deﬁnição da
ontologia a ﬁm de permitir a instanciação do elemento pendente. Essas mudanças devem ser consideradas dentro do contexto do processo de evolução de ontologias. Deve-se buscar manter a coerência
ao longo das mudanças e, portanto, é preferível que não sejam geradas mudanças derivadas. Limitar o
processo de evolução a admitir apenas mudanças de adição faz com que esse objetivo seja atingido.
Assim, garante-se a consistência da ontologia de deﬁnições (EXP ER Ontology) e das ontologias de
instâncias (os pacotes de laboratório já instanciados) ao longo das mudanças realizadas. O processo
de evolução é ainda mais simpliﬁcado nesse caso, porque as mudanças admitidas pelo workﬂow a
partir da análise dos elementos de informação abrangem apenas mudanças de adição de conceitos.
Os conceitos da EXP ER Ontology são representados como classes OWL na implementação da
ontologia. Por serem classes OWL, estão organizadas em uma hierarquia. Portanto, as mudanças
admitidas na atividade de evolução do workﬂow são apenas duas:
• AddClass(newClass) e
• AddSubclass(newClass,class).
O usuário pode apenas solicitar que seja criada (AddClass(newClass)) e inserida uma nova subclasse
a alguma classe previamente deﬁnida (AddSubclass(newClass,class)). O impacto dessas mudanças
de adição é mínimo e gerenciável, como pode ser visto na Tabela 4.1. Basta ao usuário estar ciente
desses impactos a ﬁm de evitá-los.
Vale ressaltar que as mudanças realizadas na ontologia são reﬂetidas na terminologia utilizada
como recurso externo de apoio ao matching e à resolução. Se um novo conceito é adicionado à
EXP ER Ontology, então é criada uma nova entrada na terminologia referente ao termo. Quanto às
mudanças que podem ser efetuadas na terminologia por meio do workﬂow, o usuário pode solicitar
que seja inserido um novo termo similar à entrada de um conceito da ontologia:
• AddSimilarTerm(newT erm,class).
43
4.3 Considerações ﬁnais
Tabela 4.1: Impacto de mudanças de adição de conceitos em uma ontologia (Abgaz et al., 2011)
Mudança
Descrição do impacto
AddClass(newClass)
Nova classe “órfã”: acontece quando um conceito é introduzido sem uma subclasse além da classe Thing (a classe
que abrange todas as instâncias em OWL).
AddSubclass(newClass,class) Nova classe insatisfatível: acontece quando há uma relação
de hierarquia entre class e uma outra classe otherClass da
ontologia e newClass e otherClass são disjuntas.
4.3
Considerações ﬁnais
Neste capítulo foi proposto um workﬂow para empacotar experimentos controlados, que inclui
uma abordagem evolutiva para a instanciação de pacotes de laboratório em uma ontologia. O uso
da ontologia como padrão das informações geradas por um experimento tem a meta de lidar com
problemas de transferência de conhecimento entre grupos de pesquisa em Engenharia de Software.
A proposta tem fundamentação no arcabouço FIRE estabelecido por (Mendonça et al., 2008). De
acordo com o FIRE, para integrar conhecimento ou evoluir os repositórios de conhecimento, é preciso
padronizar pacotes. De fato, Carver (2010) enfatiza a importância da padronização do conjunto de
informações reportado de um experimento.
Conforme os pacotes de laboratório são instanciados por meio do workﬂow, a ontologia pode
se aproximar de um padrão semântico que permite acomodar variações de pacotes de laboratório, e
portanto, a evolução da EXP ER Ontology aprimora a sua aplicação em empacotar experimentos.
No capítulo seguinte é apresentada uma avaliação da proposta, com a operacionalização do workﬂow e a demonstração de sua execução, utilizando como entrada publicações de experimentos controlados.
44
C APÍTULO
5
Avaliação do workﬂow
Para avaliar o workﬂow proposto, é preciso exercitar cada uma de suas atividades. Assim, a
partir das deﬁnições (Capítulo 4), é preciso operacionalizá-lo com a implementação de cada uma
delas. Como entrada do workﬂow, é considerado um pacote de laboratório contendo um conjunto
de informação que descreve o experimento. Nesse sentido, qualquer descrição de experimento pode
ser usada, inclusive uma publicação de experimento encontrada na literatura. Nesse caso, é preciso
providenciar a extração dos elementos de informação dos artigos que descrevem os experimentos
(Cruzes et al., 2007).
Neste capítulo é apresentada a avaliação da proposta deste projeto de mestrado, utilizando publicações de experimentos controlados como pacotes de laboratório de entrada. Na Seção 5.1 é dada uma
visão geral da ferramenta PontoLab++, que implementa as atividades do workﬂow, admitindo pacotes
de laboratório de entrada sob o formato XML. Na Seção 5.2, é apresentada a implementação de um
pré-processamento que realiza a extração de elementos de informação dos artigos e gera documentos
XML aptos a serem admitidos como pacotes de laboratório de entrada. Também é demonstrada a
execução do workﬂow por meio da ferramenta PontoLab++.
5.1
Ferramenta PontoLab++
A ferramenta PontoLab++ consiste na implementação da instância do workﬂow de empacotamento descrita na Seção 4.2. Foi utilizada a linguagem de programação Java, o que possibilitou a
adoção das APIs JDOM1 e OWL API2 para a manipulação de documentos XML e OWL, respectivamente.
Na interface inicial (Figura 5.1), o usuário ajusta o diretório de entrada (que contém os arquivos
XML com os elementos de informação de experimentos controlados) e o diretório de saída (que deve
conter os arquivos OWL com os pacotes de laboratório instanciados). A partir do diretório de entrada
selecionado, é gerada uma lista dos arquivos nele contidos e o usuário escolhe o pacote de laboratório
1
2
http://www.jdom.org
http://owlapi.sourceforge.net
45
5.1 Ferramenta PontoLab++
de entrada. As demais entradas do matching, como a EXP ER Ontology, a terminologia e o threshold
são conﬁguradas separadamente, conforme pode ser visto na Figura 5.2.
Figura 5.1: PontoLab++ - Interface inicial com os ajustes para a execução do workﬂow
Figura 5.2: PontoLab++ - Interface com os demais ajustes para a execução do workﬂow
Após realizar o matching, são exibidos ao usuário os conjuntos de elementos casados (Figura
5.3) e de elementos não casados (Figura 5.4). Para cada elemento selecionado, são exibidos o
nome do elemento (Name), o seu conteúdo (Content) e, no caso de um elemento casado, a classe
da EXP ER Ontology com a qual foi estabelecida uma correspondência (Class).
O usuário pode, então, fazer a resolução de cada elemento de informação não casado. Para isso, é
46
5.1 Ferramenta PontoLab++
Figura 5.3: PontoLab++ - Interface com o conjunto de elementos de informação casados
Figura 5.4: PontoLab++ - Interface com o conjunto de elementos de informação não casados
47
5.1 Ferramenta PontoLab++
preciso selecionar uma classe da hierarquia da EXP ER Ontology (Figura 5.5). O usuário pode também
incrementar a terminologia com novos termos durante a resolução. Assim, conforme novos termos são
inseridos, apóia-se a própria resolução e o matching. Caso não haja uma classe deﬁnida na hierarquia
da EXP ER Ontology que seja adequada para instanciar o elemento, o usuário pode inserir uma nova
classe na hierarquia antes de completar a resolução.
Figura 5.5: PontoLab++ - Interface de resolução e evolução
5.2
Execução do workﬂow proposto
Não há livre acesso às bases de dados, documentos XML ou planilhas dos diferentes grupos de
pesquisa em Engenharia de Software Experimental. Essa diﬁculdade em se acessar diretamente os pacotes de laboratório implica no uso de outro meio para acessar as informações sobre os experimentos:
os artigos publicados pelos pesquisadores (Cruzes et al., 2007).
Cada artigo pode apresentar um conjunto de informações distinto (Jedlitschka et al. (2008); Carver
(2010)), o que implica em um modelo subjacente de pacote de laboratório distinto. O documento PDF
do artigo publicado do experimento contém a descrição de suas informações. Logo, pode ser adotado
como representante do pacote de laboratório de entrada.
5.2.1
Pré-processamento
O documento PDF não consiste em um formato (semi)estruturado, como o requerido pelo workﬂow. Contudo, as informações contidas no texto estão de acordo com um modelo de dados subjacente,
ou seja, os elementos de informação estão presentes no documento. Apesar de não estarem estruturados, os elementos de informação estão dispersos em meio ao texto em linguagem natural.
48
5.2 Execução do workﬂow proposto
Uma visão geral do resultado esperado do pré-processamento é dada na Figura 5.6. Para realizar
a extração do texto do documento PDF (pois esse formato de arquivo embute muitos outros tipos de
dados como imagens, formulários, fontes, etc), foi utilizada a biblioteca PDFBox3 . A partir do texto,
cada elemento de informação extraído é representado por um elemento XML.
Software developers, programmers, and
other information systems
(IS
software engineering have yet to be
replaced by computational
automation that will transform the field.
In our research program,
we are investigating the theory and
technology for processing the
semantic meaning of programs to enable
fast and precise understanding
of program behaviors. The emerging
technology of function
extraction (FX) will achieve this objective
through
automated computation of the functional
behavior of programs
to the fullest extent possible [20,21,25].
FX technology has the potential
<ObjectOfStudy> ER and UML
class diagrams
</ObjectOfStudy>
<QualityFocus> Comprehension
support </QualityFocus>
<NullHypothesis> There is no
difference between the support
provided by ER and UML class
diagrams when performing
comprehension tasks on data
models (Comprehension Support)
</NullHypothesis>
Figura 5.6: Extração de elementos de informação do texto
A extração de elementos depende de uma busca por termos representativos (que devem dar origem
às tags dos elementos XML) em meio ao texto e da seleção dos trechos que correspondem à informação de fato (conteúdo dos elementos XML), conforme a representação da Figura 5.7. Os termos
representativos são provenientes da terminologia utilizada como recurso externo do matching.
<NullHypothesis> There is no difference between the support
provided by ER and UML class diagrams when performing
comprehension tasks on data models (Comprehension
Support) </NullHypothesis>
Figura 5.7: Extração de um elemento de informação do texto
A ﬁm de estabelecer uma busca com contexto e facilitar a seleção de trechos de texto, foi implementada a segmentação do texto em seções e parágrafos (também representados em um documento
XML intermediário). Quanto à seleção do trecho de texto que deve ser instanciado ao se identiﬁcar
um termo representativo, foram adotadas duas heurísticas: (i) se o termo aparecer em um título de
seção, seleciona-se o texto inteiro da seção; (ii) se o termo aparecer em um parágrafo, seleciona-se o
parágrafo. A interface inicial da ferramenta desenvolvida para o realizar o pré-processamento é dada
na Figura 5.8.
3
http://pdfbox.apache.org
49
5.2 Execução do workﬂow proposto
Figura 5.8: Interface da ferramenta de pré-processamento
Com a execução dessa etapa de pré-processamento, é gerado um documento semiestruturado em
XML para cada artigo em PDF, contendo os respectivos elementos de informação. Os trechos de texto
que não são selecionados até o ﬁnal da busca com o apoio da terminologia dão origem a elementos
XML com a tag “NotIdentiﬁedYet”. Dessa maneira, o documento XML pode ser tomado como
entrada na ferramenta PontoLab++.
5.2.2
Execução do workﬂow
Dispondo do pré-processamento, é possível obter documentos XML que contêm elementos de
informação a partir de artigos e, então, executar o workﬂow por meio da ferramenta PontoLab++.
Com esse propósito, foi selecionado um conjunto de 56 publicações de experimentos controlados em
Engenharia de Software. A busca pelos artigos foi realizada tanto por meio dos nomes dos autores
(pesquisadores de Engenharia de Software Experimental) quanto por evento/periódico da área de
Engenharia de Software.
O conjunto de artigos passou pelo pré-processamento e gerou, como saída, um conjunto de documentos XML. Cada documento XML foi tomado como entrada no workﬂow, e deu origem a um
pacote de laboratório instanciado na ontologia. Dentre os artigos do conjunto selecionado, foi escolhido um – De Lucia et al. (2010) – para apresentar o seu empacotamento.
Após a execução da atividade de matching para o artigo escolhido, foram gerados como saída
os respectivos conjuntos de correspondências e de elementos não casados. Na Tabela 5.1 é exibida uma amostra das correspondências. Cada linha representa uma correspondência, com o par
conceito-elemento. A primeira coluna indica o conceito da EXP ER Ontology e a segunda apresenta o
50
5.2 Execução do workﬂow proposto
conteúdo do elemento de informação.
Tabela 5.1: Amostra do conjunto de correspondências
Conceito
Parte do conteúdo do elemento
Hypothesis
« Section » 2.3 Hypothesis Formulation The main objective of our study
was to analyse whether UML class diagrams are more comprehensible
than ER diagrams during comprehension, maintenance, and veriﬁcation
activities on data models. Thus, the nul-hypotheses were formulated for
testing the effect of the design notation (i.e., ER or UML diagrams) on
the comprehensibility, maintainability, and veriﬁability of a data model:
â"H 0 c : there is no difference between the support provided by ER and
UML class diagrams when performing comprehension tasks on data
models (Comprehension Support). â"H 0 m : there is no difference
between the support provided by ER and UML class diagrams when
identifying the change to perform on data models to meet a maintenance
request (...)
Subject
« Section » 2.2.1 Subjects The controlled experiments were executed at
the University of Salerno (Italy) and involved students having different
academic backgrounds and, consequently, different levels of experience
on ER and UML diagrams: â"zero-knowledge students, i.e., fresher B.
Sc. students that were starting their academic career when the experiment was performed; â"bachelor students, i.e., 2 nd year B. Sc. students
that attended Programming and Databases courses in the past and were
attending the Software Engineering course when the experimentation
was performed. (...)
DependentVariable
« Section » 2.5 Measurement of the Dependent Variables The main outcome observed in the set of controlled experiments Comprehension was
the comprehension level. To evaluate it, we asked the subjects to answer
a questionnaire (similar to Kuzniarz et al. 2004; Purchase et al. 2001,
2004; Ricca et al. 2007) consisting of 5 multiple choice questions where
each question has one or more correct answers (see Table 4 for sample
questions and De Lucia et al. 2008 a for the complete questionnaire).
(...)
(continuação na próxima página)
51
5.2 Execução do workﬂow proposto
Tabela 5.1: Amostra do conjunto de correspondências (continuação)
Conceito
Parte do conteúdo do elemento
ExperimentalDesign
« Section » 2 Experimental Method This section describes in detail the
deﬁnition, design, and settings of all the controlled experiments we performed. 1 We replicated each experiment at least once, and the design,
the material and the procedure of the replications were exactly the same
as the main experiments. Subjects represented the only substantial difference among the experiment and the replications. (...)
Result
« Section » 3 Experimental Results In the next sections we report on the
results achieved in the three sets of controlled experiments, i.e., Comprehension, Maintenance,and Veriﬁcation,aswellasthe results achieved
in the survey questionnaires (...)
« Paragraph from section » 2.5 Measurement of the Dependent Variables After the execution of each experiment, we collected the questionnaires ﬁlledin by each subject in each laboratory session. The results
of the questionnaire were reported by one of the author in spreadsheets
aiming at performing the data analysis.
« Paragraph from section » 2.5 Measurement of the Dependent Variables To reduce the risk of human errors in reporting the results, another
author doublechecked the inserted data. Once the data were validated,
the F-measures achieved by the subject were calculated.
Analysis
« Section » 2.7 Data Analysis Since experiments were organised as longitudinal studies, 5 where each subject performed a task on two different models (i.e., S1 or S2) with the two possible treatments (i.e., ER
or UML), it was possible to use a paired Wilcoxon one-tailed test (Conover 1998) to analyse the differences exhibited by each subject for the
two treatments. A one-tailed paired t-test (Conover 1998) can be used
as alternative to the Wilcoxon test. (...)
« Paragraph from section » 4.4 Conclusion Validity A deﬁnition of
conclusion validity could be the degree to which conclusions we reach about relationships in our data are reasonable. With regard to our
experiment, proper tests were performed to statistically reject null hypotheses. In cases where differences were present but not signiﬁcant,
this was explicitly mentioned. Nonparametric tests were used in place
of parametric tests where there were not the necessary conditions to
use parametric tests. In particular, the Mann-Whitney test for unpaired
analyses and the Wilcoxon test for paired analysis.
(continuação na próxima página)
52
5.2 Execução do workﬂow proposto
Tabela 5.1: Amostra do conjunto de correspondências (continuação)
Conceito
Parte do conteúdo do elemento
« Paragraph from section » 4.4 Conclusion Validity This allowed us to
use statistical analysis to analyse differences in the feedback provided
by subjects with different levels of ability and experience.
ConclusionValidity
« Section » 4.4 Conclusion Validity A deﬁnition of conclusion validity
could be the degree to which conclusions we reach about relationships
in our data are reasonable. With regard to our experiment, proper tests
were performed to statistically reject null hypotheses. In cases where
differences were present but not signiﬁcant, this was explicitly mentioned. Nonparametric tests were used in place of parametric tests where
there were not the necessary conditions to use parametric tests. In particular, the Mann-Whitney test for unpaired analyses and the Wilcoxon
test for paired analysis. (...)
Os nomes dos elementos foram omitidos por serem idênticos aos nomes dos conceitos. A razão
disso é aplicação da terminologia para extraí-los do texto em linguagem natural. Essa situação enfatiza
que os elementos foram extraídos no pré-processamento por meio dos próprios nomes de conceitos
da EXP ER Ontology e não pelos termos similares a eles contidos na terminologia.
O conjunto de elementos não casados é apresentado na Tabela 5.2. Esse conjunto é entrada da
atividade de resolução do workﬂow. Os elementos não casados precisam ser resolvidos (para se
tornarem correspondências) ou podem ser deletados. Adicionalmente, enquanto tenta resolver um
elemento, o usuário pode decidir se o mesmo sugere um novo conceito ou termo similar (na atividade
de evolução).
Para resolver os elementos não casados, o usuário analisa o conteúdo de cada um. Apenas o
quarto elemento da Tabela 5.2 indica um elemento que deve ser instanciado. O elemento NotIdentiﬁedYet4, apesar de não possuir qualquer conceito correspondente deﬁnido na ontologia, sugere um
novo conceito: LessonsLearned. Os demais não podem ser instanciados em qualquer conceito da
EXP ER Ontology e não sugerem mudanças na ontologia. Portanto, podem ser descartados.
As lições aprendidas são conclusões dos pesquisadores diante da análise dos resultados e da experiência que adquiriram realizando o experimento. Portanto, ao realizar a resolução do elemento
LessonsLearned, o usuário também efetua uma evolução na ontologia, por meio da mudança AddClass(LessonsLearned) e AddSubclass(LessonsLearned, Thing).
Após resolver os elementos não casados, o usuário pode solicitar a instanciação do pacote de
laboratório a partir do conjunto de correspondências, composto pelas correspondências estabelecidas
pela atividade de matching (de maneira automática) e pela atividade de resolução (com o apoio do
usuário). Assim, completa-se a execução do workﬂow por meio da ferramenta PontoLab++ para gerar
um pacote de laboratório padronizado de acordo com os conceitos da EXP ER Ontology.
53
5.3 Considerações ﬁnais
Nome do elemento
NotIdentiﬁedYet1
NotIdentiﬁedYet2
NotIdentiﬁedYet3
NotIdentiﬁedYet4
NotIdentiﬁedYet5
5.3
Tabela 5.2: Conjunto de elementos não-casados
Parte do conteúdo do elemento
« Section » 1 Introduction A data model is a set of concepts that can be
used to describe both the structure of and the operations on a database
(Navathe 1992). It represents the output of data modelling (or conceptual design), an activity that aims at creating a conceptual schema in a
diagrammatic form and facilitating the communication between developers and users (Navathe 1992). (...)
« Section » 3.1 ER vs UML during Comprehension Activities Tables 7,
8,and9 show descriptive statistics (i.e., median, mean, and standard deviation)â"grouped by Method and Systemâ"for the dependent variable
Comprehension Support of the Comprehension experiments carried out
with fresher students (Comp-Fsc), with bachelor students (Comp-Bsc),
and with master students (Comp Msc). (...)
« Section » 3.2 ER vs UML during Maintenance Activities Tables 11 and 12 show the descriptive statistics (i.e., median, mean,
and standard deviation) for the dependent variable Maintenance Supportâ"grouped by Method and Systemâ"of the Maintenance experiments carried out with bachelor students (Maint-Bsc) and with master
students (Maint-Msc).
« Section » 5 Lessons Learned The results achieved in the reported experiments provided us with a number of lessons learned: â"UML class
diagrams represent a notation easier to comprehend than ER diagrams
independently of the subjects experience. The analysis also revealed
that both subjects ability and experience inﬂuence the comprehension
level. (...)
« Section » 6 Related Work In the last two decades several papers have
analysed, through controlled experiments or empirical studies or surveys, graphical notations supporting the software development process.
Considerações ﬁnais
Neste capítulo foram discutidos aspectos sobre a execução do workﬂow proposto. Nesse sentido,
foi apresentada a ferramenta PontoLab++, a implementação da instância de workﬂow da Seção 4.2.
A ferramenta possibilitou que cada atividade deﬁnida no workﬂow fosse exercitada para demonstrar
o seu funcionamento.
Considerando que a ferramenta admite como entrada apenas pacotes de laboratório em XML,
para executá-la a partir de um conjunto de artigos no formato PDF, foi implementada e executada
uma atividade adicional de pré-processamento. Assim, foi gerado um conjunto de documentos XML
contendo elementos de informação extraídos do texto dos artigos.
Apesar de ter sido implementada uma busca simples para o pré-processamento, os elementos de
informação gerados são relativamente coerentes com o que deveriam ser, considerando a descrição
do experimento no artigo. Portanto, a busca com o apoio de um vocabulário e a adoção de heurísticas
são suﬁcientes para atingir os propósitos do pré-processamento dos artigos em PDF.
Dentre um conjunto de artigos selecionados para a avaliação do workﬂow, foi escolhido um para
demonstrar da execução de todas as suas atividades. Pode-se concluir que os conceitos deﬁnidos
54
5.3 Considerações ﬁnais
na ontologia apresentaram uma boa cobertura dos respectivos elementos de informação. Apenas
restaram cinco elementos não casados, dos quais apenas um apresentou a necessidade de evoluir a
EXP ER Ontology.
55
C APÍTULO
6
Conclusões
Neste trabalho de mestrado é proposto um workﬂow para aplicar uma ontologia ao empacotamento
de experimentos controlados em Engenharia de Software. O objetivo dessa abordagem é padronizar a
estrutura das informações contidas em um pacote de laboratório, o que apóia a integração de estudos
isolados em um corpo comum de conhecimento.
As entradas do workﬂow proposto são uma ontologia, contendo os conceitos de experimentos
controlados, e um pacote de laboratório, composto de informações de um experimento controlado.
Para que seja gerado como saída um pacote de laboratório padronizado a partir dessas entradas,
foram identiﬁcadas as seguintes atividades: o matching entre os elementos de informação do pacote
e os conceitos da ontologia, a instanciação dos elementos casados, a resolução dos elementos não
casados e a evolução da ontologia pela adição de novos conceitos, que podem ser requeridos para
resolver elementos não casados. As atividades de matching e instanciação são realizadas de maneira
automática, enquanto que as atividades de resolução e evolução precisam da intervenção do usuário.
A partir da deﬁnição geral do workﬂow (Figura 4.4), uma instância pode ser obtida ao se determinar a ontologia que deve ser utilizada e o formato do pacote de laboratório de entrada, além das
escolhas de implementação das atividades. Neste trabalho foi considerada uma instância do workﬂow
cujas entradas são a EXP ER Ontology (Garcia et al., 2008) e um documento XML, composto pelos
elementos de informação de um pacote de laboratório.
Considerando o formato do pacote de entrada como um documento XML, foram adotadas técnicas
baseadas em termos para compor a solução de matching. Uma vez que a aplicação dessas técnicas
é feita dentro de um contexto bem deﬁnido (Engenharia de Software Experimental), a ambiguidade
das correspondências estabelecidas é consideravelmente diminuída. Quanto à evolução, a instância
do workﬂow apenas admite mudanças de adição de conceitos, cujo impacto sobre as deﬁnições da
ontologia é mínimo. Dessa maneira, é mantida a coerência dos pacotes de laboratório gerados antes
de serem aplicadas mudanças à EXP ER Ontology.
A ﬁm de avaliar a proposta, as atividades do workﬂow foram implementadas e executadas. A
instância do workﬂow foi implementada na ferramenta PontoLab++. Para a execução, foram adotadas
56
publicações de experimentos controlados, o que requereu a implementação de uma atividade adicional de pré-processamento para extrair elementos de informação presentes em meio à descrição em
linguagem natural dos experimentos controlados.
Vale ressaltar que os elementos de informação gerados a partir do texto usando essa abordagem
não contêm informações absolutamente precisas. Não obstante, ainda que imprecisos, os elementos
de informação servem para indicar a presença de um determinado conceito em meio ao texto. Isso
basta para demonstrar a execução do workﬂow e a padronização de um pacote de laboratório por meio
da ontologia.
A padronização dos pacotes de laboratório é uma das atividades sugeridas pelo FIRE para aprimorar a transferência de conhecimento entre grupos de pesquisa. Deve-se considerar, entretanto, que o
empenho em gerar pacotes de laboratório bem projetados, é apenas um aspecto complementar para se
favorecer replicações. A comunicação entre grupos de pesquisa tem papel fundamental, fato corroborado pela criação da ISERN (International Software Engineering Research Network1 ) e pela atividade
de planejamento e coordenação de iniciativas do ciclo externo (intergrupos) do FIRE (Mendonça et
al., 2008).
6.1
Contribuições e limitações
A principal contribuição deste trabalho é a deﬁnição de um workﬂow de empacotamento de experimentos controlados com base em uma ontologia. Estabeleceu-se uma abordagem para a padronização
de pacotes de laboratório compostos por diferentes conjuntos de informações. Portanto, foi tratada
a questão da falta de padronização de pacotes de laboratório, que é um dos fatores de problemas de
integração e transferência de conhecimento em Engenharia de Software.
Outra contribuição é a implementação da EXP ER Ontology em OWL para ser adotada como o
padrão das informações dos pacotes de laboratório de entrada. Também foi desenvolvida uma ferramenta que consiste na implementação de uma instância do workﬂow, a PontoLab++. Dessa maneira,
é possível executá-lo e avaliá-lo.
A partir da execução do workﬂow, são gerados pacotes de laboratórios de acordo com um modelo estruturado e padronizado. Armazenar as informações de um experimento como instâncias dos
conceitos de uma ontologia signiﬁca que as informações estão estruturadas de acordo com um vocabulário comum. Além disso, por se tratar de uma especiﬁcação formal, a ontologia de instâncias
de cada pacote pode ser facilmente processada, pois embute a semântica do domínio em que está
inserida, ou seja, contém o signiﬁcado das informações representadas. Os pacotes não seriam tão
portáveis se fossem instanciados em bancos de dados relacionais, por exemplo.
Porém, há diﬁculdades para veriﬁcar a inﬂuência da abordagem no que se refere a promover um
melhor entendimento durante a revisão dos experimentos pelos pesquisadores, já que é necessário
dispor da colaboração de pesquisadores de diferentes contextos revisando pacotes de laboratório.
Para essa avaliação, é preciso comparar a revisão de pacotes de laboratório não padronizados pela
ontologia e a revisão daqueles cujas informações foram instanciadas em seus conceitos por meio da
execução do workﬂow.
1
http://isern.iese.de/
57
6.2 Trabalhos futuros
6.2
Trabalhos futuros
Alguns trabalhos estendem o escopo deste projeto de mestrado e tratam as limitações nele contidas:
• Utilizar pacotes de laboratório estruturados para serem padronizados pelo workﬂow. Dessa maneira, os pacotes dão origem a uma estrutura hierárquica no documento XML, que pode ser
comparada à estrutura da EXP ER Ontology. Assim é obtida uma instância distinta do workﬂow,
que implica em mudanças na implementação da atividade de matching, com a possibilidade adicional de aplicar técnicas que comparam a estrutura. Combinar diferentes técnicas de matching
aprimora as correspondências estabelecidas.
• Realizar uma avaliação da inﬂuência da adoção da EXP ER Ontology no entendimento compartilhado das informações do pacote de laboratório nela instanciadas. Para isso é preciso dispor
da colaboração de outros grupos de pesquisa.
• Investigar maneiras de explorar a representação semântica dos pacotes de laboratório sob o formato de ontologia OWL. É possível utilizar um reasoner para computar vinculações inferidas
a partir dos pacotes de laboratório padronizados de saída do workﬂow (Sirin et al., 2007).
• Aplicar técnicas de aprendizagem de máquina para extrair os elementos do texto dos artigos de
experimentos controlados. Com uma abordagem similar à de Matos et al. (2010), é possível
extrair informações mais precisas para compor o documento XML de entrada do workﬂow.
6.3
Produção bibliográﬁca
Destaca-se que, ao longo do desenvolvimento deste trabalho, houve duas publicações em eventos,
que apresentam a abordagem proposta neste projeto de mestrado:
• SCATALON, Lilian Passos; GARCIA, Rogério Eduardo; CORREIA, Ronaldo Celso Messias.
Uma ferramenta para instanciação de ontologia de experimentos controlados em engenharia de
software. In: Conferência Ibérica de Sistemas e Tecnologias de Informação, 2011, Chaves Portugal. 6a Conferência Ibérica de Sistemas e Tecnologias de Informação (CISTI 2011). Porto
- Portugal: Associação Ibérica de Sistemas e Tecnologias de Informação, 2011.
• SCATALON, Lilian Passos; GARCIA, Rogério Eduardo; CORREIA, Ronaldo Celso Messias.
Packaging Controlled Experiments Using an Evolutionary Approach Based on Ontology. In:
International Conference on Software Engineering and Knowledge Engineering, 2011, Miami
- USA. 23rd International Conference on Software Engineering and Knowledge Engineering
(SEKE 2011), 2011.
Outra publicação está sob elaboração, contendo a avaliação do workﬂow e seus resultados, a ser
submetida ao International Journal of Software Engineering and Knowledge Engineering.
58
Referências Bibliográﬁcas
A BGAZ , Y. M.; JAVED , M.; PAHL , C.
A framework for change impact analysis of
ontology-driven content-based systems. In: Confederated International Conference On the
move to meaningful internet systems, Berlin, Heidelberg: Springer-Verlag, 2011, p. 402–411.
A MARAL , E. A. G. G.; T RAVASSOS , G. H. A package model for software engineering experiments. In: Proceedings of ISESE 2003 - International Symposium on Empirical Software
Engineering, 2003, p. 21–22.
BARBOSA , E. F.; NAKAGAWA , E. Y.; M ALDONADO , J. C. Towards the establishment of
an ontology of software testing. In: International Conference on Software Engineering and
Knowledge Engineering (SEKE 2006), 2006, p. 522–525.
BASILI , V. R. The role of controlled experiments in software engineering research. In: Empirical Software Engineering Issues: Critical assessment and future directions, 2006, p. 33–37.
BASILI , V. R.; S ELBY, R. W. Comparing the effectiveness of software testing strategies.
IEEE Transaction on Software Engineering, v. 13, n. 12, p. 1278–1296, 1987.
BASILI , V. R.; S HULL , F.; L ANUBILE , F. Building knowledge through families of experiments. IEEE Transactions on Software Engineering, v. 25, n. 4, p. 456–473, 1999.
BASILI , V. R.; Z ELKOWITZ , M. V. Empirical studies to build a science of computer science.
Communications of the ACM, v. 50, n. 11, p. 33–37, 2007.
B IOLCHINI , J.; M IAN , P. G.; NATALI , A. C. C.; C ONTE , T. U.; T RAVASSOS , G. H. Scientiﬁc research ontology to support systematic review in software engineering. Advanced Engineering Informatics, v. 21, n. 2, p. 133–151, 2007.
B ROOKS , A.; ROPER , M.; W OOD , M.; DALY, J.; M ILLER , J. Guide to advanced empirical
software engineering, cáp. Replication’s Role in Software Engineering Springer-Verlag London,
p. 365–379, 2008.
C ARVER , J. C. Towards reporting guidelines for experimental replications: A proposal. In:
International Workshop on Replication in Empirical Software Engineering Research (RESER),
2010.
59
Referências Bibliográﬁcas
C RUZES , D.; M ENDONCA , M.; BASILI , V.; S HULL , F.; J INO , M.
Extracting information
from experimental software engineering papers. In: Proceedings of the XXVI International
Conference of the Chilean Society of Computer Science, Washington, DC, USA: IEEE Computer
Society, 2007, p. 105–114.
D E L UCIA , A.; G RAVINO , C.; O LIVETO , R.; T ORTORA , G. An experimental comparison
of er and uml class diagrams for data modelling. Empirical Software Engineering, v. 15, n. 5,
p. 455–492, 2010.
E UZENAT, J.; S HVAIKO , P. Ontology matching. Springer-Verlag, 2007.
FALBO , R.; RUY, F. B.; M ORO , R. D. Using ontologies to add semantics to a software engineering environment. In: International Conference on Software Engineering and Knowledge
Engineering (SEKE 2005), 2005, p. 151–156.
F ENSEL , D. Ontologies: Dynamic networks of formally represented meaning. In: Semantic
web working symposium, Stanford, CA, USA, 2001.
G ARCIA , R. E. Vidaese: processo de visualização exploratória para apoio a estudos experimentais em veriﬁcação, validação e teste de software. Tese de Doutoramento, Instituto de
Ciências Matemáticas e de Computação (ICMC-USP), 2006.
G ARCIA , R. E.; H ÖHN , E. N.; BARBOSA , E. F.; M ALDONADO , J. C. An ontology for
controlled experiments on software engineering. In: International Conference on Software
Engineering and Knowledge Engineering (SEKE 2008), Knowledge Systems Institute Graduate
School, 2008, p. 685–690.
G OMÉZ -P ÉREZ , A. Ontological engineering: Theoretical foundations. Tutorial, international
Joint Conference on Artiﬁcial Intelligence, 1999.
G RUBER , T. R. Toward principles for the design of ontologies used for knowledge sharing.
International Journal of Human-Computer Studies - Special issue: the role of formal ontology
in the information technology, v. 43, p. 907–928, 1995.
G UARINO , N.; O BERLE , D.; S TAAB , S. Handbook on ontologies, cáp. What is an ontology?
Springer Verlag, p. 201–221, 2009.
H AASE , P.; S TOJANOVIC , L. Consistent evolution of OWL ontologies. In: European Conference on The Semantic Web: Research and Applications, Berlin, Heidelberg: Springer-Verlag,
2005, p. 182–197.
H AKIMPOUR , F.; G EPPERT, A. Resolving semantic heterogeneity in schema integration: an
ontology-based approach. In: Proceedings of the International Conference on Formal Ontology
in Information Systems, New York, NY, USA: ACM, 2001, p. 297–308.
H ALEVY, A. Why your data won’t mix: Semantic heterogeneity. ACM Queue, v. 3, p. 50–58,
2005.
60
Referências Bibliográﬁcas
H ORRIDGE , M. A practical guide to building OWL ontologies using Protégé 4 and CO-ODE
tools. Available at http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial, 2009.
J EDLITSCHKA , A.; C IOLKOWSKI , M.; P FAHL , D. Reporting guidelines for controlled experiments in software engineering. Relatório Técnico, Fraunhofer Institute for Experimental
Software Engineering, Germany, 2007.
J EDLITSCHKA , A.; C IOLKOWSKI , M.; P FAHL , D. Guide to advanced empirical software
engineering, cáp. Reporting Experiments in Software Engineering London: Springer-Verlag, p.
201–228, 2008.
J URISTO , N.; M ORENO , A. M.
2001.
Basics of software engineering experimentation.
Kluwer,
K ITCHENHAM , B. Procedures for performing systematic reviews. Relatório Técnico, Keele
University Joint Technical Report TR/SE-0401, 2004.
K ITCHENHAM , B. The role of replications in empirical software engineering–a word of warning. Empirical Software Engineering, v. 13, n. 2, p. 219–221, 2008.
K ITCHENHAM , B. A.; P FLEEGER , S. L.; P ICKARD , L. M.; J ONES , P. W.; H OAGLIN , D. C.;
E MAM , K. E.; ROSENBERG , J. Preliminary guidelines for empirical research in software
engineering. IEEE Transactions on Software Engineering, v. 28, n. 8, p. 721–734, 2002.
K ITCHENHAM , B. A.; T RAVASSOS , G. H.; VON M AYRHAUSER , A.; N IESSINK , F.; S CH NEIDEWIND , N. F.; S INGER , J.; TAKADA , S.; V EHVILAINEN , R.; YANG , H. Towards an
ontology of software maintenance. Journal of Software Maintenance, v. 11, n. 6, p. 365–389,
1999.
L OPES , V.; T RAVASSOS , G. Knowledge repository structure of an experimental software
engineering environment. In: Simpósio Brasileiro de Engenharia de Software (SBES), 2009, p.
32–42.
M ATOS , P. F.; L OMBARDI , L. O.; PARDO , T. A. S.; C IFERRI , C. D. A.; V IEIRA , M. T. P.;
C IFERRI , R. R. An environment for data analysis in biomedical domain: information extraction
for decision support systems. In: International Conference on Industrial engineering and other
applications of applied intelligent systems - Volume Part I, Berlin, Heidelberg: Springer-Verlag,
2010, p. 306–316.
M ENDONÇA , M. G.; M ALDONADO , J. C.; DE O LIVEIRA , M. C. F.; C ARVER , J.; FABBRI ,
S. C. P. F.; S HULL , F.; T RAVASSOS , G. H.; H OHN , E. N.; BASILI , V. R. A framework for
software engineering experimental replications. In: ICECCS, 2008, p. 203–212.
M ILLER , J. Replicating software engineering experiments: a poisoned chalice or the holy grail.
Information and Software Technology, v. 47, n. 4, p. 233–244, 2005.
61
Referências Bibliográﬁcas
N OY, N. F.; M C G UINNESS , D. L. Ontology development 101: A guide to creating your ﬁrst
ontology. Relatório Técnico, Stanford University, 2001.
Ontologies - introduction and overview.
P RETORIUS , A. J.
http://www.starlab.vub.ac.be/teaching/Ontologies_Intr_Overv.pdf, 2004.
Disponível em
R AHM , E. Schema matching and mapping, cáp. Towards Large-Scale Schema and Ontology
Matching Springer Publishing Company, Incorporated, p. 3–27, 2011.
R AHM , E.; B ERNSTEIN , P. A survey of approaches to automatic schema matching.
VLDB Journal, v. 10, n. 4, p. 334–350, 2001.
The
S HULL , F.; BASILI , V. R.; C ARVER , J.; M ALDONADO , J. C.; T RAVASSOS , G. H.; M EN DONÇA , M. G.; FABBRI , S. C. P. F. Replicating software engineering experiments: Addressing the tacit knowledge problem.
Engineering (ISESE), 2002, p. 7–16.
In: International Symposium on Empirical Software
S HULL , F.; C ARVER , J.; T RAVASSOS , G. H.; M ALDONADO , J. C.; C ONRADI , R.; BASILI ,
V. R. Replicated studies: building a body of knowledge about software reading techniques.
In: Lecture notes on empirical software engineering, River Edge, NJ, USA: World Scientiﬁc
Publishing Co., Inc., p. 39–84, 2003.
S HULL , F.; M ENDONÇA , M. G.; BASILI , V.; C ARVER , J.; M ALDONADO , J. C.; FABBRI , S.;
T RAVASSOS , G. H.; F ERREIRA , M. C. Knowledge-sharing issues in experimental software
engineering. Empirical Software Engineering, v. 9, n. 1-2, p. 111–137, 2004.
S HULL , F. J.; C ARVER , J. C.; V EGAS , S.; J URISTO , N. The role of replications in empirical
software engineering. Empirical Software Engineering, v. 13, n. 2, p. 211–218, 2008.
S HVAIKO , P.; E UZENAT, J. A survey of schema-based matching approaches. Journal on Data
Semantics, v. IV, p. 146–171, 2005.
S HVAIKO , P.; E UZENAT, J. Ontology matching: state of the art and future challenges. Disponível em http://ontologymatching.org/publications.html, 2012.
S INGER , J. Using the APA style guidelines to report experimental results. In: Proceedings of
Workshop on Empirical Studies in Software Maintenance, 1999, p. 71–75.
S IRIN , E.; PARSIA , B.; G RAU , B. C.; K ALYANPUR , A.; K ATZ , Y. Pellet: A practical
OWL-DL reasoner. Web Semantics: Science, Services and Agents on the World Wide Web, v. 5,
n. 2, p. 51–53, 2007.
S JØBERG , D. I. K.; H ANNAY, J. E.; H ANSEN , O.; B Y K AMPENES , V.; K ARAHASANOVIC ,
A.; L IBORG , N.-K.; C. R EKDAL , A. A survey of controlled experiments in software engineering. IEEE Transactions on Software Engineering, v. 31, n. 9, p. 733–753, 2005.
62
Referências Bibliográﬁcas
S TOJANOVIC , L. Methods and tools for ontology evolution. Tese de Doutoramento, University
of Karlsruhe, 2004.
S TOJANOVIC , L.; M AEDCHE , A.; M OTIK , B.; S TOJANOVIC , N. User-driven ontology evolution management. In: International Conference on Knowledge Engineering and Knowledge
Management, London, UK: Springer-Verlag, 2002, p. 285–300.
S TUDER , R.; B ENJAMINS , V. R.; F ENSEL , D. Knowledge engineering: principles and
methods. Data Knowledge Engineering, v. 25, n. 1-2, p. 161–197, 1998.
U SCHOLD , M.; G RUNINGER , M. Ontologies: Principles, methods and applications. Knowledge Engineering Review, v. 11, p. 93–136, 1996.
U SCHOLD , M.; G RUNINGER , M. Ontologies and semantics for seamless connectivity. ACM
SIGMOD Record, v. 33, p. 58–64, 2004.
W3C
W3C Recommendation. OWL Web Ontology Language Structural Speciﬁcation and
Functional-Style Syntax. Available at http://www.w3.org/TR/owl2-syntax, 2009.
W OHLIN , C.; RUNESON , P.; H ÖST, M.; O HLSSON , M.; R EGNELL , B.; W ESSLÉN , A. Experimentation in software engineering: An introduction. Boston, USA: Kluwer Academic
Publishers, 2000.
63

Download

Empacotamento de experimentos controlados em engenharia de

Empacotamento de experimentos controlados em engenharia de

Ontologia? - Universidade Federal de Santa Catarina

Filosofia da Arte_ Estetica2 (963584)

ISEL MEIC RPC - isel2918929391

apresentação - Decom

Ontologia

Agentes Inteligentes e Sistemas Cooperativos (aula convidada)

Aula Prática Protégé

Exemplo de Ontologia Utilizando a Ferramenta - DAINF

Ontologias