Universidade da Madeira Departamento de Matemática e ... · HSDPA – High Speed Downlink Packet...

Departamento de Matemática e Engenharias

Dissertação para obtenção do grau de Mestre em

Engenharia de Telecomunicações e Redes

Orientador: Prof. Dr. José Manuel Baptista

Discente:

Gonçalo Luís Nº.2045902

Maio 2009

Universidade da Madeira

Interacção Através de Dispositivo Móvel Com Plataforma de Rede

Social

Indices

Interacção Através de Dispositivo Móvel com Plataforma de Rede Social i

Índice Índice de Figuras ....................................................................... iii

Índice de Tabela ......................................................................... iv

Agradecimentos .......................................................................... 1

Acrónimos ................................................................................... 2

Prefácio ....................................................................................... 4 Motivação ............................................................................................................. 4 Enquadramento ..................................................................................................... 5 Objectivos ............................................................................................................. 7

1.Introdução ............................................................................... 8 1.1.Aspectos Tecnológicos e de Negócio .................................................................. 8 1.2.Tecnologia ...................................................................................................... 10

1.2.1.Serviços de Dados e Redes Móveis .......................................................... 10 1.2.2.Location Based Services ......................................................................... 11 1.2.3.Técnicas de Localização .......................................................................... 12

1.2.3.1.GPS .......................................................................................... 13 1.2.3.2.Posicionamento GSM/UMTS ........................................................ 15 1.2.3.3.Posicionamento WLAN ................................................................ 17

1.2.4.Terminais Móveis ................................................................................... 19 1.2.5.Software ...................................................................................................... 20 1.3.Serviços Móveis Para Turismo ........................................................................... 21

1.3.1.Plataformas Existentes ........................................................................... 23 1.3.1.1.Crumpet ................................................................................... 23 1.3.1.2.The Guide ................................................................................. 25 1.3.1.3.Intousys .................................................................................... 25 1.3.1.4.Mobile Tour Guide ..................................................................... 26 1.3.1.5.Es Madrid .................................................................................. 28

2.Culture for Us ......................................................................... 29 2.1.Plataforma ...................................................................................................... 29 2.2.Comparação com Plataformas Estudadas ........................................................... 31 2.3.Dispositivos Móveis .......................................................................................... 32

3.Modelização do Sistema ......................................................... 35 3.1.Arquitectura Proposta ...................................................................................... 36 3.2.Diagrama de Casos de Utilização ...................................................................... 38 3.3.Cenários Utilização .......................................................................................... 40

3.3.1.Cenário 1 – “Chegada à Região” .............................................................. 40 3.3.2.Cenário 2 - “Localização por BTS” ............................................................ 41 3.3.3.Cenário 3 - “Localização por GPS” ........................................................... 41

3.4.Diagrama de Sequência ................................................................................... 42 3.5.Requisitos ....................................................................................................... 45

3.5.1.Requisitos Funcionais ............................................................................. 45 3.5.2.Requisitos Não Funcionais ...................................................................... 46

3.6.Diagrama de Actividades .................................................................................. 46 3.6.1.Funcionalidades da Página Web Móvel ..................................................... 47 3.6.2.Funcionalidade da Aplicação Móvel .......................................................... 54

3.7.Modelo Visualização Controlo ............................................................................ 57 3.8.Diagrama de Entidade Relação ......................................................................... 59

4.Implementação da Arquitectura ............................................ 60 4.1.Symbian C++ vs Java ME em Sistemas Operativos Symbian ............................... 60

Indices

Interacção Através de Dispositivo Móvel com Plataforma de Rede Social ii

4.1.1.Desempenho ......................................................................................... 61 4.1.2.Instalação de Aplicações ......................................................................... 61 4.1.3.Desenvolvimento de Software em Symbian e Java .................................... 62 4.1.4.Portabilidade e Fragmentação ................................................................. 64 4.1.5.Segurança ............................................................................................. 65 4.1.6.Ferramentas e Aprendizagem .................................................................. 66 4.1.7.Análise Global ........................................................................................ 66

4.2.Funcionalidades e Assinatura Symbian .............................................................. 67 4.3.Processo de Construção de um Programa Symbian C++ ..................................... 71

4.3.1.Ficheiros Recurso ................................................................................... 73 4.3.2.Ficheiro MMP ......................................................................................... 74

4.4.XTHML MP vs WML .......................................................................................... 75 4.5.Implementação da Aplicação ............................................................................ 77

4.5.1.Programação da aplicação móvel............................................................. 78 4.5.1.1.Comunicação http ...................................................................... 78 4.5.1.2.Obtenção dos parâmetros de Localização ..................................... 82

4.6.Implementação Página Web Móvel.................................................................... 85 4.7.Testes ............................................................................................................ 91

4.7.1.Chegada à Região .................................................................................. 92 4.7.1.1.Página Web ............................................................................... 92 4.7.1.2.Aplicação Móvel ......................................................................... 97

4.7.2.Localização por BTS ............................................................................. 100 4.7.3.Localização por GPS ............................................................................. 101

4.8.Desempenho da Aplicação .............................................................................. 102 4.8.1.Nokia N95 ........................................................................................... 102 4.8.2.Nokia N78 ........................................................................................... 108

5.Conclusão e Trabalho Futuro ............................................... 111 5.1.Conclusão ..................................................................................................... 111 5.2.Trabalho Futuro ............................................................................................ 112

6.Bibliografia ........................................................................... 113

7.Anexos 117 Anexo A – Código de Algumas Funções ................................................................. 117

Método SetupConnectionL(): ......................................................................... 117 Método IssueHTTPGetL(): ............................................................................. 121 Método IssueHTTPPostL(): ............................................................................ 122 Método MHFRunL(): ..................................................................................... 123 Método GetNetworkParameters(): ................................................................. 128 Método GetCurrentPositionL(): ...................................................................... 129 Método PostNetworkInfo(): ........................................................................... 129 Método GetGPSInfoL(): ................................................................................. 131 Método SendHTTPRequestL(): ....................................................................... 132 Método SetupFileDownload(): ....................................................................... 133

Indices

Interacção Através de Dispositivo Móvel com Plataforma de Rede Social iii

Índice de Figuras

Figura 1 Modelo Geral da Plataforma ............................................................ 5 Figura 2 Processo de Pedidos e Colocação de Conteúdos ................................ 6 Figura 1.1 Operação GPS ........................................................................... 14 Figura 1.2 Cell ID ou Cell Id com TA ........................................................... 16 Figura 1.3 Operação E-OTD ....................................................................... 17 Figura 1.4 Serviços LBS e Precisão de Localização ........................................ 19 Figura 1.5 Arquitectura Funcional do sistema multi-agente CRUMPET ............ 24 Figura 1.6 Sistema de Comunicação ............................................................ 26 Figura 1.7 Arquitectura MTG ...................................................................... 27 Figura 2.1 Arquitectura da plataforma do Culture for Us ............................... 31 Figura 2.2 Cotas de Mercado dos Sistemas Operativos Móveis ...................... 33 Figura 3.1 Arquitectura Proposta ................................................................ 37 Figura 3.2 Modelo de Casos de utilização .................................................... 39 Figura 3.3 Diagrama de Sequência respectivo ao Cenário 1 .......................... 43 Figura 3.4 Diagrama de Sequência do Cenário 2 .......................................... 44 Figura 3.5 Diagrama de Sequência do Cenário 3 .......................................... 44 Figura 3.6 Diagrama de Actividades – Visualizar Localização/Serviços ............ 48 Figura 3.7 Diagrama de Actividades – Procurar Lugares/Serviços .................. 49 Figura 3.8 Diagrama de Actividades – Colocar Fotos ..................................... 50 Figura 3.9 Diagrama de Actividades – Editar/Visualizar Fotos ........................ 51 Figura 3.10 Diagrama de Actividades – Registo ............................................ 52 Figura 3.11 Diagrama de Actividades – Autenticação .................................... 53 Figura 3.12 Diagrama de Actividades – Instalar Programa ............................ 54 Figura 3.13 Diagrama de Actividades – Localização por BTS ......................... 55 Figura 3.14 Diagrama de Actividades – Localização por GPS ......................... 56 Figura 3.15 Modelo MVC ............................................................................ 58 Figura 3.16 Diagrama de Entidade Relação.................................................. 59 Figura 4.1 Classes Básicas da Aplicação ...................................................... 71 Figura 4.2 Espera de obtenção de coordenadas ..................................................... 85 Figura 4.3 Mapa………………………………………………………………………………………85 Figura 4.4 Página Incial ............................................................................. 86 Figura 4.5 Login ........................................................................................ 86 Figura 4.7 Área de Cliente .......................................................................... 87 Figura 4.8 Where I am .............................................................................. 88 Figura 4.9 Search by name ........................................................................ 89 Figura 4.10 Upload Photos ......................................................................... 90 Figura 4.11 Pré-visualização da Foto carregada com Localização ................... 90 Figura 4.12 Fotos agrupadas por lugar ........................................................ 91 Figura 4.13 Página Inicial ........................................................................... 92 Figura 4.14 Registo ................................................................................... 93 Figura 4.15 Conta ..................................................................................... 93

Indices

Interacção Através de Dispositivo Móvel com Plataforma de Rede Social iv

Figura 4.16 Procura por Lugar .................................................................... 94 Figura 4.17 Lista de Lugares ................................................................... 94 Figura 4.18 Resultados de Serviço .............................................................. 94 Figura 4.19 Detalhes de Serviço ................................................................. 95 Figura 4.20 Página de Upload de Fotos ....................................................... 95 Figura 4.21 Pré-visualização da Foto carregada com Localização ................... 96 Figura 4.22 Fotos carregadas por Local ....................................................... 96 Figura 4.23 Fotos de determinada Localização ............................................. 97 Figura 4.24 Visualização da Foto ................................................................ 97 Figura 4.25 Aspecto da Aplicação ............................................................... 98 Figura 4.26 Menu da Aplicação………………………………………………………………… 98 Figura 4.27 Autenticação na Aplicação…..…………………………………………………… 98 Figura 4.28 Escolha Ponto de Acesso………………………………………………………. 98 Figura 4.29 Início ………………………………………………………………………………… 99 Figura 4.30 Mensagem de Sucesso ............................................................. 99 Figura 4.31 Aplicação Minimizada ............................................................... 99 Figura 4.32 Visualização da Localização..................................................... 100 Figura 4.33 Lista Serviços ........................................................................ 101 Figura 4.34 Espera de obtenção de coordenadas ……………………………………102 Figura 4.35 Mapa…………………………………………………………………………………..102 Figura 4.36 Consumo de Potência Chamada .............................................. 103 Figura 4.37 Consumo de Potência Chamada (continuação temporal da Figura 4.36) ...................................................................................................... 104 Figura 4.38 Consumo de Potência Google Maps ......................................... 105 Figura 4.39 Consumo de Potência Google Maps (continuação temporal da Figura 4.38) ............................................................................................ 105 Figura 4.40 Consumo de Potência aplicação Culture for Us - Nokia N95 ....... 106 Figura 4.41 Consumo de Potência aplicação Culture for Us – Nokia N95 (continuação temporal da Figura 4.40) ...................................................... 107 Figura 4.42 Consumo de Potência aplicação Culture for Us - Nokia N78 ....... 109 Figura 4.43 Consumo de Potência aplicação Culture for Us – Nokia N78 (continuação temporal da Figura 4.42) ...................................................... 109

Índice de Tabela

Tabela 1 Redes de Dados Móveis e Redes Sem Fio ...................................... 11 Tabela 2 Desempenho, Implementação e Custos dos vários métodos de

Localização ............................................................................... 18 Tabela 3 Capacidades das linguagens Java ME e Symbian C++ .................... 63

Agradecimentos

Interacção Através de Dispositivo Móvel com Plataforma de Rede Social 1

Agradecimentos

Primeiramente quero agradecer aos meus pais e irmã, pelo incentivo que

me deram ao longo destes anos, porque sem eles nunca teria chegado à

universidade.

Ao meu orientador Professor Doutor José Manuel Baptista, pela

confiança depositada em mim, pela sua capacidade de trabalho, sentido crítico

e disponibilidade.

À Sandra Drumond, namorada, amiga e companheira deste já longo

trajecto, por toda a sua compreensão e incentivo.

Ao Gustavo Fernandes por todo o trabalho desenvolvido em conjunto.

À Márcia Vieira, pelas revisões a esta tese.

Aos meus colegas e amigos, Fábio Vieira, Sara Drumond, pela ajuda e

apoio que me deram ao longo destes anos.

O meu muito obrigado a todos eles, pois todos contribuíram um pouco

para que conseguisse chegar até aqui.

Acrónimos


Acrónimos

AMS – Application Management System

API – Application Programming Interface

AppUI – Application User Interface

ARM – Advance RISC Machine

BTS – Base Transceiver Station

DRM – Digital Restrictions Management

EDGE – Enhanced Data Rates for Global Evolution

E-OTD – Enhanced- Observed Time Difference

GPRS – General Packet Radio Services

GPS - Global Positioning System

GSM – Global System for Mobile Communications

GUI – Graphical User Interface

HSDPA – High Speed Downlink Packet Access

HTML - HyperText Markup Language

HTTP - Hypertext Transfer Protocol

J2ME – Java 2 Micro Edition

JCP – Java Community Process

JPEG - Joint Photographic Experts Group

JSR – Java Specification Requests

KVM – Kernel Virtual Machine

LBS – Location Based Services

LMU – Location Measurement Units

MIDP – Mobile Information Device Profile

MMS - Multimedia Messaging Service

MNOs – Mobile Network Operators

MS – Mobile Station

MVC – Model View Controller

PIN – Personal Identification Number

QoS - Quality of Service

Acrónimos


SMS - Short Message Service

SDK – Software Development Kit

TA – Timing Advance

TOA – Time of Arrival

UI – User Interface

UML - Unified Modeling Language

UMTS – Universal Mobile Telecommunications System

WAP - Wireless Application Protocol

WCDMA - Wide-Band Code-Division Multiple Access

WCSS - Wap Cascading Style Sheet

WiFi – Wireless Fidelity

WLAN – Wireless Local Area Network

WML – Wireless Markup Language

XHTML MP – Extensible Hypertext Markup Language Mobile Profile

Prefácio


Prefácio

Motivação

As tecnologias de informação têm presentemente um papel

preponderante no nosso dia-a-dia.

Com o aparecimento dos dispositivos móveis, surgiram diferentes formas

de divulgação de conteúdos. No entanto, nestas tecnologias, urge a

padronização dos diferentes dispositivos, já que cada fabricante tem tendência

a apresentar a sua tecnologia própria. Além disso, estes dispositivos têm a

grande vantagem de serem móveis e pessoais, podendo-se potenciar

características de georeferênciação e conteúdos de informação adaptados ao

local.

Vários estudos sugerem que, os serviços de Internet Móvel têm um

grande potencial, podendo ter uma grande penetração no mercado. Com a

evolução das redes móveis em termos de largura de banda, em conjunto com a

evolução dos Smartphones e PDAs, existirão serviços com maior capacidade

dos que existem actualmente. Combinando isto, com as tecnologias de

localização existentes é possível desenvolver um conjunto de aplicações

interessantes, com diversas funcionalidades.

Nos sistemas de rede fixa tradicionais, a localização de um terminal era

já conhecida e por períodos de tempo longos. Nesta nova era, a da mobilidade,

a posição de um terminal é muito variável, surgindo uma nova gama de

problemas e oportunidades a ter em conta. O uso de sistemas que exploram a

posição de um terminal, acompanhadas pela capacidade das redes móveis de

fornecerem dados, pode levar a uma prestação de serviços inovadores e

intuitivos que não estavam disponíveis no passado recente.

Com os recentes desenvolvimentos da tecnologia de localização de

dispositivos móveis, surge o aparecimento de serviços atractivos e com grande

potencial, que utiliza esse tipo de informação. Assim, surgem os serviços de

turismo móvel como uma das primeiras opções dos fornecedores.

Prefácio


Enquadramento

Este trabalho consistiu no desenvolvimento de uma plataforma de apoio

ao turismo e foi realizado em conjunto com um aluno de Mestrado em

Engenharia de Informática, Gustavo Fernandes.

O sistema desenvolvido, denominado Culture for Us consiste na criação

de uma aplicação móvel, que faz uso de algumas técnicas de localização, e na

construção de um servidor que serve de apoio à plataforma. Este tem de

conseguir, após a recepção da localização, devolver e colocar informação

consoante a localização do dispositivo, ou conseguir devolvê-la em tempo real

no próprio dispositivo. O desenvolvimento da aplicação móvel ficou a meu

cargo, bem como o design da página Web móvel que serve de apoio à

plataforma, sendo que a construção do servidor e das funções de acesso ao

mesmo ficou ao cargo do aluno Gustavo Fernandes.

A plataforma é baseada no modelo cliente/servidor, em que o cliente é

um turista e o servidor servirá de suporte, sendo a fonte de armazenamento de

conteúdos. O modelo está dividido em processos: processo de registo, processo

de pedido de conteúdos e processo de colocação de dados, como apresentado

na Figura 1.

Figura 1 Modelo Geral da Plataforma

Prefácio


O processo de registo tem como função indicar ao servidor informações

sobre o utilizador, tais como: nome, idade, entre outros. Este processo tem

como objectivo identificar o utilizador, criando uma conta para o mesmo, para

posterior colocação de dados relevantes. Ao finalizar este processo, o utilizador

pode começar a pedir e a colocar dados no servidor, como por exemplo, a

colocação da sua localização.

Os pedidos e colocação de conteúdos terão como base a localização

obtida pela aplicação instalada no dispositivo móvel do utilizador. Assim, após a

recepção da localização por parte do servidor, este conseguirá disponibilizar

informação adequada àquela localização, bem como associar à mesma

informação, o próprio utilizador e os dados que este queira colocar. Estes

poderão ser fotografias tiradas com o dispositivo móvel, em que o servidor

poderá associar uma localização às mesmas. Esta localização será enviada pela

aplicação, sendo que esta, também enviará a data e a hora do dispositivo.

Todo o processo de pedidos e colocação de conteúdos pode ser

resumido na Figura 2.

Figura 2 Processo de Pedidos e Colocação de Conteúdos

Prefácio


Objectivos

Este trabalho pretende servir de apoio a um projecto mais alargado,

pluridisciplinar no âmbito de uma plataforma de apoio ao turismo através da

rede móvel.

O Culture for Us é um projecto iniciado na Universidade da Madeira, que

visa construir uma plataforma de comunicação dinâmica para entrega de

informação e comunicação instantânea com turistas móveis. Assim, pretende-se

construir uma plataforma de comunicação entre dispositivos e a rede móvel,

com a capacidade de fornecer ao turista, informações turísticas de acordo com

a localização, bem como permitir outros serviços, tais como, a colocação de

mensagens e fotos visíveis a outros utilizadores da plataforma.

Introdução


1. Introdução

Actualmente existe um conjunto de tecnologias que permite a entrega de

informação até aos equipamentos móveis e respectivos utilizadores, com

diferentes desempenhos, qualidade e custos. Estas informações permitem às

operadoras uma nova oportunidade de negócio, como as aplicações com

conteúdo turístico.

Para a construção de um sistema de Location Based Services (LBS) para

Turismo, há que ter em conta os aspectos tecnológicos e de negócio que

suportam os LBS, a tecnologia usada, onde se estudam técnicas de localização

e transferência de dados, e por fim estudam-se possíveis serviços que um LBS

para turismo pode ter [1].

1.1. Aspectos Tecnológicos e de Negócio

Os serviços aplicados ao sector do Turismo estão intimamente

relacionados com o fornecimento de conteúdos. Estes conteúdos, abrangem

várias temáticas, como a cultura, transportes, eventos, emergências, entre

outros. No entanto, estes poderão levar o utilizador para outros serviços e

conteúdos, que inicialmente não estava interessado.

O desenvolvimento das tecnologias de informação tornou possível o

acesso à informação em larga escala. Assim, existe a possibilidade dos

utilizadores acederem a aplicações e informações dessa forma, através de

diversos canais, como a internet, rede móvel e interfaces de voz, facultando-se

assim uma arquitectura multi-canal. Com a evolução desta arquitectura,

possibilita-se a entrega de conteúdos de forma personalizada e adaptada às

capacidades dos dispositivos existentes, tais como, Smartphones, PDAs,

telemóveis, havendo a necessidade de incrementar o número de canais para a

divulgação dos mesmos.

Introdução


A tecnologia não é só a razão por detrás do conceito de Turismo. O

mercado móvel de segunda geração (2G) e segunda geração e meia (2,5G)

existente, chegou ao seu ponto de saturação como previsto, criando grandes

expectativas para a rede 3G e 3,5G [1]. No entanto os custos das licenças e do

desenvolvimento das redes 3G foram muito elevados, levando as operadoras a

grandes dificuldades económicas, tornando-se pessimistas na adopção da rede

[1]. Para ultrapassar esses factores, as operadoras viraram-se para a

investigação de novas oportunidades de negócio para as redes móveis sem fio.

Assim a prestação de serviços sobre redes 2,5G e 3G, não só permite que os

utilizadores e os prestadores de serviços tirem o máximo partido das infra-

estruturas existentes, mas também incentiva a sua utilização, aumentando as

expectativas para a próxima geração de redes móveis. Para prestar este tipo de

serviços, é necessária a integração de diversos componentes e serviços

adaptados ao local, indo contra as políticas da maioria dos MNOs, que

tradicionalmente têm uma posição conservadora, monolítica e contida [1].

No domínio LBS é comum que o protocolo de posicionamento e o

protocolo de localização estejam em linha com os conceitos actuais e

arquitecturas existentes. No entanto, a implementação de novos serviços, tais

como os LBS, terá de ter sempre em conta aspectos técnicos, económicos,

éticos e sociais.

Para construir um sistema para entrega de informações turísticas

baseadas na localização, é preferível e possível construir uma aplicação para

um utilizador final que esteja na vanguarda tecnológica, permitindo a

interoperabilidade entre sistemas de fornecedores de serviços, exploração de

futuras tecnologias de localização, cumprimento dos requisitos e normas de

qualidade de serviço, garantia de privacidade e implementação e actualização

de baixo custo dos serviços existentes, desde o 2G/2,5G até ao 3G/3,5G. Assim,

a oferta de conteúdo relacionado com o turismo abrange uma grande parte da

informação que é entregue através de location based services.

Introdução


1.2. Tecnologia

É fundamental analisar a tecnologia ou técnicas usadas num LBS, de

forma a se perceber como é que a conectividade irá se processar, permitindo a

entrega de dados a um dispositivo e como é que a localização irá ser calculada,

de forma a se conseguir posicionar um utilizador no espaço.

1.2.1. Serviços de Dados e Redes Móveis

Os utilizadores de telefones móveis, não utilizam somente os serviços de

voz que este faculta. Eles apreciam também outros tipos de serviços tais como:

serviços de informação (como tempo e notícias), serviços de entretenimento

(como chat e horóscopo) e por fim serviços de comunicação (como SMS, MMS e

e-mail).

Esta informação multimédia é transmitida através de canais de

comunicação, oferecidos pelas operadoras móveis. As tecnologias usadas são

GSM, GPRS, UMTS, HSDPA e WiFi.

O GSM é a segunda geração de redes telefónicas móveis. Originalmente,

esta foi desenhada para comunicações de voz, mas no entanto consegue

suportar transferência de dados a uma taxa de 9,6Kbits/s, sendo muito baixa

para aplicações multimédia.

O GPRS é um protocolo de comunicação de redes móveis, baseado na

mesma modulação do GSM e desenhado para complementar-se com este,

facilitando assim a transferência de dados na rede GSM. As taxas de

transmissão de dados que o GPRS pode atingir são na ordem dos 40kbits/s,

proporcionando também um acesso contínuo à Internet nos equipamentos

móveis. Este protocolo é conhecido também como geração 2,5G.

O UMTS é conhecido como a terceira geração de redes telefónicas

móveis. Utiliza modulação WCDMA, permitindo um aumento das taxas de

transferência de dados. Este possui diversas classes de serviço com diversas

taxas de transferência de dados, que vão desde os 100kbits/s até aos 2Mbits/s.

Introdução


Outra tecnologia, é o HSDPA, que é uma actualização da rede UMTS,

podendo actualmente atingir taxas de transferência de dados de 14,4Mbps/s. É

também conhecida como a geração 3,5G, beneficiando assim as aplicações que

requerem maior largura de banda, tais como Mobile TV.

Por fim existe o WiFi, que é um termo que se refere normalmente ao

protocolo 802.11. Este protocolo, tem na sua família outros protocolos, tais

como, o 802.11b e o 802.11g, que operam nas bandas de 2,4GHz e 5GHz.

Estes, são os mais populares da família 802.11, podendo atingir velocidades na

ordem dos 108Mbs/s. As redes WiFi são redes locais móveis, ou seja, são

restringidas a um edifício ou a uma determinada área, não oferecendo a

mobilidade que as redes celulares móveis disponibilizam.

Na Tabela 1, verifica-se de forma sistematizada as diferentes redes de

dados móveis e redes sem fio.

Tecnologia Desempenho Custo Cobertura Compatibilidade

GSM 9,6Kbps Elevado Global Muito Elevada

GPRS 40Kbps Médio Global Elevada

UMTS 220Kbps Médio Global Elevada

HSDPA 750Kbps Médio Global Elevada

WiFi 11Mbps Baixo Local/Interior Elevada

Tabela 1 Redes de Dados Móveis e Redes Sem Fio

1.2.2. Location Based Services

Os LBS, são uma classe de serviços que utilizam informações sobre a

posição do utilizador, para que os conteúdos dos serviços sejam entregues fácil

e intuitivamente.

Assim, um dos principais aspectos dos LBS é a localização. A maioria dos

LBS é categorizada em quatro aplicações de negócio: serviços de

monitorização, serviços de informação e serviços de entretenimento e diversão.

Os serviços de monitorização contemplam por norma os serviços de

emergência e de gestão de frotas. No caso dos serviços de emergência, a rede

Introdução


tem a capacidade de localizar pessoas que estão em risco ou desaparecidas,

dando-lhes a protecção necessária. Outra capacidade destes serviços é de

localizar objectos roubados, tais como automóveis. Já os serviços de gestão de

frota, têm como função coordenar sistemas de rádio-taxi, sistemas de

transporte entre outros, sendo que nestes casos a precisão da localização é

elevada.

Outro grupo de serviços inclui os serviços de informação, em que os

conteúdos relativos a uma localização são entregues ao utilizador. No entanto à

escala global, a precisão da localização não é o mais importante, mas sim a

forma como os resultados são apresentados. Este grupo tem serviços como

notícias locais, informações culturais e de eventos, entre outros.

Por fim, existe o grupo de entretenimento e diversão, que é uma nova

oportunidade de negócio, tendo actividades como chat entre utilizadores o que

se torna muito popular.

1.2.3. Técnicas de Localização

Informações turísticas adaptadas ao local, LBS, requerem o

posicionamento do utilizador móvel, com uma precisão variável. Isto não

significa que o posicionamento seja sempre requerido ou desejado para se

utilizar um determinado serviço, uma vez que se pode pedir uma informação

sem estar fisicamente presente no local.

Para obter-se a localização de um determinado utilizador, é necessário

que o mesmo esteja equipado com um dispositivo que tenha uma ligação a

uma rede ou infra-estrutura. Os elementos que compõem este agregado

poderão ser:

Equipamentos, como PDAs, telemóveis 2G ou 3G e receptores GPS, de

forma a obter-se uma localização; GPRS, UMTS;

Conectividade a uma Infra-estrutura, de forma unidireccional ou

bidireccional, utilizando sistemas como WiFi, GSM, GPRS, UMTS, entre outros;

Introdução


Infra-Estruturas, que poderão ser redes móveis ou fixas, como sistemas

de satélite (GPS), redes de dados e telefones móveis (GSM, GPRS, UMTS) ou

um conjunto de pontos de acesso (WiFi, Bluetooth).

O posicionamento pode ser definido em duas categorias, Activo ou

Passivo. No posicionamento Activo, o cliente é o único responsável pelo

processamento das estimativas de localização. No posicionamento Passivo, o

cliente é localizado sem intervir, sendo a própria infra-estrutura que ao extrair

informações do dispositivo do cliente, calcula o posicionamento do mesmo.

Existem também os denominados métodos híbridos, que aumentam a

precisão da localização bem como a disponibilidade dos serviços. Assim, surgem

os sistemas self-contained e os sistemas always connected. No caso dos

sistemas self-contained, como os sistemas de GPS integrados em PDAs ou

Smartphones, informações sobre serviços nessas aplicações estão guardadas no

equipamento, não sendo necessário se ligar ao exterior para obtê-las. Contudo,

o leque de serviços dessas aplicações é limitado, sendo a navegação o serviço

mais popular das mesmas. Já os sistemas always connected requerem o acesso

ao exterior para a troca de dados, podendo desta forma a aplicação adquirir a

posição do utilizador ou trocar informações para estimá-la e aceder aos

conteúdos dos serviços requisitados.

Assim, existem diversas maneiras para se obter a localização de um

utilizador, sendo os sistemas GPS, posicionamento GSM/UMTS ou WLAN os

sistemas mais populares.

1.2.3.1. GPS

O posicionamento através de GPS é calculado através de uma rede com

24 satélites. O dispositivo do cliente recebe sinais de vários satélites, sendo

necessários pelo menos três satélites para efectuar-se uma estimativa

bidimensional (Latitude, Longitude) e quatro satélites para que uma estimativa

tridimensional (Latitude, Longitude, Altitude) possa ser calculada. O intervalo de

tempo dos sinais é codificado, permitindo ao cliente calcular a distância a que

Introdução


está de cada satélite através da diferença de tempo entre os sinais enviados e

os recebidos. Para um posicionamento mais exacto, requer-se a combinação

das distâncias acima mencionadas para múltiplos satélites. Guardar as

coordenadas é uma forma de calcular a velocidade e a distância de um

utilizador GPS. A Figura 1.1 mostra como se processa a operação GPS.

Figura 1.1 Operação GPS

Um dos problemas dos satélites civis, consiste em possuírem um sinal

mais fraco que os satélites militares, tendo os primeiros uma potência na ordem

dos 50watts na frequência de 1575MHz. Pelo facto da sua potência ser mais

fraca, os sinais transmitidos por estes, não conseguem penetrar no metal ou

terra, penetrando no vidro e no plástico, prevenindo-se assim, o uso do GPS em

locais fechados. Outro dos problemas é o uso do GPS em ambientes urbanos

muito densos, por haver reflexões dos sinais em objectos sólidos e fenómenos

estratosféricos, resultando em estimativas erradas. Uma forma de resolver

estes problemas, é usar mais do que um satélite.

A principal vantagem do GPS é a precisão, podendo atingir nos sistemas

civis os 15m. Este facto aliado à simplicidade dos dispositivos e à

disponibilidade dos serviços fazem com que as aplicações comerciais que o

Introdução


usem tenham grande sucesso, como por exemplo a navegação para turistas. A

grande desvantagem deste sistema é de o GPS ser controlado pelo

Departamento de Defesa dos Estados Unidos da América.

O sistema GPS possui uma rede suplementar para que o sistema esteja

disponível aquando da falta de cobertura de satélite.

Para garantir a total independência do GPS norte-americano, a União

Europeia propôs a implementação de um GPS Europeu, o Galileu, uma vez que

a precisão do GPS americano pode variar sempre que a administração norte

americana o queira. Um exemplo flagrante foi em 1991, aquando da Guerra do

Golfo, o GPS ter estado inacessível aos Europeus. Assim, o Galileu

proporcionará uma precisão com uma margem inferior a um metro.

1.2.3.2. Posicionamento GSM/UMTS

O Posicionamento GSM/UMTS é facultado pelas operadoras móveis. A

operação é baseada no facto de haver uma informação sobre a localização de

um dispositivo GSM/UMTS, para que a rede possa entregar dados ao

dispositivo. Como esta é originada pela rede, pode levantar problemas de

segurança e privacidade, que pode ser ultrapassado em situações de

emergência, não se proporcionando o uso indevido desta operação.

Este tipo de posicionamento está quase sempre disponível, desde que

haja cobertura por parte da rede. No entanto dependendo da infra-estrutura de

rede e o método usado, a precisão da localização pode variar muito, variando

desde os 100m até aos 500m, podendo atingir até vários quilómetros. Devido à

sua baixa precisão, este posicionamento é pouco usado para aplicações que

necessitem de muita exactidão na localização, sendo usado para aplicações

interactivas.

Uma das técnicas usadas para obter o posicionamento, é o CellId, que

utiliza a informação dos elementos fixos da rede (neste caso as BTSs), para

identificar a localização dos equipamentos móveis, como se pode verificar na

Figura 1.2. Esta técnica pode ser combinada com uma outra, o Timing

Advanced (TA) para redes GSM e o Round Trip Time (RTP) para redes WCDMA,

aumentando-se assim a precisão. O TA é uma técnica que utiliza a informação

Introdução


de timing advance aplicada a redes GSM, que determina a que distância está

uma MS de uma BTS.

Figura 1.2 Cell ID ou Cell Id com TA

Outra técnica de posicionamento usando GSM/UMTS é o Enhanced

Observed Time Difference (E-OTD). É uma técnica mais complexa, que requer

LMUs, usadas para obter informações temporais exactas para redes

assíncronas. Este consegue aumentar a exactidão da localização, mas aumenta

também o custo da infra-estrutura. O E-OTD, bem como o Time of Arrival

(TOA), são métodos semelhantes GPS, sendo a localização de dispositivos

móveis calculada através do tempo de sinalização de duas ou mais estações,

como se verifica na Figura 1.3.

Introdução


Figura 1.3 Operação E-OTD

O Posicionamento GSM/UMTS nem sempre está disponível, uma vez que

está dependente das operadoras móveis. Devido aos problemas de privacidade

que este pode trazer, este tipo de posicionamento está envolto numa série de

regras e acordos.

1.2.3.3. Posicionamento WLAN

O Posicionamento WLAN é do tipo local, usando hotspots WLAN, que são

na sua maioria restritos a espaços interiores, como por exemplo edifícios. Esta

técnica é a principal candidata para ser usada em aeroportos, museus espaços

comerciais, entre outros, onde a rádio interferência não se coloca, devendo ser

precisa o suficiente para guiar um visitante dentro dessas áreas. A localização é

calculada de forma muito semelhante ao Posicionamento GSM/UMTS e GPS,

usando a diferença de tempo entre sinais de algumas posições conhecidas.

Neste posicionamento, a informação sobre a estrutura física da área alvo

é crucial, de forma a se obter resultados mais confiáveis. O custo desta técnica

é razoável, uma vez que a infra-estrutura e equipamentos são acessíveis e

usados para aplicações que requerem o uso de uma rede de dados.

Introdução


Assim, cada método apresentado tem vantagens e desvantagens. No

entanto, o GPS parece ser o mais bem posicionado quando se fala em

posicionamento global, mas métodos como GSM/UMTS e WLAN podem ser

melhores para outro tipo de aplicações. Na Tabela 2 exemplifica-se uma

descrição do desempenho, implementação e custos dos diversos métodos.

Cell ID + TA E-OTD GPS Híbrido

Precisão 100m – 10Km 100m – 500m 10m - indefinido 1m – 100m

Requisitos Móveis Nenhum Baixo Elevado Muito Elevado

Aplicabilidade Boa Má Muito Boa Boa

Área de Aplicabilidade Urbana Densa Urbana/Urbana

Densa Suburbana

Interior

Exterior

Cobertura Elevada Elevada Parcial Elevada

Qualidade Geral Pobre Média Elevada Excelente

Compatibilidade Média Pobre Integral Pobre

Tabela 2 Desempenho, Implementação e Custos dos vários métodos de Localização

Os diferentes serviços que podem ser implementados requerem maior ou

menor precisão do posicionamento do utilizador. Na Figura 1.4, apresentam-se

os diferentes serviços e o grau de precisão que estes necessitam. Analisando a

figura, verifica-se que serviços como eventos locais, meteorologia, sugestões,

notícias locais, são serviços que não requerem baixa precisão, salvaguardando

que como se pode verificar, os serviços de emergência estão na fronteira entre

a baixa e a elevada precisão. Serviços como a procura, localizador de amigos e

guia da cidade, são serviços que poderão ter uma baixa ou elevada precisão, ou

seja, um meio-termo, dependendo dos objectivos traçados para eles. Serviços

como emergência, gestão de frotas, e direcções requerem uma elevada

precisão exterior, porque ao gerir uma frota ou dar-se uma direcção a precisão

dessas informações terá de ser a mais exacta possível. Por fim, serviços como

exibições ou museus, têm de possuir uma elevada precisão interior, porque ao

visitar-se um museu as informações prestadas sobre o conteúdo deste terão de

ser a mais exacta possível, de forma a não se dar, por exemplo, uma

Introdução


informação sobre um quadro que não está relacionado com o que está a ser

visualizado.

Figura 1.4 Serviços LBS e Precisão de Localização

1.2.4. Terminais Móveis

O desenvolvimento de um LBS para Turistas de elevada qualidade,

pressupõe a existência de dispositivos com elevada capacidade de bateria,

processamento, memória, tamanho e peso. Actualmente existem quatro

categorias de terminais: telefones GSM padrão, telefones GPRS/UMTS,

PDAs/Smartphones e Laptops.

Existem duas categorias de telefones GPRS/UMTS, que são os baseados

em WAP e os baseados em HTML. Os primeiros oferecem capacidades para

consumo de informação WAP, ou seja, sítios WAP, enquanto os últimos trocam

informação em padrões Web, como os formatos HTML, JPEG, requerendo

também um servidor Web.

Introdução


Os Smartphones são a última geração de telefones móveis, equipados

com ecrãs grandes, processadores poderosos e com capacidades que até então

só se conseguiam fazer em computadores pessoais. Os PDAs são dispositivos

muito idênticos aos SmartPhones, destacando-se as capacidades de

apresentação e aplicações em vez da comunicação [1]. Ambos estão

normalmente equipados com browsers HTML, GPS, GSM e WiFi integrados ou

externos.

Por fim, existem os Laptops que são equipamentos que possuem todas

as capacidades avançadas de um computador em termos computacionais,

capacidade de armazenamento, tendo no entanto uma mobilidade limitada [1].

1.2.5. Software

O software usado nos LBS está dividido em cliente e infra-estrutura. No

caso da infra-estrutura o seu desenvolvimento poderá ser feito através de todas

as tecnologias Web existentes, não apresentando assim grandes limitações. Já

no caso do cliente, o desenvolvimento das aplicações para dispositivos móveis,

têm algumas limitações. Assim sendo, surgem linguagens como Java Micro

Edition, Microsoft.Net e Symbian OS, que são específicas para o

desenvolvimento de aplicações para dispositivos móveis.

O Java ME é uma versão de Java específica para dispositivos móveis,

com menores capacidades de processamento e armazenamento, quando

comparados com computadores pessoais. É um ambiente que proporciona um

conjunto de ferramentas que são típicas de Java para computadores pessoais,

proporcionando também um conjunto de capacidades para micro dispositivos.

Este tipo de linguagem é muito comum em dispositivos 2G e 3G, tal como em

PDAs.

O Microsoft.Net Compact Framework é uma versão do Microsoft.Net em

plataforma Windows. Esta versão só está disponível para PDAs ou outros

dispositivos que utilizem plataforma Windows, sendo o seu desempenho muito

promissor. Utiliza algumas classes e bibliotecas do.NET Framework, sendo que

algumas dessas bibliotecas foram desenvolvidas especificamente para

Introdução


dispositivos móveis. No entanto algumas destas bibliotecas são mais simples

que as do .NET Framework, de forma a ocuparem menos espaço. Os

dispositivos, onde podem ser instaladas aplicações desenvolvidas nesta

linguagem, terão de suportar Microsoft.NET Compact Framework. De referir

também que estas aplicações podem ser instaladas em computadores pessoais

que tenham .NET Framework instalado, desde que tenham sido usadas

bibliotecas partilhadas por ambas as plataformas. No entanto, a sua interface

gráfica não pode ser actualizada para aplicações de Desktop.

Já o Symbian OS, foi especialmente desenhado para telefones móveis,

que têm recursos limitados e podem estar ligados durante meses sem nunca

serem desligados. Este sistema dá grande ênfase à conservação de memória,

com expressões de programação específicas para Symbian. Existem também

várias técnicas de conservação de espaço em disco e de controlo de

processamento em que o processador é desligado quando uma aplicação não

necessita do mesmo. Existem várias versões deste sistema operativo, o S40,

S60 e S80, sendo a S60 vocacionada para Smartphones. Esta última apresenta

três versões comercializadas. Este sistema operativo possui uma linguagem

nativa para desenvolvimento de aplicações por entidades externas,

denominando-se Symbian C++. De forma a manipular as excepções e gerir a

memória dos dispositivos, o Symbian C++ oferece uma série de conceitos

diferentes do C++ padrão. Esta linguagem quando comparada com outras

disponíveis para dispositivos Symbian, oferece aos programadores um acesso

mais compreensivo às funcionalidades dos dispositivos, permitindo um

desenvolvimento de aplicações mais eficiente e eficaz. A plataforma S60

proporciona uma variedade de APIs para UIs S60, aplicações, tecnologias e

frameworks.

1.3. Serviços Móveis Para Turismo

O conteúdo para Turismo pode ser qualquer um que seja do interesse de

um visitante a um local. Este poderá ser estático (mapas), dinâmico (trânsito),

cultural (museus), informativo (tempo), ou comercial (restaurantes), tendo uma

Introdução


grande procura sobretudo quando um consumidor visita um lugar em

particular.

Neste contexto, o termo “Turista” é vagamente relacionado com o típico

“Turista”, enquadrando-se principalmente com a definição de “utilizador de

equipamentos móveis”. Naturalmente que existem um grande número de

serviços que se enquadram neste cenário, tais como entrega de mapas,

informações arqueológicas, notícias de eventos, emergências, serviços de

saúde, informações sobre transportes, museus, entre outros. Todos estes

serviços que foram enumerados são serviços adaptados ao local para turistas.

Ao desenvolver-se uma plataforma capaz de suportar estes serviços, há

que ter em conta aspectos técnicos que têm de ser explorados, para que esta

seja aplicável. É necessário estudar possíveis restrições sociológicas, para que

estes serviços possam ser desenvolvidos e facultados. Por fim, é necessário

atingir os requisitos ou expectativas de consumidor final, para que a plataforma

tenha sucesso [1].

Ao implementar-se serviços adaptados ao local, existem pontos-chave

que terão de ser considerados na divulgação ao Turista:

QoS, como o tempo de resposta, disponibilidade ou cobertura;

Segurança, como autenticação e privacidade;

Procedimentos, como activação, preço, entre outros;

Recursos, como notificações e posicionamento;

Tecnologias Emergentes, como redes móveis e posicionamentos.

Inquéritos revelam que usuários já referenciados preferem serviços

intuitivos de baixo custo que satisfaçam as suas expectativas dentro dos limites

toleráveis de qualidade [1].

Em relação ao posicionamento, uma elevada precisão nem sempre é

fundamental. Por exemplo, ao se providenciar informações sobre transportes ou

direcções de serviços, o utilizador necessita apenas de um posicionamento

relativo. Por outro lado, ao exibir-se informações de algo que o utilizador está a

ver, não só requer um posicionamento preciso, como também informações

precisas, como por exemplo, ao visitar-se um museu.

Introdução


Outra questão que se pode levantar são os custos adicionais com

determinados requisitos, tais como a precisão do posicionamento ou alguns

conteúdos. Estes custos não são só em termos financeiros, como o custo do

GPS, mas também têm impacto na autonomia e dimensões dos dispositivos. Em

relação aos conteúdos, atente-se o exemplo dos serviços multimédia que

requerem uma elevada largura de banda e equipamentos avançados.

Ao localizar-se um utilizador, surgem novos problemas. Por exemplo,

para o utilizador obter a sua posição, este terá de pedi-la ou o sistema irá

facultá-la de forma automática e contínua? A localização contínua nem sempre

é necessária e poderá ser até enfadonha, uma vez que aquando de uma

mudança de posição do utilizador este poderá receber informações que não

pediu. Assim, uma boa prática, será o de evitar o posicionamento automático,

em vez de ignorar a informação da nova posição temporária do utilizador.

Apesar disto, existem sistemas que precisam de ambas as práticas.

1.3.1. Plataformas Existentes

Existem actualmente algumas plataformas de Apoio ao Turismo

estudadas e outras já implementadas.

Na literatura encontram-se diversas plataformas, realçando-se de entre

muitas, apenas cinco, Crumpet, The Guide, Intousys, Mobile Tour Guide e Es

Madrid”.

1.3.1.1. Crumpet

O projecto Creation of User-Friendly Mobile Services Personalized for

Tourism, Crumpet, é uma plataforma desenvolvida e validada por um consórcio

Europeu, constituído por quatro países: Alemanha, Finlândia, Reino Unido e

Portugal.

Esta plataforma tem implementado um sistema de serviços de apoio ao

turista adaptados ao lugar, numa arquitectura multi-agente, com o conceito de

mediação e interacção de serviços.

Introdução


A sua arquitectura (Figura 1.5) está assente em três estruturas:

Clientes Móveis;

Serviços Locais;

Sistema multi-agente, entre as duas estruturas referidas anteriormente,

que implementa os serviços integrados.

Figura 1.5 Arquitectura Funcional do sistema multi-agente CRUMPET

Os grandes objectivos do Crumpet, são a implementação e teste de

serviços para turismo, para utilizadores móveis de redes móveis ou fixas, tais

como, redes IP, WLAN, GSM, GPRS e UMTS, usando telemóveis de última

geração e PDAs. O outro objectivo é que a tecnologia desenvolvida tenha um

bom desempenho e aceitável por parte dos utilizadores, para que a aplicação

seja robusta e escalável.

O sistema oferece uma interface e um manuseamento de serviços

simples para o utilizador. As principais funcionalidades são:

Introdução


A recomendação de serviços ao turista, com base nos seus interesses

pessoais e posição;

Mapas interactivos, com capacidade de zoom;

Informações sobre atracções turísticas, indicando a direcção, mapa e

informações detalhadas;

Dar sugestões proactivas que poderão interessar ao utilizador, aquando

da aproximação de um determinado lugar.

1.3.1.2. The Guide

O projecto The Guide, foi desenvolvido com sucesso na Universidade de

Lancaster, para proporcionar aos visitantes da cidade de Lancaster no Reino

Unido, uma plataforma de apoio ao turista.

Este sistema faculta informações contextualizadas aos visitantes da

cidade. A informação é reportada ao turista, de acordo com o seu perfil e

contexto, incluindo a sua localização física.

Para servir de suporte aos serviços interactivos e às informações

dinâmicas do Guide, este utiliza tecnologias de grande largura de banda, o

CellId, infra-estruturas de redes sem fios e um sistema de localização adicional

GPS.

1.3.1.3. Intousys

O Projecto Intelligent Tourism System foi desenvolvido na Universitá

degli Studi di Salerno, com o intuito de criar uma plataforma cultural de apoio

ao turista. Esta tem associada três serviços: serviços de informação; serviços

personalizados e serviços de localização. Os serviços de informação têm como

objectivo facultar o máximo de informações úteis de forma simples e eficiente.

O sistema actua como um assistente para um turista que visite um lugar

cultural. O turista terá de ter um equipamento móvel, PDA ou telefone 3G

conectado à Internet através de GPRS/UMTS e ter um dispositivo GPS como se

pode ver na Figura 1.6.

Introdução


Figura 1.6 Sistema de Comunicação

Aquando, da primeira visita do turista ao sistema através de um browser,

este poderá descarregar a aplicação que garante a recolha de informação

geográfica e posterior envio à plataforma através de HTTP. No segundo passo,

a aplicação inquire o turista sobre os seus interesses culturais entre outros.

O sistema reconhece sempre o utilizador sempre que este liga o

equipamento ao mesmo, colocando a posição geográfica do turista. Outra

particularidade é a do turista poder interactuar com a plataforma, pedindo

informações sobre eventos culturais, hotéis, comércio, entre outros, sendo que

a resposta deste, tem sempre em conta a posição do utilizador. Mas, a

funcionalidade típica do sistema, é de identificar um lugar histórico sempre que

o turista está próximo deste, através das coordenadas geográficas.

1.3.1.4. Mobile Tour Guide

O projecto Digital Dunhuang Mobile Tour Guide (MTG) surge na China,

com o objectivo de construir uma plataforma de apoio ao Turismo, tendo por

base o famoso Templo Budista Dunhuang Mogao Grottoes.

Introdução


A plataforma tem por base as redes sem fios, comunicações móveis e

informações geográficas. Os dispositivos alvos são os PDAs, telemóveis e outros

dispositivos móveis.

A arquitectura proposta por este projecto (Figura 1.7), está assente em

cinco componentes: terminais móveis, servidor Web, servidor de localização,

servidor da aplicação MTG e base de dados do Digital Duanhuang. Os clientes

do MTG são localizados usando GPS, WiFi, ou outras técnicas de localização,

tendo por base uma interface gráfica.

Figura 1.7 Arquitectura MTG

A informação do posicionamento pode ser obtida usando SMS, MMS ou

através de um servidor de mapas remoto, acedido através de uma rede sem

fios.

O servidor Web foi construído usando Apache, Tomcat e IIS, estando

encarregue de aceitar, analisar e autorizar os pedidos dos clientes,

transmitindo-os através do protocolo http.

A informação de geo-localização das atracções é guardada no servidor

de localização. Um turista com um dispositivo móvel obtém essas informações,

enviando as coordenadas GPS, pela Internet móvel, até ao servidor que contém

a localização e descrição dos clientes.

Introdução


O servidor da aplicação possui o processador de serviços da arquitectura,

fazendo com que a aplicação MTG obtenha serviços de cultura, atracções,

análise de datas, entre outros.

A base de dados do Digital Dunhuang é o suporte de todos os serviços,

facultando o armazenamento e gestão de dados, tais como: imagens, texto,

vídeo e áudio.

Por fim, a aplicação desenvolvida para dispositivos móveis, foi

implementada usando a linguagem J2ME.

1.3.1.5. Es Madrid

A plataforma “Es Madrid” foi desenvolvida com o propósito de dar a

conhecer a cidade de Madrid aos turistas, através das memórias e comentários

colocados por estes. Assim, o objectivo é contar as histórias da verdadeira

cidade de Madrid do ponto de vista dos visitantes, documentando o que há e o

que é Madrid, dando assim a verdadeira essência da cidade. No entanto esta

plataforma foi concebida para ser acedida através de um computador pessoal.

No sítio da Internet que está totalmente operacional

(http://www.esmadrid.com), as pessoas falam da gastronomia, arte, tradições,

podendo também partilhar fotos e vídeos. Este inclui uma série de serviços ao

dispor, que podem ser consultados pelos turistas, tais como, meteorologia,

trânsito, transportes, agenda cultural, alojamentos, restaurantes, entre outros.

Culture for Us


2. Culture for Us

Neste capítulo, explica-se de forma clara o que é e com que intuito o

Culture for Us surge, bem como os dispositivos móveis que o podem utilizar,

explicando que requisitos estes terão de possuir e a razão da escolha de um

determinado tipo de telefone.

2.1. Plataforma

A plataforma surge, como já foi referido, na Universidade da Madeira,

com o propósito de construir uma plataforma para entrega e consulta de

informações turísticas de acordo com a sua localização. Esta tem como grupo

alvo, turistas, que consumem e colocam informação, pontos turísticos, que

informam e guiam, residentes e cientistas. Como conteúdo esta pretende ter

conteúdo geográfico, histórico, ecológico, geológico e episódico.

O Culture for Us tem como objectivo, não ser apenas um portal Web,

mas sim uma plataforma Web-based-service, que acede a uma base de dados,

oferecendo informações turísticas, e uma plataforma móvel a que o turista

consiga acedê-las tendo como base a sua localização, tempo, selecção e

interacção.

A plataforma pode ser acedida de duas formas. A partir de casa através

de um computador pessoal, onde o turista pode planear a sua viagem, antes de

viajar ou através de um dispositivo móvel, tal como Smartphone ou PDA.

Usando o acesso móvel, o turista pode seleccionar que informação quer saber,

tal como a sua localização, que serviços existem nesse mesmo local, ou mesmo

colocar detalhes da sua viagem com base nessa mesma localização.

O dispositivo móvel do turista é usado para utilizar a plataforma, sendo o

serviço prestado através do posicionamento do utilizador. A informação dada ao

turista é específica da localização actual do mesmo, em que o posicionamento

será dado pelo próprio dispositivo que acedeu à plataforma. Esta irá oferecer

pontos turísticos, dando as moradas dos serviços pretendidos, tais como: bares

Culture for Us


e restaurantes, dando também uma perspectiva histórica desses mesmos

lugares, através de histórias contadas pelos locais, por exemplo.

Usando o seu dispositivo móvel e a capacidade deste para obter a

localização do mesmo, usando o GPS ou outra técnica, como por exemplo

informação de rede, o turista também poderá colocar informações

georeferênciadas sobre a sua viagem, como por exemplo fotografias da sua

viagem. Este tipo de informação, tem como objectivo o partilhar experiências

vividas durante a viagem com outros utilizadores da plataforma, bem como

identificar erros nesta, permitindo que o sistema esteja permanentemente

actualizado durante a sua utilização.

Outra funcionalidade que a plataforma pretende deter, é a possibilidade

de o sistema localizar os seus utilizadores, com o propósito de esta informação

ser utilizada pelas autoridades locais em caso de emergência.

Para além dos enormes recursos de dados desenvolvidos para turismo, a

plataforma pretende que a informação seja colocada de diversas maneiras.

Desta forma, a informação poderá ser preparada e colocada no portal através

de casa ou de um escritório, indicando qual a localização no mapa. Ser um

fornecedor de conteúdo para o portal, não se limita apenas a pessoas do ramo

turístico, podendo a plataforma estar aberta a indivíduos que necessitam e

queiram comunicar com turistas, quer por razões de negócio ou por lazer.

Outro aspecto que a plataforma pretende facultar, é a possibilidade de

esta informar o turista sobre determinado serviço por iniciativa própria, ou seja,

informação que poderá ser automaticamente enviada para o turista, aquando

da sua chegada a um determinado local. Esta informação poderá ser

seleccionada através da subscrição de diversos eventos por parte do turista,

como por exemplo, as condições meteorológicas de determinado lugar ou o

aconselhamento para uma determinada visita a não perder.

Assim, a plataforma terá um grande potencial para aumentar a

interacção social, entre os turistas e os habitantes locais, oferecendo não só

tecnologia para as pessoas comunicarem, mas também juntando-as, pois

normalmente não têm essa oportunidade.

A arquitectura geral da ideia é ilustrada na Figura 2.1.

Culture for Us


Figura 2.1 Arquitectura da plataforma do Culture for Us

No entanto, a plataforma deu lugar a uma outra, o Madeira Life, em que

esta nova plataforma evolui ainda mais como rede social entre residentes e

visitantes. Contínua a ser um lugar onde se pode partilhar fotos e texto,

evoluindo, por outro lado, para a partilha de vídeo e áudio, associando estes

conteúdos a um determinado lugar. Esta pretende também facultar um novo

espaço em que as pessoas podem ler comentários sobre o lugar onde está,

ouvir histórias sobre esses lugares, visualizar vídeos e até obter informações

sobre compras e novas promoções. Esta nova plataforma é uma colaboração

entre o Lab:Use, Madeira Tecnopólo, ZON Madeira e Carnegie Mellon

University.

2.2. Comparação com Plataformas Estudadas

Comparando o Culture for Us com as plataformas já faladas, verifica-se

que todas têm como principal objectivo a interacção de um utilizador, turista,

com o seu telefone móvel, com excepção do Es Madrid. Todas têm em comum

o facultar a localização do turista, serviços contextualizados de apoio ao turismo

Culture for Us


com base na localização e recomendação de serviços aos turistas. Assim sendo,

o Culture for Us, tem como principal diferença a possibilidade de o utilizador

poder interactuar com a plataforma, tornando-a mais do que uma plataforma

de apoio ao turismo, aumentando desta forma a interacção social. Há que

destacar a possibilidade de o turista poder colocar informação georeferenciada,

fazendo com que este possa partilhar as suas experiências com outros

utilizadores ou até mesmo com os seus amigos. Outro aspecto relevante e que

difere das plataformas estudadas, são as diferentes formas de colocação de

informação, que não se confere apenas a fornecedores de conteúdo turístico,

estando também aberta a indivíduos que necessitam e queiram comunicar com

turistas, quer por razões de negócio ou por lazer. Assim, esta consegue ser

uma mistura de todas as plataformas apresentadas anteriormente, ou seja, em

termos de conteúdo para turismo é parecida com as plataformas Crumpet, The

Guide, Intousys e Mobile Tour Guide, sendo que apresenta semelhanças com o

Es Madrid, no que concerne à interacção a plataforma, tornando-se assim,

potencialmente, uma plataforma mais completa que todas as outras estudadas.

2.3. Dispositivos Móveis

Para a construção de um LBS, tem de se ter em conta os dispositivos

alvos, como já foi mencionado no capítulo anterior. Assim, a plataforma Culture

for Us foi desenvolvida tendo como alvo Smartphones com Sistema Operativo

Symbian S60 3ª Edição.

A escolha deste tipo de Smartphone, deve-se ao facto dos Smartphones

com Sistemas Symbian S60 possuírem a liderança do mercado, ganhando

progressivamente posição e volume de mercado. Até ao final do mês de Junho

2008, tinham sido vendidos mais de 180 milhões de telefones S60, sendo um

terço deste valor, dispositivos S60 3ª Edição [11]. A Figura 2.2 demonstra as

diversas cotas de mercado dos diferentes Sistemas Operativos existentes para

Smartphones e PDAs.

Culture for Us


Figura 2.2 Cotas de Mercado dos Sistemas Operativos Móveis

Outro factor é de o Symbian S60 estar licenciado a quatro fabricantes de

telefones móveis mundiais, a Nokia, LG Electronics, Lenovo e Samsung,

potenciando assim o leque de modelos e tecnologias à escolha.

O Symbian S60 faculta aos programadores, múltiplos canais de

desenvolvimento, como também reduções de tempo e custos para o

desenvolvimento de aplicações, uma vez que proporciona uma plataforma de

APIs uniformizada, uma vasta disponibilidade de ferramentas e SDKs e por fim,

um ambiente de desenvolvimento estável e seguro.

Na escolha do telefone não se tem, apenas em conta, factores de

negócio e implementação, existindo igualmente outros factores importantes.

São o caso das tecnologias de acesso, o browser, a câmara e a possibilidade de

uso de GPS, uma vez que todos estes itens têm um grande peso na construção

de um LBS.

Os telefones Symbian 3ª Edição suportam múltiplas tecnologias de

acesso, tais como, GSM, GPRS, EDGE, WCDMA, HSDPA e WLAN,

Culture for Us


proporcionando, assim, um vasto role de opções de acesso e velocidades à rede

e ao exterior.

O browser do Symbian S60 3ª edição oferece um conjunto de

componentes open-source de grande desempenho e bom conteúdo Web. Este

suporta padrões de Internet móvel, tais como: WML, XHTML MP e CSS.

A aplicação de câmara dos S60 3ª Edição, proporciona não só a captura

de fotografias, mas também a gravação de vídeos. Os vídeos e as fotos são

guardados na aplicação galeria, podendo ser editadas e geridas através de uma

vasta gama de funcionalidades, tais como, corte de imagens, redução do

tamanho, redução de olhos vermelhos, entre outros.

Este software permite, também, que os fabricantes possam colocar

vários tipos de tecnologias nos seus telefones, garantindo o acesso a estas.

Assim, é possível, aos fabricantes, integrarem nos telefones tecnologias como

GPS e WLAN, existindo, já no mercado, vários modelos de telefones S60 3ª

Edição com GPS integrado.

Assim, preferencialmente, os dispositivos deveriam possuir um módulo

de GPS integrado, para facultar uma posição mais exacta do utilizador, não

sendo este um requisito fundamental, dado que o programa desenvolvido

obtém a localização do utilizador usando, não só, o GPS. Outro aspecto é de o

telefone a ser usado na plataforma ter de possuir uma câmara fotográfica

incorporada, para que seja possível georeferenciar as fotografias capturadas

pelo turista. Outro requisito do telefone, é que este possua acesso UMTS,

fazendo com que a colocação das fotografias no servidor seja relativamente

mais rápido, do que o 2,5G, ou então que tenha também um acesso WiFi, para

que seja possível utilizar-se uma tecnologia em que o acesso é mais rápido. Por

último, e igualmente decisivo, o facto de o telefone do utilizador ter

necessariamente software S60 3ª edição, uma vez que a aplicação foi

desenvolvida para este tipo de sistema.

Modelização do Sistema


3. Modelização do Sistema

O modelo proposto consiste numa aplicação a ser instalada num

dispositivo móvel, com a função de obter a localização dos dispositivos, e numa

página Web de apoio compatível com estes. Assim, abordou-se a

implementação da plataforma de forma vertical, de forma a se tentar construir

uma base sólida para uma futura evolução e crescimento do Culture for Us.

A construção da aplicação móvel, o desenho e implementação da página

Web, numa linguagem suportada pelos browsers dos dispositivos móveis,

ficaram ao meu encargo, ou seja, a camada de apresentação do modelo MVC.

Já a construção da base de dados e do servidor de apoio à aplicação, e página

Web móvel, foram desenvolvidos pelo aluno Gustavo Fernandes, ou seja, as

camadas de modelo e controlo do modelo MVC.

Deste modo, a aplicação a ser desenvolvida deverá obter dados de

localização do dispositivo e disponibilizá-los de forma a serem recolhidos pelo

servidor, e posteriormente, guardados na base de dados.

A página Web móvel foi construída com o intuito, não só de disponibilizar

a aplicação de localização, mas também, de ser um apoio efectivo na

localização e disponibilização de serviços.

Antes da construção de software, devemos analisá-lo de forma a se

conseguir ter uma noção do domínio deste, dando assim a possibilidade da

construção de modelos. Estes proporcionam a interacção com o sistema e um

conhecimento global deste.

Assim, usa-se a modelagem de software, que é a actividade de construir

modelos, permitindo a identificação das características e funcionalidades que o

software deverá fornecer e o planeamento da construção deste. Normalmente,

a modelagem implica o uso de modelos gráficos que exemplificam os

componentes de software usados, bem como as suas relações. No entanto, a

modelagem de programas orientados a objectos, pode ser implementada

através de linguagem UML (Linguagem de Modelagem Unificada).



Um factor a ter em conta será o aspecto de padronização e organização

do código, realizado através do uso do modelo MVC (Modelo Vista Controlador),

que por ser uma arquitectura em camadas, separa responsabilidades de forma

a desenvolver uma aplicação sólida e escalável.

Desta forma, neste capítulo, pretende-se fazer uma análise do sistema

construído, usando:

Diagrama de Casos de Utilização;

Diagrama de Actividades;

Cenários de Utilização;

Diagrama de Sequência;

Modelo MVC;

Diagramas de Entidade-Relação.

3.1. Arquitectura Proposta

A arquitectura proposta consiste num turista com um telefone móvel

equipado, ou não, com GPS, numa rede móvel, servidor de localização/Web,

numa base de dados de ponto geográficos externa e numa base de dados da

plataforma. Na Figura 3.1, exemplifica-se a arquitectura proposta.



Figura 3.1 Arquitectura Proposta

(1) O cliente com um telefone móvel tem como suporte uma

aplicação que obtém a sua localização através de GPS ou pela BTS a que está

ligado, enviando posteriormente esses dados por http até ao servidor da

plataforma. Este tem ainda disponível uma página Web desenhada para

dispositivos móveis, que serve de complemento à aplicação.

Os dados poderão ser enviadas através de GPRS/UMTS, ou por

WiFi, desde que o dispositivo esteja equipado com uma WLAN.

(2) O Servidor Web/Localização será construído usando Apache e é

responsável por aceitar, enviar, e autorizar os pedidos dos clientes,

transmitindo-os através de http. Este também é responsável pela ligação a

servidores e base de dados externos, processando as respectivas respostas.

(3) O Servidor de GPS é um servidor externo, contactado pelo

servidor Web/Localização, para obter os mapas da localização exacta do cliente



através das coordenadas de GPS obtidas pela aplicação oferecida pela

plataforma. Os servidores que irão ser usados são os do “Sapo Mapas”, “Yahoo”

e “Google Maps”.

(4) A base de dados do Culture for Us, será construída em SQL. Esta

é responsável por guardar todas as informações dos clientes, tais como: o

número da BTS a que este está ligado, nome de utilizador, senha e

coordenadas de GPS. Esta base de dados é também responsável por armazenar

os serviços disponibilizados pela plataforma e as localizações associadas às

BTSs.

(5) A base de dados de pontos geográficos está situada no

Geonames.org, que é uma base de dados externa onde se encontram diversos

pontos geográficos de vários países, estando disponível para ser consultada.

A abordagem feita para a construção desta plataforma, como se pode

constatar, foi vertical, podendo-se posteriormente desenvolver cada uma delas

de forma mais aprofundada. Tentou-se assim construir uma base de

desenvolvimento sustentada e sólida.

3.2. Diagrama de Casos de Utilização

O modelo de casos de utilização num sistema é utilizado para

exemplificar os seus actores, (chamados também de tipo de utilizadores),

sendo os casos de utilização a relação entre eles. Neste caso, os actores esta

plataforma serão os turistas que irão usufruir desta.

O esquema é utilizado para mostrar as funcionalidades e utilidade que o

sistema possuirá, embora não descreva os detalhes internos de como isso

deverá ser realizado, sendo identificado no contexto com quem interage

(actores) e qual é a finalidade (casos de utilização). Na figura 3.2 pode ser

observado o modelo referente ao desenvolvimento da plataforma Culture for

Us.



No sistema temos os seguintes actores: Visitante e Cliente, onde cada

utilizador tem acesso a diferentes funcionalidades ou interacções dentro do

sistema. A relação entre o “Visitante” e o “Cliente” é a relação entre uma

entidade mais genérica e uma entidade mais especializada, onde o “filho”

(Cliente) herda o comportamento, dos casos de utilização do “pai” (Visitante),

sendo possível o filho intervir em qualquer contexto que o pai interagir.

Na sequência da arquitectura proposta, verificou-se os possíveis casos de

utilização da plataforma, usando para o efeito os diagramas de Casos de

Utilização. Estes pretendem facilitar a comunicação com o cliente, para definir

numa etapa inicial do estudo, as características que o sistema deverá

implementar.

Figura 3.2 Modelo de Casos de utilização



3.3. Cenários Utilização

Os cenários são um conjunto de acções entre um sistema e um conjunto

de actores externos ao mesmo. É uma descrição que contém os intervenientes

no sistema, as acções que, por ele, podem ser efectuadas, os seus objectivos e

informações que o caracterizam. Estes podem ser descritos como narrativas,

storyboards, modelos em vídeo ou protótipos, podendo estar numa notação

forma, semi-formal ou informal.

As principais vantagens do uso de cenários são que com estes consegue-

se ter em conta o ponto de vista do utilizador, são fáceis de entender, são por

norma ciclos curtos e podem ainda servir de teste ao sistema.

Um exemplo de um cenário, poderá ser uma narrativa de uma interacção

humano - computador.

Para a construção e percepção da plataforma, construiu-se três

narrativas, tentando abranger o máximo de funcionalidades que o sistema pode

ter. Foi elaborado igualmente os diagramas de sequência desses mesmos

cenários, no Capítulo 3.4.

3.3.1. Cenário 1 – “Chegada à Região”

Um turista, após chegar à Ilha da Madeira, ouviu falar da cidade de

Santana e da plataforma Culture for Us, após conversar com um recepcionista

do hotel. O turista, ficou então interessado em conhecer a cidade, mas não

sabia que serviços existiam lá nem sabia como lá chegar, resolvendo então

consultar o sítio móvel do Culture for Us, através do seu telefone móvel. Mas,

para começar a usar a plataforma o utilizador teve de se registar no sítio móvel

do Culture for Us.

Após o registo, o turista visualiza a sua conta e ao vê-la entra na página

de pesquisa por nome. Aí introduz o nome da cidade, escolhendo também o

serviço de restaurante, pois pretende almoçar nessa localidade. O resultado da

pesquisa consiste no lugar que pretende visitar com a possibilidade de vê-lo no



mapa, bem como uma lista dos serviços escolhidos associados a esse mesmo

local.

Ao saber onde fica a cidade de Santana, o turista desloca-se a esta.

Aquando da chegada, depara com uma casa típica da região, tirando-lhe uma

foto com o seu telefone, com o intuito de a partilhar com os seus amigos e

familiares. Esta foto foi tirada com o seu dispositivo móvel e o turista sabe da

possibilidade de carregar fotos na plataforma (Culture for Us), podendo,

inclusive, estas ser associadas ao local onde foram tiradas. Para tal o utilizador

registou-se e após ter descarregado e instalado o programa de localização no

seu telefone, executou-o e autenticou-se no campo disponibilizado para o

efeito.

3.3.2. Cenário 2 - “Localização por BTS”

O turista do cenário anterior encontra-se num determinado local. No

entanto, não sabe a sua localização e pretende jantar num sítio próximo do

local onde se encontra. Então começa a executar o programa de localização no

seu telefone, autenticando-se, neste, e na página móvel do Culture for Us. A

consulta tem como objectivo saber onde se encontra e que serviços poderão

existir nesse lugar. Este verifica que se encontra na Penteada e selecciona o

serviço de bares e restaurantes. Como resposta obtém uma lista desses

serviços, com informação da morada e possibilidade de visualizá-los no mapa.

3.3.3. Cenário 3 - “Localização por GPS”

Um turista, com um telefone equipado com GPS, pretende saber

exactamente onde está. Como este não tem licenças para usar os mapas do

seu telefone, então decide usar a plataforma Culture for Us para o efeito.

Após o registo e instalação da aplicação, disponibilizada pela plataforma

para obtenção da localização, o turista executa-a e autentica-se, no campo

disponibilizado para o efeito. Após esses passos, ele carrega sobre o campo

“localização por GPS”, fazendo com que a aplicação obtenha as coordenadas do



lugar onde o turista se encontra. Após a obtenção destas, é devolvido pelo

programa o mapa do lugar actual do turista.

3.4. Diagrama de Sequência

Um diagrama de sequência na linguagem de modelagem UML representa

uma sequência de processos num programa de computador, para que se tenha

uma visão global do comportamento deste, uma vez que um projecto pode ter

uma grande quantidade de classes e métodos diferentes.

Este descreve a forma de como um grupo de objectos interactuam, entre

si, ao longo de uma execução do programa, analisando o comportamento dos

casos de uso e exibindo as mensagens passadas entre objectos nesses casos de

uso.

Assim, os diagramas de sequência não são mais que uma representação

em UML das acções, entre os diversos objectos de um cenário, dando destaque

à ordenação temporal em que as mensagens ou acções são trocadas entre

esses objectos.

Num diagrama deste tipo, tem-se em conta os conceitos de actores,

objectos, gate, fragmento e linha de vida.

Os actores são as entidades que usam o sistema, usufruindo das

funcionalidades do mesmo, gerando, assim, os eventos que iniciam os

processos.

Os objectos representam as instâncias das classes representadas no

processo, sendo descritos por rectângulos, compondo desta maneira uma

dimensão horizontal.

A gate aponta para onde pode ser transmitida a mensagem, pois esta

poderá ter dois sentidos, para dentro ou para fora da interacção.

Quanto aos fragmentos, existem diversos tipos, que são o alternativo

(Alt), opcional (Opt), parar (Break), repetição (loop), entre outros.

Por fim, a linha de vida representa a sequência de vida de um objecto

durante a interacção.

Logo, para os diagramas de sequência representarem o comportamento

entre um programa e os respectivos utilizadores do mesmo, desenhou-se três



diagramas deste tipo tendo em conta os três cenários descritos no Capítulo 3.3.

Em seguida, mostra-se nas Figuras 3.3, 3.4 e 3.5, os diagramas de sequência

alusivos aos diferentes cenários.

Figura 3.3 Diagrama de Sequência respectivo ao Cenário 1



Figura 3.4 Diagrama de Sequência do Cenário 2

Figura 3.5 Diagrama de Sequência do Cenário 3



3.5. Requisitos

Existem dois tipos de especificação de requisitos, os Requisitos

Funcionais e os Requisitos não Funcionais.

Os Requisitos Funcionais são aqueles que descrevem o comportamento

do sistema de forma completa e consistente, ou seja, descreve aquilo que tem

de ser feito por este. É também o que o utilizador espera que o sistema possa

oferecer, de acordo com os objectivos dele.

Os Requisitos Não Funcionais, expressam as restrições ou propriedades

do sistema, permitindo definir se este será eficiente na tarefa para que foi

concebido.

3.5.1. Requisitos Funcionais

Definiu-se um conjunto de requisitos funcionais para a página Web de

apoio e para a aplicação de localização.

A página Web de apoio deverá:

(1) Permitir o registo de utilizadores;

(2) Apresentar uma área de nome de utilizador e senha;

(3) Permitir o download da aplicação;

(4) Disponibilizar campo com a localização actual;

(5) Disponibilizar campo de procura de serviços;

(6) Possibilidade de carregar fotos e adicionar comentários às

mesmas;

(7) Associar um lugar a uma foto;

(8) Obtenção de um mapa através de coordenadas GPS;

(9) Apresentar fotos associadas à conta de utilizador, agrupadas por

lugar.

Por sua vez a aplicação de localização deverá:

(1) Apresentar uma área de introdução de nome de utilizador e

senha;



(2) Capturar a BTS a que o dispositivo está ligado;

(3) Enviar por http o número da BTS obtido para o servidor;

(4) Obter data e hora do equipamento móvel;

(5) Enviar por http data e hora obtidas para o servidor;

(6) Apresentar a lista de pontos de acesso que o dispositivo possui;

(7) Obter as coordenadas de GPS;

(8) Enviar por http as coordenadas adquiridas;

(9) Obter por http, como resposta ao envio das coordenadas, o mapa

respectivo às mesmas mostrando-o ao utilizador;

(10) Apresentar um conjunto de mensagens de controlo;

(11) Proporcionar um campo de ajuda;

(12) Permitir que a aplicação funcione em Background.

3.5.2. Requisitos Não Funcionais

Os requisitos não funcionais definidos para a plataforma foram:

(1) Servidor Apache com suporte para MySQL e PHP;

(2) Base de dados MySQL;

(3) Telefones Symbian S60 3ª Edição;

(4) Apresentação simples com interface amigável e fácil de

interpretar;

(5) Ser rápido, eficiente e robusto;

(6) Servidor GPS externo;

(7) Base de dados externa de pontos geográficos

3.6. Diagrama de Actividades

Usaram-se diagramas de actividades para exemplificar como são

processados os aspectos dinâmicos do sistema. Este é definido através do uso

da linguagem UML.

O diagrama de actividades pode ser visualizado essencialmente como um

gráfico de fluxo, que mostra o curso de uma actividade, conseguindo-se



modelar diferentes tarefas e operações. Neste caso, com a utilização de linhas

verticais de responsabilidade, foram divididas as acções em dois grupos, as

operações realizadas no cliente e as efectuadas no servidor.

Nas figuras seguintes visualiza-se os diagramas de actividades das

diferentes funcionalidades a ser implementadas na plataforma. Na página Web

de apoio deverão ser construídas as funcionalidades de Visualizar Localização

ou Serviços, Procurar Lugares ou Serviços, Colocar Fotos, Editar ou Visualizar

Fotos, Registo, Instalar Programa e Autenticação, sendo esta última comum à

aplicação e à página Web. Na aplicação deverão ser desenvolvidas as

funcionalidades de Iniciar obtenção da Localização e Localização por GPS.

3.6.1. Funcionalidades da Página Web Móvel

A funcionalidade de Localização pretende devolver ao cliente a sua

posição baseada nas informações recolhidas pela aplicação instalada no

telefone do cliente, ou seja, o número da BTS a que está ligado ou

coordenadas de GPS. Ao aceder a esta funcionalidade o utilizador não só obtém

a sua localização, como pode ser informado dos serviços disponíveis nessa

zona, facultando-lhe os contactos dos mesmos. Na Figura 3.6 apresenta-se o

diagrama de actividades da funcionalidade.



Figura 3.6 Diagrama de Actividades – Visualizar Localização/Serviços

A funcionalidade de Procurar Lugares ou Serviços, tem como

objectivo proporcionar ao cliente um motor de busca de diversos lugares, de

forma a facultar ao turista a possibilidade de procurar lugares que já conhecia o

seu nome ou que já tinha ouvido falar. Esta permite também restringir o raio da

pesquisa, bem como seleccionar os serviços que pretende conhecer. Assim, o

turista fica a saber onde se situa determinado lugar e que serviços existem,



podendo, igualmente, visualizá-lo no mapa. Na Figura 3.7, mostra-se o

diagrama de actividades da referida funcionalidade.

Figura 3.7 Diagrama de Actividades – Procurar Lugares/Serviços

A Colocação de Fotos visa dar ao cliente, a oportunidade de guardar

as fotos que tirou com o seu equipamento móvel durante a sua viagem. As

fotos estão agrupadas por lugar, desde que, no momento, em que tenham sido

tiradas, a aplicação de localização do turista esteja ligada. No caso de a

aplicação estar desligada, as fotos são na mesma carregadas pelo sítio de

internet, dando a oportunidade de o cliente criar um álbum fotográfico digital



online. Esta função dá também a possibilidade do utilizador comentar as suas

fotos.

Portanto, com a elaboração do álbum fotográfico por parte do turista,

este pode partilhá-lo com os seus amigos, familiares e outros utilizadores da

plataforma. Na Figura 3.8, é apresentado o diagrama de actividades da

Colocação de Fotos na plataforma.

Figura 3.8 Diagrama de Actividades – Colocar Fotos



A função de Editar e Visualizar Fotos, tem como objectivo dar ao

turista a possibilidade de gestão das fotos associadas à sua conta de utilizador.

Nessa gestão, oferece-se ao cliente, a possibilidade de fazer novos comentários

às suas fotos, eliminar as que não deseja, bem como visualizá-las, estando

estas organizadas por lugares. Na Figura 3.9, é facultado o diagrama de

actividades da referida função.

Figura 3.9 Diagrama de Actividades – Editar/Visualizar Fotos



O Registo foi criado para dar ao futuro utilizador da plataforma a

oportunidade de se registar nesta, usufruindo, desta forma, de todas as

funcionalidades nela existentes. Para o efeito, pede-se ao cliente que crie um

nome de utilizador e uma senha de acesso, de forma a poder-se identificar.

Neste processo, é criada, também, a conta de utilizador do cliente. Na Figura

3.10, pode-se verificar o diagrama de actividades da função.

Figura 3.10 Diagrama de Actividades – Registo

O acesso à conta do cliente é feito através da autenticação, bastando

para isso introduzir o nome de utilizador e senha, criados pelo utilizador no

Registo. Após a autenticação, o cliente não só terá acesso à sua conta, como

também, poderá começar a desfrutar da aplicação de localização,



disponibilizada pela plataforma e instalada posteriormente no seu telefone. Na

Figura 3.11, é apresentado o diagrama de actividades da Autenticação.

Figura 3.11 Diagrama de Actividades – Autenticação

A funcionalidade de Instalar o Programa, é uma das mais importantes

da plataforma, dado que dá a possibilidade ao utilizador de descarregar e

posteriormente instalar, o programa disponibilizado pela plataforma. Só após a

instalação da aplicação, é que um utilizador poderá ser localizado. Na Figura

3.12, mostra-se o diagrama de actividades referente a esta funcionalidade.



Figura 3.12 Diagrama de Actividades – Instalar Programa

3.6.2. Funcionalidade da Aplicação Móvel

Como já foi mencionado, inclusive pode ser constatado, no diagrama de

casos de uso apresentado na Figura 3.2, a plataforma móvel do Culture for Us,

é composta por uma página Web compatível com dispositivos móveis e uma

aplicação que é instalada no telemóvel. Até agora, mostrou-se os diagramas de

actividades das funcionalidades da página Web. De seguida mostrar-se-á os

diagramas de actividades da aplicação desenvolvida para o dispositivo móvel.

A funcionalidade de autenticação, tem como função o utilizador poder se

identificar na plataforma, como já foi mencionado. Esta função é idêntica à da

página Web.



Após a autenticação do cliente, este poderá usufruir de todas as funções

disponibilizadas pela aplicação, tais como: Localização por BTS ou por GPS. A

localização por BTS tem como objectivo capturar, a que BTS está ligado o

equipamento móvel do cliente, enviando, posteriormente por http o número

desta, bem como o nome de utilizador, a data e hora do dispositivo, em que foi

obtida a BTS. Estes dados são guardados na base de dados, associados à conta

de utilizador do cliente, para que este consiga consultar a sua localização na

página Web de apoio e também para que possa ter associadas às fotos a

localização de onde estas foram capturadas. Na Figura 3.13, apresenta-se o

diagrama de actividades desta funcionalidade.

Figura 3.13 Diagrama de Actividades – Localização por BTS



A Localização por GPS foi projectada para garantir um posicionamento

mais preciso do utilizador, desde que o dispositivo que possui esteja equipado

com um módulo de GPS. O processo é iniciado após o pedido de localização por

GPS, por parte do cliente. Assim, a aplicação activa o módulo de GPS, e após a

obtenção das coordenadas de latitude e longitude, estas são enviadas para o

servidor através de http. Depois de guardadas na conta de utilizador e

redireccionadas para o servidor de GPS externo, a aplicação obtém o mapa

correspondente às coordenadas e mostra-o em tempo real ao utilizador. Na

Figura 3.14 é apresentado o diagrama de actividades desta funcionalidade.

Figura 3.14 Diagrama de Actividades – Localização por GPS



3.7. Modelo Visualização Controlo

O Modelo Visualização Controlo (MVC) está encarregue de separar os

dados de uma aplicação, da interface do utilizador e da lógica de controlo, em

três componentes distintos. Estes componentes são a camada de Modelo,

camada de Apresentação e camada de Controlo.

A Camada de Modelo é aquela camada que especifica o domínio de

informação sobre a qual funcionará a aplicação, numa perspectiva de alto nível.

O domínio desta camada pode ser definido como o acesso às bases de dados e

funções que realizam a lógica do modelo. Desta forma, se eventualmente for

mudado o gestor de base de dados, só ficarão afectadas estas funções e não

toda a aplicação, possuindo-se assim um modelo bem delimitado que permite

que várias aplicações possam partilhar os mesmos dados.

Na Camada de Apresentação é onde são apresentados os dados do

modelo num formato adequado para interactuar com a interface do cliente.

A Camada de Controlo é a interface que faz a ligação da camada de

apresentação à camada modelo. É nesta interface onde serão processadas

todas as requisições. O controlo não acede directamente à base de dados, nem

gera HTML, limita-se a obter os valores e processar-lhes. Assim, toda a lógica

da aplicação é feita no controlo.

É possível encontrar diferentes implementações da arquitectura MVC,

onde o fluxo de controlo pode ser definido como o seguinte: o cliente interactua

com a interface do utilizador (ex: inserir informação num formulário), o

controlador recebe a notificação, faz a gestão do evento, logo, este acede ao

modelo actualizando-o ou até modificando-o de forma adequada com a acção

solicitada. A interface do utilizador espera novas interacções para recomeçar o

ciclo.

A arquitectura desta plataforma pode ser descrita pelo modelo MVC,

como se pode verificar na Figura 3.15. Assim sendo, a camada de Modelo é

constituída pelas bases de dados criadas para suportar a plataforma, que

permitirão manusear os dados de forma simples e organizada.



A camada de Apresentação possui todos os arquivos e Templates, que

possuem a informação para a exibição. Estes serão arquivos XHTML Mobile

Profile, arquivos CSS e também arquivos Symbian/C++, usados na criação da

aplicação para o dispositivo móvel, realizando assim o mapeamento adequado

da informação após a execução do modelo.

Por fim, a camada de Controlo, controlará todas as acções realizadas

pelos utilizadores.

Figura 3.15 Modelo MVC



3.8. Diagrama de Entidade Relação

Diagrama de Entidade Relação (DER) é um modelo conceitual, que tem

como objectivo efectuar uma simulação dos dados de diferentes perspectivas

(utilizador, gestor, analista), de forma a disponibilizar uma réplica teórica da

realidade. Este tem o intuito de possibilitar a formulação dos pressupostos

teóricos para a criação da base de dados.

O DER desta plataforma pode ser visto na Figura 3.16, mostrando-se

assim o modelo conceptual da base de dados da plataforma móvel. Para o caso

concreto desta plataforma, tem-se um conjunto de entidades (rectângulos) com

os seus respectivos atributos (oval), que interagem entre si através de

relacionamentos (losangos). As entidades criadas para o efeito foram as

seguintes: Conta, Utilizador, Localização, Serviços e Fotos.

Figura 3.16 Diagrama de Entidade Relação

Implementação da Arquitectura


4. Implementação da Arquitectura

Para a implementação deste tipo de plataforma, tem-se de ter em conta

uma série de questões, como, que tipo de linguagens usar, fundamentando o

porquê da sua escolha.

No caso da aplicação que obtém a localização do turista, teve-se em

consideração duas linguagens, o Java Micro Edition (J2ME) e o Symbian C++,

tendo-se optado por esta última.

No caso do desenvolvimento da página Web móvel, a dúvida consistiu no

uso do Extensible Hypertext Markup Language Mobile Profile (XHTML MP) ou no

uso do Wireless Markup Language (WML). Escolheu-se, então, o XHTML MP,

depois de uma análise cuidada dos prós e contras das duas linguagens.

4.1. Symbian C++ vs Java ME em Sistemas Operativos Symbian

Para a escolha da linguagem a ser utilizada na implementação da

aplicação de localização, optou-se por fazer primeiro uma análise entre as

linguagens Symbian C++ e o J2ME, por serem as duas plataformas mais

usadas no desenvolvimento de aplicações para dispositivos móveis [23].

Sabendo que o J2ME está a dar passos para a não fragmentação da

linguagem e que o Symbian faculta uma melhor usabilidade, existem, desta

forma, vários prós e contras, em ambas as linguagens.

O processo de escolha teve em atenção uma série de aspectos, tais

como: o desempenho, a instalação, o acesso a aplicações de sistema, a

portabilidade/fragmentação, a segurança, o tempo de aprendizagem e os

aspectos económicos.



4.1.1. Desempenho

Sabendo-se que o Symbian C++ é compilado directamente em

instruções ARM (Advanced RISC Machine). Este é o processador usado em

telefones móveis e PDAs, não sendo assim, necessária a interpretação das

instruções. Consequentemente, as aplicações em Symbian C++ têm um melhor

desempenho na globalidade, que as construídas em J2ME.

Por outro lado, o Java é uma linguagem interpretada, em que as

aplicações construídas nesta linguagem correm numa máquina virtual que

interpreta as instruções Java em instruções apropriadas ARM, sendo uma das

desvantagens desta linguagem. No entanto, é necessário salientar que o Java

foi concebido tendo em conta a portabilidade e a segurança, descorando um

pouco o desempenho.

Em relação ao tempo de espera para abrir uma aplicação, uma MIDLet

(aplicação Java ME), necessita de toda a máquina virtual binária, como parte da

sequência de iniciação. Mais, se a aplicação ainda não for residente, o

Application Management System (AMS), precisa de ser carregado, sendo esta

mais uma desvantagem. Obviamente que as aplicações nativas Symbian C++

não apresentam as mesmas desvantagens. Mas ser uma aplicação nativa, não é

garantia de rapidez de execução, porque o tempo também depende da

complexidade da aplicação.

4.1.2. Instalação de Aplicações

Uma aplicação deste tipo pode ser instalada no Sistema Operativo

Symbian através do SWInstaller. Isto pode ser feito directamente através do

ficheiro SIS, ou, implicitamente, através da instalação ou actualização de uma

aplicação no subdirectório “Importação”. Isto permite uma variedade de

soluções a ser facultada ao cliente.

No entanto, o mesmo não acontece com as MIDlets do Java ME. A

descarga de dados de uma MIDlet é possível através de um servidor remoto



(dados como jogos, áudio, entre outros), mas para se fazer uma actualização, a

nova versão terá de ser instalada sobre a antiga.

4.1.3. Desenvolvimento de Software em Symbian e Java

O Symbian oferece uma série de frameworks de desenvolvimento,

incluindo o controlo de recursos, acesso a informações de hardware e

informações de serviço, um modelo de segurança e suporte para uma

variedade de padrões industriais. Na tabela 3, apresentam-se as vantagens e

desvantagens do desenvolvimento de aplicações em ambas as linguagens,

Symbian C++ e Java.

Em relação às APIs existentes, as aplicações Java ME não podem tirar o

máximo partido de tudo o que uma plataforma oferece, e isso inclui os

Sistemas Operativos Symbian, em virtude de ser uma linguagem externa e

centralizada em JCP (Java Community Process). As APIs disponíveis em Java

ME, na forma de JSRs (Java Specification Requests), têm de ser comparadas

com as APIs nativas, disponíveis em C++.

Para quem desenvolve aplicações para telemóveis, ter acesso a APIs

nativas, permite uma melhor implementação, uma vez que estas estão melhor

integradas no Sistema Operativo. Tendo mais processos e controlo de memória,

como aceso a serviços de sistema, as aplicações nativas conseguem fazer uso,

de uma forma mais eficiente, de recursos como janelas, microfones e câmaras.

Ao contrário desta flexibilidade, o Java ME, requer o JSR para

desenvolver-se um projecto e caso este não exista para um determinado

fabricante, o desenvolvimento da aplicação terá de ser abortado, ou então terá

de se seguir uma estratégia híbrida para contornar a limitação.



Java ME Symbian C++

APIs

• Rico, fácil de usar, bem

documentada e familiar

à maioria dos

programadores;

• Desenhado entre várias

entidades, de forma a

garantir que estas se

adequam à maioria das

situações;

• Desenvolvimento 80%

mais rápido que em

C++ [23].

• Mais APIs para explorar;

• Maior número de APIs

significa que algumas

aplicações não podem

ser feitas em Java, tais

como o Skype.

Uso de memória e

bateria

• Sistema

instantâneo/limitados

recursos de gestão de

memória;

• Informação do estado

de bateria inacessível;

• Inexistência de controlo

de processos.

• Grande controlo sobre a

memória e criação de

processos;

• Grande potencial de

gestão de memória

usada, pois cada MIDlet

acedida requer uma

máquina virtual de

aprox. 1300k;

• Consegue aceder e

monitorizar o estado da

bateria;

Acesso a funcionalidades

do telefone

• Limitado no Java ME. • Processo de

intercomunicação,

acesso ao hardware,

controlando outras

aplicações nativas,

como o browser;

• Possibilidade de adição

de código assembler às

secções críticas de uma

aplicação.

Execução • Desempenho mais lento

que as aplicações

nativas.

• Aplicações C++ são

nativas, tendo um

óptimo desempenho.

Tabela 3 Capacidades das linguagens Java ME e Symbian C++



No entanto, o uso de APIs nativas poderá, também, ser um problema

para quem desenvolve aplicações, uma vez que esta poderá não ser compatível

com outros dispositivos, levando a problemas de portabilidade. É por isto, que o

Java foi concebido, tendo em conta uma plataforma comum,

independentemente das especificações de determinados modelos.

4.1.4. Portabilidade e Fragmentação

A fragmentação tem sido o maior problema do Java Me, isto pois,

aquando do surgimento dos primeiros dispositivos com Java ME no mercado,

surgiram igualmente diversas bibliotecas que abordavam as lacunas que a

linguagem entretanto tinha. Bibliotecas de desenvolvimento de jogos ou

multimédia surgiram antes de existir normas padrão entre os diversos

dispositivos. Outra razão é a implementação dos JSRs, que varia entre os

dispositivos, até entre telefones do mesmo fabricante. O não estabelecimento

de um conjunto de JSRs obrigatórios foi outra das razões para a fragmentação,

dado que os fabricantes escolhiam os JSRs a serem incluídos nos seus

telefones, consoante a estratégia definida para cada modelo.

Tem havido diversas tentativas de uniformizar o Java ME ao longo dos

anos. Embora a fragmentação continue, surgiu um novo JSR, o 248, que é

compatível com um largo número de telefones emergentes no mercado.

A fragmentação existe também no Symbian C++, mas numa menor

escala que o Java ME, sendo mais previsível, pois existem diversas versões de

Symbian. Refira-se que, existem diferenças substanciais entre sistemas

Symbian UIQ e Symbian S60, não sendo fácil converter um programa de um

sistema para outro.

Os custos associados à portabilidade de aplicações Symbian, para novos

telefones com o mesmo UI, são mínimos, pois os custos são essencialmente de

testes e ajustes. No caso do Java ME, a portabilidade entre os diversos

dispositivos é de 10 a 15% do orçamento inicial para o desenvolvimento da

aplicação [23].



A mudança de UI (por exemplo de S60 para UIQ), no caso do Symbian,

tem um custo associado de 25% do orçamento inicial, sendo este número

muito conservador [23].

4.1.5. Segurança

A usabilidade das aplicações Java pode ser posta em causa, com o

modelo de segurança usado para a certificação das mesmas, uma vez que pode

sobrecarregar o utilizador com diversos avisos.

A vantagem de usar-se aplicações nativas C++, é de estas possuírem

certificados Symbian, compatíveis com S60 e UIQ. Assim, assinando as

aplicações com esses certificados, garante-se ao utilizador uma boa

comodidade quer na instalação, quer na execução.

Presentemente, as políticas de segurança dos dispositivos MIDP 2.0

Java, depende da sua configuração, podendo forçar, inúmeras vezes, o

utilizador a confirmar, ou negar, o acesso a funções de mensagem, leitura ou

escrita de ficheiros, acesso à câmara e a funcionalidades de acesso à rede. Isto

depende de onde foram certificadas as aplicações e que restrições foram

colocadas pelo fabricante ou operador, colocando, outra questão de

complexidade, ao modelo de segurança.

Por outro lado, as assinaturas Symbian tornam a segurança das

aplicações em Symbian C++ mais pragmática. Estas somente têm de facultar

as funcionalidades que necessitam, sendo verificadas no acto na instalação.

Assim, as aplicações, que foram assinadas não têm de avisar o utilizador

quando acedem a APIs protegidas, proporcionando a este um maior conforto.

No subcapítulo, Funcionalidades Symbian, explica-se o que são estas

funcionalidades e para que foram criadas.



4.1.6. Ferramentas e Aprendizagem

A disponibilidade de ferramentas de desenvolvimento de aplicações em

Symbian C++ ou Java ME, não compromete nenhuma das linguagens, uma vez

que existem diversas ferramentas para desenvolver aplicações nessas

linguagens. Ferramentas como o Eclipse, Netbeans ou Sun’s Wireless Toolkit,

estão disponíveis para o Java ME, enquanto o Carbide, Visual Studio 2003 ou

2005 ou Metroworks Code Warrior, estão ao dispor do Symbian.

Em relação ao período de aprendizagem, o Java ME não é mais que uma

versão do Java Standard Edition, compilado numa máquina virtual. Desta

maneira, um programador com alguma experiência em Java, consegue

aprender sem qualquer dificuldade as bibliotecas, o design e estratégias do

Java ME, em alguns dias. No caso de um iniciante, desde que este tenha um

bom tutorial, consegue aprender em poucas semanas.

Já no caso do Symbian, a curva de aprendizagem é muito mais lenta,

fazendo com que programadores experimentados em C ou C++ tenham

dificuldades com os conceitos Symbian, tais como: controlo de memória, as

duas fases de construção e os objectos activos.

4.1.7. Análise Global

Fazendo um balanço da análise realizada às duas linguagens, verificou-

se que o Symbian é uma linguagem mais cara que o Java ME, para o

desenvolvimento de aplicações para dispositivos móveis. Outro ponto da

linguagem Java é que uma aplicação desenvolvida nesta linguagem poderá

correr numa larga gama de dispositivos, por esta ser uma linguagem

transversal a quase todos os fabricantes de telefones móveis. Assim, do ponto

de vista do retorno económico, o desenvolvimento de um projecto de

aplicações móveis em Java, consegue ter um mercado alvo muito mais alargado

do que as aplicações nativas.

No entanto, existem, também, muitas razões para se desenvolver

aplicações em Symbian C++, especialmente quando o desempenho é crucial ou



quando uma aplicação precisa de acessos de nível baixo a um conjunto de

serviços de um sistema operativo Symbian, tais como: mensagens de

subsistema, manipulação e conversação de imagens, acesso directo ao ecrã,

intercepção ou gestão de chamadas, obtenção de dados de rede, entre outros.

Como exemplo de aplicações desenvolvidas, o Google Maps foi

desenvolvido em Symbian C++, para telefones com sistema operativo Symbian,

sendo mais eficiente que a versão genérica Java ME, devendo-se em grande

parte à má gestão de memória do Java ME. Mais, a aplicação em Symbian

C++, permite escolher que mapas e rotas o utilizador quer guardar, possuindo

igualmente uma integração melhor com o módulo de GPS e um acesso mais

rápido aos endereços das localizações.

Assim, o Symbian C++ e o Java ME são duas linguagens que se

complementam uma à outra, sendo maduras, robustas e comercialmente

viáveis, havendo diversas razões para se escolher entre uma ou outra.

Portanto, para o desenvolvimento da aplicação da plataforma Culture for

Us, escolheu-se a linguagem Symbian C++. Especialmente, por esta permitir o

acesso de baixo nível ao Sistema Operativo Symbian, como por exemplo,

aceder a que BTS o telefone está ligado, bem como por esta conseguir validar o

requisito não funcional de construção de aplicação robusta, rápida e eficiente.

No entanto, segundo informações recolhidas em fóruns, diz-se que a última

versão de Java que começa a sair nos novos telefones, já permite recolher essa

informação [24], não tendo sido possível, no entanto, comprovar esse facto.

Nesses mesmos fóruns, é comentado também que essa informação não pode

ser obtida pelo dispositivo usado como teste, Nokia N95, para o

desenvolvimento da aplicação.

4.2. Funcionalidades e Assinatura Symbian

As funcionalidades e a assinatura Symbian complementam-se, na medida

em que algumas funcionalidades só podem ser acedidas após a assinatura da



aplicação. Se a aplicação possui funcionalidades básicas que não estejam

protegidas, então o programador apenas tem de seguir os testes padrão

Symbian, como auto-assinar a aplicação através do Carbide, por exemplo.

No caso de a aplicação necessitar de funcionalidades avançadas esta

terá de ser testada e assinada pela Symban, bastando para isso, obter-se a

assinatura através do Symbian Signed online, www.symbiansigned.com,

indicando quais as funcionalidades requeridas, após a obtenção e colocação do

identificador do programador (UIDs) na aplicação.

Existe também um conjunto de funcionalidades que estão protegidas

pelo fabricante, podendo ser acedidas após autorização do fabricante.

Assim, as funcionalidades são agrupadas em três grupos, básicas,

avançadas e protegidas pelos fabricantes.

As funcionalidades básicas são compostas por:

• LocalServices, que permite o acesso a serviços através de ligações

de curta distância, como, por exemplo, o Bluetooh ou

Infravermelhos. Estes serviços normalmente não têm associado

nenhum custo para o utilizador.

Um programa, com esta funcionalidade, pode normalmente enviar

ou receber informação através de uma porta série, USB,

infravermelho ou Bluetooh. Exemplos desses serviços são a

sincronização de dados com o PC, transferência de ficheiros, entre

outros.

• Location, que permite o acesso a dados de localização do

telefone, gerindo-os como coordenadas de GPS.

• NetworkServices, que permite o acesso a serviços remotos,

gerindo a entrega destes por GSM, CDMA, WiFi e todos os

protocolos IP de transporte, incluindo IP sobre Bluetooh (PAN

Profile), podendo trazer custos ao utilizador. Normalmente faz

com que o utilizador aceda a um serviço remoto, sem qualquer



restrição na sua localização física. Exemplos destes serviços são

chamadas de voz, SMS, ou serviços de Internet.

• ReadUserData, que dá acesso a dados confidenciais do utilizador

tais como: contactos, mensagens e notas. Para outros conteúdos,

como imagens e sons, a escolha poderá ser feita pelo utilizador.

• UserEnvironment, que acede a dados actuais do utilizador,

protegendo assim a privacidade deste. Exemplos de serviços

protegidos por esta funcionalidade são o acesso a áudio, imagens,

vídeos e dados biométricos.

• WriteUserData, que faz a gestão da integridade dos dados do

utilizador. No entanto, nem sempre está directamente relacionada

com o ReadUserData. Esta funcionalidade tem como objectivo

prevenir que um programa possa apagar algum ficheiro de música

por exemplo, mas poderá lê-lo.

Os programadores podem usar esta funcionalidade para controlar

o acesso aos seus dados, quando o programa está instalado em

directorias privadas.

Já as funcionalidades avançadas, são constituídas por:

• PowerMgmt, que tem como função abortar qualquer processo,

desligar qualquer periférico que não esteja a ser usado, colocar o

telefone em standby, ligá-lo ou desligá-lo completamente.

• ProtServ, que dá acesso à leitura de informação confidencial do

operador móvel, do fabricante e das definições do dispositivo.

Definições que não são confidenciais, não precisam de ser

protegidas por esta funcionalidade, como por exemplo o relógio

do sistema. Agora, informações confidenciais do dispositivo são

por exemplo a lista de aplicações instaladas ou o PIN.



• SurroundingsDD, que permite o acesso a drivers lógicos de

dispositivos que colocam informações circundantes ao telefone no

mesmo. Bons exemplos são drivers de GPS ou de dados

Biométricos.

• SwEvent, que permite simular a entrada de dados a partir do

teclado, capturando esses eventos a partir de qualquer programa.

• TrustedUI, que dá a possibilidade de criar sessões de UI

confiáveis, mostrando caixas de diálogo num ambiente de UI

seguro.

• WriteDeviceData, que permite escrever nas configurações do

dispositivo. Esta funcionalidade não está directamente relacionada

com o ReadDeviceData, isto porque os dados importantes de

sistema não podem ser alterados, podendo, no entanto, ser lidos.

Por fim, o último conjunto de funcionalidades são as protegidas pelos

fabricantes, sendo constituídas por:

• AllFiles, que dá permissões de acesso escrito e de leitura, a todos

os ficheiros de sistema, incluindo directorias privadas.

• CommDD, que proporciona o acesso directo a todos os

dispositivos de comunicação do telefone móvel.

• Drm, que dá acesso ao conteúdo DRM protegido. Os agentes DRM

usam esta funcionalidade para decidir se um programa poderá ou

não ter acesso a conteúdo reservado.

• MultimediaDD, que permite aceder a funções multimédia críticas,

tais como, prioridades de acesso a APIs multimédia.

• NetworkControl, que dá a capacidade de modificar ou aceder a

protocolos de controlo de rede.



• Tcb, que permite escrever em recurso executáveis e de leitura

apenas, como por exemplo nas directorias \sys ou \resources.

Esta é a funcionalidade mais crítica, pois permite a escrita de

executáveis, responsáveis pela segurança de um processo.

4.3. Processo de Construção de um Programa Symbian C++

Ao se programar em Symbian C++, é necessário ter em atenção como

um programa é constituído. Assim, será feita uma pequena abordagem de que

ficheiros constituem um programa, abordando-se apenas os mais importantes.

Em qualquer linguagem, tem-se de ter em conta o processo de

construção da aplicação, para implementá-la. Em Symbian C++, os programas

são escritos em C++, tendo o programa um conjunto de ficheiros C++. Numa

aplicação GUI (Grafical User Interface), normalmente são necessários pelo

menos quatro ficheiros: de aplicação, de controlo, de modelo e de

apresentação, ou seja, as quatro componentes do modelo MVC, tendo-se os

seguintes ficheiros C++: o C4UsApp.cpp, o C4UsDocument.cpp, o

C4UsAppUi.cpp e o C4UsView.cpp, respectivamente.

A figura seguinte, apresenta as classes atrás mencionadas, que dão

forma à aplicação.

Figura 4.1 Classes Básicas da Aplicação

A classe Application proporciona poucas funcionalidades, sendo

responsável por devolver o valor do UID3 da aplicação e criar a classe



Document. A classe Document é usada para criar a interface da aplicação,

AppUi. A classe AppUi é a classe central para a criação da interface do

utilizador. Esta não é visível, mas permite a visualização dos controlos do menu

e dos eventos associados às teclas do telefone. A classe View contém todos os

controlos que estão a ser vistos pelo utilizador. Por fim, o Model, não é uma

parte formal da estrutura da aplicação, mas poderá ser chamado pelas classes

Document, AppUi ou View, dependendo da aplicação.

A classe Application é a primeira classe a ser construída quando uma

aplicação é acedida, definindo, também, o comportamento da mesma. Esta tem

duas funções: tanto é como uma fábrica, que cria objectos do Document

concretos, tanto é como um fornecedor de funções úteis, não específicas de

nenhuma instância em particular do Document.

A classe Document é tradicionalmente usada para guardar dados da

aplicação num ficheiro, permitindo que estes sejam persistentes. Por exemplo,

um calendário precisa de ser persistente, para que os lembretes possam ser

colocados pelo utilizador e acedidos posteriormente. Adicionalmente, as classes

do Document são usadas para construir a AppUi. O sistema Operativo Symbian,

faculta uma classe Document abstracta, que específica uma série de funções

virtuais, que as classes que derivam desta, devem implementar, definindo o

comportamento básico das mesmas.

A classe AppUi é a classe central da interface de utilizador. Esta cria,

possui controlos para indicar os dados da aplicação e centraliza a manipulação

de comandos de entrada, tais como, menus e barras de ferramentas. Esta

classe não é visível, delegando o desenho das suas funcionalidades às classes

apropriadas. Assim, esta é responsável pela resposta a vários tipos de eventos,

geridos através de funções virtuais, tais como, o HandleKeyEventL(), que faz a

gestão de eventos de teclado; o HandleSystemEventL(), que faz a gestão dos

eventos de sistema; o HandleCommandL(), que faz a gestão dos comandos

definidos nos ficheiros de recurso, entre outras.



4.3.1. Ficheiros Recurso

Como já foi mencionado anteriormente, as classes acedem a ficheiros

recurso. Estes são obrigatórios em todas as aplicações Symbian, especificando

a informação sobre a aplicação e poderão conter componentes da interface de

utilizador que poderão ser mostrados. Estes ficheiros têm a extensão .rss.

É possível, também, carregar ficheiros de recurso adicionais,

dinamicamente durante a execução da aplicação, acedendo aos recursos

contidos nestes.

A livraria Uikon predefine várias estruturas de recursos que podem ser

usados normalmente neste tipo de ficheiro. Diferentes designs de UI, podem

ser adicionados a estas definições, de forma a personalizar a aparência dos

componentes da UI.

Entre os ficheiros de recurso, há que destacar os ficheiros .hrh, .rls e

menu.

Os ficheiros .hrh, são conhecidos como header files, e definem a

enumeração das constantes para os comandos das aplicações. Deste modo, só

haverá um único valor definido, desde que haja apenas um item menu na

aplicação.

Os ficheiros .rls, são também header files, sendo nestes que as strings

usadas na UI são definidas. Um exemplo de definição de strings é a seguinte

instrução:

#define qtn_caption_string "C4Usv6"

Outro ficheiro de recurso mencionado, são os de menu .rss, onde são

definidos os menus de uma aplicação, tais como, o menubar e o menupane. O

menubar específica o menupane a ser apresentado. O menupane define os

itens de menu de disponíveis numa aplicação. Estes itens, serão aqueles que

serão passados à função HandleCommandL(), onde o texto especificado em

cada item do menu, será o apresentado ao utilizador. Um exemplo da definição

do conteúdo de menu poderá ser o seguinte:



RESOURCE MENU_PANE r_menu {

items = { // added the new Options menu command here

MENU_ITEM {

command = ELogin; txt = qtn_login;

} }; }

Por fim, no acto da compilação, os ficheiros .rss, são compilados em

ficheiros .rsc, reduzindo o tamanho da plataforma. Adicionalmente, os ficheiros

.rsg, são gerados. Isto permite que cada recurso tenha um índice, permitindo

que estes sejam acedidos a partir do código C++.

4.3.2. Ficheiro MMP

O ficheiro .mmp, é o ficheiro responsável pela especificação das

propriedades de um projecto numa plataforma e compiladores independentes.

É neste ficheiro que se especifica o seguinte:

• Target Type, que especificam o tipo de aplicação, que para

versões de Symbian a partir da v.9.0, são “exe”;

• UID, que especifica os identificadores da aplicação. Existem dois,

identificadores da aplicação: o UID2, que define o identificador do

programador e o UID3, que identifica uma aplicação em

particular;

• Languages, que define qual a língua que é usada na aplicação;



• Stack Size, que define o tamanho da pilha, que por definição é de

8k;

• UI Resource, que define os ficheiros de recurso da aplicação, por

exemplo:

Start Resources <appname>.RSS Header TargetPath \Resource\Apps End

A instrução Header, diz ao compilador para produzir os ficheiros

<appname>.rsg

• Registration File, que especifica o ficheiro de registo da aplicação,

usando outro Start Resource. Por exemplo:

Start Resource <appname>_reg.rss TargetPath \prvate\10003a3f\apps End

• Source, que define as classes da aplicação, ou seja, os ficheiros

.cpp;

• Library, que especifica as bibliotecas usadas na aplicação.

4.4. XTHML MP vs WML

O Extensible Hypertext Markup Language Mobile Profile (XTHML MP) é

uma nova linguagem definida na especificação WAP 2.0, a mais recente

especificação de serviços móveis, criada pelo Fórum WAP (actualmente Open

Mobile Aliance, OMA). A especificação WAP CSS (WAP Cascading Style Sheet ou

WCSS) é também definida pelo WAP 2.0, sendo o WCSS o parceiro do XHTML

MP, uma vez que são usados conjuntamente. Com o WCSS, consegue-se

facilmente mudar e formatar a apresentação das páginas em XHTML MP.

O XHTML MP é um subconjunto da linguagem XHTML, sendo uma

linguagem HTML mais rigorosa. O XHTML MP é XHTML básico, também ele um



subconjunto do XHTML, mas com alguns elementos e atributos adicionais da

versão completa de XHTML.

O objectivo do XHTML MP é conciliar as tecnologias de Internet móvel

com as da world wide web. Antes do aparecimento do XHTML MP, os

programadores de WAP faziam uso do WML (Wireless Markup Language) e de

WML script, para a criação de páginas WAP, enquanto os programadores Web,

usavam HTML ou XHTML e estilos CSS, para construir páginas Web.

Assim, o surgimento do XHTML MP veio garantir a convergência entre as

tecnologias usadas para a criação de páginas Web e páginas WAP. Outro

aspecto relevante é a utilização do WCSS com o XHTML MP, que garante aos

programadores um melhor e maior controlo da apresentação das páginas WAP,

permitindo a separação do conteúdo e da apresentação em ficheiros diferentes,

pois como é sabido, os dispositivos móveis têm diferentes tamanhos de ecrã e

assim sendo, com esta separação, o conteúdo é apenas escrito uma vez e a

apresentação pode ser modificada de acordo com os diferentes dispositivos.

Portanto, alguém familiarizado com o HTML, XHTML e CSS, consegue

facilmente desenvolver uma página WAP com esta linguagem. Outra vantagem

desta tecnologia é das ferramentas de desenvolvimento poderem ser as

mesmas para ambos os ambientes (WAP e Web), levando a um menor custo e

tempo de desenvolvimento. Outro aspecto relevante, é a possibilidade das

páginas WAP poderem ser testadas em browsers normais, não substituindo,

evidentemente, um último teste antes da versão final, num browser de um

dispositivo móvel ou emulador. Outra vantagem é o de uma página

HTML/XHTML poder ser convertida para XHTML MP, através de alterações de

muito pouca relevância ou até mesmo nenhuma, não deixando de tomar em

linha de conta, o facto dessas páginas não excederem o tamanho máximo de

uma página para dispositivos móveis e de garantir, igualmente, que estas

tenham um bom aspecto num ecrã pequeno.

Todavia, o XHTML MP, também apresenta desvantagens, como algumas

funções que o WML dispõe e que não existem no XHTML MP. Dentro das

funções existentes no WML e que foram perdidas no XHTML MP, temos por

exemplo, o facto de este não suportar variáveis, sendo a solução guardar os



dados no lado do servidor; fazer Post com links anchor, sendo possível fazê-lo

no XHTML MP através de botões submit, entre outros. De salientar, que para

todas as funções perdidas, existe sempre uma alternativa no XHTML MP, para a

obtenção do mesmo efeito.

4.5. Implementação da Aplicação

Para a implementação da aplicação de localização, é necessário ter em

conta que linguagem usar para a construção e quais as técnicas de localização

que são mais adequadas.

Assim, para a construção da aplicação, a primeira coisa a ser reflectida

foi que técnicas serão usadas para a obtenção da localização. Escolheu-se

então, como já foi mencionado, no decorrer deste estudo, o posicionamento

por GSM/UMTS, que consiste na obtenção da BTS a que o telefone móvel está

ligado, e com essa informação conseguir-se facultar ao utilizador uma

localização aproximada de onde está, variando dos 100m até a algumas

dezenas de quilómetros, dependendo em que ambiente (urbano ou rural) o

utilizador está. As razões, para a escolha desta técnica, foram por esta estar

quase sempre disponível, desde que haja cobertura de rede, e por a maioria

dos serviços disponibilizados na plataforma não necessitarem de uma

localização muito precisa, como pode ser comprovado na Figura 1.4. A outra

técnica escolhida foi o GPS, de forma a se conseguir facultar uma localização

mais exacta ao utilizador, complementando desta forma o posicionamento por

GSM/UMTS.

Como já foi referido, nos capítulos anteriores, utilizou-se a linguagem

Symbian C++ para a implementação da aplicação. A escolha recaiu sobre o

Symbian, por esta linguagem proporcionar o acesso aos parâmetros de rede

(como por exemplo a BTS), fazer uma gestão de memória de forma eficaz,

entre outros.



4.5.1. Programação da aplicação móvel

Toda a aplicação foi construída tendo em conta a modelização do

sistema, descrita no capítulo 3. Como já foi mencionado, a aplicação de

localização tem como objectivo adquirir e fornecer dados suficientes para se

conseguir obter a localização do utilizador. Esses dados serão a que BTS o

telefone do turista está ligado e as coordenadas de GPS do mesmo, no caso de

o telemóvel possuir um módulo de GPS integrado.

Começando a descrever a aplicação, esta tem três funcionalidades:

autenticação, localização por BTS e localização por GPS. Todas elas têm em

comum um factor, pois utilizam o protocolo http/IP para a comunicação com o

servidor, ou seja, todas elas comunicam com este ou para obter informação,

que é o caso da localização por GPS e a autenticação, ou para colocar

informação, comum a todas. Assim, pode-se afirmar que toda a aplicação está

assente na construção do protocolo de comunicação, sendo este fundamental

para o funcionamento da aplicação.

4.5.1.1. Comunicação http

As transacções http implementadas foram as mais típicas, GET e POST.

Para isso, usou-se uma API disponibilizada pela Nokia [29], sendo esta a base

de construção da aplicação. Assim, a comunicação implementada apresenta

quatro conceitos chave:

• Sessões, em que o RHTTPSession encapsula toda a actividade

http do cliente, definindo as propriedades das transacções http,

tais como, protocolo, codificação e transporte.

• Transacções, em que o RHTTPTransaction representa a interacção

entre o servidor e o cliente http, consistindo num header http e

num corpo de dados. A transacção poderá ser também um pedido

ou uma resposta http, como definido no protocolo http. Esta é

executada de forma assíncrona e um mecanismo de callback é

usado para passar eventos das transacções, tal como, uma

notificação de sucesso quando um header é recebido.



• Header, em que o RHTTPHeader encapsula os headers de um

pedido ou resposta http, tais como, tamanho do conteúdo ou o

tipo.

• DataSupliers, em que as classes que implementam

MHTTPDataSupliers encapsulam o corpo de uma transacção de

qualquer pedido ou resposta.

Antes de se efectuar uma ou muitas transacções, uma sessão terá de ser

aberta. O RHTTPSession encapsula a actividade e propriedades do cliente, tais

como, os protocolos, durante a execução do cliente. O método usado para a

criação de uma sessão é o SetupConectionL(), descrito de seguida:

private RHTTPSession iSession; void CClientEngine::SetupConnectionL() { (…) iSession.OpenL(); (…) } CClientEngine::~CClientEngine() { (…) iSesion.Close(); (…) } Depois de aberta a sessão, as transacções podem começar a ser

efectuadas. Essas transacções serão feitas através dos métodos

IssueHTTPGetL() e IssueHTTPPostL(), métodos esses que implementam as

comunicações mais comuns do protocolo http. A estrutura destes métodos é a

seguinte, podendo ser vista na íntegra no Anexo A:

void CClientEngine::IssueHTTPGetL(const TDesC8& aUri) {

(…) }



void CClientEngine::IssueHTTPPostL(const TDesC8& aUri, const TDesC8& aContentType, const TDesC8& aBody) {

(…) }

Após a abertura de uma sessão, é necessário implementar uma classe

responsável por todos os eventos gerados por uma transacção, o

MHTTPTransactionCallback. Enquanto uma transacção está a decorrer, uma

framework chama os métodos MHFRunL() e MHFRunError(), disponibilizados

pela classe MHTTPTransactionCallback, responsáveis por notificar os eventos e

os erros de uma transacção. Assim, o MHFRunL() é a parte mais importante de

uma aplicação http, dado que neste método são recebidos todos os dados de

uma transacção. A estrutura típica deste método é a seguinte:

void CClientEngine::MHFRunL(RHTTPTransaction aTransaction, const THTTPEvent& aEvent) { switch (aEvent.iStatus) { case THTTPEvent::EGotResponseHeaders: {

(…) } break; case THTTPEvent::EGotResponseBodyData: { (…) } break; case THTTPEvent::EResponseComplete: {

(…) }



break; case THTTPEvent::ESucceeded: { (…) } break; case THTTPEvent::EFailed: { (…) } break; } }

O segundo parâmetro do método MHFRunL(), o THHTPEvent, contém os

eventos de uma transacção. Estes eventos são por norma muito úteis e nesta

aplicação foram usados e manipulados de acordo com os objectivos

pretendidos. Os eventos são:

• EGotResponseBodyData, responsável por receber parte do corpo

de dados, isto porque normalmente o corpo de uma resposta http

é recebida em pequenas tramas, fazendo com que o

EGotResponseBodyData receba múltiplas linhas. Este evento é

usado para formatar, capturar ou guardar os dados.

• EGotResponseHeaders, responsável por verificar se os headers já

foram recebidos.

• EGotResponseComplete, responsável por verificar se os dados de

um evento foram recebidos na sua totalidade.

• ESucceed, responsável por verificar se a transacção foi bem

sucedida.

• EFailed, responsável por verificar se a transacção foi mal

sucedida.



4.5.1.2. Obtenção dos parâmetros de Localização

Como já foi descrito, um dos métodos de localização do utilizador é o

Posicionamento GSM/UMTS. Este tem como principal elemento a obtenção da

BTS a que o telefone do utilizador está ligado naquele momento. Assim, a

classe implementada, para este caso, foi a CNetworkApp. Para a obtenção dos

parâmetros de rede, a Symbian disponibiliza uma biblioteca, a Etel3rdParty.

Nesta, estão descritos todos os parâmetros de rede, entre os quais, os usados

para a obtenção da localização do telefone. O método implementado, para

obter os parâmetros de rede, foi o seguinte:

void CNetworkApp::GetNetworkParameters( TUint& aCellID, TUint& aLocationAreaCode, TDes& aNetworkID, TDes&

aCountryCODE, TDes& aLongName) {

(…) }

Verifica-se que, os parâmetros pretendidos são o identificador da BTS,

aCellId, para que se consiga dar uma localização aproximada do utilizador, o

código da zona da BTS, aLocationAreaCode, para que seja possível saber a que

zona pertence a BTS, como por exemplo Madeira, o identificador do país,

aCountryCode, para que se saiba a que país pertence a rede e por fim o

identificador da rede, bem como o seu nome, iNetworkId e aLongName, para

que se possa saber a que rede pertence aquela BTS, uma vez que os

identificadores de BTS variam de rede para rede.

O outro método usado para a obtenção da localização é a Localização

por GPS. A classe implementada para obter as coordenadas de GPS foi a

CGPSPositionRequest. O Symbian, neste caso, também disponibiliza uma

biblioteca para a obtenção destes parâmetros, o lbs e o lbspositioninfo. Assim,

o método implementado para a obtenção das coordenadas de GPS foi o

seguinte:



TBool CGpsPositionRequest::GetCurrentPostionL(TReal& aLatitude, TReal& aLongitude) {

(…) }

O método é do tipo TBool, para que só seja pedido o mapa

correspondente, no caso da obtenção das coordenadas de GPS.

Estes métodos só serão chamados após indicação do utilizador, sendo

posteriormente enviados os resultados obtidos para o servidor.

Quando o utilizador indica a Localização por BTS, é chamado o método

GetNetworkParameters(), sendo também verificado a hora e data do telefone

(para que, na eventualidade do turista querer adicionar uma foto à sua conta,

esta possa ser associada a um lugar), em que esta acção foi pedida, sendo

posteriormente enviado para o servidor. Como o turista pode estar a

movimentar-se, a BTS a que o telefone deste está ligado poderá mudar. Assim,

implementou-se um temporizador que chama a função PostNetworkInfo() de

minuto a minuto. Nesta função é chamado o método de obtenção dos

parâmetros de rede, bem como é verificado se o identificador da BTS mudou.

Caso esta proposição seja verdadeira, envia-se os novos dados para o servidor,

poupando-se desta forma alguns recursos do telefone. Adicionalmente, a

função PostNetworkInfo() chama um método que verifica a existência de dados

de GPS. Se estes dados estiverem disponíveis, serão enviados também para o

servidor, para que depois seja possível, por parte do utilizador, uma pesquisa

de serviços online mais precisa. Assim sendo, o método PostNetworkInfo() foi

implementado da seguinte forma:

void CC4Usv6AppUi::PostNetworkInfo() { (…) }

A outra funcionalidade da aplicação é a Localização por GPS. Aquando da

indicação do utilizador, é chamada a função GetGPSInfoL(). Nesta função é

chamado o método GetCurrentPositionL(), para a obtenção das coordenadas de

GPS, bem como são obtidas as dimensões do ecrã do telefone do utilizador,



sendo estas usadas para o correcto dimensionamento do mapa a obter. Após a

aquisição das coordenadas é pedido o mapa correspondente, enviando as

coordenadas para o servidor do Culture for Us, sendo criado o ficheiro para a

posterior visualização do mapa na aplicação. A função GetGPSInfoL()

implementada, é a seguinte:

void CC4Usv6AppView::GetGPSInfoL() {

(…) }

Em que a função SetupFileDownload() cria o ficheiro em que será

carregado o mapa e a função SendHTTPRequestL() envia o pedido de download

do mapa. Estas funções foram implementadas da seguinte forma:

void CC4Usv6AppView::SendHTTPRequestL() {

(…) }

void CC4Usv6AppView::SetupFileDownload() {

(…) }

As figuras seguintes mostram o processo efectuado por estes métodos.

Na Figura 4.2 visualiza-se a caixa de espera enquanto são obtidos os dados de

GPS e na Figura 4.3 demonstra-se a visualização do mapa.



Figura 4.2 Espera de obtenção de coordenadas Figura 4.3 Mapa

4.6. Implementação Página Web Móvel

Na implementação da página Web móvel, o primeiro aspecto a ter em

conta foi que linguagem usar para a implementação da apresentação e

formatação da mesma. Assim sendo, usou-se o XHTML MP em conjunto com o

WCSS. A escolha recaiu sobre estas linguagens por permitirem a separação do

conteúdo e da apresentação em ficheiros diferentes, garantindo que o conteúdo

é escrito apenas uma vez e a apresentação pode ser modificada de acordo com

os diferentes dispositivos, por actualmente todos os browsers de telefones

móveis suportarem estas linguagens e também por o XHTML MP conciliar as

tecnologias de Internet móvel com as da world wide web. A linguagem usada

no lado do servidor foi o php e a usada na implementação da base de dados o

MySQL, tendo estas sido desenvolvidas pelo aluno Gustavo Fernandes, sendo

de minha autoria o desenvolvimento da apresentação e formatação da página.

Os métodos usados nas transacções de colocação e obtenção de

informação foram o Post e o Get, respectivamente.

Descrevendo a página implementada, esta é composta por uma página

inicial, onde são facultados ao utilizador campos para este efectuar a



autenticação, registo e download da aplicação. A página desenvolvida encontra-

se na figura (Figura 4.4) seguinte:

Figura 4.4 Página Incial

A página de Login, Figura 4.5, foi criada para que o cliente possa

autenticar-se na plataforma, após o registo na plataforma.

Figura 4.5 Login

A página de Registo foi desenvolvida para que o cliente se possa registar

na plataforma, podendo a página ser visualizada na Figura 4.6.



Figura 4.6 Registo

Foi criada também uma página para a conta de cliente, onde são

disponibilizadas as funcionalidades de Localização por BTS, Where I am,

pesquisa por nome, Search by Name, a possibilidade de carregar fotos à conta

de utilizador, Upload Photos, e por fim a possibilidade de visualizar as fotos já

carregadas pelo utilizador, My Photos. A conta de utilizador pode ser vista na

Figura 4.7.

Figura 4.7 Área de Cliente



A página Where I am, Figura 4.8, foi criada para que o utilizador possa

visualizar a sua localização, estando esta associada à última BTS colocada

através da aplicação móvel instalada no telefone do utilizador. Nesta página é

também facultado ao utilizador a possibilidade de procurar serviços associados

à localização.

Figura 4.8 Página “Where I am”

A página Search by Name, Figura 4.9, foi criada para que o cliente, no

caso de saber o nome de um lugar da Região, possa pesquisar por serviços

existentes neste.



Figura 4.9 Página “Search by name”

Para que o cliente possa carregar fotos para a sua conta foi

implementada a página da Figura 4.10. Nesta, o cliente pode associar várias

fotos ao mesmo tempo, tendo sido criada uma função em javascript para o

efeito, bastando para isso carregar no botão Add more photos e procurar a foto

pretendida. Após isso, estas são associadas ao local onde foram capturadas, no

caso de a aplicação móvel estar activa. Estas são associadas ao lugar, Figura

4.11, através da data e hora em que foram tiradas, sendo estes dados

comparados com a data e hora do telefone, postos aquando da colocação da

BTS por parte da aplicação móvel. Esta comparação é conseguida, porque uma

foto capturada num dispositivo com Sistema Operativo Symbiam S60 3ª Edição,

possui um ficheiro exif associado a esta, que contém a data e hora do

dispositivo aquando da sua captura. Na página de pré-visualização, o cliente



também poderá dar um nome à foto, bem como colocar um comentário à

mesma.

Figura 4.10 Página “Upload Photos”

Figura 4.11 Pré-visualização da Foto carregada com Localização



Por fim, o cliente pode visualizar as fotos que carregou para a sua conta.

Estas são agrupadas por lugar onde foram tiradas e as que não têm qualquer

localização associada, estão agrupadas à parte, como se pode verificar na

Figura 4.12.

Figura 4.12 Fotos agrupadas por lugar

4.7. Testes

Depois de implementada a aplicação e a página Web de apoio, foi

necessário testá-las, para visualizar o seu funcionamento na prática. O telefone

usado para os testes da aplicação foi o Nokia N95, e a página Web foi testada

no emulador S60 3rd Edition Emulator. A aplicação não foi testada nesse

emulador, por este não proporcionar um ambiente capaz de simular um módulo

de GPS ou a obtenção da BTS, ou seja, não é possível neste alterar os valores

da BTS e das coordenadas de GPS para valores reais. De realçar também que a

aplicação foi desenvolvida para dispositivos com Sistema Operativo Symbian

S60 3ª edição, não funcionando desta forma, noutros sistemas operativos.

Na página Web só será mostrado o seu layout, uma vez que o seu

design e implementação são de minha autoria, ou seja, a camada de



apresentação do modelo MVC. Já a aplicação instalada no telefone, será

completamente testada e explorada.

Assim, de forma a validar a modelização do sistema, descrita no capítulo

3, usar-se-ão os cenários descritos nas secções 3.3.1, “Chegada à Região”,

3.3.2, “Localização por BTS” e 3.3.3 “Localização por GPS”, como base para os

testes efectuados. É necessário ter em atenção, que os testes não foram

efectuados nos lugares mencionados nos cenários, funcionando apenas de

guião para os testes.

4.7.1. Chegada à Região

Tendo em conta o cenário 1, “Chegada à Região”, descrito na secção

3.3.1, serão efectuados testes à página Web e à aplicação móvel, descritos

individualmente, para que se tenha uma melhor percepção da sua utilidade, no

decorrer do cenário.

4.7.1.1. Página Web

Testando a página Web no âmbito do cenário mencionado, o utilizador

começa por visualizar a página inicial do Culture for Us, site de dispositivos

móveis. A página implementada para o efeito foi a que se encontra na próxima

figura (Figura 4.13).

Figura 4.13 Página Inicial



Após isso, efectuou o registo na página criada para o acto, mostrada na

Figura 4.14, de forma a poder utilizar a aplicação, bem como usufruir de todas

as funcionalidades da plataforma.

Figura 4.14 Registo

Após o registo, o turista visualiza a sua conta. De seguida este faz uma

pesquisa por nome de lugar e serviço pretendido, restaurante, obtendo, como

resposta, uma lista de nomes de restaurantes, como se pode visualizar nas

Figuras 4.15, 4.16, 4.17 e 4.18. Ao carregar num deles, este visualiza os

detalhes deste, demonstrado na Figura 4.19.

Figura 4.15 Conta



Figura 4.16 Procura por Lugar

Figura 4.17 Lista de Lugares Figura 4.18 Resultados de Serviço



Figura 4.19 Detalhes de Serviço

Continuando com o desenrolar do cenário, no que diz respeito à

utilização do site móvel, o turista tirou uma fotografia, colocando-a na sua

conta, sendo posteriormente associada à localização de onde foi capturada,

tendo para o efeito instalado e ligado a aplicação, descrita na próxima secção.

As Figuras 4.20 e 4.21 mostram as páginas Web criadas para o efeito.

Figura 4.20 Página de Upload de Fotos



Figura 4.21 Pré-visualização da Foto carregada com Localização

As fotos do utilizador poderão ser vistas todas agrupadas por lugares na

sua conta de utilizador. As páginas implementadas para disponibilizá-las podem

ser visualizadas nas Figuras 4.22, 4.23 e 4.24.

Figura 4.22 Fotos carregadas por Local



Figura 4.23 Fotos de determinada Localização

Figura 4.24 Visualização da Foto

4.7.1.2. Aplicação Móvel

No decorrer do cenário, o utilizador tirou uma fotografia. Para que esta

possa ser associada a um lugar, o turista teve de descarregar a aplicação,

instalá-la e posteriormente ligá-la. Ao ligar a aplicação, como se pode visualizar

na Figura 4.25, entrou no menu, Figura 4.26, e efectuou a autenticação,



mostrada na Figura 4.27. Para esse efeito, o turista escolheu o ponto de acesso

que quis usar para comunicar com o servidor, mostrado na Figura 4.28, ficando

desta forma aberto o canal de comunicação da aplicação.

Figura 4.25 Aspecto da Aplicação Figura 4.26 Menu da Aplicação

Figura 4.27 Autenticação na Aplicação Figura 4.28 Escolha Ponto de Acesso

Depois, o turista deu início à colocação dos parâmetros de rede (BTS)

usados para a sua localização, com sucesso, como se pode ver na Figura 4.29 e



Figura 4.30. A mensagem de sucesso aparece sempre que qualquer

comunicação com o servidor é bem sucedida.

Figura 4.29 Início Figura 4.30 Mensagem de Sucesso

Após a colocação dos dados de rede, o utilizador pode minimizar a

aplicação, usufruindo do seu telefone na íntegra, não descorando, a

actualização dos dados usados para o cálculo da sua localização, uma vez que

esta contínua a correr no seu telefone. Este processo pode ser visualizado na

Figura 4.31.

Figura 4.31 Aplicação Minimizada



4.7.2. Localização por BTS

Tendo, desta feita, por base o cenário 2, “Localização por BTS”, da

secção 3.3.2, o turista não sabe onde se encontra e após ter ligado a aplicação

e iniciado o processo de obtenção dos parâmetros de rede, como exemplificado

no cenário 1, “Chegada à Região”, este consulta então a página Web

implementada para facultar a localização do utilizador, Figura 4.32.

Figura 4.32 Visualização da Localização

Após a obtenção da localização, o utilizador seleccionou a procura de

serviços nesse lugar, obtendo como resposta, a lista de serviços pretendidos,

como se pode ver na Figura 4.33.



Figura 4.33 Lista Serviços

4.7.3. Localização por GPS

Por fim, e para completar a panóplia de testes, no cenário 3,

“Localização por GPS”, da secção 3.3.3, o turista pretende obter uma

localização mais exacta de onde está. Para obtê-la, seleccionou a opção GPS

Info disponibilizada pela aplicação. Após isso, o utilizador espera a aquisição

das coordenadas e respectivo mapa, por parte da aplicação. As Figuras 4.34 e

4.35 demonstram o procedimento desde a espera da obtenção das

coordenadas até ao visualizar do mapa.



Figura 4.34 Espera de obtenção de coordenadas Figura 4.35 Mapa

4.8. Desempenho da Aplicação

Ao desenvolver-se uma aplicação, é necessário ter em conta a eficiência

da mesma, ou seja, tendo em conta que o dispositivo alvo é um telefone móvel

e sabendo-se que este apresenta recursos limitados, nomeadamente de bateria,

será necessário avaliar esse parâmetro para garantir um bom desempenho de

energia da aplicação. Testou-se também a aplicação num outro telefone, Nokia

N78, verificando-se também o seu desempenho em termos de consumo de

potência.

O programa usado para analisar a eficiência da aplicação foi o Nokia

Energy Profiler 1.2, que é uma aplicação de avaliação de desempenho para

aplicações S60 3ª edição. Esta permite testar e monitorizar as aplicações em

tempo real nos dispositivos alvo [30].

4.8.1. Nokia N95

Fizeram-se três testes, um a uma chamada de voz normal, outro ao

programa Google Maps, programado em Symbian C++, e por último à

aplicação desenvolvida. Estes três testes foram pensados de forma a se

poderem comparar duas aplicações desenvolvidas na mesma linguagem e com



funcionalidades idênticas, bem como poder compará-las com a funcionalidade

mais usada num telefone. O ambiente de teste foi o mesmo para os três testes,

ou seja, a carga de bateria foi aproximadamente a mesma, sendo que o

número de aplicações abertas no telefone foi o mesmo.

Para servir como base de comparação, fez-se um pequeno teste a uma

chamada de voz num telefone móvel, verificando-se o consumo de potência.

Nas Figuras 4.36 e 4.37, é mostrado o consumo de potência da chamada.

Verifica-se que até aos 15s o telefone tem um consumo muito inferior a 1W,

período no qual este estava em utilização normal, apenas com luz ligada e

entrada e saída do menu. Aos 15s estabeleceu-se uma chamada, verificando-se

aí um pico de potência de 2W, baixando um pouco até aos 100s

aproximadamente. Pode-se verificar também que entre os 115s até quase aos

215s o consumo manteve-se quase inalterado abaixo de 1w, reportando o

período no qual o ecrã esteve em standby, havendo novamente um pico de

potência no desligar da chamada, mas com um valor ligeiramente inferior ao de

estabelecimento. Corrobora-se também que a média de consumo é de 1,03 W e

a duração de bateria de 3 horas e 42 minutos, se esta média se mantiver.

Figura 4.36 Consumo de Potência Chamada



Figura 4.37 Consumo de Potência Chamada (continuação temporal da Figura 4.36)

O outro teste efectuado foi à aplicação Google Maps, verificando-se o

consumo de potência. Nas Figuras 4.38 e 4.39, apresenta-se o consumo de

potência da aplicação, averiguando-se que durante os períodos entre os 0s -

100s e os 115s – 145s acontece o maior consumo de potência, com picos que

atingem valores superiores a 2W, pois estes reportam a ligação do módulo de

GPS para aquisição da posição e o acesso à internet através de UMTS, de forma

a actualizar a posição do utilizador no mapa, carregando-o sempre que

necessário. Verifica-se também que a média de consumo de potência cifrou-se

na ordem dos 1,50W. Outro dado, também obtido, é o tempo de duração da

bateria, no caso da média de consumo se manter no valor obtido, que se cifra

nas 2 horas e 35 minutos.



Figura 4.38 Consumo de Potência Google Maps

Figura 4.39 Consumo de Potência Google Maps (continuação temporal da Figura 4.38)

Por fim, testou-se a aplicação desenvolvida para devolver a localização

do utilizador da plataforma Culture for Us. As Figuras 4.40 e 4.41 apresentam

os gráficos de consumo de potência por parte da aplicação. Ao analisá-los,

averigua-se que durante os períodos entre os 15s – 45s e 145s – 215s, o

consumo de potência é mais elevado, atingindo por vezes valores superiores a



2W. Este maior consumo aconteceu aquando da colocação e pedido de dados

ao servidor, ou seja, durante o estabelecimento de ligações à internet por parte

do telefone, para colocação e obtenção de dados. O primeiro período reporta à

autenticação e colocação da BTS a que o telefone está ligado e o segundo

período, reporta à obtenção das coordenadas de GPS e respectivo mapa.

Corrobora-se também que entre os 45s – 145s e após os 215s, o consumo é

aproximadamente de 1W, períodos esses em que a aplicação apenas efectua o

ciclo de verificação de BTS, não havendo alteração da mesma, pois não existe

um grande consumo. Outro dado de destaque na análise dos gráficos, é o facto

de a bateria durar 3 horas e 50 minuto, se a aplicação mantiver aquela média

de consumo de potência.

Figura 4.40 Consumo de Potência aplicação Culture for Us - Nokia N95



Figura 4.41 Consumo de Potência aplicação Culture for Us – Nokia N95 (continuação temporal da Figura 4.40)

Comparando o Google Maps e a aplicação desenvolvida, conclui-se que

em termos de consumo de potência o primeiro tem um consumo maior,

devendo-se sobretudo ao facto de sempre que o utilizador desloca o mapa ou

entra numa zona em que o mapa não está carregado a aplicação terá de fazer

uma ligação ao servidor para carregá-lo, havendo também o contributo de

consumo do ecrã, uma vez que o utilizador quer estar constantemente a ver o

mapa para se localizar. No caso da aplicação do Culture for Us, o mapa só é

carregado por indicação do utilizador e a colocação da BTS no servidor só

acontece aquando da mudança da mesma, sendo que durante este período

existe um desligar do ecrã, havendo desta forma uma optimização de recursos.

Comparando estas aplicações com uma chamada de voz, averigua-se que o

consumo desta é ligeiramente superior ao da aplicação construída, uma vez que

esta apresenta apenas picos de consumo por ligações de curta duração à rede,

enquanto durante uma chamada telefónica a ligação a essa mesma rede é

contínua. No caso do Google Maps, o seu consumo é superior ao de uma

chamada telefónica, uma vez que durante o teste esteve quase sempre ligado à

rede e o ecrã esteve sempre ligado, sendo que no caso da chamada telefónica,



este último desligou-se ao fim de 30s, período estipulado pelo utilizador do

telefone.

4.8.2. Nokia N78

Para não descorar a possível portabilidade da aplicação, esta foi testada

num outro telefone Symbian S60 3ª edição, um Nokia N78, com uma bateria de

1200mAh.

Assim, ao instalar-se a aplicação neste telefone, todas as suas

funcionalidades funcionaram na íntegra, até mesmo a localização por GPS, uma

vez que este telefone tem um módulo de GPS integrado.

Pensou-se então em comparar o desempenho da aplicação, nesse

telefone, em termos de consumo de potência, para posteriormente comparar-se

com o desempenho obtido por esta no Nokia N95. Instalou-se para o efeito a

aplicação Nokia Energy Profiler 1.2.

Como se pode constatar nas Figuras 4.42 e 4.43, o consumo de potência

da aplicação Culture for Us apresenta um maior consumo nos intervalos de

15s - 45s e 145s – 215s, períodos esses que reportam o acesso à rede para

colocação e obtenção de dados. O primeiro período reporta à autenticação e

colocação da BTS a que o telefone está ligado e o segundo período, reporta à

obtenção das coordenadas de GPS e respectivo mapa. Verifica-se também que

entre os 45s – 145s e após os 215s o consumo é inferior a 1W, período no qual

a aplicação efectuava o ciclo de verificação da BTS, não havendo alteração da

mesma, por não existir um grande consumo. Outro valor obtido é a duração da

bateria ser de 5 horas e 51 minutos, no caso da média de consumo não se

alterar.



Figura 4.42 Consumo de Potência aplicação Culture for Us - Nokia N78

Figura 4.43 Consumo de Potência aplicação Culture for Us – Nokia N78 (continuação temporal da Figura 4.42)

Comparando os consumos da aplicação nos telefones testados, verifica-

se que o consumo no Nokia N78 é inferior, com uma média de 0,84W,

contrastando com os 1,01W gastos no Nokia N95. Isto poderá acontecer devido



aos diferentes métodos de gestão de energia existentes nesses telefones, uma

vez que o Nokia N78 apresenta uma edição mais recente de Sistema Operativo

Symbian S60 3ª edição, ou seja, quando comparados os períodos entre 45s –

145s e após os 215s, em que a aplicação efectua o ciclo de verificação de BTS,

verifica-se que no caso do Nokia N78 o consumo é inferior ao obtido no Nokia

N95. De realçar também que no telefone Nokia N78 a bateria apresenta uma

maior autonomia, devendo-se não só ao menor consumo, mas também por a

bateria deste telefone apresentar uma maior capacidade, 1200mAh,

contrastando com os 950mAh do telefone Nokia N95.

Conclusão e Trabalho Futuro


5. Conclusão e Trabalho Futuro

5.1. Conclusão

Este é um trabalho que visou a implementação de uma plataforma

dinâmica para entrega de informação e comunicação instantânea com turistas

móveis. Assim, conseguiu-se implementar uma plataforma capaz de fornecer ao

turista, informações turísticas de acordo com a localização, bem como usufruir

de outros serviços, tais como, a colocação de mensagens e fotos. Para o efeito,

implementou-se uma aplicação para a obtenção da localização do utilizador,

fazendo uso de duas técnicas de localização, Localização por GPS e

Posicionamento por GSM/UMTS. Esta fornece os dados para a obtenção da

localização, a um servidor que os usa posteriormente para georeferenciar uma

série de serviços, ou seja, conseguiu-se implementar a obtenção da BTS a que

o telefone está ligado, bem como no caso de o telefone possuir um módulo de

GPS integrado, conseguiu-se obter as coordenadas de GPS do mesmo e o

respectivo mapa. Implementou-se também uma página Web para dispositivos

móveis, construída com uma interface amigável e de fácil utilização, através da

linguagem mais adequada para o efeito, o XHTML MP. De realçar também o

facto de esta poder ser acedida na maioria dos telefones existentes no

mercado.

É de salientar que a aplicação foi testada correctamente em dois

dispositivos com Sistema Operativo Symbian 3ª edição, Nokia N95 e Nokia N78,

sistema para o qual foi desenvolvida a aplicação. Nestes dois dispositivos, esta

conseguiu ter um desempenho aceitável em termos de consumo de bateria,

como comprovado pelos testes efectuados.

Conclusão e Trabalho Futuro


5.2. Trabalho Futuro

Em relação ao trabalho futuro, a aplicação desenvolvida tem um grande

potencial de desenvolvimento, podendo ser implementada a triangularização do

sinal de rede, garantido desta forma uma localização através da utilização das

BTSs sem recurso a GPS. Outro aspecto que poderá ser desenvolvido é a

redução do uso do sítio móvel, implementando as funções nele inseridas, na

aplicação móvel, como por exemplo, a colocação de fotos no servidor, pesquisa

de serviços e lugares, uma vez que, a aplicação já tem implementado, toda a

comunicação com servidor. Assim, garante-se desta forma, uma melhor

usabilidade da plataforma por parte dos utilizadores, tornando-a mais simples e

intuitiva.

Bibliografia


6. Bibliografia

[1] Pease, Wayne, Rowe, Michelle and Cooper, Malcolm. 2007.

Information and Communication Technolgies in Support of the Tourism

Industry. s.l. : Idea Group Publishing, 2007.

[2] .NET. Wikipedia. [Online] [Cited: 2008.]

http://en.wikipedia.org/wiki/.NET_Compact_Framework.

[3] Crumpet. European Media Laboratory. [Online] [Cited: 2008.]

http://www.eml-development.de/english/research/crumpet/index.php.

[4] Location-based mobile tourist services - first user experiences. Schmidt-

Belz, Barbara, Laamanen, Heimo, Poslad, Stefan and Zipf,

Alexander. 2003. Finland : Springer-Verlag Wien, 2003.

[5] Experiences of developing and deploying a context-aware tourist guide:

The GUIDE Project. Cheverst, Keith, Davies, Nigel and Friday,

Adrian. 2000. Boston, Massachusetts, United States : ACM, 2000.

ISBN:1-58113-197-6.

[6] INTOUSYS: a Prototype Personalized Tourism System. Bordoni, L.,

Gisolfi, A. and Trezza, A. 2007. Rome : AI*IA, 2007.

[7] Location-Based Mobile Tour Guide Services towards Digital Dunhuang.

Chang-jie, Ma, Quansheng, Miao and Yuhuai, Zeng. 2008.

Beijing : ISPRS Congress Beijing 2008, 2008. ISSN 1682-1750.

[8] esMadrid.com. [Online] [Cited: 2008.]

http://www.esmadrid.com/en/portal.do?IDM=35&NM=1.

Bibliografia


[9] Coulton, Paul, Edwards, Reuben and Clemson, Helen. 2007. S60

Programming - A Tutorial Guide. Chichester : Wiley, 2007. ISBN 978-0-

470-02765-3.

[10] Forum.Nokia.com. Nokia. [Online] [Cited: ]

http://www.forum.nokia.com/Resources_and_Information/Explore/Runti

me_Platforms/Symbian_C++/.

[11] 2009. S60 open to new features. S60. [Online] 2009. [Cited: ]

http://www.s60.com/life/thisiss60/S60forbusiness/keyfigures.

[12] Nokia Corporation. Maio 2008. S60 platform 3rd Edition

Overview. Finlândia : Nokia, Maio 2008.

[13] Faria, João Pascoal. 2001. FEUP. [Online] 2001. [Cited: 2008.]

http://paginas.fe.up.pt/~jpf/teach/POO/usecases.pdf.

[14] Diagrama de Casos de Uso. Wikipedia. [Online] [Cited: 2008.]

http://pt.wikipedia.org/wiki/Diagrama_De_Casos_De_Utiliza%C3%A7%C

3%A3o.

[15] Castilho, Marcelo. 2008. Dimensão Tech. [Online] Agosto 27,

2008. [Cited: 2008.]

http://blog.dimensaozero.com/2008/08/modelagem-de-software/.

[16] Faria, João Pascoal. 2001. FEUP. [Online] 2001. [Cited: 2008.]

http://paginas.fe.up.pt/~jpf/teach/ES/UML/actividade.ppt.

[17] Model View Controller. Wikipedia. [Online] [Cited: 2008.]

http://pt.wikipedia.org/wiki/MVC.

[18] Macoratti.net. [Online] [Cited: 2008.]

http://www.macoratti.net/vbn_mvc.htm.

Bibliografia


[19] Engenharia de Requisitos. Wikipedia. [Online] [Cited: 2008.]

http://pt.wikipedia.org/wiki/Engenharia_de_Requisitos.

[20] Cenários. Wikipedia. [Online] [Cited: 2008.]

http://pt.wikipedia.org/wiki/Cen%C3%A1rios.

[21] Diagrama de Sequencia. Wikipedia. [Online] [Cited: 2008.]

http://pt.wikipedia.org/wiki/Diagrama_de_sequ%C3%AAncia.

[22] Arquitectura ARM. Wikipedia. [Online] [Cited: 2009.]

http://pt.wikipedia.org/wiki/Arquitetura_ARM.

[23] Mason, Sam and Korolev, Elise. Março 2008. Native and Java

ME Development on Symbian OS. s.l. : Symbian Developer Network,

Março 2008. Versão 1.0.

[24] 2008. Forum.Nokia.com. Nokia. [Online] Setembro 12, 2008.

[Cited: 2008.]

http://discussion.forum.nokia.com/forum/showthread.php?t=144297.

[25] Sciabarrà, Michele. 2005. Symbian C++ Programming Tutorial.

symbiantutorial.com. [Online] Dezembro 30, 2005. [Cited: 2008.]

http://www.symbiantutorial.org/symbian-

tutorial/?2._Building_programs_with_the_SDK:2.3_The_build_process.

[26] Nokia Corporation.. 2007. Symbian OS Basics - Course Pack.

s.l. : Nokia , 2007. BO-EN-04300-20080108.

[27] Heath, Craig. Março 2006. Symbian OS Platform Security. s.l. :

Symbian Press, Março 2006. ISBN 0-470-01882-8 .

[28] 2007. Forum.Nokia.com. Nokia. [Online] Novembro 20, 2007.

[Cited: 2009.] http://wiki.forum.nokia.com/index.php/MMP_file.

Bibliografia


[29] 2008. Forum.Nokia.com. Nokia. [Online] Abril 16, 2008.

http://www.forum.nokia.com/info/sw.nokia.com/id/458604da-e7fc-4d4e-

92ee-3ce8a1e68a86/S60_Platform_HTTP_Client_API_Example.html.

[30] 2009. Forum.Nokia.com. Nokia. [Online] Abril 1, 2009.

http://www.forum.nokia.com/Resources_and_Information/Explore/Devel

opment_Process_and_User_Experience/Power_Management/Nokia_Ener

gy_Profiler_Quick_Start.xhtml.

[31] 2009. inov inesc inovação. INOV. [Online] Maio 24, 2009.

http://www.inov.pt/eng/news/archive_01.html.

Anexos


7. Anexos

Anexo A – Código de Algumas Funções

Método SetupConnectionL():

void CClientEngine::SetupConnectionL()

{

TInt bearerFilter = EApBearerTypeAllBearers;

TInt currentProfileId;

// Check whether we are offline or online

iRepository->Get(KProEngActiveProfile, currentProfileId);

// Close the connection only if

// a) this is not the first time and

// b) the profile has changed and

// c) either the previous or the current profile is Offline (5 = Offline)

if (iPrevProfileId != -1 && iPrevProfileId != currentProfileId &&

(iPrevProfileId == 5 || currentProfileId == 5))

{

// Close and uninitialize

iConnectionSetupDone = EFalse;

iSession.Close();

iConnection.Close();

iSocketServ.Close();

Anexos


}

// Save current profile id

iPrevProfileId = currentProfileId;

// Try to find an existing connection. If connection has not been set up,

// iConnection is not initialized and FindExistingConnection() fails.

// Thus, in that case, finding must not be carried out.

if (iConnectionSetupDone && !FindExistingConnection())

{

iConnectionSetupDone = EFalse;

}

if (iConnectionSetupDone)

{

// Connection setup is done

return;

}

// Open RHTTPSession with default protocol ("HTTP/TCP")

iSession.OpenL();

// Install this class as the callback for authentication requests. When

// page requires authentication the framework calls GetCredentialsL to get

// user name and password.

//InstallAuthenticationL(iSession);

// In offline, only WLAN connections are available

Anexos


if (currentProfileId == 5)

{

bearerFilter = EApBearerTypeWLAN;

}

// Show IAP selection dialog

CActiveApDb* aDb = CActiveApDb::NewL();

CleanupStack::PushL(aDb);

CApSettingsHandler* settings = CApSettingsHandler::NewLC(

*aDb,

ETrue,

EApSettingsSelListIsPopUp,

EApSettingsSelMenuSelectNormal,

KEApIspTypeAll,

bearerFilter,

KEApSortNameAscending,

0,

EVpnFilterBoth,

ETrue);

TInt iapRet = settings->RunSettingsL(0, iSelectedIap);

CleanupStack::PopAndDestroy(settings);

CleanupStack::PopAndDestroy(aDb);

if (iapRet != KApUiEventSelected)

{

// Exit no selection

User::Leave(KErrNotReady);

Anexos


}

else

{

// IAP Selected

// Open socket server and start the connection

User::LeaveIfError(iSocketServ.Connect());

User::LeaveIfError(iConnection.Open(iSocketServ));

// Now we have the iap Id. Use it to connect for the connection

TCommDbConnPref connectPref;

// Setup preferences

connectPref.SetDialogPreference(ECommDbDialogPrefDoNotPrompt);

// Sets the CommDb ID of the IAP to use for this connection

connectPref.SetIapId(iSelectedIap);

// Start connection

User::LeaveIfError(iConnection.Start(connectPref));

// Set the sessions connection info...

RStringPool strPool = iSession.StringPool();

RHTTPConnectionInfo connInfo = iSession.ConnectionInfo();

// ...to use our socket server and connection

connInfo.SetPropertyL ( strPool.StringF(HTTP::EHttpSocketServ,

RHTTPSession::GetTable() ), THTTPHdrVal (iSocketServ.Handle()) );

// ...to use our connection

connInfo.SetPropertyL ( strPool.StringF(HTTP::EHttpSocketConnection,

RHTTPSession::GetTable() ),

THTTPHdrVal (REINTERPRET_CAST(TInt, &(iConnection))) );

iConnectionSetupDone = ETrue;

}

Anexos


}

Método IssueHTTPGetL():

void CClientEngine::IssueHTTPGetL(const TDesC8& aUri) { // Parse string to URI (as defined in RFC2396) TUriParser8 uri; uri.Parse(aUri); // Create HTTP connection TRAPD(err, SetupConnectionL()); // User didn't select an IAP if (err == KErrNotReady) { HBufC* resTxCancelled = StringLoader::LoadLC(R_HTTP_TX_CANCELLED); iObserver.ClientEvent(*resTxCancelled); CleanupStack::PopAndDestroy(resTxCancelled); return; } // Get request method string for HTTP GET RStringF method = iSession.StringPool().StringF(HTTP::EGET, RHTTPSession::GetTable()); // Open transaction with previous method and parsed uri. This class will // receive transaction events in MHFRunL and MHFRunError. iTransaction = iSession.OpenTransactionL(uri, *this, method); // Set headers for request; user agent and accepted content type RHTTPHeaders hdr = iTransaction.Request().GetHeaderCollection(); SetHeaderL(hdr, HTTP::EUserAgent, KUserAgent); SetHeaderL(hdr, HTTP::EAccept, KAccept); // Submit the transaction. After this the framework will give transaction // events via MHFRunL and MHFRunError. iTransaction.SubmitL(); iRunning = ETrue; HBufC* resConnecting = StringLoader::LoadLC(R_HTTP_CONNECTING); iObserver.ClientEvent(*resConnecting);

Anexos


CleanupStack::PopAndDestroy(resConnecting); }

Método IssueHTTPPostL():

void CClientEngine::IssueHTTPPostL(const TDesC8& aUri, const TDesC8& aContentType, const TDesC8& aBody) { // Parse string to URI TUriParser8 uri; uri.Parse(aUri); // Copy data to be posted into member variable; iPostData is used later in // methods inherited from MHTTPDataSupplier. delete iPostData; iPostData = 0; iPostData = aBody.AllocL(); // Create HTTP connection TRAPD(err, SetupConnectionL()); // User didn't select an IAP if (err == KErrNotReady) { HBufC* resTxCancelled = StringLoader::LoadLC(R_HTTP_TX_CANCELLED); iObserver.ClientEvent(*resTxCancelled); CleanupStack::PopAndDestroy(resTxCancelled); return; } // Get request method string for HTTP POST RStringF method = iSession.StringPool().StringF(HTTP::EPOST, RHTTPSession::GetTable()); // Open transaction with previous method and parsed uri. This class will // receive transaction events in MHFRunL and MHFRunError. iTransaction = iSession.OpenTransactionL(uri, *this, method); // Set headers for request; user agent, accepted content type and body's // content type.

Anexos


RHTTPHeaders hdr = iTransaction.Request().GetHeaderCollection(); SetHeaderL(hdr, HTTP::EUserAgent, KUserAgent); SetHeaderL(hdr, HTTP::EAccept, KAccept); SetHeaderL(hdr, HTTP::EContentType, aContentType); // Set this class as an data supplier. Inherited MHTTPDataSupplier methods // are called when framework needs to send body data. MHTTPDataSupplier* dataSupplier = this; iTransaction.Request().SetBody(*dataSupplier); // Submit the transaction. After this the framework will give transaction // events via MHFRunL and MHFRunError. iTransaction.SubmitL(); iRunning = ETrue; HBufC* resConnecting = StringLoader::LoadLC(R_HTTP_CONNECTING); iObserver.ClientEvent(*resConnecting); CleanupStack::PopAndDestroy(resConnecting); }

Método MHFRunL():

void CClientEngine::MHFRunL(RHTTPTransaction aTransaction,

const THTTPEvent& aEvent)

{

switch (aEvent.iStatus)

{

case THTTPEvent::EGotResponseHeaders:

{

// HTTP response headers have been received. Use

// aTransaction.Response() to get the response. However, it's not

// necessary to do anything with the response when this event occurs.

Anexos


// Get HTTP status code from header (e.g. 200)

RHTTPResponse resp = aTransaction.Response();

TInt status = resp.StatusCode();

// Get status text (e.g. "OK")

TBuf<KStatustextBufferSize> statusText;

statusText.Copy(resp.StatusText().DesC());

HBufC* resHeaderReceived = StringLoader::LoadLC(R_HTTP_HEADER_RECEIVED,

statusText, status);

iObserver.ClientEvent(*resHeaderReceived);

CleanupStack::PopAndDestroy(resHeaderReceived);

}

break;

case THTTPEvent::EGotResponseBodyData:

{

// Part (or all) of response's body data received. Use

// aTransaction.Response().Body()->GetNextDataPart() to get the actual

// body data.

// Get the body data supplier

MHTTPDataSupplier* body = aTransaction.Response().Body();

TPtrC8 dataChunk;

// GetNextDataPart() returns ETrue, if the received part is the last

// one.

TBool isLast = body->GetNextDataPart(dataChunk);

Anexos


//iObserver.ClientBodyReceived(dataChunk);

if(cont!=0)

ClientLoginReceived(dataChunk);

else

iObserver.ClientBodyReceived(dataChunk);

HBufC* resBytesReceived = StringLoader::LoadLC(R_HTTP_BYTES_RECEIVED,

dataChunk.Length());

iObserver.ClientEvent(*resBytesReceived);

CleanupStack::PopAndDestroy(resBytesReceived);

// NOTE: isLast may not be ETrue even if last data part received.

// (e.g. multipart response without content length field)

// Use EResponseComplete to reliably determine when body is completely

// received.

if (isLast)

{

HBufC* resBodyReceived = StringLoader::LoadLC(R_HTTP_BODY_RECEIVED);

iObserver.ClientEvent(*resBodyReceived);

CleanupStack::PopAndDestroy(resBodyReceived);

}

// Always remember to release the body data.

body->ReleaseData();

}

break;

Anexos


case THTTPEvent::EResponseComplete:

{

// Indicates that header & body of response is completely received.

// No further action here needed.

HBufC* resTxComplete = StringLoader::LoadLC(R_HTTP_TX_COMPLETE);

iObserver.ClientEvent(*resTxComplete);

CleanupStack::PopAndDestroy(resTxComplete);

}

break;

case THTTPEvent::ESucceeded:

{

// Indicates that transaction succeeded.

HBufC* resTxSuccessful = StringLoader::LoadLC(R_HTTP_TX_SUCCESSFUL);

iObserver.ClientEvent(*resTxSuccessful);

CleanupStack::PopAndDestroy(resTxSuccessful);

// Transaction can be closed now. It's not needed anymore.

aTransaction.Close();

if(cont!=0)

Confirm();

else

iObserver.ClientBodyCompleted();

iRunning = EFalse;

}

break;

Anexos


case THTTPEvent::EFailed:

{

// Transaction completed with failure.

HBufC* resTxFailed = StringLoader::LoadLC(R_HTTP_TX_FAILED);

iObserver.ClientEvent(*resTxFailed);

CleanupStack::PopAndDestroy(resTxFailed);


iRunning = EFalse;

}

break;

default:

// There are more events in THTTPEvent, but they are not usually

// needed. However, event status smaller than zero should be handled

// correctly since it's error.

{

if (aEvent.iStatus < 0)

{

HBufC* resNoInternetConnection = StringLoader::LoadLC(

R_HTTP_NO_INTERNET_CONNECTION, aEvent.iStatus);

iObserver.ClientEvent(*resNoInternetConnection);

CleanupStack::PopAndDestroy(resNoInternetConnection);

// Close the transaction on errors


iRunning = EFalse;

}

Anexos


else

{

// Other events are not errors (e.g. permanent and temporary

// redirections)

HBufC* resUnrecognisedEvent = StringLoader::LoadLC(

R_HTTP_UNRECOGNISED_EVENT, aEvent.iStatus);

iObserver.ClientEvent(*resUnrecognisedEvent);

CleanupStack::PopAndDestroy(resUnrecognisedEvent);

}

}

break;

}

}

Método GetNetworkParameters():

void CNetworkApp::GetNetworkParameters( TUint& aCellID, TUint& aLocationAreaCode, TDes& aNetworkID, TDes&

aCountryCODE, TDes& aLongName) { CNetworkApp* self= new(ELeave) CNetworkApp( aCellID, aLocationAreaCode, aNetworkID, aCountryCODE,

aLongName); CleanupStack::PushL(self); self->ConstructL(); CleanupStack::PopAndDestroy(self); }

Anexos


Método GetCurrentPositionL():

TBool CGpsPositionRequest::GetCurrentPostionL(TReal& aLatitude, TReal& aLongitude) { // cancel previous request (just in case) Cancel(); // request current location iPositioner.NotifyPositionUpdate(iPositionInfo, iStatus); SetActive(); // start wait note and wait for request end ShowWaitNoteL(); //_LIT16(Kwait, "Wait for GPS Connection"); //iAppView->AddToStatusWindowL(Kwait); // process result if (iError == KErrNone) { // success, return given position TPosition pos; iPositionInfo.GetPosition(pos); aLatitude = pos.Latitude(); aLongitude = pos.Longitude(); return ETrue; } // fail return EFalse; }

Método PostNetworkInfo():

void CC4Usv6AppUi::PostNetworkInfo(){ TUint LocationAreaCode(0); TBuf<30> NetworkId; TBuf<30> CountryId; TBuf<30> OperatorLongName; TReal latitude; TReal longitude;

Anexos


const TInt KMaxFolatLength = 8; const TInt KDecimalPos = 5; const TInt KExtraSpaceForSign = 2; TRealFormat format( KMaxFolatLength, KDecimalPos ); format.iType = KRealFormatFixed | KDoNotUseTriads | KExtraSpaceForSign; // buffer for localized text TBuf<50> myBuf; TBuf<50> myBuf2; TBuf<500> query; // Object for datetime data TTime myDate; TTime myTime; // Set current datetime to object myDate.HomeTime(); myTime.HomeTime(); // Format date and time according to current locale settings // Format string is universal, so that whatever the locale is, // date and time is always formatted correctly myDate.FormatL(myBuf, _L("&timestamp=%3-%2-%1%F")); myTime.FormatL(myBuf2, _L(".%-B%:0%J%:1%T%:2%S%:3%*B")); CNetworkApp::GetNetworkParameters( CellId, LocationAreaCode, NetworkId, CountryId, OperatorLongName ); iAppView->GPSInfo(latitude, longitude, control); if(latitude==0&&longitude==0) { latitude = 190; longitude = 190; } TBuf<250> so; HBufC* longitudeDes = HBufC::NewLC(257); longitudeDes->Des().Num(longitude,format);

Anexos


HBufC* latitudeDes = HBufC::NewLC(257); latitudeDes->Des().Num(latitude,format); _LIT(KNetworkInfoFormat, "&btsid=%d&lac=%d&lat=%S&lon=%S&nn=%S"); TBuf<250> networkInfoBuf; // It's recommended to use RBuf/HBufC here! networkInfoBuf.Format(KNetworkInfoFormat, CellId, LocationAreaCode, latitudeDes, longitudeDes, &OperatorLongName); //mount query to post query.Copy(Kuserid); query.Append(username); query.Append(networkInfoBuf); query.Append(myBuf); query.Append(myBuf2); TBuf8<250> postData8; TBuf8<500> uri8; uri8.Copy(KHttpName); uri8.Append(query); if(Last!=CellId || control==1){ Last=CellId; control=0; // Start transaction TRAPD(err, iEngine->IssueHTTPPostL(uri8, KMimeType, postData8)); //TRAPD(err, iEngine->IssueHTTPGetL(uri8)); // TODO: Error handling if (err){ } } }

Método GetGPSInfoL():

void CC4Usv6AppView::GetGPSInfoL() { iEngine->CancelTransaction();

Anexos


contGps = 0; // create CGpsPositionRequest object and put it into cleanup stack; // pass application name as argument CGpsPositionRequest* request = CGpsPositionRequest::NewL( _L("C4Usv6")); CleanupStack::PushL( request ); // get current location (this operation can be long up to 30 seconds); // progress dialog is shown to user during this time result = request->GetCurrentPostionL(latitude, longitude); //Get display info HAL::Get(HAL::EDisplayXPixels, Info1); HAL::Get(HAL::EDisplayYPixels, Info2); // delete request object CleanupStack::PopAndDestroy(request); if(result) { // Setup a file in the filesystem to download the map SetupFileDownload(); // send HtTp request to download map SendHTTPRequestL(); } }

Método SendHTTPRequestL():

void CC4Usv6AppView::SendHTTPRequestL(){ const TInt KMaxFolatLength = 8; const TInt KDecimalPos = 5; const TInt KExtraSpaceForSign = 2; TRealFormat format( KMaxFolatLength, KDecimalPos ); format.iType = KRealFormatFixed | KDoNotUseTriads | KExtraSpaceForSign; TBuf8<KDefaultBufferSize> uri8;

Anexos


uri8.Append( KGoogleMapURL ); HBufC8* longitudeDes = HBufC8::NewLC(257); longitudeDes->Des().Num(longitude,format); HBufC8* latitudeDes = HBufC8::NewLC(257); latitudeDes->Des().Num(latitude,format); TBuf8<KDefaultBufferSize> TempBuffer; TempBuffer.Format(uri8,Zoom,Info1,Info2,latitudeDes,longitudeDes); CleanupStack::PopAndDestroy(2); // Start transaction TRAPD(err, iEngine->IssueHTTPGetL(TempBuffer)); // TODO: Error handling if (err){ } }

Método SetupFileDownload():

void CC4Usv6AppView::SetupFileDownload(){ TBuf<256> imgname; //for(img;img>0;img++); img=img+1; _LIT(FileName, "LbsSample%d.jpg" ); imgname.Format(FileName,img); _LIT(KXMLFilePath, "c:\\Data\\Images\\"); TFileName iCurrentFileName; iCurrentFileName.Append(KXMLFilePath); //iCurrentFileName.Append(_L("LbsSample.jpg")); iCurrentFileName.Append(imgname); TInt err=iRLbsImage.Open(CCoeEnv::Static()-

>FsSession(),iCurrentFileName,EFileWrite); if (err==KErrNotFound) // file does not exist - create it {

Anexos


err=iRLbsImage.Create(CCoeEnv::Static()->FsSession(),iCurrentFileName,EFileWrite);

} }

Universidade da Madeira Departamento de Matemática e ... · HSDPA – High Speed Downlink Packet...

Documents

Transcript of Universidade da Madeira Departamento de Matemática e ... · HSDPA – High Speed Downlink Packet...