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 pelo usuário no módulo FormQuery deixando-as em um formato que possam, então, ser submetidas e compreendidas pelo módulo de consultas do SPEED. Além disso, efetua o processamento dos resultados de consulta traduzindo-os para um formato compreensível ao 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 de interação com o sistema SPEED. Esse módulo funciona como um proxy entre os módulos da camada de interação com o usuário e os demais componentes do sistema SPEED necessá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 sistema deve estar de acordo. Existem diferentes tipos de requisitos:
• Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar;
4.2. REQUISITOS ESTABELECIDOS PARA A INTERFACE VISUALSPEED
• Os requisitos de dados captam tipo, volatilidade, tamanho, persistência, precisão e valor das quantidades de dados exigidos;
• Os requisitos de contexto ou ambiente referem-se à circunstância em que se espera que 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) e as medidas associadas para um produto em particular (Rogers et al., 2011). Analisando a arquitetura apresentada na Figura 4.1 é possível observar algumas características e funcionalidades desejáveis para a interface de interação do sistema SPEED. Primeiro, tendo em vista a submissão de consultas, o sistema precisa oferecer uma 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 necessidades e privilégios de seu perfil. Terceiro, por tratar-se de um ambiente distribuído, como mostrado anteriormente, é desejável que se possua uma interface para visualização gráfica da topologia da rede, bem como um formulário de cadastro que possibilite a entrada de novos pontos de dados, caso o sistema esteja sendo acessado por um usuário que ainda não faça parte da rede.
A partir das características gerais apresentadas foram estabelecidos os Requisitos Funcionais (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 na representação gráfica do esquema de dados dos pontos.
4.2. REQUISITOS ESTABELECIDOS PARA A INTERFACE VISUALSPEED
RF7 - Interpretar e traduzir as consultas fornecidas pelo usuário em comandos SPARQL para 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 a visualizaçã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 consulta submetida 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 implementadas no 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 este trabalho.
Requisitos funcionais são melhor descritos em um diagrama de casos de uso. O diagrama de casos de uso é um diagrama da Unified Modeling Language (UML) cujo objetivo é 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ário definir os tipos de usuário do mesmo: Usuário Participante da Rede (UP) e Usuário não Participante da Rede (UN), possibilitando que usuários externos possam acessar o sistema.
O usuário UP é integrante de uma comunidade semântica da rede. Este ponto de dados representa um provedor compartilhando dados com outros pontos de dados no sistema.
4.2. REQUISITOS ESTABELECIDOS PARA A INTERFACE VISUALSPEED
O usuário UN é aquele que interage com o sistema por meio de um computador que não é ponto de dados da rede e não compartilha dados com o sistema. Este tipo de usuário representa um consumidor dos dados compartilhados no sistema e, como não compartilha dados com a rede, necessita primeiramente escolher um domínio e um ponto que seja provedor 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 um cadastro, caso tenha interesse de compartilhar seus dados com a rede.