Andrêza Leite de Alencar - repositorio.ufpe.br · Estes ambientes possuem características como o...

“VisualSPEED:Uma Interface de Interação com o Usuáriopara PDMS Baseado em Ontologias”

Por

Andrêza Leite de Alencar

Dissertação de Mestrado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, Março/2012

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Andrêza Leite de Alencar

“VisualSPEED:Uma Interface de Interação com oUsuário para PDMS Baseado em Ontologias”

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Ana Carolina Brandão Salgado

RECIFE, Março/2012

A Deus, que sempre me guiou nessa jornada,

A minha Mãe, Querubina,

A minha irmã, Andréa.

Agradecimentos

Agradeço...

• À minha família, por ter acreditado no meu sonho e por ter me dado todo o apoionessa conquista;

• À minha orientadora Ana Carolina Salgado, pela sua confiança e orientação semprerica de boas idéias e conselhos pertinentes;

• Aos membros do projeto SPEED, por terem criado um excelente ambiente detrabalho, de aprendizado e de companheirismo;

• Aos docentes do Centro de Informática da UFPE, pelos ensinamentos e auxíliodurante os anos de mestrado;

• Ao meu namorado Julio, por todos os cuidados, força, suporte e, acima de tudo,pela sua amizade e compreensão nos momentos mais difíceis dessa jornada;

• Aos meus amigos e companheiros de mestrado, em especial Talitha Huanna, Jo-sino Rodrigues, Wilton Oliveira, Carlos Portela e Bruno Leonardo, pelo apoio emotivação nos momentos que mais precisei.

• Aos amigos paraenses, que me receberam de braços abertos e sempre me fizeramsentir o "gostinho de casa"presente na vida em Recife;

• Aos amigos distantes que, de alguma forma, sempre estiveram torcendo por mim;

• À vida, que me deu mais esta oportunidade de aprender e crescer;

• A todos os amigos que direta ou indiretamente contribuíram para realização destesonho.

Muito Obrigado!

iv

I open my eyes each morning I rise, to find a true

thought, know that it’s real, I’m lucky to breathe,

I’m lucky to feel, I’m glad to wake up, I’m glad to be

here, with all of this world, and all of it’s pain, all

of it’s lies, and all of it’s flipped down, I still

feel a sense of freedom, so glad I’m around,

It’s my freedom, can’t take it from me, i know it, it

won’t change, but we need some understanding, I know

we’ll be all right.

—S.O.JA. (Open My Eyes)

Resumo

A problemática da interação do usuário para a formulação e execução de consultasvem sendo investigada para ambientes distribuídos e dinâmicos, tais como Peer Data

Management System (PDMS). Estes ambientes possuem características como o fato deserem altamente dinâmicos em uma infraestrutura de pontos distribuídos, heterogêneos eautônomos. Muitos destes PDMS baseados em semântica são compostos por pontos dedados cujos esquemas exportados são representados por ontologias. Alguns destes PDMSjá propuseram interfaces para interação com o usuário, mas nenhuma das abordagensatende, de forma geral, as necessidades de um PDMS no que diz respeito à interação como usuário.

Neste sentido, definimos uma interface visual para PDMS que proporciona ao usuá-rio uma interação simples e objetiva com este tipo de sistema. A VisualSPEED foidesenvolvida e validada no ambiente de um PDMS baseado em ontologias chamadoSPEED (Semantic PEEr-to-Peer Data Management System). Esta interface apresentaas ontologias graficamente e em hierarquia de conceitos, permitindo a formulação deconsultas por meio da manipulação desta visualização da ontologia, selecionando osconceitos desejados para a consulta e combinando-os com operadores da Description

Logic (DL).Uma outra opção para submissão de consultas é o uso de templates SPARQL(SPARQL Protocol and RDF Query Language), onde o usuário deve apenas inserir osconceitos desejados para a consulta. Ainda para a execução de consultas, é possívelmelhorar os resultados obtidos enriquecendo a consulta submetida, com o uso de va-riáveis que representam relacionamentos entre os conceitos da consulta (aproximação,subconceito, superconceito e agregação). Além da formulação e submissão de consultas,a interface possibilita uma visualização organizada dos resultados com informações sobreas correspondências semânticas que os geraram e os pontos de origem identificados emuma topologia gráfica da rede.

A VisualSPEED foi especificada, seguindo técnicas de análise e prototipação, eimplementada. Para a avaliação da interface, foram realizados experimentos com doistipos de usuário (especialista e não especialista) e verificação de conformidade com oscritérios de usabilidade. Analisados os resultados obtidos das avaliações, concluímos quea VisualSPEED é uma interface visual que apresenta as funcionalidades e transparêncianecessárias para interação do usuário com um PDMS.

Palavras-chave: Interface, Interação com o Usuário, Ontologia, Ambientes Distribuídose Autônomos, PDMS.

vi

Abstract

The issue of user interaction for query formulation and execution has been investigated fordistributed and dynamic environments, such as Peer Data Management System (PDMS).These environments have characteristics such that they are highly dynamic in a infras-tructure of distributed, heterogeneous and autonomous peers. Many of these semanticsbased PDMS are composed of data peers whose exported schemes are represented byontologies. There are some approachs that have already proposed PDMS interfaces, butnone of them addresses the PDMS needs for user interaction.

In this sense, we defined a visual interface for PDMS which provides the user a simpleand straightforward interaction. The VisualSPEED was developed and validated in theenvironment of a PDMS, ontology based, called SPEED (Semantic PEEr-to-Peer DataManagement System). This interface presents ontologies graphically as a graph and as ahierarchy of concepts, providing a visual query formulation by ontology manipulation,selecting the concepts and combining them with Description Logic (DL) operators.Another option to submit queries is using SPARQL (SPARQL Protocol and RDF QueryLanguage) templates, inserting just the concepts to be queried. Even for running queries,is possible to improve the results enriching the submitted query, by using variables thatrepresent relationships between query concepts (approach, subconcept, superconceptand aggregation). In addition to query formulation and submission, the interface allowsan organized results view with information about the semantic correspondences thatgenerated them, and the results origin peer identified graphically in a network topology.

The VisualSPEED was specified, using analysis and prototyping techniques, andimplemented. For interface assessment, experiments were performed with two user types(experts and non-experts) and compliance verification with usability criteria as well.Analyzed the evaluations results, we concluded that VisualSPEED is a visual interfacethat provides the functionality and transparency necessary for user interaction with aPDMS.

Keywords: Interface, User Interaction, Ontology, Autonomous and Distributed Environ-ments, PDMS

vii

Sumário

Lista de Figuras xi

Lista de Quadros xiii

Lista de Siglas xiv

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . 41.4 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Conceitos Básicos 62.1 Interfaces Visuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Interação Humano-Computador . . . . . . . . . . . . . . . . . 72.1.2 Projeto de Interface . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Peer-to-Peer (P2P) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Topologia P2P Pura . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Topologia P2P Híbrida . . . . . . . . . . . . . . . . . . . . . . 142.2.3 Topologia P2P Super-Peer . . . . . . . . . . . . . . . . . . . . 15

2.3 Peer Data Managemen System (PDMS) . . . . . . . . . . . . . . . . . 162.4 Ontologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 Resource Description Framework (RDF) . . . . . . . . . . . . 192.4.2 Web Ontology Language (OWL) . . . . . . . . . . . . . . . . 19

2.5 Lógica Descritiva (DL) . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6 SPARQL Protocol and RDF Query Language . . . . . . . . . . . . . . 212.7 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Interfaces e PDMS 233.1 Interfaces Baseadas em Ontologia . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Formulação de Consultas . . . . . . . . . . . . . . . . . . . . . 233.1.2 Interação do Usuário . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Interfaces de Peer Data Management Systems - PDMS . . . . . . . . . 253.2.1 Interfaces de Consulta Baseadas em Navegação . . . . . . . . . 25

viii

3.2.2 Interfaces de Consulta Baseada em Múltiplas Visões . . . . . . 303.2.3 Interface Baseada no Roteamento de Consultas . . . . . . . . . 323.2.4 Resumo Comparativo das Abordagens Apresentadas . . . . . . 33

3.3 O sistema Semantic PEEr-to-Peer Data Management System (SPEED) . 353.3.1 Arquitetura do Sistema SPEED . . . . . . . . . . . . . . . . . 353.3.2 Geração de Correspondências Semânticas entre Esquemas . . . 373.3.3 Conexão de um Novo Ponto . . . . . . . . . . . . . . . . . . . 413.3.4 Processamento de Consultas . . . . . . . . . . . . . . . . . . . 423.3.5 Reformulação de Consultas no SPEED . . . . . . . . . . . . . 42

3.4 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 VisualSPEED: Uma Interface de Interação com o Usuário para PDMS Ba-seado em Ontologias 464.1 Arquitetura da VisualSPEED . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.1 Módulo ViewOntology . . . . . . . . . . . . . . . . . . . . . . 484.1.2 Módulo FormQuery . . . . . . . . . . . . . . . . . . . . . . . 484.1.3 Módulo ViewResults . . . . . . . . . . . . . . . . . . . . . . . 494.1.4 Módulo ViewNetwork . . . . . . . . . . . . . . . . . . . . . . . 504.1.5 Módulo QueryManager . . . . . . . . . . . . . . . . . . . . . 514.1.6 Módulo CommunicationManager . . . . . . . . . . . . . . . . 51

4.2 Requisitos Estabelecidos para a Interface VisualSPEED . . . . . . . . . 514.3 Prototipação da Interface VisualSPEED . . . . . . . . . . . . . . . . . 554.4 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 Implementação e Estudo de Caso 635.1 Implementação da Interface VisualSPEED . . . . . . . . . . . . . . . . 63

5.1.1 Submissão de Consultas . . . . . . . . . . . . . . . . . . . . . 645.1.2 Visualização de Resultados . . . . . . . . . . . . . . . . . . . . 665.1.3 Visualização da Topologia da Rede . . . . . . . . . . . . . . . 675.1.4 Documentação da Interface . . . . . . . . . . . . . . . . . . . . 69

5.2 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.3 Processamento de uma Consulta . . . . . . . . . . . . . . . . . . . . . 715.4 Visualização dos Resultados da Consulta . . . . . . . . . . . . . . . . . 735.5 Avaliação da Interface VisualSPEED . . . . . . . . . . . . . . . . . . . 74

5.5.1 Avaliação da Usabilidade e Relevância das Funcionalidades . . 745.5.2 Avaliação da Usabilidade e Qualidade Ergonômica da Interface 77

ix

5.6 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Conclusões e Trabalhos Futuros 836.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Referências 87

Apêndices 93

A Protótipos de Alta Fidelidade da Interface VisualSPEED 94

B Telas Implementadas da VisualSPEED 97

C Questionário para Avaliação das Funcionalidades da Interface VisualSPEED 98

D Respostas do Questionário de Avaliação das Funcionalidades da VisualS-PEED 101

x

Lista de Figuras

2.1 Processo de Projeto de Interação. Adaptado de (Dix et al., 2003) . . . . 102.2 Topologia P2P Pura. (Fiorano, 2011) . . . . . . . . . . . . . . . . . . . 132.3 Topologia P2P Híbrida. (Fiorano, 2011) . . . . . . . . . . . . . . . . . 142.4 Topologia P2P Super-Peer. (Fiorano, 2011) . . . . . . . . . . . . . . . 152.5 Exemplo de Consulta SPARQL Protocol and RDF Query Language

(SPARQL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Protótipo da interface de consulta da Query Tool (Franconi et al., 2010) 263.2 Navegando para criação de um padrão de consulta do GRQL (Athanasis

et al., 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Interface de consulta do SEWASIE (SEWASIE, 2011) . . . . . . . . . . 293.4 Interface de consulta do Ontogator (Hyvonen and Viljanen, 2003) . . . 303.5 Interface de consulta do sistema OntoViews (Makela et al., 2004) . . . . 313.6 Interface gráfica do SUNRISE (Mandreoli et al., 2007) . . . . . . . . . 323.7 Arquitetura do sistema SPEED (Pires, 2009) . . . . . . . . . . . . . . . 373.8 Utilizando uma Ontologias de Domínio (OD) para especificar as Corres-

pondências Semânticas (Souza, 2009) . . . . . . . . . . . . . . . . . . 393.9 Ontologia de Domínio (Souza, 2009) . . . . . . . . . . . . . . . . . . . 403.10 Ontologias Comparáveis (Souza, 2009) . . . . . . . . . . . . . . . . . 403.11 Descoberta de clusters semânticos através de comparação ontológica

(Pires, 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.12 Cenário das consultas no SPEED(Souza, 2009) . . . . . . . . . . . . . 44

4.1 Arquitetura do sistema destacando as camadas e módulos que irão operarnas atividades de interação do usuário com o sistema SPEED . . . . . . 47

4.2 Funcionamento do Módulo ViewOntology . . . . . . . . . . . . . . . . 494.3 Funcionamento do Módulo FormQuery . . . . . . . . . . . . . . . . . 494.4 Funcionamento do Módulo ViewResults . . . . . . . . . . . . . . . . . 504.5 Funcionamento do Módulo ViewNetwork . . . . . . . . . . . . . . . . 514.6 Diagrama de casos de uso do sistema SPEED . . . . . . . . . . . . . . 544.7 Protótipo da tela de consulta com visualização gráfica de uma ontologia 564.8 Protótipo da tela de consulta com visualização hierárquica de uma ontologia 574.9 Protótipo da tela para submissão de consulta SPARQL . . . . . . . . . 584.10 Protótipo de visualização dos pontos de origem de um resultado . . . . 60

xi

4.11 Tela de cadastro de um novo ponto . . . . . . . . . . . . . . . . . . . . 61

5.1 Tela para princípio da submissão de consultas por usuário Usuário NãoParticipante da Rede (UN) . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Tela de consulta com visualização gráfica de uma ontologia . . . . . . . 655.3 Tela de consulta com visualização hierárquica de uma ontologia . . . . 665.4 Tela para submissão de consultas SPARQL . . . . . . . . . . . . . . . 675.5 Tela de visualização das correspondências semânticas e feedback . . . . 675.6 Tela de visualização dos pontos de origem de um resultado . . . . . . . 685.7 Tela para visualização gráfica da topologia rede . . . . . . . . . . . . . 685.8 Tela para visualização do Javadoc da interface . . . . . . . . . . . . . . 695.9 Ontologia O1= LOEdu.owl do ponto de dados PD 2378 . . . . . . . . 705.10 Processamento de uma consulta no sistema SPEED . . . . . . . . . . . 715.11 Resultado das consultas sem uso de variáveis de enriquecimento . . . . 735.12 Resultado das consultas enriquecidas . . . . . . . . . . . . . . . . . . . 735.13 Informações semânticas para o resultado da consulta não enriquecida . . 745.14 Informações semânticas para o resultado da consulta enriquecida . . . . 745.15 Gráfico com percentuais de avaliação das funcionalidades por usuários

especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.16 Gráfico com percentuais de avaliação das funcionalidades por usuários

não especialistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.17 Gráfico com percentuais individuais de adequação aos critérios de usabi-

lidade do ErgoList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.18 Gráfico de adequação geral da interface desenvolvida à avaliação do

ErgoList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A.1 Protótipo da tela principal do sistema SPEED . . . . . . . . . . . . . . 94A.2 Protótipo da tela de documentação do sistema SPEED . . . . . . . . . . 95A.3 Protótipo de tela para o princípio da submissão de consultas por usuário UN 95A.4 Protótipo para visualização das correspondências semânticas que geraram

os resultados e feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 96A.5 Protótipo da tela de visualização da topologia da rede por usuário UP . . 96

B.1 Tela de cadastro de um novo ponto . . . . . . . . . . . . . . . . . . . . 97

C.1 Questionário de Avaliação do Usuário(Página 1) . . . . . . . . . . . . . 99C.2 Questionário de Avaliação do Usuário(Página 2) . . . . . . . . . . . . . 100

xii

Lista de Quadros

2.1 Comparação entre as topologias P2P. Adaptado de (Fiorano, 2011) . . . 16

3.1 Quadro resumo das abordagens apresentadas . . . . . . . . . . . . . . . 34

4.1 Quadro de contribuição da VisualSPEED em relação as abordagens exis-tentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

D.1 Totais de Respostas Obtidas por Usuários Não Especialistas . . . . . . . 102D.2 Totais de Respostas Obtidas por Usuários Especialistas . . . . . . . . . 102

xiii

Lista de Siglas

ALC Attribute Language with Complement

API Application Programming Interface

BA Brokering Agents

DHT Distributed Hash Table

DL Description Logic

DAWG RDF Data Access Working Group

GUI Graphical User Interface

GRQL Graphical RQL

GVV Global Virtual View

IHC Interação Humano Computador

IDE Integrated Development Environment

NLG Natural Language Generation

OWL Web Ontology Language

QA Query Agents

QueLo Query Logic

OD Ontologias de Domínio

OWL Web Ontology Language

OPDMS Ontology-based Peer Data Management System

PDMS Peer Data Management System

P2P Peer-to-Peer

RDF Resource Description Framework

RF Requisitos Funcionais

xiv

RQL RDF Query Language

RDQL RDF Data Query Language

SEWASIE SEmantic Web and AgentS in Integrated Economies

SINode Information Node

SPEED Semantic PEEr-to-Peer Data Management System

SPARQL SPARQL Protocol and RDF Query Language

SQL Structured Query Language

SRI Semantic Routing Index

SeRQL Sesame RDF Query Language

SWT Standard Widget Toolkit

UA User Agent

UFPE Universidade Federal de Pernambuco

UI User Interface

UML Unified Modeling Language

UP Usuário Participante da Rede

UN Usuário Não Participante da Rede

URI Uniform Resource Identifier

VQS Visual Query System

VQL Visual Query Language

WIMP Windows, Icons, Menus e Pointers

WYSIWYG What you see is what you get

W3C World Wide Web Consortium

XML Extensible Markup Language

xv

1Introdução

Neste capítulo, será feita uma breve introdução dos aspectos que motivaram e caracteriza-ram este trabalho. Também serão apresentados os objetivos desta pesquisa, assim como aestrutura desta dissertação.

1.1 Motivação

Recentemente, a problemática envolvendo a formulação e execução de consultas vemsendo investigada em diferentes tipos de ambientes, tais como Sistemas de Integração deDados (Halevy et al., 2006), PDMS (Blanco et al., 2006) e na Web Semântica (Berners-Lee et al., 2001). Estes ambientes, apesar de algumas diferenças, possuem característicascomuns como o fato de serem altamente dinâmicos em uma infraestrutura de pontosdistribuídos, heterogêneos e autônomos. Para facilitar a integração, muitos destes sistemasrepresentam seus esquemas de dados através de ontologias.

Sistemas distribuídos e dinâmicos dispõem de vários meios para que seus usuáriospossam formular suas consultas. Uns disponibilizam algum tipo de linguagem de consulta,como Structured Query Language (SQL) (SQLOrg, 2012) ou SPARQL (Prud’hommeauxand Seaborne, 2008), enquanto outros fazem uso de interfaces de formulários, Web ouvisuais, que tornam a interação um pouco mais amigável (Blanco et al., 2006). Algumasdessas interfaces utilizam modelos de categorias ou mesmo ontologias representandotambém o domínio de interesse (Hoang and Tjoa, 2006). Contudo, em geral, essasabordagens não trazem grandes benefícios para os usuários, nem permitem a transparêncianecessária às diversas estruturas presentes nas fontes de dados. Isso faz com que osusuários, muitas vezes, tenham de entender os detalhes sobre a estrutura do ambiente eseus mecanismos de gerenciamento para conseguirem formular as consultas.

Pode-se destacar alguns problemas que dificultam a utilização de interfaces de con-

1

1.2. JUSTIFICATIVA

sulta comumente encontradas em tais ambientes:

• Os vários níveis de usuários existentes – leigos, semi-leigos ou especialistas –possuem especificidades inerentes aos seus objetivos e conhecimento técnico ou dodomínio;

• As linguagens de consulta existentes não são consideradas fáceis de usar, obrigandoo usuário a conhecer detalhes técnicos das mesmas se quiser obter resultadossatisfatórios;

• O usuário necessita ter amplo conhecimento da estrutura existente nas fontes dedados a fim de conseguir especificar com precisão e sem ambiguidades a suanecessidade de informação independente do nível de conhecimento técnico;s e

• A informação quando retornada ao usuário pelo sistema nem sempre satisfaz assuas necessidades. O usuário pode preferir receber uma resposta aproximada a nãoreceber resposta alguma.

Neste sentido, interfaces de consulta em ambientes distribuídos e dinâmicos baseadosem ontologias devem ser desenvolvidas considerando a usabilidade dos sistemas atuaispara proporcionar ao usuário uma interação simples e objetiva com o sistema.

1.2 Justificativa

O desenvolvimento de aplicações na Web, com a maior participação dos usuários naprodução de informações (Web 3.0), fez crescer a necessidade por novas arquiteturasde sistemas distribuídos. Uma delas é a arquitetura P2P (Peer-to-peer) que vem sendobastante utilizada para trocas de informações, especialmente arquivos, na Web (Milojicicet al., 2003). O interesse deste trabalho se concentra no problema de gerenciamento dedados, acessados a partir de fontes de dados distribuídas, e a integração dos mesmos pararesponder às consultas efetuadas nos diversos pontos que compõem um sistema P2P. Ossistemas de gerenciamento de dados P2P ou PDMS (Peer Data Management Systems)representam uma evolução dos tradicionais sistemas de integração de dados.

O termo P2P refere-se a uma variedade de sistemas e aplicações que empregamrecursos de maneira distribuída para realizarem suas atividades de uma maneira descen-tralizada (Milojicic et al., 2003). PDMS é uma aplicação peer-to-peer na qual cada umde seus elementos constituintes é um ponto de dados autônomo que pode compartilhar

2

1.2. JUSTIFICATIVA

seus esquema de dados com os demais pontos de forma total ou parcial (Blanco et al.,2006). Os sistemas PDMS são um exemplo muito comum e importante de um ambientedistribuído e dinâmico. O compartilhamento de dados entre os pontos em um PDMS éfeito pela exportação de seus esquemas. Um PDMS possui as seguintes características:compartilhamento descentralizado dos dados; escalabilidade; processamento e armazena-mento de dados distribuídos feitos a partir de pontos autônomos que também armazenamas correspondências semânticas dos dados (Blanco et al., 2006).

Os PDMS representam uma evolução dos tradicionais sistemas de integração dedados, onde o esquema global único é substituído por uma coleção de correspondênciassemânticas entre os esquemas dos pontos que compõem a rede (Blanco et al., 2006).Tais correspondências permitem que o PDMS recupere dados que são semanticamentesimilares, mas se encontram descritos por diferentes esquemas e armazenados em pontosdistintos.

Muitos desses PDMS baseados em semântica são compostos por pontos cujos esque-mas exportados são representados por ontologias. Muitas definições de ontologia sãoencontradas na literatura. Uma das definições diz que ontologia é uma descrição formalexplícita de conceitos em um domínio do discurso, de propriedades de cada conceitodescrevendo atributos ou características, e de restrições dessas propriedades (Noy andMcguinness, 2002). Outro trabalho considera também que uma ontologia juntamente comdefinições de instâncias de seus conceitos forma uma base de conhecimento (Guarino,1998). Os conceitos são as entidades principais de uma ontologia, podendo representarum domínio de aplicação.

Uma grande vantagem dos sistemas PDMS é a de que qualquer ponto pode submeteruma consulta na rede utilizando apenas seu próprio esquema de dados, sem precisar co-nhecer esquemas de outros pontos. Com isso, através dos caminhos semânticos existentesentre os pontos, a consulta original pode ser reformulada (adequada) aos outros pontosdo caminho semântico, de acordo com seus respectivos esquemas de dados.

O sistema SPEED é um PDMS baseado em semântica, composto de pontos cujosesquemas exportados são representados por ontologias (Pires, 2009).Para este sistema, foidesenvolvido um módulo de consultas que possibilita: a submissão de consultas em umdado ponto da rede; a identificação da semântica da consulta; o enriquecimento semânticoda consulta; sua reformulação ao ser passada para outros pontos da rede; a execução da

3

1.3. OBJETIVOS

consulta nos pontos requisitados; a integração dos resultados no ponto que submeteu aconsulta; e a exibição dos resultados para o usuário. Uma primeira versão do módulo deconsultas já foi implementada baseando-se no fato que os esquemas das fontes de dadossão representados por ontologias necessitando ainda de uma interface que dê suporte aeste tipo de consulta que possa ser submetida nos diferentes pontos da rede.

1.3 Objetivos

O objetivo geral deste trabalho é desenvolver uma interface que proporcione aos usuáriosuma interação simples e objetiva com PDMS. Para alcançar tal objetivo, será feito umlevantamento do estado da arte da interação do usuário em ambientes de PDMS. Estainterface será desenvolvida e validada no ambiente do sistema SPEED.

1.3.1 Objetivos Específicos

• Especificar e implementar uma interface de interação com o usuário para PDMS ;

• Melhorar o processo de interação do usuário em ambientes distribuídos e dinâmicosbaseados em ontologias;

• Auxiliar os usuários na formulação e execução de consultas;

• Melhorar a visualização de resultados de consultas em PDMS; e

• Fazer os experimentos da interface no ambiente do sistema SPEED.

1.4 Organização da Dissertação

Este trabalho está organizado em seis capítulos, conforme a divisão que se segue:

• O Capítulo 1 introduz e motiva as idéias principais do trabalho, destacando amotivação, a justificativa, os objetivos e a estrutura da dissertação;

• O Capítulo 2 apresenta os principais conceitos que fundamentam este trabalho. En-tre estes são apresentados os conceitos envolvidos à concepção e à implementaçãode interfaces de interação com o usuário em ambientes distribuídos baseados emontologia;

4

1.4. ORGANIZAÇÃO DA DISSERTAÇÃO

• O Capítulo 3 apresenta os principais tipos de interface de consulta utilizados emPDMS bem como as abordagens existentes para estes tipos de interface;

• O Capítulo 4 apresenta a especificação de uma interface visual de interação com ousuário PDMS baseados em ontologia, detalhando a arquitetura proposta, definiçãode requisitos e prototipação da interface;

• O Capítulo 5 apresenta os detalhes de implementação da interface proposta eum estudo de caso detalhando as funcionalidades contempladas, em um cenáriodefinido para experimentação desta. Este capítulo apresenta, também, a avaliaçãoda interface desenvolvida; e

• O Capítulo 6 resume o trabalho realizado, discutindo as contribuições alcançadas eindicando algumas pesquisas futuras para extensão da proposta.

5

2Conceitos Básicos

Neste capítulo serão discutidos os principais conceitos relacionados à concepção e àimplementação de interfaces de interação com o usuário. Serão abordadas também, ascaracterísticas de sistemas P2P, PDMS, ontologias e SPARQL, inerentes ao escopo destetraballho.

2.1 Interfaces Visuais

As interfaces de usuário, em especial as interfaces visuais, têm a preocupação de aprimorara comunicação e a interação dos usuários com o computador, constituindo-se em elementoessencial e indispensável nos diversos tipos de sistemas computacionais e nas maisdiversas áreas: banco de dados, computação gráfica, inteligência artificial, entre outras.As interfaces visuais estão, aos poucos, sendo usadas em substituição às linguagensde programação tradicionais devido à constante popularização dos recursos gráficos eproporcionarem uma melhor interação do usuário com informações (Silva, 1998).

Visual Query System (VQS), ou sistemas de consulta visuais, são definidos comosistemas para consulta de banco de dados que usam uma representação visual paradescrever o domínio de interesse e expressar consultas relacionadas. Estes sistemastiram vantagem da conhecida largura de banda do campo de visão humana, permitindoo reconhecimento e manuseamento de grandes quantidades de informação assim comoa possibilidade de usar o feedback visual para melhorar o diálogo humano-computador.VQS provêem linguagens para expressar consultas de maneira visual e uma variedadede funcionalidades para facilitar a interação entre o usuário e o sistema. Assim, eles sãoorientados para uma grande variedade de usuários, especialmente usuários que possuemum conhecimento computacional limitado e geralmente ignoram a estrutura interna dabase de dados acessada (Catarci et al., 1997).

6

2.1. INTERFACES VISUAIS

Um VQS é composto de uma, Visual Query Language (VQL), ou linguagem deconsulta visual, para expressão de consultas e algumas funcionalidades para facilitara interação humano-computador (Catarci et al., 1997). A VQL é uma subclasse delinguagens visuais que servem para extração de dados de bancos de dados (Fadhil andHaarslev, 2007). Historicamente, interfaces de banco de dados tem deixado de ser textual(com o uso de SQL, por exemplo) para serem baseadas em formulários, diagramas(Athanasis et al., 2004) e ícones.

VQLs baseiam-se principalmente na idéia de manipular o banco de dados em umavisualização em forma de grafo, selecionando as partes que serão incluídas na consulta(Fadhil and Haarslev, 2007).

Desenvolver uma interface implica em desenvolver um processo de interação com ousuário (Dix et al., 2003). O desenvolvimento de uma boa interface envolve a utilizaçãode técnicas e princípios, que vão desde a elaboração do projeto até análises e testes com osusuários finais. Conforme Dix (Dix et al., 2003), as principais etapas do desenvolvimentode uma interface são: análise de usuários e tarefas, projeto da interação, prototipação etestes (podendo estas etapas estarem envolvidas em um processo cíclico).

Para análise de usuários, Shneiderman (Shneiderman and Plaisant, 2010) recomendaque os projetistas de interfaces levem em consideração os diferentes tipos de personalida-des, isto é, quanto ao nível de conhecimento ou grau de experiência em informática.

Nesta seção, serão abordados os aspectos necessários ao processo de desenvolvimentode uma interface de interação com usuário.

2.1.1 Interação Humano-Computador

A Interação Humano Computador (IHC) pode ser definida como a disciplina envolvidacom o projeto, avaliação e implementação de sistemas computacionais interativos parauso humano e os fenômenos a ele relacionados (Dix et al., 2003).

A IHC envolve três fatores fundamentais: a interface, o homem e o computador. Arelação entre estes termos é conhecida como interação. O termo interface é aplicadonormalmente àquilo que interliga dois sistemas. Tradicionalmente, considera-se que umainterface homem-máquina é a parte de um artefato que permite a um usuário controlare avaliar o funcionamento do mesmo através de dispositivos sensíveis às suas ações ecapazes de estimular sua percepção. No processo de interação, usuário-sistema-interfaceé o combinado de software e hardware necessário para viabilizar e facilitar os processosde comunicação entre o usuário e a aplicação.

A interface entre usuários e sistemas computacionais diferencia-se das interfaces de

7


máquinas convencionais por exigir das pessoas um maior esforço cognitivo em atividadesde interpretação e expressão das informações que o sistema processa (Dix et al., 2003).Norman (Norman, 1994), um dos mais influentes pesquisadores e um dos pioneiros naaplicação de Psicologia e Ciência Cognitiva ao design de interfaces de usuário, enfatizaque a tecnologia deve ser projetada com o objetivo de ajudar as pessoas a serem maisespertas, eficientes e inteligentes. Ele salienta a necessidade da construção de artefatoscognitivos que tornam as pessoas mais espertas.

Para adequar-se a este ponto de vista, o desenvolvimento de sistemas computacionaisinterativos não pode ser considerado apenas dentro do escopo restrito da Ciência daComputação e de fatores humanos (ergonomia). As habilidades dos usuários, a situaçãode uso e o domínio de aplicação onde eles estão envolvidos são fundamentais paraa usabilidade e devem ser considerados no desenvolvimento de sistemas interativos,pois, de acordo com Dix (Dix et al., 2003), sistemas concebidos sem os conhecimentosnecessários das áreas envolvidas acabam fazendo uso da capacidade de adaptação do serhumano para compensar deficiências.

Princípios, diretrizes, regras e padrões são utilizados por especialistas e centros deestudos como instrumento de apoio ao projeto de interfaces de maneira a auxiliar osprojetistas. Tais instrumentos têm sido fundamentais a muitos projetistas, principalmentedevido à proliferação dos computadores pessoais e à diversidade de usuários, exigindoassim uma atenção maior às interfaces e contribuindo para o surgimento de Graphical

User Interface (GUI) e novos estilos de interação (Dix et al., 2003). Como exemplos deestilos de interação pode-se citar: menus, preenchimento de formulários, manipulaçãodireta, linguagem natural, Windows, Icons, Menus e Pointers (WIMP) e What you see is

what you get (WYSIWYG).

2.1.2 Projeto de Interface

O projeto de uma boa interface não consiste no uso abundante de recursos gráficos como objetivo de tornar a interface mais bonita. É necessário utilizar estes recursos comconhecimento de causa de modo que a interface se torne um meio de comunicação efetivopara um maior número de pessoas.

Segundo Foley (Foley et al., 1995), as principais metas de um projeto de interfacecompreendem: aumento da velocidade de aprendizado; aumento da velocidade de uso;redução na taxa de erros; facilidade de uma rápida revisão de como utilizar a interfacee aumento da atratividade para potenciais usuários, sendo estes os fatores cruciais dausabilidade.

8


Dix (Dix et al., 2003) afirma que, independente do padrão de interface ou plataformaque serão escolhidos, é preciso planejar a interface, pois é na fase do projeto que sãodefinidos o comportamento e a apresentação da mesma. A execução de um projetoenvolve: tipos de diálogo ou interação; análise do usuário e das tarefas; fatores humanos;dispositivos de entrada e saída; princípios, padrões, regras e diretivas; protótipos eavaliação de sistemas existentes. O resultado do projeto é a especificação do mesmo,geralmente através de especificações formais, protótipos ou ainda documentos informais.

2.1.2.1 Projeto de Interação

Segundo Dix (Dix et al., 2003) interação é qualquer comunicação entre o usuário e ocomputador, seja direta ou indireta. Interação direta é aquela em que há diálogo, retorno(feedback) e controle das operações realizadas. A indireta, por sua vez, envolve dois pos-síveis tipos de processamento: de fundo ou em lotes. Em ambas, o que realmente importaé a interação entre o usuário e o computador, em busca da solução para alguma tarefaespecífica. Cabe ao designer de interação a definição de como será a comunicação dainterface com o usuário. Isso não implica em somente preocupar-se com os componentesdas interações, mas essencialmente com a forma pela qual tais componentes orientam asações dos usuários (Dix et al., 2003).

Essencialmente, o processo de projeto da interação é composto por quatro atividadesbásicas: Identificação das necessidades dos usuários, desenvolvimento de alternativas deprojeto, construção de versões iterativas e avaliação do projeto. É importante destacarque essas atividades estão inter-relacionadas fornecendo informações umas às outras,podendo ser inclusive repetidas.

O projeto da interação considera ainda três aspectos chaves do processo: foco nousuário, definição de metas de usabilidade e iteração. O foco no usuário é central noprocesso de projeto, de modo que o processo encoraja este foco e provê oportunidadespara a participação do usuário dentro do processo. Os critérios de usabilidade devemser identificados, concordados e documentados no início do projeto e são especialmenteimportantes no momento da escolha das alternativas de projeto. Por último, iteraçãodeve estar sempre presente e é por meio dela que se permite o refinamento baseado emresultados de avaliações de versões intermediárias.

2.1.2.2 Processo de Projeto de Interação

O processo de projeto é composto por quatro fases principais mais um ciclo de iteração: (1)identificação das necessidades dos usuários; (2) análise das necessidades dos usuários; (3)

9


desenvolvimento de alternativas de projeto e construção de versões iterativas(protótipo);e (4) implementação do projeto. Estas fases proporcionam um ciclo metodológico ondeatividades reconhecidamente importantes para a pesquisa de IHC podem ser adicionadas(Dix et al., 2003). A Figura 2.1 apresenta as principais fases deste processo.

Figura 2.1: Processo de Projeto de Interação. Adaptado de (Dix et al., 2003)

Muitos métodos de projeto de interface foram definidos e, em geral, partem dacaptura e análise do perfil do usuário e de suas tarefas, análise dos objetivos da interface,definição do projeto das telas, da navegação e teste da interface prototipada. Em muitosaspectos estes métodos possuem similaridade; apresentam diferentes números de fases;são genéricos, por isso algumas ferramentas têm sido implementadas para dar suporte aoprocesso de desenvolvimento; e, na maioria das vezes, não expõem de fato como ocorre aconcepção dos componentes gráficos, dos aspectos estéticos e semiológicos da interface.Também, não prevêem em que momento do processo o desenvolvedor de interface Webirá aplicar os requisitos estabelecidos pelos padrões Web.

O processo de interação tem uma estrutura flexível, portanto, o ciclo metodológicopode ser adaptado a cenários diversos. Assim, foram inseridas atividades específicas como objetivo de aumentar a qualidade do resultado do processo que é composto por quatrofases. A seguir, cada fase do processo é descrita em conjunto com as atividades propostasa cada fase.

Fase 1 - Identificação das Necessidades dos UsuáriosA principal motivação para o estudo do usuário está no fato de que diferentes usuários

têm diferentes necessidades e produtos interativos devem ser projetados de acordo comesses desejos e expectativas. Isso exige uma compreensão de quem é o público-alvo doproduto ou sistema que está sendo projetado e que tipo de suporte o usuário necessita.

10


Nesta fase do processo as atividades se iniciam com a identificação dos objetivos seguidada definição do público-alvo, da definição das técnicas que serão empregadas e dodesenvolvimento dos instrumentos de coleta necessários para uso com a técnica escolhida.Dentre as técnicas usadas para isso em IHC, pode-se destacar: entrevista, gravação eobservação dos usuários (etnografia).

A coleta de dados tem por objetivo a busca de informações suficientes e relevantespara a definição de um conjunto estável de requisitos. Para que informações comoquais as tarefas dos usuários, quais seus objetivos em executá-las, qual o contexto emque estas atividades são executadas, quais as dificuldades em realizá-las, entre outrasinformações sejam obtidas, é importante o conhecimento de técnicas de coleta de dados esua aplicabilidade. A definição dos cenários de interação pode ser feita em conjunto comum método de análise de tarefas, por exemplo.

Existem várias técnicas e a escolha depende do tipo de informação que se desejaobter, dos recursos disponíveis, da acessibilidade dos stakeholders a serem considerados,entre outras razões (Prates and Barbosa, 2003).

Fase 2 - AnáliseEnquanto a fase anterior está mais preocupada com o tema, quais os usuários cujas

necessidades serão estudadas e com a escolha das técnicas, a fase de análise está maisfocada em executar o estudo e analisar os dados. Assim, os resultados das observaçõese entrevistas precisam ser ordenados de forma a trazer para fora questões essenciais aodesenvolvimento do projeto. Uma vez que a coleta dos dados tenha sido encerrada, teminício a análise dos dados obtidos. O objetivo é iniciar a estruturação e o registro dos re-quisitos (Pires, 2009). Várias técnicas podem ser utilizadas, cada uma contribuindo maisenfaticamente em investigar aspectos diferentes dos dados. Softwares também podem serutilizados para análise dos dados. O seu uso amplia significativamente o conjunto finalde categorias que podem ser identificadas pelos pesquisadores. Um exemplo de softwareutilizado para análise dos dados de entrevistas é o NUDIST (NUDIST, 2011).

Fase 3 - ProjetoUma vez que as principais necessidades dos usuários tenham sido identificadas,

iniciam as atividades de projeto. O principal objetivo é a busca por ideias que atendam àsnecessidades identificadas na fase anterior.

Esta fase pode ainda ser dividida em duas outras sub-atividades que são: projetoconceitual, que envolve a criação do modelo do produto; e projeto físico, que envolve os

11

2.2. P2P

detalhes do produto, tais como telas e menus.Com a obtenção dos resultados da coleta e a análise dos dados da etapa anterior, são

usadas técnicas de projeto que possibilitem a criação de versões que permitam a interaçãodo usuário. Em especial, técnicas de prototipagem rápida e de baixa fidelidade permitemavaliar as melhores soluções mesmo antes de o sistema começar a ser implementado.Quanto mais protótipos e iterações, maiores as chances do produto final ser adequado aopúblico ao qual ele se destina.

Prototipagem: Para a concepção do produto que atenda aos requisitos estabelecidos,faz-se uso intensivo de prototipação. Os protótipos podem ser baseados em papéis atémodelos mais próximos ao produto final. Protótipos permitem que os usuários interajamcom um modelo de menor fidelidade que o produto final e possam expor suas primeiraspercepções sobre o que está sendo desenvolvido.

A avaliação do protótipo compreende a preparação, aplicação e análise de testes deusabilidade a serem realizados em diferentes versões dos protótipos em desenvolvimento.Estes testes permitem verificar se o produto atende a um conjunto de critérios de usabili-dade e experiência anteriormente estabelecida do usuário na fase de análise. Por ser umprocesso iterativo, os protótipos evoluem nas atividades de projeto e avaliação num cicloiterativo de projeto-prototipagem-avaliação e projeto novamente. Para a realização dessestestes, avaliações heurísticas podem ser utilizadas (Dix et al., 2003).

Fase 4 - Implementar e ImplantarNesta última fase, quando se está satisfeito com o projeto, é necessário implementar

o produto. Isto envolve a codificação do mesmo. Uma vez codificado, pode-se executartestes de usabilidade e experimentações do produto implementado.

Geralmente esta fase envolve também a criação de documentação, manual e ajuda dosistema.

2.2 P2P

O termo peer-to-peer (par-a-par) se refere a uma variedade de sistemas e aplicaçõesque empregam recursos de maneira distribuída para realizarem suas atividades de formadescentralizada (Milojicic et al., 2003). Em uma rede P2P, as unidades de processamentonão possuem um papel fixo para comunicação com outras máquinas, podendo agir tanto

12

2.2. P2P

como um cliente quanto como um servidor.A organização de uma rede P2P é descentralizada, ou seja, não existe um gerenci-

amento central. Por isso, quando há a transmissão de dados entre dois pontos da rede,a informação costuma passar por vários pontos da rede desde a origem até alcançar odestino pretendido.

As aplicações peer-to-peer possuem características importantes como escalabilidade,volatilidade, autonomia dos pontos, roteamento, entre outras.

As redes P2P foram categorizadas em diferentes topologias de acordo com as diferen-tes organizações e papéis de cada ponto na rede. As principais topologias serão descritasnas seções seguintes.

2.2.1 Topologia P2P Pura

Em uma topologia P2P pura não existe centralização no processamento, todos os peers

exercem as mesmas funções na rede, não existindo hierarquia entre os pontos da rede. AFigura 2.2 ilustra a topologia P2P pura.

Figura 2.2: Topologia P2P Pura. (Fiorano, 2011)

Como dito anteriormente, a informação, ao trafegar por uma rede P2P pura, passapor outros pontos até chegar ao destino pretendido. Os outros pontos apenas repassam a

13

2.2. P2P

informação, quando esta não é direcionada a eles. Uma virtude da topologia P2P puraé a escalabilidade, já que qualquer ponto pode se juntar a uma rede P2P e começar atrocar informações com outros pontos. Essas redes também são tolerantes a falhas, poisse algum peer em particular da rede falha, não ha impacto para o restante do sistema(Fiorano, 2011).

2.2.2 Topologia P2P Híbrida

Na topologia P2P híbrida há a presença de um ou mais servidores centrais para controleda troca de informações mas o fluxo de dados ocorre da mesma maneira que na topologiaP2P pura. A presença do servidor ameniza o problema de falta de gerenciamento, presentena topologia P2P pura. O papel principal do servidor é o monitoramento dos outros pontosda rede, garantindo a coerência na informação trocada por eles (Fiorano, 2011). A Figura2.3 ilustra a topologia P2P híbrida.

Figura 2.3: Topologia P2P Híbrida. (Fiorano, 2011)

Neste tipo de topologia pode ocorrer o mesmo problema que ocorre em um sistemacentralizado; caso o sistema central sofra algum tipo de falha, a rede perde a habilidadede gerenciamento e controle da troca de informações. Com o fluxo de informaçõescentralizado este tipo de topologia não é indicado para sistemas que necessitam de umaalta escalabilidade.

14

2.2. P2P

2.2.3 Topologia P2P Super-Peer

Na topologia super-peer, como mostra a Figura 2.4, a arquitetura é composta de umamistura entre a abordagem centralizada, com existência de gerenciamento, e a abordagemdescentralizada, na busca e troca de dados entre os pontos.

Figura 2.4: Topologia P2P Super-Peer. (Fiorano, 2011)

Alguns pontos podem assumir papéis distintos na rede. Nesta topologia os peers demaior capacidade computacional podem ser eleitos para coordenar um subconjunto depontos da rede. Esse ponto é chamado de super-peer (Fiorano, 2011).

Em (Fiorano, 2011), são listadas uma série de vantagens sobre a topologia P2P super-

peer. A busca nesse tipo de topologia é muito rápida em comparação a outras arquiteturas,já que o sistema possui seu espaço de busca particionado em um conjunto menor de peers

coordenados por super-peers, os quais possuem a informação de seus peers indexada.Essa arquitetura define várias unidades autônomas colaborando entre si. Cada con-

junto de pontos sob o mesmo super-peer (também chamado de cluster do super-peer)corresponde a uma unidade autônoma, no sentido de não haver dependência de umservidor central para a troca de informações.

15

2.3. PEER DATA MANAGEMEN SYSTEM (PDMS)

Os super-peers mais confiáveis e com maior poder de processamento monitorama atividade de seus clusters. Isso garante um controle contra atividades maliciosas narede. Nesta topologia, há também um melhor balanceamento das responsabilidadesdependendo da capacidade do peer, o que previne uma queda de desempenho graças auma fragmentação da rede no caso de todos os peers possuírem a mesma responsabilidadee muita carga ficar sobre um peer com pouca capacidade de processamento.

O Quadro 2.1 apresenta uma comparação entre as topologias discutidas, incluindotambém a comparação com sistemas centralizados (estilo cliente-servidor), com relação agerenciamento, coerência da informação, escalabilidade e confiabilidade.

Quadro 2.1: Comparação entre as topologias P2P. Adaptado de (Fiorano, 2011)

Topologia Gerenciável Coerente Escalável ConfiávelCentralizada Sim Sim Não Não

Descentralizada Não Não Sim SimP2P Hibrida Sim Sim Sim NãoSuper Ponto Sim Sim Sim Sim

2.3 Peer Data Managemen System (PDMS)

PDMS é uma aplicação peer-to-peer que tem como elementos constituintes peers dedados autônomos que podem compartilhar seus esquemas de dados entre si de forma totalou parcial (Blanco et al., 2006).

Os sistemas PDMS podem ser definidos também como sistemas de gerenciamentopeer-to-peer que provêem um ambiente de integração de dados, sendo estes armazenadosem fontes autônomas, heterogêneas e dinâmicas (Blanco et al., 2006).

A forma de compartilhamento de dados entre os peers em um PDMS é feita pelaexportação de seus esquemas. Um PDMS possui as seguintes características:

• Compartilhamento descentralizado dos dados;

• Escalabilidade; e

• Processamento e armazenamento de dados distribuídos em peers autônomos, quetambém armazenam os mapeamentos semânticos dos dados.

A organização descentralizada é importante para que o PDMS não fique inviabilizadocaso algum ponto em particular venha a falhar. Os pontos em um PDMS são considerados

16

2.3. PEER DATA MANAGEMEN SYSTEM (PDMS)

autônomos devido à sua liberdade de entrada ou saída de uma rede, ou até mesmo sobrepossíveis alterações em seus esquemas de dados.

Em um PDMS, um dos serviços mais importantes é o processamento de consultas.Quando uma consulta é submetida em um ponto, o sistema consegue obter dados rele-vantes não só do ponto que recebeu a consulta, mas de qualquer outro ponto que estejaconectado à rede por meio de caminhos semânticos (Tatarinov and Halevy, 2004).

Uma grande vantagem dos sistemas PDMS é a de que qualquer ponto pode submeteruma consulta na rede utilizando apenas seu próprio esquema de dados, sem precisarconhecer os esquemas de outros pontos. Com isso, a consulta original pode ser reformu-lada (adequada) aos outros pontos da rede por meio dos caminhos semânticos existentes,sendo estes definidos de acordo com os esquemas de dados dos pontos.

Por exemplo, se uma consulta Q é submetida em um peer A, o PDMS geralmenteretorna primeiro um resultado baseando-se nos dados de A (pode ocorrer também deo PDMS integrar todos os resultados e retorná-los de uma só vez). Tento feito isso,a consulta Q é reformulada para os vizinhos semânticos de A e outros resultados sãoretornados baseados em outros esquemas de dados. Isso contribui para se obter umresultado mais completo para a consulta submetida.

A escolha do caminho semântico a ser seguido é muito importante pois, dependendodo caminho semântico seguido pela consulta, novas respostas podem ser obtidas. Issopode resultar em alguns problemas. Alguns desses problemas são citados em (Tatarinovand Halevy, 2004):

• Surgimento de respostas redundantes. Cada reformulação desnecessária degrada odesempenho do sistema;

• Um caminho que encontre um final muito cedo, passando por poucos pontos, ouseja, podado precocemente; e

• Reformulações ineficientes, ou seja, consultas em pontos que poderiam ser melhoraproveitadas (otimizadas, ou enriquecidas) antes de serem executadas.

Os pontos de um PDMS não possuem todas as informações sobre um domínio.Por isso, escolher um bom caminho semântico quando uma consulta é submetida é degrande importância, a fim de se extrair o maior número de informações que possam serencontradas na rede.

Os PDMS se tornaram grande fonte de pesquisa por serem uma extensão às bases dedados distribuídas no contexto peer-to-peer (Pires, 2009). Devido à grande variedade

17

2.4. ONTOLOGIA

na representação de dados e na semântica dos peers, um modelo de PDMS baseado emontologias foi sugerido (Xiao, 2006). Xiao (Xiao, 2006) introduziu uma nova definiçãopara este novo modelo, que possui o intuito de oferecer uma representação de dados emuma notação mais uniforme. Esse tipo de sistema é conhecido como Ontology-based

Peer Data Management System (OPDMS).

2.4 Ontologia

Muitas definições de ontologia são encontradas na literatura no âmbito da inteligênciaartificial. Uma das definições diz que ontologia é uma descrição formal explícita deconceitos em um domínio do discurso, de propriedades de cada conceito descrevendoatributos ou características, e de restrições dessas propriedades (Noy and Mcguinness,2002). É conhecido também que uma ontologia juntamente com definições de instânciasde suas classes formam uma base de conhecimento (Guarino, 1998).

As classes são as entidades principais de uma ontologia. Uma ontologia pode re-presentar um domínio de aplicação, e várias classes podem ser apresentadas com seusatributos, limitações, características e relacionamentos com outras classes do domínio,como por exemplo, o relacionamento de subclasse e superclasse, muito comuns nasontologias.

Ontologias são muito comuns na Web, servindo para uma diversidade de propósitos,desde a descrição de sites como de um simples produto comercial. As ontologias definemum vocabulário comum e estruturado para a troca de informações de um domínio entrepesquisadores. Algumas das principais razões para o desenvolvimento de uma ontologiasão (Noy and Mcguinness, 2002):

• Compartilhar um conhecimento comum entre pessoas ou agentes de software;

• Permitir o reuso do conhecimento de um domínio;

• Melhorar a análise do conhecimento de um domínio; e

• Separar o conhecimento do domínio do conhecimento operacional.

A fim de oferecer uma padronização na representação desse conhecimento da Web,duas linguagens (arquiteturas) surgiram nesse contexto: Resource Description Fra-

mework (RDF) e Web Ontology Language (OWL), ambas recomendações da World

Wide Web Consortium (W3C) (McGuinness and van Harmelen, 2004), que serão maisbem explicadas nas próximas subseções.

18

2.4. ONTOLOGIA

2.4.1 Resource Description Framework (RDF)

A Web provê acesso sem precedentes à informação. Metadados (campos descritivos dealgum tipo de informação) aumentam o acesso a essa informação, e o RDF surge comoum padrão da W3C proposto para definir a arquitetura necessária para dar suporte aosmetadados da Web (Miller, 1998).

RDF é uma linguagem para representar informação na Internet. Essa linguagempermite aos computadores representar e compartilhar dados semânticos na Web (W3C,2004).

A RDF possui um modelo padrão para descrever recursos da Web. Um recurso, paraRDF, é um objeto, que possui propriedades. Tais propriedades possuem tipos (numéricos,caracteres,...), e valores possíveis. Os valores de uma propriedade podem ser atômicos ououtros recursos.

A RDF em si é uma linguagem simples que é capaz de fazer relacionamentos entreinformações, mas, além disso, é necessário um meio para definição de dados. A RDFSchema (Brickley and Guha, 2000) foi criada, também pela W3C, com essa finalidade.

A RDF Schema (Brickley and Guha, 2000) é responsável por prover mecanismos paradeclaração de propriedades dos recursos e também definir os tipos de recursos que estãosendo descritos. Pode ser entendido como uma espécie de dicionário onde são definidosos termos que serão utilizados em declarações RDF. A especificação da RDF Schema daW3C fornece os mecanismos necessários à definição de elementos, de classes de recursos,de posséveis restrições de classes e relacionamentos e detecção de violação de restrições.

2.4.2 Web Ontology Language (OWL)

OWL é uma linguagem para definição e instanciação de ontologias na Web. É viávelutilizar OWL quando a informação contida nos documentos precisa ser processada poralguma aplicação, ao contrário do que ocorre quando a informação apenas necessita serapresentada ao usuário (McGuinness and van Harmelen, 2004), sem nenhum tipo deprocessamento.

A OWL é considerada uma extensão de RDF. Sendo assim, também pode incluirdescrições de classes, suas respectivas propriedades e relacionamentos. Assim comoRDF, OWL é uma recomendação da W3C, mas possui um maior poder de interpretaçãoe mais recursos para modelar o conteúdo da Web do que RDF ou Extensible Markup

Language (XML) (Thompson, 1997), pois a OWL possui um vocabulário mais amplo euma semântica mais bem definida.

19

2.5. LÓGICA DESCRITIVA (DL)

A linguagem OWL é mencionada como uma tecnologia importante para a futuraimplementação da Web semântica (Shadbolt et al., 2006). Esta possui um vocabuláriomais amplo para expressar propriedades e relacionamentos, como o de cardinalidade,enumerações, entre outros. A OWL possui três sublinguagens expressivas direcionadas acomunidades específicas (W3C, 2004):

• OWL Lite - Dá suporte a usuários que necessitam de uma classificação hierárquicae restrições simples. Por exemplo, embora suporte restrições de cardinalidade, elasó permite valores de cardinalidade 0 ou 1. É mais simples fornecer ferramentasque dão suporte a OWLLite

• OWL Description Logic (DL) - Dá suporte a usuários que querem a máximaexpressividade, enquanto mantém a computabilidade e decidibilidade. OWL DLpossui todas as construções da linguagem OWL, porém elas somente podem serusadas com algumas restrições. Possui esse nome devido à sua correspondênciacom as lógicas de descrição; e

• OWL Full - Direcionada aos usuários que querem máxima expressividade e liber-dade sintática sem nenhuma garantia computacional. A OWL Full permite queuma ontologia aumente o vocabulário pré-definido de RDF ou OWL.

2.5 Lógica Descritiva (DL)

A lógica descritiva (ou DL, do inglês Description Logic) é um conjunto de linguagens derepresentação de conhecimento de aplicações, que enfatiza o domínio de uma aplicaçãode uma maneira formal e estruturada, e que é bem compreendido (Baader et al., 2003).

A DL consegue explicitar e detalhar diversos domínios de aplicações graças ao seupoder de descrição de entidades por meio de operadores bem definidos e quantificadores,e também graças às regras de formação dessas descrições de algum objeto ou situaçãoem particular. Além disso, a DL possui toda uma carga semântica apoiada na lógicamatemática.

Os construtores Attribute Language with Complement (ALC) são: (1) ¬C (negação);(2) CuD (conjunção); (3) CtD (disjunção); (4) ∀R.C (restrição universal); e (5) ∃R.C(restrição existencial limitada), onde C e D são conceitos e R é uma propriedade. Nessesentido, considera-se uma ontologia como uma tripla O = {C,R, I} , onde C é umconjunto de conceitos, R é um conjunto de propriedades e I é um conjunto de indivíduos(instâncias).

20

2.6. SPARQL PROTOCOL AND RDF QUERY LANGUAGE

Uma consulta formulada utilizando a DL é uma expressão Q =C, onde C é um con-ceito. Esse conceito pode ser atômico ou complexo (inclui propriedades, quantificadores,conjunções ou disjunções) (Souza, 2009).

Um exemplo de consulta formulada em DL é: Q1 = [Teacher u Researcher] t[Student uResearcher], que procura por indivíduos que são professores e pesquisadoresou estudantes que também são pesquisadores.

2.6 SPARQL Protocol and RDF Query Language

SPARQL é uma linguagem de consulta para documentos RDF, mas que também fazbuscas em estruturas de arquivos OWL, ou seja, busca em ontologias em geral. Épadronizada pela RDF Data Access Working Group (DAWG) da W3C (Prud’hommeauxand Seaborne, 2008).

As consultas em SPARQL consistem de um padrão triplo (triple patterns): conjunções,disjunções e padrões opcionais de complementação. Essa idéia de tripla se baseianas estruturas de grafo do RDF. SPARQL foi desenvolvida a partir de linguagens deconsulta em RDF anteriores, como RDF Data Query Language (RDQL) (Seaborne,2004) e Sesame RDF Query Language (SeRQL) (Broekstra and Kampman, 2004), e suaimplementação é compatível com uma série de plataformas.

Além da possibilidade de consulta de dados, SPARQL também oferece a capacidadede extração de informações de repositórios a partir de regras de elaboração do usuário,com o auxílio dos construtores reservados de SPARQL: Construct, Ask, e Describe.Um ambiente comum para a prática de consultas SPARQL é o Jena (Jena, 2011) com oauxílio do ARQ (ARQ, 2011), um motor de consulta que trabalha com o Jena.

O Figura 2.5 apresenta um exemplo de consulta em SPARQL, que deseja recuperarde uma ontologia todos os identificadores (ID) de professores.

Detalhando mais essa consulta a respeito da sintaxe da linguagem, tem-se os seguintesitens:

• Prefixos - no início há a declaração de prefixos com a palavra reservada prefix, queassocia uma sigla com um Uniform Resource Identifier (URI) específico. Umaconsulta pode incluir qualquer quantidade de prefixos desejada;

• Select - palavra reservada que define os itens que serão retornados pela consulta (asvariáveis em SPARQL são precedidas de “?” ou “$”);

• From - identifica a ontologia na qual a consulta irá executar;

21

2.7. CONSIDERAÇÕES

Figura 2.5: Exemplo de Consulta SPARQL.

• Where - indica as condições para o retorno do resultado. Neste caso, como expli-cado, pode-se observar o padrão de triplas do SPARQL. A tripla pode ser entendidacomo uma construção de sujeito, predicado e objeto;

• ?x - a variável “x” é ligada a conceitos do tipo “Teacher” na ontologia;

• Operador ponto - o operador “.” indica uma concatenação de restrições. A segundarestrição indica que, dado que “x” contém um professor, seu ID deve ser atribuídoà variável ID (?ID, que é a variável de retorno da consulta).

2.7 Considerações

Neste capítulo foram abordados os principais conceitos envolvidos na concepção eimplementação de interfaces de interação com o usuário. Também foram descritos osconceitos e características de sistemas P2P, PDMS e ontologias inerentes ao escopo destetrabalho. No próximo capítulo serão apresentados alguns tipos de interfaces propostaspara PDMS abordando, principalmente, interfaces que fazem uso de ontologias nainteração do usuário para formulação de consultas.

22

3Interfaces e PDMS

Neste capítulo serão descritos os tipos de interface utilizados em PDMS bem como asabordagens existentes para estes tipos de interface.

3.1 Interfaces Baseadas em Ontologia

Visando classificar as abordagens existentes para consulta baseada ontologias, Hoang(Hoang and Tjoa, 2006) identificou alguns critérios, bem como algumas metodologias,com base em semelhança de objetivos de pesquisa. Dentre estes critérios encontram-se aformulação de consultas e a interação do usuário.

3.1.1 Formulação de Consultas

Muitos tipos de consultas complexas podem ser formuladas como um problema deencontrar um grupo de objetos de determinados tipos que são ligados por certas relações.Isto se traduz em padrões gráficos, mas, embora tais padrões sejam fáceis para formalizara consulta no contexto semântico, elas permanecem problemáticas porque não são fáceisde formular para os usuários (Hoang and Tjoa, 2006).

Visando auxiliar o usuário na formulação de consultas, Athanasis (Athanasis et al.,2004) e Franconi (Franconi et al., 2010) propõem uma interface gráfica de usuário queapresenta um padrão para construção da consulta baseada em navegação pela ontologia,onde o usuário parte da seleção de uma classe e, por meio de navegação, pode especificaros artefatos para consulta entre as propriedades aplicáveis para a classe selecionada.

Outro padrão que tem se mostrado como um poderoso paradigma de busca é o baseadoem visões múltiplas (Makela et al., 2004) combinado com o uso de ontologias (Hyvonenand Viljanen, 2003). Nesta abordagem muitas visões distintas são previstas para os

23

3.1. INTERFACES BASEADAS EM ONTOLOGIA

dados. Essas visões são criadas por projeção de ontologias usando também vários outrosrelacionamentos hierárquicos inerentes à ontologia.

A busca por palavra-chave com uso de ontologias também aparece entre as aborda-gens para formulação de consultas baseadas em ontologias. Muitas implementações deexpansão e consultas fazem uso de thesaurus como um passo em expansão de consultascomo o apresentado por Buscaldi (Buscaldi et al., 2007). Uma dessas técnicas bem co-nhecida é o uso do WordNet (Fellbaum, 1998). Esse tipo de sistema funciona em processobásico onde: primeiro as palavras-chave são localizadas na ontologia, então, vários outrosconceitos são localizados depois que os termos relacionados a estes conceitos são usadospara ampliar ou restringir a busca.

As abordagens que fazem uso exclusivamente de palavras-chave não serão analisadasneste trabalho por consistirem, geralmente, em recuperação de texto, onde o objetivo éencontrar conceitos relacionados em uma coleção de documentos, mas serão tratadasabordagens que combinam o uso de palavras-chave com a busca baseada em visões.

3.1.2 Interação do Usuário

As abordagens encontradas para interação do usuário em consultas baseadas em ontologiaapresentam a interação do usuário no processo de refinamento de consultas. Stojanovic(Stojanovic et al., 2004) apresenta uma abordagem para refinamento de consultas baseadasem ontologias que é fundamentada na interação do usuário durante o incremento eadaptação de uma consulta de acordo com as necessidades do usuário. Estas necessidadessão implícitas e provocadas durante o processo de pesquisa pela análise do comportamentodo usuário. O intervalo entre a necessidade do usuário e sua consulta é quantificado pelamedição de vários tipos de ambiguidades de consulta. Consequentemente, no processo derefinamento o usuário recebe uma lista ordenada de refinamentos sugeridos pelo sistema,que deverão diminuir as ambiguidades.

Além dos refinamentos sugeridos pelo sistema, a abordagem permite ao usuário, pormeio de uma exploração mais profunda da ontologia, a detecção de resultados semelhantesque devem ajudar o usuário a satisfazer a sua necessidade.

24

3.2. INTERFACES DE PEER DATA MANAGEMENT SYSTEMS - PDMS

3.2 Interfaces de Peer Data Management Systems - PDMS

Um PDMS, de uma maneira geral, consiste em um conjunto de peers, cada um atuandocomo um componente de integração de informação. Consultas submetidas num peer sãorespondidas tanto com dados locais como com dados de outros peers da rede em que estese encontra. Esses outros peers são alcançados por meio de caminhos e mapeamentosdefinidos entre os peers na rede.

Diversos autores (Adjiman et al., 2007; Castano et al., 2003; Mandreoli et al., 2008;Montanelli and Castano, 2008) apresentam abordagens para o processamento de consultasbaseadas em ontologias para PDMS . Dentre os que trazem proposta de interfaces deusuário na formulação e submissão de consultas foi possível estabelecer uma classificaçãobaseada na metodologia ou técnica utilizada para formulação de consultas. Para estaclassificação temos: interfaces de consulta baseadas em navegação; interfaces de consultabaseadas em múltiplas visões e interfaces de consulta baseadas em palavras-chave. Den-tre estas, serão consideradas as abordagens para formulação de consultas baseadas emnavegação e múltiplas visões, onde esta última combina o uso de palavras-chave em suatécnica. Além destas abordagens baseadas em ontologias, serão abordadas também umoutro tipo de interface que permite ao usuário explorar o caminho mais promissor para oroteamento de consultas na rede.

3.2.1 Interfaces de Consulta Baseadas em Navegação

Como dito anteriormente, algumas abordagens (Athanasis et al., 2004; Franconi et al.,2010; Beneventano et al., 2007) propõem interfaces gráficas de usuário que apresentamum padrão para construção da consulta baseada em navegação pela ontologia, onde ousuário parte da seleção de uma classe e, por meio de navegação, pode especificar osartefatos para consulta entre as propriedades aplicáveis para a classe selecionada. Nestaseção, serão descritas algumas abordagens que propõem este tipo de interface de usuário.

Query Tool(Franconi et al., 2010)Franconi (Franconi et al., 2010) propõe um framework formal juntamente com um

software para formulação de consultas precisas capturando da melhor maneira as informa-ções que o usuário necessite, de modo que o seu uso pode ser feito sem o conhecimento

25


sobre os sistemas que mantêm os dados. A interface de consulta utiliza técnicas debusca automática através do uso de linguagens naturais sobre ontologias que descrevem odomínio dos dados. A implementação do framework é chamada Query Tool que consisteem três componentes baseados numa arquitetura Web cliente-servidor:

• Query Logic (QueLo) - Módulo responsável por implementar a lógica das consultassobre as ontologias para o fornecimento apenas de informações relevantes;

• Natural Language Generation (NLG) - A função deste módulo é fazer um mapea-mento de uma consulta com ontologias para uma sentença em linguagem natural(inglês); e

• User Interface (UI) - A interface de consulta fornece um acesso visual para realiza-ção de buscas permitindo a interação entre os módulos QueLo e NLG.

Figura 3.1: Protótipo da interface de consulta da Query Tool (Franconi et al., 2010)

A Query Tool pode ser utilizada por usuários que não possuem conhecimento sobre aorganização dos dados ou do vocabulário utilizado na ontologia. Em um cenário ondeexiste um modelo conceitual descrito por uma ontologia e não se sabe nada sobre odomínio dos dados, a Query Tool é utilizada para mostrar particularidades que permitemdescobrir informações sobre a ontologia e o domínio modelado. Inicialmente o usuáriopode fazer uma busca em nível bem abstrato e a Query Tool fornece operações que pode-rão ser utilizadas para a manipulação da consulta, sendo: add para adicionar novos termose relações; substitute para alterar parte da consulta com informações mais específicas ougerais; delete para excluir partes da consulta; e weaken para tornar parte da consulta omais geral possível. O protótipo da interface de consulta proposta é mostrado na Figura

26


3.1.

Graphical RQL (GRQL) (Athanasis et al., 2004)Athanasis (Athanasis et al., 2004) apresenta uma abordagem para interface gráfica

de consulta expressa em RDF Query Language (RQL), uma linguagem de consultadeclarativa para RDF, e formulada por navegação. Essa interface recebe o nome deGRQL. Nessa abordagem, primeiramente uma classe na ontologia é selecionada comoponto inicial. Todas as propriedades definidas como aplicáveis à classe na ontologiasão então dadas por expansão. Clicando em uma propriedade expande-se o grafo paraconter aquela propriedade e move-se a seleção para o intervalo de classe definido poraquela propriedade. Por exemplo, na Figura 3.2, clicando em “creates property” na classeArtist cria o padrão “Artist→ creates→ Artifact”, e move o foco para a classe Artist,mostrando as propriedades para aquela classe para futuro caminho de expansão.

Além de alongar o caminho, outras operações podem ser realizadas nesse padrão deconsulta. Este pode, por exemplo, ser mais rigoroso com relação a algumas subclassesde uma classe, como o artefato “Painting or Sculptures” no exemplo visto anteriormentepara “Artist→ creates→ Painting or Sculpture”. Da mesma maneira, as definições derestrições da propriedade podem ser mais rigorosas em subpropriedades. Consultas maiscomplexas podem ser formuladas visitando um nó criado anteriormente e ramificaçõesda expressão, criando padrões como o representado na Figura 3.2.

Figura 3.2: Navegando para criação de um padrão de consulta do GRQL (Athanasis et al.,2004)

SEWASIE (Beneventano et al., 2007)Beneventano (Beneventano et al., 2007) apresenta o SEmantic Web and AgentS in

Integrated Economies (SEWASIE), um sistema que implementa um mecanismo de buscaavançado que permite o acesso inteligente a fontes de dados heterogêneas na Web viaenriquecimento semântico.

27


SEWASIE fornece aos usuários um cliente de busca que tem uma interface de consulta,e que podem extrair as informações necessárias a partir da Internet e mostrá-las em umformato útil e amigável. Do ponto de vista arquitetural, o protótipo do sistema forneceráum motor de busca e servidores de indexação e ontologias (SEWASIE, 2011).

O projeto SEWASIE é baseado na tecnologia de sistema multi-agentes. Sua arquite-tura provê duas camadas: uma de nível local, onde os peers (desenvolvidos como agentesmediadores) mantêm uma visão integrada de suas fontes locais; outra, no nível de rede,onde agentes (brokering agents) mantêm os mapeamentos entre os diferentes peers. Aarquitetura do SEWASIE é definida da seguinte forma (SEWASIE, 2011):

• SEWASIE Information Node (SINode) - são sistemas baseados em mediadoresque fornecem uma visão virtual das fontes de informação. Os SINodes utilizamtradutores (wrapper) para extrair dados e metadados das fontes. Um construtor deontologias (Ontology Builder) é utilizado para criar uma ontologia integrada detodos os esquemas das fontes, denominado Global Virtual View (GVV)(visão virtualgobal). Essas ontologias serão futuramente integradas ao Brokering Agent(BA)para estabelecer uma ligação entre os SINodes e a interface do usuário;

• Brokering Agents (BA) - responsável por integrar as GVV de diferentes SINodesem uma ontologia Brokering Agent Ontology (BA Ontology) e fazer o roteamentodas consultas na rede. A ontologia do BA é usada para guiar os agentes deconsulta(Query Agents) para os SINodes que contêm dados relevantes à consulta.É possível que no sistema existam vários BA, cada um representando um domínioespecífico. Mapeamentos entre diferentes BA podem ser criados e dessa formafazer com que novos encaminhamentos de consultas possam ser realizados. Logo,o SEWASIE se apresenta com uma arquitetura super-peer, onde os BA agem comosuper-peers, e os SINodes como peers de dados;

• Query Agents (QA) - após receber a consulta (expressa como uma ontologia doBA), reescreve em função do GVV do SINode (identificado pelo BA) e faz o envio;e

• User Agent (UA) - o usuário interage com uma interface Web gerenciada pelo UAque disponibiliza uma lista das ontologias dos BA disponíveis para que a consultapossa ser formulada. O UA instancia um QA que traduz, por meio dos BA, aconsulta do usuário em um conjunto de consultas que deverão ser realizadas nonível dos SINodes. No retorno da consulta, o QA integra as respostas e retorna osdados no formato XML para o UA (Beneventano et al., 2007).

28


Figura 3.3: Interface de consulta do SEWASIE (SEWASIE, 2011)

A Figura 3.3 mostra a interface de consulta Web do SEWASIE com uma consultano cenário comercial para fornecedores de calças (suppliers trousers) com um preçomenor que 80 euros (< 80). Esta consulta pôde ser composta interativamente pelo usuáriopor meio da visualização da ontologia em uma estrutura de árvore e selecionando ositens relevantes para a consulta. A interface de consulta contém uma funcionalidade deraciocínio que permite apenas uma combinação de propriedades que seja consistente àontologia onde, tomando como exemplo a consulta exibida na figura 3.3, foi feita umacombinação entre os itens vendidos (has selling) ,nesse caso calças (Thousers), pelofornecedor (Supplier) com uma restrição de preço (has price) menor que 80.

29


3.2.2 Interfaces de Consulta Baseada em Múltiplas Visões

A consulta baseada em visões múltiplas (Makela et al., 2004) combinada com o usode ontologias tem se mostrado como um poderoso paradigma de busca (Hyvonen andViljanen, 2003). Nessa abordagem, muitas visões distintas são previstas para os dados.Essas visões são criadas por projeção de ontologias usando também vários outros rela-cionamentos hierárquicos inerentes à ontologia. Nesta seção, serão descritas algumasabordagens que propõem este tipo de interface de usuário.

Ontogator(Hyvonen and Viljanen, 2003)Hyvonen (Hyvonen and Viljanen, 2003) apresenta o sistema Ontogator, onde as onto-logias de domínio são mapeadas em visões para facilitar a busca. Depois de encontrarinformações de interesse, o Ontogator usa a ontologia de domínio juntamente com asanotações de dados para recomendar aos usuários outros resultados relacionados. Essesoutros resultados relevantes não são aplicáveis na fase de busca por múltiplas visões. Elespodem ser exibidos por recomendação do sistema por meio de navegações semânticas.

Figura 3.4: Interface de consulta do Ontogator (Hyvonen and Viljanen, 2003)

30


A ideia por traz desse conceito é que o usuário pode iniciar restringindo a buscaa partir da visão que é mais natural para ele. A interface do sistema é apresentada naFigura 3.4 que exibe, em uma mesma tela, a visualização dos recursos selecionados, osresultados relevantes para a consulta e suas descrições.

OntoViews (Makela et al., 2004)Uma outra abordagem para interface de consulta baseada em ontologias é o OntoViews

apresentada por Makela (Makela et al., 2004). Ela utiliza o conceito de auto-completarque faz uso de busca por palavra-chave como um princípio para a navegação ontológica.A ideia é que a interface principal do portal abre com um campo para inserção depalavra-chave, como mostrado na Figura 3.5.

Figura 3.5: Interface de consulta do sistema OntoViews (Makela et al., 2004)

Nessa abordagem, as palavras-chave não são ligadas diretamente aos itens de in-formação, mas a classes ontológicas nas diferentes visões. Deste modo, ambiguidadessemânticas podem ser eliminadas. Após a inserção da palavra-chave, a busca proseguecomo uma consulta de múltiplas visões.

Uma vez que a pesquisa estiver em um ponto onde pelo menos uma única instância deinteresse é encontrada, informações adicionais podem ser obtidas por meio de navegação.O processo é similar à navegação da Word Wide Web, no entanto, os itens mostrados sãorecursos e as ligações entre eles são definidas por suas relações.

31


3.2.3 Interface Baseada no Roteamento de Consultas

Além das abordagens encontradas para interfaces de consulta baseadas em ontologias,foi encontrada uma abordagem proposta por Mandreoli (Mandreoli et al., 2007) quepermite ao usuário explorar o caminho mais promissor para o roteamento de consultasna rede. Nesta seção será descrita a interface proposta para a interação do usuário nessaabordagem.

SUNRISE (Mandreoli et al., 2007)O SUNRISE possui uma interface gráfica que permite ao usuário explorar os caminhosmais promissores, em se tratando do roteamento de consultas, durante uma busca emPDMS. Nessa interface, o usuário pode indicar o peer e o conceito a ser explorado noinício do processo, a condição de parada e a estratégia a ser explorada. São condiçõesde parada: (1) máximo de saltos; e (2) objetivo satisfeito (uma medida de qualidade doscaminhos a serem explorados). Com relação às estratégias de busca, o usuário poderáescolher entre randômico, baseado no mapeamento semântico (explorando apenas osvizinhos do mapeamento) e baseado em Semantic Routing Index (SRI) - utilizando osíndices semânticos.

Figura 3.6: Interface gráfica do SUNRISE (Mandreoli et al., 2007)

32


No SUNRISE cada peer que compõe a rede mantém um resumo das informações arespeito do grau de similiaridade semântica entre os conceitos armazenados entre um peer

e seus respectivos vizinhos. Essa informação é mantida em uma estrutura de dados localdenominada SRI. Sendo assim, um peer p que tenha n vizinhos e m conceitos em seuesquema, armazena um SRI estruturado como uma matriz com m colunas e n+1 linhas,onde a primeira linha refere-se ao conhecimento sobre o esquema local do peer p, comomostra a Figura 3.6. É possível assim, que cada peer sintetize, para cada conceito de seuesquema, a aproximação semântica das sub-redes acessíveis a partir de seus vizinhos e,assim, fornecer uma informação sobre a relevância dos dados que podem ser alcançadosem cada trajeto a ser escolhido.

Na Figura 3.6, o peer A é o ponto inicial de busca, o conceito solicitado é paper e aestratégia baseada em índices de roteamento semânticos SRI. O SRI do peer A indica quea direção mais promissora é o peer C. Logo, o peer C é escolhido e o processo é iniciado.O peer C torna-se o peer corrente e o conceito é traduzido conforme o mapeamento dosesquemas. O conceito paper do peer A torna-se o conceito article para o peer C. Emseguida, o usuário pode continuar a busca ou finalizar.

3.2.4 Resumo Comparativo das Abordagens Apresentadas

O Quadro 3.1 fornece uma comparação das abordagens apresentadas conforme o resumode algumas características: formulação de consultas (técnica adotada para a formulação esubmissão de consultas); visualização de resultados (técnica adotada para a visualizaçãode resultados de consultas); visualização da rede (possibilidade de visualização doesquema da rede); e usuário (tipos de usuários a interagir com o sistema).

Dentre as abordagens analisadas, todas apresentam propostas para a formulação esubmissão de consultas mas nenhuma propõe essas funcionalidades na forma de umainterface de usuário visual, que tem como objectivo não só fornecer uma interface deconsulta natural, mas também apoiar uma manipulação do esquema de dados permitindoa geração automática de consultas (Li et al., 1997).

As abordagens analisadas se apresentam, em geral, com diferentes técnicas e carac-terísticas particulares para a submissão de consultas, onde algumas destas podem seraproveitadas para uma implementação de maneira visual em PDMS. Como exemplo,tem-se a visualização da ontologia em forma de grafo proposta por Athanasis no GRQL(Athanasis et al., 2004) que ainda não possui uma implementação que a valide mas quepode ser acrescentada a uma interface de consulta visual.

Para a visualização dos resultados de consultas, apenas duas abordagens (Hyvonen

33


Quadro 3.1: Quadro resumo das abordagens apresentadas

AbordagensFormulação deconsulta

Visualização deresultados

Visualização darede

ImplementaçãoTipos de Usuá-rio

Query Tool

Uso de linguagens na-

turais sobre ontolo-

gias e Navegação por

menus

Não apresenta

proposta

Não apresenta

proposta

Não apresenta pro-

posta

Pode ser utilizada por

usuários que não pos-

suem conhecimento

sobre a organização

dos dados ou do

vocabulário utilizado

na ontologia

GraphicalRQL

Consulta expressa em

RQL e Formulada por

navegação na ontolo-

gia

Não apresenta

proposta

Não apresenta

proposta

Não apresenta pro-

posta

Não apresenta

proposta

SEWASIE

Consulta formulada

pela seleção de

conceitos por meio

da visualização da

ontologia em uma

estrutura de árvore

Integra as respostas

dos diversos peers e

retorna os dados no

formato XML mas

não propõe interface

Não apresenta

propostaInterface web

Não apresenta

proposta

Ontogator

Ontologias de domí-

nio são mapeadas em

visões e usadas com

as anotações de dados

para recomendar ou-

tros resultados.

Exibe em uma mesma

tela a visualização dos

recursos selecionados

e os resultados rele-

vantes para a consulta

bem como suas descri-

ções

Não apresenta

propostaDesktop

Não apresenta

proposta

OntoViews

Utiliza a técnica

de auto-completar

fazendo uso de busca

por palavra chave

como um princípio

para a navegação pela

ontologia

Não apresenta

proposta

Não apresenta

propostaInterface Web

Não apresenta

proposta

SUNRISE

O usuário visualiza o

esquema da rede indi-

cando o peer e o con-

ceito a ser consultado

Não apresenta

proposta

Permite ao usuário ex-

plorar os caminhos

mais promissores para

roteamento de consul-

tas

DesktopNão apresenta

proposta

34

3.3. O SISTEMA SPEED

and Viljanen, 2003; Beneventano et al., 2007) apontam discussões, sendo que apenas oOntogator (Hyvonen and Viljanen, 2003) propõe uma interface gráfica onde a visualizaçãodos resultados de consultas e suas descrições são apresentadas na interface mas sem umaorganização que facilite a interpretação dos resultados pelos usuários.

Quanto à visualização do esquema da rede, apenas o SUNRISE proposto por Madreoli(Mandreoli et al., 2007) apresenta uma interface para visualização dos pontos da redee seus relacionamentos. Esta visualização é usada como princípio para a submissão deconsultas, onde o usuário indica o peer e o conceito a ser consultado, permitindo exploraros caminhos mais promissores para roteamento de consultas.

Sobre tipos de usuários, apenas a Query Tool proposta por Franconi (Franconi et al.,2010) aponta que a interface pode ser utilizada por usuários que não possuem conhe-cimento sobre a organização dos dados ou do vocabulário utilizado na ontologia. Mas,ainda assim, não define o perfil do usuário e nem especifica as funcionalidades quefacilitariam a utilização do sistema para cada tipo de usuário, apresentando apenas umprotótipo da interface sem uma implementação que valide a proposta.

Dentre as soluções propostas, apenas quatro abordagens(SEWASIE, 2011; Hyvonenand Viljanen, 2003; Makela et al., 2004; Mandreoli et al., 2007) apresentam implementa-ções que validem as funcionalidades definidas mas, como dito anteriormente, nenhumacom formulação de consultas por meio de interfaces visuais de interação com o usuário.

3.3 O sistema SPEED

O sistema SPEED (Pires, 2009) é um sistema de gerenciamento de dados P2P (PDMS)baseado em semântica, composto de pontos cujos esquemas exportados são representadospor ontologias. Esta seção detalha o sistema SPEED em sua arquitetura, geração decorrespondências semânticas entre esquemas, conexão de um novo ponto e processamentode consultas.

3.3.1 Arquitetura do Sistema SPEED

No SPEED, os pontos são organizados de acordo com o conteúdo que compartilham.Existem três tipos de pontos no sistema SPEED : (i) ponto de dados; (ii) ponto deintegração; e (iii) ponto semântico.

Um ponto de dados representa uma fonte compartilhando dados com outros pontosde dados no sistema, através de mapeamentos semânticos. Os pontos de dados são oslocais onde são realizadas as consultas no sistema. Os pontos de dados são agrupados

35


nos clusters semânticos de acordo com seus interesses semânticos, ou seja, seu temade interesse e sua ontologia local. O tema de interesse é uma descrição do domíniosemântico do ponto, enquanto a ontologia local descreve o esquema exportado do pontode dados (Pires, 2009).

O ponto de integração é um ponto de dados com diferentes responsabilidades e maiorcapacidade computacional. Um ponto de integração ligado a vários pontos de dadossemanticamente similares forma um cluster semântico. Cada cluster está ligado a umconjunto de conceitos ontológicos (ontologia do cluster) que representa os dados com-partilhados pelos pontos daquele cluster. Este conjunto de conceitos é um subconjuntodos conceitos da ontologia de domínio armazenada no ponto semântico. A ontologiado cluster é armazenada no ponto de integração (Pires, 2009). Um ponto de integraçãopossui um conhecimento detalhado sobre os pontos de dados pertencentes ao seu cluster.Os pontos de integração se comunicam com outros pontos de integração, com os pontosde dados de seu cluster semântico e também com o ponto semântico (Arruda, 2010).Conjuntos de clusters semânticos que compartilhem informações a respeito de um mesmodomínio, junto com um ponto semântico, formam as comunidades semânticas.

O ponto semântico é responsável por armazenar e disponibilizar uma ontologiarepresentativa de uma comunidade - uma ontologia de domínio, contendo elementos quecaracterizam o conhecimento de um domínio. Uma outra responsabilidade desse tipo deponto é gerenciar os metadados dos pontos de integração e clusters que se conectam aele.

A Figura 3.7 ilustra a arquitetura do SPEED. Os esquemas de dados dos pontosno SPEED são representados através de ontologias, estruturadas na linguagem OWL -uma linguagem para definição e instanciação de ontologias na Web (Schneider, 2009).Exemplos de pontos de integração na Figura 3.7 são I1, I2 e In; S1 é um exemplo deponto semântico; I1D1 e I1D2 são exemplos de pontos de dados.

O sistema foi projetado com duas topologias de redes distintas: a Distributed Hash

Table (DHT), que organiza os pontos semânticos, e a super ponto para o gerenciamentode pontos de integração e pontos de dados. A rede DHT é utilizada para auxiliar umponto a encontrar outros pontos com características comuns através de uma função hash e,posteriormente, formarem comunidades semânticas. Dentro das comunidades semânticas,os pontos são organizados de acordo com a topologia super-ponto (Pires, 2009). Natopologia super-ponto alguns pontos podem assumir papéis distintos em uma rede, com aeleição de pontos de maior capacidade computacional para coordenar um subconjunto deoutros pontos da rede. Esses pontos eleitos são os super-pontos. A busca nesse tipo de

36


Figura 3.7: Arquitetura do sistema SPEED (Pires, 2009)

topologia é muito rápida em comparação a outras arquiteturas, já que o sistema possuiseu espaço de busca particionado em um conjunto menor de pontos coordenados porsuper-pontos, os quais possuem uma indexação das informações dos pontos coordenadospor ele (Yang and Garcia-Molina, 2003).

3.3.2 Geração de Correspondências Semânticas entre Esquemas

As correspondências semânticas são os relacionamentos identificados entre os conceitose propriedades dos esquemas dos pontos (esquemas locais).

No sistema SPEED os pontos são agrupados em um mesmo domínio de conhecimento(como Educação, Saúde, por exemplo) e uma ontologia descrevendo o domínio está dis-ponível para ser utilizada como background knowledge. As correspondências semânticasentre os pontos são estabelecidas para prover um entendimento comum de suas fontesde dados (Souza, 2009). Considera-se que as correspondências são determinadas entrepares de pontos que foram relacionados semanticamente de acordo com um processo declustering.

Dize-se que {C}= {Ci j}i<> j se refere ao conjunto de correspondências semânticasentre uma ontologia fonte (Oi) e uma ontologia destino (O j). Como a normalização termi-nológica é um requisito necessário no qual as representações iniciais das duas ontologias

37


são transformadas para um formato comum adequado para uma computação de simila-ridade, considera-se que Oi e O j foram convertidas para um formato de representaçãouniforme, ou seja, os nomes dos elementos de Oi e O j foram ajustados para se tornaremcompatíveis com os nomes dos elementos encontrados na Ontologia de Domínio (OD)(Souza, 2009).

As OD contêm conceitos e propriedades de um domínio de conhecimento em par-ticular. Consideramos as ontologias de domínio como referências confiáveis que sãodisponibilizadas na Web. Particularmente, nós as utilizamos para fazer a identificação dediferenças ou semelhanças conceituais entre duas ontologias.

Nesse sentido, duas ontologias passam por uma operação de comparação ontológica(matching semântico) e têm seus conceitos e propriedades comparados com os concei-tos ou propriedades equivalentes na OD e a correspondência semântica entre as duasontologias iniciais é inferida baseada no relacionamento semântico existente entre oselementos da OD . A ontologia de domínio possui um papel fundamental na definiçãodas correspondências semânticas utilizadas nas consultas do SPEED (Souza, 2009).

A Figura 3.8 mostra uma visão global para a especificação da semântica das cor-respondências entre duas ontologias O1 e O2 no sistema SPEED. Nessa figura, O1 : x

possui uma equivalência (denotada pelo símbolo ≡) com OD : k e O2 : y possui umaequivalência com OD : z. Como “k” é subconceito de “z” na OD, inferimos que o mesmorelacionamento ocorre entre “x” e “y”. Então, conclui-se que O1 : x é subconceito deO2 : y.

Essa abordagem considera sete tipos de correspondências semânticas (Souza, 2009):

• Equivalência, denotado por O1x≡ O2y;

• SubConceito e SuperConceito (Generalização e Especialização), denotados porO1xv O2y (x subconceito de y) e O1xw O2y (x superconceito de y);

• “Parte de” e “Todo” (Agregação e Composição), denotados por O1x .O2y (x éparte de y) e O1x/O2y (x é composto de y);

• Aproximação (isCloseTo), denotado por O1x≈ O2y; e

• Disjunção, denotado por O1x⊥ O2y

onde x e y são elementos (conceitos ou propriedades) pertencentes às ontologias O1 eO2.

38


Figura 3.8: Utilizando uma OD para especificar as Correspondências Semânticas (Souza,2009)

A fim de especificar essas correspondências, foram considerados quatro aspectos: (1)o conhecimento semântico encontrado na OD; (2) se os conceitos das ontologias dospeers compartilham superconceitos na OD; (3) se esses superconceitos são diferentes donó raiz; e (4) a profundidade entre dois conceitos medida em nós.

A seguir, cada um dos tipos de correspondências semânticas existentes é explicado,provendo alguns exemplos utilizando um cenário ilustrativo que diz respeito a dispositivoseletrônicos, incluindo computadores e seus componentes. A Figura 3.9 ilustra a OD e aFigura 3.10 mostra as ontologias do nosso cenário (Souza, 2009).

Nessa abordagem, se O1 : x aponta para (se relaciona com) um conceito “k” daOD e O2 : y se relaciona com o mesmo conceito “k”, pode-se inferir que ambos osconceitos ou propriedades descrevem o mesmo conceito ou propriedade do mundoreal(são equivalentes). Referindo-se ao cenário apresentado, se tem-se O1 : PC≡OD : PC

e O2 : ComputadorPessoal ≡ OD : PC, então O1 : PC ≡ O2 : ComputadorPessoal.A correspondência de subconceito diz que o conceito ou propriedade “x” de O1 é

menos genérico que o seu conceito (ou propriedade) relacionado “y” de O2. Por outro lado,a correspondência de superconceito expressa o fato de que “x” de O1 é mais enérico que “y”de O2. Supondo que O2 : ComputadorPessoal≡OD : PC , O3 : DispositivoEletronico≡OD : DispositivoEletronico e OD : PC v OD : DispositivoEletronico, então

39


Figura 3.9: Ontologia de Domínio (Souza, 2009)

Figura 3.10: Ontologias Comparáveis (Souza, 2009)

O2 : ComputadorPessoal v O3 : DispositivoEletronico.A correspondência “parte de” diz que o conceito “x” de O1 é parte/componente do

conceito relacionado “y” de O2, e a correspondência de “todo” expressa o fato de que“x” em O1 é um agregado (uma composição) de “y” que está em O2. Como exemploda correspondência “parte de” pode-se considerar que O3 : Teclado ≡ OD : Teclado ,O1 : PC ≡ OD : PC e OD : Teclado.OD : PC, então O3 : Teclado.O1 : PC.

Dois conceitos ou propriedades de ontologias comparáveis são ditos aproximados(close) se eles são percebidos como pertencendo juntos a um contexto relevante comum,ou seja, dois conceitos estão sob o mesmo conceito do mundo real (o mesmo ancestralna OD). Considerando a OD, dois conceitos aproximados normalmente se sobrepõem(overlap) em algum grau. Se isso não acontece, eles devem ser declarados explicitamentecomo disjuntos. Nesse sentido, exemplos de conceitos aproximados semanticamente

40


organizados sob o mesmo ancestral (Computador) são notebook, palmtop, e mainframe.O último tipo de correspondência é a disjunção, a qual foi definida no sentido de

identificar uma forte dissimilaridade entre os elementos das ontologias comparáveis. Essacorrespondência diz que dois conceitos O1 : x e O2 : y são disjuntos se os seus elementoscorrespondentes (equivalentes) na OD “k” e “z”, respectivamente, são disjuntos, ou seja,“k” e “z” foram definidos na OD como sendo disjuntos. Isso significa que “x” de O1 nãosobrepõe y de O2.

3.3.3 Conexão de um Novo Ponto

Quando um ponto de dados se conecta ao SPEED, este primeiramente identifica aqual comunidade semântica deverá pertencer, através de palavras-chave dos domíniosexistentes, utilizando a estrutura DHT do sistema. Após essa etapa, a busca pelo cluster

semântico a que ele vai pertencer é realizada através da operação de matching semântico(a mesma operação que gera as correspondências semânticas) entre a ontologia querepresenta o esquema do ponto que deseja se conectar e os sumários das ontologias dosclusters. Essa operação está ilustrada na Figura 3.11.

Figura 3.11: Descoberta de clusters semânticos através de comparação ontológica (Pires,2009)

Esse matching também irá originar uma medida de similaridade semântica entre asontologias, que ajudará a identificar o cluster do qual o ponto entrante do sistema faráparte. Um limite de cluster pode ser definido para descartar clusters que apresentembaixo grau de similaridade semântica. Em seguida, o ponto solicitante ao SPEED seconecta ao cluster cujo valor de similaridade foi o maior de todos os comparados. Osconceitos do esquema de dados (ontologia local) deste ponto são adicionados à ontologiado cluster. Neste caso, pode ser aplicado um processo de merge entre as ontologias.

41


Por outro lado, caso o valor de similaridade calculado seja inferior ao limite estabe-lecido, significa dizer que nenhum dos clusters daquela comunidade trata do interessedo ponto solicitante. Sendo assim, este ponto irá formar um novo cluster, cuja ontologiaserá formada inicialmente pelo seu esquema local e evoluirá com a conexão de outrosnovos pontos (Pires, 2009).

3.3.4 Processamento de Consultas

As correspondências semânticas apresentadas anteriormente são particularmente im-portantes para o processamento de consultas no SPEED. Quando um usuário submeteuma consulta num ponto de dados, a consulta, além de ser processada naquele ponto, éencaminhada até o ponto de integração daquele cluster. O ponto de integração identificaos pontos de dados capazes de responder àquela consulta, ao mesmo tempo em que aconsulta é propagada para outros pontos de integração da mesma comunidade (Arruda,2010).

Por meio das correspondências semânticas geradas entre os pontos da comunidadeé que a consulta pode ser reformulada para os termos dos esquemas de outros pontos,sem modificação da intenção semântica original (Souza, 2009). No final, os resultadosrecebidos dos pontos que executaram a consulta são integrados no ponto de integraçãoque propagou a consulta, e o resultado final é enviado ao ponto onde a consulta foisubmetida.

O usuário possui a liberdade de escolher quais correspondências semânticas serãolevadas em consideração no momento da reformulação da consulta. Essas escolhas, assimcomo a submissão da consulta em si, são feitas no módulo de consultas do sistema, queserá explicado na próxima seção.

3.3.5 Reformulação de Consultas no SPEED

As consultas no SPEED podem ser submetidas nos peers de integração ou nos peers dedados do sistema. No trabalho implementado por Souza (Souza, 2009) a reformulaçãoe execução de consultas é feita envolvendo apenas peers de integração. Esses peers

de integração recebem a consulta, processam localmente, reformulam de acordo com oesquema de outros pontos e no final integram os resultados recebidos dos demais pontose os apresentam ao usuário.

Uma questão importante nesse processo é a reformulação da consulta entre pontosatravés de caminhos de correspondências semânticas. Considerando a semântica implícita

42


existente nas correspondências entre os pontos, é possível, no momento da reformula-ção, permitir o enriquecimento da consulta, provendo os usuários com resultados maissignificativos (Souza, 2009).

O SPEED permite a elaboração de consultas em um ponto de submissão. O móduloainda identifica a semântica da consulta e, a partir de correspondências semânticas entreos peers, reformula essa consulta (com ou sem enriquecimento) e a envia a outros pontosde integração que possam respondê-la satisfatoriamente.

A utilização de semântica é uma das principais características do SPEED. Essasemântica auxilia para um processo de reformulação expandido e para a apresentaçãode resultados mais completos para as consultas. Na fase de reformulação da consulta,nem sempre um conceito presente no ponto de submissão terá conceitos equivalentes empontos de destino onde a consulta será executada depois de reformulada. Sendo assim,se não é possível produzir um resultado exato para uma dada consulta ou se o usuáriodefine que ele aceita que não sejam retornadas apenas respostas exatas, pode ser melhorproduzir um resultado com respostas aproximadas do que não produzir resultado algum(Souza, 2009).

Para este fim, o SPEED considera que uma consulta formulada de acordo com ostermos da ontologia de um peer fonte pode ser reformulada de forma exata ou enriquecidaem outra consulta utilizando os termos de uma ontologia de um peer destino em funçãodo conjunto de correspondências semânticas existente entre eles.

Utilizando esse conjunto de correspondências, as reformulações de uma consulta quepodem ser produzidas são definidas da seguinte maneira:

• Reformulação Exata - Uma reformulação Q′ de uma consulta Q é exata se cada con-ceito (ou propriedade) C′ de Q′ está relacionado com um conceito (ou propriedade)C de Q por meio de uma correspondência CO, onde CO ∈ {≡} (equivalência); e

• Reformulação Enriquecida - Uma reformulação Q′ de uma consulta Q é enriquecidase cada conceito (ou propriedade) C′ de Q′ está relacionado com um conceito (oupropriedade) C de Q por meio de uma correspondência CO, onde CO ∈ {v,w,≈,B,C,⊥}.

O usuário possui ainda a liberdade de escolher o modo de reformulação para suasconsultas: (1) modo restrito, onde apenas os resultados considerando as correspondênciasde equivalência são retornados, ou em outras palavras, apenas a reformulação exata seráproduzida; ou (2) modo expandido, onde o resultado contemplará as correspondênciassemânticas escolhidas pelo usuário na opção de configuração de um conjunto de variáveis

43


de enriquecimento, além da própria correspondência de equivalência, ou em outraspalavras, ambas as reformulações (exata e enriquecida) serão produzidas.

Para considerar as outras correspondências no modo expandido (exceto equivalên-cia), o usuário encontra no SPEED uma série de variáveis, chamadas de variáveis deenriquecimento, que podem ser selecionadas e priorizapara as consultas.

Cada variável está ligada a uma ou mais correspondências semânticas para seremincorporadas na reformulação da consulta. São quatro variáveis de enriquecimento: (1)Aproximação, referente à correspondência de aproximação; (2)Especialização, ligadaà correspondência de subconceito; (3) Generalização, referente à correspondência desuperconceito; e (4) Composição, ligada às correspondências de agregação.

O usuário submete uma consulta num peer P1 e ela é reformulada apenas para umpeer destino (P2). Sendo assim, tem-se apenas duas ontologias (esquemas) de pontosenvolvidas no processamento da consulta (O1 e O2) e um conjunto de correspondênciassemânticas entre elas. A Figura 3.12 ilustra esse cenário.

Figura 3.12: Cenário das consultas no SPEED(Souza, 2009)

O SPEED utiliza o conceito de contexto, como uma forma de melhorar todo o

44


processo de reformulação da consulta. O contexto do usuário é identificado a partirdo conjunto de variáveis de enriquecimento que permitem ao usuário expressar suaspreferências a respeito do processo de reformulação (em outras palavras, o usuário decideque correspondências semânticas devem ser levadas em consideração na reformulação daconsulta e em que ordem de priorização essas correspondências devem ser consideradas).

O contexto da consulta é adquirido a partir de sua semântica e do seu modo dereformulação (se no modo restrito ou no modo expandido). Finalmente, o contexto doambiente é capturado utilizando alguns parâmetros definidos pelo usuário e leva emconsideração a disponibilidade dos peers (Souza, 2009).

3.4 Considerações

Uma vez conhecida as abordagens apresentadas na Seção 3.2, é possível identificaralgumas das principais características e funcionalidades necessárias à interação do usuáriocom sistemas PDMS, principalmente as que envolvem funcionalidades de formulação esubmissão de consultas.

Analisando as abordagens, com auxílio do Quadro 3.1 que resume as principaiscaracterísticas de cada uma, observa-se a necessidade de definição de uma interface visualpara PDMS com algumas das funcionalidades existentes apresentadas pelos autores e,também, acrescentando novas funcionalidades, ainda não definidas de maneira visualpara a interação do usuário em PDMS.

Neste capítulo também foi detalhado o sistema SPEED em sua arquitetura, geração decorrespondências semânticas entre esquemas, conexão de um novo ponto e processamentode consultas. Essas são as características do sistema SPEED consideradas necessáriaspara a interação do usuário.

Nesse sentido, o Capítulo 4 apresentará a especificação de uma interface visual parainteração de usuários com PDMS.

45

4VisualSPEED: Uma Interface de Interação

com o Usuário para PDMS Baseado emOntologias

Neste capítulo será detalhada a especificação de uma interface visual para PDMS baseadoem ontologias. Inicialmente, a arquitetura proposta será descrita, seguido dos requisitosdefinidos para a interface e do modelo de casos de uso da interface de interação dosusuários com o sistema.

4.1 Arquitetura da VisualSPEED

Como já mencionado anteriormente, este trabalho propõe uma interface visual de inte-ração com o usuário para PDMS baseado em ontologias. Nesse sentido, o ambiente dosistema SPEED, descrito na Seção 3.3, foi utilizado para estudo e definição das funci-onalidades e características desta interface. Para alcançar este objetivo, foi necessárioadicionar duas novas camadas à arquitetura do sistema SPEED: a camada de interaçãocom o usuário e a camada de gerenciamento. A camada de interação com o usuárioé composta por cinco novos módulos que irão operar na interação do usuário com osistema. A camada de gerenciamento é composta por dois novos módulos responsáveispela comunicação entre a camada de interação com o usuário e o núcleo do sistemaSPEED. A Figura 4.1 ilustra a arquitetura proposta onde as novas camadas e módulos sãoapresentados em linha contínua e a terceira camada, que representa o núcleo do sistemaSPEED com os componentes necessários às funcionalidades de interação com o usuário,em linha pontilhada.

46

4.1. ARQUITETURA DA VISUALSPEED

Figura 4.1: Arquitetura do sistema destacando as camadas e módulos que irão operar nasatividades de interação do usuário com o sistema SPEED

Os seguintes componentes do sistema SPEED, localizados na terceira camada daFigura 4.1, não foram desenvolvidos no escopo deste trabalho:

• PSemRef - representa o módulo de consultas do sistema, responsável pelo proces-samento e reformulação de consultas (Arruda, 2010). Este contém um módulointerno para tradução das consultas:

47


– Tradutor SPARQL- responsável por traduzir as consultas formuladas pelousuário no módulo FormQuery em uma consulta SPARQL, caso esta nãotenha sido formulada já nesta linguagem.

• Comunidade Semântica - são pontos de dados agrupados em clusters semânticosde acordo com seus interesses semânticos, ou seja, seu tema de interesse e suaontologia local; e

• Pontos de dados - representam, de modo geral, as fontes de dados que serãoconsultadas no sistema.

Para melhor entendimento das responsabilidades e funções de cada novo módulo dascamadas de interação com o usuário e gerenciamento, os mesmos serão descritos nasseções seguintes.

4.1.1 Módulo ViewOntology

O módulo ViewOntology é responsável por converter as ontologias, que representam osesquemas das fontes de dados, em visualizações gráficas ou em hierarquia de termos.Estas opções estarão disponíveis para uma escolha do usuário conforme sua preferênciapara a visualização e navegação pela ontologia.

A Figura 4.2 ilustra o funcionamento do módulo ViewOntology onde, para a visualiza-ção gráfica da ontologia, faz-se o uso de uma Application Programming Interface (API)que processa o arquivo recebido e constrói a visualização da ontologia a ser exibida parao usuário em forma de grafo.

Para a visualização hierárquica, o módulo ViewOntology processa o arquivo recebidoe constrói a visualização da ontologia a ser a exibida para o usuário como uma hierarquiade termos. Essa visualização hierárquica foi implementada inicialmente no módulo deconsultas PSemRef.

4.1.2 Módulo FormQuery

O módulo FormQuery é responsável pela formulação das consultas que serão enviadasao módulo de consultas. Esta formulação atende à necessidade de diversos tipos deusuário e poderá ser efetuada de duas maneiras: (1) para usuários não conectados apontos participantes da rede, por meio da escolha de um domínio e um ponto de partida,que serão informados pelo sistema, seguido da visualização e manipulação do esquema

48


Figura 4.2: Funcionamento do Módulo ViewOntology

de dados do ponto escolhido; e (2) para usuários participantes da rede, partindo direto davisualização e manipulação do esquema de dados local. Estas opções para a formulaçãode consultas serão disponibilizadas automaticamente de acordo com o tipo de usuárioque esteja interagindo com o sistema.

A Figura 4.3 ilustra o funcionamento do módulo FormQuery detalhando a composiçãode uma consulta por seleção de conceitos em uma visualização gráfica da ontologia. Nestacomposição de consulta, é possível o uso de operadores da lógica de descrição DL e detemplates para inserção de uma instrução SPARQL. A consulta formulada neste móduloé encaminhada para o módulo de consultas que, por sua vez, irá executa-la e enviar osresultados para o módulo ViewResults.

Figura 4.3: Funcionamento do Módulo FormQuery

4.1.3 Módulo ViewResults

O módulo ViewResults é responsável pela organização e exibição dos resultados dasconsultas. Este módulo é responsável também pela exibição de informações detalhadas

49


sobre os resultados, tais como as correspondências semânticas que os geraram e ospontos de origem dos mesmos, sendo estes identificados em uma visualização gráficada topologia rede. Para acesso às informações de rede do sistema SPEED, este móduloconta com o auxílio do módulo CommunicationManager (descrito na Seção 4.1.6).

A Figura 4.4 ilustra o funcionamento do módulo ViewResults, onde os resultadosrecebidos do módulo de consultas são exibidos em uma tabela que relaciona o resultadoencontrado com o ponto de dados que o originou. Nessa tabela também está disponívelum ícone, que permite ao usuário ter acesso a informações detalhadas sobre os resultadoscomo, por exemplo, as correspondências semânticas que os geraram e a visualizaçãográfica da topologia da rede com o ponto de origem identificado nesta.

Figura 4.4: Funcionamento do Módulo ViewResults

4.1.4 Módulo ViewNetwork

O módulo ViewNetwork é responsável por exibir a topologia da rede possibilitando aousuário conhecer os vizinhos do ponto onde ele está interagindo. Para essa visualização,o módulo ViewNetwork conta com o apoio do módulo CommunicationManager que faza comunicação com a rede do SPEED e solicita a topologia da rede ao peer semântico(componente do SPEED descrito anteriormente no Capítulo 3). Essa topologia é retornadaao ViewNetwork, por meio do CommunicationManager, como um documento no formatoXML que será processado por uma API para a construção da visualização gráfica da rede.

A Figura 4.5 ilustra o funcionamento do módulo ViewNetwork detalhando os passospara a construção da visualização gráfica do esquema da rede.

50

4.2. REQUISITOS ESTABELECIDOS PARA A INTERFACE VISUALSPEED

Figura 4.5: Funcionamento do Módulo ViewNetwork

4.1.5 Módulo QueryManager

O Módulo QueryManager é responsável pelo tratamento das consultas formuladas pelousuário no módulo FormQuery deixando-as em um formato que possam, então, sersubmetidas e compreendidas pelo módulo de consultas do SPEED. Além disso, efetua oprocessamento dos resultados de consulta traduzindo-os para um formato compreensívelao módulo ViewResults para visualização pelo usuário.

4.1.6 Módulo CommunicationManager

O módulo CommunicationManager é responsável pela comunicação da camada deinteração com o sistema SPEED. Esse módulo funciona como um proxy entre os módulosda camada de interação com o usuário e os demais componentes do sistema SPEEDnecessários às funcionalidades de interação.

4.2 Requisitos Estabelecidos para a Interface VisualS-PEED

Um requisito é definido como uma condição ou uma capacidade com a qual o sistemadeve estar de acordo. Existem diferentes tipos de requisitos:

• Os requisitos funcionais especificam ações que um sistema deve ser capaz deexecutar;

51


• Os requisitos de dados captam tipo, volatilidade, tamanho, persistência, precisão evalor das quantidades de dados exigidos;

• Os requisitos de contexto ou ambiente referem-se à circunstância em que se esperaque o sistema opere;

• Os requisitos de usuário capturam as características do grupo de usuários preten-dido; e

• Os requisitos de usabilidade captam metas de usabilidade (eficiência, eficácia,segurança, utilidade, capacidade de memorização e capacidade de aprendizagem) eas medidas associadas para um produto em particular (Rogers et al., 2011).

Analisando a arquitetura apresentada na Figura 4.1 é possível observar algumascaracterísticas e funcionalidades desejáveis para a interface de interação do sistemaSPEED. Primeiro, tendo em vista a submissão de consultas, o sistema precisa ofereceruma interface amigável e, essencialmente, compreensível para a formulação de consultas,visualização dos resultados, visualização da topologia da rede, dentre outras funcionalida-des. Segundo, cada tipo de usuário necessita de uma interface adequada às necessidadese privilégios de seu perfil. Terceiro, por tratar-se de um ambiente distribuído, comomostrado anteriormente, é desejável que se possua uma interface para visualização gráficada topologia da rede, bem como um formulário de cadastro que possibilite a entrada denovos pontos de dados, caso o sistema esteja sendo acessado por um usuário que aindanão faça parte da rede.

A partir das características gerais apresentadas foram estabelecidos os RequisitosFuncionais (RF) desejáveis ao sistema:

RF1 - Disponibilizar um cadastro para integração de novos pontos à rede.

RF2 - Listar os domínios existentes na rede.

RF3 - Listar os pontos de dados que participam de um determinado domínio.

RF4 - Apresentar o esquema de dados dos pontos em forma gráfica.

RF5 - Possibilitar a composição de consultas por meio da seleção de conceitos narepresentação gráfica do esquema de dados dos pontos.

RF6 - Permitir a inserção de operadores para a composição de consultas.

52


RF7 - Interpretar e traduzir as consultas fornecidas pelo usuário em comandos SPARQLpara execução nos pontos de dados.

RF8 - Possibilitar a submissão de consultas por meio da inserção de comandos SPARQL.

RF9 - Disponibilizar templates para a inserção de comandos SPARQL.

RF10 - Permitir o enriquecimento das consultas.

RF11 - Exibir os resultados das consultas de uma maneira organizada, que permita avisualização de informações detalhadas sobre os resultados.

RF12 - Informar as correspondências semânticas que geraram os resultados.

RF13 - Possibilitar que o usuário julgue um resultado satisfatório ou não para a consultasubmetida de acordo com as correspondências semânticas que os geraram.

RF14 - Exibir, graficamente, a topologia da rede.

RF15 - Identificar na topologia da rede o ponto de origem dos resultados.

RF16 - Possibilitar a impressão dos resultados.

RF17 - Possibilitar o arquivamento dos resultados.

Alguns desses requisitos (RF7, RF8, RF9 e RF10) ja possuem versões implementadasno módulo de consultas PSemRef (Arruda et al., 2010). Assim, para estes casos deseja-se acrescentar algumas melhorias em sua forma de apresentação ao usuário para estetrabalho.

Requisitos funcionais são melhor descritos em um diagrama de casos de uso. Odiagrama de casos de uso é um diagrama da Unified Modeling Language (UML) cujoobjetivo é representar, do ponto de vista do usuário, um requisito do sistema que seráautomatizado (Pressman, 2009).

Para o desenvolvimento do diagrama de casos de uso geral do sistema, foi necessáriodefinir os tipos de usuário do mesmo: Usuário Participante da Rede (UP) e Usuárionão Participante da Rede (UN), possibilitando que usuários externos possam acessar osistema.

O usuário UP é integrante de uma comunidade semântica da rede. Este ponto dedados representa um provedor compartilhando dados com outros pontos de dados nosistema.

53


O usuário UN é aquele que interage com o sistema por meio de um computador quenão é ponto de dados da rede e não compartilha dados com o sistema. Este tipo de usuáriorepresenta um consumidor dos dados compartilhados no sistema e, como não compartilhadados com a rede, necessita primeiramente escolher um domínio e um ponto que sejaprovedor de dados para acessar o esquema deste e poder formular e submeter consultas.Além disso, o usuário UN tem a opção de se tornar um provedor da rede por meio de umcadastro, caso tenha interesse de compartilhar seus dados com a rede.

Figura 4.6: Diagrama de casos de uso do sistema SPEED

54

4.3. PROTOTIPAÇÃO DA INTERFACE VISUALSPEED

Diante das particularidades dos tipos de usuário definidos para o sistema, o diagramade casos de uso, apresentado na Figura 4.6, exibe a interação para cada um destes tiposde usuário.

Analisando o diagrama, observa-se que o usuário UN possui algumas atividades amais que o usuário UP pois, como dito anteriormente, este tipo de usuário não acessa osistema como um ponto participante (provedor de dados) da rede, necessitando, para asubmissão de consultas, escolher um domínio e um ponto de partida para se conectar. Ousuário UN também tem a opção de se tornar um membro da rede por meio do cadastrodisponibilizado como uma opção na visualização da rede.

4.3 Prototipação da Interface VisualSPEED

As atividades do projeto de interação iniciam uma vez que o conjunto de requisitos tenhasido estabelecido. Existem dois tipos de projeto: o conceitual e o físico. O primeiropreocupa-se em desenvolver um modelo conceitual que capte o que o sistema irá realizare como irá se comportar, o segundo preocupa-se com detalhes como tela, estrutura demenus, ícones e gráficos (Rogers et al., 2011).

Como apresentado no Capítulo 3, o projeto evolui iterativamente em ciclos repetidosde projeto-avaliação-reprojeto. Para que esta avaliação fosse eficaz foi desenvolvida umaversão interativa da interface do sistema, um protótipo. Existem dois tipos de protótipo:protótipos de baixa fidelidade e protótipos de alta fidelidade. O protótipo de baixafidelidade é aquele que não se assemelha muito ao produto final, ele utiliza materiaiscomo papel e cartolina em vez de telas eletrônicas. A prototipagem de alta fidelidadeutiliza materiais que se espera que estejam no produto final e realiza um protótipo que separece muito mais com algo acabado (Rogers et al., 2011).

As telas de interação do sistema a ser desenvolvido foram prototipadas com base nasanálises dos requisitos, diagrama e arquitetura propostos anteriormente.

Os protótipos foram desenvolvidos utilizando a ferramenta Pencil, uma ferramentagratuita e de código aberto para fazer diagramas e prototipação de interfaces gráficas deusuário (Mozila, 2011). Nesta seção serão descritas detalhadamente as principais caracte-rísticas e funcionalidades definidas para o sistema, com protótipos de alta fidelidade quepermitiram obter uma versão interativa da interface e ilustrar as telas das funcionalidadesque serão desenvolvidas.

Como apresentado no diagrama ilustrado na Figura 4.6, foi necessário considerar

55


dois tipos de usuários diferentes para o sistema: usuário UP e o usuário UN. Diantedisso, se faz necessário que o sistema possua uma apresentação diferenciada em algumasfuncionalidades para cada tipo de usuário. Dentre estas, se destacam a submissão deconsultas que está disponível para os dois tipos de usuário, mas é executada de maneiradiferenciada para o usuário UN; e a visualização da topologia da rede que oferece umaopção de cadastro para se tornar um provedor de dados, como descrito anteriormente.

O sistema irá apresentar para ambos os usuários quatro menus: Home, Query, Network

e Documentation, onde os menus Home e Documentation irão se comportar de maneirapadrão para todos os tipos de usuário. O menu Home exibirá informações detalhadascomo a descrição do sistema e os pontos participantes da rede. O menu Documentation

apresentará os documentos do sistema disponíveis aos usuários como, por exemplo, umguia de utilização. Os protótipos das telas dos menus Home e Documentation estãoilustrados nas Figuras A.1 e A.2, respectivamente, apresentadas no Apêndice A.

O menu Query se apresenta com características diferentes para a submissão deconsultas por cada um dos tipos de usuário.

Um usuário UP acessa o sistema por meio de um ponto de dados ou ponto deintegração, tipos de pontos do SPEED descritos no Capítulo 3. Esses usuários são capazesde visualizar o seu esquema de dados em forma de grafo ou como uma hierarquia determos, como apresentado nos protótipos ilustrados nas Figuras 4.7 e 4.8, respectivamente,satisfazendo o requisito [RF4].

Figura 4.7: Protótipo da tela de consulta com visualização gráfica de uma ontologia

56


Figura 4.8: Protótipo da tela de consulta com visualização hierárquica de uma ontologia

Esta visualização gráfica permitirá uma manipulação da ontologia onde os usuáriospoderão criar visões diferentes da mesma, destacando pontos de seu interesse através danavegação pela estrutura gráfica ou configurando os níveis de profundidade desejados.A manipulação da ontologia poderá ser feita por meio de uma visualização gráficaapresentada no lado esquerdo da tela ilustrada na Figura 4.7, e também por meio de umavisualização hierárquica, apresentada na Figura 4.8.

A formulação de consultas para os usuários será feita por meio da seleção de conceitosna representação gráfica da ontologia, satisfazendo o requisito [RF5]. Os conceitosselecionados serão direcionados ao campo de composição da consulta, apresentada nolado superior direito das telas de consulta apresentadas nas Figuras 4.7 e 4.8 onde poderãoser usados operadores DL para a composição da consulta, satisfazendo o requisito [RF6].

A consulta composta e submetida pelo usuário é interpretada pelo sistema e traduzidapara um comando SPARQL para ser executada nos pontos de dados ou de integração,satisfazendo o requisito [RF7].

Os usuários podem ainda efetuar a personalização da consulta por meio da seleção epriorização de variáveis de enriquecimento. Essas variáveis possuem relações com umaou mais correspondências semânticas da seguinte maneira(Arruda, 2010):

• Approximate - correspondência de aproximação (isCloseTo);

• Generalize - correspondência de subconceito (isSubConceptOf );

57


• Specialize - correspondência de superconceito (isSuperConceptOf ); e

• Compose - correspondências de agregação (isPartOf e isWholeOf ).

O enriquecimento da consulta está ilustrado na parte inferior direita das Figuras 4.7 e4.8, satisfazendo o requisito [RF10].

Ainda no menu Query, usuários especialistas tem a opção de submeter consultas pormeio de comandos SPARQL, satisfazendo o requisito [RF8].

Selecionando a opção para submissão de consultaSPARQL, os usuários terão oauxílio de templates, visto que a linguagem SPARQL não é intuitiva para a maioria dosusuários (Arruda, 2010). Para formulação das consultas, os usuários deverão escolherum dos templates disponíveis na interface, satisfazendo o requisito [RF9], e selecionaros conceitos desejados na visualização gráfica da ontologia para o preenchimento dotemplate escolhido.

Figura 4.9: Protótipo da tela para submissão de consulta SPARQL

Cada template SPARQL possui a estrutura de uma consulta específica. Tais templatespodem ser visualizados na parte superior direita do protótipo ilustrado na Figura 4.9,nessa ordem, de cima para baixo, (1) one concept ou busca por um conceito; (2) union ouunião de conceitos; (3) intersection ou interseção de conceitos; e (4) negation ou negaçãoe complemento de um conceito.

58


Para a submissão de consultas por um usuário UN, considera-se que este pode nãoter conhecimento sobre ontologias e/ou PDMS e, como este tipo de usuário não estáem um ponto de dados na rede, ele precisa, primeiramente, se conectar a um ponto dedados para ter acesso à visualização de seu esquema de dados para prosseguir com acomposição da consulta. Assim, o sistema deve conduzir o usuário desde o início daformulação da consulta até a exibição dos resultados. Diante disso, foram definidas duasetapas iniciais, específicas para usuários UN, pelas quais é necessário ao usuário passarpara a formulação da consulta. Estas etapas são descritas a seguir:

1. Seleção do domínio - nesta etapa o usuário deverá escolher um domínio para sub-missão de consultas em uma lista informada pelo sistema, satisfazendo o requisito[RF2]; e

2. Seleção de um ponto de partida - aqui o sistema irá exibir os pontos participantesda comunidade semântica, que representa o domínio escolhido na primeira etapa, eo usuário deverá escolher um ponto de partida para a submissão de consultas.

Após ter selecionado o ponto de partida, o usuário UN poderá visualizar o esquema doponto de dados escolhido e proceder com a consulta seguindo o mesmo padrão utilizadopara um usuário UP, descrito anteriormente.

Uma vez submetida a consulta, o sistema deve exibir os resultados de uma maneiraorganizada, que permita a visualização de informações detalhadas sobre estes, satisfa-zendo o requisito [RF11]. Além da visualização dos resultados, o sistema deve permitir aimpressão e armazenamento destes como indicado à direita na parte superior da área devisualização de resultados, satisfazendo os requisitos [RF16] e [RF17], respectivamente.A visualização dos resultados está na parte inferior direita do protótipo ilustrado nasFiguras 4.7, 4.8 e 4.9.

Na visualização dos resultados, o sistema deve permitir que os usuários acesseminformações mais detalhadas sobre os resultados como, por exemplo: as correspondênciassemânticas existentes entre os termos das ontologias consideradas para a reformulação dasconsultas entre os pontos de dados; e a identificação dos pontos de dados que originaramo resultado.

Analisando as correspondências semânticas, o sistema deve permitir que o usuáriosindiquem sua satisfação quanto aos resultados, satisfazendo o requisito [RF13]. Na telade visualização das correspondências o usuário deverá enviar seu feedback ao sistemaaceitando ou rejeitando um determinado resultado para a consulta submetida.

59


Outra funcionalidade que o sistema deve disponibilizar nas informações detalhadasdos resultados é uma visualização da topologia da rede identificando os pontos que deramorigem aos resultados, satisfazendo o requisito [RF15]. O protótipo da tela para estavisualizacão está ilustrado na Figura 4.10.

Figura 4.10: Protótipo de visualização dos pontos de origem de um resultado

A visualização da topologia da rede , que satisfaz o requisito [RF14], também deveser apresentada por meio do menu Network. Essa visualização da topologia da redepermitirá que o usuário conheça os demais pontos que compartilham dados na rede sem anecessidade de ter submetido uma consulta previamente. Por meio desta visualização,o usuário poderá visualizar a localização de todos os pontos na rede com opções quefacilitem o entendimento da topologia como, por exemplo, destacar os clusters de dados epermitir que o usuário visualize somente alguns dos tipos de pontos de dados do sistema,de acordo com sua preferência.

Os protótipos de telas das etapas iniciais de submissão de consulta por um usuário UN,da visualização de informações detalhadas dos resultados de consultas com feedback, e domenu Network estão ilustrados nas Figuras A.3, A.4 e A.5, respectivamente, apresentadasno Apêndice A.

O menu Network deve apresentar ainda, exclusivamente para usuários UN, alémda topologia da rede, um formulário de cadastro permitindo que novos pontos sejamintegrados ao sistema, satisfazendo o requisito [RF1].

60


Para participar do sistema será necessário que o usuário forneça um esquema dedados e selecione o domínio no qual o novo ponto irá participar (o domínio indicará acomunidade semântica na qual o novo ponto será alocado). Caso o domínio desejado aindanão exista no sistema, será possível informar um novo domínio e uma nova comunidadesemântica será criada. O protótipo para o formulário de cadastro está ilustrado na Figura4.11.

Figura 4.11: Tela de cadastro de um novo ponto

4.4 Considerações

Neste capítulo, a especificação da interface VisualSPEED foi apresentada, iniciando coma descrição da arquitetura proposta para o sistema e a definição de requisitos para ainterface. Foram apresentados também, a modelagem de casos de uso, considerando doistipos de usuário para o sistema SPEED; e a descrição das funcionalidades e característicasdefinidas para a interface VisualSPEED, com alguns protótipos que ilustraram a propostadeste trabalho. Estas funcionalidades e características foram definidas de acordo com asnecessidades para a interação do usuário com PDMS.

Como dito anteriormente, dentre as interfaces existentes para PDMS analisadas noCapítulo 3, nenhuma apresenta proposta para a formulação e submissão de consultas emuma interface visual, que tem como objetivo não só fornecer uma interface de consulta

61


amigável, mas também apoiar uma manipulação precisa e direta do esquema de dadospermitindo a geração automática de consultas.

O Quadro 4.1 apresenta uma comparação entre as abordagens analisadas e a VisualS-

PEED, destacando também que nenhuma das abordagens existentes atende, de formageral, a todas as características e funcionalidades necessárias para a interação do usuáriocom PDMS em uma interface visual, como proposto neste trabalho.

O próximo capítulo apresentará os detalhes da implementação da interface VisualS-

PEED validando a proposta deste trabalho.

Quadro 4.1: Quadro de contribuição da VisualSPEED em relação as abordagens existentes

AbordagensFormulação de

Consulta

Visualização de

Resultados

Visualização da

RedeImplementação

Vários Tipos de

Usuário

Query Tool X - - - XGraphical RQL X - - - -SEWASIE X - - X -Ontogator X X - X -OntoViews X - - X -SUNRISE X - X X -VisualSPEED X X X X X

62

5Implementação e Estudo de Caso

A fim de validar a abordagem proposta nesse trabalho, este capítulo detalha a implementa-ção da interface VisualSPEED, desenvolvida e validada no ambiente do sistema SPEED,um PDMS baseado em ontologias descrito na Seção 3.3.

Para a demonstração da VisualSPEED, será ilustrado o passo-a-passo de utilizaçãoe funcionamento da interface com alguns exemplos de consultas em um estudo de caso(exemplo de uso da interface desenvolvida).

Além da implementação e estudo de caso, será apresentada a avaliação da interfacedesenvolvida. Para esta avaliação, foram considerados alguns critérios de usabilidade e odesempenho das funcionalidades disponíveis para a interação com o usuário.

5.1 Implementação da Interface VisualSPEED

Para a implementação do VisualSPEED, foi utilizada a linguagem de programação Java(Oracle, 2012), com o auxílio do Integrated Development Environment (IDE) Eclipse(Eclipse, 2012).

A linguagem Java foi escolhida por ser uma linguagem independente de plataformae, em uso com a ferramenta Eclipse, permite a utilização de plugins para a criação deinterfaces gráficas amigáveis para a interação com o usuário.

O plugin utilizado foi o Jigloo (CloudGarden, 2012), que permite construir e gerenciarinterfaces gráficas Java Swing e Standard Widget Toolkit (SWT).

Além disso, Java possui API (Jena, 2011; Stanford, 2012) que dão suporte à progra-mação com ontologias, facilitando sua manipulação. Estas APIs permitem o desenvolvi-mento de métodos de consultas sobre ontologias com o uso da linguagem SPARQL.

Nesta seção, são apresentados os detalhes de implementação da interface VisualS-

PEED, exibindo as principais telas para interação dos usuários com o sistema.

63

5.1. IMPLEMENTAÇÃO DA INTERFACE VISUALSPEED

5.1.1 Submissão de Consultas

A submissão de consultas é acessada por meio do menu Query e, como dito anteriormente,se apresenta com caracrerísticas diferentes para cada tipo de usuário.

Figura 5.1: Tela para princípio da submissão de consultas por usuário UN

Para a submissão de consultas por um usuário UN, a interface oferece os passosdefinidos na especificação, para escolha do domínio e ponto de partida. A tela como princípio para submissão de consultas por usuários UN está ilustrada na Figura 5.1,na qual o usuário escolhe o domínio de interesse na lista de domínios informada pelosistema, e o ponto de dados, na visualização gráfica da topologia da rede.

Selecionado o ponto de partida, o usuário UN poderá visualizar o esquema do pontode dados escolhido seguindo o mesmo padrão do usuário UP.

Para a visualização gráfica das ontologias, foi utilizada a API Prefuse (Prefuse, 2011)que fornece um conjunto de ferramentas de software livre para a criação de visualizaçõesinterativas de dados. Esta API processa o arquivo da ontologia, recebido no formatoOWL, auxiliando na construção da visualização da ontologia a ser exibida para o usuárioem forma de grafo.

A formulação de consultas é feita por meio da seleção de conceitos na representaçãográfica da ontologia. Para selecionar, basta clicar duplamente nos conceitos desejadose estes serão direcionados ao campo de composição da consulta, apresentada no ladosuperior direito das telas de consulta ilustrada nas Figuras 5.2 e 5.3. Neste campo

64


Figura 5.2: Tela de consulta com visualização gráfica de uma ontologia

também estão disponíveis os operadores AND, OR e NOT para a composição da consulta,conforme especificação. Os operadores presentes na interface estão relacionados aconstrutores DL para a submissão da consulta ao módulo PSemRef. Estes operadores DLsão, na ordem de cima para baixo, t disjunção (ou operador de união), u conjunção (ouoperador de interseção), ¬ negação (ou operador de complemento).

Ainda na tela de submissão de consultas, o usuário pode efetuar a personalização daconsulta por meio da seleção e priorização de variáveis de enriquecimento, conformeespecificação da interface apresentada no Capítulo 4. O enriquecimento da consulta estáilustrado na parte central direita das Figuras 5.2 e 5.3.

Uma outra opção para submissão de consultas por usuários especialistas, definidana especificação da interface apresentada no Capítulo 4, é o uso de comandos SPARQL.Na interface implementada, esta funcionalidade também é acessada por meio do menuQuery.

Na opção SPARQL as consultas são formuladas com o auxílio de templates, dispo-níveis na área de formulação das consultas, conforme especificado. Para formular umaconsulta SPARQL, o usuário precisa preencher o template escolhido para submissão da

65


Figura 5.3: Tela de consulta com visualização hierárquica de uma ontologia

consulta SPARQL. A tela para esta opção está ilustrada na Figura 5.4.

5.1.2 Visualização de Resultados

Uma vez submetida a consulta, a mesma será processada e os resultados desta são exibidosem uma tabela que relaciona as instâncias encontradas com o ponto que a originou. Atabela de visualização dos resultados está ilustrada na parte inferior direita das Figuras5.2, 5.3 e 5.4.

Ainda na tabela de visualização dos resultados, os usuários podem acessar as informa-ções mais detalhadas sobre estes por meio do ícone localizado à direita da instância quese deseja obter a informação. A tela de visualização destas informações está ilustrada naFigura 5.5. Analisando as correspondências semânticas, os usuários podem ainda indicarsua satisfação quanto aos resultados, conforme especificado para a interface no Capítulo4. Para isto devem utilizar os ícones de feedback, localizado à direita da tela.

Outra funcionalidade, disponível por meio do ícone de informações de resultados, é avisualização do esquema gráfico da topologia da rede com identificação dos pontos deorigem dos resultados. A tela para esta funcionalidade está ilustrada na Figura 5.6.

66


Figura 5.4: Tela para submissão de consultas SPARQL

Figura 5.5: Tela de visualização das correspondências semânticas e feedback

5.1.3 Visualização da Topologia da Rede

A visualização da topologia da rede é apresentada também no menu Network. Esteoferece, além da visualização, opções que facilitam o entendimento da topologia como,por exemplo, destacar os clusters de dados em cores diferenciadas e permitir que o usuáriovisualize os tipos de pontos de dados do sistema, de acordo com sua preferência.

Para a implementação da visualização gráfica da topologia da rede, também foi

67


Figura 5.6: Tela de visualização dos pontos de origem de um resultado

utilizada a API Prefuse. Neste caso, a API processa um arquivo recebido no formatoXML e constrói a visualização gráfica da topologia da rede. A tela desta funcionalidadeestá ilustrada na Figura 5.7, observando-se as opções para apresentação da topologia,podendo ser configuradas à direita da tela.

Figura 5.7: Tela para visualização gráfica da topologia rede

Como definido na especificação, o menu Network apresenta também um formulário

68

5.2. ESTUDO DE CASO

de cadastro para usuários UN, caso estes queiram fazer parte da rede. Esta versão dotrabalho ainda não permite a entrada de um novo ponto na rede mas o formulário para ocadastro foi desenvolvido e está ilustrado na Figura B.1 do Apêndice B.

5.1.4 Documentação da Interface

O menu Documentation apresenta a documentação do sistema, conforme especificaçãoda interface apresentada no Capítulo 4. Acessando este menu o usuário pode visualizar oJavadoc do projeto, com detalhes do funcionamento dos módulos da interface desevolvida.A Figura 5.8 ilustra a tela desta funcionalidade.

Figura 5.8: Tela para visualização do Javadoc da interface

5.2 Estudo de Caso

Nesta seção o cenário a ser utilizado na experimentação do sistema será descrito. Inicial-mente, lembra-se que para executar consultas no sistema o usuário poderá acessa-lo deduas maneiras: (1) como usuário UP, que acessa de um ponto de dados participante darede do SPEED; e (2) como um usuário UN, que não acessa de um ponto de dados da

69

5.2. ESTUDO DE CASO

rede. Na primeira opção, como descrito anteriormente, o usuário já inicia com acesso àvisualização da ontologia local do ponto, mas para a segunda opção o usuário deverá pri-meiramente selecionar o domínio desejado e, em seguida, selecionar um ponto de dadospara poder ter acesso a visualização de sua ontologia. Assim, informa-se que o domínio eponto de dados utilizados para a interação dos usuários durante os experimentos foramEducação e PD2378, respectivamente.

Uma vez escolhido o domínio e o ponto de partida é possível, então, ter acesso àontologia que representa o esquema do ponto de dados escolhido. A Figura 5.9 ilustra aontologia local do ponto O1 = LOEdu.owl utilizada neste cenário, com alguns conceitosbásicos do domínio Educação. Para a submissão de consultas durante o experimento, foinecessário criar instâncias na ontologia O1.

Figura 5.9: Ontologia O1= LOEdu.owl do ponto de dados PD 2378

Para os experimentos da interface, efetuou-se uma consulta Q1 = Student tPro ject,que busca por estudantes ou projetos, selecionando os conceitos na visualização gráfica daontologia e o construtor DL disponível na interface. Esta mesma consulta foi submetidade duas maneiras: (1) sem opção de enriquecimento e (2) com uso das variáveis deenriquecimento Generalize e Specialize, seguindo esta ordem de priorização.

Além da consulta anterior, efetuou-se uma consulta Q2, com os mesmos conceitos,mas na opção de SPARQL. Para esta consulta, fez-se uso do template SPARQL Union.A consulta Q2 submetida está ilustrada na Listagem 5.1.

Listagem 5.1: Consulta Q2 com Uso do Template SPARQL Union

SELECT

distinct ?x

FROM

70

5.3. PROCESSAMENTO DE UMA CONSULTA

/www.owl-ontologies.com/Ontology1237476463.owl>

WHERE { {

?x rdf:type /www.owl-ontologies.com/Ontology1237476463.owl#

Student>

} UNION {

?x rdf:type /www.owl-ontologies.com/Ontology1237476463.owl#

Project> } }

5.3 Processamento de uma Consulta

A fim de descrever o processamento de uma consulta submetida no sistema por meioda interface VisualSpeed, este processamento foi ilustrado na Figura 5.10 , onde setemódulos são envolvidos em um fluxo de doze passos:

Figura 5.10: Processamento de uma consulta no sistema SPEED

1. Quando o sistema é inicializado, a interface VisualSPEED envia uma mensagempara o CommunicationManager solicitando a ontologia do ponto de dados que estáacessando o sistema para a submissão de consultas;

71

5.3. PROCESSAMENTO DE UMA CONSULTA

2. O CommunicationManager se comunica com a SPEEDNetwork e solicita a ontolo-gia do ponto que enviou a mensagem;

3. A SPEEDNetwork, por sua vez, envia a ontologia local do ponto para o Communi-

cationManager. Caso a máquina que está acessando o sistema não seja um pontode dados da rede, o usuário terá que escolher um domínio e um ponto de partida,como descrito anteriormente;

4. O CommunicationManager encaminha, então, a ontologia para a interface VisualS-

PEED;

5. Por sua vez, o VisualSPEED encaminha a ontologia para o módulo ViewOntology,que fará uma exibição gráfica da ontologia em forma de grafo ou em hierarquia determos, conforme preferência do usuário;

6. Interagindo com a visualização da ontologia, o usuário seleciona os conceitos queirão compor a consulta no módulo FormQuery;

7. Após a composição a consulta é encaminhada para o módulo QueryManager. Estefará o tratamento da consulta, preparando-a com os parâmetros necessários para aexecução pelo módulo de consultas PSemRef ;

8. Após o tratamento a consulta é encaminhada para o CommunicationManager;

9. O CommunicationManager, por sua vez, encaminha a consulta para o módulo deconsultasPSemRef ;

10. O PSemRef ( executando no ponto de integração do cluster no qual o ponto dedados que submeteu a consulta participa) reformula a consulta submetida paraos pontos de dados e pontos de integração vizinhos. A consulta reformulada étraduzida para uma instrução SPARQL e executada nos pontos de destino. Apósa execução, os resultados da consulta são integrados para retorno ao ponto desubmissão. Juntamente com o resultado, os pontos de integração (componentesda rede do SPEED) enviam informações que identificam os pontos de dados quederam origem a este resultado;

11. A Rede do SPEED encaminha, então, o resultado da consulta para o Communicati-

onManager; e

12. O CommunicationManager, por sua vez, encaminha o resultado da consulta para omódulo ViewResults que é o responsável pela visualização deste.

72

5.4. VISUALIZAÇÃO DOS RESULTADOS DA CONSULTA

5.4 Visualização dos Resultados da Consulta

Para as consultas(Q1 e Q2) descritas anteriormente, os usuários terão os resultados comoilustrados na Figura 5.11, para as consultas submetidas sem uso de variáveis de enri-quecimento, e Figura 5.12, para as consultas enriquecidas. Nestas figuras observa-sea diferença na quantidade de instâncias retornadas para os dois casos pois, enquanto aconsulta não enriquecida retornou apenas duas instâncias (uma para cada conceito con-sultado), a consulta que fez uso das variáveis de enriquecimento retornou seis instâncias(sendo duas destas as mesmas da consulta anterior, e mais quatro instâncias originadaspelo enriquecimento).

Figura 5.11: Resultado das consultas sem uso de variáveis de enriquecimento

Figura 5.12: Resultado das consultas enriquecidas

Visualizando informações mais detalhadas sobre estes resultados, acessados por meiodo ícone ao lado de cada instância de resultado, é possível que o usuário conheça ascorrespondências semânticas que os geraram, caso tenha optado pelo enriquecimento daconsulta. As Figuras 5.13 e 5.14 ilustram as informações semânticas para resultados daconsulta não enriquecida e de uma das instâncias da consulta enriquecida, respectivamente.Analisando as figuras, observa-se que a instância Ana corresponde somente ao conceitoStudent submetido para a consulta. Já as informações da instância FabianaCoelho

demosnstram que esta é do tipo UnderGraduateStudent, resultante do uso da variávelde enriquecimento Generalize, que representa uma correspondência de subconceito(isSubConceptOf ) com o conceito Student, submetido para a consulta.

73

5.5. AVALIAÇÃO DA INTERFACE VISUALSPEED

Figura 5.13: Informações semânticas para o resultado da consulta não enriquecida

Figura 5.14: Informações semânticas para o resultado da consulta enriquecida

5.5 Avaliação da Interface VisualSPEED

Antes de declarar um software pronto para uso, é importante saber se ele apoia adequa-damente os usuários nas suas tarefas e no ambiente em que será utilizado. Assim comotestes de funcionalidade são necessários para se verificar a robustez da implementação, aavaliação de usabilidade da interface é necessária para se analisar a qualidade de uso deum software (Prates and Barbosa, 2003; Rogers et al., 2011).

Nesta seção serão apresentados os mecanismos de avaliação ao qual a interfaceVisualSPEED foi submetida, onde será descrita, inicialmente, a avaliação da usabilidadedas funcionalidades disponíveis para a interação com o usuário, seguida de uma avaliaçãogeral da usabilidade que verifica a qualidade ergonômica da interface desenvolvida.

5.5.1 Avaliação da Usabilidade e Relevância das Funcionalidades

Para avaliar a usabilidade das funcionalidades, foram convidados quarenta e dois usuáriosvoluntários para executarem alguns experimentos com o uso da interface VisualSPEED.Os usuários convidados foram divididos em dois grupos sendo: (1) vinte e quatro volun-tários considerados como usuários especialistas; e (2) dezoito usuários voluntários nãoespecialistas no uso de ontologias, operadores DL e linguagem SPARQL.

74


Como o objetivo central deste trabalho é prover a interação do usuário em ambientesde gerenciamento de dados distribuídos em rede P2P (PDMS) baseados em ontologia,é importante obter a opinião dos usuários sobre o uso das funcionalidades disponíveisno sistema. Nesse sentido, os usuários convidados para a avaliação receberam umroteiro de utilização da interface VisualSPEED com o passo-a-passo dos experimentos aserem executados. Estes experimentos fizeram uso do cenário descrito no início destecapítulo com as consultas sendo submetidas de três maneiras: (1) modo restrito, apenascom inserção de conceitos e operadores DL; (2) modo restrito, utilizando os templatesSPARQL disponíveis na interface; e (3) modo expandido, selecionando variáveis deenriquecimento para as duas consultas anteriores.

Além das consultas propostas no cenário fornecido aos usuários, estes também tiveramtotal liberdade para executar quaisquer consultas adicionais que desejassem antes deexplanarem suas opiniões para avaliação do sistema.

A coleta da opinião de usuários tem por objetivo se obter uma apreciação dos usuáriosem relação ao sistema interativo. Normalmente, deseja-se identificar o nível de satisfaçãodos usuários com o sistema, o que inclui aspectos como: se a aparência estética do sistemaé satisfatória, se o sistema faz aquilo que eles desejam, se tiveram algum problema aousá-lo, e/ou se eles gostariam de (ou pretendem) usá-lo novamente. As principais técnicasutilizadas para se coletar a opinião de usuários são questionários e entrevistas (Rogerset al., 2011; Nicolaci-da Costa, 2001).

Para esta avaliação, foi solicitado aos usuários um levantamento a respeito da VisualS-

PEED por meio de um questionário disponível na Web e ilustrado no Apêndice C. Estequestionário é composto de 12 perguntas que coletam as opiniões dos usuários sobre ausabilidade e relevância das funcionalidades disponíveis para a interação do usuário como sistema.

Os gráficos ilustrados nas Figuras 5.15 e 5.16 exibem os resultados destes experimen-tos para usuários especialistas e não especialistas, respectivamente. Os gráficos informamo percentual de respostas (Ruim, Boa e Excelente) para as perguntas do questionário,onde cada uma destas está relacionada com uma funcionalidade do sistema. Os dadosbrutos das respostas obtidas no questionário bem como os comentários e sugestões dosusuários estão no Apêndice D.

Analisando os gráficos, observamos que a maioria dos usuários, especialistas e nãoespecialistas, responderam ao questionário indicando que estavam satisfeitos com asfuncionalidades disponíveis no sistema. Em uma grande maioria das perguntas foramobtidas respostas entre Boa e Excelente, confirmando que a interface proporciona ao

75


Figura 5.15: Gráfico com percentuais de avaliação das funcionalidades por usuários espe-cialistas

Figura 5.16: Gráfico com percentuais de avaliação das funcionalidades por usuários nãoespecialistas

usuário uma interação simples e objetiva com este tipo de sistema.Poucos usuários não especialistas classificaram negativamente funcionalidades como:

composição de consulta SPARQL, uso de variáveis de enriquecimento e visualização deinformações semânticas de resultados de consultas. Mas, estas respostas se justificamcom o fato de estas funcionalidades não terem tanta importância ou significado para estesusuários, por mais que tenham conseguido utilizá-las devido à facilidade proporcionada

76


pela interface. Visto que este tipo de usuário não possui conhecimento sobre ontologias elinguagem de consulta SPARQL. Assim, estas respostas não foram consideradas opiniõesnegativas para o sistema, mas sim como comprovação de que o objetivo de promoveruma interação simples e objetiva independente do tipo de usuário foi alcançado.

5.5.2 Avaliação da Usabilidade e Qualidade Ergonômica da Inter-face

Para realizar uma inspeção da qualidade ergonômica da interface com o usuário, foiutilizado o serviço Web ErgoList. Este foi desenvolvido pelo laboratório LabIUtil, quepropõe inspeções de usabilidade por checklists (Cybis et al., 2003).

As inspeções de usabilidade por checklists são vistorias baseadas em listas de verifi-cação, através das quais profissionais, não necessariamente especialistas em ergonomiacomo, por exemplo, programadores e analistas, diagnosticam rapidamente problemasgerais e repetitivos das interfaces (Jeffries et al., 1991).

Neste tipo de técnica, ao contrário das avaliações heurísticas, são as qualidades daferramenta (checklists) e não dos avaliadores, que determinam as possibilidades paraa avaliação. Checklists bem elaborados devem produzir resultados mais uniformes eabrangentes, em termos de identificação de problemas de usabilidade, pois os inspetoressão conduzidos no exame da interface através de uma mesma lista de questões a respondersobre a usabilidade do projeto. Os resultados obtidos por meio dessa técnica dependementão da organização e do conteúdo, geral ou específico, dessas ferramentas.

Dominique Scapin realizou um estudo (Scapin, 1990) visando a organização dosconhecimentos sobre ergonomia de interfaces homem-computador, de modo a torná-los facilmente disponíveis, tanto para especialistas como para não especialistas nessadisciplina. O sistema de critérios definido por Scapin resulta desse esforço e visa facilitara recuperação de conhecimento ergonômico.

Os critérios elementares que determinam a ergonomia de uma interface homem-computador, aos quais estão associados os checklists do ErgoList (LabUtil, 2012) são emnúmero de dezoito, conforme descrição a seguir:

1. Presteza - Esse critério engloba os meios utilizados para levar o usuário a realizardeterminadas ações como, por exemplo, entrada de dados. Esse critério englobatambém todos os mecanismos ou meios que permitem ao usuário conhecer asalternativas, em termos de ações, conforme o estado ou contexto nos quais elese encontra. A presteza diz respeito igualmente às informações que permitem ao

77


usuário identificar o estado ou contexto no qual ele se encontra, bem como asferramentas de ajuda e seu modo de acesso;

2. Agrupamento por Localização - diz respeito ao posicionamento relativo dos itens,estabelecido para indicar se eles pertencem ou não a uma dada classe, com caracte-rísticas gráficas semelhantes, ou para indicar diferenças entre classes. Esse critériotambém diz respeito ao posicionamento relativo dos itens dentro de uma classe;

3. Agrupamento por Formato - diz respeito mais especificamente às característicasgráficas (formato, cor, entre outras) que indicam se itens pertencem ou não a umadada classe, ou que indicam ainda distinções entre classes diferentes ou distinçõesentre itens de uma dada classe;

4. Feedback Imediato - diz respeito às respostas do sistema às ações do usuário. Taisentradas podem ir do simples pressionar de uma tecla até uma lista de comandos.Em todos os casos, respostas do computador devem ser fornecidas, de forma rápida,com passo (timing) apropriado e consistente para cada tipo de transação. De todomodo, uma resposta rápida deve ser fornecida com informações sobre a transaçãosolicitada e seu resultado;

5. Legibilidade - diz respeito às características léxicas das informações apresentadasna tela que possam dificultar ou facilitar a leitura dessa informação (brilho docaractere, contraste letra/fundo, tamanho da fonte, espaçamento entre palavras,espaçamento entre linhas, espaçamento de parágrafos, comprimento da linha, entreoutras). Por definição, o critério Legibilidade não abrange mensagens de erro oude feedback;

6. Concisão - diz respeito à carga perceptiva e cognitiva de saídas e entradas indi-viduais. Por definição, a Concisão não diz respeito às mensagens de erro e defeedback;

7. Ações Mínimas - diz respeito à carga de trabalho em relação ao número de açõesnecessárias à realização de uma tarefa. O que tem-se aqui é uma questão de limitartanto quanto possível o número de passos que o usuário deve empregar;

8. Densidade Informacional - diz respeito à carga de trabalho do usuário de umponto de vista perceptivo e cognitivo, com relação ao conjunto total de itens deinformação apresentados aos usuários, e não a cada elemento ou item individual;

78


9. Ações Explícitas do Usuário - se refere às relações entre o processamento pelocomputador e as ações do usuário. Essa relação deve ser explícita, isto é, ocomputador deve processar somente aquelas ações solicitadas pelo usuário e apenasquando solicitado a fazê-lo;

10. Controle do Usuário - se refere ao fato de que os usuários deveriam estar sempreno controle do processamento do sistema (por exemplo, interromper, cancelar,suspender e continuar). Cada ação possível do usuário deve ser antecipada e opçõesapropriadas devem ser oferecidas;

11. Flexibilidade - se refere aos meios colocados à disposição do usuário que lhepermitem personalizar a interface, a fim de levar em conta as exigências da tarefa,de suas estratégias ou seus hábitos de trabalho. Ela corresponde também ao númerodas diferentes maneiras à disposição do usuário para alcançar um certo objetivo.Trata-se, em outros termos, da capacidade da interface de se adaptar às variadasações do usuário;

12. Consideração da experiência do usuário - diz respeito aos meios implementadosque permitem que o sistema respeite o nível de experiência do usuário;

13. Proteção contra os erros - diz respeito aos mecanismos empregados para detectar eprevenir os erros de entradas de dados, comandos, possíveis ações de consequênciasdesastrosas e/ou não recuperáveis;

14. Qualidade das mensagens de erro - refere-se à pertinência, à legibilidade e àexatidão da informação dada ao usuário, sobre a natureza do erro cometido (sintaxe,formato, entre outros) e sobre as ações a executar para corrigi-lo;

15. Correção dos erros - diz respeito aos meios colocados à disposição do usuário como objetivo de permitir a correção de seus erros;

16. Consistência - refere-se à homogeneidade e coerência da interface, ou seja, à formana qual as escolhas na concepção da interface (códigos, denominações, formatos,procedimentos, entre outros) são conservadas idênticas, em contextos idênticos, ediferentes, em contextos diferentes;

17. Significados - diz respeito à adequação entre o objeto ou a informação apresentadaou pedida e sua referência. Códigos e denominações significativas possuem umaforte relação semântica com seu referente. Termos pouco expressivos para o usuário

79


podem ocasionar problemas de condução, podendo levá-lo a selecionar uma opçãoerrada; e

18. Compatibilidade - refere-se ao acordo que possa existir entre as características dousuário (memória, percepção, hábitos, competências, idade, expectativas, entreoutras) e as tarefas, de uma parte, e a organização das saídas, das entradas e dodiálogo de uma dada aplicação, de outra. Ela diz respeito também ao grau desimilaridade entre diferentes ambientes e aplicações.

Figura 5.17: Gráfico com percentuais individuais de adequação aos critérios de usabilidadedo ErgoList

O gráfico que compõe a Figura 5.17 ilustra os percentuais de conformidade da inter-face desenvolvida para cada um dos critérios avaliados nos checklists. Para a construçãodo gráfico, foi utilizado o laudo final emitido pelo serviço Web ErgoList que contabilizaas respostas das questões em: questões conformes (questões ergonômicas atendidas pela

80


interface desenvolvida); questões não conformes (questões ergonômicas que a interfacedesenvolvida não atende corretamente); e questões não aplicáveis (questões que tratamde especificidades ergonômicas não necessárias à interface desenvolvida).

Figura 5.18: Gráfico de adequação geral da interface desenvolvida à avaliação do ErgoList

Como se pode observar no gráfico, o critério FeedBack apresenta um percentual denão conformidade. Este se deve ao fato de o sistema ainda não fornecer um histórico doscomandos utilizados por um usuário em uma sessão de utilização do referido sistema.Para os demais critérios, além do percentual de conformidade, observa-se também ospercentuais de questões não aplicáveis que se destinam, em geral, a questões sobreapresentação e uso de valores numéricos não aplicáveis à interface desenvolvida.

Além do gráfico com os percentuais individuais para cada critério considerado naavaliação, foi elaborado um gráfico que ilustra a avaliação geral da interface de acordocom os totais de conformidade informados no laudo final emitido pelo serviço WebErgoList. Este gráfico está ilustrado na Figura 5.18 onde pode-se observar que a interfaceestá, de forma geral, em conformidade com os critérios de usabilidade esperados peloErgoList.

81


5.6 Considerações

Neste capítulo foram tratados os aspectos de implementação da abordagem adotada,apresentando todas as telas que constituem a VisualSPEED , com comentários sobre cadaum de seus componentes em detalhes. As principais telas de nossa ferramenta envolvema submissão de consultas, a visualização de informações semânticas dos resultados deconsultas e a exibição gráfica da topologia da rede em uma interface visual, excetuando-sea opção para submissão de consultas SPARQL.

A fim de verificar a validade da abordagem adotada, foram feitos experimentos coma interface VisualSPEED por meio de um estudo de caso, descrevendo um cenário deutilização da interface desenvolvida com casos para submissão de consultas e utilizaçãodas demais funcionalidades disponíveis.

Além da implementação e estudo de caso, foi apresentada também a avaliação dainterface desenvolvida de acordo com critérios de usabilidade e satisfação dos usuárioscom relação às funcionalidades disponíveis na referida interface. Em ambas as avaliações,a interface obteve um bom desempenho demostrando adequação não somente aos critériosde usabilidade e ergonomia esperados, mas também na satisfação dos usuários paraa formulação e submissão de consultas, bem como na visualização de resultados einformações detalhadas que o sistema oferece sobre estes e a rede.

82

6Conclusões e Trabalhos Futuros

Ambientes de Peer Data Management System (PDMS) possuem características comoo fato de serem altamente dinâmicos em uma infraestrutura de pontos distribuídos,heterogêneos e autônomos. Muitos destes PDMS baseados em semântica são compostospor pontos de dados cujos esquemas exportados são representados por ontologias. Devidoa essas características, a interação do usuário com esses tipos de sistemas pode setornar uma tarefa difícil, principalmente para a formulação e execução de consultas.Considerando isto, seria ideal que esses tipos de sistema possuissem interfaces queproporcionassem uma interação simples e objetiva com os usuários.

A VisualSPEED foi desenvolvida e validada no ambiente de um PDMS baseado emontologias chamado SPEED (Semantic PEEr-to-Peer Data Management System), o qualadota uma arquitetura de super-peers. A abordagem adotada apresenta as ontologiasgraficamente e em hierarquia de conceitos, permitindo a formulação de consultas por meioda manipulação desta visualização da ontologia, selecionando os conceitos desejados paraa consulta e combinando-os com operadores da Description Logic (DL) ou com templates

SPARQL (SPARQL Protocol and RDF Query Language), disponíveis na interface.Ainda para a execução de consultas, é possível melhorar os resultados obtidos enri-

quecendo a consulta submetida com o uso de variáveis que representam relacionamentosentre os conceitos da consulta (aproximação, subconceito, superconceito e agregação).Além da formulação e submissão de consultas, a interface possibilita uma visualizaçãoorganizada dos resultados com informações sobre as correspondências semânticas que osgeraram e os pontos de origem identificados em um esquema gráfico da rede.

A VisualSPEED foi especificada, seguindo técnicas de análise e prototipação, im-plementada e avaliada. Para esta avaliação, foram realizados experimentos com doistipos de usuário (especialista e não especialista) e verificação de conformidade com oscritérios de usabilidade. Analisados os resultados obtidos das avaliações, concluiu-se que

83

6.1. CONTRIBUIÇÕES

a VisualSPEED é uma interface visual que apresenta as funcionalidades e transparêncianecessárias para interação do usuário com um PDMS.

6.1 Contribuições

As contribuições deste trabalho são descritas a seguir.

• A definição de uma interface para PDMS que possibilita a interação de vários tiposde usuário;

• A formulação de consultas de forma visual por meio da manipulação da visualiza-ção gráfica das ontologias;

• A melhoria da utilização de operadores da DL, templates SPARQL e variáveis deenriquecimento para composição de consultas;

• A visualização dos resultados de maneira organizada permitindo o acesso a infor-mações detalhadas sobre estes;

• A exibição das correspondências semânticas que geraram os resultados das consul-tas;

• A identificação do ponto de origem dos resultados na topologia da rede;

• A visualização gráfica da topologia da rede com todos os pontos e comunidadessemânticas que compõem o sistema; e

• A validação da abordagem proposta com a implementação da VisualSPEED, alémdas avaliações e experimentos realizados.

6.2 Trabalhos Futuros

Considera-se que o presente trabalho atingiu o objetivo proposto. Porém, a abordagemVisualSPEED merece algumas extensões e melhorias na forma de trabalhos futuros, osquais são especificados a seguir:

• Desenvolvimento de ajuda e guia de utilização do usuário - o sistema disponibilizauma documentação dos módulos desenvolvidos para a interface, mas não possuium guia de utilização com o passo-a-passo para utilização das funcionalidades

84

6.2. TRABALHOS FUTUROS

disponíveis nem exibe instruções de ajuda que complementem as informações jádisponíveis na tela;

• Formulação de consultas com base nas propriedades - esta versão do trabalho consi-dera apelas os conceitos das ontologias par a formulação de consultas. Necessita-seque sejam consideradas as propriedades dos conceitos existentes na ontologia parauma especificação mais detalhada de consultas;

• Impressão e exportação de resultados - esta versão do trabalho ainda não disponi-biliza um mecanismo que possibilite aos usuários obter os resultados de maneiraimpressa ou em documento digital, exportando-os por meio da interface;

• Maximização da tabela de resultados - esta versão do trabalho apresenta os resulta-dos de consultas em uma tabela. Visando escalabilar esta funcionalidade do sistemapara visualização de um volume maior dados necessita-se desenvolver um meca-nismo que permita ao usuário maximizar a tabela de resultados para visualizaçãoem tela cheia;

• Indicação do ponto a ser escolhido pelo usuário UN - nesta versão do trabalho ousuário não participante da rede escolhe um ponto de partida para submissão deconsultas de forma aleatória, sem nenhuma recomendação do sistema. Necessita-seimplementar uma funcionalidade para que o sistema recomende ao usuário o melhorponto a ser escolhido baseado em informações como poder de processamento,memória, disponibilidade, entre ouras;

• Guardar histórico de utilização - como apontado pela avaliação, esta versão do tra-balho não disponibiliza ao usuário um histórico dos comandos utilizados por ele emuma seção do sistema, necessitando ainda da implementação desta funcionalidade;

• Obtenção de dados reais - esta versão do trabalho considera para o resultados deconsultas apenas as instâncias presentes nas ontologias utilizadas para representaçãodos esquemas de dados dos pontos. É necessário que se obtenha, também pararesultados de consulta, os dados reais dos pontos considerando as instâncias dosbancos de dados compartilhados, apresentando-os da melhor forma na interface;

• Internacionalização da interface - esta versão do trabalho apresenta a interface emapenas um idioma (inglês). É desejável que se implemente a internacionalizaçãoda interface permitindo ao usuário uma interação com uma interface apresentadaem diversos idiomas; e

85

6.2. TRABALHOS FUTUROS

• Implantação e teste da interface desenvolvida em um ambiente real - nesta versãodo trabalho a interface foi validada no ambiente do sistema SPEED executando emrede local com 2 peers semânticos e 5 peers de dados. Necessita-se ainda implantaresta interface em um ambiente com uma quantidade maior de peers executando emredes dististas e interligados por meio da Internet, caracterizando um ambiente realde execução.

86

Referências Bibliográficas

Adjiman, P., Goasdoue, F., and Rousset, M. (2007). Somerdfs in the semantic web.chapter SomeRDFS in the semantic web, pages 158–181. Springer-Verlag, Berlin,Heidelberg. 25

ARQ (2011). Arq - a sparql processor for jena. http://jena.sourceforge.net/ARQ/ .Acessado em dezembro de 2011. 21

Arruda, T. (2010). PSemRef: personalização de consultas em ambientes distribuídos e

dinâmicos. Master’s thesis, Federal University of Pernambuco (UFPE/CIn). 36, 42, 47,57, 58

Arruda, T., Souza, D., and Salgado, A. C. (2010). Psemref: personalized query reformu-lation based on user preferences. In Proceedings of the 12th International Conference

on Information Integration and Web-based Applications & Services, iiWAS ’10,pages 683–686, New York, NY, USA. ACM. 53

Athanasis, N., Christophides, V., and Kotzinos, D. (2004). Generating on the fly queriesfor the semantic web: The ics-forth graphical rql interface (grql). In In Proc. of ISWC

2004, pages 486–501. xi, 7, 23, 25, 27, 33

Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D., and Patel-Schneider, P. F.(2003). The Description Logic Handbook - Theory, Implementation, and Applications.Cambridge University Press, New York, NY, USA. 20

Beneventano, D., Bergamaschi, S., and Guerra, F. (2007). The sewasie network ofmediator agents for semantic search. Computer, 13(12), 1936–1969. 25, 27, 28, 35

Berners-Lee, T., Hendler, J., and Lassilaq, O. (2001). The semantic web. Scientific

American, 284(5), 34–43. 1

Blanco, R., Ahmed, N., Hadaller, D., Sung, L. G. A., Li, H., and Soliman, M. A. (2006).A survey of data management in peer-to-peer systems. 1, 3, 16

Brickley, D. and Guha, R. V. (2000). Resource description framework (rdf) schemaspecification. 19

Broekstra, J. and Kampman, A. (2004). Serql: An rdf query and transformation language.21

87

REFERÊNCIAS BIBLIOGRÁFICAS

Buscaldi, D., Rosso, P., and Sanchis, E. (2007). A wordnet-based indexing technique forgeographical information retrieval. In C. Peters, P. Clough, F. Gey, J. Karlgren, B. Mag-nini, D. Oard, M. de Rijke, and M. Stempfhuber, editors, Evaluation of Multilingual

and Multi-modal Information Retrieval, volume 4730 of Lecture Notes in Computer Sci-

ence, pages 954–957. Springer Berlin - Heidelberg. 10.1007/978-3-540-74999-8-122.24

Castano, S., Ferrara, A., Montanelli, S., and Zucchelli, D. (2003). Helios: a generalframework for ontology-based knowledge sharing and evolution in p2p systems. InProceedings of the 14th International Workshop on Database and Expert Systems

Applications, DEXA ’03, pages 597–, Washington, DC, USA. IEEE Computer Society.25

Catarci, T., Costabile, M. F., Levialdi, S., and Batini, C. (1997). Visual query systems fordatabases - a survey. Journal of Visual Languages and Computing, 8, 215–260. 6, 7

CloudGarden (2012). Jigloo swt/swing gui builder for eclipse and websphere. Disponívelem: <http://www.cloudgarden.com/jigloo/>. 63

Cybis, W. d. A., Dyck, A. F., de Oliveira, R., Pagliuso, P. B. B., Tambascia, C. d. A.,Villas-Boas, A. L. d. C., and Freitas, M. (2003). Approach for the development ofsystematic and productive verifying lists of usability. In Proceedings of the Latin

American conference on Human-computer interaction, CLIHC 03, pages 29–40, NewYork, NY, USA. ACM. 77

Dix, A., Finlay, J. E., Abowd, G. D., and Beale, R. (2003). Human-Computer Interaction

(3rd Edition). Prentice Hall, 3 edition. xi, 7, 8, 9, 10, 12

Eclipse (2012). Eclipse - integrated development environments. Disponível em:<http://www.eclipse.com/>. 63

Fadhil, A. and Haarslev, V. (2007). Ontovql - a graphical query language for owlontologies. In D. Calvanese, E. Franconi, V. Haarslev, D. Lembo, B. Motik, A.-Y.Turhan, and S. Tessaris, editors, Description Logics, volume 250 of CEUR Workshop

Proceedings. 7

Fellbaum, C. (1998). WordNet - An Electronical Lexical Database. The MIT Press,Cambridge, MA. 24

88


Makela, E., Hyvonen, E., Saarela, S., and Viljanen, K. (2004). Ontoviews - a tool forcreating semantic web portals. In IN: PROCEEDINGS OF THE THIRD INTERNATION

SEMANTIC WEB CONFERENCE (ISWC2004), pages 797–811. Springer Verlag. xi,23, 30, 31, 35

Mandreoli, F., Martoglia, R., Penzo, W., Sassatelli, S., and Villani, G. (2007). Sunrise:Exploring pdms networks with semantic routing indexes. xi, 32, 35

Mandreoli, F., Martoglia, R., Sassatelli, S., Villani, G., and Penzo, W. (2008). Buildinga pdms infrastructure for xml data sharing with sunrise. In Proceedings of the 2008

EDBT workshop on Database technologies for handling XML information on the web,DataX ’08, pages 51–59, New York, NY, USA. ACM. 25

McGuinness, D. L. and van Harmelen, F. (2004). Owl - web ontology language over-view. W3C recommendation, W3C. http://www.w3.org/TR/2004/REC-owl-features-20040210/. 18, 19

Miller, E. (1998). An introduction to the resource description framework. D-Lib Magazine.19

Milojicic, D. S., Kalogeraki, V., Lukose, R., Nagaraja, K., Pruyne, J., Richard, B., Rollins,S., and Xu, Z. (2003). Peer-to-peer computing. Technical report. 2, 12

Montanelli, S. and Castano, S. (2008). Semantically routing queries in peer-basedsystems: The h-link approach. Knowl. Eng. Rev., 23, 51–72. 25

Mozila (2011). Pencil project. http://pencil.evolus.vn/en-US/Home.aspx. Acessado emnovembro de 2001. 55

Nicolaci-da Costa, A. M. (2001). Gerando conhecimento sobre os homens, mulheres ecrianças que usam computadores: algumas contribuições da psicologia clínica. Anais

do IV Workshop sobre Fatores Humanos em Sistemas Computacionais (IHC 2001),pages 120–131. 75

Norman, D. A. (1994). Things That Make Us Smart: Defending Human Attributes In The

Age Of The Machine. Basic Books. 8

Noy, N. F. and Mcguinness, D. L. (2002). Ontology development 101: A guide to creatingyour first ontology. Technical report. 3, 18

90


NUDIST (2011). Software for qualitative research. http://www.qsrinternational.com/.Acessado em novembro de 2001. 11

Oracle (2012). Java language. Dsponível em: <http://www.java.com/>. 63

Pires, C. (2009). Ontology-based Clustering in a Peer Data Management System. Ph.D.thesis, Tese de Doutorado, Centro de Informática - UFPE. xi, 3, 11, 17, 35, 36, 37, 41,42

Prates, R. O. and Barbosa, S. D. J. (2003). Avaliação de interfaces de usuário - conceitose métodos. Jornada de Atualização em Informática do Congresso da Sociedade

Brasileira de Computação. Campinas: SBC, v. 2, p. 245–293. 11, 74

Prefuse (2011). Prefuse information visualization toolkit. Disponível em:<http://prefuse.org/>. 64

Pressman, R. (2009). Software Engineering: A Practitioners Approach. McGraw-HillScience/Engineering/Math, 7 edition. 53

Prud’hommeaux, E. and Seaborne, A. (2008). Sparql query language for rdf. W3c re-commendation, W3C. http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/.1, 21

Rogers, Y., Sharp, H., and Preece, J. (2011). Interaction Design: Beyond Human -

Computer Interaction. Wiley, 3 edition. 52, 55, 74, 75

Scapin, D. L. (1990). Organizing human factors knowledge for the evaluation and designof interfaces. Int. J. Hum. Comput. Interaction, 2(3), 203–229. 77

Schneider, M. (2009). Owl 2 web ontology language rdf-based semantics. W3C re-commendation, W3C. http://www.w3.org/TR/2009/REC-owl2-rdf-based-semantics-20091027/. 36

Seaborne, A. (2004). Rdql - a query language for rdf. Technical report, HP LabsBristol. http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ . Acessadoem dezembro de 2011. 21

SEWASIE (2011). Semantic webs and agents in integrated economies.http://www.sewaise.org. Acessado em novembro de 2001. xi, 28, 29, 35

91


Shadbolt, N., Berners-Lee, T., and Hall, W. (2006). The semantic web revisited. IEEE

Intelligent Systems, 21, 96–101. 20

Shneiderman, B. and Plaisant, C. (2010). Designing the User Interface - Strategies for

Effective Human-Computer Interaction (5. ed.). Addison-Wesley. 7

Silva, J. T. (1998). Uma Interface Visual para Modelos de Bancos de Dados Orientados

a Objetos com Suporte para Versões. Master’s thesis, Universidade Federal do RioGrande do Sul (UFRGS). 6

Souza, D. (2009). Using Semantics to Enhance Query Reformulation in Dynamic

Distributed Environments. Ph.D. thesis, Tese de Doutorado, Centro de Informática -UFPE. xi, 21, 37, 38, 39, 40, 42, 43, 44, 45

SQLOrg (2012). Structured query language (sql). http://www.sql.org/. 1

Stanford (2012). Protégé-owl api. Disponível em:<http://protege.stanford.edu/plugins/owl/api/>. 63

Stojanovic, N., Studer, R., and Stojanovic, L. (2004). An approach for step-by-step queryrefinement in the ontology-based information retrieval. Web Intelligence, IEEE / WIC /

ACM International Conference on, 0, 36–43. 24

Tatarinov, I. and Halevy, A. (2004). Efficient query reformulation in peer data manage-ment systems. 17

Thompson, H. (1997). Extensible markup language (xml).http://www.w3.org/XML/Core/. 19

W3C, R. W. G. (2004). Resource description framework (rdf). http://www.w3.org/RDF/ .Acessado em dezembro de 2011. 19, 20

Xiao, H. (2006). Query Processing for Heterogeneous Data Integration using Ontologies.Ph.D. thesis, University of Illinois, Chicado, USA. 18

Yang, B. and Garcia-Molina, H. (2003). Designing a super-peer network. In ICDE, pages49–. 37

92

Apêndices

93

AProtótipos de Alta Fidelidade da Interface

VisualSPEED

Figura A.1: Protótipo da tela principal do sistema SPEED

94

Figura A.2: Protótipo da tela de documentação do sistema SPEED

Figura A.3: Protótipo de tela para o princípio da submissão de consultas por usuário UN

95

Figura A.4: Protótipo para visualização das correspondências semânticas que geraram osresultados e feedback

Figura A.5: Protótipo da tela de visualização da topologia da rede por usuário UP

96

BTelas Implementadas da VisualSPEED

Figura B.1: Tela de cadastro de um novo ponto

97

CQuestionário para Avaliação das

Funcionalidades da InterfaceVisualSPEED

98

Figura C.1: Questionário de Avaliação do Usuário(Página 1)

99

Figura C.2: Questionário de Avaliação do Usuário(Página 2)

100

DRespostas do Questionário de Avaliação

das Funcionalidades da VisualSPEED

s

101

Quadro D.1: Totais de Respostas Obtidas por Usuários Não Especialistas

Funcionalidades Avaliadas por Pergunta do Questionário Excelente Boa Ruim1 - Seleção de domínios e pontos de partida 4 14 02 -Formulario para entrada de um novo ponto na rede 6 12 03 -Visualização da ontologia em forma de grafo 12 6 04 - Visualização da ontologia em hierarquia de conceitos 8 10 05 - Visualização da topologia da rede 10 8 06 - Composição de consultas e o uso de operadores DL 6 12 07 - Composição de consultas e o uso de templates SPARQL 6 10 28 - Uso e priorização das variáveis de enriquecimento 8 6 49 - Visualização de resultados de consulta 6 12 010 - Visualização de informaçoes semânticas de resultados 10 6 211 - Feedback sobre os resultados de consultas 6 12 012 - Identificação da origem de um resultado 6 12 0

Comentários1 na minha opinião os resultados deveria ser mais exposto para ser visualizado.2 Excelente sistema de consulta, parabéns.3 Os diagramas que mostram as ontologias não estão inicialmente posicionados ao

centro, havendo sempre a necessidade de reposicionar o diagrama para podervisualizar todos os elementos. Sugiro que seja revista esta exibição do diagrama deforma a facilitar a interação do usuário com o mesmo e, consequentemente, com osistema.

4 A visualização grafica da ontologia fica ruim quando se tem muitos nós.5 faltam mensagens de ajuda para facilitar o uso do sistema6 O VisualSPEED é bastante intuitivo, com layout amigável e bastante objetivo.Senti

falta apenas de um HELP (opção de ajuda) para auxiliar melhor na consultaSPARQL, mesmo a ferramenta trazendo a estrutura da consulta desejada, seriaimportante conceituar o que cada opção da consulta faz.

102

Quadro D.2: Totais de Respostas Obtidas por Usuários Especialistas

Funcionalidades Avaliadas por Pergunta do Questionário Excelente Boa Ruim1 - Seleção de domínios e pontos de partida 24 0 02 -Formulario para entrada de um novo ponto na rede 24 0 03 -Visualização da ontologia em forma de grafo 24 0 04 - Visualização da ontologia em hierarquia de conceitos 16 8 05 - Visualização da topologia da rede 24 0 06 - Composição de consultas e o uso de operadores DL 18 6 07 - Composição de consultas e o uso de templates SPARQL 24 0 08 - Uso e priorização das variáveis de enriquecimento 24 0 09 - Visualização de resultados de consulta 24 0 010 - Visualização de informaçoes semânticas de resultados 24 0 011 - Feedback sobre os resultados de consultas 24 0 012 - Identificação da origem de um resultado 24 0 0

103

andreza

Typewritten Text

andreza

Typewritten Text

andreza

Typewritten Text

Andrêza Leite de Alencar - repositorio.ufpe.br · Estes ambientes possuem características como o...

Documents

Transcript of Andrêza Leite de Alencar - repositorio.ufpe.br · Estes ambientes possuem características como o...