CAP ÍTULO 4
INTERFACES PARA ÁLGEBRA DE MAPAS
Segundo Oliveira (1996), "em Sistemas de Informações Geográficas (SIG), o modelo
conceitual não pode ser usado como modelo de representação para a interface (como
ocorre, por exemplo, com interfaces de bancos de dados relacionais). A modelagem de
dados em um SIG envolve conceitos espaciais usualmente expressos em estruturas de
baixo nível, que não são adequadas para a cognição espacial humana”. Mesmo assim, os
SIGs devem oferecer ao usuário as funcionalidades necessárias para que este possa
expressar seus modelos, fórmulas e procedimentos da maneira mais próxima possível da
sua percepção dos fenômenos espaciais.
O objetivo deste Capítulo é estabelecer os requisitos para o projeto de interface para
Álgebra de Mapas para o SPRING, serão revisados alguns conceitos de projetos de interface
usuário-computador, serão apresentados os paradigmas de interface e sua aplicação em álgebra
de mapas e serão revisadas algumas interfaces para álgebra de mapas existentes no mercado
ou propostas na literatura.
4.1
Projeto de Interfaces Usuário-Computador
No entender de Eberts(1994), “o projetista de interface deve conhecer a atividade cognitiva
do usuário a fim de projetar interfaces efetivas e fáceis de usar” Aspectos psicológicos da
teoria de cognição humana devem ser aplicados em Interfaces Usuário Computador (IUC)
para fazer com que o processamento das informações por parte do usuário seja rápido e
eficiente, reduzindo dúvidas e ambigüidades. O Projeto de Interface deve se basear no
Modelo Conceitual do sistema, concebido em uma fase anterior no processo de engenharia do
software, e no Modelo Mental do usuário, que é a forma como o usuário irá conceber o
funcionamento do sistema, como é ilustrado na Figura 4.1:
55
Modelo Conceitual
Modelo Metal
Projeto de Interface
Figura 4.1 - Processo de desenvolvimento de Projeto de Interfaces.
Fonte: Adaptado de Eberts (1994).
O modelo conceitual deve estar o mais próximo possível do modelo mental, cabe ao projeto de
interface ajudar o usuário a formar um modelo mental conciso e coerente com o sistema. Uma
forma de fazer com que o modelo mental do usuário seja conciso é utilizando-se de
analogias e metáforas. O uso eficiente deste recurso visa minimizar o processo de
familiarização com o sistema. Para isto são escolhidos comandos, figuras e relacionamentos
semelhantes a situações rotineiras da atividade do usuário, para representar dados,
operadores, opções e relacionamentos no sistema informatizado.
4.2
Paradigmas de Interfaces para Álgebra de Mapas
Nesta seção analisaremos paradigmas de interfaces aplicáveis a álgebra de mapas, os quais
são: interfaces por linha de comando ou linguagem de programação; interface por menus e formulários
e interfaces de manipulação direta. Foge ao escopo deste trabalho interfaces por linguagem
natural e comandos de voz e demais inovações que envolvem outra linha de pesquisa que
não a de interface gráficas com o usuário, ou Graphical User Interface (GUI).
4.2.1
Linhas de Comandos e Linguagens de Programação
Visão Geral
Neste categoria de interface, os sistemas oferecem uma ou mais linhas em branco onde o
usuário pode digitar uma expressão (no caso de linguagens de programação) ou comando
(no caso de interfaces por linha de comandos), informando ao sistema aquilo que pretende
que se faça. Para preencher estas linhas em branco, o usuário deve conhecer a sintaxe dos
comandos e expressões da linguagem.
Neste paradigma de interface, seu projetista tenta estabelecer metáforas através do uso de
expressões do jargão do usuário, com a finalidade de aproximar-se da sua linguagem
natural. "Na prática de SIGs este processo é prejudicado, muitas vezes, porque a estrutura
de dados acaba por influenciar na definição da linguagem, tornando necessário o uso de
termos como vector ou grid" (Lucena et al., 1997).
56
É necessário também que esta linguagem seja abrangente o suficiente para oferecer ao
usuário a facilidade de expressão de conceitos complexos na construção de modelos
espaciais com todos os operadores, parâmetros e tipos de dados necessários. Por este
motivo, a álgebra de mapas de Tomlin (1990) tem servido de referência para os projetistas
de SIG, no desenvolvimento de várias implementações.
Apesar da grande maioria do SIGs de mercado possuir interfaces gráficas baseadas em
ícones, menus e botões, o uso de linguagens de comando e linguagens de programação
continua sendo necessário para a realização de projetos complexos, que envolvem
procedimentos de modelagem. Entre as abordagens possíveis, podemos citar:
•
Macro-comandos interpretados que operam através de através de
procedimentos atômicos (como o AML do ARC/INFO e os arquivos
“batch” do IDRISI e do GRASS). Cada comando tem de ser auto-contido
e fornecer todos os parâmetros necessários para sua operação.
•
Linguagens de programação de propósito geral, às quais são acrescentados
operadores específicos de análise espacial e tipos de dados gráficos e
tabulares básicos (como o AVENUE do Arc/View ou o MapBasic do
Map/Info). Cabe ao usuário a responsabilidade de definir a semântica das
operações de análise espacial a partir dos tipos de dados básicos.
•
Linguagens de programação específicas para geoprocessamento, com tipos
de dados de alto conteúdo semântico, como LEGAL, MAP e GRID. Os
programas são menores e mais legíveis, mas o usuário tem de seguir uma
seqüência estabelecida de organização de programa (como foi mostrado no
Capítulo 3), incluindo necessidades típicas de programação, tais como
declaração e instanciação.
O formalismo inerente às linguagens de programação, aliado à expressividade da linguagem
são pontos fortes para a defesa deste tipo de interação. Programadores de computador
trabalham a décadas e com sucesso documentando e desenvolvendo procedimentos
complexos desta maneira. Adicionalmente, uma vez desenvolvido e testado um modelo de
análise, na forma de um programa, o procedimento fica estabelecido, podendo ser
analisado, disseminado e reaproveitado.
57
As dificuldades do usuário com interface baseadas em linha de comandos e linguagem de
programação são (Bruns e Egenhofer 1997) :
!
Memorizar um número grande de nomes de operadores;
!
Escrever a sintaxe dos comando corretamente;
!
Selecionar o operador apropriado para cada tarefa.
A prática mostra que aprender uma linguagem de comandos ou linguagem de programação
demanda uma certa quantidade de tempo, que irá depender de quão complexo são os
comandos e que experiência o usuário tem na aplicação em
outras linguagens de
programação. Adicionalmente, um programa que descreva um modelo de análise só é
compreendido por pessoas que conhecem a mesma linguagem, limitando assim, sua
capacidade de disseminar de informações.
Exemplo - Arc/ Info:
O sistema Arc/Info (ESRI, 1992) possui vários modos de operação, como será vistos nos
exemplos. Na sua forma básica a interação se baseia em chamada de programas e passagem
de parâmetros, onde os dados são arquivos de entrada e saída para os comandos,
caracterizado portanto como Interface por Linguagem de Comandos (Figura 4.2).
Objetivo: determinar as regiões que distam 5 km das estradas em uma área de
reflorestamento
1. Criar mapa de distância (arquivo roadbuffer) a partir
do mapa de estradas (arquivo roadlines), utilizar o módulo “arc”:
Arc: buffer roadline roadbuf # # 5000 # line
2. Visualizar o resultado utilizar o módulo
e informar os parâmetros:
Arcplot: mapex roadbuf
Arcplot: linecolor 2
Arcplot: arcs roadline
Arcplot: linecolor 5
Arcplot: arcs roadbuf
“arcplot”
Figura 4.2 - Exemplo de operação de análise no Arc/Info.
Fonte: Tutorial do Arc/Info (Murmion, 1997)
Alguns módulos podem ser acrescentados ao mesmo sistemas conferindo-lhe outras
formas de interação. O módulo GRID (ESRI, 1992), por exemplo, adiciona ao sistema
uma linguagem de programação para álgebra de mapas, baseada nos trabalho de Tomlin
(1990).
OUTGRID = INGRID1 + INGRID2
58
OUTGRID = INGRID1 XOR 5
OUTGRID = SIN(INGRID1)*4/LOG(INGRID2)
Exemplo - OSUMAP:
O sistema OSUMAP (OSU, 1997) baseado na linguagem MAP (Tomlin, 1990)é um
exemplo clássico de interface por linha de comando em álgebra de mapas. Toda interação
se dá pela digitação de comandos no sinal de prontidão do sistemas: “>”, o que pode ser
observado na linha de baixo da tela do computador representada pela Figura 4-3. O usuário
pode solicitar ajuda ao sistema (comando “help”) e obter uma lista dos comandos
disponíveis (Figura 4.3), pode ainda solicitar a instruções sobre cada comando, p. ex.: o
comando “help expose” trás a sintaxe completa do comando “expose”.
Figura 4.3 – Interface por Linha de Comandos do OSUMAP.
59
4.2.2
Menus e Formulários
Visão Geral
O princípio básico deste paradigma é a existência de um questionário eletrônico, baseado
em campos texto, listas de opções, botões de múltipla escolha e outros recursos de
interface gráfica (GUI), onde o sistema pode auxiliar o usuário no preenchimento correto
dos campos, ex.: Figura 4.4.
Figura 4.4 – Interface de operações aritméticas no SPRING.
Em interface por menus existe um conjunto hierarquizado de opções para facilitar ao usuário a
busca por um operador apropriado. Se o sistema puder determinar qual o tipo de resultado
que o usuário pretende obter então ele desabilitar ou deixa de apresentar as opções
inconsistentes, o que facilitaria a construção de comandos corretos. Este procedimento é
chamado “seleção baseada em contexto” onde o contexto pode ser determinado, p. ex.,
pelo último dado selecionado.
Menus e formulários é o paradigma de interface utilizado nos SIG atuais para a maioria das
tarefas. Como as operações de álgebra de mapas requerem um conjunto amplo de
60
informações, alguns sistemas utilizam janelas de diálogo baseadas em formulário para que o
usuário estabeleça os parâmetros para a execução da operação.
Interfaces por formulários auxiliam o usuário na construção de comandos corretos. Uma vez
que todas as opções são apresentadas sob a forma de listas e botões de escolha, o comando
construído através de formulários fica livre de erros de sintaxe.
Os principais inconvenientes do uso de menus e formulários para operações de Álgebra de
Mapas são:
•
Menus e janelas de diálogo com formulários costumam apresentar
sobreposições inconvenientes, escondendo partes da janela que deveriam
estar expostas no momento da definição dos parâmetros.
•
Este paradigma não permite uma visão global da seqüência dos comandos
e do modelo de Análise Espacial.
•
Normalmente, os formulários são preenchidos, executados e desaparecem
da tela, nem sempre
sendo armazenados nem organizados como
procedimentos para ser reutilizados, e não ficam documentados como em
uma linguagem de programação. A menos que o sistema mantenha um
registro do que esta sendo executado não é possível recuperar a história
dos comandos e opções executados, para recuperar o modelo de análise
desenvolvido.
Em resumo,
o uso de menus e formulários para álgebra de mapas só pode ser
recomendado para operações atômicas, que tenham grande significado independente e não
necessitem fazer parte de um procedimento mais elaborado. Os exemplos seriam
operações de declividade e fatiamento em modelos numéricos de terreno, mapas de
distância, geração de legendas.
Exemplo - IDRISI Windows:
O sistemas IDRISI Windows 1.0 (IDRISI, 1996), Figura 4-5, faz uso de janelas de diálogos
do MS_Windows com formulários para que o usuário especifique operações de análise
espacial. O usuário escolhe o operador adequado a sua tarefa em um sistema hierárquico de
61
menus, onde as opções estão agrupadas em subníveis, por tipo do operador, o que facilita
a localização do operador desejado.
Em alguns SIGs, cada operador de análise espacial tem um formulário próprio que solicita
ao usuários o preenchimentos dos campos referentes aos parâmetros que são necessário
para a sua execução.
Figura 4.5 - Formulário do operador “escalar” do IDRISIW.
Exemplo - MGE Intergraph
No sistema MGE Intergraph existe um único formulário para geração de comandos para
vários operadores. O usuários selecionar os operadores, operandos e opções através de
listas de opções. Conforme isto é feito o sistema responde ao usuário apresentando na
linha inferior do formulário o texto completo do comando, dá como está sendo
“montado”, o que pode ser observado na parte inferior da Figura 4.6:
62
Figura 4.6 - Formulário do MGE Intergraph.
Nota-se que neste tipo de interface o contexto é definido pelos valores preenchidos pelo
usuário, de forma que os campos que ainda não foram preenchidos listam somente opções
compatíveis com o contexto.
4.2.3
Interfaces por Manipulação Direta
Visão Geral
Interface gráfica baseadas em manipulação direta permitem a interação do usuário com o
sistema mediante o ato de apontar, mover ou conectar representações de objetos do
sistema na tela do computador. “A idéia central está em visualizar e identificar rapidamente
os objetos e operadores de interesse, substituindo os comandos de sintaxe complexas pela
manipulação direta de seus ícones.” (Adaptado de Shineidermann, 1992)
Alguns ensaios tem analisado a eficiência e a deficiência de interfaces por manipulação
direta. O trabalho de Eberts (1994) mostrou que, tomando-se uma interface baseada em
comandos e uma interface baseada em manipulação direta, o desempenho dos usuários
experientes tende a diminuir quando estes migram de sistemas baseados em comandos para
sistemas baseados em manipulação direta; usuários novatos tendem a apresentar melhor
desempenho se iniciam sua atividades em sistemas baseados em manipulação direta do que
em sistemas baseados em comandos, como indicado na Figura 4.7.
63
Figura 4.7 - Avaliação de Interfaces por Manipulação Direta.
Fonte: Eberts (1994).
Interface Baseada em Diagrama de Fluxo
Diagramas são bastante empregados em ambientes CASE (Computer Aided Software
Engineering) e sistemas industriais. Neste tipo de interface, ícones são dispostos sobre a
tela de forma que o usuário possa fazer conexões entre eles estabelecendo uma seqüência,
da mesma forma como faria se estive simplesmente editando um diagrama estático.
Este paradigma oferece uma visão global e gráfica do procedimento em desenvolvimento.
A linguagem metafórica se restringe ao ícones e suas conexões e não à manipulação
propriamente dita (como no ato de arrastar um arquivo para a lixeira). Mas, na vida real, o
usuário não arrasta um mapa para sua prancheta de desenho, a fim de construir um
diagrama de fluxo com este mapa.
A metáfora principal não tem relação com a tarefa física desenvolvida pelo usuário, mas
sim com a forma de expressão de um problema através do encadeamento de tarefas em um
diagrama, técnica que é largamente utilizada em várias áreas do conhecimento e utilizada
em muitas publicações sobre aplicações de análise espacial (MacGuire e GodChild, 1992)
(Figura 4.8).
64
Primary
maps
Engineering:
gentle slope
close to roads
Derived
maps
Interpreted
maps
Elevation
Elevation
S-Pref
Roads
Prox-R
R-Pref
Prox-C
C-Pref
Prescriptive
maps
Slope
Aesthetics:
gentle slope
good view
west aspect
Coast
Slope
Coast
Development
Views
V-Pref
Elevation
Aspect
A-Pref
Coast
Constraints
Elevation
Constraints:
100m sefback
<50% slope
Slope
Figura 4.8 – Diagrama de Fluxo em Análise Espacial.
Fonte Berry (1991).
Interfaces de Manipulação Direta em Álgebra de Mapas
No caso de SIG, as interfaces de manipulação direta estão, na maior parte dos casos, ligadas
às interfaces por linguagens de programação, pois geram programas que podem ser
posteriormente executados.
As interfaces de manipulação direta dão uma visão global e gráfica do procedimento em
desenvolvimento, os modelos de análise ficam documentados de forma gráfica e bastante
expressiva. Ao contrário de programas em linguagem de programação não é necessário ser
especialista no software para se ter um entendimento mínimo do que faz o modelo.
No entanto, administrar diagramas muito complexos pode se tornar uma atividade extra
para usuário e tomar mais tempo do que o necessário. Em alguns casos o sistema precisará
de janelas de diálogo com alguns formulários para que o usuário informe parâmetros de
operadores ou expressões complexas que não podem ser expressas graficamente de forma
simples, tais como expressões matemáticas.
A aplicabilidade deste paradigma de interface, manipulação direta, para Geoprocessamento é
funcionar como suporte ao desenvolvimento de modelos de análise espacial de forma mais
cognitiva do que na própria linguagem de manipulação do SIG. Sua principal vantagem é
65
dar ao usuários uma visão global do procedimento de análise. Entre os principais exemplos
de interfaces de manipulação direta para álgebra de mapas, podemos citar:
•
Geographer’s DeskTop ( citado por Bruns e Egenhofer, 1996);
•
Grassland (LAS, 1997);
•
Model Maker (ERDAS, 1993);
•
VFQL (Standing, 1995).
Exemplo – Geographer´s Desktop
No Geographer’s Desktop (citado por Bruns e Egenhofer, 1996) como pode ser observado
na Figura 4.9, os objetos são apresentados em projeção perspectiva, um armário de mapas e
uma mesa de luz. As gavetas são abertas através de um “clique” do “mouse”, quanto então
os mapas aparecem flutuando sob o armário, também em projeção perspectiva, com seus
nomes ao lado. O usuário pode arrasta os mapas para mesa de luz na ordem que lhe
convier e estabelecer operações na pilha de mapas que se forma sobre a mesa de luz. Os
operadores apresentam uma outra metáfora, a de operações matemáticas sobre colunas de
valores.
A expressividade desta interface é grande. É praticamente um ambiente virtual onde os
mapas podem ser arrastados e sobrepostos. No entando, devemos observar que, sendo
agora um tecnologia mais acessível, os sistemas informatizados para Geoprocessamento
acabaram por abolir o uso de mesas de luz e sistemas manuais, o que prejudica esta
metáfora como forma de aproximação à rotina do atual usuário de SIG.
66
Figura 4.9 - Interface Baseada em Pilhas.
Fonte: Bruns (1996)
.
Este paradigma de interface baseada em Manipulação Direta resgata a metáfora da
manipulação, ou seja, o ato de arrastar e dispor dos ícones semelhantemente ao que é feito
na prática. Tal qual a operação em um ambiente “DeskTop” os ícones dos documentos são
arrastados e empilhados sobre os operadores que irão processá-los.
Exemplo - Grassland
Desenvolvido a partir do GRASS, o Grassland 1.1 (LAS, 1997) implementa sua interface
para análise geográfica baseada em fluxograma como pode ser visto na Figura 4.10. Os
dados e operadores são selecionados em janelas auxiliares e arrastados para a janela do
“Procedure Workbench”.
No “Procedure Workbench” o usuário pode fazer conexão entre dados e operadores para a
montagar diagramas de fluxo de dados. Tanto os dados quanto os operadores tem
terminais para as conexão, como “plugs” de tomadas. O formato e a cor do “plug”
identificam o tipo do dado, se é vetorial ou matricial, por exemplo. Isto para impedir que as
conexões sejam feita erroneamente. Selecionando-se o ícone do operador, uma janela com
formulário pede os parâmetros necessários. Estabelecida uma conexão de entra ou saída de
dado, automaticamente o campo apropriado do formulário, “mapa de entrada” ou “mapa
de saída”, é preenchido.
67
Figura 4.10 - Ambiente de Análise Espacial do Grassland.
Fonte: Bruns e Egenhofer (1996).
Exemplo - Model Maker
Baseado na “Spatial Modeler Language” (SML) e fazendo parte do conjunto de módulos
do sistema IMAGINE (ERDAS, 1993), o Model Maker é um editor de diagramas de fluxo
aplicado a álgebra de mapas. Seu desenho é bastante simples é limpo, facilitando a leitura
do modelo. Existem ícones para cada tipo de dado, um único ícone para operador
(representado por um círculo) e as setas indicam a direção do fluxo de dados.
No procedimento de criação de um modelo o usuário seleciona em uma janela a parte, qual
o tipo de ícone ele deseja incluir no diagrama: grade, imagem, mapa temático ou um
operador. Neste ponto as conexões já podem ser feitas, mesmo sem terem sido definidos
que mapas e que operadores são aqueles representados pelos ícones. Portanto, o diagrama
é montado sem que o usuário tenha a certeza da disponibilidade do dado ou se o operador
é adequado para processá-lo, já que o sistema só pode checar a consistência das conexões
após obter do usuário estas informações.
68
Figura 4.11 – Diagrama de Fluxo do Model Maker.
Fonte: Bruns e Egenhofer (1996).
Exemplo – VFQL
Visual Funcition Query Language (Standing, 1995) é uma ferramenta de interface por
manipulação direta que permiti a construção de operações de consulta e análise espacial,
através da geração de macros em linguagem AML (Arc/Info). A metáfora deste modelo de
interface se restringe aos ícones dos dados que representam mapas em papel semi
desenrolados (somente a parte escura da Figura 4.12). A indicação de que tipo de dado é
representado pelo ícone se dá pelo desenho este que contém, como por exemplo o
polígono (vide Figura 4-12) indica um dado temático. Cada um deste ícones escuros, na
forma de mapas semi desenrolados, aparecem desordenadamente em uma janela onde o
usuário pode arrastá-los para um outra região da interface onde serão conectados dados e
operadores.
69
Figura 4.12 – Operador de Buffer atuando sobre mapa temático “Lakes” no
VFQL (Standing, 1995).
Um exemplo completo usando o VFQL (Figura 4.13) apresenta a sobreposição de
comandos, onde resultados intermediário são dados de entrada para o comando seguinte
construindo a expressão apresentada logo abaixo da figura:
Showattribs(Vegsite(Identify(Erase(Buffer(Roads,300),Buffer(Lakes,20))
,Vegcn),VEGCN-ID=14 and INSIDE=1 and AREA=>2000))
Figura 4.13 – Virtual Functional Query Language.
Fonte Standing (1995).
A proposta de VFQL se baseia em programação funcional, ou seja, seu objetivo é que o
usuário construa expressões de manipulação espacial, semelhante ao exemplo da Figura
4.13, e armazene-as no sistema como uma função. Então, cada função pode ser executada
independente de uma seqüência de operações. Isto difere de diagrama de fluxo de dados,
que se baseiam em programação procedural, caracterizada por registrar e seguir uma
seqüência ordenada de procedimentos.
4.2.4
Resumo
A revisão dos paradigmas de interface e sua implementação, feita na seção anterior, indica
que para álgebra de mapas em Geoprocessamento é interessante que o usuário possua, ao
mesmo tempo, uma linguagem de programação de grande poder expressivo, um sistema de
menus e formulários para executar operações atômicas e uma interface de manipulação direta
70
para expressar graficamente seqüência de procedimentos baseados em metodologias de
análise espacial. Neste sentido, o paradigma de diagrama de fluxos seria empregado com o
objetivo de auxiliar o usuário a compor seus modelo diretamente em um diagrama de fluxo
e gerar programas executáveis no SIG.
Um fator que determina de forma bastante decisiva o projeto de interface é o modelo de
dados do SIG sobre o qual a interface é desenvolvida. Se o modelo de dados é capaz de
representar a informação geográfica em níveis de abstração de mais alto nível, da mesma
forma a linguagem de programação e a interface de manipulação direta poderão representar
melhor o conhecimento do usuário em um nível mais elevado, ao construir o modelo de
análise espacial.
Por exemplo: na Figura 4.9, no Geographer’s Desktop, o operador "add" atua sobre o dado
solos (soil) e vegetação (veg), somando indistintamente os valores encontrados nos dois
mapas e criando como resultado o mapa "solos+vegetação" (veg+soil). Este comando não
explicita quais as classes de solos e vegetação serão combinadas no mapa resultante como
ocorre em uma expressão em LEGAL (vide Capítulo 3).
Outro problema nas interfaces analisadas: no Model Maker, baseado no sistema ERDAS,
os dados são armazenados diretamente pelo sistema de arquivo, não existe um modelo
conceitual que organize um banco de dados geográficos como no SPRING (vide Capítulo
2), já no Grassland, o modelo conceitual se restringe a separar os mapas de acordo com
suas estruturas de armazenamento de baixo nível, tais como raster, vector, line, point e
region. Além de impactar na qualidade da representação do conhecimento, a conseqüência
prática é que o usuário certamente terá dificuldade em encontrar o dado caso ele se
encontre em uma estrutura desordenada de arquivos e diretórios.
A partir da análise aqui apresentada, podemos concluir que:
•
Dada a complexidade das aplicações de Geoprocessamento e a diversidade
de capacitação dos usuários, um SIG de propósito geral não pode estar
limitado a um único paradigma de interface, devendo idealmente combinar
as três alternativas: linguagens de comando ou linguagens programação; menus e
formulários; e interfaces de manipulação direta.
71
•
Para usuários experiente, a metáfora de diagrama de fluxo traz a vantagem de
apresentar e documentar bem o modelo da análise espacial.
•
Considerando o problema de aprendizado, diagramas de fluxo se baseiam em
programação procedural o que corresponde ao apelo mais didático,
expressivo e intuitivos deste paradigma.
Neste contexto, optou-se por desenvolver uma interface de Álgebra de Mapas baseada no
paradigma de diagramas de fluxo, que tenha como saída um programa na linguagem LEGAL.
Deste modo, pode-se estabelecer uma combinação ótima para satisfazer tanto usuários
experientes (que preferem a expressão direta do programa em linguagem) como iniciantes
(que terão uma ferramenta de fácil compreensão).
4.3
Requisitos para o projeto de Interface para Álgebra de Mapas
Para o desenvolvimento de um projeto de interface para álgebra de mapas, é necessário em
primeiro lugar o conhecimento do domínio do problema análise espacial e
geoprocessamento, como visto no Capítulo 2, e o conhecimento de uma descrição formal
para operações sobre dados espaciais tal qual o apresentado pela linguagem LEGAL
(Capítulo 3). Feita estas duas revisão é importante também analisar as alternativas existentes
no mercado e na literatura verificando as soluções adotadas e suas justificativas. Como
resultado deste processo de analise é possível então, elaborar uma lista com os requisitos
para a interface a ser proposta.
A lista de requisitos a seguir está dividida em:
requisitos gerais de interface por
manipulação direta, requisitos específicos para álgebra de mapas e requisitos específicos
para o SPRING. As fontes bibliográficas das quais foram extraídos os requisitos são:
" dos critérios utilizados no trabalho de Bruns e Egenhofer (1996), que analisa
interfaces para álgebra de mapas em vários sistemas SIG comerciais: requisitos
1, 3, 4, 7, 8, 9;
" discussões sobre a tendência das interfaces (Halfhill, 1997): requisito 6;
" observações sobre personalização de interface para SIG,
Medeiros (1996) e Worboys (1996): requisitos 10 e 11;
72
em Câmara e
" tópicos de projetos de interfaces em Sheniderrman (1993) e Eberts (1994):
requisitos 2 e 5;
" dos Capítulos 2 e 3 deste trabalho: requisitos 12 e 13.
4.3.1
Requisitos Gerais
1. Utilizar metáforas adequadas com o domínio da aplicação;
A escolha de metáforas irá agilizar o processo mental do usuário de
relacionar o símbolo com o seu conteúdo semântico. Interfaces baseadas
em comandos costumam adotar como comandos termos do jargão do
usuário o que é preferível a se adorar termos computacionais ou
matemáticos. Semelhantemente, interfaces baseadas em manipulação direta
necessitam relacionar seus ícones e a maneira de trata-los dentro de um
ambiente gráfico, com os elementos do cotidiano das tarefas executadas
pelo usuário.
2. Não trazer uma metáfora estranha ao domínio da aplicação;
Evitar apresentar uma outra metáfora que não seja aquela relacionada
diretamente com o contexto da aplicação pois pode causar ambigüidade.
3. Facilitar a construção de comandos corretos;
Apresentar formas assistidas de edição dos comandos e impedir que se
estabeleçam conexões incorretas.
4. Auxiliar na escolha do operador certo para a tarefa;
O sistema deve basear-se no contexto para listar e sugerir operadores
apropriados, oferecendo recursos de busca e seleção tanto de dados como
de operadores;
5. Ambiente dinâmico e interativo;
Oferecer ao usuário a sensação de controle sobre os elementos do sistema
através de um ambiente de trabalho dinâmico e interativo, onde o sistema
poça responder imediatamente aos atos do usuário.
73
6. Evitar a sobreposição de janelas;
O excesso de janelas se sobrepondo dificultam o diálogo entre o usuário e o
sistema, escondendo parte da informação justamente no momento de tomar
a decisão sobre a ação a ser executada.
7. Reduzir complexidades
Reduzir complexidades, sejam elas sintáticas ou gráficais. Oferecer uma
interação com os elementos da interface com regras simples e intuitivas e
dar suporte a administração de diagramas muito extensos.
4.3.2
Requisitos Específicos sobre Álgebra de Mapas
8. Expressar bem o modelo de análise espacial;
Facilitar a
compreensão da lógica do modelo independentemente dos
rudimentos da linguagem e do sistema utilizado;
9. Documentar o modelo de análise;
Para seu uso posterior, difusão ou publicação dos resultados e da
metodologia.
10. Permitir a personalização de aplicações de SIG;
Segundo Câmara et. al. (1996), Sistemas de Informação Geográfica, de uma
maneira geral, têm aplicações tão diversificadas que seria necessário a
construção de uma interface para cada aplicação, e por este motivo é
importante que os SIGs permitam que o usuário configure e personalize a
interface da sua aplicação. Este não é um requisito específico de álgebra de
mapas mas de todo o conjunto de funcionalidade que o SIG pode oferecer
e que portanto influencia nas operações de álgebra de mapas. No entanto na
medida em que o usuário possa incluir seus modelos de análise no banco de
dados e possa reutiliza-lo, pode-se considerar que ele esteja personalizando
ama aplicação.
11. Extensiblidade
74
O sistema de interface deve ser extensível. Conforme os novos operadores
de são desenvolvidos, no decorrer da evolução do software, é necessário
incluí-los na interface, através de recursos que não impliquem em
reprogramar seu código mas sim reconfigurar o software, informando as
características de cada novo operador.
4.3.3
Requisitos Específicos para o SPRING
12. Gera programas em LEGAL
O sistema deve ser capaz de gerar código em LEGAL livre de erros.
13. Representar o modelo conceitual do SPRING
O sistema deverá se basear no modelo de dados do SPRING tanto no
acesso ao dados quanto na construção de expressões de análise.
14. Salvar e recuperar modelos no banco de dados do SPRING
O sistema deverá salvar os modelos de análise na mesma estrutura de
armazenamento do banco de dados do SPRING.
75
76