Relatório de Projecto de Licenciatura

Departamento de Informáticada Universidade da Beira Interior

carFree.ubiComputação ubíqua ao serviço dos transportes públicos

Joel Silva Carvalho

Orientador do Projecto:

Prof. Doutor Simão Melo de Sousa

Covilhã, Junho de 2008

Agradecimentos

A todos os que contribuíram de alguma forma para este projecto, aqui ficao meu forte agradecimento.Não vale a pena citar nomes, porque foram muitas as pessoas que derama sua contribuição por mínima que tenha sido.Obrigado a todos!

i

Conteúdo

Agradecimentos i

Conteúdo iii

Lista de Figuras vii

Acrónimos ix

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 carFree.ubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Organização do relatório . . . . . . . . . . . . . . . . . . . . . 8

2 Estado de Arte 11

2.1 Discussão existente . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Framework adoptada . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Plataforma carFree.ubi 17

3.1 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . 18

iii

iv CONTEÚDO

3.1.2 Requisitos não funcionais . . . . . . . . . . . . . . . . 20

3.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Ecrãs tácteis . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 PDA com ou sem GPS . . . . . . . . . . . . . . . . . . 22

3.2.3 Telemóvel . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Tecnologias e Ferramentas . . . . . . . . . . . . . . . . . . . . 23

3.4 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.2 Móvel e Carro . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.3 Transportes Públicos . . . . . . . . . . . . . . . . . . . 30

3.4.4 Casa e Trabalho . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Servidor 33

4.1 Base De Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.2 Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.3 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.5 Conteúdos . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.6 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.7 Transportes . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Privacidade e Segurança . . . . . . . . . . . . . . . . . . . . . 40

4.3 Métodos e Classes . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.1 Diagrama do Visual Studio . . . . . . . . . . . . . . . 42

4.3.2 Classe: Com . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.3 Classe: LigacaoBD . . . . . . . . . . . . . . . . . . . . 46

4.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CONTEÚDO v

5 Cliente Windows Mobile 49

5.1 Registo/Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.1 CryptoLib . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.2 Passos do Processo . . . . . . . . . . . . . . . . . . . . 53

5.2 Horários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Amigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 Mobile Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 Cliente Windows 61

6.1 BTLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7 Conclusão 69

7.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Bibliografia 73

Lista de Figuras

3.1 Esquema da plataforma carFree.ubi . . . . . . . . . . . . . . 26

3.2 Web Services Description Language (WSDL) do Servidor . . 27

3.3 Menu principal da aplicação PDA . . . . . . . . . . . . . . . 30

3.4 Menu principal da aplicação Windows . . . . . . . . . . . . . 31

4.1 Diagrama da Base de Dados . . . . . . . . . . . . . . . . . . . 35

4.2 Diagrama do VS2008 do Servidor . . . . . . . . . . . . . . . . 42

5.1 Diagrama do VS2008 da aplicação Windows Mobile . . . . . 50

5.2 Menu principal da aplicação Windows Mobile . . . . . . . . 53

5.3 Menu 1 da aplicação Windows Mobile . . . . . . . . . . . . . 54

5.4 Menu de login da aplicação Windows Mobile . . . . . . . . . 55

5.5 Menu horários da aplicação Windows Mobile . . . . . . . . . 56

5.6 Menu amigos da aplicação Windows Mobile . . . . . . . . . 57

5.7 Menu histórico da aplicação Windows Mobile . . . . . . . . 58

5.8 Menu Mobile Info da aplicação Windows Mobile . . . . . . . 59

6.1 Diagrama do VS2008 da aplicaçao Windows . . . . . . . . . 62

6.2 Lista de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Teclado virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.4 Exemplo de uma autenticação falhada . . . . . . . . . . . . . 66

vii

Acrónimos

DS Desenvolvimento Sustentável

SI Sistema de Informação

GPS Global Positioning System

VS2008 Visual Studio 2008

DEA Diagrama de Entidade-Associaçao

WSDL Web Services Description Language

PDA Personal Digital Assistant

MAC Media Access Control

API Application Programming Interface

DC Developed Countries

RFID Radio Frequency Identification

SOA Service Oriented Architecture

DLL Dynamic-link library

IDE Integrated Development Environment

SDK Software Development Kit

IIS Internet Information Services

HTTP Hypertext Transfer Protocol

ix

x Acrónimos

HTTPS HyperText Transfer Protocol Secure

FTP File Transfer Protocol

SMTP Simple Mail Transfer Protocol

NMTP Negotiable Mail Transfer Protocol

GUI Graphical User Interface

IA Inteligência Artificial

GDI Graphics Device Interface

SQL Structured Query Language

WPF Windows Presentation Foundation

UBI Universidade da Beira Interior

WSE Web Services Enhancements

XML Extensible Markup Language

IV Initialization Vector

AES Advanced Encryption Standard

CBC Cipher-block Chaining

ECB Electronic CodeBook

MD5 Message-Digest algorithm 5

Capítulo 1

Introdução

Objectivo do documentoEste relatório descreve detalhadamente o trabalho desenvolvido para a

disciplina de Projecto do curso de Engenharia Informática na Universidadeda Beira Interior. O documento condensa um conjunto de conhecimentosadquiridos e justifica as abordagens seguidas na sua implementação.

Objectivo do projectoAo longo do percurso académico pretende-se que o aluno adquira di-

versas competências que se reflectem no desenvolvimento de um projectoà sua escolha. Escolha esta que foi previamente construída e desenvolvidaem colaboração com o Professor orientador, culminando no objectivo deconstruir uma plataforma inovadora que permitisse melhorar a experiên-cia de utilização do utente de transportes públicos. Este projecto nasceuda combinação de inúmeros factores e resultou na participação da finalnacional do concurso da Microsoft (Imagine CUP1) que tinha por tema:"Imagina um mundo onde a tecnologia possibilita um ambiente sustentável"2.

Aprendizagem complementarPara além deste projecto representar um grande desafio na construção

de uma ideia que fosse verdadeiramente contributiva ao ambiente, ele

1http://www.microsoft.com/portugal/imaginecup/vencedoresnacionais.mspx2http://imaginecup.com/PT/SD.aspx

1

http://www.microsoft.com/portugal/imaginecup/vencedoresnacionais.mspx

http://imaginecup.com/PT/SD.aspx

2 Introdução

surgiu também no seguimento da vontade de estudar sistemas ubíquos(ver capítulo 2). Este tipo de sistemas, apesar de ter uma importânciacrescente, não é abordado no plano curricular actual do curso. O quepor si também foi factor decisivo na escolha do projecto e do orientador.A vontade de enriquecer e complementar o conhecimento adquirido éinsaciável.

EquipaDada a exigência do desenvolvimento de raíz de uma arquitectura tão

vasta, considerou-se fundamental construir uma equipa capaz de desen-volver um trabalho com impacto suficiente para uma participação na finalnacional do Imagine CUP. A equipa que se passou a designar por Ubiquistaficou constituída pelos seguintes elementos: André Passos, Joaquim Tojal,João Oliveira e Joel Carvalho. Cada qual com um conjunto de respons-abilidades e tarefas específicas (ver 1.2) providenciando independência notrabalho. Sendo dois destes alunos do projecto ImagineCup@ubi (JoaquimTojal e Joel Carvalho) ficou-lhes atribuído maior quota de trabalho no pro-jecto global.

1.1 Motivação

Computação UbíquaEste projecto tem uma origem um quanto peculiar comparativamente

aos restantes. Da curiosidade e vontade de estudar a computação ubíquaconciliada com a abertura do Professor orientador surgiu esta necessidade.Assimilados os conceitos e a filosofia, tornou-se a dada altura imperativopensar num caso de estudo que permitisse enfrentar as dificuldades e peri-gos referidos na literatura (ver capítulo 2). Desenvolver uma arquitecturaque pretende integrar diversos tipos de dispositivos conciliando diversasformas de utilização não é algo trivial nem pode ser descurado. A pri-vacidade dos dados tem de ser garantida e o sistema deve adaptar-se aoutilizador, nunca o contrário.

Imagine CUP 2008Uma vez que o desenvolvimento deste projecto é focado no enriquec-

1.1 Motivação 3

imento pessoal dos alunos, em detrimento de produção científica (maisadequada para Mestrado), torna-se evidente que a participação num con-curso é uma mais-valia. O Imagine CUP para além de ser um desafio é umajanela de oportunidade, quer para promoção pessoal como institucional.Sendo que desde cedo o Imagine CUP fez sentido, especialmente quandoa temática do concurso deste ano foca um assunto que nos preocupa atodos. Está-se claro a falar do ambiente numa vertente em que não sepretendem posições extremistas mas sim pensadas no DesenvolvimentoSustentável (DS).

SI’s ao serviço do ambienteO desafio de produzir um Sistema de Informação (SI) capaz de con-

tribuir para o ambiente foi uma motivação extra. Mas não foi fácil escolheruma ideia a desenvolver que fosse suficientemente boa e inovadora. In-clusivamente no processo de selecção de ideias foram descartadas umaquantidade substancial delas já que o objectivo da participação no con-curso era conseguir-se pelo menos um apuramento para a final nacional.O problema dos SI’s é que estes não são de todo a maneira mais intuitiva decolaborar para um melhor ambiente. Mais facilmente se pensa em sistemaselectromecânicos, electrotécnicos e energéticos para melhorar o ambientedo que em SI’s.

Ideias abandonadasNas ideias que ficaram para trás destacam-se algumas que até são de

algum interesse, no entanto foram consideradas como insuficientes ou de-masiado óbvias. Nomeadamente um sistema ubíquo de apoio ao consum-idor. A ideia deste sistema consistia em classificar os produtos alimentaresdisponíveis nos supermercados como sendo mais ou menos ecológicostendo em conta a sua origem e outras informações. Outra ideia passavapela implementação de um sistema ubíquo de informação e sensibiliza-ção ambiental, no qual se pretendia criar rotas verdes e desviar tráfego dezonas com níveis de poluição elevados.

4 Introdução

1.2 carFree.ubi

Descrição resumidaDe todas as ideias que foram consideradas convergiu-se para uma que

se passa a designar por carFree.ubi. A ideia principal do carFree.ubi éincentivar as pessoas a utilizar os transportes públicos em detrimento dostransportes particulares recorrendo a diversas tecnologias presentes noquotidiano. Apesar de actualmente ser na verdade mais confortável uti-lizar o veículo particular, isso não quer dizer que os transportes públicosnão possam superar esse conforto. O carFree.ubi pretende até contribuir namelhoria desse conforto fornecendo, ao utilizador de transportes públicos,conteúdos multimédia exclusivos no interior do próprio transporte. Issoé feito recorrendo a uma aplicação a correr em cada ecrã táctil instaladopor todos os lugares. O carFree.ubi pretende também facilitar a escolhado transporte mais rápido ou económico com base numa aplicação emWindows Mobile que serve de extensão do sistema de Global PositioningSystem (GPS) e que fornece informações em tempo real sobre a rede detransportes públicos. Pretende-se com isto agitar e alterar a forma comoos transportes públicos são vistos e utilizados. O tempo dispensado nasviagens quer-se produtivo e enriquecedor, coisa que actualmente não seconsegue na plenitude recorrendo ao transporte particular. É providenci-ada uma descrição mais detalhada, sobre como o carFree.ubi faz isso tudo,no capítulo 3 e seguintes.

Impacto dos transportesPara se chegar a esta ideia foi importante estudar um pouco todos os

problemas ambientais e perceber qual a abordagem do DS. Dos diversosproblemas existentes foi interessante constatar que a utilização massivados transportes públicos tem várias consequências ambientais, sociais eeconómicas. Sabendo que o DS é construído sobre estes três pilares inter-dependentes e mutuamente sustentadores tornou-se evidente que umasolução como o carFree.ubi já devia existir há mais tempo. Como provadisso é interessante constatar como recentemente a questão do preço doscombustíveis veio abanar os transportes. Um estudo americano[2] feitoà pouco mais de seis meses veio revelar, para além do impacto directoda poluição, dados impressionantes. Por exemplo foi divulgado que ocusto provocado pelos congestionamentos das metrópoles, apenas nos

1.2 carFree.ubi 5

Estados Unidos, era avaliado em 78 mil milhões de dólares. Valor quecorresponde a 4.2 mil milhões de horas perdidas e 10.97 mil milhões delitros de combustível perdido.

VantagensPara além de tudo o que já se possa imaginar pela argumentação feita

até ao momento. A vantagem do carFree.ubi em instrumentalizar umaferramenta que pode apoiar medidas políticas para a limitação da utiliza-ção dos transportes particulares no interior dos centros urbanos é tambémuma mais-valia incontestável. Ao contrário do que foi feito noutras áreas éimportante melhorar as soluções existentes antes de tomar medidas maisduras. Mas a verdade é incontornável, se o crescimento dos transportesparticulares continuar a aumentar, mesmo que estes não sejam poluentes,vai chegar-se a um ponto de saturação em que ninguém vai fazer distanciascurtas em tempos considerados decentes. Muitas cidades europeias já pos-suem os centros urbanos cortados a trânsito rodoviário excepto transportespúblicos e abastecimento de comércios. Essa realidade vai fazer parte dofuturo de todas as cidades e os transportes públicos vão ter que se adaptarde modo a servir as necessidades dos utentes. O carFree.ubi enquadra-seperfeitamente numa solução que consegue suportar melhor essa neces-sidade, para mais informações pode consultar documentos referidos nasecção contributo.

DificuldadesUma das questões que acabou por surgir, incide no facto do que possa

acontecer se realmente este sistema conseguir resultados. Existe o receio,por parte de quem avaliou a ideia, do carFree.ubi se tornar inutilizávelem caso de saturação dos transportes públicos. Como só existem ecrãstácteis nos assentos, quem fica de pé não tem acesso ao sistema. A ideiado carFree.ubi é de um sistema adaptado às necessidades dos utentes,promovendo qualidade de vida e melhorando a experiência de utilizaçãodos transportes públicos. Um caso de saturação de transporte público,para além de comportar uma situação ilegal, é a antítese da plataformacarFree.ubi. Qualquer rede de transportes públicos que trabalhe para obenefício dos utentes e queira um sistema como este, de certeza que nãovai aceitar que os seus transportes estejam constantemente sobre saturação.

6 Introdução

Os transportes públicos, para além de terem a obrigação de se adaptar àsnecessidades dos utentes, devem servi-los com a máxima qualidade. Seas transportadoras e os governos querem resolver o problema dos con-gestionamentos nos grandes centros urbanos só existe uma solução! Nãopermitir o transito de veículos particulares no centro das cidades. Por con-seguinte torna-se necessário aumentar a frota de transportes e melhorar oincentivo da utilização dos mesmos. Decisão esta que pode ser sustentadacom a plataforma carFree.ubi.

Divisão de trabalhoComo foi referido anteriormente o carFree.ubi foi desenvolvido por qua-

tro elementos de forma independente, no entanto ligada. A arquitectura docarFree.ubi é apresentada no capítulo 3, mas em forma de breve antevisãoapresenta-se desde já a divisão do trabalho.

• André Passos - Responsável pelo desenho da interface da aplicaçãocliente em Windows.

• Joaquim Tojal - Responsável por:

• Desenho da interface da aplicação cliente em Windows Mobile.

• Desenvolvimento da parte relativa à extensão do sistema GPS.Sistema que consiste resumidamente em fornecer rotas alter-nativas ao transporte particular indicando ao condutor ondeestacionar o carro, qual a paragem a tomar para chegar ao seudestino e posteriormente conseguir voltar. Tudo dentro doshorários que ele pretenda cumprir. Para mais informações con-sultar relatório número 54.

• João Oliveira - Responsável pela componente de inteligência artificial.

• Joel Carvalho - Responsável por:

• Desenho da arquitectura do sistema e da base de dados, bemcomo a forma como a comunicação entre os clientes e servidoré feita.

• Definição das políticas de segurança e privacidade, incluindo omodo como os utilizadores são identificados pelo sistema,

1.3 Contributo 7

• Desenvolvimento da aplicação servidor.

• Desenvolvimento de parte da aplicação cliente do Windows noque respeitou o login.

• Desenvolvimento de parte da aplicação Windows Mobile no querespeitou o registo do utilizador no sistema e configuração deprimeira utilização da aplicação Mobile bem como desenvolvi-mento de algumas opções como a consulta de horários, consultade dados do utilizador entre outros.

1.3 Contributo

carFree.ubiComo contributo principal destaca-se o desenvolvimento da plataforma

em si. Desde a ideia até à execução, todo o trabalho foi feito de raiz e oresultado possui potencialidades futuras que não podem ser ignoradas.Esta plataforma colmata necessidades existentes nos centros urbanos quejá possuem uma boa rede de transportes públicos.

BTLibPara além do que foi referido anteriormente, ainda foram desenvolvidas

duas bibliotecas. Durante o desenvolvimento do carFree.ubi cada um foi-se deparando com algumas dificuldades. Dessas dificuldades resultou anecessidade de criação e utilização de uma biblioteca .NET (desenvolvidaem C++) capaz de descobrir dispositivos como Telemóveis e PersonalDigital Assistant (PDA)’s através de Bluetooth e recolher o Media AccessControl (MAC) Address dos mesmos. Essa necessidade surgiu uma vezque a Application Programming Interface (API) da Microsoft feita emC++ revelou-se muito sensível a algumas manipulações (ver capítulo 6).Esta biblioteca ficou designada por BTLib e encontra-se em processo deavaliação para publicaçao na SourceForge3.

CryptoLibA outra biblioteca surgiu da necessidade de facilitar a utilização da

3http://sourceforge.net/projects/btlib/

http://sourceforge.net/projects/btlib/

8 Introdução

API criptográfica da Framework .NET, no sentido que a mesma revela-senecessária para algumas partes fundamentais do projecto e considerou-semais útil desenvolver esta biblioteca de forma a ser totalmente reutilizávelquer pela aplicação Windows como Windows Mobile. Mais uma vez trata-sede uma bilbioteca .NET (desenvolvida em FSharp) que ficou designadapor CryptoLib, sendo que a mesma se encontra em processo de avaliaçãopara publicaçao na SourceForge4.

DocumentosAinda foi necessário realizar e apresentar alguns documentos5 no âm-

bito do concurso que se decidiu publicar quer para futuros alunos quepretendam participar no Imagine CUP como também para divulgação doprojecto. Existem também referências feitas na página oficial da Microsoft6

com alguma informação sobre o projecto.

1.4 Organização do relatório

Este relatório divide-se em capítulos. No primeiro capítulo optou-se porfazer uma breve introdução ao projecto.

Cap 2 - Estado de ArteNo segundo capítulo são introduzidos os princípios e a filosofia agregada

ao sistema desenvolvido.

Cap 3 - Plataforma carFree.ubiNo terceiro capítulo descreve-se a plataforma carFree.ubi bem como a

análise de requisitos, as tecnologias e os dispositivos utilizados.

4http://sourceforge.net/projects/cryptolib/5http://skydrive.live.com/6http://www.microsoft.com/portugal/presspass/press/2008/mai08/

05-21imaginecup2008.mspx

http://sourceforge.net/projects/cryptolib/

http://skydrive.live.com/

http://www.microsoft.com/portugal/presspass/press/2008/mai08/05-21imaginecup2008.mspx

http://www.microsoft.com/portugal/presspass/press/2008/mai08/05-21imaginecup2008.mspx

1.4 Organização do relatório 9

Cap 4 - ServidorNo quarto capítulo aborda-se de forma mais detalhada o trabalho de-

senvolvido no Servidor onde se inclui a descrição da Base de Dados daplataforma.

Cap 5 - Cliente Windows MobileNo quinto capítulo apresenta-se e descreve-se a aplicação cliente para

Windows Mobile bem como uma biblioteca criptográfica desenvolvida.

Cap 6 - Cliente WindowsNo sexto capítulo descreve-se o trabalho desenvolvido no cliente Win-

dows que funciona no interior dos transportes públicos e uma bibliotecapara descoberta de dispositivos bluetooth.

Cap 7 - ConclusãoNo último capítulo fazem-se as últimas conclusões e finaliza-se o re-

latório.

Capítulo 2

Estado de Arte

Dispositivos computacionaisA proliferação massiva de dispositivos com capacidades computacionais

tem-se alargado um pouco por todas as áreas. Os computadores já não sãoapenas peças de Hardware volumosas de ter em casa junto da secretária.Qualquer cidadão de um país dito desenvolvido segundo padrões con-sumistas (Developed Countries (DC)[1]) possuí pelo menos um disposi-tivo com capacidades computacionais. Esses dispositivos são actualmentemuito diversificados desde PDA’s, Telemóveis, Smart Card’s, Radio Fre-quency Identification (RFID)’s, entre muitos outros.

Princípios fundamentaisO problema deste aglomerado de dispositivos é que, apesar de muitos

serem comunicantes cada um funciona no seu pequeno mundo e com assuas regras. Mark Weiser, considerado hoje como o pai da computaçãoubíqua[3], publicou em 1991 e 1993 alguns documentos com citaçõesinspiradoras[14][12][13][11]. Desses documentos destacam-se citações comoas seguintes:

• "A good tool is an invisible tool. By invisible, I mean that the tool does notintrude on your consciousness; you focus on the task, not the tool."[14]

• "The technology required for ubiquitous computing comes in three parts:cheap, low-power computers that include equally convenient displays, a

11

12 Estado de Arte

network that ties them all together, and software systems implementingubiquitous applications."[11]

• "A well-implemented version of ubiquitous computing could even affordbetter privacy protection than exists today."[11]

• "Unlike PDA’s, ubiquitious computing envisions a world of fully connecteddevices, with cheap wireless networks everywhere; unlike PDA’s, it postu-lates that you need not carry anything with you, since information will beaccessable everywhere."[12]

TecnologiaPassado uma década Mark Weiser começa a ganhar uma importância

fundamental. Afinal a sua visão dos computadores estarem em todo olado e comunicarem essencialmente por redes sem fios tornou-se uma re-alidade. Como exemplo basta pegar nos PDA’s. Estes são hoje uma junçãodos descritos, na última citação de Mark Weiser, no entanto com a inte-gração de capacidades atribuídas aos telefones móveis mais tradicionais ecom a grande vantagem de terem acesso a redes sem fios. O PDA que MarkWeiser refere em 1993 é bem diferente do PDA actual. O actual está incriv-elmente mais próximo da visão de sistemas ubíquos do que muitos outrosdispositivos, mesmo sendo um dispositivo que pode ser transportado.

O FuturoO culminar da filosofia apresentada por Mark Weiser, onde todos os

dispositivos computacionais passam a servir as populações de forma in-visível, vai dar-se quando se perder a consciência completa da tecnologiaque se utiliza e se focar meramente na tarefa. Pode imaginar-se que otal PDA sofre mais uma evolução e passa a fazer parte dos óculos quemuitas pessoas usam. As pessoas precisam dos óculos para corrigir umadificuldade visual, mas porque não dar-lhe uma funcionalidade extra?Continuando a ficcionar, imagine-se que os mesmos recebem instruçõesvocais que processam e executam acções. Essas acções podem ter um out-put visual, numa parte da lente dos óculos, e um ouput sonoro, produzidopor vibrações transmitidas pela armação fazendo chegar o som ao ouvidosem que ninguém se aperceba.

2.1 Discussão existente 13

Computação UbíquaNo entanto os sistemas ubíquos precisam de software, sem ele os dis-

positivos não passam de meros objectos com funcionalidades próximas deuma pedra. Não basta ter as tecnologias, é preciso integrar as mesmas efazer com que elas realmente sirvam a população. A computação ubíquadefendida por Mark Weiser tem um papel importantíssimo no desenvolvi-mento futuro de aplicações. Já chega de desenvolver aplicações e sistemassem pensar nas consequências. É preciso defender os interesses e direitosdos utilizadores de modo a que estes realmente gostem, queiram e tenhamproveito na utilização das tecnologias sem sequer pensarem nelas. Cadavez mais a privacidade das pessoas é invadida, todos os dias existem mil-hares de câmaras a vigiar as cidades. Todos os dias deixamos rastos doque fazemos, quando fazemos, como fazemos só falta registas o porquê.Mas afinal porque é que os sistemas não evoluem de modo a salvaguardara privacidade das pessoas?

ParadigmasA grande dificuldade actual encontrada no desenvolvimento de com-

putação ubíqua é, precisamente, como praticá-la correctamente e com baseem que paradigma. Ainda não se pode dizer que exista um modelo rígidoque defina como e quando se deve praticar computação ubíqua. Istoporque derivaram da computação ubíqua diversos paradigmas, nomeada-mente o Wearable Computing[8], o Activity-Based Centered UbiquitousComputing[6], ou ainda o Context Aware Mobile Computing[4].

2.1 Discussão existente

Adam Greenfield[10] é um escritor reconhecido a nível internacional eé uma das pessoas que mais tem participado activamente para um de-bate aberto sobre a computação ubíqua. Já publicou um livro intitulado:"Everyware: The dawning age of ubiquitous computing". Algumas das suaspalestras[7] para além de apresentarem a temática, abordam uma serie depreocupações com as quais se deve ter algum cuidado. Tal como MarkWeiser, Adam Greenfield considera que o desenvolvimento de tais sis-temas deve ser cuidado por diversos motivos que vão ser apresentados deseguida.

14 Estado de Arte

InadvertênciaUm deles é a inadvertência dos utilizadores. Imaginando um sistema

ubíquo que permite difundir a localização do utilizador para um conjuntolimitado de pessoas ou para todas as pessoas. O facto do utilizador poderenganar-se num botão, e em vez de divulgar a sua posição apenas para umconjunto limitado de pessoas o fizer para todas, consistiu um risco. Riscoesse que pode e deve ser limitado se o desenvolvimento do sistema fordevidamente pensado.

DesconhecimentoOutro factor a ter em consideração é o desconhecimento, por parte dos

utilizadores, do sistema. Eles podem não saber da existência do mesmo oupodem não conhecer todas as suas funcionalidades. Consequentementenão sabem que informações o sistema recolhe, o que é feito com essasinformações ou até mesmo quem as guarda e com que objectivo. Apesarde isso ter um lado positivo, porque torna-se invisível para o utilizador,não o interrompe na sua tarefa nem molda a sua maneira de actuar. Naverdade pode constituir um problema, porque todos possuem o direito desaber o que é feito com os dados que são recolhidos das suas interacções.

RejeiçãoSegundo Adam Greenfield, este é o tema mais controverso. O facto de

uma pessoa rejeitar a utilização de um sistema, seja por qual motivo for,deve ser um direito inquestionável. Ninguém deve ser obrigado a utilizaralgo que não quer. No entanto nem sempre se aceita esta premissa nodesenvolvimento de sistemas ubíquos. Muitas vezes parte-se do princípioerrado de que todos vão aceitar e querer utilizar o sistema. Existem muitosexemplos de sistemas que não são propriamente ubíquos mas obrigam outilizador a aceitar algo que pode não querer. As câmaras de vigilância sãoum exemplo disso. No entanto se for evitável repetir erros actuais deve-seevoluir para soluções que garantam a privacidade das pessoas, já que éum direito constitucional.

EpílogoO importante a reter actualmente é precisamente o perigo que pode advir

de um sistema ubíquo pouco pensado. A discussão sobre o tema contínua

2.2 Framework adoptada 15

em aberto e o seu sucesso depende do que as equipas de desenvolvimentodecidirem considerar como proveitoso. De notar que como qualquer tipode sistema a computação ubíqua só consegue ter o seu sucesso se for cen-trada nas pessoas. Quer no que elas precisam como nas suas preocupações.Como exemplo a seguir, se um sistema ubíquo regista alguns dados de in-teracção do utilizador o ideal será nunca saber ao certo quem é o utilizador(ver capítulo 3).

2.2 Framework adoptada

Framework .NETA computação ubíqua, dada a sua natureza, permanece em desenvolvi-

mento contínuo. Existem no meio académico algumas frameworks desen-volvidas e outras em desenvolvimento como o caso do ActivitySpot[9].Todavia a abordagem adoptada no desenvolvimento do sistema foi orien-tada pela necessidade de usar as ferramentas da Microsoft uma vez que oconcurso Imagine CUP assim o exigia.

Paradigma SOAA escolha da Framework .NET levou a que fosse seguida o paradigma

Service Oriented Architecture (SOA)[5]. Este paradigma tem a particulari-dade de permitir a utilização de Web Services em .NET tal como era exigidopara efeitos de concurso e possibilita o desenvolvimento de um sistemaque não fica dependente da Framework. Simultaneamente o SOA potenciao desenvolvimento de aplicações com base na computação ubíqua.

2.3 Conclusão

Este capítulo introduziu o contexto da plataforma ubíqua que vai passara ser descrita no capítulo seguinte. Para além do estudo teórico apresen-tado, muitas das ideias presentes neste capítulo vão servir de suporte paraescolhas tomadas no desenvolvimento do carFree.ubi.

Capítulo 3

Plataforma carFree.ubi

ObjectivoO carFree.ubi consiste numa plataforma ubíqua que interliga uma série

de dispositivos e tecnologias de modo a fornecer ao utente de transportespúblicos informações e serviços considerados úteis em qualquer lugar.Tal como foi referido, o objectivo principal do carFree.ubi é incentivara utilização dos transportes públicos recorrendo a tecnologias utilizadasmassivamente nos dias correntes.

Arquitectura Cliente/ServidorA arquitectura da plataforma baseia-se na arquitectura cliente/servidor

comum a muitos sistemas distribuídos. Nesta arquitectura incluem-se trêstipos de clientes distintos. Um dos tipos de clientes é uma aplicação paraWindows Mobile que para além de possibilitar a consulta de horários eoutras informações em tempo real, também é um autêntico assistente deviagens para transportes públicos. Outro cliente é uma aplicação Windowsque funciona com ecrãs tácteis e que permite a consulta de conteúdosmultimédia exclusivos. O último cliente é simplesmente uma página Webinstitucional, isto é, pode ser simplesmente a página Web da empresa quegere os transportes públicos. Esta arquitectura é descrita com maior detalhena secção 3.4.

17

18 Plataforma carFree.ubi

3.1 Análise de Requisitos

Antes de se passar a uma maior descrição da plataforma em si, apresenta-sea análise de requisitos feita. Esta análise foi realizada avaliando informal-mente as necessidades de um conjunto de pessoas de confiança. Destaforma foi possível perceber em que medida um sistema ubíquo podia cor-responder às suas necessidades mantendo uma certa descrição em todaa fase de desenvolvimento. Esta descrição foi necessária uma vez quese pretendia chegar ao Imagine CUP com uma ideia totalmente distinta eoriginal.

3.1.1 Requisitos funcionais

RF01 - Conteúdos multimédiaAlgo que ficou imediatamente identificado foi a necessidade de tornar

o tempo dispendido dentro dos transportes públicos de maior qualidadee utilidade. Numa sociedade em constante evolução os transportes, inde-pendentemente do tipo, possuem uma importância crescente. Pensando eolhando para os utilizadores de transportes públicos actuais, constata-sefacilmente que alguns tentam passar esse tempo ocupando-se. Algunslêem jornais, outros jogam no telemóvel, outros telefonam ou falam comamigos, etc. É claro que existe sempre quem dedique o tempo da viagema fazer uma reflexão interna e não queira outra solução. O requisito queaqui fica identificado é a necessidade do sistema possibilitar (e não obri-gar) aos utentes a consulta de conteúdos multimédia dentro dos própriostransportes.

RF02 - Assistente de viagensOutra questão pertinente e que rapidamente se fez transparecer foi a ne-

cessidade de melhorar o conforto e a comodidade dos transportes públicos.Isto porque, estes dois factores são responsáveis por muitos condutores nãoabdicarem dos seus veículos particulares. Relativamente à comodidade,identificou-se como requisito a possibilidade de integração dum assistentede viagens. Este deve fornecer, de forma simples e intuitiva, alternativasao percurso a realizar com o veículo particular. Isto é, o condutor deixa dese preocupar onde vai estacionar o carro e se as ruas X e Y estão ou não

3.1 Análise de Requisitos 19

congestionadas. Antes de entrar numa cidade, o condutor utiliza o assis-tente de viagens de modo a que este lhe indique um local onde estacionaro carro e qual o transporte público a seguir para chegar mais facilmente aoseu destino dentro da hora pretendida.

RF03 - Conteúdos adaptáveisRelativamente ao conforto identificou-se como requisito a possibilidade

de utilizar métodos de inteligência artificial para ajustar os conteúdosmultimédia ao comportamento do utente. À semelhança do que é feitoem alguns sistemas Web é possível classificar os utilizadores pelo quevisualizam. Deste modo, consegue-se sugerir conteúdos que possam serdo seu interesse.

RF04 - Conteúdos recuperáveisAlgo que ficou assente no seguimento dos requisitos anteriores é que

torna-se necessário guardar de alguma forma o estado do último conteúdovisualizado pelo utente. Isto para permitir que um conteúdo que tenhaficado em aberto seja recuperado no mesmo estado aquando de uma novasessão por parte daquele utente.

RF05 - Agrupamento de utilizadoresOs SI’s são muitas vezes acusados de fechar as pessoas num mundo à

parte. Uma vez que este sistema já pretende integrar uma componente deinteligência artificial, surgiu como requisito a possibilidade de tentar criaruma rede de socialização dos utentes. Esta rede que passa a ser designadapor rede de amigos tem como objectivo o agrupamento de utilizadorespelos conteúdos visualizados.

RF06 - Informação em qualquer lugarA exigência da sociedade manifesta-se perante os SI’s com a necessidade

de ter acesso a qualquer informação em qualquer lugar. No âmbito destesistema, a consequência dessa exigência é a identificação de um requisitoque permita a qualquer utilizador aceder a informações pertinentes ondequer que esteja. Isto é, considera-se útil que o utilizador possa aceder àsseguintes informações:


• Histórico dos conteúdos visualizados nos transportes públicos.

• Horários dos transportes públicos.

• Lista de amigos presentes num determinado transporte público.

• Dados sobre o registo do utilizador no sistema.

RF07 - Página Web institucionalComo vem sendo comum em qualquer organização ou empresa, fica

como ultimo requisito a necessidade de associação do sistema a uma páginainstitucional. Na qual devem constar, para além das informações sobre aempresa gestora da rede de transportes, informações detalhadas sobre ofuncionamento do carFree.ubi e condições de utilização.

3.1.2 Requisitos não funcionais

RNF01 - SegurançaComo ficou patente nos requisitos funcionais, é necessário ter utilizadores

no sistema. Cada utilizador deve ser identificado por um dos dois con-juntos de pares, password e dispositivo móvel (Telemóvel ou PDA) oupassword e número de registo. Por motivos de segurança a password éprivada e cifrada. Por motivos de privacidade o identificador do disposi-tivo, neste caso o MAC Address, também é cifrado.

RNF02 - PrivacidadeEm momento algum são utilizados dados pessoais do utilizador. O

sistema não precisa nem deve solicitar ou armazenar dados como nome,morada e outros. Cada utilizador é essencialmente identificado pelosdispositivos que utiliza. Apesar de os dispositivos possuírem um MACAddress que é público apenas o próprio utilizador pode fazer a associaçãoentre o MAC Address e o número de registo.

RNF03 - PortabilidadeApesar de o sistema ser desenvolvido para um concurso com as fer-

ramentas da Microsoft pretende-se como requisito que o mesmo tenha

3.2 Dispositivos 21

alguma portabilidade. Nesse sentido deve utilizar-se o paradigma SOApara possibilitar uma futura utilização do servidor noutras plataformasque não Windows.

RNF04 - ManutençãoUm sistema com uma dimensão como este exige que a programação seja

feita por partes e com documentação suficiente. Neste caso, pelo menos,comentários aos métodos e uso de dll’s para algumas componentes daaplicação.

RNF05 - UsabilidadeQualquer aplicação deve ser feita pensando na forma como o utilizador

vai interagir com a mesma e com o meio envolvente. A aplicação para PDAdeve ser confortável na sua utilização, não exigindo demasiado escrita detexto por parte do utilizador. Por sua vez a aplicação Windows deve serpensada e realizada considerando que não existe nenhum teclado ao dispordo utente. Portanto a interface deve ser desenhada tendo em conta que outente tem um ecrã táctil à sua frente, no qual, caso seja necessário deveser utilizado um teclado virtual.

RNF06 - FiabilidadePela natureza ubíqua da aplicação torna-se evidente a indispensabili-

dade do utilizador ter acesso, em qualquer lado, a uma rede privada semfios ou a uma rede internet sem fios. O sistema deve ser visto como umsistema adaptado e enquadrado às cidades mais modernas, que no entantovão tornar-se comuns em breve.

3.2 Dispositivos

No seguimento dos requisitos foram identificados os dispositivos a utilizarnesta plataforma. De notar que, apesar da escolha feita, outras soluçõesforam avaliadas como por exemplo smartcard’s sem contacto à semelhançados passes utilizados no Porto. No entanto, e apesar de serem mais seguros,os mesmos não são de fácil acesso. Sendo a plataforma algo complexa e


o tempo de desenvolvimento curto, optou-se por recorrer a equipamentosde acesso mais imediato. Mas numa futura implementação do sistemaestas soluções não são de desprezar.

3.2.1 Ecrãs tácteis

Apesar de não terem sido utilizados, o desenvolvimento da aplicaçãoa correr no interior dos transportes públicos, foi pensada neste tipo deequipamento. Este tipo de dispositivos é ideal para servir de interfacenum ambiente urbano. Para além de ocuparem um espaço muito limitadopermitem uma interacção mais intuitiva. À semelhança de muitas tarefasque são realizadas no dia-a-dia com um ecrã táctil descarta-se qualquernecessidade de objectos supérfluos como o rato e o teclado. Este disposi-tivo enquadra-se nos objectivos dos requisitos RF01 (ver 3.1.1), RF03 (ver3.1.1), RF04 (ver 3.1.1). Para além de servir como meio de identificação doutilizador (RFN01, ver 3.1.2) perante os ecrãs tácteis existente no interiordos transportes.

3.2.2 PDA com ou sem GPS

Este não é um dispositivo muito comum mas a verdade é que o seu preçocomeça a aproximar-se cada vez mais ao dos telemóveis. Tendo maisfuncionalidades, é uma questão de tempo até existir uma fusão dos doisdispositivos ou dos telemóveis desaparecerem para apenas sobreviver oPDA. Este dispositivo enquadra-se nas necessidades dos requisitos RF06(ver 3.1.1) e RF02 (ver 3.1.1). No caso do RF02, o dispositivo requer aexistência de GPS integrado ou de um dispositivo GPS externo. Masapesar de poderem funcionar na mesma aplicação o RF06 e RF02 sãoindependentes.

3.2.3 Telemóvel

Uma vez que existe a consciência de nem todos disporem de PDA’s eassim o utilizador já não conseguir ter acesso às funcionalidades própriasda aplicação Mobile. Pretende-se que o mesmo possa pelo menos usufruir

3.3 Tecnologias e Ferramentas 23

dos serviços no interior do autocarro. Deste modo o telemóvel ou outrodispositivo comunicante bluetooth pode servir como meio de identificaçãodo utilizador (RFN01, ver 3.1.2).

3.3 Tecnologias e Ferramentas

ContextualizaçãoEsta plataforma mexe com múltiplas técnicas e tecnologias mas nem to-

das foram introduzidas. De seguida são apresentadas muito brevementetodas as tecnologias que estão de uma ou outra forma integradas na apli-cação.

VS2008O Visual Studio 2008 (VS2008) é um Integrated Development Environment

(IDE) da Microsoft que permite desenvolver aplicações usando um lequeinteressante de linguagens para diversas situações. O VS2008 permite criarbibliotecas, aplicações para consola ou aplicações gráficas para Windows eWindows Mobile. Através deste IDE foi possível utilizar e integrar lingua-gens como o C++, CSharp e FSharp no desenvolvimento da plataforma.

Windows SDKO Windows Software Development Kit (SDK) reúne um conjunto de

bibliotecas, API’s e exemplos para desenvolvimento de aplicações em Win-dows. Este SDK foi necessário para o uso da API Bluetooth da Microsoft.

Framework .NET 3.5A Framework .NET é uma componente integrante dos sistemas oper-

ativos da Microsoft. Esta é talvez um dos maiores pontos favoráveis aodesenvolvimento de aplicações em Windows, uma vez que aglomera umconjunto enorme de bibliotecas. Para além disso, a Framework é expansívele pode ser usada em múltiplas linguagens flexibilizando a programação.

Compact Framework .NET 3.5A Compact Framework .NET é a versão Framework .NET da Microsoft


para dispositivos móveis e embebidos. Apesar de serem muito semel-hantes é preciso ter algum cuidado porque nem todas as funcionalidadesda Framework .NET existem nesta versão.

IIS 6.0O Internet Information Services (IIS) é um servidor Hypertext Transfer

Protocol (HTTP) HyperText Transfer Protocol Secure (HTTPS), File Trans-fer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) e NegotiableMail Transfer Protocol (NMTP) que corre em windows. Foi utilizado noprojecto como servidor de HTTP de modo a tornar os Web Services criadosdisponíveis pela internet.

MS SQL Server 2005O Microsoft MSQL Server é um servidor de Base de Dados para Windows

com uma interface de gestão completa. Uma vez que a plataforma necessitade armazenar dados no servidor, a solução adoptada foi recorrer à base dedados da Microsoft.

Microsoft Expression Blend 2Para o desenvolvimento da interface gráfica da aplicação Windows

optou-se por utilizar o Microsoft Expression Blend 2. Este Graphical UserInterface (GUI) builder facilita a criação de interfaces ricas para a Web eWindows.

Microsoft MapPointO Microsoft MapPoint é tanto uma tecnologia como uma ferramenta e

foi utilizado para o desenvolvimento da componente que pretende servirde extensão do GPS. Esta ferramenta permite integrar, editar e visualizarmapas. Ela penas foi utilizada pelo Joaquim Tojal, como tal, maioresreferências e explicações são feitas no relatório 54.

OpenNetCFA OpenNetCF desenvolveu e disponibilizou uma extensão da Compact

Framework .NET da Microsoft. Esta extensão teve de ser usada devido adois factores fundamentais:

3.4 Arquitectura 25

• Em primeiro pelo facto da Compact Framework não incluir os méto-dos da Framework .NET para derivação de chaves.

• Em segundo porque esta foi a solução mais prática que se encontroupara conseguir recolher internamente o MAC Address das interfacesde rede do PDA.

EpílogoComo é possível constatar todas as ferramentas utilizadas são da Mi-

crosoft, não porque fosse considerado que eram as melhores mas porqueassim era exigido para efeitos de concurso. No entanto, isso não consti-tuiu nenhuma limitação no desenvolvimento da plataforma, muito pelocontrário.

3.4 Arquitectura

Finalmente passa-se a apresentar a arquitectura que foi idealizada para estaplataforma ubíqua. A arquitectura baseia-se numa arquitectura cliente/servidore está dividida em módulos segundo alguns padrões de funcionamento.

3.4.1 Servidor

ObjectivoNo centro encontra-se o servidor, uma vez que esta é a peça nuclear

da arquitectura. Se o servidor falhar, falha toda a plataforma. Ou melhor,toda a plataforma fica parcialmente inutilizável já que as aplicações clientesprecisam de respostas do servidor. Por exemplo: a aplicação a funcionarno PDA deixa de fazer sentido se não conseguir receber respostas doservidor, no entanto a mesma continua a funcionar sem conseguir fornecerinformação ao utilizador. Já a aplicação a correr no interior dos transportespúblicos pode continuar a funcionar quase normalmente se tiver uma cachede conteúdos locais. Esta situação não foi implementada mas pode vira ser adicionada futuramente. Para uma implementação comercial destaplataforma seria necessário difundir o servidor por diversos computadoresde modo a que se algum falhasse, esse fosse compensado pelos restantes.


Figura 3.1: Esquema da plataforma carFree.ubi

3.4 Arquitectura 27

Figura 3.2: WSDL do Servidor

Sem claro esquecer a redundância que seria necessária com BackBones eRouters.

ComponentesPelo diagrama 3.1 consegue-se perceber que o servidor possui três com-

ponentes distintas mas interligadas e acessíveis por Web Services, são elasa Base de Dados, os WebServives e a Inteligência Artificial (IA). Em mo-mento algum um cliente comunica directamente com a Base de Dados oucom a classe de IA.

SegurançaSe um cliente quer alguma informação da Base de Dados a aplicação faz

esse pedido aos Web Services e eles tratam do resto. Optou-se por esta abor-dagem por motivos de segurança. Em momento algum se pretende darinformação mais do que o necessário a um atacante. Com esta metodologiatudo o que está para além dos Web Services é uma autêntica caixa negrapara qualquer atacante externo.


Inteligência ArtificialPouco se vai adiantar sobre a parte de inteligência artificial, uma vez que

a mesma foi desenvolvida pelo João Oliveira. Apenas fica mais uma breveexplicação sobre a motivação para esta componente existir na arquitectura.Como ficou identificado nos requisitos, considerou-se necessário ter umacomponente que permitisse adaptabilidade por parte da aplicação clientea correr nos transportes públicos. Também se considerou pertinente classi-ficar os utilizadores pelas suas interacções com a mesma aplicação clientede modo a proporcionar uma maior socialização dos utentes, caso elesassim o desejem. Com esta componente designada por rede de amigostorna-se muito mais fácil as pessoas ficarem a conhecer outras com osmesmos gostos.

Base de DadosA Base de Dados pode ser considerada como outra peça nuclear da

plataforma e a mesma é descrita com maior precisão no capítulo 4 já quefoi parte integrante do trabalho desenvolvido.

Web ServicesOs Web Services podem ser vistos na relação Cliente/Servidor como o

Front-End do sistema. Tal como foi referido previamente, estes é quesão responsáveis por dar resposta aos pedidos dos clientes sem que osmesmos tenham de se preocupar com a Base de Dados ou com qualqueroutra componente. A única necessidade existente é que o servidor HTTPesteja acessível para o cliente e que tenha todos os serviços activos. Partedos Web Services são descritos com maior detalhe no capítulo 4, aqueles queacabaram por ser feitos pelo Joaquim Tojal, devido às suas necessidades,não são apresentados neste relatório.

3.4.2 Móvel e Carro

ObjectivoEstas duas componentes da arquitectura apesar de estarem divididas

estão na verdade integradas numa só aplicação. Aplicação que pretendefornecer ao utilizador as seguintes funcionalidades:

3.4 Arquitectura 29

Figura 3.3: Menu principal da aplicação PDA

• Assistente de viagens GPS para transportes públicos como alternativaao particular (Joaquim tojal).

• Processo de primeira utilização da aplicação que pode servir paragerar ou recuperar um registo.

• Horários dos transportes públicos indicando o tipo do transporte e aparagem de origem e destino.

• Lista de amigos presentes e lugar que ocupam, num determinadotransporte público em tempo real.

• Histórico dos conteúdos visualizados nos transportes públicos, dadauma data de utilização e um tipo de conteúdo.

• Dados sobre o registo do utilizador no sistema, como a data de reg-isto, o número de registo e os MAC Address dos seus dispositivosregistados.


ComponentesO objectivo da divisão destas duas componentes é a de vincar a diferença

entre o trabalho do Joaquim Tojal referente ao RF02 (ver 3.1.1) e o que vaiser descrito com maior detalhe no capítulo 5 referente ao RF06 (ver 3.1.1).Optou-se por, comodidade do utilizador, juntar tudo numa só aplicação,mas como vai ser possível verificar a mesma está dividida e funciona deforma independente. Isto é, se o PDA não tiver GPS a parte relativa aoRF06 funciona, mas a parte relativa ao RF02 não.

InterfacePara se chegar ao resultado apresentado na figura 3.3 bem como no

capítulo 5 foi necessário recorrer a um processo de "desenho"de interfaces(GDI) integrado com controlos. Os créditos da pesquisa desta técnica edo desenho da interface principal vão para o Joaquim Tojal. Apesar decada um ter feito a sua parte da aplicação era obviamente incompatívelapresentar duas interfaces distintas. Deste modo, o trabalho apresentadono capítulo 5 faz uso da técnica citada.

3.4.3 Transportes Públicos

ObjectivosTal como ficou estabelecido no RF01 (ver 3.1.1), RF03 (ver 3.1.1), RF04

(ver 3.1.1) e RF05 (ver 3.1.1) esta aplicação pretende, de forma genérica,disponibilizar conteúdos multimédia (música, livros, jornais, revistas, etc.)de preferência exclusivos num ecrã táctil. O facto de fornecer conteúdosmultimédia não representa grande inovação, por mais bonita que possaser a interface. No entanto, o facto de isso ser feito num ecrã com qualidadee com uma interface agradável para o utilizador, conjugado com conteúdosque não estão disponíveis noutro lugar e uma certa adaptabilidade dainterface é sem dúvida uma mais-valia. Uma parte fundamental incidentesobre a disponibilização de conteúdos para esta aplicação está relatada nocapítulo 4 através da descrição da Base de Dados. O restante processo, queainda não foi descrito, incide sobre a identificação do utilizador perante osistema e será explicado no capítulo 6.

3.4 Arquitectura 31

Figura 3.4: Menu principal da aplicação Windows

InterfaceOs créditos da pesquisa da técnica utilizada para desenvolvimento da

interface (utilização do expression blend), bem como o desenho da interfaceprincipal vão para o André Passos. O trabalho apresentado no capítulo 6sobre a parte referente ao login desta aplicação usa as técnicas anteriores.

3.4.4 Casa e Trabalho

Esta é a componente da arquitectura referente ao RF07 (ver 3.1.1) quese acabou por valorizar menos. A ideia desta componente consiste naimplementação/reutilização de uma página institucional. Esta página podeinclusivamente ser a página da empresa que queira utilizar esta plataforma.Infelizmente, devido à falta de tempo, ninguém acabou por desenvolveresta componente ficando a mesma para trabalho futuro.


3.5 Conclusão

Neste capítulo ficou descrito a plataforma carFree.ubi. Como é possívelperceber ao longo do capítulo as preocupações foram mais focadas paraa arquitectura em si do que para questões sobre a interface devido aotrabalho desenvolvido. Neste tipo de projectos o trabalho apesar de serindependente não pode ser desconexo. Como tal, uns preocuparam-semais com a interface e outras questões como foi o caso do Joaquim Tojalpara a aplicação PDA e do André Passos para aplicação Windows enquantoo João Oliveira se preocupou com a parte de Inteligência Artificial. Semo trabalho de todos seria impossível chegar onde se chegou. Até aquifoi descrito o trabalho mais teórico realizado no âmbito deste projecto.Enquanto nos capítulos seguintes será descrito todo o trabalho práticodesenvolvido.

Capítulo 4

Servidor

Servidor WindowsTal como foi referido, o servidor é a peça nuclear do sistema. Desde

cedo optou-se por configurar e trabalhar directamente com um servidorWindows existente na sala 6.10. Este servidor não foi instalado de raízpor motivos de licenças, sendo que o sistema operativo de base foi oWindows XP que já se encontrava instalado na máquina. Foi concedidotemporariamente acesso exterior ao porto 80 da máquina uma vez que éaquele com que se trabalha para disponibilização dos Web Services.

ConfiguraçãoO processo de configuração da máquina passou assim pela instalação

do IIS 6.0 e do SQL Server 2005. Para além da instalação foi necessárioproceder a algumas configurações de modo a manter um nível de segu-rança considerado mínimo. Essas configurações passaram por limitar oacesso à Base de Dados e à página dos Web Services1. Para esse efeito foiutilizado uma conta interna na Base de Dados e uma conta do Windowspara o IIS. Mais podia ter sido feito em termos de configurações paratornar o acesso aos Web Services mais seguro (recorrendo ao Web ServicesEnhancements (WSE) por exemplo) mas o projecto consiste em muito maisdo que isto, tendo-se revelado necessário focar a atenção noutras partes doprojecto.

1http://193.136.67.242:50001/Servidor/Service.asmx

33

http://193.136.67.242:50001/Servidor/Service.asmx

34 Servidor

4.1 Base De Dados

Até ao momento ainda não foi especificada a Base de Dados. Todaviaisso vai ser feito nesta secção uma vez que o desenho e implementação damesma integraram-se no trabalho relativo à implementação do servidor.

4.1.1 Diagrama

A Base de Dados possui alguma complexidade como é possível verificar nafigura 4.1. Para uma melhor compreensão optou-se por dividir a descriçãoda Base de Dados por componentes.

Processo de desenvolvimentoO processo de desenvolvimento da Base de Dados não pode ser con-

siderado tradicional uma vez que o diagrama foi directamente desenhadona ferramenta administrativa do MS! (MS!) SQL Server (Microsoft SQLServer Management Studio Express). Assim, não foi desenhado nenhumDiagrama de Entidade-Associaçao (DEA), no entanto é de salientar queestes diagramas são algo equivalentes. A ideia foi desenvolver a Basede Dados de forma pensada e calculada recorrendo directamente a umaferramenta que permitisse posteriormente gerar scripts para criação daBD! (BD!) em MS! SQL Server. Possivelmente até existem outras ferramen-tas com esta potencialidade, mas esta acabou por ser a que se identificoue explorou primeiro. Tendo-se revelado suficiente, para as necessidades eobjectivos pretendidos, não se exploraram outras ferramentas.

VantagensPara além da geração de scripts através do diagrama, outra grande van-

tagem de desenhar o diagrama com recurso a esta ferramenta consisteno facto de que quem desenvolve a Base de Dados se pode abstrair total-mente com a apresentação das tabelas. Isto é, a ferramenta possibilita tantoum escalonamento do diagrama como disposição automática das tabelas.Quem desenvolve só se preocupa com aquilo que realmente interessa queé com as tabelas, os elementos das tabelas, as relações e restrições.

4.1 Base De Dados 35

Figura 4.1: Diagrama da Base de Dados

36 Servidor

EsclarecimentosPara facilitar a descrição do diagrama introduzem-se alguns esclareci-

mentos sobre os símbolos presentes. No interior de cada tabela junto a de-terminados elementos existe um símbolo de chave dourada. Isso significaque os elementos em questão são chave primária da tabela em questão.No caso desta Base Dados os elementos chave podem ser únicos, em paresou triplos. Relativamente às relações entre as tabelas, também surgemdois símbolos distintos. Uma chave dourada e um símbolo infinito quepodem aparecer combinados de múltiplas formas. Sempre que surge umachave numa extremidade e uma chave na outra extremidade, significa quea relação das tabelas é de 1 para 1. Sempre que numa extremidade surgeuma chave e noutra extremidade um infinito, significa que a relação dastabelas é de 1 para N e vice-versa.

4.1.2 Utilizadores

Começando pelo ponto central desta Base de Dados, a tabela Utilizadorpossui cinco relações distintas com outras tabelas que vão ser explicadasmais à frente. O importante nesta tabela é que cada utilizador vai possuirum ID_Utilizador único que o vai identificar, em algumas situações esteID é designado por número de registo de modo a ser mais amigável para outilizador do sistema. Não existe nesta tabela, ou em outra qualquer, umúnico elemento relativo a dados pessoais do utilizador. O sistema, tal comoestá especificado no RNF02, não precisa de conhecer o nome, morada ouqualquer outro dado pessoal do utilizador. No entanto o ID_Utilizadornunca é suficiente para validar a identidade do utilizador tal como ficouespecificado no RNF01, sendo necessário recorrer a uma pass cifrada tam-bém ela presente na tabela.

4.1.3 Grupos

Ainda na tabela Utilizador é possível verificar a existência de um ID_Grupo.Esse ID_Grupo está relacionado com a tabela Grupos, na qual são iden-tificados os grupos de utilizadores reconhecidos pela IA (Tarefa do JoãoOliveira). Assim permite-se que cada utilizador apenas pertença a umgrupo, mas que cada grupo tenha vários utilizadores. De notar também


que, sempre que um Utilizador se regista, o mesmo fica a pertencer a umgrupo de pessoas ditas "indeterminadas".

4.1.4 Interface

Uma das outras relações existentes com o utilizador é a da tabela Interface.Nesta tabela pode verificar-se a relação de 1 para 1, permitindo que um uti-lizador não tenha estado e quando tenha apenas possua um. Isto verifica-seno acto do registo, quando o utilizador nunca recorreu à interface existenteno interior dos transportes públicos e como tal não possui um estado de-terminado. Este estado serve para permitir que os utilizadores tenham umconjunto de configurações de interface ao seu dispor. Esta funcionalidadenão está patente nos requisitos tendo sido acrescentada posteriormente.

4.1.5 Conteúdos

Utilizador_ConteudoOutra das relações feitas com o utilizador tem a ver com os conteúdos

que o mesmo já visualizou. Cada utilizador pode ter visualizado váriosconteúdos e pode inclusivamente ver o mesmo conteúdo em instantesdiferentes. A partir do momento que um conteúdo é aberto insere-se umregisto na tabela Utilizador_Conteudo que vai actualizando o elementoestado até o mesmo sair desse conteúdo. Esse estado refere-se ao estadopropriamente do conteúdo. Se é um livro qual a página aberta, se forum vídeo em que minuto do vídeo se encontra e por ai fora. A partir domomento em que um utilizador sai da aplicação e deixa um conteúdo emaberto o mesmo fica com um estado diferente de zero que posteriormentepode ser recuperado tal como foi especificado no RF04 (ver 3.1.1). Caso umconteúdo seja encerrado para dar lugar à visualização de outro o estado écolocado a 0 não sendo feita mais nenhuma actualização a esse registo.

ConteudoA tabela Conteudo está no centro dos conteúdos como está o utilizador

no centro da Base Dados. Essa tabela possui relações com tabelas de Autor,Genero, Tipo, Editora, sendo estas do mesmo tipo de relação e outra relação

38 Servidor

distinta com a tabela anteriormente vista. Isto faz com que cada conteúdopossa pertencer a vários registos da tabela Utilizador_Conteudo. Como éainda possível constatar pelo diagrama, a tabela Conteudo possui várioselementos que identificam o conteúdo. De notar que a tabela embute oconteúdo em si, não faz nenhuma referência à localização dos conteúdos.Isto torna a Base de Dados mais pesada, mas considerou-se que seria aforma mais correcta de proceder.

Autor, Genero, Tipo, EditoraTodas estas tabelas foram criadas de modo a que cada conteúdo possa

ter um autor, um género, um tipo e uma editora e que cada uma destas car-acterísticas possa estar presente em conteúdos diferentes. Relativamenteao tipo dos conteúdos estes existem para distinguir as músicas dos livros,etc.

4.1.6 Dispositivos

A componente relativa aos dispositivos divide-se em duas tabelas muitosimples. Numa, designada por Dispositivo, adicionam-se os diversosdispositivos registados. Noutra, designada por Utilizador_Dispositivo,estabelece-se a relação entre os utilizadores e os dispositivos. Isto é, estatabela de relação serve para permitir que cada utilizador tenha mais doque um dispositivo. No entanto um utilizador pode não ter um disposi-tivo associado, bem como a determinada altura, um dispositivo pode serdesvinculado de um utilizador para passar a pertencer a outro ou simples-mente deixar de existir. De notar ainda que, um dispositivo fica identifi-cado pelo seu MAC Address cifrado e combinado com a chave pode servirem determinadas situações de identificação do utilizador tal como ficouespecificado no RNF01 (ver 3.1.2) e RNF02 (ver 3.1.2).

4.1.7 Transportes

A componente dos transportes, tal como as restantes, também se rela-ciona com o utilizador tendo como facto de que se pretende saber seum utilizador está presente num transporte ou não. Assim a tabela de


relação Utilizador_Transporte permite que um utilizador esteja num qual-quer transporte ocupando um determinado lugar, como pode não estar emnenhum. De notar ainda que cada transporte possui um tipo, por exemploautocarro, metro, etc., e que cada tipo pode ter vários transportes. Paraalém de um transporte ter um nome, uma matrícula, o número de lugares,o mesmo possui uma latitude e longitude que se quer actualizada à medidaque o transporte se move.

Rotas

Outra parte importante na relação dos transportes é o facto dos mesmosterem horários, isto é rotas. Esta parte é talvez a mais complexa da Base deDados e decidiu-se para simplificar a mesma que cada circuito de um dadotransporte, feito a uma dada hora, consiste numa rota que pode ser feitaem diversos dias. Assim uma rota consiste num conjunto de paragens pelaqual o transporte passa a uma determinada hora prevista. Cada transportepode ter diversas rotas e uma rota pode ser feita por diversos transportes,tendo em consideração que num dia apenas um transporte pode fazeressa rota. No de um transporte fazer um percurso em contínuo durante odia inteiro deve-se partir essa rota de modo a que o transporte não repitanenhuma paragem.

Paragens

As paragens juntam duas situações que se consideram compatíveis pelotipo de dados armazenados na tabela Paragem. Deste modo uma paragempossui um tipo que pode ser de paragem ou estacionamento. Esta paragemdeve ser vista como um ponto de paragem possível para um utilizadordo sistema. Assim sendo, um utilizador pode parar numa paragem deum transporte como pode parar num estacionamento onde deixa o carro.No caso de ser efectivamente uma paragem de um transporte a mesmapossui relações com as rotas dos transportes, no caso de a paragem ser umestacionamento então esta vai possuir um preço.

40 Servidor

4.2 Privacidade e Segurança

Base de DadosComo foi dito anteriormente, o acesso à Base de Dados é limitado a um

determinado utilizador. Qualquer pedido à Base de Dados tem de serfeito com as devidas credenciais. Outro aspecto que já foi referido e que éimportante repetir, tem a ver com o facto de todo e qualquer acesso à Basede Dados nunca ser feito directamente por uma aplicação cliente. Isto evitaque um atacante tenha conhecimento sobre a estrutura da Base de Dados eque sobre efeito de alguma técnica consiga injectar SQL para extrair aindamais informações.

Dados cifradosComo foi possível perceber noutros pontos do relatório existem dados

cifrados na Base de Dados, nomeadamente as passwords dos utilizadorese os MAC Address dos dispositivos. No capítulo 5 faz-se uma descriçãodetalhada de como esses dados são cifrados. De momento o importanteé o motivo para a existência desses dados cifrados. Qualquer pessoaque escute comunicações não cifradas vai conseguir interceptar e tratar osdados passados na comunicação.

Password cifradaSe a password não estiver cifrada basta ao atacante descobrir qual o MAC

Address do utilizador juntamente com a password não cifrada, emular esseMAC Address e assim conseguir identificar-se nos ecrãs tácteis como sendoalguém que não é. O perigo disso é que um atacante pode conseguir semautorização perceber quais são os gostos de uma outra pessoa, coisa quedo ponto de vista dos sistemas ubíquos é totalmente indesejável.

MAC Address cifradoJá o MAC Address é cifrado por um motivo ligeiramente diferente. Hoje

em dia confia-se demasiado nas empresas que possuem a informação, masalguma informação não deve ser totalmente confiada. Do ponto de vistadas redes tanto existem perigos de ataque de pontos externos à rede comode pontos internos. Inclusivamente os internos até são mais perigososdo que os externos. Imaginando que o MAC Address não era cifrado,

4.3 Métodos e Classes 41

qualquer administrador do sistema podia ter acesso à Base de Dados efazer associações entre utilizadores e os seus MAC Address. Cifrando estesdados, um administrador consegue na mesma recolher muita informaçãosobre um determinado utilizador no entanto nunca vai conseguir associaro utilizador a um dispositivo.

IISTal como acontece com a Base de Dados o servidor de Web Services está

limitado a quem tenha as credencias de autenticação. Isto impossibilita queos Web Services desenvolvidos no projecto sejam utilizados por terceirossem a devida autorização. Limita-se com isto, a possibilidade de atacantesdesenvolverem código que invoque os Web Services para extrair informaçãode forma automatizada.

EpílogoA segurança é um tema que despertou interesse e representou mais

um desafio na realização deste projecto, no entanto não é apresentadaaqui nenhuma solução milagrosa. Acredita-se que mais cedo ou maistarde seja possível contornar as barreiras implementadas. Sendo que,considera-se necessário recorrer a uma avaliação externa para apurar atéque ponto as medidas são ou não eficientes. Apesar de tudo as medidasnão foram implementadas em vão, existe uma forte convicção sobre asmesmas terem a sua eficiência, apesar de possivelmente existirem falhasque até ao momento não foram detectadas.

4.3 Métodos e Classes

Em termos de desenvolvimento convêm esclarecer que os métodos apre-sentados de seguida não foram realizados pela sequência apresentada norelatório. Isto é, apesar de o servidor ter uma importância significativa eestar apresentado em primeiro no relatório na verdade os métodos foramdesenvolvidos à medida que se foram tornando necessários.

42 Servidor

Figura 4.2: Diagrama do VS2008 do Servidor

4.3.1 Diagrama do Visual Studio

Na figura 4.2 apresenta-se o diagrama das classes e métodos automati-camente gerado pelo Visual Studio. De notar a presença de uma ClasseIA desenvolvida pelo João Oliveira, como tal não são apresentados nemmétodos nem maiores explicações sobre a mesma. O diagrama só con-templa métodos desenvolvidos na realização deste projecto para evitarqualquer tipo de confusão sobre a autoria dos mesmos. Outros métodosforam usados para o funcionamento de partes de trabalho desenvolvidaspelos restantes elementos, mas os mesmos não se encontram aqui listados.

4.3.2 Classe: Com

Os Web Services são, como referido anteriormente, o que vai transparecerpara fora do servidor. Eles são como uma ponte entre todas as componentesdo servidor e as aplicações cliente, pelo que todos os métodos presentesna classe Com (do tipo Web Service) são do tipo Web Method.


connectO método connect existe no âmbito do projecto para testes. Este método

basicamente estabelece a ligação entre o cliente e o servidor devolvendoum valor booleano, sem receber qualquer tipo de argumentos.

userValEste método recebe um número de registo e uma password cifrada de

modo a devolver um valor booleano indicando se existe ou não um uti-lizador com tal correspondência.

userVal2Semelhante ao método anterior mas desta vez para validar um par difer-

ente. Mais precisamente o MAC Adress já cifrado com uma passwordcifrada.

userLastTravelMétodo responsável por devolver uma string devidamente formatada

correspondente à data em que um determinado utilizador viajou numtransporte público. Há que ter em conta que, para que seja possível saberquando foi a ultima vez que um determinado utente viajou num transporte,implica necessariamente que este tenha interagido com os ecrãs tácteis dosistema. Por outras palavras, o método devolve a data da última interacçãocom o sistema presente no interior dos transportes públicos.

userAddMétodo que permite, recebendo uma password cifrada, adicionar um

novo utilizador ao sistema. O valor devolvido por este método é uminteiro que corresponde ao número de registo do utilizador.

transportationsTypeEste método já difere um pouco dos anteriores uma vez que necessita

de devolver uma lista de dados. O método em si devolve a lista de todosos tipos de transportes. Para isso devolve o resultado em XmlDataDoc-ument. Integrado com o cabeçalho Extensible Markup Language (XML)gerado automaticamente pelo Web Service o que o método faz é preencher

44 Servidor

o XML com os dados de interesse. Esta técnica foi seguida sempre quehouve necessidade de trabalhar com tipos de dados mais sofisticados doque um inteiro, uma string ou um booleano. Isto permite tornar os méto-dos compatíveis com diversas linguagens já que devolvem um XML queconsegue ser lido independentemente da plataforma tal como se pretendiano RNF03 (ver 3.1.2).

stationsListMétodo que devolve em XML todas as paragens de um determinado

tipo de transporte.

contentsTypeMétodo que devolve em XML a lista de todos os tipos de conteúdos

existentes.

contentsDateListMétodo que lista em XML todas as datas de visualização de conteúdos

de um determinado utilizador. De notar que as datas na Base de Dadospossuem horas, minutos e segundos, no entanto o que sai deste métodosão apenas as datas com dia, mês e ano em que o utilizador recorreu aosistema.

transportationsListMétodo que devolve em XML a lista de todos os transportes de um

determinado tipo. Isto é, dado o nome de um tipo de transporte é listadoo nome dos transportes desse mesmo tipo.

userDataEste método recebe o número de registo de um utilizador e devolve em

XML alguns dados sobre esse registo, nomeadamente a data em que outilizador se registou e o grupo a que pertence.


devicesListMétodo responsável por devolver a lista dos dispositivos de um de-

terminado utilizador. De notar que os MAC Address devolvidos estãocifrados, ficando à responsabilidade da aplicação cliente pedir a passwordao utilizador de modo a conseguir decifrar os dados.

friendsInMétodo que dado um número de registo e o nome de um transporte

devolve a lista dos amigos presentes nesse transporte. Relembra-se queos amigos são as pessoas que foram classificadas como sendo do mesmogrupo.

contentsViewedEste método devolve a lista dos conteúdos visualizados por um uti-

lizador num determinado dia e de um dado tipo. Mais uma vez, o métodorecebe o número de registo do utilizador, o nome do tipo e a data devi-damente formatada, sendo que devolve, como nos restantes casos, o XMLcom a lista.

stationsStartMétodo responsável por devolver as possíveis paragens de origem com

ligação a uma paragem de destino. Consegue-se fazer a diferença entreuma paragem de origem ou destino consoante a hora em que está previstoo transporte passar nas mesmas.

stationsEndMétodo semelhante ao anterior, mas desta vez para uma paragem de

origem o método devolve a lista das possíveis paragens de destino.

transportationsList2Método que recebe diversos argumentos de entrada como o nome do

tipo de um transporte, o nome de uma paragem de origem e o nome de umaparagem de destino. Para posteriormente devolver a lista dos possíveistransportes que contemplem os requisitos introduzidos.

46 Servidor

4.3.3 Classe: LigacaoBD

Esta classe é que na verdade implementa todas as chamadas à Base deDados necessárias. Assim optou-se, sempre que necessário, por duplicaros nomes dos métodos da classe Com, para a classe LigacaoBD, de modo aestes serem invocados pelos Web Services. Esta abordagem foi seguida querpor motivos de organização como de estruturação do código desenvolvido.De notar ainda que em cada método é aberta e fechada uma ligação à Basede Dados.

Uma vez que já se sabe, da secção anterior, o que cada método deve fazerapenas basta acrescentar umas ligeiras informações. Nomeadamente, é dereferir que em muitos casos a query a ser processada pela Base de Da-dos gera o XML automaticamente. Isso faz-se adicionando se seguinteinstrução "FOR XML PATH (’Elemento’), root(’Utilizador’)" no fim de cadaquery.

De seguida listam-se todos os métodos que invocaram directamentequery’s à Base de Dados.

• userVal

• userVal2

• userLastTravel

• transportationsType

• stationsList

• contentsType

• contentsDateList

• transportationsList

• userData

• devicesList

4.4 Conclusão 47

Por fim surgem os métodos que necessitaram a criação e utilização deprocedimentos por serem um pouco mais complexos de implementar.

• userAdd

• friendsIn

• contentsViewed

• stationsStart

• stationsEnd

• transportationsList2

4.4 Conclusão

Este capítulo introduziu o trabalho e as preocupações tidas em consider-ação no desenvolvimento do servidor, nomeadamente as preocupações aonível de segurança no armazenamento e na comunicação dos dados. Foitambém apresentada a estrutura quer da Base de Dados como do Servi-dor e por fim a forma como os Web Services ligam todas as componentespresentes no servidor. No capítulo seguinte será descrito o trabalho de-senvolvido na aplicação cliente a correr em Windows Mobile, isto é o clientepara PDA.

Capítulo 5

Cliente Windows Mobile

Tal como foi referido anteriormente esta aplicação possui duas compo-nentes distintas. Numa a aplicação pretende servir de assistente de viagenspara condutores de veículos particulares, para mais informações consultarprojecto 54. Na outra, aqui descrita, a aplicação pretende fornecer infor-mações consideradas pertinentes. No entanto, antes sequer de a aplicaçãoser lançada em modo de funcionamento normal é preciso passar por umprocesso de registo. Tudo isto vai ser descrito neste capítulo com maiordetalhe.

Processo de desenvolvimentoO processo de desenvolvimento foi baseado nos requisitos apresentados

e na documentação produzida de forma informal. Nessa documentaçãoinformal consta, alguns fluxogramas, story boards da interface, cenáriosde interacção e outros apontamentos.

Diagrama do Visual StudioPara efeito informativo apresenta-se na figura 5.1 o diagrama com as

classes e métodos desenvolvidos. Ao contrário do que foi feito com oservidor aqui não se pretende descrever cada um dos métodos uma vezque muitos estão relacionados com acções de botões e questões relativas aoambiente gráfico. A abordagem vai ser mais demonstrativa e explicativaaté porque, ao contrário do servidor, nesta aplicação pode-se recorrer àsimagens da interface.

49

50 Cliente Windows Mobile

Figura 5.1: Diagrama do VS2008 da aplicação Windows Mobile

5.1 Registo/Login 51

5.1 Registo/Login

Começando pelo mais importante tendo em conta que o registo/login daaplicação representa um aspecto bastante ponderado por motivos de se-gurança. Surgiram várias abordagens possíveis para esta tarefa. Todaviaa que acabou por parecer mais eficiente e segura consiste em armazenar eusar o número de registo do utilizador directamente no registo do Windows.

Registo do WindowsInicialmente tinha-se pensado em recorrer a um ficheiro no qual se colo-

caria o número de registo cifrado. Nesse processo o número de registo eracifrado e decifrado derivando a chave de um MAC Address do disposi-tivo. No entanto rapidamente se encontraram falhas a esta implementação.Para começar o ficheiro podia facilmente ser copiado de PDA para PDAbastando a um atacante conhecer e conseguir emular os MAC address.Sem excluir a possibilidade de inadvertidamente o ficheiro poder ser apa-gado. Sendo que decidiu-se usar precisamente o mesmo processo masguardando o número de registo cifrado no próprio registo do Windows.

Vantagens e desvantagensA vantagem de cifrar o número de registo directamente para o registo

do Windows é que o mesmo não se copia nem apaga com tanta facilidade,uma vez que é preciso ter acesso local ao PDA para realizar tal operação.A desvantagem continua a manter-se no facto de este método não impedirque o número de registo seja replicado.

5.1.1 CryptoLib

Para proceder à cifragem e decifragem, quer nesta aplicação como naaplicação que vai ser apresentada no capítulo seguinte, optou-se por criaruma biblioteca criptográfica com métodos para cifrar e decifrar com todaa comodidade. Esta biblioteca foi desenvolvida em FSharp e baseia-se nabiblioteca criptográfica do .NET.


ObjectivoOptou-se por criar uma biblioteca auxiliar porque cada vez que se pre-

tende instanciar algum objecto da classe criptográfica do .NET para cifrarou decifrar é necessário manipular streams entre outras coisas. Com estabiblioteca auxiliar facilita-se todo o processo. Basta instanciar a classe e deseguida chamar o método adequado para cifrar ou decifrar fornecendo-lhe o texto a cifrar ou o array de byte a decifrar, a chave e o InitializationVector (IV) caso necessário. A classe criada possui vários métodos parapermitir cifrar em vários modos recorrendo a duas cifras distintas.

AES-ECBUma das cifras é o Advanced Encryption Standard (AES) em modo

Cipher-block Chaining (CBC) ou Electronic CodeBook (ECB). O modo ECBtem a grande desvantagem de não esconder padrões quando as mensagensa cifrar são grandes. No entanto como aqui não é o caso esse problemanão se verifica. Este modo não requer IV e é utilizado para cifrar e decifraro número de registo do utilizador na aplicação do PDA. De notar aindaque com este modo é utilizado um padding aleatório que faz com que umtexto cifrado várias vezes com a mesma chave só resulte num criptogramaidêntico se o padding aleatório se repetir.

AES-CBCO modo CBC por sua vez permite esconder padrões e requer a utilização

de um IV. Para além de, ao contrário do modo ECB, não necessitar depadding aleatório para cifrar a mesma mensagem com a mesma chavediversas vezes e obter criptogramas distintos. Este modo acaba por sermais seguro que o anterior, no entanto o anterior é bem suficiente emalgumas situações. No caso de cifrar e decifrar o MAC Address, o modoECB já não é assim tão suficiente. Para além do MAC Address originardois blocos, logo a necessidade de esconder padrões, o facto do IV variaré uma mais-valia para esta situação. O modo CBC é assim utilizado paracifrar e decifrar os MAC Address dos dispositivos.

MD5 com SaltApesar da cifra Message-Digest algorithm 5 (MD5) ter sido quebrada há


algum tempo, ela continua a ser viável com algumas alterações, nomeada-mente com a introdução de Salt. O MD5 ao contrário do AES é uma cifraOne-Way, ou seja irreversível, no entanto devido à descoberta de colisõespassou a ser possível explorar o MD5. Inclusivamente é possível encon-trar Rainbow-Tables, tabelas que permitem obter o texto plano através docriptograma, do MD5. No entanto, essas tabelas de nada servem quandoadicionado um salt ao texto a cifrar. Se o salt for fixo ainda existem algu-mas possibilidades de tentar explorar a falha do MD5, mas variando o salto processo torna-se impossível (até ao momento). Deste modo o MD5 éutilizado para cifrar e decifrar as passwords dos utilizadores recorrendo aum salt que varia de utilizador para utilizador. Na verdade o Salt usadoneste caso é mais uma derivação da chave.

5.1.2 Passos do Processo

Arranque da aplicaçãoDito isto pode-se finalmente descrever por completo o processo de reg-

isto/login. Quando a aplicação é executada o primeiro passo consiste emverificar a existência do número de registo do utilizador no registo do Win-dows. Se este existir é feito o processo de arranque do menu principal semsequer se decifrar o número de registo, todavia o login fica virtualmentefeito.

Decifrar o número de registoSempre que a aplicação necessitar do número de registo do utilizador ela

passa a ler o valor cifrado do registo do Windows. Posteriormente decifrao valor lido utilizando a cifra AES em modo ECB com chave derivadade um dos MAC Address do PDA. O MAC Address é escolhido lendosequencialmente as interfaces de rede do dispositivo e extraindo o MACAddress da primeira interface identificada como sendo do tipo Ethernet ouWiFi. De notar que quer a leitura dos MAC Address como a derivaçãode chaves em Compact Framework só é possível graças à utilização dabiblioteca OpenNetCF citada no capítulo 3.

Menu 1No caso do registo do Windows não conter o número de registo do uti-


Figura 5.2: Menu principal da aplicação Windows Mobile

lizador então surge um primeiro menu de boas vindas interrogando outilizador quanto ao seu estado de registo. Se o utilizador já estiver regis-tado segue para um menu de login, se não segue para um menu de registo.

Menu RegistoNo menu de registo é solicitada uma password ao utilizador que deve ser

repetida para confirmação. Se as mesmas forem idênticas e diferentes deuma password vazia então a aplicação cliente cifra a password recorrendoà cifra MD5 com salt derivado da própria password. Essa password éenviada para o Web Service que devolve o número de registo do utilizadorcriado. Esse número é cifrado usando a cifra AES em modo ECB comchave derivada de um MAC Address do dispositivo, tal como foi explicadoanteriormente. Assim que o valor está cifrado o mesmo é adicionado aoregisto e a aplicação é lançada normalmente para o menu principal.

Menu LoginNo menu de login o utilizador tem de fornecer a sua password e o próprio

número de registo. A password é cifrada, pelo processo já explicado, e


Figura 5.3: Menu 1 da aplicação Windows Mobile

Figura 5.4: Menu de login da aplicação Windows Mobile


enviada juntamente com o número de registo para um Web Service. Seexistir uma correspondência então a aplicação cifra o número de registo earmazena-o no registo do Windows, tal como no menu anterior. Assim queesse processo é completado a aplicação inicia normalmente para o menuprincipal.

5.2 Horários

A opção dos horários permite ter acesso à lista dos transportes e dos seushorários tendo em consideração três dados relevantes. O primeiro é o tipode transporte desejado, o segundo é a paragem de origem e o terceiro aparagem de destino. Este menu foi feito de maneira a que inicialmentenão sejam listadas paragens de destino ou de origem. Essas paragens sósão listadas assim que o tipo de transporte é seleccionado.

Primeiro passoApós selecção do tipo de transporte são listadas todas as paragens rela-

cionadas com esse tipo de transporte quer nas paragens de origem comodestino. Assim neste primeiro passo não existe uma distinção entre para-gens de origem ou de destino uma vez que todas as listadas são prováveisparagens de destino ou de origem.

Segundo passoAo seleccionar uma das paragens no destino ou na origem a lista oposta

é actualizada com paragens que tenham a relação pretendida com a selec-cionada. Por exemplo se for seleccionada uma determinada paragem deorigem a aplicação cliente recebe do servidor a lista das possíveis paragensde destino e vice-versa.

Terceiro passoO terceiro, e último passo, consiste em seleccionar a outra paragem. A

aplicação verifica se as listas possuem todas valores seleccionados e passaa listar os horários respectivos tendo em consideração a hora actual. Assimapenas são listados horários a partir da hora actual e nunca horários quejá passaram.

5.3 Amigos 57

Figura 5.5: Menu horários da aplicação Windows Mobile

5.3 Amigos

Na opção dos amigos o utilizador pode consultar a lista dos amigos pre-sentes num determinado transporte. Mais uma vez, primeiro é precisoseleccionar o tipo de transporte após isso a lista dos transportes é actual-izada e basta ao utilizador escolher um dos transportes para saber em quelugares do transporte vão os seus amigos. Isto claro se existirem utentesdentro desse transporte pertencentes ao mesmo grupo que o dono do PDA.

5.4 Histórico

O histórico permite ao utilizador recuperar os nomes de alguns conteú-dos visualizados nas suas interacções com a aplicação a correr no interiordos transportes públicos. O funcionamento do menu é bastante simplesbastando ao utilizador seleccionar qual o tipo de conteúdo que pretendevisualizar e qual a data de utilização para de seguida lhe ser apresentadaa lista com a informação desejada.


Figura 5.6: Menu amigos da aplicação Windows Mobile

Figura 5.7: Menu histórico da aplicação Windows Mobile

5.5 Mobile Info 59

Figura 5.8: Menu Mobile Info da aplicação Windows Mobile

5.5 Mobile Info

Por fim, mas não menos importante, o menu de informação sobre o registodo utilizador. Este menu acaba por ser o único dos menus, exceptuando oregisto/login, que requer a introdução da password. Como foi previamenteexplicado os MAC Address são guardados na Base de Dados de formacifrada. Uma vez que quer o IV como a chave usada, para cifrar e decifrar oMAC Address, são derivadas da password do utilizador torna-se necessáriopedir a mesma. É de realçar o facto da password apenas ser necessáriapara a apresentação da lista dos MAC Address registados. A restanteinformação aparece assim que o menu é aberto, sem qualquer necessidadede introdução da password.

5.6 Conclusão

Este capítulo descreveu o trabalho desenvolvido na aplicação cliente paraWindows Mobile. Nesse trabalho consta a descrição de todo o processo


de registo/login do utilizador aquando de uma primeira utilização da apli-cação, contemplando o RNF01 (ver 3.1.2) e o RNF06 (ver 3.1.2). Bem comoa descrição dos restantes menus seguindo o RF06 (ver 3.1.1). A aplicaçãofoi testada e demonstrou-se estável. Inclusivamente foi possível validar ocorrecto tratamento de diversas excepções. No capítulo seguinte passa-sea descrever a outra aplicação cliente, desta vez para Windows.

Capítulo 6

Cliente Windows

Descreve-se neste capítulo a aplicação a funcionar no interior dos trans-portes públicos. Cada utente tem à sua disposição um ecrã táctil a partirdo qual consegue interagir com a interface da aplicação. Esta foi pensadae desenvolvida tendo em atenção o facto de não existir teclado ou ratoà disposição do utente tal como ficou patente no requisito RNF05 (ver3.1.2). O trabalho realizado foca-se apenas na primeira parte do funciona-mento da aplicação. Isto é, na parte de reconhecimento e autenticação dosutilizadores.

Processo de desenvolvimentoÀ semelhança do que aconteceu com o desenvolvimento da aplicação

para Windows Mobile o trabalho desenvolvido nesta aplicação foi feito combase em documentos informais e nos requisitos. Destaca-se ainda o factode inicialmente não ter sido previsto o desenvolvimento da interface recor-rendo ao Expression Blend como tal até foram desenvolvidas parcialmenteduas versões desta aplicação. Uma baseada em forms do Windows maistradicionais e outra aqui apresentada com uma interface muito mais apela-tiva.

Diagrama do Visual StudioTal como foi feito no capítulo 4 e 5, apresenta-se na figura 6.1 o diagrama

com as classes e métodos desenvolvidos. Como muitos métodos estão

61

62 Cliente Windows

Figura 6.1: Diagrama do VS2008 da aplicaçao Windows

relacionados com acções de botões e questões relativas ao ambiente gráficoos mesmos não vão ser descritos exaustivamente.

6.1 BTLib

Antes de se descrever o menu de login propriamente dito, convêm referira biblioteca que serviu de apoio no processo. A biblioteca baseia-se na APIbluetooth feita em C++do Windows SDK. Acontece que essa API revelou-sebastante instável, além de não permitir chamadas directamente do CSharpusando as funcionalidades do .NET.

MotivaçãoO uso da API e o desenvolvimento de uma biblioteca de apoio foi

6.2 Login 63

necessário por se ter considerado que os utilizadores de dispositivos móveis(PDA, Telemóvel), com bluetooth, deviam utilizar o mesmo como uma es-pécie de chave. Todo o processo de login podia ser feito esquecendo odispositivo. Bastava usar o número de registo juntamente com a passworde o utente entrava no sistema. Mas parte da segurança pretendida perdia-se uma vez que o utilizador deixava de necessitar de um objecto que oidentificasse.

BibliotecaA biblioteca BTLib justifica-se de forma a juntar numa única DLL todo o

código C++ necessário para descoberta de dispositivos bluetooth e recolhados seus MAC Address. Apesar do código desta biblioteca ser diminuto odesenvolvimento do mesmo necessitou algum esforço para ficar funcional.As falhas da API da Microsoft resumem-se à quantidade de problemas quesurgem com ligeiras alterações no código e à fraca documentação existente.Limitando o uso da biblioteca numa DLL em C++, com métodos capazes deserem invocados pela Framework .Net, consegue-se controlar o ambientede funcionamento da API. Esta DLL fica assim facilmente importável paraqualquer projecto do Visual Studio e com duas ou três linhas de códigoconsegue-se fazer a descoberta de dispositivos.

6.2 Login

O menu de login é bastante simples e intuitivo de utilizar. Do ponto devista do utente dos transportes públicos basta que o seu dispositivo tenha obluetooth ligado e visível a todos para que o mesmo seja listado na interface.De seguida só lhe resta seleccionar o nome do seu dispositivo, introduzira password utilizando o teclado virtual e premir o botão entrar.

Actualização de dispositivosDo ponto de vista da aplicação o que na realidade acontece é que a

todo o momento existe uma thread responsável por actualizar a lista dedispositivos encontrados. Sempre que essa pesquisa é terminada a listados dispositivos, que surge na interface, actualiza (ver figura 6.2).

64 Cliente Windows

Figura 6.2: Lista de dispositivos

Teclado VirtualPor sua vez o teclado virtual só é activado quando um utente selecciona

o nome de um dispositivo presente na lista. O teclado permite ao utenteintroduzir a sua password podendo a qualquer momento mudar o mesmode posição ou até fecha-lo. De notar que o teclado volta a ser aberto sefor seleccionado novamente o nome do dispositivo. No entanto se forseleccionado outro nome a password fica vazia.

EntrarAssim que o utente tiver introduzido a sua password só lhe resta premir o

botão para entrar. Nesta fase o MAC Address do dispositivo seleccionadoé cifrado usando a cifra AES em modo CBC e a password cifrada com MD5e salt. Este processo é feito de forma análoga ao descrito para a aplicaçãoWindows Mobile, recorrendo também à biblioteca criptográfica apresentadano capítulo anterior. Por fim os dados são enviados ao servidor que teráa responsabilidade de os validar ou não. Se forem validados o utilizadorpassa a ter acesso ao menu principal, caso contrário a password fica vazia eo utilizador é informado que os dados não estão correctos (ver figura 6.4).

6.2 Login 65

Figura 6.3: Teclado virtual

Figura 6.4: Exemplo de uma autenticação falhada

66 Cliente Windows

Entrar AnónimoExiste ainda a possibilidade de qualquer utente entrar no sistema de

forma anónima, no entanto este modo de utilização é limitado.

SairQuando um utente decide sair da aplicação basta-lhe premir o botão sair

e automaticamente o menu de login é activado. Voltando ao menu de logina password fica vazia para evitar que enquanto o dispositivo se encontre emalcance alguém consiga entrar no sistema usando as credenciais do utenteanterior

6.3 Conclusão

Neste capítulo apresentou-se o trabalho desenvolvido para a aplicaçãoWindows. As duas aplicações cliente combinadas com o servidor represen-tam o ponto forte desta plataforma ubíqua. Todas as aplicações apresen-tadas foram devidamente testadas e estão funcionais como é constatávelpelas imagens. No capítulo seguinte finaliza-se o relatório e apresentam-seas últimas conclusões.

Capítulo 7

Conclusão

Implementação de uma plataforma inovadoraTal como está referido na proposta do projecto, este pretende "implemen-

tar uma plataforma inovadora que permite melhorar a experiência de utilizaçãodo utente de transportes públicos". Resta dizer que o objectivo principal deimplementar tal plataforma ficou cumprido à semelhança dos restantesobjectivos.

Desenho e implementaçãoA parte do projecto que constava realizar de forma independente con-

sistiu em desenhar e implementar a plataforma de comunicação móvel edisponibilização de conteúdos. Por outras palavras, o núcleo da arquitec-tura do carFree.ubi que pode ser consultado no capítulo 3, bem como otrabalho apresentado nos capítulos 4, 5 e 6.

Plano de trabalhoNo plano de trabalho constavam quatro tópicos que foram todos cumpri-

dos. Relativamente à análise de requisitos a mesma pode ser consultada nocapítulo 3, enquanto a definição da estrutura do programa a desenvolverjuntamente com a descrição da implementação e testes estão concentradosnos capítulos 4, 5 e 6. Como é possível constatar pela estrutura do relatórioainda foram feitos alguns estudos teóricos sobre tecnologias e paradigmas.

67

68 Conclusão

DesafioEste projecto representou um desafio muito aliciante devido à necessi-

dade de aplicar um conjunto bastante largo de conhecimentos adquiridosao longo do curso e pela possibilidade de desenvolver outros, como acomputação ubíqua. Sendo este um curso de Engenharia Informática, umprojecto como este é tudo o que qualquer um podia desejar. Para alémdo projecto ter tido uma componente de instalação e configuração de sis-temas, permitiu apurar conhecimentos sobre programação para .NET 3.5,CSharp, FSharp, SQL, ADO .NET, Web Services, Windows PresentationFoundation (WPF), Drawing de interfaces e dispositivos móveis. Contemp-lando parte de matérias de disciplinas como Base de Dados, ProgramaçãoOrientada a Objectos, Sistemas Operativos, Redes, Engenharia de Soft-ware, Interacção Humana Com o Computador, Sistemas Distribuídos, Se-gurança Informática, Compiladores, Organização e Gestão de Empresas eainda Aspectos Profissionais da Informática.

DificuldadesComo em qualquer projecto existiram obviamente muitas dificuldades

na implementação da plataforma idealizada. Neste momento é difícilenumera-las todas, no entanto destaca-se o facto de o projecto ter umperíodo de desenvolvimento curto (cerca de quatro meses com relatório).Algumas opções tiveram de ser tomadas rapidamente e nem sempre foifeita a devida ponderação. O importante é que todas as dificuldades foramsuperadas. Desde a questão de lidar com dispositivos bluetooth usandouma API pouco estável, passando pelas falhas de segurança detectadas ecorrigidas ao longo da implementação. Como pela necessidade de lidarcom tecnologias com as quais apenas se está familiarizado de nome e àsvezes nem isso. Por fim é preciso não esquecer que a disciplina de projectoteve de ser combinada com outras disciplinas, o que limitou um pouco oespaço evolutivo da plataforma.

7.1 Resultados

Participação na final nacional do Imagine CUP 2008O resultado mais evidente da realização deste projecto é a própria

plataforma. Em segundo plano fica a participação e apuramento para

7.2 Trabalho Futuro 69

a final nacional do Imagine CUP em representação da Universidade daBeira Interior (UBI). A final deste concurso decorreu em Lisboa na Cul-turgest dia 20 de Maio de 2008. O processo de selecção das equipas queforam apuradas para a final nacional teve duas etapas que apuraram seteequipas participantes.

Enriquecimento PessoalTal como se pretendia foi possível melhorar conhecimentos sobre as difi-

culdades reais no desenvolvimento de aplicações ubíquas. A organizaçãoe divisão de tarefas pelo grupo de trabalho referido no primeiro capítulotambém se revelaram interessantes. A interacção e coordenação no desen-volvimento da plataforma foram uma mais-valia como experiência. Bemcomo os conhecimentos adquiridos e expostos ao longo do relatório. Semesquecer o que ficou por dizer como as horas passadas na Universidade,quer de noite como alguns fins-de-semana, a trabalhar para o desenvolvi-mento da plataforma. Bem como a ida a Lisboa, o nervosismo de enfrentarjornalistas e um júri constituído por elementos de prestígio nas mais di-versificadas áreas.

7.2 Trabalho Futuro

Apesar de o carFree.ubi estar funcional, o mesmo não está totalmente con-cluído. Como trabalho futuro fica a necessidade de construir uma aplicaçãoou página web de administração da base de dados do sistema. Uma vezque o objectivo era ter a plataforma funcional os dados de teste foram in-troduzidos por intermédio de scripts. Outra funcionalidade que fica comotrabalho futuro é o desenvolvimento de uma página Web para divulgaçãoe download da aplicação, isto no caso de o carFree.ubi conseguir cativaralguém da área dos transportes. Ficam ainda sugestões de expansão daplataforma a redes de marketing que possam dirigir as suas publicidadesa cada utilizador de forma moderada e controlada pelo mesmo. Isto como objectivo de potenciar a baixa de preço dos transportes aproveitandoas receitas geradas pela rede de publicidade. Como última sugestão ficatambém a introdução de uma ferramenta de detecção de roubos de dis-positivos. Uma vez que cada dispositivo de um utilizador fica registadono sistema pelo seu MAC Address cifrado com a password do utilizador.

70 Conclusão

Torna-se possível, caso o mesmo solicite, alterar o MAC cifrado para possi-bilitar que este seja detectado pelo sistema e assim se tenha conhecimentoda posição do mesmo.

Bibliografia

[1] Central Intelligence Agency. Appendix B - International Organizationsand Groups, 6 2008. https://www.cia.gov/library/publications/the-world-factbook/appendix/appendix-b.html.

[2] American Public Transportation Association. Annual study shows trafficcongestion worsening in cities large and small, 3 2008. http://www.publictransportation.org/resources/2207_tti_report.asp.

[3] Palo Alto Research Center. In memory of Dr. Mark Weiser, 3 2008.http://www2.parc.com/csl/members/weiser/.

[4] Guanling Chen and David Kotz. A Survey of Context-Aware MobileComputing Research, 2000.

[5] Stefano Russo Domenico Cotroneo, Almerindo Graziano. SecurityRequirements in Service Oriented Architectures for Ubiquitous Computing,2004.

[6] Yang Li and James A. Landay. Exploring Activity-Based UbiquitousComputing: Interaction Styles, Models and Tool Support, 2006.

[7] Switzerland LIFT07 conference in Geneva. Everyware: Further downthe rabbit hole, 3 2008. http://light.vpod.tv/?s=0.0.133764.

[8] Francisco Javier Arias Moreno. An approach of wearable computing,2006.

[9] Helder Pinto and Rui José. Activity-centered ubiquitous computing sup-port to localized activities, 2005.

71

https://www.cia.gov/library/publications/the-world-factbook/appendix/appendix-b.html

https://www.cia.gov/library/publications/the-world-factbook/appendix/appendix-b.html

http://www.publictransportation.org/resources/2207_tti_report.asp

http://www.publictransportation.org/resources/2207_tti_report.asp

http://www2.parc.com/csl/members/weiser/

http://light.vpod.tv/?s=0.0.133764

72 BIBLIOGRAFIA

[10] Studies and Observations. About the Author | Everyware: Thedawning age of ubiquitous computing, 3 2008. http://www.studies-observations.com/everyware/about_the_author.html.

[11] Mark Weiser. The Computer for the Twenty-First Century, 1991.

[12] Mark Weiser. Hot Topics: Ubiquitous Computing, 1993.

[13] Mark Weiser. Some Computer Science Problems in Ubiquitous Computing,1993.

[14] Mark Weiser. The world is not a desktop, 1994.

http://www.studies-observations.com/everyware/about_the_author.html

http://www.studies-observations.com/everyware/about_the_author.html

Education

Relatório de Projecto de Licenciatura