4.2 Instância do workflow
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 definido naEXP EROntologypara estabelecer uma correspondência.
Estabelecer a correspondência de maneira manual requer que o usuário analise os conceitos defini- dos 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 identificar 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 workflow é executado. Essa abordagem implica em melhorias para as próximas vezes em que a resoluçãoe o matching forem executados.
Caso não esteja definido um conceito adequado para instanciar um determinado elemento de in- formação, por meio da atividade de evolução o usuário é capaz de solicitar mudanças à definição da ontologia a fim de permitir a instanciação do elemento pendente. Essas mudanças devem ser conside- radas 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 definições (EXP EROntology) 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 simplificado nesse caso, porque as mudanças admitidas pelo workflow a partir da análise dos elementos de informação abrangem apenas mudanças de adição de conceitos.
Os conceitos da EXP EROntology 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 workflow 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 definida (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 fim de evitá-los.
Vale ressaltar que as mudanças realizadas na ontologia são refletidas na terminologia utilizada como recurso externo de apoio ao matching e à resolução. Se um novo conceito é adicionado à
EXP EROntology, então é criada uma nova entrada na terminologia referente ao termo. Quanto às
mudanças que podem ser efetuadas na terminologia por meio do workflow, o usuário pode solicitar que seja inserido um novo termo similar à entrada de um conceito da ontologia:
4.3 Considerações finais
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 é intro- duzido 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 finais
Neste capítulo foi proposto um workflow 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 workflow, 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 daEXP EROntologyaprimora a sua aplicação em empacotar experimentos.
No capítulo seguinte é apresentada uma avaliação da proposta, com a operacionalização do work- flowe a demonstração de sua execução, utilizando como entrada publicações de experimentos con- trolados.
CAPÍTULO
5
Avaliação do workflow
Para avaliar o workflow proposto, é preciso exercitar cada uma de suas atividades. Assim, a partir das definições (Capítulo 4), é preciso operacionalizá-lo com a implementação de cada uma delas. Como entrada do workflow, é 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 publi- cações de experimentos controlados como pacotes de laboratório de entrada. Na Seção5.1é dada uma visão geral da ferramenta PontoLab++, que implementa as atividades do workflow, admitindo pacotes de laboratório de entrada sob o formato XML. Na Seção5.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 workflow por meio da ferramenta PontoLab++.
5.1
Ferramenta PontoLab++
A ferramenta PontoLab++ consiste na implementação da instância do workflow de empacota- mento descrita na Seção 4.2. Foi utilizada a linguagem de programação Java, o que possibilitou a adoção das APIs JDOM1e OWL API2para a manipulação de documentos XML e OWL, respectiva-
mente.
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
1http://www.jdom.org 2http://owlapi.sourceforge.net
5.1 Ferramenta PontoLab++
de entrada. As demais entradas do matching, como aEXP EROntology, a terminologia e o threshold
são configuradas separadamente, conforme pode ser visto na Figura5.2.
Figura 5.1: PontoLab++ - Interface inicial com os ajustes para a execução do workflow
Figura 5.2: PontoLab++ - Interface com os demais ajustes para a execução do workflow 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 daEXP EROntologycom a qual foi estabelecida uma correspondência (Class).
5.1 Ferramenta PontoLab++
Figura 5.3: PontoLab++ - Interface com o conjunto de elementos de informação casados
5.1 Ferramenta PontoLab++
preciso selecionar uma classe da hierarquia daEXP EROntology(Figura5.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 definida na hierarquia daEXP EROntology 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 workflow 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 dificuldade em se acessar diretamente os pa- cotes 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- flow. 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 estrutura- dos, os elementos de informação estão dispersos em meio ao texto em linguagem natural.