Relatório Projecto Licenciatura

8/4/2019 Relatrio Projecto Licenciatura

1/84

Departamento de Informtica

da Universidade da Beira Interior

carFree.ubi

Computao ubqua ao servio dos transportes pblicos

Joel Silva Carvalho

Orientador do Projecto:

Prof. Doutor Simo Melo de Sousa

Covilh, Junho de 2008


2/84


3/84

Agradecimentos

A todos os que contriburam de alguma forma para este projecto, aqui ficao meu forte agradecimento.

No vale a pena citar nomes, porque foram muitas as pessoas que derama sua contribuio por mnima que tenha sido.Obrigado a todos!

i


4/84


5/84

Contedo

Agradecimentos i

Contedo iii

Lista de Figuras vii

Acrnimos ix

1 Introduo 1

1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 carFree.ubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Organizao do relatrio . . . . . . . . . . . . . . . . . . . . . 8

2 Estado de Arte 11

2.1 Discusso existente . . . . . . . . . . . . . . . . . . . . . . . . 13

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

2.3 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Plataforma carFree.ubi 17

3.1 Anlise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 18

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

iii


6/84

iv CONTEDO

3.1.2 Requisitos no funcionais . . . . . . . . . . . . . . . . 20

3.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.1 Ecrs tcteis . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 PDAcom ou semGPS . . . . . . . . . . . . . . . . . . 22

3.2.3 Telemvel . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

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

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

3.4.2 Mvel e Carro . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.3 Transportes Pblicos . . . . . . . . . . . . . . . . . . . 30

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

3.5 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Contedos . . . . . . . . . . . . . . . . . . . . . . . . . 37

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

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

4.2 Privacidade e Segurana . . . . . . . . . . . . . . . . . . . . . 40

4.3 Mtodos e Classes. . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.1 Diagrama do Visual Studio . . . . . . . . . . . . . . . 424.3.2 Classe: Com . . . . . . . . . . . . . . . . . . . . . . . . 43

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

4.4 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


7/84

CONTEDO v

5 Cliente Windows Mobile 49

5.1 Registo/Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.1 CryptoLib . . . . . . . . . . . . . . . . . . . . . . . . . 51

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

5.2 Horrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

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

5.4 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

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

5.6 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 Cliente Windows 61

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

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

6.3 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7 Concluso 69

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

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

Bibliografia 73


8/84


9/84

Lista de Figuras

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

3.2 Web Services Description Language (WSDL) do Servidor . . 273.3 Menu principal da aplicao PDA . . . . . . . . . . . . . . . 30

3.4 Menu principal da aplicao Windows. . . . . . . . . . . . . 31

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

4.2 Diagrama doVS2008do Servidor . . . . . . . . . . . . . . . . 42

5.1 Diagrama doVS2008da aplicao Windows Mobile . . . . . 50

5.2 Menu principal da aplicao Windows Mobile . . . . . . . . 53

5.3 Menu 1 da aplicao Windows Mobile . . . . . . . . . . . . . 54

5.4 Menu de login da aplicao Windows Mobile . . . . . . . . . 55

5.5 Menu horrios da aplicao Windows Mobile. . . . . . . . . 56

5.6 Menu amigos da aplicao Windows Mobile . . . . . . . . . 57

5.7 Menu histrico da aplicao Windows Mobile . . . . . . . . 58

5.8 Menu Mobile Info da aplicao Windows Mobile. . . . . . . 59

6.1 Diagrama doVS2008da aplicaao Windows . . . . . . . . . 62

6.2 Lista de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 646.3 Teclado virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.4 Exemplo de uma autenticao falhada . . . . . . . . . . . . . 66

vii


10/84


11/84

Acrnimos

DS Desenvolvimento Sustentvel

SI Sistema de InformaoGPS Global Positioning System

VS2008 Visual Studio 2008

DEA Diagrama de Entidade-Associaao

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


12/84

x Acrnimos

HTTPS HyperText Transfer Protocol Secure

FTP File Transfer Protocol

SMTP Simple Mail Transfer Protocol

NMTP Negotiable Mail Transfer Protocol

GUI Graphical User Interface

IA Inteligncia 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 StandardCBC Cipher-block Chaining

ECB Electronic CodeBook

MD5 Message-Digest algorithm 5


13/84

Captulo 1

Introduo

Objectivo do documentoEste relatrio descreve detalhadamente o trabalho desenvolvido para a

disciplina de Projecto do curso de Engenharia Informtica na Universidadeda Beira Interior. O documento condensa um conjunto de conhecimentosadquiridos e justifica as abordagens seguidas na sua implementao.

Objectivo do projectoAo longo do percurso acadmico pretende-se que o aluno adquira di-

versas competncias que se reflectem no desenvolvimento de um projecto sua escolha. Escolha esta que foi previamente construda e desenvolvidaem colaborao com o Professor orientador, culminando no objectivo deconstruir uma plataforma inovadora que permitisse melhorar a experin-cia de utilizao do utente de transportes pblicos. Este projecto nasceuda combinao de inmeros factores e resultou na participao da finalnacional do concurso da Microsoft (Imagine CUP1) que tinha por tema:"Imagina um mundo onde a tecnologia possibilita um ambiente sustentvel"2.

Aprendizagem complementarPara alm deste projecto representar um grande desafio na construode 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.mspxhttp://imaginecup.com/PT/SD.aspxhttp://imaginecup.com/PT/SD.aspxhttp://www.microsoft.com/portugal/imaginecup/vencedoresnacionais.mspx


14/84

2 Introduo

surgiu tambm no seguimento da vontade de estudar sistemas ubquos

(ver captulo2). Este tipo de sistemas, apesar de ter uma importnciacrescente, no abordado no plano curricular actual do curso. O quepor si tambm foi factor decisivo na escolha do projecto e do orientador.A vontade de enriquecer e complementar o conhecimento adquirido insacivel.

EquipaDada a exigncia do desenvolvimento de raz de uma arquitectura to

vasta, considerou-se fundamental construir uma equipa capaz de desen-volver um trabalho com impacto suficiente para uma participao na final

nacional do Imagine CUP. A equipa que se passou a designar por Ubiquistaficou constituda pelos seguintes elementos: Andr Passos, Joaquim Tojal,Joo Oliveira e Joel Carvalho. Cada qual com um conjunto de respons-abilidades e tarefas especficas (ver1.2) providenciando independncia notrabalho. Sendo dois destes alunos do projecto ImagineCup@ubi (JoaquimTojal e Joel Carvalho) ficou-lhes atribudo maior quota de trabalho no pro-

jecto global.

1.1 Motivao

Computao UbquaEste projecto tem uma origem um quanto peculiar comparativamente

aos restantes. Da curiosidade e vontade de estudar a computao ubquaconciliada 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 captulo2). Desenvolver uma arquitecturaque pretende integrar diversos tipos de dispositivos conciliando diversasformas de utilizao no algo trivial nem pode ser descurado. A pri-vacidade dos dados tem de ser garantida e o sistema deve adaptar-se aoutilizador, nunca o contrrio.

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


15/84

1.1 Motivao 3

imento pessoal dos alunos, em detrimento de produo cientfica (mais

adequada para Mestrado), torna-se evidente que a participao num con-curso uma mais-valia. OImagine CUP para alm de ser um desafio umajanela de oportunidade, quer para promoo pessoal como institucional.Sendo que desde cedo oImagine CUPfez sentido, especialmente quandoa temtica do concurso deste ano foca um assunto que nos preocupa atodos. Est-se claro a falar do ambiente numa vertente em que no sepretendem posies extremistas mas sim pensadas no DesenvolvimentoSustentvel (DS).

SIs ao servio do ambienteO desafio de produzir um Sistema de Informao (SI) capaz de con-

tribuir para o ambiente foi uma motivao extra. Mas no foi fcil escolheruma ideia a desenvolver que fosse suficientemente boa e inovadora. In-clusivamente no processo de seleco de ideias foram descartadas umaquantidade substancial delas j que o objectivo da participao no con-curso era conseguir-se pelo menos um apuramento para a final nacional.O problema dos SIsqueestesnosodetodoamaneiramaisintuitivadecolaborar para um melhor ambiente. Mais facilmente se pensa em sistemas

electromecnicos, electrotcnicos e energticos para melhorar o ambientedo que emSIs.

Ideias abandonadasNas ideias que ficaram para trs destacam-se algumas que at so de

algum interesse, no entanto foram consideradas como insuficientes ou de-masiado bvias. Nomeadamente um sistema ubquo de apoio ao consum-idor. A ideia deste sistema consistia em classificar os produtos alimentares

disponveis nos supermercados como sendo mais ou menos ecolgicostendo em conta a sua origem e outras informaes. Outra ideia passavapela implementao de um sistema ubquo de informao e sensibiliza-o ambiental, no qual se pretendia criar rotas verdes e desviar trfego dezonas com nveis de poluio elevados.


16/84

4 Introduo

1.2 carFree.ubi

Descrio 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 pblicos em detrimento dostransportes particulares recorrendo a diversas tecnologias presentes noquotidiano. Apesar de actualmente ser na verdade mais confortvel uti-lizar o veculo particular, isso no quer dizer que os transportes pblicosno possam superaresse conforto. O carFree.ubi pretende at contribuir namelhoria desse conforto fornecendo, ao utilizador de transportes pblicos,

contedos multimdia exclusivos no interior do prprio transporte. Isso feito recorrendo a uma aplicao a correr em cada ecr tctil instaladopor todos os lugares. O carFree.ubi pretende tambm facilitar a escolhado transporte mais rpido ou econmico com base numa aplicao emWindows Mobileque serve de extenso do sistema de Global PositioningSystem (GPS) e que fornece informaes em tempo real sobre a rede detransportes pblicos. Pretende-se com isto agitar e alterar a forma comoos transportes pblicos so vistos e utilizados. O tempo dispensado nasviagens quer-se produtivo e enriquecedor, coisa que actualmente no seconsegue na plenitude recorrendo ao transporte particular. providenci-ada uma descrio mais detalhada, sobre como o carFree.ubi faz isso tudo,

no captulo3e seguintes.

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

problemas ambientais e perceber qual a abordagem doDS. Dos diversosproblemas existentes foi interessante constatar que a utilizao massivados transportes pblicos tem vrias consequncias ambientais, sociais eeconmicas. Sabendo que oDS construdo sobre estes trs pilares inter-dependentes e mutuamente sustentadores tornou-se evidente que umasoluo como o carFree.ubi j devia existir h mais tempo. Como prova

disso interessante constatar como recentemente a questo do preo doscombustveis veio abanar os transportes. Um estudo americano[2] feito pouco mais de seis meses veio revelar, para alm do impacto directoda poluio, dados impressionantes. Por exemplo foi divulgado que ocusto provocado pelos congestionamentos das metrpoles, apenas nos


17/84

1.2 carFree.ubi 5

Estados Unidos, era avaliado em 78 mil milhes de dlares. Valor que

corresponde a 4.2 mil milhes de horas perdidas e 10.97 mil milhes delitros de combustvel perdido.

VantagensPara alm de tudo o que j se possa imaginar pela argumentao feita

at ao momento. A vantagem do carFree.ubi em instrumentalizar umaferramenta que pode apoiar medidas polticas para a limitao da utiliza-o dos transportes particulares no interior dos centros urbanos tambmuma mais-valia incontestvel. Ao contrrio do que foi feito noutras reas importante melhorar as solues existentes antes de tomar medidas mais

duras. Mas a verdade incontornvel, se o crescimento dos transportesparticulares continuar a aumentar, mesmo que estes no sejam poluentes,vai chegar-se a um ponto de saturao em que ningumvai fazerdistanciascurtas em tempos considerados decentes. Muitas cidades europeias j pos-suem os centros urbanos cortados a trnsito rodovirio excepto transportespblicos e abastecimento de comrcios. Essa realidade vai fazer parte dofuturo de todas as cidades e os transportes pblicos vo ter que se adaptarde modo a servir as necessidades dos utentes. O carFree.ubi enquadra-seperfeitamente numa soluo que consegue suportar melhor essa neces-sidade, para mais informaes pode consultar documentos referidos na

seco contributo.

DificuldadesUma das questes 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 inutilizvelem caso de saturao dos transportes pblicos. Como s existem ecrstcteis nos assentos, quem fica de p no tem acesso ao sistema. A ideiado carFree.ubi de um sistema adaptado s necessidades dos utentes,promovendo qualidade de vida e melhorando a experincia de utilizao

dos transportes pblicos. Um caso de saturao de transporte pblico,para alm de comportar uma situao ilegal, a anttese da plataformacarFree.ubi. Qualquer rede de transportes pblicos que trabalhe para o

benefcio dos utentes e queira um sistema como este, de certeza que novaiaceitar que os seustransportes estejamconstantemente sobre saturao.


18/84

6 Introduo

Os transportes pblicos, para alm de terem a obrigao de se adaptar s

necessidades dos utentes, devem servi-los com a mxima qualidade. Seas transportadoras e os governos querem resolver o problema dos con-gestionamentos nos grandes centros urbanos s existe uma soluo! Nopermitir o transito de veculos particulares no centro das cidades. Por con-seguinte torna-se necessrio aumentar a frota de transportes e melhorar oincentivo da utilizao dos mesmos. Deciso esta que pode ser sustentadacom a plataforma carFree.ubi.

Diviso 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 captulo 3, mas em forma de breve antevisoapresenta-se desde j a diviso do trabalho.

Andr Passos - Responsvel pelo desenho da interface da aplicaocliente emWindows.

Joaquim Tojal - Responsvel por:

Desenho da interface da aplicao cliente em Windows Mobile.

Desenvolvimento da parte relativa extenso do sistemaGPS.

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 doshorrios que ele pretenda cumprir. Para mais informaes con-sultar relatrio nmero 54.

Joo Oliveira - Responsvel pela componentede intelignciaartificial.

Joel Carvalho - Responsvel por:

Desenho da arquitectura do sistema e da base de dados, bemcomo a forma como a comunicao entre os clientes e servidor feita.

Definio das polticas de segurana e privacidade, incluindo omodo como os utilizadores so identificados pelo sistema,


19/84

1.3 Contributo 7

Desenvolvimento da aplicao servidor.

Desenvolvimento de parte da aplicao cliente do Windowsnoque respeitou ologin.

Desenvolvimento de parte da aplicao Windows Mobileno querespeitou o registo do utilizador no sistema e configurao deprimeira utilizao da aplicao Mobilebem como desenvolvi-mento de algumas opes como a consulta de horrios, 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 execuo, todo o trabalho foi feito de raiz e oresultado possui potencialidades futuras que no podem ser ignoradas.Esta plataforma colmata necessidades existentes nos centros urbanos que

j possuem uma boa rede de transportes pblicos.

BTLibPara alm 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 criao e utilizao de uma biblioteca .NET (desenvolvidaem C++) capaz de descobrir dispositivos como Telemveis e PersonalDigital Assistant (PDA)s atravs 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 sensvel a algumas manipulaes (ver captulo6).Esta biblioteca ficou designada por BTLib e encontra-se em processo deavaliao para publicaao na SourceForge3.

CryptoLibA outra biblioteca surgiu da necessidade de facilitar a utilizao da

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


20/84

8 Introduo

API criptogrfica da Framework .NET, no sentido que a mesma revela-se

necessria para algumas partes fundamentais do projecto e considerou-semais til desenvolver esta biblioteca de forma a ser totalmente reutilizvelquer pela aplicaoWindowscomoWindows 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 avaliaopara publicaao na SourceForge4.

DocumentosAinda foi necessrio realizar e apresentar alguns documentos5 no m-

bito do concurso que se decidiu publicar quer para futuros alunos quepretendam participar no Imagine CUPcomo tambm para divulgao doprojecto. Existem tambm referncias feitas na pgina oficial da Microsoft6

com alguma informao sobre o projecto.

1.4 Organizao do relatrio

Este relatrio divide-se em captulos. No primeiro captulo optou-se por

fazer uma breve introduo ao projecto.

Cap2- Estado de ArteNosegundocaptulosointroduzidososprincpioseafilosofiaagregada

ao sistema desenvolvido.

Cap3- Plataforma carFree.ubiNo terceiro captulo descreve-se a plataforma carFree.ubi bem como a

anlise 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.mspxhttp://www.microsoft.com/portugal/presspass/press/2008/mai08/05-21imaginecup2008.mspxhttp://www.microsoft.com/portugal/presspass/press/2008/mai08/05-21imaginecup2008.mspxhttp://www.microsoft.com/portugal/presspass/press/2008/mai08/05-21imaginecup2008.mspxhttp://skydrive.live.com/http://sourceforge.net/projects/cryptolib/


21/84

1.4 Organizao do relatrio 9

Cap4- Servidor

No quarto captulo aborda-se de forma mais detalhada o trabalho de-senvolvido no Servidor onde se inclui a descrio da Base de Dados daplataforma.

Cap5- Cliente Windows MobileNo quinto captulo apresenta-se e descreve-se a aplicao cliente para

Windows Mobilebem como uma biblioteca criptogrfica desenvolvida.

Cap6- Cliente WindowsNo sexto captulo descreve-se o trabalho desenvolvido no cliente Win-

dowsque funciona no interior dos transportes pblicos e uma bibliotecapara descoberta de dispositivos bluetooth.

Cap7- ConclusoNo ltimo captulo fazem-se as ltimas concluses e finaliza-se o re-

latrio.


22/84


23/84

Captulo 2

Estado de Arte

Dispositivos computacionaisA proliferaomassiva de dispositivos comcapacidades computacionais

tem-se alargado um pouco por todas as reas. Os computadores j no soapenas peas de Hardwarevolumosas de ter em casa junto da secretria.Qualquer cidado de um pas dito desenvolvido segundo padres con-sumistas (Developed Countries (DC)[1]) possu pelo menos um disposi-tivo com capacidades computacionais. Esses dispositivos so actualmentemuito diversificados desdePDAs, Telemveis, Smart Cards, Radio Fre-

quency Identification (RFID)s, entre muitos outros.

Princpios 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 computaoubqua[3], publicou em 1991 e 1993 alguns documentos com citaesinspiradoras[14][12][13][11]. Dessesdocumentosdestacam-secitaes 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


24/84

12 Estado de Arte

network that ties them all together, and software systems implementing

ubiquitous applications."[11]

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

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

TecnologiaPassado uma dcada Mark Weiser comea a ganhar uma importncia

fundamental. Afinal a sua viso dos computadores estarem em todo olado e comunicarem essencialmente por redes sem fios tornou-se uma re-alidade. Como exemplo basta pegar nos PDAs. Estes so hoje uma junodos descritos, na ltima citao de Mark Weiser, no entanto com a inte-grao de capacidades atribudas aos telefones mveis mais tradicionais ecom a grande vantagem de terem acesso a redes sem fios. O PDA queMarkWeiser refere em 1993 bem diferente doPDAactual. O actual est incriv-elmente mais prximo da viso de sistemas ubquos do que muitos outros

dispositivos, 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 populaes de forma in-visvel, vai dar-se quando se perder a conscincia completa da tecnologiaque se utiliza e se focar meramente na tarefa. Pode imaginar-se que otalPDAsofre mais uma evoluo e passa a fazer parte dos culos quemuitas pessoas usam. As pessoas precisam dos culos para corrigir umadificuldade visual, mas porque no dar-lhe uma funcionalidade extra?

Continuando a ficcionar, imagine-se que os mesmos recebem instruesvocais que processam e executam aces. Essas aces podem ter um out-put visual, numa parte da lente dos culos, e um ouput sonoro, produzidopor vibraes transmitidas pela armao fazendo chegar o som ao ouvidosem que ningum se aperceba.


25/84

2.1 Discusso existente 13

Computao Ubqua

No entanto os sistemas ubquos precisam de software, sem ele os dis-positivos no passam de meros objectos com funcionalidades prximas deuma pedra. No basta ter as tecnologias, preciso integrar as mesmas efazer com que elas realmente sirvam a populao. A computao ubquadefendida por Mark Weiser tem um papel importantssimo no desenvolvi-mento futuro de aplicaes. J chega de desenvolver aplicaes e sistemassem pensar nas consequncias. preciso defender os interesses e direitosdos utilizadores de modo a que estes realmente gostem, queiram e tenhamproveito na utilizao das tecnologias sem sequer pensarem nelas. Cadavez mais a privacidade das pessoas invadida, todos os dias existem mil-hares de cmaras a vigiar as cidades. Todos os dias deixamos rastos do

que fazemos, quando fazemos, como fazemos s falta registas o porqu.Mas afinal porque que os sistemas no evoluem de modo a salvaguardara privacidade das pessoas?

ParadigmasA grande dificuldade actual encontrada no desenvolvimento de com-

putao ubqua , precisamente, como pratic-la correctamente e com baseem que paradigma. Ainda no se pode dizer que exista um modelo rgidoque defina como e quando se deve praticar computao ubqua. Istoporque derivaram da computao ubqua diversos paradigmas, nomeada-

mente o Wearable Computing[8], o Activity-Based Centered UbiquitousComputing[6], ou ainda o Context Aware Mobile Computing[4].

2.1 Discusso existente

Adam Greenfield[10] um escritor reconhecido a nvel internacional e uma das pessoas que mais tem participado activamente para um de-

bate aberto sobre a computao ubqua. J publicou um livro intitulado:"Everyware: The dawning age of ubiquitous computing". Algumas das suas

palestras[7] para alm de apresentarem a temtica, abordam uma serie depreocupaes 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 vo ser apresentados deseguida.


26/84

14 Estado de Arte

Inadvertncia

Um deles a inadvertncia dos utilizadores. Imaginando um sistemaubquo que permite difundir a localizao do utilizador para um conjuntolimitado de pessoas ou para todas as pessoas. O facto do utilizador poderenganar-se num boto, e em vez de divulgar a sua posio 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 considerao o desconhecimento, por parte dos

utilizadores, do sistema. Eles podem no saber da existncia do mesmo oupodem no conhecer todas as suas funcionalidades. Consequentementeno sabem que informaes o sistema recolhe, o que feito com essasinformaes ou at mesmo quem as guarda e com que objectivo. Apesarde isso ter um lado positivo, porque torna-se invisvel para o utilizador,no 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 so recolhidos das suas interaces.

Rejeio

Segundo Adam Greenfield, este o tema mais controverso. O facto deuma pessoa rejeitar a utilizao de um sistema, seja por qual motivo for,deve ser um direito inquestionvel. Ningum deve ser obrigado a utilizaralgo que no quer. No entanto nem sempre se aceita esta premissa nodesenvolvimento de sistemas ubquos. Muitas vezes parte-se do princpioerrado de que todos vo aceitar e querer utilizar o sistema. Existem muitosexemplos de sistemas que no so propriamente ubquos mas obrigam outilizador a aceitar algo que pode no querer. As cmaras de vigilncia soum exemplo disso. No entanto se for evitvel repetir erros actuais deve-seevoluir para solues que garantam a privacidade das pessoas, j que um direito constitucional.

EplogoO importante a reter actualmente precisamente o perigo quepode advir

de um sistema ubquo pouco pensado. A discusso sobre o tema contnua


27/84

2.2 Framework adoptada 15

em aberto e o seu sucesso depende do que as equipas de desenvolvimento

decidirem considerar como proveitoso. De notar que como qualquer tipode sistema a computao ubqua s consegue ter o seu sucesso se for cen-trada nas pessoas. Quer no que elas precisamcomo nas suas preocupaes.Como exemplo a seguir, se um sistema ubquo regista alguns dados de in-teraco do utilizador o ideal ser nunca saber ao certo quem o utilizador(ver captulo3).

2.2 Framework adoptada

Framework .NETA computao ubqua, dada a sua natureza, permanece em desenvolvi-mento contnuo. Existem no meio acadmico 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 oconcursoImagine CUPassim o exigia.

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

Service Oriented Architecture (SOA)[5]. Este paradigma tem a particulari-dade de permitir a utilizao deWeb Servicesem .NET tal como era exigidopara efeitos de concurso e possibilita o desenvolvimento de um sistemaque no fica dependente da Framework. Simultaneamente oSOApotenciao desenvolvimento de aplicaes com base na computao ubqua.

2.3 Concluso

Este captulo introduziu o contexto da plataforma ubqua que vai passar

a ser descrita no captulo seguinte. Para alm do estudo terico apresen-tado, muitas das ideias presentes neste captulo vo servir de suporte paraescolhas tomadas no desenvolvimento do carFree.ubi.


28/84


29/84

Captulo 3

Plataforma carFree.ubi

ObjectivoO carFree.ubi consiste numa plataforma ubqua que interliga uma srie

de dispositivos e tecnologias de modo a fornecer ao utente de transportespblicos informaes e servios considerados teis em qualquer lugar.Tal como foi referido, o objectivo principal do carFree.ubi incentivara utilizao dos transportes pblicos recorrendo a tecnologias utilizadasmassivamente nos dias correntes.

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

comum a muitos sistemas distribudos. Nesta arquitectura incluem-se trstipos de clientes distintos. Um dos tipos de clientes uma aplicao paraWindows Mobile que para alm de possibilitar a consulta de horrios eoutras informaes em tempo real, tambm um autntico assistente deviagens para transportes pblicos. Outro cliente uma aplicaoWindows

que funciona com ecrs tcteis e que permite a consulta de contedosmultimdia exclusivos. O ltimo cliente simplesmente uma pginaWebinstitucional, isto , pode ser simplesmente a pgina Webda empresa quegere os transportes pblicos. Esta arquitectura descrita commaior detalhena seco3.4.

17


30/84

18 Plataforma carFree.ubi

3.1 Anlise de Requisitos

Antesdesepassaraumamaiordescriodaplataformaemsi,apresenta-sea anlise de requisitos feita. Esta anlise foi realizada avaliando informal-mente as necessidades de um conjunto de pessoas de confiana. Destaforma foi possvel perceber em que medida um sistema ubquo podia cor-responder s suas necessidades mantendo uma certa descrio em todaa fase de desenvolvimento. Esta descrio foi necessria uma vez quese pretendia chegar aoImagine CUPcom uma ideia totalmente distinta eoriginal.

3.1.1 Requisitos funcionais

RF01 - Contedos multimdiaAlgo que ficou imediatamente identificado foi a necessidade de tornar

o tempo dispendido dentro dos transportes pblicos de maior qualidadee utilidade. Numa sociedade em constante evoluo os transportes, inde-pendentemente do tipo, possuem uma importncia crescente. Pensando eolhando para os utilizadores de transportes pblicos actuais, constata-sefacilmente que alguns tentam passar esse tempo ocupando-se. Algunslem jornais, outros jogam no telemvel, outros telefonam ou falam com

amigos, etc. claro que existe sempre quem dedique o tempo da viagema fazer uma reflexo interna e no queira outra soluo. O requisito queaqui fica identificado a necessidade do sistema possibilitar (e no obri-gar) aos utentes a consulta de contedos multimdia dentro dos prpriostransportes.

RF02 - Assistente de viagensOutra questo pertinente e que rapidamente se fez transparecer foi a ne-

cessidade de melhorar o conforto e a comodidade dos transportes pblicos.Isto porque, estes dois factores so responsveis por muitos condutoresno

abdicarem dos seus veculos particulares. Relativamente comodidade,identificou-se como requisito a possibilidade de integrao dum assistentede viagens. Este deve fornecer, de forma simples e intuitiva, alternativasao percurso a realizar com o veculo particular. Isto , o condutor deixa dese preocupar onde vai estacionar o carro e se as ruas X e Y esto ou no


31/84

3.1 Anlise 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 pblico a seguir para chegar mais facilmente aoseu destino dentro da hora pretendida.

RF03 - Contedos adaptveisRelativamente ao conforto identificou-se como requisito a possibilidade

de utilizar mtodos de inteligncia artificial para ajustar os contedosmultimdia ao comportamento do utente. semelhana do que feitoem alguns sistemas Web possvel classificar os utilizadores pelo quevisualizam. Deste modo, consegue-se sugerir contedos que possam ser

do seu interesse.

RF04 - Contedos recuperveisAlgo que ficou assente no seguimento dos requisitos anteriores que

torna-se necessrio guardar de alguma forma o estado do ltimo contedovisualizado pelo utente. Isto para permitir que um contedo que tenhaficado em aberto seja recuperado no mesmo estado aquando de uma novasesso por parte daquele utente.

RF05 - Agrupamento de utilizadoresOsSIs so muitas vezes acusados de fechar as pessoas num mundo parte. Uma vez que este sistema j pretende integrar uma componente deinteligncia artificial, surgiu como requisito a possibilidade de tentar criaruma rede de socializao dos utentes. Esta rede que passa a ser designadapor rede de amigos tem como objectivo o agrupamento de utilizadorespelos contedos visualizados.

RF06 - Informao em qualquer lugarA exigncia da sociedade manifesta-se perante os SIs com a necessidade

de ter acesso a qualquer informao em qualquer lugar. No mbito destesistema, a consequncia dessa exigncia a identificao de um requisitoque permita a qualquer utilizador aceder a informaes pertinentes ondequer que esteja. Isto , considera-se til que o utilizador possa aceder sseguintes informaes:


32/84


Histrico dos contedos visualizados nos transportes pblicos.

Horrios dos transportes pblicos.

Lista de amigos presentes num determinado transporte pblico.

Dados sobre o registo do utilizador no sistema.

RF07 - Pgina Web institucionalComo vem sendo comum em qualquer organizao ou empresa, fica

comoultimorequisitoanecessidadedeassociaodosistemaaumapginainstitucional. Na qual devem constar, para alm das informaes sobre a

empresa gestora da rede de transportes, informaes detalhadas sobre ofuncionamento do carFree.ubi e condies de utilizao.

3.1.2 Requisitos no funcionais

RNF01 - SeguranaComoficoupatentenosrequisitosfuncionais,necessrioterutilizadores

no sistema. Cada utilizador deve ser identificado por um dos dois con-juntos de pares, password e dispositivo mvel (Telemvel ouPDA) oupassword e nmero de registo. Por motivos de segurana a password privada e cifrada. Por motivos de privacidade o identificador do disposi-tivo, neste caso oMACAddress, tambm cifrado.

RNF02 - PrivacidadeEm momento algum so utilizados dados pessoais do utilizador. O

sistema no precisa nem deve solicitar ou armazenar dados como nome,morada e outros. Cada utilizador essencialmente identificado pelosdispositivos que utiliza. Apesar de os dispositivos possurem umMACAddress que pblico apenas o prprio utilizador pode fazer a associaoentre oMACAddress e o nmero 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


33/84

3.2 Dispositivos 21

alguma portabilidade. Nesse sentido deve utilizar-se o paradigmaSOA

para possibilitar uma futura utilizao do servidor noutras plataformasque no Windows.

RNF04 - ManutenoUm sistema com uma dimenso como este exige que a programao seja

feita por partes e com documentao suficiente. Neste caso, pelo menos,comentrios aos mtodos e uso de dlls para algumas componentes daaplicao.

RNF05 - UsabilidadeQualquer aplicao deve ser feita pensando na forma como o utilizadorvaiinteragircomamesmaecomomeioenvolvente. Aaplicaopara PDAdeve ser confortvel na sua utilizao, no exigindo demasiado escrita detexto por parte do utilizador. Por sua vez a aplicaoWindowsdeve serpensadaerealizadaconsiderandoquenoexistenenhumtecladoaodispordo utente. Portanto a interface deve ser desenhada tendo em conta que outente tem um ecr tctil sua frente, no qual, caso seja necessrio deveser utilizado um teclado virtual.

RNF06 - FiabilidadePela natureza ubqua da aplicao 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 entantovo 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 soluesforam avaliadas como por exemplosmartcardssem contacto semelhanados passes utilizados no Porto. No entanto, e apesar deserem mais seguros,os mesmos no so de fcil acesso. Sendo a plataforma algo complexa e


34/84


o tempo de desenvolvimento curto, optou-se por recorrer a equipamentos

de acesso mais imediato. Mas numa futura implementao do sistemaestas solues no so de desprezar.

3.2.1 Ecrs tcteis

Apesar de no terem sido utilizados, o desenvolvimento da aplicaoa correr no interior dos transportes pblicos, foi pensada neste tipo deequipamento. Este tipo de dispositivos ideal para servir de interfacenum ambiente urbano. Para alm de ocuparem um espao muito limitadopermitem uma interaco mais intuitiva. semelhana de muitas tarefas

que so realizadas no dia-a-dia com um ecr tctil descarta-se qualquernecessidade de objectos suprfluos como o rato e o teclado. Este disposi-tivo enquadra-se nos objectivos dos requisitos RF01 (ver3.1.1), RF03 (ver3.1.1), RF04 (ver3.1.1). Para alm de servir como meio de identificao doutilizador (RFN01, ver3.1.2) perante os ecrs tcteis existente no interiordos transportes.

3.2.2 PDAcom ou semGPS

Este no um dispositivo muito comum mas a verdade que o seu preocomea a aproximar-se cada vez mais ao dos telemveis. Tendo maisfuncionalidades, uma questo de tempo at existir uma fuso dos doisdispositivos ou dos telemveis desaparecerem para apenas sobreviver oPDA. Este dispositivo enquadra-se nas necessidades dos requisitos RF06(ver3.1.1) e RF02 (ver3.1.1). No caso do RF02, o dispositivo requer aexistncia deGPS integrado ou de um dispositivoGPSexterno. Masapesar de poderem funcionar na mesma aplicao o RF06 e RF02 soindependentes.

3.2.3 TelemvelUma vez que existe a conscincia de nem todos disporem de PDAs eassim o utilizador j no conseguir ter acesso s funcionalidades prpriasda aplicaoMobile. Pretende-se que o mesmo possa pelo menos usufruir


35/84

3.3 Tecnologias e Ferramentas 23

dos servios no interior do autocarro. Deste modo o telemvel ou outro

dispositivo comunicantebluetoothpode servir como meio de identificaodo utilizador (RFN01, ver3.1.2).

3.3 Tecnologias e Ferramentas

ContextualizaoEsta plataforma mexe com mltiplas tcnicas e tecnologias mas nem to-

das foram introduzidas. De seguida so apresentadas muito brevementetodas as tecnologias que esto de uma ou outra forma integradas na apli-

cao.

VS2008OVisualStudio2008(VS2008)umIntegratedDevelopmentEnvironment

(IDE) da Microsoft que permite desenvolver aplicaes usando um lequeinteressante de linguagens para diversas situaes. O VS2008 permite criar

bibliotecas, aplicaes para consola ou aplicaes grficas paraWindowseWindows Mobile. Atravs desteIDEfoi possvel utilizar e integrar lingua-gens como o C++, CSharp e FSharp no desenvolvimento da plataforma.

Windows SDKO Windows Software Development Kit (SDK) rene um conjunto de

bibliotecas, APIs e exemplos para desenvolvimento de aplicaes em Win-dows. EsteSDKfoi necessrio para o uso daAPIBluetooth da Microsoft.

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

ativos da Microsoft. Esta talvez um dos maiores pontos favorveis aodesenvolvimento de aplicaes em Windows, uma vez que aglomera umconjuntoenormedebibliotecas. Paraalmdisso,aFrameworkexpansvele pode ser usada em mltiplas linguagens flexibilizando a programao.

Compact Framework .NET 3.5A Compact Framework .NET a verso Framework .NET da Microsoft


36/84


para dispositivos mveis e embebidos. Apesar de serem muito semel-

hantes preciso ter algum cuidado porque nem todas as funcionalidadesda Framework .NET existem nesta verso.

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 deHTTPde modo a tornar osWeb Servicescriadosdisponveis pelainternet.

MS SQL Server 2005OMicrosoftMSQLServerumservidordeBasedeDadosparaWindows

comumainterfacedegestocompleta. Umavezqueaplataformanecessitade armazenar dados no servidor, a soluo adoptada foi recorrer base dedados da Microsoft.

Microsoft Expression Blend 2Para o desenvolvimento da interface grfica da aplicao Windows

optou-se por utilizar o Microsoft Expression Blend 2. Este Graphical UserInterface (GUI) builder facilita a criao de interfaces ricas para a WebeWindows.

Microsoft MapPointO Microsoft MapPoint tanto uma tecnologia como uma ferramenta e

foi utilizado para o desenvolvimento da componente que pretende servirde extenso doGPS. Esta ferramenta permite integrar, editar e visualizarmapas. Ela penas foi utilizada pelo Joaquim Tojal, como tal, maioresreferncias e explicaes so feitas no relatrio 54.

OpenNetCFA OpenNetCF desenvolveu e disponibilizou uma extenso da Compact

Framework .NET da Microsoft. Esta extenso teve de ser usada devido adois factores fundamentais:


37/84

3.4 Arquitectura 25

Em primeiro pelo facto da Compact Framework no incluir os mto-

dos da Framework .NET para derivao de chaves. Em segundo porque esta foi a soluo mais prtica que se encontrou

para conseguir recolher internamente oMACAddress das interfacesde rede doPDA.

EplogoComo possvel constatar todas as ferramentas utilizadas so da Mi-

crosoft, no porque fosse considerado que eram as melhores mas porqueassim era exigido para efeitos de concurso. No entanto, isso no consti-

tuiu nenhuma limitao no desenvolvimento da plataforma, muito pelocontrrio.

3.4 Arquitectura

Finalmentepassa-seaapresentaraarquitecturaquefoiidealizadaparaestaplataformaubqua. Aarquitecturabaseia-senumaarquitecturacliente/servidore est dividida em mdulos segundo alguns padres de funcionamento.

3.4.1 Servidor

ObjectivoNo centro encontra-se o servidor, uma vez que esta a pea nuclear

da arquitectura. Se o servidor falhar, falha toda a plataforma. Ou melhor,toda a plataforma fica parcialmente inutilizvel j que as aplicaesclientesprecisam de respostas do servidor. Por exemplo: a aplicao a funcionarnoPDAdeixa de fazer sentido se no conseguir receber respostas doservidor, no entanto a mesma continua a funcionar sem conseguir fornecerinformao ao utilizador. J a aplicao a correr no interior dos transportes

pblicospodecontinuarafuncionarquasenormalmentesetiverumacachede contedos locais. Esta situao no foi implementada mas pode vira ser adicionada futuramente. Para uma implementao comercial destaplataforma seria necessrio difundir o servidor por diversos computadoresde modo a que se algum falhasse, esse fosse compensado pelos restantes.


38/84


Figura 3.1: Esquema da plataforma carFree.ubi


39/84

3.4 Arquitectura 27

Figura 3.2: WSDLdo Servidor

Sem claro esquecer a redundncia que seria necessria com BackBoneseRouters.

ComponentesPelo diagrama3.1consegue-se perceber que o servidor possui trs com-ponentes distintas mas interligadas e acessveis porWeb Services, so elasa Base de Dados, os WebServives e a Inteligncia Artificial (IA). Em mo-mento algum um cliente comunica directamente com a Base de Dados oucom a classe deIA.

SeguranaSe um cliente quer alguma informao da Base de Dados a aplicao faz

esse pedido aos Web Services e eles tratam do resto. Optou-se por esta abor-dagem por motivos de segurana. Em momento algum se pretende darinformao mais do que o necessrio a um atacante. Comesta metodologiatudo o que est para alm dos Web Services uma autntica caixa negrapara qualquer atacante externo.


40/84


Inteligncia Artificial

Pouco se vai adiantar sobre a parte de inteligncia artificial, uma vez quea mesma foi desenvolvida pelo Joo Oliveira. Apenas fica mais uma breveexplicao sobre a motivao para esta componente existir na arquitectura.Como ficou identificado nos requisitos, considerou-se necessrio ter umacomponente que permitisse adaptabilidade por parte da aplicao clientea correr nos transportes pblicos. Tambm se considerou pertinente classi-ficar os utilizadores pelas suas interaces com a mesma aplicao clientede modo a proporcionar uma maior socializao dos utentes, caso elesassim o desejem. Com esta componente designada por rede de amigostorna-se muito mais fcil as pessoas ficarem a conhecer outras com osmesmos gostos.

Base de DadosA Base de Dados pode ser considerada como outra pea nuclear da

plataforma e a mesma descrita com maior preciso no captulo4j quefoi parte integrante do trabalho desenvolvido.

Web ServicesOs Web Services podem ser vistos na relao Cliente/Servidor como o

Front-End do sistema. Tal como foi referido previamente, estes queso responsveis 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 servidorHTTPesteja acessvel para o cliente e que tenha todos os servios activos. Partedos Web Services so descritos com maior detalhe no captulo 4, aqueles queacabaram por ser feitos pelo Joaquim Tojal, devido s suas necessidades,no so apresentados neste relatrio.

3.4.2 Mvel e Carro

ObjectivoEstas duas componentes da arquitectura apesar de estarem divididas

esto na verdade integradas numa s aplicao. Aplicao que pretendefornecer ao utilizador as seguintes funcionalidades:


41/84

3.4 Arquitectura 29

Figura 3.3: Menu principal da aplicao PDA

Assistentede viagens GPS paratransportespblicoscomoalternativaao particular (Joaquim tojal).

Processo de primeira utilizao da aplicao que pode servir para

gerar ou recuperar um registo.

Horrios dos transportes pblicos indicando o tipo do transporte e aparagem de origem e destino.

Lista de amigos presentes e lugar que ocupam, num determinadotransporte pblico em tempo real.

Histrico dos contedos visualizados nos transportes pblicos, dadauma data de utilizao e um tipo de contedo.

Dados sobre o registo do utilizador no sistema, como a data de reg-isto, o nmero de registo e osMACAddress dos seus dispositivosregistados.


42/84


Componentes

Oobjectivodadivisodestasduascomponentesadevincaradiferenaentre o trabalho do Joaquim Tojal referente ao RF02 (ver3.1.1) e o que vaiser descrito com maior detalhe no captulo5referente ao RF06 (ver3.1.1).Optou-se por, comodidade do utilizador, juntar tudo numa s aplicao,mas como vai ser possvel verificar a mesma est dividida e funciona deforma independente. Isto , se oPDAno tiverGPSa parte relativa aoRF06 funciona, mas a parte relativa ao RF02 no.

Interface

Para se chegar ao resultado apresentado na figura 3.3bem como nocaptulo5foi necessrio recorrer a um processo de "desenho"de interfaces(GDI) integrado com controlos. Os crditos da pesquisa desta tcnica edo desenho da interface principal vo para o Joaquim Tojal. Apesar decada um ter feito a sua parte da aplicao era obviamente incompatvelapresentar duas interfacesdistintas. Deste modo, o trabalho apresentadono captulo5faz uso da tcnica citada.

3.4.3 Transportes Pblicos

ObjectivosTal como ficou estabelecido no RF01 (ver3.1.1), RF03 (ver3.1.1), RF04

(ver3.1.1) e RF05 (ver3.1.1) esta aplicao pretende, de forma genrica,disponibilizar contedos multimdia (msica, livros, jornais, revistas, etc.)de preferncia exclusivos num ecr tctil. O facto de fornecer contedosmultimdia no representa grande inovao, por mais bonita que possaser ainterface. No entanto, o facto de isso ser feito num ecr com qualidadee com umainterfaceagradvel para o utilizador, conjugado com contedosque no esto disponveis noutro lugar e uma certa adaptabilidade da

interface sem dvida uma mais-valia. Uma parte fundamental incidentesobre a disponibilizao de contedos para esta aplicao est relatada nocaptulo4atravs da descrio da Base de Dados. O restante processo, queainda no foi descrito, incide sobre a identificao do utilizador perante osistema e ser explicado no captulo6.


43/84

3.4 Arquitectura 31

Figura 3.4: Menu principal da aplicao Windows

InterfaceOs crditos da pesquisa da tcnica utilizada para desenvolvimento da

interface(utilizao do expression blend), bem como o desenho dainterface

principal vo para o Andr Passos. O trabalho apresentado no captulo6sobre a parte referente aologindesta aplicao usa as tcnicas anteriores.

3.4.4 Casa e Trabalho

Esta a componente da arquitectura referente ao RF07 (ver 3.1.1) que

se acabou por valorizar menos. A ideia desta componente consiste naimplementao/reutilizaode umapginainstitucional. Esta pginapodeinclusivamenteserapginadaempresaquequeirautilizarestaplataforma.Infelizmente, devido falta de tempo, ningum acabou por desenvolveresta componente ficando a mesma para trabalho futuro.


44/84


3.5 Concluso

Neste captulo ficou descrito a plataforma carFree.ubi. Como possvelperceber ao longo do captulo as preocupaes foram mais focadas paraa arquitectura em si do que para questes sobre a interface devido aotrabalho desenvolvido. Neste tipo de projectos o trabalho apesar de serindependente no pode ser desconexo. Como tal, uns preocuparam-semais com a interfacee outras questes como foi o caso do Joaquim Tojalpara a aplicao PDA e do Andr Passos para aplicao Windows enquantoo Joo Oliveira se preocupou com a parte de Inteligncia Artificial. Semo trabalho de todos seria impossvel chegar onde se chegou. At aquifoi descrito o trabalho mais terico realizado no mbito deste projecto.Enquanto nos captulos seguintes ser descrito todo o trabalho prticodesenvolvido.


45/84

Captulo 4

Servidor

Servidor WindowsTal como foi referido, o servidor a pea nuclear do sistema. Desde

cedo optou-se por configurar e trabalhar directamente com um servidorWindows existente na sala 6.10. Este servidor no foi instalado de razpor motivos de licenas, sendo que o sistema operativo de base foi oWindows XP que j se encontrava instalado na mquina. Foi concedidotemporariamente acesso exterior ao porto 80 da mquina uma vez que aquele com que se trabalha para disponibilizao dos Web Services.

ConfiguraoO processo de configurao da mquina passou assim pela instalao

do IIS 6.0 e do SQL Server 2005. Para alm da instalao foi necessrioproceder a algumas configuraes de modo a manter um nvel de segu-rana considerado mnimo. Essas configuraes passaram por limitar oacesso Base de Dados e pgina dos Web Services1. Para esse efeito foiutilizado uma conta interna na Base de Dados e uma conta do Windowspara oIIS. Mais podia ter sido feito em termos de configuraes paratornar o acesso aosWeb Servicesmais seguro (recorrendo ao Web ServicesEnhancements (WSE) por exemplo) mas o projecto consiste em muito maisdo que isto, tendo-se revelado necessrio focar a ateno noutras partes doprojecto.

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

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


46/84

34 Servidor

4.1 Base De Dados

At ao momento ainda no foi especificada a Base de Dados. Todaviaisso vai ser feito nesta seco uma vez que o desenho e implementao damesma integraram-se no trabalho relativo implementao do servidor.

4.1.1 Diagrama

A Base de Dados possui alguma complexidade como possvel verificar nafigura4.1.Para uma melhor compreenso optou-se por dividir a descrio

da Base de Dados por componentes.

Processo de desenvolvimentoO processo de desenvolvimento da Base de Dados no pode ser con-

siderado tradicional uma vez que o diagrama foi directamente desenhadona ferramenta administrativa doMS!(MS!) SQL Server (Microsoft SQLServer Management Studio Express). Assim, no foi desenhado nenhumDiagrama de Entidade-Associaao (DEA), no entanto de salientar queestes diagramas so algo equivalentes. A ideia foi desenvolver a Base

de Dados de forma pensada e calculada recorrendo directamente a umaferramenta que permitisse posteriormente gerar scripts para criao daBD! (BD!) em MS! SQL Server. Possivelmente at existemoutras 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, no se exploraram outras ferramentas.

VantagensPara alm da gerao de scripts atravs do diagrama, outra grande van-

tagem de desenhar o diagrama com recurso a esta ferramenta consiste

no facto de que quem desenvolve a Base de Dados se pode abstrair total-mente com a apresentao das tabelas. Isto , a ferramenta possibilita tantoum escalonamento do diagrama como disposio automtica das tabelas.Quem desenvolve s se preocupa com aquilo que realmente interessa que com as tabelas, os elementos das tabelas, as relaes e restries.


47/84

4.1 Base De Dados 35

Figura 4.1: Diagrama da Base de Dados


48/84

36 Servidor

Esclarecimentos

Para facilitar a descrio do diagrama introduzem-se alguns esclareci-mentos sobre os smbolos presentes. No interior de cada tabela junto a de-terminados elementos existe um smbolo de chave dourada. Isso significaque os elementos em questo so chave primria da tabela em questo.No caso desta Base Dados os elementos chave podem ser nicos, em paresou triplos. Relativamente s relaes entre as tabelas, tambm surgemdois smbolos distintos. Uma chave dourada e um smbolo infinito quepodem aparecer combinados de mltiplas formas. Sempre que surge umachave numa extremidade e uma chave na outra extremidade, significa quea relao das tabelas de 1 para 1. Sempre que numa extremidade surgeuma chave e noutra extremidade um infinito, significa que a relao das

tabelas de 1 para N e vice-versa.

4.1.2 Utilizadores

Comeando pelo ponto central desta Base de Dados, a tabela Utilizadorpossui cinco relaes distintas com outras tabelas que vo ser explicadasmais frente. O importante nesta tabela que cada utilizador vai possuirum ID_Utilizador nico que o vai identificar, em algumas situaes esteID designado por nmero de registo de modo a ser mais amigvel para o

utilizador do sistema. No existe nesta tabela, ou em outra qualquer, umnico elemento relativo a dados pessoais do utilizador. O sistema, tal comoest especificado no RNF02, no 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 necessrio recorrer a uma pass cifrada tam-

bm ela presente na tabela.

4.1.3 Grupos

AindanatabelaUtilizadorpossvelverificaraexistnciadeumID_Grupo.Esse ID_Grupo est relacionado com a tabela Grupos, na qual so iden-tificados os grupos de utilizadores reconhecidos pela IA (Tarefa do JooOliveira). Assim permite-se que cada utilizador apenas pertena a umgrupo, mas que cada grupo tenha vrios utilizadores. De notar tambm


49/84


que, sempre que um Utilizador se regista, o mesmo fica a pertencer a um

grupo de pessoas ditas "indeterminadas".

4.1.4 Interface

Uma das outras relaes existentes com o utilizador a da tabela Interface.Nesta tabela pode verificar-se a relao de 1 para 1, permitindo que um uti-lizadornotenhaestadoequandotenhaapenaspossuaum. Istoverifica-seno acto do registo, quando o utilizador nunca recorreu interface existenteno interior dos transportes pblicos e como tal no possui um estado de-terminado. Este estado serve para permitir que os utilizadores tenham umconjunto de configuraes de interface ao seu dispor. Esta funcionalidadeno est patente nos requisitos tendo sido acrescentada posteriormente.

4.1.5 Contedos

Utilizador_ConteudoOutra das relaes feitas com o utilizador tem a ver com os contedos

que o mesmo j visualizou. Cada utilizador pode ter visualizado vrioscontedos e pode inclusivamente ver o mesmo contedo em instantes

diferentes. A partir do momento que um contedo aberto insere-se umregisto na tabela Utilizador_Conteudo que vai actualizando o elementoestado at o mesmo sair desse contedo. Esse estado refere-se ao estadopropriamente do contedo. Se um livro qual a pgina aberta, se forum vdeo em que minuto do vdeo se encontra e por ai fora. A partir domomento em que um utilizador sai da aplicao e deixa um contedo 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 umcontedo seja encerrado para dar lugar visualizao de outro o estado colocado a 0 no sendo feita mais nenhuma actualizao a esse registo.

ConteudoA tabela Conteudo est no centro dos contedos como est o utilizador

no centro da Base Dados. Essa tabela possui relaes com tabelas de Autor,Genero, Tipo, Editora, sendo estas do mesmo tipo de relao e outra relao


50/84

38 Servidor

distinta com a tabela anteriormente vista. Isto faz com que cada contedo

possa pertencer a vrios registos da tabela Utilizador_Conteudo. Como ainda possvel constatar pelo diagrama, a tabela Conteudo possui vrioselementos que identificam o contedo. De notar que a tabela embute ocontedo em si, no faz nenhuma referncia localizao dos contedos.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 contedo possa

ter um autor, um gnero, um tipo e uma editora e que cada uma destas car-

actersticas possa estar presente em contedos diferentes. Relativamenteao tipo dos contedos estes existem para distinguir as msicas 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 relao entre os utilizadores e os dispositivos. Isto , estatabela de relao serve para permitir que cada utilizador tenha mais doque um dispositivo. No entanto um utilizador pode no 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 seuMACAddress cifrado e combinado com a chave pode servirem determinadas situaes de identificao do utilizador tal como ficouespecificado no RNF01 (ver3.1.2) e RNF02 (ver3.1.2).

4.1.7 TransportesA componente dos transportes, tal como as restantes, tambm se rela-ciona com o utilizador tendo como facto de que se pretende saber seum utilizador est presente num transporte ou no. Assim a tabela de


51/84


relao Utilizador_Transporte permite que um utilizador esteja num qual-

quer transporte ocupando um determinado lugar, como pode no estar emnenhum. De notar ainda que cada transporte possui um tipo, por exemploautocarro, metro, etc., e que cada tipo pode ter vrios transportes. Paraalm de um transporte ter um nome, uma matrcula, o nmero de lugares,omesmopossuiumalatitudeelongitudequesequeractualizadamedidaque o transporte se move.

Rotas

Outra parte importante na relao dos transportes o facto dos mesmosterem horrios, 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 considerao que num dia apenas um transporte pode fazeressa rota. No de um transporte fazer um percurso em contnuo durante odia inteiro deve-se partir essa rota de modo a que o transporte no repita

nenhuma paragem.

Paragens

As paragens juntam duas situaes que se consideram compatveis pelotipo de dados armazenados na tabela Paragem. Deste modo uma paragempossui um tipo que pode serde paragem ou estacionamento. Esta paragemdeve ser vista como um ponto de paragem possvel para um utilizador

do 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 relaes com as rotas dos transportes, no caso de a paragem ser umestacionamento ento esta vai possuir um preo.


52/84

40 Servidor

4.2 Privacidade e Segurana

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 aplicao cliente. Isto evitaque um atacante tenha conhecimento sobre a estrutura da Base de Dados eque sobre efeito de alguma tcnica consiga injectarSQLpara extrair aindamais informaes.

Dados cifradosComo foi possvel perceber noutros pontos do relatrio existem dados

cifrados na Base de Dados, nomeadamente as passwords dos utilizadorese osMACAddress dos dispositivos. No captulo5faz-se uma descriodetalhada de como esses dados so cifrados. De momento o importante o motivo para a existncia desses dados cifrados. Qualquer pessoaque escute comunicaes no cifradas vai conseguir interceptar e tratar osdados passados na comunicao.

Password cifradaSeapasswordnoestivercifradabastaaoatacantedescobrirqualoMAC

Address do utilizador juntamente com a password no cifrada, emularesseMACAddresseassimconseguiridentificar-senosecrstcteiscomosendoalgum que no . O perigo disso que um atacante pode conseguir semautorizao perceber quais so os gostos de uma outra pessoa, coisa quedo ponto de vista dos sistemas ubquos totalmente indesejvel.

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

em dia confia-se demasiado nas empresas que possuem a informao, masalguma informao no 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 so mais perigososdo que os externos. Imaginando que oMACAddress no era cifrado,


53/84

4.3 Mtodos e Classes 41

qualquer administrador do sistema podia ter acesso Base de Dados e

fazer associaes entre utilizadores e os seus MAC Address. Cifrando estesdados, um administrador consegue na mesma recolher muita informaosobre 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 Servicesest

limitadoaquemtenhaascredenciasdeautenticao. Istoimpossibilitaqueos Web Servicesdesenvolvidos no projecto sejam utilizados por terceiros

sem a devida autorizao. Limita-se com isto, a possibilidade de atacantesdesenvolveremcdigoqueinvoqueos Web Services para extrair informaode forma automatizada.

EplogoA segurana um tema que despertou interesse e representou mais

um desafio na realizao deste projecto, no entanto no apresentadaaqui nenhuma soluo milagrosa. Acredita-se que mais cedo ou maistarde seja possvel contornar as barreiras implementadas. Sendo que,

considera-se necessrio recorrer a uma avaliao externa para apurar atque ponto as medidas so ou no eficientes. Apesar de tudo as medidasno foram implementadas em vo, existe uma forte convico sobre asmesmas terem a sua eficincia, apesar de possivelmente existirem falhasque at ao momento no foram detectadas.

4.3 Mtodos e Classes

Em termos de desenvolvimento convm esclarecer que os mtodos apre-sentados de seguida no foram realizados pela sequncia apresentada norelatrio. Isto , apesar de o servidor ter uma importncia significativa eestar apresentado em primeiro no relatrio na verdade os mtodos foramdesenvolvidos medida que se foram tornando necessrios.


54/84

42 Servidor

Figura 4.2: Diagrama doVS2008do Servidor

4.3.1 Diagrama do Visual Studio

Na figura4.2apresenta-se o diagrama das classes e mtodos automati-

camente gerado pelo Visual Studio. De notar a presena de uma ClasseIA desenvolvida pelo Joo Oliveira, como tal no so apresentados nemmtodos nem maiores explicaes sobre a mesma. O diagrama s con-templa mtodos desenvolvidos na realizao deste projecto para evitarqualquer tipo de confuso sobre a autoria dos mesmos. Outros mtodosforam usados para o funcionamento de partes de trabalho desenvolvidaspelos restantes elementos, mas os mesmos no se encontram aqui listados.

4.3.2 Classe: Com

OsWeb Servicesso, como referido anteriormente, o que vai transparecerparaforadoservidor. Elessocomoumaponteentretodasascomponentesdo servidor e as aplicaes cliente, pelo que todos os mtodos presentesna classe Com (do tipoWeb Service) so do tipoWeb Method.


55/84


connect

O mtodo connect existe no mbito do projecto para testes. Este mtodobasicamente estabelece a ligao entre o cliente e o servidor devolvendoum valor booleano, sem receber qualquer tipo de argumentos.

userValEste mtodo recebe um nmero de registo e uma password cifrada de

modo a devolver um valor booleano indicando se existe ou no um uti-lizador com tal correspondncia.

userVal2Semelhante ao mtodo anterior mas desta vez para validar um par difer-

ente. Mais precisamente oMACAdress j cifrado com uma passwordcifrada.

userLastTravelMtodo responsvel por devolver uma string devidamente formatada

correspondente data em que um determinado utilizador viajou numtransporte pblico. H que ter em conta que, para que seja possvel saberquando foia ultima vez que um determinado utente viajou num transporte,implica necessariamente que este tenha interagido com os ecrs tcteis dosistema. Por outras palavras, o mtodo devolve a data da ltima interacocom o sistema presente no interior dos transportes pblicos.

userAddMtodo que permite, recebendo uma password cifrada, adicionar um

novo utilizador ao sistema. O valor devolvido por este mtodo uminteiro que corresponde ao nmero de registo do utilizador.

transportationsType

Este mtodo j difere um pouco dos anteriores uma vez que necessitade devolver uma lista de dados. O mtodo em si devolve a lista de todosos tipos de transportes. Para isso devolve o resultado em XmlDataDoc-ument. Integrado com o cabealho Extensible Markup Language (XML)gerado automaticamente peloWeb Serviceo que o mtodo faz preencher


56/84

44 Servidor

oXMLcom os dados de interesse. Esta tcnica foi seguida sempre que

houve necessidade de trabalhar com tipos de dados mais sofisticados doque um inteiro, uma string ou um booleano. Isto permite tornar os mto-dos compatveis com diversas linguagens j que devolvem umXMLqueconsegue ser lido independentemente da plataforma tal como se pretendiano RNF03 (ver3.1.2).

stationsListMtodo que devolve emXMLtodas as paragens de um determinado

tipo de transporte.

contentsTypeMtodo que devolve emXMLa lista de todos os tipos de contedos

existentes.

contentsDateListMtodo que lista emXMLtodas as datas de visualizao de contedos

de um determinado utilizador. De notar que as datas na Base de Dados

possuem horas, minutos e segundos, no entanto o que sai deste mtodoso apenas as datas com dia, ms e ano em que o utilizador recorreu aosistema.

transportationsListMtodo que devolve emXMLa 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 mtodo recebe o nmero de registo de um utilizador e devolve em

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


57/84


devicesList

Mtodo responsvel por devolver a lista dos dispositivos de um de-terminado utilizador. De notar que osMACAddress devolvidos estocifrados, ficando responsabilidade da aplicao cliente pedir a passwordao utilizador de modo a conseguir decifrar os dados.

friendsInMtodo que dado um nmero de registo e o nome de um transporte

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

contentsViewedEste mtodo devolve a lista dos contedos visualizados por um uti-

lizador num determinado dia e de um dado tipo. Mais uma vez, o mtodorecebe o nmero de registo do utilizador, o nome do tipo e a data devi-damente formatada, sendo que devolve, como nos restantes casos, oXMLcom a lista.

stationsStart

Mtodo responsvel por devolver as possveis paragens de origem comligao a uma paragem de destino. Consegue-se fazer a diferena entreuma paragem de origem ou destino consoante a hora em que est previstoo transporte passar nas mesmas.

stationsEndMtodo semelhante ao anterior, mas desta vez para uma paragem de

origem o mtodo devolve a lista das possveis paragens de destino.

transportationsList2Mtodo que recebe diversos argumentos de entrada como o nome do

tipodeumtransporte,onomedeumaparagemdeorigemeonomedeumaparagem de destino. Para posteriormente devolver a lista dos possveistransportes que contemplem os requisitos introduzidos.


58/84

46 Servidor

4.3.3 Classe: LigacaoBD

Esta classe que na verdade implementa todas as chamadas Base deDados necessrias. Assim optou-se, sempre que necessrio, por duplicaros nomes dos mtodos da classe Com, para a classe LigacaoBD, de modo aestes serem invocados pelos Web Services. Esta abordagem foi seguida querpormotivosdeorganizaocomodeestruturaodocdigodesenvolvido.De notar ainda que em cada mtodo aberta e fechada uma ligao Basede Dados.

Uma vez que j se sabe, da seco anterior, o que cada mtodo deve fazer

apenas basta acrescentar umas ligeiras informaes. Nomeadamente, dereferir que em muitos casos a query a ser processada pela Base de Da-dos gera oXMLautomaticamente. Isso faz-se adicionando se seguinteinstruo"FOR XML PATH (Elemento), root(Utilizador)"no fim de cadaquery.

De seguida listam-se todos os mtodos que invocaram directamentequerys Base de Dados.

userVal userVal2

userLastTravel

transportationsType

stationsList

contentsType

contentsDateList

transportationsList

userData

devicesList


59/84

4.4 Concluso 47

Por fim surgem os mtodos que necessitaram a criao e utilizao de

procedimentos por serem um pouco mais complexos de implementar.

userAdd

friendsIn

contentsViewed

stationsStart

stationsEnd

transportationsList2

4.4 Concluso

Este captulo introduziu o trabalho e as preocupaes tidas em consider-ao no desenvolvimento do servidor, nomeadamente as preocupaes aonvel de segurana no armazenamento e na comunicao dos dados. Foitambm apresentada a estrutura quer da Base de Dados como do Servi-dor e por fim a forma como os Web Servicesligam todas as componentes

presentes no servidor. No captulo seguinte ser descrito o trabalho de-senvolvido na aplicao cliente a correr emWindows Mobile, isto o clienteparaPDA.


60/84


61/84

Captulo 5

Cliente Windows Mobile

Tal como foi referido anteriormente esta aplicao possui duas compo-nentes distintas. Numa a aplicao pretende servir de assistente de viagenspara condutores de veculos particulares, para mais informaes consultarprojecto 54. Na outra, aqui descrita, a aplicao pretende fornecer infor-maes consideradas pertinentes. No entanto, antes sequer de a aplicaoser lanada em modo de funcionamento normal preciso passar por umprocesso de registo. Tudo isto vai ser descrito neste captulo com maiordetalhe.

Processo de desenvolvimentoO processo de desenvolvimento foi baseado nos requisitos apresentados

e na documentao produzida de forma informal. Nessa documentaoinformal consta, alguns fluxogramas, story boards da interface, cenriosde interaco e outros apontamentos.

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

classes e mtodos desenvolvidos. Ao contrrio do que foi feito com o

servidor aqui no se pretende descrever cada um dos mtodos uma vezque muitos esto relacionados com aces de botes e questes relativas aoambiente grfico. A abordagem vai ser mais demonstrativa e explicativaat porque, ao contrrio do servidor, nesta aplicao pode-se recorrer simagens da interface.

49


62/84

50 Cliente Windows Mobile

Figura 5.1: Diagrama doVS2008da aplicao Windows Mobile


63/84

5.1 Registo/Login 51

5.1 Registo/Login

Comeando pelo mais importante tendo em conta que o registo/logindaaplicao representa um aspecto bastante ponderado por motivos de se-gurana. Surgiram vrias abordagens possveis para esta tarefa. Todaviaa que acabou por parecer mais eficiente e segura consiste em armazenar eusar o nmerode registo do utilizador directamente no registodo Windows.

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

caria o nmero de registo cifrado. Nesse processo o nmero de registo eracifrado e decifrado derivando a chave de umMACAddress do disposi-tivo. No entanto rapidamente se encontraram falhas a esta implementao.Para comear o ficheiro podia facilmente ser copiado dePDAparaPDA

bastando a um atacante conhecer e conseguir emular osMACaddress.Sem excluir a possibilidade de inadvertidamente o ficheiro poder ser apa-gado. Sendo que decidiu-se usar precisamente o mesmo processo masguardando o nmero de registo cifrado no prprio registo doWindows.

Vantagens e desvantagensA vantagem de cifrar o nmero de registo directamente para o registodoWindows que o mesmo no se copia nem apaga com tanta facilidade,uma vez que preciso ter acesso local aoPDApara realizar tal operao.A desvantagem continua a manter-se no facto de este mtodo no impedirque o nmero de registo seja replicado.

5.1.1 CryptoLib

Para proceder cifragem e decifragem, quer nesta aplicao como naaplicao que vai ser apresentada no captulo seguinte, optou-se por criaruma biblioteca criptogrfica com mtodos para cifrar e decifrar com todaa comodidade. Esta biblioteca foi desenvolvida em FSharp e baseia-se na

biblioteca criptogrfica do .NET.


64/84


Objectivo

Optou-se por criar uma biblioteca auxiliar porque cada vez que se pre-tende instanciar algum objecto da classe criptogrfica do .NET para cifrarou decifrar necessrio manipular streams entre outras coisas. Com esta

biblioteca auxiliar facilita-se todo o processo. Basta instanciar a classe e deseguida chamar o mtodo 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 necessrio. A classe criada possui vrios mtodos parapermitir cifrar em vrios modos recorrendo a duas cifras distintas.

AES-ECB

Uma das cifras o Advanced Encryption Standard (AES) em modoCipher-blockChaining (CBC)ouElectronicCodeBook(ECB). Omodo ECBtem a grande desvantagem de no esconder padres quando as mensagensa cifrar so grandes. No entanto como aqui no o caso esse problemano se verifica. Este modo no requerIVe utilizado para cifrar e decifraro nmero de registo do utilizador na aplicao doPDA. De notar aindaque com este modo utilizado um padding aleatrio que faz com que umtexto cifrado vrias vezes com a mesma chave s resulte num criptogramaidntico se opaddingaleatrio se repetir.

AES-CBCO modo CBC por sua vez permite esconder padres e requer a utilizao

de umIV. Para alm de, ao contrrio do modoECB,no necessitar depadding aleatrio 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 situaes. No caso de cifrar e decifrar oMACAddress, o modoECBj no assim to suficiente. Para alm doMACAddress originardois blocos, logo a necessidade de esconder padres, o facto doIVvariar uma mais-valia para esta situao. O modoCBC assim utilizado para

cifrar e decifrar osMACAddress dos dispositivos.

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


65/84

5.1 Registo/Login 53

algum tempo, ela continua a ser vivel com algumas alteraes, nomeada-

mente com a introduo de Salt. OMD5ao contrrio doAES uma cifraOne-Way, ou seja irreversvel, no entanto devido descoberta de colisespassou a ser possvel explorar oMD5. Inclusivamente possvel encon-trarRainbow-Tables, tabelas que permitem obter o texto plano atravs docriptograma, doMD5. No entanto, essas tabelas de nada servem quandoadicionado umsaltao texto a cifrar. Se o salt for fixo ainda existem algu-mas possibilidades de tentar explorar a falha doMD5, mas variando o salto processo torna-se impossvel (at ao momento). Deste modo oMD5utilizado para cifrar e decifrar as passwords dos utilizadores recorrendo aumsaltque varia de utilizador para utilizador. Na verdade oSaltusadoneste caso mais uma derivao da chave.

5.1.2 Passos do Processo

Arranque da aplicaoDito isto pode-se finalmente descrever por completo o processo de reg-

isto/login. Quando a aplicao executada o primeiro passo consiste emverificar a existncia do nmero de registo do utilizador no registo do Win-dows. Se este existir feito o processo de arranque do menu principal semsequer se decifrar o nmero de registo, todavia o login fica virtualmentefeito.

Decifrar o nmero de registoSempre que a aplicao necessitar do nmero de registo do utilizador ela

passa a ler o valor cifrado do registo do Windows. Posteriormente decifrao valor lido utilizando a cifraAESem modoECBcom chave derivadade um dos MAC Address doPDA. OMACAddress escolhido lendosequencialmente as interfaces de rede do dispositivo e extraindo oMACAddress da primeira interface identificada como sendo do tipoEthernetouWiFi. De notar que quer a leitura dosMACAddress como a derivaode chaves em Compact Framework s possvel graas utilizao da

biblioteca OpenNetCF citada no captulo3.

Menu 1No caso do registo doWindowsno conter o nmero de registo do uti-


66/84


Figura 5.2: Menu principal da aplicao Windows Mobile

lizador ento 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 delogin, se no segue para um menu de registo.

Menu RegistoNomenuderegistosolicitadaumapasswordaoutilizadorquedeveser

repetida para confirmao. Se as mesmas forem idnticas e diferentes deuma password vazia ento a aplicao cliente cifra a password recorrendo cifraMD5com salt derivado da prpria password. Essa password enviada para oWeb Serviceque devolve o nmero de registo do utilizadorcriado. Esse nmero cifrado usando a cifraAESem modoECBcomchavederivadadeum MAC Address do dispositivo, tal como foi explicadoanteriormente. Assim que o valor est cifrado o mesmo adicionado aoregisto e a aplicao lanada normalmente para o menu principal.

Menu LoginNomenude login outili

Documents

Relatório Projecto Licenciatura