Empacotamento de experimentos controlados em engenharia de software: uma abordagem baseada em ontologia

(1)

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

(2)

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.

(3)

(4)

(5)

(6)

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 umaroommatemuito 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çãoque me proporci-onou. 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, vi-agens 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 impor-tantes 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 oworkshop. Quando você for o diretor da FCT, lembre-se daquela promessa.

(7)

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 agra-decimento 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. Obri-gada 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 parti-cipar 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!

(8)

Índice

Índice . . . viii

Lista de Figuras . . . x

Lista de Tabelas . . . xi

Resumo . . . xii

Abstract . . . xiii

1 Introdução 1 1.1 Motivação . . . 2

1.2 Formulação do problema . . . 2

1.3 Objetivos . . . 3

1.4 Organização . . . 3

2 Experimentos controlados em Engenharia de Software 5 2.1 Experimentos controlados . . . 5

2.2 Processo de experimentação . . . 7

2.2.1 Deﬁnição . . . 8

2.2.2 Planejamento . . . 8

2.2.3 Operação . . . 9

2.2.4 Análise e interpretação . . . 10

2.2.5 Empacotamento. . . 10

2.3 Replicações . . . 11

2.4 Transferência de conhecimento . . . 13

2.4.1 Pacotes de laboratório e artigos cientíﬁcos . . . 14

2.4.2 Diretrizes para reportar experimentos controlados . . . 14

2.5 Considerações ﬁnais . . . 18

3 Ontologia 20 3.1 Visão geral sobre ontologia . . . 20

3.2 Ontologias para experimentos controlados em Engenharia de Software . . . 22

3.3 EXP EROntology . . . 24

(9)

3.5 Matchingde ontologias/esquemas . . . 28

3.5.1 Processo dematching . . . 29

3.5.2 Técnicas dematchingpor tipo de entrada . . . 30

4 Workflowpara empacotar experimentos controlados 33 4.1 Definição do comportamento doworkflow . . . 33

4.1.1 Atividade deMatching . . . 35

4.1.2 Atividades de Instanciação, Resolução e Evolução . . . 36

4.2 Instância doworkﬂow . . . 38

4.2.1 Entradas doworkﬂow . . . 38

4.2.2 Atividade dematching . . . 40

4.2.3 Atividade de instanciação . . . 42

4.2.4 Atividades de resolução e evolução . . . 43

5 Avaliação doworkﬂow 45 5.1 Ferramenta PontoLab++ . . . 45

5.2 Execução doworkﬂowproposto . . . 48

5.2.1 Pré-processamento . . . 48

5.2.2 Execução doworkﬂow . . . 50

6 Conclusões 56 6.1 Contribuições e limitações . . . 57

6.2 Trabalhos futuros . . . 58

6.3 Produção bibliográﬁca . . . 58

(10)

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 Processo de experimentação (Wohlin et al. (2000); Garcia (2006)) . . . 7

2.4 Processo de experimentação - fase de empacotamento (Wohlin et al. (2000); Amaral e Travassos (2003)) . . . 11

2.5 Papel da replicação . . . 11

2.6 Ciclos do FIRE (Mendonça et al., 2008) . . . 12

2.7 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 Conceituação do domínio de recursos humanos . . . 21

3.3 Processo de desenvolvimento de uma ontologia (Goméz-Pérez, 1999) . . . 22

3.4 Ontologia da estrutura de um estudo experimental em Engenharia de Software (Biol-chini et al., 2007) . . . 23

3.5 Ambiente de Engenharia de Software Experimental com um repositório de conheci-mento (Lopes e Travassos, 2009) . . . 23

3.6 EXP EROntology- conceitos de experimentos controlados (Garcia et al., 2008) . . . 24

3.7 EXP EROntology- conceitos de um pacote de laboratório (Garcia et al., 2008) . . . . 25

3.8 Processo de evolução de ontologia (Stojanovic, 2004) . . . 26

3.9 Introdução de inconsistências após a realização de uma mudança . . . 27

3.10 Matchingde esquemas/ontologias, representado como uma operação com entradas e saída (Euzenat e Shvaiko, 2007) . . . 29

3.11 Processo dematchingde esquemas (Rahm, 2011) . . . 29

4.1 Integração de pacotes de laboratório usando ontologia . . . 34

4.2 Empacotamento com ontologia - situação ideal . . . 34

(11)

4.6 Atividade de instanciação doworkﬂow . . . 36

4.7 Atividade de resolução doworkﬂow . . . 37

4.8 Atividade de evolução doworkﬂow . . . 37

4.9 Trecho de um pacote de laboratório em documento XML . . . 38

4.10 Instantâneo daEXP EROntologyno editor Protégé . . . 39

4.11 Ontologias de instâncias e aEXP EROntology . . . 42

5.1 PontoLab++ - Interface inicial com os ajustes para a execução doworkﬂow . . . 46

5.2 PontoLab++ - Interface com os demais ajustes para a execução doworkﬂow . . . 46

5.3 PontoLab++ - Interface com o conjunto de elementos de informação casados . . . . 47

5.4 PontoLab++ - Interface com o conjunto de elementos de informação não casados . . 47

5.5 PontoLab++ - Interface de resolução e evolução . . . 48

5.6 Extração de elementos de informação do texto . . . 49

5.7 Extração de um elemento de informação do texto . . . 49

(12)

Lista de Tabelas

2.1 Visão geral das diretrizes para reportar experimentos controlados (Jedlitschka et al.,

2008) . . . 15

2.2 Diretrizes propostas por Jedlitschka et al. (2007). . . 15

3.1 Mudanças elementares a uma ontologia (Stojanovic, 2004) . . . 27

3.2 Distância de edição entre nomes dos conceitos (Euzenat e Shvaiko, 2007) . . . 30

3.3 Distância entre nomes de conceitos calculada com o apoio de um tesauro (Euzenat e Shvaiko, 2007) . . . 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 Amostra do conjunto de correspondências . . . 51

(13)

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 En-genharia de Software. Construir esse corpo de conhecimento requer a condução de experimentos controlados e suas replicações a fim de generalizar os resultados obtidos. As informações e o co-nhecimento 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, pesquisado-res enfrentam dificuldades ao revisar os pacotes de laboratório disponíveis. Um dos fatopesquisado-res 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 umworkflowpara 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 doworkflowque adota como padrão aEXP EROntology, uma ontologia para experimentos

(14)

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 ge-neralize 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 difficulties 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 workflow that applies an ontology to package controlled experiments in Software Engineering. In order to evaluate this approach, the tool Ponto-Lab++ was implemented, which corresponds to a workflow instance that adoptsEXP EROntology, an

(15)

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 obje-tivos, 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 soft-ware. Os participantes, que os representam, aplicam a tecnologia sob investigação. Os dados produ-zidos 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 suficientes 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 confiança (Shull et al.(2008);Brooks et al.(2008)). Quando outros pesquisadores replicam um experimento com sucesso, a confianç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 pes-quisa 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

procedi-mentos adotados, o conhecimento gerado, os resultados e as conclusões (Shull et al.,2002).

(16)

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 – aEXP EROntology– 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 pesqui-sador publica um conteúdo diferente sobre o experimento realizado, em relação ao conjunto de in-formaçõ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 conheci-mento comum (Jedlitschka et al.,2008).

(17)

1.3 Objetivos

O principal objetivo é instanciar pacotes de laboratório de acordo com os conceitos de uma on-tologia, 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 trans-ferê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 umworkflowde empacotamento de experimentos controlados com base em uma ontologia. Uma vez que as definições da ontologia não são necessariamente estáticas, oworkflowpermite que a ontologia absorva novos conceitos, con-forme pacotes de laboratório contendo diferentes conjuntos de informação são instanciados. Adicio-nalmente, foi implementada uma instância doworkflow, que adota aEXP EROntologycomo ontologia

de entrada – a ferramenta PontoLab++.

1.4 Organização

Para contextualizar e apresentar a proposta de trabalho, o restante desta dissertação está organi-zado como segue:

• No Capítulo2são dadas deﬁnições gerais sobre experimentos controlados e o processo de ex-perimentaçã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 conheci-mento 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, aEXP EROntologyé 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 ematchingde ontologias/esquemas.

• No Capítulo4é proposto oworkflowpara 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 definição de um conjunto de atividades, neste capítulo é apresentada uma instância doworkflow, considerando aEXP EROntologycomo ontologia adotada e algumas

(18)

1.4 Organização

• No Capítulo5é mostrada uma avaliação da proposta. Para isso, é apresentada a implementação (i)da instância doworkflow(ferramenta PontoLab++) e (ii) de um pré-processamento para per-mitir a execução usando um conjunto de artigos como representantes dos pacotes de laboratório a serem padronizados. Por fim, é fornecida uma demonstração da execução doworkflow por meio da ferramenta PontoLab++.

(19)

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 con-juntos 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 pro-cesso para estabelecer e executar um experimento. Na Seção2.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 pes-quisa. Na Seção2.4aborda-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.

(20)

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 Figura2.1.

construção da causa

construção do efeito

tratamentos resultados construção

causa-efeito

construção tratamento-resultado

Objetivo do experimento

Execução do experimento

Variável independente Variável dependente

Teoria

Observação

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 ostratamentos. Por exemplo,

consi-derando 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 testeaplicada eexperiência dos participan-tes. Para o fatortipo de técnica, os tratamentos podem ser: leitura de código, teste estruturaleteste 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 onúmero de defeitos encontradospor 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.

Processo Variáveis

independentes

Variável dependente

…

Figura 2.2: Variáveis independentes e dependentes de um experimento controlado (Wohlin et al., 2000)

(21)

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 detestes(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 reflita 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 finalidade de alcançar o nível de controle que um experimento requer. De acordo com a Figura2.3, o processo sugerido porWohlin et al. (2000) é composto pelas fases: definição, planejamento, operação, análise e interpretação e apresentação e empacotamento.

,GHLDSDUDR ([SHULPHQWR

'HILQLomRGR([SHULPHQWR 'RFXPHQWRGH'HILQLomR

3ODQHMDPHQWR

2SHUDomR

$QiOLVHH,QWHUSUHWDomR

$SUHVHQWDomRH (PSDFRWDPHQWR

3URMHWR([SHULPHQWDO

'DGRV&ROHWDGRV

5HODWyULRGR([SHULPHQWR

Figura 2.3: Processo de experimentação (Wohlin et al.(2000);Garcia(2006))

Adeﬁniçãoestabelece o escopo do experimento, que é deﬁnido em termos dos objetivos e metas.

Noplanejamento, as hipóteses são formalizadas e o projeto é determinado (o arranjo de quais

par-ticipantes devem aplicar quais tratamentos). Aoperaçãoé a execução do experimento propriamente

dita. Nessa fase as medidas dos resultados são coletadas e então avaliadas na fase deanálise e inter-pretação. Por ﬁm, os procedimentos adotados, resultados e conclusões obtidos são armazenados na

(22)

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 define o objetivo em termos gerais. Pode ser, por exemplo, comparar diferentes técnicas. OFoco de qualidadeé o efeito sob estudo no experimento. Alguns exemplos são efetividade, custo e confiabi-lidade. Aperspectivarevela o ponto de vista do qual os resultados são interpretados (desenvolvedor, gerente de projeto, cliente ou pesquisador). Por fim, ocontextoé 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 contextodo 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, ashipótesesque 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, ahipó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. Umahipó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,

(23)

deve ser derivada diretamente da hipótese e a medida escolhida para representá-la deve ser determi-nada. Por exemplo, a eﬁcácia de uma técnica de inspeção pode ser medida pela média de defeitos encontrados pelos participantes.

Osparticipantesdevem 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 aleato-riedade 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 ainstrumentaçãodo 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 avalidadedos 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. Avalidade internagarante que os resultados sejam inﬂuenciados apenas por fatores que sejam controlados e medidos. Avalidade de construçãoconﬁ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. Avalidade externase 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 emWohlin et al. (2000) e pode ser usada como uma checklistdurante 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 procedi-mentos. É importante que as pessoas estejam motivadas e dispostas a participar ao longo do experi-mento. Todos os instrumentos devem estar prontos: as instruções devem ser passadas e os formulários entregues aos participantes.

(24)

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 dadoseteste 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áficos que podem ser utilizados são: gráfico de dis-persão (scatter plot), histograma e gráfico de setores. A partir dos gráficos gerados, é possível detectar distorções (outliers), ou seja, pontos de dados que divergem muito dos outros. Quandooutlierssão identificados, é preciso analisar as razões que os ocasionaram para decidir se devem ser eliminados ou não. Em seguida, verifica-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 fim, se a hipótese nula for descartada é possível obter conclusões sobre a influência das va-riáveis independentes nas vava-riáveis dependentes, considerando que o experimento éválido(com base na análise davalidadedos resultados). Após descartar a hipótese nula, tira-se conclusões gerais sobre a relação causa-feito sob estudo, considerando avalidade externado experimento. Se o experimento não pôde rejeitar a hipótese nula não é possível afirmar 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, ge-rando 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).

(25)

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 popu-lação à qual se aplicam as conclusões obtidas (ver Figura2.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 profissionais de Engenharia de Software. Apenas a re-plicação de experimentos em diferentes contextos torna possível verificar a validade de uma hipótese com um nível de confiança maior (Miller(2005);Shull et al.(2008)).

conclusões sobre a técnica Ambiente

cultural

Diferentes condições durante a execução

Background pessoal e experiência

Figura 2.5: Papel da replicação

(26)

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 dispo-níveis, pesquisadores enfrentam dificuldades em entendê-los e revisá-los. As principais dificuldades 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 dife-rença de contextos pode dificultar 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 gene-ralizaçã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 oFIRE (Framework for Improving the Replication of Experi-ments), 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 efetiva-mente revisado por eventuais replicadores de outro grupo de pesquisa. Oframeworktrata 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 Interno Ciclo Externo executar experimento padronizar pacotes compartilhar conhecimento criar/evoluir corpo de conhecimento planejar e coordenar iniciativas compreender experimentos e pacotes de laboratório definir objetivos do experimento criar/evoluir pacote e armazenar experiência analisar e integrar dados projetar experimento, identificar participantes, e obter/adaptar artefatos

Figura 2.6: Ciclos do FIRE (Mendonça et al.,2008)

(27)

2.3 Replicações

se interceptam, compreender os experimentos e os pacotes de laboratório é fundamental para se deﬁnir os objetivosde 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 – for-necedores do conhecimento – e os replicadores – usuários do conhecimento.

Conforme pode ser visto na Figura2.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 bru-tos, análises e resultados;

• Combinação, em que as informações que devem compor o pacote de laboratório são seleciona-das e

• Internalizaçãodo conhecimento por replicadores, com a leitura, abstração e interpretação das informações que compõem o pacote de laboratório.

Socialização entre replicadores

Internalização o

Pacote de Laboratório

Combinação Exteriorização

anotações

documentos dados brutos conhecimento tácito conhecimento tácito

conhecimento explícito conhecimento explícito

conhecimento

tácito

conhecimento

tácito

conhecimento

explícito

conhecimento

explícito

(28)

2.4 Transferência de conhecimento

Há dois tipos de conhecimento que pode ser transferido entre os pesquisadores: conhecimento tá-cito e conhecimento explítá-cito. Oconhecimento explícitose refere às informações que compõem o pa-cote 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,

por-tanto, 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 infor-maçõ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 representa-das é de extrema importância, o que se conﬁrma também pela atividade depadronização de pacotes. Disponibilizar pacotes de laboratório ampara a realização de mais replicações, mas pacotes bem pro-jetados 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 obti-dos. 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 ne-cessidade 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 Soft-ware, 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 Tabela2.1.

(29)

proposta apresentada emJedlitschka et al.(2007).

Para cada conjunto de diretrizes proposto, a sua respectiva entrada na Tabela2.1 fornece os ele-mentos que devem compor a estrutura de um artigo de experimento. Na Tabela2.2, os elementos da proposta deJedlitschka 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) Wohlin et al. (2000)

Kitchenham et al. (2002)

Juristo e Moreno (2001)

Jedlitschka et al. (2007)

* * * * título

* * * * autores

resumo * * * resumo estruturado

* * * * palavras-chave

introdução introdução * deﬁnição de metas introdução

declaração do pro-blema

planejamento do experimento

contexto experi-mental

introdução declaração do pro-blema

contexto experi-mental

deﬁnição de metas background

método planejamento do

experimento

projeto experimen-tal

projeto planejamento do

experimento procedimento operação do

expe-rimento

condução do expe-rimento e coleta de dados

execução do expe-rimento

execução

resultados análise de dados análise análise experimen-tal

análise

discussão interpretação de re-sultados

interpretação de re-sultados

análise experimen-tal

discussão

discussão discussão e conclu-são

* análise

experimen-tal

conclusões e traba-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 explici-tamente mencionados.

Tabela 2.2: Diretrizes propostas porJedlitschka et al.(2007)

Seção Conteúdo Escopo Prioridade

Título <título> + “um experimento controlado”; É infor-mativo e inclui os principais tratamentos e variáveis dependentes?

Requerido

(30)

Tabela2.2: Diretrizes propostas porJedlitschka et al.(2007) (continuação)

Autores Inclui informações de contato, por exemplo, um

e-mail válido?

Requerido

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-cados?

Requerido

Resultados Quais são as principais descobertas? Implicações práticas?

Requerido

Limitações Quais são os pontos fracos dessa pesquisa?

Conclusões Qual é a conclusão? Requerido

Palavras-chave Áreas de pesquisa dos tratamentos, variáveis depen-dentes e tipo de estudo

Pode ser reque-rido pelo editor Introdução Declaração Qual é o problema? Onde ocorre? Quem o

obser-vou?

Requerido

do problema Por que é importante que seja resolvido? Objetivo da

pesquisa

Qual é a questão de pesquisa a ser respondida por 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 pesquisa se relaciona a uma situação especíﬁca (am-biente)?

Requerido

Background Tecnologia

sob investi-gação

O que é necessário que o leitor saiba sobre a tecno-logia para reproduzir sua aplicação?

Necessário se não estiver publicado em outro lugar Tecnologias alternativas

Como essa pesquisa se relaciona a tecnologias alter-nativas? Qual é o tratamento de controle?

Requerido

Estudos rela-cionados

Como essa pesquisa se relaciona aos estudos já exis-tentes? Quais foram os resultados desses estudos?

Se disponível

Relevância na prática

Como se relaciona ao estado da prática? Se disponível

Planejamento do experimento

Metas Formalização das metas, reﬁnamento das constru-ções importantes (por exemplo, foco na qualidade) das metas do experimento

Requerido

(31)

Unidades experimen-tais

De qual população as amostras serão tiradas? Como os grupos serão formados (atribuição aos tratamen-tos)? Qualquer tipo de aleatoriedade ou blinding

deve ser descrito

Requerido

Material ex-perimental

Quais objetos são selecionados e por quê? Requerido

Tarefas Quais tarefas devem ser realizadas pelos indivíduos? Requerido Hipóteses,

parâmetros e variáveis

Quais são as construções e sua operacionalização? Elas devem ser derivadas da questão de pesquisa e da meta do experimento

Necessário (um estudo explora-tivo pode não ter hipóteses) Projeto Que tipo de projeto experimental foi escolhido? Requerido Procedimento Como o experimento será realizado (por exemplo,

coleta de dados)? Quais instrumentos, materiais, ferramentas serão usados e como?

Pode ser inte-grado à execu-ção

Procedimento da análise

Como os dados serão analisados? Pode ser inte-grado à análise Execução Preparação O que foi feito para preparar a execução do

experi-mento (por exemplo, horários, treinaexperi-mento)

Desvios Descreve qualquer desvio do planejado, por exem-plo, como a coleta de dados foi realizada de fato? Análise Estatística

descritiva

Quais são os resultados de estatística descritiva? Requerido

Preparação do conjunto de dados

O que foi feito para preparar o conjunto de dados, como e por quê?

Teste da hi-pótese

Como os dados foram avaliados e como o modelo de análise foi validado?

Discussão Avaliação dos

resul-tados e

implicações

Explicar os resultados e a relação dos resultados de pesquisa anterior, especialmente o que foi mencio-nado na seçãoBackground

Ameaças à validade

Como a validade dos resultados experimentais é ga-rantida? Como os dados foram validados de fato?

Requerido

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 hi-pótese captura os objetivos, a generalização dos re-sultados)

(32)

Inferências Inferências obtidas a partir dos dados em direção a condições mais gerais

Requerido

Lições aprendidas

Qual experiência foi adquirida ao longo do experi-mento

Recomendado

Conclusões e trabalhos

Resumo Resumo conciso da pesquisa e de seus resultados como apresentado nas seções anteriores

Requerido

futuros Impacto Descrição dos impactos com relação aos custos, cro-nograma e qualidade, circunstâncias sob as quais a abordagem pode não trazer os benefícios esperados Trabalhos

futuros

Quais outros experimentos podem ser executados para investigar os resultados obtidos ou para evoluir o corpo de conhecimento

Requerido

Agradecimentos Agências de fomento, participantes e colaboradores que não cumprem os requisitos para a autoria devem ser mencionados

Se for necessá-rio

Referências A literatura citada deve ser apresentada no formato requerido pelo editor

Requerido

Apêndices Materiais do experimento, os dados brutos e as aná-lises detalhadas, o que pode ser útil para outros pes-quisadores desenvolverem seus trabalhos

Podem ser dis-ponibilizados 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.

(33)

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

(34)

C

APÍTULO

3

Ontologia

Ontologias podem ser utilizadas para permitir que pesquisadores tenham acesso a fontes de in-formação heterogêneas que são expressas usando vocabulários diversos ou formatos inacessíveis ( Bi-olchini 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 é inves-tigar 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 EROntology, 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ção3.4) e dematching 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)).

Umaconceituaçã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 maneiraexplícitasob a forma de conceitos e relações entre eles.

Adicionalmente, deve haver uma especiﬁcação formaldos conceitos, em um formato que seja

(35)

3.1 Visão geral sobre ontologia

pode ser considerada como um conjunto de tais axiomas.

Programador (Pedro) Programador (Julia)

Gerente (João)

Figura 3.1: Domínio de recursos humanos, adaptado deGuarino et al.(2009)

Programador

reportaA

Gerente Pessoa

1 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 quep1 ep2 representam programadores ego gerente ao qualp1 ep2 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 especificação formal de uma conceituação não é, necessariamente, uma especificação de uma conceituaçãocompartilhada(Guarino et al.,2009). A fim 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 serconsensualentre as partes.

Portanto, pode-se afirmar que uma ontologia é uma especificação de conhecimento consensual sobre um modelo abstrato de domínio, definida explicitamente em termos de conceitos e seus relaci-onamentos por meio de axiomas, possibilitando, assim, que seja legível por máquinas.

(36)

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 amanutençã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} Lan-guage), 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 com-ponentes básicos da linguagem:classes,propriedadeseinstâ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

Enge-nharia de Software

Com o objetivo de lidar com as problemas na transferência de conhecimento entre grupos de pes-quisa (ver Seção2.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.

(37)

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 referen-tes 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

Quality of Study

Control Structure of

Study

Intervention Hypothesis

Problem

Unit of Study Outcome

Measurement

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 Figura3.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)

Ambiente de Experimentação

consulta consulta

instancia

Pesquisador eSEE

(38)

3.2 Ontologias para experimentos controlados em Engenharia de Software

Sob outra perspectiva, Garcia et al.(2008) estabeleceram uma ontologia especíﬁca para experi-mentos controlados, aEXP EROntology, que descreve os conceitos que devem compor um pacote de

laboratório. A EXP EROntology tem o propósito de padronizar conceitos e facilitar o

compartilha-mento de pacotes de laboratório (Garcia et al.,2008).

3.3

_{EXP ER}

Ontology

AEXP EROntologyfoi elaborada para esclarecer os conceitos associados a experimentos

contro-lados 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 Figura3.6, contém os principais conceitos de experimen-tos controlados. O segundo nível, na Figura 3.7 se refere ao reﬁnamento do conceito de pacote de laboratório. <<concept>> Designer <<concept>> Experimenter Profile <<concept>> Replicator 1 1..* has 1 0..*

is basis for <<concept>> Lab package <<concept>> Validity <<concept>> Replication 1 1 is recorded 1 1 generates 1 1 generates 1 1..* has 1..* 1 conducts 1..* 1..* designs 0..* 0..1 influences 1 1 has <<concept>> Original experiment 1 1 has

Figura 3.6:EXP EROntology- conceitos de experimentos controlados (Garcia et al.,2008)

Para formalizar a ontologia, foram criados axiomas de Lógica de Primeira Ordem. Por exemplo, o predicadoDesignque 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)

(39)

3.3EXP EROntology

<<concept>>

Context

<<concept>>

Initial hypothesis

- Alternative hypothesis : char - Null hypothesis : char

<<concept>> Hypothesis formalised <<concept>> Experiment object <<concept>> Experimental design <<concept>> Result <<concept>> Technology <<concept>> Form <<concept>> Profile <<concept>> Subject <<concept>> Execution Plan <<concept>> Artifact <<concept>> Dependent variable <<concept>> Independent variable 1..* 1 generates 1..* 1..*

is basis for

1 1..*

is basis for

1..* 1

is defined from

1

1 can be a value of 1..*

1..* is defined from

1..* 1..*

is basis for

1 1..*

uses as factor

1 1..*

uses as treatment

1 1..* 1 1..* 1 1..* 1 1 follows 1 1..* follows 1 1 has 1 1..*

is obtained by

1..* 1..* can use <<concept>> Training 1

0..* can be

1 describes 1..*

1

1..* is basis for <<concept>>

Confirmatory analysis

<<concept>>

Exploratory analysis

- Period : int <<concept>> Task <<concept>> Task performed <<concept>> Task planned 0..* 1..* is obtained during a

1..* 1..* Is obtained using in a 1..*

1..*

is applied in

1..* 1

is obtained applying a

1

1 teaches in

1..* 1..*

is defined from <<concept>>

Object of study

<<concept>> Purpose <<concept>> Quality focus <<concept>> Technique <<concept>> Tool <<concept>> Method <<concept>> Questionnaire <<concept>> Document <<concept>> Analysis 1..* 1..* uses 1..* - Technique : String

Statistical analysis _1..*

Figura 3.7:EXP EROntology- conceitos de um pacote de laboratório (Garcia et al.,2008)

predicadoDesigné 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 predicadoT raining indica que um participantes pode ser treinado em uma tecnologiatr

(40)

3.3EXP EROntology

participantesaplica a tecnologiatrno artefatoadurante um período de tempop.

Na EXP EROntology 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 ins-tanciados. Contextualizando no processo de desenvolvimento de ontologias da Figura3.3, Garcia et al.(2008) apresentaram a Conceituação (conceitos e relacionamentos) e a Formalização (um conjunto de axiomas) daEXP EROntology.

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 influenciar e modificar as definições da ontologia (Fensel, 2001). Evoluir ao longo do tempo é um requisito essencial para que uma ontologia seja útil (Fensel,2001).

Aevoluçãode 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 Figura3.8.

Processo de evolução de ontologia Representa -ção Semântica da mudança Requisição para uma mudança Implementa-ção Mudança requerida Mudanças requeridas e derivadas Modificação de artefatos dependentes Ontologia modificada Propagação

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 desemântica da mudança, deve ser garantida a consistência do restante da

ontologia diante das mudanças a serem realizadas. No exemplo da Figura3.9, a classeTechnology

tem a propriedadeisAppliedInrelacionando-a com a classeArtifact. As classesMethod,Technique

e Tool são subclasses de Technology. Por serem subclasses, herdam a propriedade isAppliedIn

relacionando-as aArtifact.