Base de Dados Geográfica

Refª   Requisitos de interface e usabilidade   CaU relacionados   Rint.19  As opções de menu respondem ao domínio de tarefas do 

utilizador  CaU7‐CaU23 

Rint.20  As tarefas alternativas são facilmente identificáveis  CaU7‐CaU14; CaU17‐ CaU23 

Tabela 18 – requisitos de interface e usabilidade   

4.1.2.3. Requisitos de desempenho    

Refª  Requisito de desempenho  CaU relacionados 

RDes.1   As pesquisas devem ser rápidas.   CaU1‐CaU7  RDes.2   Todas as interacções do sistema devem ser realizadas num 

tempo apropriado.   CaU1‐CaU33 

RDes.3  Alteração visível na selecção de ícones – 0.50‐1.50 segundos  CaU7‐CaU23  RDes.4  Tarefas de simples execução – 1 segundo   CaU1‐CaU5 

RDes.5  Tarefas comuns – 2 a 4 segundos  CaU7‐CaU33 

RDes.6  Tarefas complexas – 8‐12 segundos  ‐   RDes.7  Os tempos de resposta são apropriados ao processamento  cognitivo do utilizador (não exigência de níveis de  concentração/retenção de informação muito elevados)  CaU1‐CaU33  RDes.8      Tabela 19 – Requisitos de desempenho    4.1.2.4. Requisitos de segurança e integridade dos dados   

Refª  Requisito de segurança, privacidade e integridade de dados  CaU relacionados  RSeg.1   O utilizador realiza operações para as quais está autorizado.   CaU1‐CaU33  RSeg.2   As credenciais devem ser únicas e fornecidas pelo 

administrador, não existe opção de registo.   CaU1‐CaU33  RSeg.3   Necessidade de existência de ligação à Internet  CaU1‐CaU33 

Tabela 20 – Requisitos de segurança e integridade dos dados   

4.1.2.5. Base de Dados Geográfica   

A  base  de  dados  geográfica  que  integra  o  projecto  de  dissertação  define  as  coordenadas  do  sistema  de  informação  geográfica,  isto  é,  armazena  a  informação  de  todas  as  localizações  possíveis relativas a estações, nós da linha e veículos do mapa.  

O  sistema  de  gestão  de  base  de  dados  PostgreSQL  define  a  solução  adoptada  para  armazenamento  e  manipulação  de  dados  geográficos  considerando  o  estudo  efectuado  relativamente às ferramentas GIS apresentadas no estado da arte.  

O  postgis  apresenta  uma  biblioteca  de  funções  geográficas  que  se  revelou  bastante  útil  no  cálculo de distância entre localizações de veículos.  

A  escolha  do  PostgreSQL  assenta  no  facto  de  ser  uma  ferramenta  livre,  simples  de  utilizar  e  permitir a definição de um sistema GIS que traduz a área de operação e que está na base do  cálculo  das  coordenadas  geográficas  para  representação  de  veículos  no  mapa  georreferenciado. 

A  base  de  dados  geográfica  é  constituída  apenas  por  duas  tabelas:  ConstLinePosition  e 

OrderedLinePoints. A primeira tabela define os dados geográficos associados aos nós da linha 

de  metro  desenhada  no  mapa.  Um  nó  pode  traduzir  uma  estação  ou  uma  baliza.  A  baliza  define um ponto geográfico da linha onde poderá ou não estar presente um veículo. A tabela 

OrderedLinePoints armazena as coordenadas geográficas da linha de metro.  

Para  o  cálculo  da  posição  em  tempo  real  dos  veículos  foi  definida  uma  função  getposition()  que retorna as coordenadas geográficas e permitem a sua representação no mapa.  

A  função  getposition  recebe  o  identificador  do  nó  da  linha  onde  está  localizado  o  veículo  (baliza  ou  estação),  a  distância  percorrida  e  a  direcção  em  que  se  desloca.  As  coordenadas  finais  são  obtidas  através  de  pesquisas  efectuadas  na  tabela  ConstLinePosition,  utilizadas  no  cálculo da distância entre coordenadas, conferido por um método PostGIS. 

115 

5. Definição e Implementação da Solução 

5.1. Comparação entre Web services e CORBA 

Uma  das  principais  diferenças  entre  as  duas  tecnologias  está  relacionada  com  a  natureza  de  cada  uma.  Os  Web  services  surgiram  da  necessidade  de  criação  de  aplicações  modulares  publicadas,  localizadas  e  invocadas  a  partir  da  Web,  o  CORBA  foi  inicialmente  pensado  para  soluções empresariais.  

O  recurso  às  novas  tecnologias  de  desenvolvimento  das  aplicações  Web  conferiu  aos  Web 

services maior facilidade de implementação, interoperabilidade, comunicação e integração de 

serviços.  

Uma  das  dificuldades  que  está  por  trás  do  uso  de  tecnologias  como  o  CORBA  assenta  na  necessidade  de  utilização  de  linguagens  de  definição  de  interfaces  (IDL),  que  revela  a  necessidade  de  conhecimento  de  técnicas  para  integração  de  diferentes  linguagens  num  cenário constituído por aplicações heterogenias. 

Os  utilizadores  de  CORBA  possuem  os  conhecimentos  necessários  para  desenvolver  Web 

services tendo em conta a complexidade adjacente à utilização das duas tecnologias. Enquanto  o CORBA exige conhecimentos mais aprofundados de linguagens como C++, os conceitos que  estão por trás do desenvolvimento de Web services assentam em tecnologias XML simples.  Os esforços de utilização de ferramentas standards na definição dos Web services contribuem  para a sua aceitação e reconhecimento rápido por parte das empresas relativamente a outras  tecnologias como o CORBA.   Embora o CORBA e o DCOM tenham adquirido bastante aceitação e sejam utilizados em várias  empresas  desde  o  seu  aparecimento,  os  Web  services  vêm  contornar  alguns  problemas  que  essas tecnologias apresentam. Um dos principais problemas associados ao uso de tecnologias  como o CORBA e DCOM está relacionado com o facto de, apesar de úteis ao estabelecimento  de  comunicações  servidor/servidor,  apresentarem  algumas  limitações  em  termos  de  interoperabilidade  cliente/servidor  através  da  Internet  [86].  Como  já  referido,  o  uso  de  tecnologias  XML  como  WSDL  e  SOAP  tornam  os  Web  services  mais  flexíveis  em  termos  de  comunicação e interoperabilidade cliente/servidor.  

Apesar da eficiência do protocolo IIOP, o SOAP oferece uma sintaxe simples que dá lugar à fácil  detecção de erros e gestão do tráfego, já que é totalmente perceptível para o programador.   A  interface  de  um  objecto  CORBA  é  definida  a  partir  de  um  IDL  que,  nos  Web  services,  corresponde  a  um  ficheiro  WSDL.  Existem  várias  ferramentas  que  permitem  gerar  ficheiros  WSDL a partir do código que define as operações do serviço como, por exemplo, o AXIS, JAX‐ RPC  ou  JAX‐WS.  Esta  tarefa  torna‐se  mais  complexa  no  CORBA,  o  IDL  tem  de  ser  editado  manualmente consoante as modificações que são efectuadas no código aplicacional.