You are on page 1of 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

Agradecimentos
A todos os que contriburam de alguma forma para este projecto, aqui ca o meu forte agradecimento. No vale a pena citar nomes, porque foram muitas as pessoas que deram a sua contribuio por mnima que tenha sido. Obrigado a todos!

Contedo
Agradecimentos Contedo Lista de Figuras Acrnimos 1 Introduo 1.1 1.2 1.3 1.4 2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . carFree.ubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizao do relatrio . . . . . . . . . . . . . . . . . . . . . i iii vii ix 1 2 4 7 8 11 13 15 15 17 18 18

Estado de Arte 2.1 2.2 2.3 Discusso existente . . . . . . . . . . . . . . . . . . . . . . . . Framework adoptada . . . . . . . . . . . . . . . . . . . . . . . Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Plataforma carFree.ubi 3.1 Anlise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . iii

iv 3.1.2 3.2 3.2.1 3.2.2 3.2.3 3.3 3.4

CONTEDO Requisitos no funcionais . . . . . . . . . . . . . . . . Ecrs tcteis . . . . . . . . . . . . . . . . . . . . . . . . PDA com ou sem GPS . . . . . . . . . . . . . . . . . . Telemvel . . . . . . . . . . . . . . . . . . . . . . . . . 20 21 22 22 22 23 25 25 28 30 32 32 33 34 34 36 36 37 37 38 38 40 41 42 43 46 47 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface . . . . . . . . . . . . . . . . . . . . . . . . . . Contedos . . . . . . . . . . . . . . . . . . . . . . . . . Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . Transportes . . . . . . . . . . . . . . . . . . . . . . . .

Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tecnologias e Ferramentas . . . . . . . . . . . . . . . . . . . . Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 3.4.2 3.4.3 3.4.4 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . Mvel e Carro . . . . . . . . . . . . . . . . . . . . . . . Transportes Pblicos . . . . . . . . . . . . . . . . . . . Casa e Trabalho . . . . . . . . . . . . . . . . . . . . . .

3.5 4

Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Servidor 4.1 Base De Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.2 4.3

Privacidade e Segurana . . . . . . . . . . . . . . . . . . . . . Mtodos e Classes . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 Diagrama do Visual Studio . . . . . . . . . . . . . . . Classe: Com . . . . . . . . . . . . . . . . . . . . . . . . Classe: LigacaoBD . . . . . . . . . . . . . . . . . . . .

4.4

Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CONTEDO 5 Cliente Windows Mobile 5.1 Registo/Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.2 5.3 5.4 5.5 5.6 6 CryptoLib . . . . . . . . . . . . . . . . . . . . . . . . . Passos do Processo . . . . . . . . . . . . . . . . . . . .

v 49 51 51 53 55 57 57 58 58 61 62 63 67 69 70 71 73

Horrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Amigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cliente Windows 6.1 6.2 6.3 BTLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Concluso 7.1 7.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . .

Bibliograa

Lista de Figuras
3.1 3.2 3.3 3.4 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6.1 6.2 6.3 6.4 Esquema da plataforma carFree.ubi . . . . . . . . . . . . . . Web Services Description Language (WSDL) do Servidor . . Menu principal da aplicao PDA . . . . . . . . . . . . . . . Menu principal da aplicao Windows . . . . . . . . . . . . . Diagrama da Base de Dados . . . . . . . . . . . . . . . . . . . Diagrama do VS2008 do Servidor . . . . . . . . . . . . . . . . Diagrama do VS2008 da aplicao Windows Mobile . . . . . Menu principal da aplicao Windows Mobile . . . . . . . . Menu 1 da aplicao Windows Mobile . . . . . . . . . . . . . Menu de login da aplicao Windows Mobile . . . . . . . . . Menu horrios da aplicao Windows Mobile . . . . . . . . . Menu amigos da aplicao Windows Mobile . . . . . . . . . Menu histrico da aplicao Windows Mobile . . . . . . . . Menu Mobile Info da aplicao Windows Mobile . . . . . . . Diagrama do VS2008 da aplicaao Windows . . . . . . . . . Lista de dispositivos . . . . . . . . . . . . . . . . . . . . . . . Teclado virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de uma autenticao falhada . . . . . . . . . . . . . 26 27 30 31 35 42 50 53 54 55 56 57 58 59 62 64 65 66

vii

Acrnimos
DS SI GPS Desenvolvimento Sustentvel Sistema de Informao Global Positioning System

VS2008 Visual Studio 2008 DEA Diagrama de Entidade-Associaao

WSDL Web Services Description Language PDA MAC API DC RFID SOA DLL IDE SDK IIS Personal Digital Assistant Media Access Control Application Programming Interface Developed Countries Radio Frequency Identication Service Oriented Architecture Dynamic-link library Integrated Development Environment Software Development Kit Internet Information Services

HTTP Hypertext Transfer Protocol ix

x HTTPS HyperText Transfer Protocol Secure FTP File Transfer Protocol

Acrnimos

SMTP Simple Mail Transfer Protocol NMTP Negotiable Mail Transfer Protocol GUI IA GDI SQL WPF UBI WSE XML IV AES CBC ECB MD5 Graphical User Interface Inteligncia Articial Graphics Device Interface Structured Query Language Windows Presentation Foundation Universidade da Beira Interior Web Services Enhancements Extensible Markup Language Initialization Vector Advanced Encryption Standard Cipher-block Chaining Electronic CodeBook Message-Digest algorithm 5

Captulo 1 Introduo
Objectivo do documento Este relatrio descreve detalhadamente o trabalho desenvolvido para a disciplina de Projecto do curso de Engenharia Informtica na Universidade da Beira Interior. O documento condensa um conjunto de conhecimentos adquiridos e justica as abordagens seguidas na sua implementao. Objectivo do projecto Ao longo do percurso acadmico pretende-se que o aluno adquira diversas competncias que se reectem no desenvolvimento de um projecto sua escolha. Escolha esta que foi previamente construda e desenvolvida em colaborao com o Professor orientador, culminando no objectivo de construir uma plataforma inovadora que permitisse melhorar a experincia de utilizao do utente de transportes pblicos. Este projecto nasceu da combinao de inmeros factores e resultou na participao da nal nacional do concurso da Microsoft (Imagine CUP1 ) que tinha por tema: "Imagina um mundo onde a tecnologia possibilita um ambiente sustentvel"2 . Aprendizagem complementar Para alm deste projecto representar um grande desao na construo de uma ideia que fosse verdadeiramente contributiva ao ambiente, ele
1 2

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

Introduo

surgiu tambm no seguimento da vontade de estudar sistemas ubquos (ver captulo 2). Este tipo de sistemas, apesar de ter uma importncia crescente, no abordado no plano curricular actual do curso. O que por si tambm foi factor decisivo na escolha do projecto e do orientador. A vontade de enriquecer e complementar o conhecimento adquirido insacivel. Equipa Dada a exigncia do desenvolvimento de raz de uma arquitectura to vasta, considerou-se fundamental construir uma equipa capaz de desenvolver um trabalho com impacto suciente para uma participao na nal nacional do Imagine CUP. A equipa que se passou a designar por Ubiquista cou constituda pelos seguintes elementos: Andr Passos, Joaquim Tojal, Joo Oliveira e Joel Carvalho. Cada qual com um conjunto de responsabilidades e tarefas especcas (ver 1.2) providenciando independncia no trabalho. Sendo dois destes alunos do projecto ImagineCup@ubi (Joaquim Tojal e Joel Carvalho) cou-lhes atribudo maior quota de trabalho no projecto global.

1.1

Motivao

Computao Ubqua Este projecto tem uma origem um quanto peculiar comparativamente aos restantes. Da curiosidade e vontade de estudar a computao ubqua conciliada com a abertura do Professor orientador surgiu esta necessidade. Assimilados os conceitos e a losoa, tornou-se a dada altura imperativo pensar num caso de estudo que permitisse enfrentar as diculdades e perigos referidos na literatura (ver captulo 2). Desenvolver uma arquitectura que pretende integrar diversos tipos de dispositivos conciliando diversas formas de utilizao no algo trivial nem pode ser descurado. A privacidade dos dados tem de ser garantida e o sistema deve adaptar-se ao utilizador, nunca o contrrio. Imagine CUP 2008 Uma vez que o desenvolvimento deste projecto focado no enriquec-

1.1 Motivao

imento pessoal dos alunos, em detrimento de produo cientca (mais adequada para Mestrado), torna-se evidente que a participao num concurso uma mais-valia. O Imagine CUP para alm de ser um desao uma janela de oportunidade, quer para promoo pessoal como institucional. Sendo que desde cedo o Imagine CUP fez sentido, especialmente quando a temtica do concurso deste ano foca um assunto que nos preocupa a todos. Est-se claro a falar do ambiente numa vertente em que no se pretendem posies extremistas mas sim pensadas no Desenvolvimento Sustentvel (DS).

SIs ao servio do ambiente O desao de produzir um Sistema de Informao (SI) capaz de contribuir para o ambiente foi uma motivao extra. Mas no foi fcil escolher uma ideia a desenvolver que fosse sucientemente boa e inovadora. Inclusivamente no processo de seleco de ideias foram descartadas uma quantidade substancial delas j que o objectivo da participao no concurso era conseguir-se pelo menos um apuramento para a nal nacional. O problema dos SIs que estes no so de todo a maneira mais intuitiva de colaborar para um melhor ambiente. Mais facilmente se pensa em sistemas electromecnicos, electrotcnicos e energticos para melhorar o ambiente do que em SIs.

Ideias abandonadas Nas ideias que caram para trs destacam-se algumas que at so de algum interesse, no entanto foram consideradas como insucientes ou demasiado bvias. Nomeadamente um sistema ubquo de apoio ao consumidor. A ideia deste sistema consistia em classicar os produtos alimentares disponveis nos supermercados como sendo mais ou menos ecolgicos tendo em conta a sua origem e outras informaes. Outra ideia passava pela implementao de um sistema ubquo de informao e sensibilizao ambiental, no qual se pretendia criar rotas verdes e desviar trfego de zonas com nveis de poluio elevados.

Introduo

1.2

carFree.ubi

Descrio resumida De 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 dos transportes particulares recorrendo a diversas tecnologias presentes no quotidiano. Apesar de actualmente ser na verdade mais confortvel utilizar o veculo particular, isso no quer dizer que os transportes pblicos no possam superar esse conforto. O carFree.ubi pretende at contribuir na melhoria 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 instalado por todos os lugares. O carFree.ubi pretende tambm facilitar a escolha do transporte mais rpido ou econmico com base numa aplicao em Windows Mobile que serve de extenso do sistema de Global Positioning System (GPS) e que fornece informaes em tempo real sobre a rede de transportes pblicos. Pretende-se com isto agitar e alterar a forma como os transportes pblicos so vistos e utilizados. O tempo dispensado nas viagens quer-se produtivo e enriquecedor, coisa que actualmente no se consegue na plenitude recorrendo ao transporte particular. providenciada uma descrio mais detalhada, sobre como o carFree.ubi faz isso tudo, no captulo 3 e seguintes. Impacto dos transportes Para se chegar a esta ideia foi importante estudar um pouco todos os problemas ambientais e perceber qual a abordagem do DS. Dos diversos problemas existentes foi interessante constatar que a utilizao massiva dos transportes pblicos tem vrias consequncias ambientais, sociais e econmicas. Sabendo que o DS construdo sobre estes trs pilares interdependentes e mutuamente sustentadores tornou-se evidente que uma soluo como o carFree.ubi j devia existir h mais tempo. Como prova disso interessante constatar como recentemente a questo do preo dos combustveis veio abanar os transportes. Um estudo americano[2] feito pouco mais de seis meses veio revelar, para alm do impacto directo da poluio, dados impressionantes. Por exemplo foi divulgado que o custo provocado pelos congestionamentos das metrpoles, apenas nos

1.2 carFree.ubi

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 de litros de combustvel perdido.

Vantagens Para alm de tudo o que j se possa imaginar pela argumentao feita at ao momento. A vantagem do carFree.ubi em instrumentalizar uma ferramenta que pode apoiar medidas polticas para a limitao da utilizao dos transportes particulares no interior dos centros urbanos tambm uma 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 transportes particulares continuar a aumentar, mesmo que estes no sejam poluentes, vai chegar-se a um ponto de saturao em que ningum vai fazer distancias curtas em tempos considerados decentes. Muitas cidades europeias j possuem os centros urbanos cortados a trnsito rodovirio excepto transportes pblicos e abastecimento de comrcios. Essa realidade vai fazer parte do futuro de todas as cidades e os transportes pblicos vo ter que se adaptar de modo a servir as necessidades dos utentes. O carFree.ubi enquadra-se perfeitamente numa soluo que consegue suportar melhor essa necessidade, para mais informaes pode consultar documentos referidos na seco contributo.

Diculdades Uma 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 inutilizvel em caso de saturao dos transportes pblicos. Como s existem ecrs tcteis nos assentos, quem ca de p no tem acesso ao sistema. A ideia do 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 plataforma carFree.ubi. Qualquer rede de transportes pblicos que trabalhe para o benefcio dos utentes e queira um sistema como este, de certeza que no vai aceitar que os seus transportes estejam constantemente sobre saturao.

Introduo

Os transportes pblicos, para alm de terem a obrigao de se adaptar s necessidades dos utentes, devem servi-los com a mxima qualidade. Se as transportadoras e os governos querem resolver o problema dos congestionamentos nos grandes centros urbanos s existe uma soluo! No permitir o transito de veculos particulares no centro das cidades. Por conseguinte torna-se necessrio aumentar a frota de transportes e melhorar o incentivo da utilizao dos mesmos. Deciso esta que pode ser sustentada com a plataforma carFree.ubi. Diviso de trabalho Como foi referido anteriormente o carFree.ubi foi desenvolvido por quatro elementos de forma independente, no entanto ligada. A arquitectura do carFree.ubi apresentada no captulo 3, mas em forma de breve anteviso apresenta-se desde j a diviso do trabalho. Andr Passos - Responsvel pelo desenho da interface da aplicao cliente em Windows. Joaquim Tojal - Responsvel por: Desenho da interface da aplicao cliente em Windows Mobile. Desenvolvimento da parte relativa extenso do sistema GPS. Sistema que consiste resumidamente em fornecer rotas alternativas ao transporte particular indicando ao condutor onde estacionar o carro, qual a paragem a tomar para chegar ao seu destino e posteriormente conseguir voltar. Tudo dentro dos horrios que ele pretenda cumprir. Para mais informaes consultar relatrio nmero 54. Joo Oliveira - Responsvel pela componente de inteligncia articial. Joel Carvalho - Responsvel por: Desenho da arquitectura do sistema e da base de dados, bem como a forma como a comunicao entre os clientes e servidor feita. Denio das polticas de segurana e privacidade, incluindo o modo como os utilizadores so identicados pelo sistema,

1.3 Contributo Desenvolvimento da aplicao servidor.

Desenvolvimento de parte da aplicao cliente do Windows no que respeitou o login. Desenvolvimento de parte da aplicao Windows Mobile no que respeitou o registo do utilizador no sistema e congurao de primeira utilizao da aplicao Mobile bem como desenvolvimento de algumas opes como a consulta de horrios, consulta de dados do utilizador entre outros.

1.3

Contributo

carFree.ubi Como contributo principal destaca-se o desenvolvimento da plataforma em si. Desde a ideia at execuo, todo o trabalho foi feito de raiz e o resultado 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. BTLib Para alm do que foi referido anteriormente, ainda foram desenvolvidas duas bibliotecas. Durante o desenvolvimento do carFree.ubi cada um foise deparando com algumas diculdades. Dessas diculdades resultou a necessidade de criao e utilizao de uma biblioteca .NET (desenvolvida em C++) capaz de descobrir dispositivos como Telemveis e Personal Digital Assistant (PDA)s atravs de Bluetooth e recolher o Media Access Control (MAC) Address dos mesmos. Essa necessidade surgiu uma vez que a Application Programming Interface (API) da Microsoft feita em C++ revelou-se muito sensvel a algumas manipulaes (ver captulo 6). Esta biblioteca cou designada por BTLib e encontra-se em processo de avaliao para publicaao na SourceForge3 . CryptoLib A outra biblioteca surgiu da necessidade de facilitar a utilizao da
3

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

Introduo

API criptogrca da Framework .NET, no sentido que a mesma revela-se necessria para algumas partes fundamentais do projecto e considerou-se mais til desenvolver esta biblioteca de forma a ser totalmente reutilizvel quer pela aplicao Windows como Windows Mobile. Mais uma vez trata-se de uma bilbioteca .NET (desenvolvida em FSharp) que cou designada por CryptoLib, sendo que a mesma se encontra em processo de avaliao para publicaao na SourceForge4 .

Documentos Ainda foi necessrio realizar e apresentar alguns documentos5 no mbito do concurso que se decidiu publicar quer para futuros alunos que pretendam participar no Imagine CUP como tambm para divulgao do projecto. Existem tambm referncias feitas na pgina ocial 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.

Cap 2 - Estado de Arte No segundo captulo so introduzidos os princpios e a losoa agregada ao sistema desenvolvido.

Cap 3 - Plataforma carFree.ubi No terceiro captulo descreve-se a plataforma carFree.ubi bem como a anlise de requisitos, as tecnologias e os dispositivos utilizados.
http://sourceforge.net/projects/cryptolib/ http://skydrive.live.com/ 6 http://www.microsoft.com/portugal/presspass/press/2008/mai08/ 05-21imaginecup2008.mspx
5 4

1.4 Organizao do relatrio

Cap 4 - Servidor No quarto captulo aborda-se de forma mais detalhada o trabalho desenvolvido no Servidor onde se inclui a descrio da Base de Dados da plataforma. Cap 5 - Cliente Windows Mobile No quinto captulo apresenta-se e descreve-se a aplicao cliente para Windows Mobile bem como uma biblioteca criptogrca desenvolvida. Cap 6 - Cliente Windows No sexto captulo descreve-se o trabalho desenvolvido no cliente Windows que funciona no interior dos transportes pblicos e uma biblioteca para descoberta de dispositivos bluetooth. Cap 7 - Concluso No ltimo captulo fazem-se as ltimas concluses e naliza-se o relatrio.

Captulo 2 Estado de Arte


Dispositivos computacionais A proliferao massiva de dispositivos com capacidades computacionais tem-se alargado um pouco por todas as reas. Os computadores j no so apenas peas de Hardware volumosas de ter em casa junto da secretria. Qualquer cidado de um pas dito desenvolvido segundo padres consumistas (Developed Countries (DC)[1]) possu pelo menos um dispositivo com capacidades computacionais. Esses dispositivos so actualmente muito diversicados desde PDAs, Telemveis, Smart Cards, Radio Frequency Identication (RFID)s, entre muitos outros. Princpios fundamentais O problema deste aglomerado de dispositivos que, apesar de muitos serem comunicantes cada um funciona no seu pequeno mundo e com as suas regras. Mark Weiser, considerado hoje como o pai da computao ubqua[3], publicou em 1991 e 1993 alguns documentos com citaes inspiradoras[14][12][13][11]. Desses documentos destacam-se citaes como as seguintes: "A good tool is an invisible tool. By invisible, I mean that the tool does not intrude 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 implementing ubiquitous applications."[11] "A well-implemented version of ubiquitous computing could even aord better privacy protection than exists today."[11] "Unlike PDAs, ubiquitious computing envisions a world of fully connected devices, with cheap wireless networks everywhere; unlike PDAs, it postulates that you need not carry anything with you, since information will be accessable everywhere."[12]

Tecnologia Passado uma dcada Mark Weiser comea a ganhar uma importncia fundamental. Anal a sua viso dos computadores estarem em todo o lado e comunicarem essencialmente por redes sem os tornou-se uma realidade. Como exemplo basta pegar nos PDAs. Estes so hoje uma juno dos descritos, na ltima citao de Mark Weiser, no entanto com a integrao de capacidades atribudas aos telefones mveis mais tradicionais e com a grande vantagem de terem acesso a redes sem os. O PDA que Mark Weiser refere em 1993 bem diferente do PDA actual. O actual est incrivelmente mais prximo da viso de sistemas ubquos do que muitos outros dispositivos, mesmo sendo um dispositivo que pode ser transportado.

O Futuro O culminar da losoa apresentada por Mark Weiser, onde todos os dispositivos computacionais passam a servir as populaes de forma invisvel, vai dar-se quando se perder a conscincia completa da tecnologia que se utiliza e se focar meramente na tarefa. Pode imaginar-se que o tal PDA sofre mais uma evoluo e passa a fazer parte dos culos que muitas pessoas usam. As pessoas precisam dos culos para corrigir uma diculdade visual, mas porque no dar-lhe uma funcionalidade extra? Continuando a ccionar, imagine-se que os mesmos recebem instrues vocais que processam e executam aces. Essas aces podem ter um output visual, numa parte da lente dos culos, e um ouput sonoro, produzido por vibraes transmitidas pela armao fazendo chegar o som ao ouvido sem que ningum se aperceba.

2.1 Discusso existente

13

Computao Ubqua No entanto os sistemas ubquos precisam de software, sem ele os dispositivos no passam de meros objectos com funcionalidades prximas de uma pedra. No basta ter as tecnologias, preciso integrar as mesmas e fazer com que elas realmente sirvam a populao. A computao ubqua defendida por Mark Weiser tem um papel importantssimo no desenvolvimento futuro de aplicaes. J chega de desenvolver aplicaes e sistemas sem pensar nas consequncias. preciso defender os interesses e direitos dos utilizadores de modo a que estes realmente gostem, queiram e tenham proveito na utilizao das tecnologias sem sequer pensarem nelas. Cada vez mais a privacidade das pessoas invadida, todos os dias existem milhares de cmaras a vigiar as cidades. Todos os dias deixamos rastos do que fazemos, quando fazemos, como fazemos s falta registas o porqu. Mas anal porque que os sistemas no evoluem de modo a salvaguardar a privacidade das pessoas? Paradigmas A grande diculdade actual encontrada no desenvolvimento de computao ubqua , precisamente, como pratic-la correctamente e com base em que paradigma. Ainda no se pode dizer que exista um modelo rgido que dena como e quando se deve praticar computao ubqua. Isto porque derivaram da computao ubqua diversos paradigmas, nomeadamente o Wearable Computing[8], o Activity-Based Centered Ubiquitous Computing[6], ou ainda o Context Aware Mobile Computing[4].

2.1

Discusso existente

Adam Greeneld[10] um escritor reconhecido a nvel internacional e uma das pessoas que mais tem participado activamente para um debate 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 de preocupaes com as quais se deve ter algum cuidado. Tal como Mark Weiser, Adam Greeneld considera que o desenvolvimento de tais sistemas deve ser cuidado por diversos motivos que vo ser apresentados de seguida.

14

Estado de Arte

Inadvertncia Um deles a inadvertncia dos utilizadores. Imaginando um sistema ubquo que permite difundir a localizao do utilizador para um conjunto limitado de pessoas ou para todas as pessoas. O facto do utilizador poder enganar-se num boto, e em vez de divulgar a sua posio apenas para um conjunto limitado de pessoas o zer para todas, consistiu um risco. Risco esse que pode e deve ser limitado se o desenvolvimento do sistema for devidamente pensado. Desconhecimento Outro factor a ter em considerao o desconhecimento, por parte dos utilizadores, do sistema. Eles podem no saber da existncia do mesmo ou podem no conhecer todas as suas funcionalidades. Consequentemente no sabem que informaes o sistema recolhe, o que feito com essas informaes ou at mesmo quem as guarda e com que objectivo. Apesar de 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. Na verdade pode constituir um problema, porque todos possuem o direito de saber o que feito com os dados que so recolhidos das suas interaces. Rejeio Segundo Adam Greeneld, este o tema mais controverso. O facto de uma pessoa rejeitar a utilizao de um sistema, seja por qual motivo for, deve ser um direito inquestionvel. Ningum deve ser obrigado a utilizar algo que no quer. No entanto nem sempre se aceita esta premissa no desenvolvimento de sistemas ubquos. Muitas vezes parte-se do princpio errado de que todos vo aceitar e querer utilizar o sistema. Existem muitos exemplos de sistemas que no so propriamente ubquos mas obrigam o utilizador a aceitar algo que pode no querer. As cmaras de vigilncia so um exemplo disso. No entanto se for evitvel repetir erros actuais deve-se evoluir para solues que garantam a privacidade das pessoas, j que um direito constitucional. Eplogo O importante a reter actualmente precisamente o perigo que pode advir de um sistema ubquo pouco pensado. A discusso sobre o tema contnua

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 tipo de sistema a computao ubqua s consegue ter o seu sucesso se for centrada nas pessoas. Quer no que elas precisam como nas suas preocupaes. Como exemplo a seguir, se um sistema ubquo regista alguns dados de interaco do utilizador o ideal ser nunca saber ao certo quem o utilizador (ver captulo 3).

2.2

Framework adoptada

Framework .NET A computao ubqua, dada a sua natureza, permanece em desenvolvimento contnuo. Existem no meio acadmico algumas frameworks desenvolvidas e outras em desenvolvimento como o caso do ActivitySpot[9]. Todavia a abordagem adoptada no desenvolvimento do sistema foi orientada pela necessidade de usar as ferramentas da Microsoft uma vez que o concurso Imagine CUP assim o exigia. Paradigma SOA A escolha da Framework .NET levou a que fosse seguida o paradigma Service Oriented Architecture (SOA)[5]. Este paradigma tem a particularidade de permitir a utilizao de Web Services em .NET tal como era exigido para efeitos de concurso e possibilita o desenvolvimento de um sistema que no ca dependente da Framework. Simultaneamente o SOA potencia o 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 apresentado, muitas das ideias presentes neste captulo vo servir de suporte para escolhas tomadas no desenvolvimento do carFree.ubi.

Captulo 3 Plataforma carFree.ubi


Objectivo O carFree.ubi consiste numa plataforma ubqua que interliga uma srie de dispositivos e tecnologias de modo a fornecer ao utente de transportes pblicos informaes e servios considerados teis em qualquer lugar. Tal como foi referido, o objectivo principal do carFree.ubi incentivar a utilizao dos transportes pblicos recorrendo a tecnologias utilizadas massivamente nos dias correntes.

Arquitectura Cliente/Servidor A arquitectura da plataforma baseia-se na arquitectura cliente/servidor comum a muitos sistemas distribudos. Nesta arquitectura incluem-se trs tipos de clientes distintos. Um dos tipos de clientes uma aplicao para Windows Mobile que para alm de possibilitar a consulta de horrios e outras informaes em tempo real, tambm um autntico assistente de viagens para transportes pblicos. Outro cliente uma aplicao Windows que funciona com ecrs tcteis e que permite a consulta de contedos multimdia exclusivos. O ltimo cliente simplesmente uma pgina Web institucional, isto , pode ser simplesmente a pgina Web da empresa que gere os transportes pblicos. Esta arquitectura descrita com maior detalhe na seco 3.4. 17

18

Plataforma carFree.ubi

3.1

Anlise de Requisitos

Antes de se passar a uma maior descrio da plataforma em si, apresenta-se a anlise de requisitos feita. Esta anlise foi realizada avaliando informalmente as necessidades de um conjunto de pessoas de conana. Desta forma foi possvel perceber em que medida um sistema ubquo podia corresponder s suas necessidades mantendo uma certa descrio em toda a fase de desenvolvimento. Esta descrio foi necessria uma vez que se pretendia chegar ao Imagine CUP com uma ideia totalmente distinta e original.

3.1.1

Requisitos funcionais

RF01 - Contedos multimdia Algo que cou imediatamente identicado foi a necessidade de tornar o tempo dispendido dentro dos transportes pblicos de maior qualidade e utilidade. Numa sociedade em constante evoluo os transportes, independentemente do tipo, possuem uma importncia crescente. Pensando e olhando para os utilizadores de transportes pblicos actuais, constata-se facilmente que alguns tentam passar esse tempo ocupando-se. Alguns lem jornais, outros jogam no telemvel, outros telefonam ou falam com amigos, etc. claro que existe sempre quem dedique o tempo da viagem a fazer uma reexo interna e no queira outra soluo. O requisito que aqui ca identicado a necessidade do sistema possibilitar (e no obrigar) aos utentes a consulta de contedos multimdia dentro dos prprios transportes. RF02 - Assistente de viagens Outra questo pertinente e que rapidamente se fez transparecer foi a necessidade de melhorar o conforto e a comodidade dos transportes pblicos. Isto porque, estes dois factores so responsveis por muitos condutores no abdicarem dos seus veculos particulares. Relativamente comodidade, identicou-se como requisito a possibilidade de integrao dum assistente de viagens. Este deve fornecer, de forma simples e intuitiva, alternativas ao percurso a realizar com o veculo particular. Isto , o condutor deixa de se preocupar onde vai estacionar o carro e se as ruas X e Y esto ou no

3.1 Anlise de Requisitos

19

congestionadas. Antes de entrar numa cidade, o condutor utiliza o assistente de viagens de modo a que este lhe indique um local onde estacionar o carro e qual o transporte pblico a seguir para chegar mais facilmente ao seu destino dentro da hora pretendida. RF03 - Contedos adaptveis Relativamente ao conforto identicou-se como requisito a possibilidade de utilizar mtodos de inteligncia articial para ajustar os contedos multimdia ao comportamento do utente. semelhana do que feito em alguns sistemas Web possvel classicar os utilizadores pelo que visualizam. Deste modo, consegue-se sugerir contedos que possam ser do seu interesse. RF04 - Contedos recuperveis Algo que cou assente no seguimento dos requisitos anteriores que torna-se necessrio guardar de alguma forma o estado do ltimo contedo visualizado pelo utente. Isto para permitir que um contedo que tenha cado em aberto seja recuperado no mesmo estado aquando de uma nova sesso por parte daquele utente. RF05 - Agrupamento de utilizadores Os SIs so muitas vezes acusados de fechar as pessoas num mundo parte. Uma vez que este sistema j pretende integrar uma componente de inteligncia articial, surgiu como requisito a possibilidade de tentar criar uma rede de socializao dos utentes. Esta rede que passa a ser designada por rede de amigos tem como objectivo o agrupamento de utilizadores pelos contedos visualizados. RF06 - Informao em qualquer lugar A exigncia da sociedade manifesta-se perante os SIs com a necessidade de ter acesso a qualquer informao em qualquer lugar. No mbito deste sistema, a consequncia dessa exigncia a identicao de um requisito que permita a qualquer utilizador aceder a informaes pertinentes onde quer que esteja. Isto , considera-se til que o utilizador possa aceder s seguintes informaes:

20

Plataforma carFree.ubi 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 institucional Como vem sendo comum em qualquer organizao ou empresa, ca como ultimo requisito a necessidade de associao do sistema a uma pgina institucional. Na qual devem constar, para alm das informaes sobre a empresa gestora da rede de transportes, informaes detalhadas sobre o funcionamento do carFree.ubi e condies de utilizao.

3.1.2

Requisitos no funcionais

RNF01 - Segurana Como cou patente nos requisitos funcionais, necessrio ter utilizadores no sistema. Cada utilizador deve ser identicado por um dos dois conjuntos de pares, password e dispositivo mvel (Telemvel ou PDA) ou password e nmero de registo. Por motivos de segurana a password privada e cifrada. Por motivos de privacidade o identicador do dispositivo, neste caso o MAC Address, tambm cifrado. RNF02 - Privacidade Em 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 identicado pelos dispositivos que utiliza. Apesar de os dispositivos possurem um MAC Address que pblico apenas o prprio utilizador pode fazer a associao entre o MAC Address e o nmero de registo. RNF03 - Portabilidade Apesar de o sistema ser desenvolvido para um concurso com as ferramentas da Microsoft pretende-se como requisito que o mesmo tenha

3.2 Dispositivos

21

alguma portabilidade. Nesse sentido deve utilizar-se o paradigma SOA para possibilitar uma futura utilizao do servidor noutras plataformas que no Windows. RNF04 - Manuteno Um sistema com uma dimenso como este exige que a programao seja feita por partes e com documentao suciente. Neste caso, pelo menos, comentrios aos mtodos e uso de dlls para algumas componentes da aplicao. RNF05 - Usabilidade Qualquer aplicao deve ser feita pensando na forma como o utilizador vai interagir com a mesma e com o meio envolvente. A aplicao para PDA deve ser confortvel na sua utilizao, no exigindo demasiado escrita de texto por parte do utilizador. Por sua vez a aplicao Windows deve ser pensada e realizada considerando que no existe nenhum teclado ao dispor do utente. Portanto a interface deve ser desenhada tendo em conta que o utente tem um ecr tctil sua frente, no qual, caso seja necessrio deve ser utilizado um teclado virtual. RNF06 - Fiabilidade Pela natureza ubqua da aplicao torna-se evidente a indispensabilidade do utilizador ter acesso, em qualquer lado, a uma rede privada sem os ou a uma rede internet sem os. O sistema deve ser visto como um sistema adaptado e enquadrado s cidades mais modernas, que no entanto vo tornar-se comuns em breve.

3.2

Dispositivos

No seguimento dos requisitos foram identicados os dispositivos a utilizar nesta plataforma. De notar que, apesar da escolha feita, outras solues foram avaliadas como por exemplo smartcards sem contacto semelhana dos passes utilizados no Porto. No entanto, e apesar de serem mais seguros, os mesmos no so de fcil acesso. Sendo a plataforma algo complexa e

22

Plataforma carFree.ubi

o tempo de desenvolvimento curto, optou-se por recorrer a equipamentos de acesso mais imediato. Mas numa futura implementao do sistema estas solues no so de desprezar.

3.2.1

Ecrs tcteis

Apesar de no terem sido utilizados, o desenvolvimento da aplicao a correr no interior dos transportes pblicos, foi pensada neste tipo de equipamento. Este tipo de dispositivos ideal para servir de interface num ambiente urbano. Para alm de ocuparem um espao muito limitado permitem uma interaco mais intuitiva. semelhana de muitas tarefas que so realizadas no dia-a-dia com um ecr tctil descarta-se qualquer necessidade de objectos supruos como o rato e o teclado. Este dispositivo enquadra-se nos objectivos dos requisitos RF01 (ver 3.1.1), RF03 (ver 3.1.1), RF04 (ver 3.1.1). Para alm de servir como meio de identicao do utilizador (RFN01, ver 3.1.2) perante os ecrs tcteis existente no interior dos transportes.

3.2.2

PDA com ou sem GPS

Este no um dispositivo muito comum mas a verdade que o seu preo comea a aproximar-se cada vez mais ao dos telemveis. Tendo mais funcionalidades, uma questo de tempo at existir uma fuso dos dois dispositivos ou dos telemveis desaparecerem para apenas sobreviver o PDA. 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 a existncia de GPS integrado ou de um dispositivo GPS externo. Mas apesar de poderem funcionar na mesma aplicao o RF06 e RF02 so independentes.

3.2.3

Telemvel

Uma vez que existe a conscincia de nem todos disporem de PDAs e assim o utilizador j no conseguir ter acesso s funcionalidades prprias da aplicao Mobile. Pretende-se que o mesmo possa pelo menos usufruir

3.3 Tecnologias e Ferramentas

23

dos servios no interior do autocarro. Deste modo o telemvel ou outro dispositivo comunicante bluetooth pode servir como meio de identicao do utilizador (RFN01, ver 3.1.2).

3.3

Tecnologias e Ferramentas

Contextualizao Esta plataforma mexe com mltiplas tcnicas e tecnologias mas nem todas foram introduzidas. De seguida so apresentadas muito brevemente todas as tecnologias que esto de uma ou outra forma integradas na aplicao. VS2008 O Visual Studio 2008 (VS2008) um Integrated Development Environment (IDE) da Microsoft que permite desenvolver aplicaes usando um leque interessante de linguagens para diversas situaes. O VS2008 permite criar bibliotecas, aplicaes para consola ou aplicaes grcas para Windows e Windows Mobile. Atravs deste IDE foi possvel utilizar e integrar linguagens como o C++, CSharp e FSharp no desenvolvimento da plataforma. Windows SDK O Windows Software Development Kit (SDK) rene um conjunto de bibliotecas, APIs e exemplos para desenvolvimento de aplicaes em Windows. Este SDK foi necessrio para o uso da API Bluetooth da Microsoft. Framework .NET 3.5 A Framework .NET uma componente integrante dos sistemas operativos da Microsoft. Esta talvez um dos maiores pontos favorveis ao desenvolvimento de aplicaes em Windows, uma vez que aglomera um conjunto enorme de bibliotecas. Para alm disso, a Framework expansvel e pode ser usada em mltiplas linguagens exibilizando a programao. Compact Framework .NET 3.5 A Compact Framework .NET a verso Framework .NET da Microsoft

24

Plataforma carFree.ubi

para dispositivos mveis e embebidos. Apesar de serem muito semelhantes preciso ter algum cuidado porque nem todas as funcionalidades da Framework .NET existem nesta verso. IIS 6.0 O Internet Information Services (IIS) um servidor Hypertext Transfer Protocol (HTTP) HyperText Transfer Protocol Secure (HTTPS), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) e Negotiable Mail Transfer Protocol (NMTP) que corre em windows. Foi utilizado no projecto como servidor de HTTP de modo a tornar os Web Services criados disponveis pela internet. MS SQL Server 2005 O Microsoft MSQL Server um servidor de Base de Dados para Windows com uma interface de gesto completa. Uma vez que a plataforma necessita de armazenar dados no servidor, a soluo adoptada foi recorrer base de dados da Microsoft. Microsoft Expression Blend 2 Para o desenvolvimento da interface grca da aplicao Windows optou-se por utilizar o Microsoft Expression Blend 2. Este Graphical User Interface (GUI) builder facilita a criao de interfaces ricas para a Web e Windows. Microsoft MapPoint O Microsoft MapPoint tanto uma tecnologia como uma ferramenta e foi utilizado para o desenvolvimento da componente que pretende servir de extenso do GPS. Esta ferramenta permite integrar, editar e visualizar mapas. Ela penas foi utilizada pelo Joaquim Tojal, como tal, maiores referncias e explicaes so feitas no relatrio 54. OpenNetCF A OpenNetCF desenvolveu e disponibilizou uma extenso da Compact Framework .NET da Microsoft. Esta extenso teve de ser usada devido a dois factores fundamentais:

3.4 Arquitectura

25

Em primeiro pelo facto da Compact Framework no incluir os mtodos da Framework .NET para derivao de chaves. Em segundo porque esta foi a soluo mais prtica que se encontrou para conseguir recolher internamente o MAC Address das interfaces de rede do PDA. Eplogo Como possvel constatar todas as ferramentas utilizadas so da Microsoft, no porque fosse considerado que eram as melhores mas porque assim era exigido para efeitos de concurso. No entanto, isso no constituiu nenhuma limitao no desenvolvimento da plataforma, muito pelo contrrio.

3.4

Arquitectura

Finalmente passa-se a apresentar a arquitectura que foi idealizada para esta plataforma ubqua. A arquitectura baseia-se numa arquitectura cliente/servidor e est dividida em mdulos segundo alguns padres de funcionamento.

3.4.1

Servidor

Objectivo No 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 ca parcialmente inutilizvel j que as aplicaes clientes precisam de respostas do servidor. Por exemplo: a aplicao a funcionar no PDA deixa de fazer sentido se no conseguir receber respostas do servidor, no entanto a mesma continua a funcionar sem conseguir fornecer informao ao utilizador. J a aplicao a correr no interior dos transportes pblicos pode continuar a funcionar quase normalmente se tiver uma cache de contedos locais. Esta situao no foi implementada mas pode vir a ser adicionada futuramente. Para uma implementao comercial desta plataforma seria necessrio difundir o servidor por diversos computadores de modo a que se algum falhasse, esse fosse compensado pelos restantes.

26

Plataforma carFree.ubi

Figura 3.1: Esquema da plataforma carFree.ubi

3.4 Arquitectura

27

Figura 3.2: WSDL do Servidor

Sem claro esquecer a redundncia que seria necessria com BackBones e Routers.

Componentes Pelo diagrama 3.1 consegue-se perceber que o servidor possui trs componentes distintas mas interligadas e acessveis por Web Services, so elas a Base de Dados, os WebServives e a Inteligncia Articial (IA). Em momento algum um cliente comunica directamente com a Base de Dados ou com a classe de IA.

Segurana Se 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 abordagem por motivos de segurana. Em momento algum se pretende dar informao mais do que o necessrio a um atacante. Com esta metodologia tudo o que est para alm dos Web Services uma autntica caixa negra para qualquer atacante externo.

28

Plataforma carFree.ubi

Inteligncia Articial Pouco se vai adiantar sobre a parte de inteligncia articial, uma vez que a mesma foi desenvolvida pelo Joo Oliveira. Apenas ca mais uma breve explicao sobre a motivao para esta componente existir na arquitectura. Como cou identicado nos requisitos, considerou-se necessrio ter uma componente que permitisse adaptabilidade por parte da aplicao cliente a correr nos transportes pblicos. Tambm se considerou pertinente classicar os utilizadores pelas suas interaces com a mesma aplicao cliente de modo a proporcionar uma maior socializao dos utentes, caso eles assim o desejem. Com esta componente designada por rede de amigos torna-se muito mais fcil as pessoas carem a conhecer outras com os mesmos gostos.

Base de Dados A Base de Dados pode ser considerada como outra pea nuclear da plataforma e a mesma descrita com maior preciso no captulo 4 j que foi parte integrante do trabalho desenvolvido.

Web Services Os Web Services podem ser vistos na relao Cliente/Servidor como o Front-End do sistema. Tal como foi referido previamente, estes que so responsveis por dar resposta aos pedidos dos clientes sem que os mesmos tenham de se preocupar com a Base de Dados ou com qualquer outra componente. A nica necessidade existente que o servidor HTTP esteja acessvel para o cliente e que tenha todos os servios activos. Parte dos Web Services so descritos com maior detalhe no captulo 4, aqueles que acabaram por ser feitos pelo Joaquim Tojal, devido s suas necessidades, no so apresentados neste relatrio.

3.4.2

Mvel e Carro

Objectivo Estas duas componentes da arquitectura apesar de estarem divididas esto na verdade integradas numa s aplicao. Aplicao que pretende fornecer ao utilizador as seguintes funcionalidades:

3.4 Arquitectura

29

Figura 3.3: Menu principal da aplicao PDA

Assistente de viagens GPS para transportes pblicos como alternativa ao 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 a paragem de origem e destino. Lista de amigos presentes e lugar que ocupam, num determinado transporte pblico em tempo real. Histrico dos contedos visualizados nos transportes pblicos, dada uma data de utilizao e um tipo de contedo. Dados sobre o registo do utilizador no sistema, como a data de registo, o nmero de registo e os MAC Address dos seus dispositivos registados.

30

Plataforma carFree.ubi

Componentes O objectivo da diviso destas duas componentes a de vincar a diferena entre o trabalho do Joaquim Tojal referente ao RF02 (ver 3.1.1) e o que vai ser descrito com maior detalhe no captulo 5 referente ao RF06 (ver 3.1.1). Optou-se por, comodidade do utilizador, juntar tudo numa s aplicao, mas como vai ser possvel vericar a mesma est dividida e funciona de forma independente. Isto , se o PDA no tiver GPS a parte relativa ao RF06 funciona, mas a parte relativa ao RF02 no.

Interface Para se chegar ao resultado apresentado na gura 3.3 bem como no captulo 5 foi necessrio recorrer a um processo de "desenho"de interfaces (GDI) integrado com controlos. Os crditos da pesquisa desta tcnica e do desenho da interface principal vo para o Joaquim Tojal. Apesar de cada um ter feito a sua parte da aplicao era obviamente incompatvel apresentar duas interfaces distintas. Deste modo, o trabalho apresentado no captulo 5 faz uso da tcnica citada.

3.4.3

Transportes Pblicos

Objectivos Tal como cou estabelecido no RF01 (ver 3.1.1), RF03 (ver 3.1.1), RF04 (ver 3.1.1) e RF05 (ver 3.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 contedos multimdia no representa grande inovao, por mais bonita que possa ser a interface. No entanto, o facto de isso ser feito num ecr com qualidade e com uma interface agradvel para o utilizador, conjugado com contedos que no esto disponveis noutro lugar e uma certa adaptabilidade da interface sem dvida uma mais-valia. Uma parte fundamental incidente sobre a disponibilizao de contedos para esta aplicao est relatada no captulo 4 atravs da descrio da Base de Dados. O restante processo, que ainda no foi descrito, incide sobre a identicao do utilizador perante o sistema e ser explicado no captulo 6.

3.4 Arquitectura

31

Figura 3.4: Menu principal da aplicao Windows

Interface Os crditos da pesquisa da tcnica utilizada para desenvolvimento da interface (utilizao do expression blend), bem como o desenho da interface principal vo para o Andr Passos. O trabalho apresentado no captulo 6 sobre a parte referente ao login desta 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 na implementao/reutilizao de uma pgina institucional. Esta pgina pode inclusivamente ser a pgina da empresa que queira utilizar esta plataforma. Infelizmente, devido falta de tempo, ningum acabou por desenvolver esta componente cando a mesma para trabalho futuro.

32

Plataforma carFree.ubi

3.5

Concluso

Neste captulo cou descrito a plataforma carFree.ubi. Como possvel perceber ao longo do captulo as preocupaes foram mais focadas para a arquitectura em si do que para questes sobre a interface devido ao trabalho desenvolvido. Neste tipo de projectos o trabalho apesar de ser independente no pode ser desconexo. Como tal, uns preocuparam-se mais com a interface e outras questes como foi o caso do Joaquim Tojal para a aplicao PDA e do Andr Passos para aplicao Windows enquanto o Joo Oliveira se preocupou com a parte de Inteligncia Articial. Sem o trabalho de todos seria impossvel chegar onde se chegou. At aqui foi descrito o trabalho mais terico realizado no mbito deste projecto. Enquanto nos captulos seguintes ser descrito todo o trabalho prtico desenvolvido.

Captulo 4 Servidor
Servidor Windows Tal como foi referido, o servidor a pea nuclear do sistema. Desde cedo optou-se por congurar e trabalhar directamente com um servidor Windows existente na sala 6.10. Este servidor no foi instalado de raz por motivos de licenas, sendo que o sistema operativo de base foi o Windows XP que j se encontrava instalado na mquina. Foi concedido temporariamente acesso exterior ao porto 80 da mquina uma vez que aquele com que se trabalha para disponibilizao dos Web Services.

Congurao O processo de congurao da mquina passou assim pela instalao do IIS 6.0 e do SQL Server 2005. Para alm da instalao foi necessrio proceder a algumas conguraes de modo a manter um nvel de segurana considerado mnimo. Essas conguraes passaram por limitar o acesso Base de Dados e pgina dos Web Services1 . Para esse efeito foi utilizado uma conta interna na Base de Dados e uma conta do Windows para o IIS. Mais podia ter sido feito em termos de conguraes para tornar o acesso aos Web Services mais seguro (recorrendo ao Web Services Enhancements (WSE) por exemplo) mas o projecto consiste em muito mais do que isto, tendo-se revelado necessrio focar a ateno noutras partes do projecto.
1

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

33

34

Servidor

4.1

Base De Dados

At ao momento ainda no foi especicada a Base de Dados. Todavia isso vai ser feito nesta seco uma vez que o desenho e implementao da mesma integraram-se no trabalho relativo implementao do servidor.

4.1.1

Diagrama

A Base de Dados possui alguma complexidade como possvel vericar na gura 4.1. Para uma melhor compreenso optou-se por dividir a descrio da Base de Dados por componentes.

Processo de desenvolvimento O processo de desenvolvimento da Base de Dados no pode ser considerado tradicional uma vez que o diagrama foi directamente desenhado na ferramenta administrativa do MS! (MS!) SQL Server (Microsoft SQL Server Management Studio Express). Assim, no foi desenhado nenhum Diagrama de Entidade-Associaao (DEA), no entanto de salientar que estes diagramas so algo equivalentes. A ideia foi desenvolver a Base de Dados de forma pensada e calculada recorrendo directamente a uma ferramenta que permitisse posteriormente gerar scripts para criao da BD! (BD!) em MS! SQL Server. Possivelmente at existem outras ferramentas com esta potencialidade, mas esta acabou por ser a que se identicou e explorou primeiro. Tendo-se revelado suciente, para as necessidades e objectivos pretendidos, no se exploraram outras ferramentas.

Vantagens Para alm da gerao de scripts atravs do diagrama, outra grande vantagem de desenhar o diagrama com recurso a esta ferramenta consiste no facto de que quem desenvolve a Base de Dados se pode abstrair totalmente com a apresentao das tabelas. Isto , a ferramenta possibilita tanto um 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.

4.1 Base De Dados

35

Figura 4.1: Diagrama da Base de Dados

36

Servidor

Esclarecimentos Para facilitar a descrio do diagrama introduzem-se alguns esclarecimentos sobre os smbolos presentes. No interior de cada tabela junto a determinados elementos existe um smbolo de chave dourada. Isso signica que os elementos em questo so chave primria da tabela em questo. No caso desta Base Dados os elementos chave podem ser nicos, em pares ou triplos. Relativamente s relaes entre as tabelas, tambm surgem dois smbolos distintos. Uma chave dourada e um smbolo innito que podem aparecer combinados de mltiplas formas. Sempre que surge uma chave numa extremidade e uma chave na outra extremidade, signica que a relao das tabelas de 1 para 1. Sempre que numa extremidade surge uma chave e noutra extremidade um innito, signica 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 Utilizador possui cinco relaes distintas com outras tabelas que vo ser explicadas mais frente. O importante nesta tabela que cada utilizador vai possuir um ID_Utilizador nico que o vai identicar, em algumas situaes este ID designado por nmero de registo de modo a ser mais amigvel para o utilizador do sistema. No existe nesta tabela, ou em outra qualquer, um nico elemento relativo a dados pessoais do utilizador. O sistema, tal como est especicado no RNF02, no precisa de conhecer o nome, morada ou qualquer outro dado pessoal do utilizador. No entanto o ID_Utilizador nunca suciente para validar a identidade do utilizador tal como cou especicado no RNF01, sendo necessrio recorrer a uma pass cifrada tambm ela presente na tabela.

4.1.3

Grupos

Ainda na tabela Utilizador possvel vericar a existncia de um ID_Grupo. Esse ID_Grupo est relacionado com a tabela Grupos, na qual so identicados os grupos de utilizadores reconhecidos pela IA (Tarefa do Joo Oliveira). Assim permite-se que cada utilizador apenas pertena a um grupo, mas que cada grupo tenha vrios utilizadores. De notar tambm

4.1 Base De Dados

37

que, sempre que um Utilizador se regista, o mesmo ca 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 vericar-se a relao de 1 para 1, permitindo que um utilizador no tenha estado e quando tenha apenas possua um. Isto verica-se no acto do registo, quando o utilizador nunca recorreu interface existente no interior dos transportes pblicos e como tal no possui um estado determinado. Este estado serve para permitir que os utilizadores tenham um conjunto de conguraes de interface ao seu dispor. Esta funcionalidade no est patente nos requisitos tendo sido acrescentada posteriormente.

4.1.5

Contedos

Utilizador_Conteudo Outra das relaes feitas com o utilizador tem a ver com os contedos que o mesmo j visualizou. Cada utilizador pode ter visualizado vrios contedos e pode inclusivamente ver o mesmo contedo em instantes diferentes. A partir do momento que um contedo aberto insere-se um registo na tabela Utilizador_Conteudo que vai actualizando o elemento estado at o mesmo sair desse contedo. Esse estado refere-se ao estado propriamente do contedo. Se um livro qual a pgina aberta, se for um vdeo em que minuto do vdeo se encontra e por ai fora. A partir do momento em que um utilizador sai da aplicao e deixa um contedo em aberto o mesmo ca com um estado diferente de zero que posteriormente pode ser recuperado tal como foi especicado no RF04 (ver 3.1.1). Caso um contedo seja encerrado para dar lugar visualizao de outro o estado colocado a 0 no sendo feita mais nenhuma actualizao a esse registo. Conteudo A 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

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 vrios elementos que identicam o contedo. De notar que a tabela embute o contedo em si, no faz nenhuma referncia localizao dos contedos. Isto torna a Base de Dados mais pesada, mas considerou-se que seria a forma mais correcta de proceder. Autor, Genero, Tipo, Editora Todas 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 caractersticas possa estar presente em contedos diferentes. Relativamente ao 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 muito simples. Numa, designada por Dispositivo, adicionam-se os diversos dispositivos registados. Noutra, designada por Utilizador_Dispositivo, estabelece-se a relao entre os utilizadores e os dispositivos. Isto , esta tabela de relao serve para permitir que cada utilizador tenha mais do que um dispositivo. No entanto um utilizador pode no ter um dispositivo associado, bem como a determinada altura, um dispositivo pode ser desvinculado de um utilizador para passar a pertencer a outro ou simplesmente deixar de existir. De notar ainda que, um dispositivo ca identicado pelo seu MAC Address cifrado e combinado com a chave pode servir em determinadas situaes de identicao do utilizador tal como cou especicado no RNF01 (ver 3.1.2) e RNF02 (ver 3.1.2).

4.1.7

Transportes

A componente dos transportes, tal como as restantes, tambm se relaciona com o utilizador tendo como facto de que se pretende saber se um utilizador est presente num transporte ou no. Assim a tabela de

4.1 Base De Dados

39

relao Utilizador_Transporte permite que um utilizador esteja num qualquer transporte ocupando um determinado lugar, como pode no estar em nenhum. De notar ainda que cada transporte possui um tipo, por exemplo autocarro, metro, etc., e que cada tipo pode ter vrios transportes. Para alm de um transporte ter um nome, uma matrcula, o nmero de lugares, o mesmo possui uma latitude e longitude que se quer actualizada medida que o transporte se move.

Rotas Outra parte importante na relao dos transportes o facto dos mesmos terem horrios, isto rotas. Esta parte talvez a mais complexa da Base de Dados e decidiu-se para simplicar a mesma que cada circuito de um dado transporte, feito a uma dada hora, consiste numa rota que pode ser feita em diversos dias. Assim uma rota consiste num conjunto de paragens pela qual o transporte passa a uma determinada hora prevista. Cada transporte pode ter diversas rotas e uma rota pode ser feita por diversos transportes, tendo em considerao que num dia apenas um transporte pode fazer essa rota. No de um transporte fazer um percurso em contnuo durante o dia 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 pelo tipo de dados armazenados na tabela Paragem. Deste modo uma paragem possui um tipo que pode ser de paragem ou estacionamento. Esta paragem deve ser vista como um ponto de paragem possvel para um utilizador do sistema. Assim sendo, um utilizador pode parar numa paragem de um transporte como pode parar num estacionamento onde deixa o carro. No caso de ser efectivamente uma paragem de um transporte a mesma possui relaes com as rotas dos transportes, no caso de a paragem ser um estacionamento ento esta vai possuir um preo.

40

Servidor

4.2

Privacidade e Segurana

Base de Dados Como foi dito anteriormente, o acesso Base de Dados limitado a um determinado utilizador. Qualquer pedido Base de Dados tem de ser feito 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 Base de Dados nunca ser feito directamente por uma aplicao cliente. Isto evita que um atacante tenha conhecimento sobre a estrutura da Base de Dados e que sobre efeito de alguma tcnica consiga injectar SQL para extrair ainda mais informaes. Dados cifrados Como foi possvel perceber noutros pontos do relatrio existem dados cifrados na Base de Dados, nomeadamente as passwords dos utilizadores e os MAC Address dos dispositivos. No captulo 5 faz-se uma descrio detalhada de como esses dados so cifrados. De momento o importante o motivo para a existncia desses dados cifrados. Qualquer pessoa que escute comunicaes no cifradas vai conseguir interceptar e tratar os dados passados na comunicao. Password cifrada Se a password no estiver cifrada basta ao atacante descobrir qual o MAC Address do utilizador juntamente com a password no cifrada, emular esse MAC Address e assim conseguir identicar-se nos ecrs tcteis como sendo algum que no . O perigo disso que um atacante pode conseguir sem autorizao perceber quais so os gostos de uma outra pessoa, coisa que do ponto de vista dos sistemas ubquos totalmente indesejvel. MAC Address cifrado J o MAC Address cifrado por um motivo ligeiramente diferente. Hoje em dia cona-se demasiado nas empresas que possuem a informao, mas alguma informao no deve ser totalmente conada. Do ponto de vista das redes tanto existem perigos de ataque de pontos externos rede como de pontos internos. Inclusivamente os internos at so mais perigosos do que os externos. Imaginando que o MAC Address no era cifrado,

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 estes dados, um administrador consegue na mesma recolher muita informao sobre um determinado utilizador no entanto nunca vai conseguir associar o utilizador a um dispositivo.

IIS Tal como acontece com a Base de Dados o servidor de Web Services est limitado a quem tenha as credencias de autenticao. Isto impossibilita que os Web Services desenvolvidos no projecto sejam utilizados por terceiros sem a devida autorizao. Limita-se com isto, a possibilidade de atacantes desenvolverem cdigo que invoque os Web Services para extrair informao de forma automatizada.

Eplogo A segurana um tema que despertou interesse e representou mais um desao na realizao deste projecto, no entanto no apresentada aqui nenhuma soluo milagrosa. Acredita-se que mais cedo ou mais tarde seja possvel contornar as barreiras implementadas. Sendo que, considera-se necessrio recorrer a uma avaliao externa para apurar at que ponto as medidas so ou no ecientes. Apesar de tudo as medidas no foram implementadas em vo, existe uma forte convico sobre as mesmas terem a sua ecincia, apesar de possivelmente existirem falhas que at ao momento no foram detectadas.

4.3

Mtodos e Classes

Em termos de desenvolvimento convm esclarecer que os mtodos apresentados de seguida no foram realizados pela sequncia apresentada no relatrio. Isto , apesar de o servidor ter uma importncia signicativa e estar apresentado em primeiro no relatrio na verdade os mtodos foram desenvolvidos medida que se foram tornando necessrios.

42

Servidor

Figura 4.2: Diagrama do VS2008 do Servidor

4.3.1

Diagrama do Visual Studio

Na gura 4.2 apresenta-se o diagrama das classes e mtodos automaticamente gerado pelo Visual Studio. De notar a presena de uma Classe IA desenvolvida pelo Joo Oliveira, como tal no so apresentados nem mtodos nem maiores explicaes sobre a mesma. O diagrama s contempla mtodos desenvolvidos na realizao deste projecto para evitar qualquer tipo de confuso sobre a autoria dos mesmos. Outros mtodos foram usados para o funcionamento de partes de trabalho desenvolvidas pelos restantes elementos, mas os mesmos no se encontram aqui listados.

4.3.2

Classe: Com

Os Web Services so, como referido anteriormente, o que vai transparecer para fora do servidor. Eles so como uma ponte entre todas as componentes do servidor e as aplicaes cliente, pelo que todos os mtodos presentes na classe Com (do tipo Web Service) so do tipo Web Method.

4.3 Mtodos e Classes

43

connect O mtodo connect existe no mbito do projecto para testes. Este mtodo basicamente estabelece a ligao entre o cliente e o servidor devolvendo um valor booleano, sem receber qualquer tipo de argumentos. userVal Este mtodo recebe um nmero de registo e uma password cifrada de modo a devolver um valor booleano indicando se existe ou no um utilizador com tal correspondncia. userVal2 Semelhante ao mtodo anterior mas desta vez para validar um par diferente. Mais precisamente o MAC Adress j cifrado com uma password cifrada. userLastTravel Mtodo responsvel por devolver uma string devidamente formatada correspondente data em que um determinado utilizador viajou num transporte pblico. H que ter em conta que, para que seja possvel saber quando foi a ultima vez que um determinado utente viajou num transporte, implica necessariamente que este tenha interagido com os ecrs tcteis do sistema. Por outras palavras, o mtodo devolve a data da ltima interaco com o sistema presente no interior dos transportes pblicos. userAdd Mtodo que permite, recebendo uma password cifrada, adicionar um novo utilizador ao sistema. O valor devolvido por este mtodo um inteiro que corresponde ao nmero de registo do utilizador. transportationsType Este mtodo j difere um pouco dos anteriores uma vez que necessita de devolver uma lista de dados. O mtodo em si devolve a lista de todos os tipos de transportes. Para isso devolve o resultado em XmlDataDocument. Integrado com o cabealho Extensible Markup Language (XML) gerado automaticamente pelo Web Service o que o mtodo faz preencher

44

Servidor

o XML com os dados de interesse. Esta tcnica foi seguida sempre que houve necessidade de trabalhar com tipos de dados mais sosticados do que um inteiro, uma string ou um booleano. Isto permite tornar os mtodos compatveis com diversas linguagens j que devolvem um XML que consegue ser lido independentemente da plataforma tal como se pretendia no RNF03 (ver 3.1.2).

stationsList Mtodo que devolve em XML todas as paragens de um determinado tipo de transporte.

contentsType Mtodo que devolve em XML a lista de todos os tipos de contedos existentes.

contentsDateList Mtodo que lista em XML todas 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 mtodo so apenas as datas com dia, ms e ano em que o utilizador recorreu ao sistema.

transportationsList Mtodo que devolve em XML a lista de todos os transportes de um determinado tipo. Isto , dado o nome de um tipo de transporte listado o nome dos transportes desse mesmo tipo.

userData Este mtodo recebe o nmero de registo de um utilizador e devolve em XML alguns dados sobre esse registo, nomeadamente a data em que o utilizador se registou e o grupo a que pertence.

4.3 Mtodos e Classes

45

devicesList Mtodo responsvel por devolver a lista dos dispositivos de um determinado utilizador. De notar que os MAC Address devolvidos esto cifrados, cando responsabilidade da aplicao cliente pedir a password ao utilizador de modo a conseguir decifrar os dados. friendsIn Mtodo que dado um nmero de registo e o nome de um transporte devolve a lista dos amigos presentes nesse transporte. Relembra-se que os amigos so as pessoas que foram classicadas como sendo do mesmo grupo. contentsViewed Este mtodo devolve a lista dos contedos visualizados por um utilizador num determinado dia e de um dado tipo. Mais uma vez, o mtodo recebe o nmero de registo do utilizador, o nome do tipo e a data devidamente formatada, sendo que devolve, como nos restantes casos, o XML com a lista. stationsStart Mtodo responsvel por devolver as possveis paragens de origem com ligao a uma paragem de destino. Consegue-se fazer a diferena entre uma paragem de origem ou destino consoante a hora em que est previsto o transporte passar nas mesmas. stationsEnd Mtodo semelhante ao anterior, mas desta vez para uma paragem de origem o mtodo devolve a lista das possveis paragens de destino. transportationsList2 Mtodo 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 uma paragem de destino. Para posteriormente devolver a lista dos possveis transportes que contemplem os requisitos introduzidos.

46

Servidor

4.3.3

Classe: LigacaoBD

Esta classe que na verdade implementa todas as chamadas Base de Dados necessrias. Assim optou-se, sempre que necessrio, por duplicar os nomes dos mtodos da classe Com, para a classe LigacaoBD, de modo a estes serem invocados pelos Web Services. Esta abordagem foi seguida quer por motivos de organizao como de estruturao do cdigo desenvolvido. De notar ainda que em cada mtodo aberta e fechada uma ligao Base de Dados. Uma vez que j se sabe, da seco anterior, o que cada mtodo deve fazer apenas basta acrescentar umas ligeiras informaes. Nomeadamente, de referir que em muitos casos a query a ser processada pela Base de Dados gera o XML automaticamente. Isso faz-se adicionando se seguinte instruo "FOR XML PATH (Elemento), root(Utilizador)" no m de cada query.

De seguida listam-se todos os mtodos que invocaram directamente querys Base de Dados. userVal userVal2 userLastTravel transportationsType stationsList contentsType contentsDateList transportationsList userData devicesList

4.4 Concluso

47

Por m 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 considerao no desenvolvimento do servidor, nomeadamente as preocupaes ao nvel de segurana no armazenamento e na comunicao dos dados. Foi tambm apresentada a estrutura quer da Base de Dados como do Servidor e por m a forma como os Web Services ligam todas as componentes presentes no servidor. No captulo seguinte ser descrito o trabalho desenvolvido na aplicao cliente a correr em Windows Mobile, isto o cliente para PDA.

Captulo 5 Cliente Windows Mobile


Tal como foi referido anteriormente esta aplicao possui duas componentes distintas. Numa a aplicao pretende servir de assistente de viagens para condutores de veculos particulares, para mais informaes consultar projecto 54. Na outra, aqui descrita, a aplicao pretende fornecer informaes consideradas pertinentes. No entanto, antes sequer de a aplicao ser lanada em modo de funcionamento normal preciso passar por um processo de registo. Tudo isto vai ser descrito neste captulo com maior detalhe. Processo de desenvolvimento O processo de desenvolvimento foi baseado nos requisitos apresentados e na documentao produzida de forma informal. Nessa documentao informal consta, alguns uxogramas, story boards da interface, cenrios de interaco e outros apontamentos. Diagrama do Visual Studio Para efeito informativo apresenta-se na gura 5.1 o 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 vez que muitos esto relacionados com aces de botes e questes relativas ao ambiente grco. A abordagem vai ser mais demonstrativa e explicativa at porque, ao contrrio do servidor, nesta aplicao pode-se recorrer s imagens da interface. 49

50

Cliente Windows Mobile

Figura 5.1: Diagrama do VS2008 da aplicao Windows Mobile

5.1 Registo/Login

51

5.1

Registo/Login

Comeando pelo mais importante tendo em conta que o registo/login da aplicao representa um aspecto bastante ponderado por motivos de segurana. Surgiram vrias abordagens possveis para esta tarefa. Todavia a que acabou por parecer mais eciente e segura consiste em armazenar e usar o nmero de registo do utilizador directamente no registo do Windows.

Registo do Windows Inicialmente tinha-se pensado em recorrer a um cheiro no qual se colocaria o nmero de registo cifrado. Nesse processo o nmero de registo era cifrado e decifrado derivando a chave de um MAC Address do dispositivo. No entanto rapidamente se encontraram falhas a esta implementao. Para comear o cheiro podia facilmente ser copiado de PDA para PDA bastando a um atacante conhecer e conseguir emular os MAC address. Sem excluir a possibilidade de inadvertidamente o cheiro poder ser apagado. Sendo que decidiu-se usar precisamente o mesmo processo mas guardando o nmero de registo cifrado no prprio registo do Windows.

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

5.1.1

CryptoLib

Para proceder cifragem e decifragem, quer nesta aplicao como na aplicao que vai ser apresentada no captulo seguinte, optou-se por criar uma biblioteca criptogrca com mtodos para cifrar e decifrar com toda a comodidade. Esta biblioteca foi desenvolvida em FSharp e baseia-se na biblioteca criptogrca do .NET.

52

Cliente Windows Mobile

Objectivo Optou-se por criar uma biblioteca auxiliar porque cada vez que se pretende instanciar algum objecto da classe criptogrca do .NET para cifrar ou decifrar necessrio manipular streams entre outras coisas. Com esta biblioteca auxiliar facilita-se todo o processo. Basta instanciar a classe e de seguida chamar o mtodo adequado para cifrar ou decifrar fornecendolhe o texto a cifrar ou o array de byte a decifrar, a chave e o Initialization Vector (IV) caso necessrio. A classe criada possui vrios mtodos para permitir cifrar em vrios modos recorrendo a duas cifras distintas.

AES-ECB Uma das cifras o Advanced Encryption Standard (AES) em modo Cipher-block Chaining (CBC) ou Electronic CodeBook (ECB). O modo ECB tem a grande desvantagem de no esconder padres quando as mensagens a cifrar so grandes. No entanto como aqui no o caso esse problema no se verica. Este modo no requer IV e utilizado para cifrar e decifrar o nmero de registo do utilizador na aplicao do PDA. De notar ainda que com este modo utilizado um padding aleatrio que faz com que um texto cifrado vrias vezes com a mesma chave s resulte num criptograma idntico se o padding aleatrio se repetir.

AES-CBC O modo CBC por sua vez permite esconder padres e requer a utilizao de um IV. Para alm de, ao contrrio do modo ECB, no necessitar de padding aleatrio para cifrar a mesma mensagem com a mesma chave diversas vezes e obter criptogramas distintos. Este modo acaba por ser mais seguro que o anterior, no entanto o anterior bem suciente em algumas situaes. No caso de cifrar e decifrar o MAC Address, o modo ECB j no assim to suciente. Para alm do MAC Address originar dois blocos, logo a necessidade de esconder padres, o facto do IV variar uma mais-valia para esta situao. O modo CBC assim utilizado para cifrar e decifrar os MAC Address dos dispositivos.

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

5.1 Registo/Login

53

algum tempo, ela continua a ser vivel com algumas alteraes, nomeadamente com a introduo de Salt. O MD5 ao contrrio do AES uma cifra One-Way, ou seja irreversvel, no entanto devido descoberta de colises passou a ser possvel explorar o MD5. Inclusivamente possvel encontrar Rainbow-Tables, tabelas que permitem obter o texto plano atravs do criptograma, do MD5. No entanto, essas tabelas de nada servem quando adicionado um salt ao texto a cifrar. Se o salt for xo ainda existem algumas possibilidades de tentar explorar a falha do MD5, mas variando o salt o processo torna-se impossvel (at ao momento). Deste modo o MD5 utilizado para cifrar e decifrar as passwords dos utilizadores recorrendo a um salt que varia de utilizador para utilizador. Na verdade o Salt usado neste caso mais uma derivao da chave.

5.1.2

Passos do Processo

Arranque da aplicao Dito isto pode-se nalmente descrever por completo o processo de registo/login. Quando a aplicao executada o primeiro passo consiste em vericar a existncia do nmero de registo do utilizador no registo do Windows. Se este existir feito o processo de arranque do menu principal sem sequer se decifrar o nmero de registo, todavia o login ca virtualmente feito. Decifrar o nmero de registo Sempre que a aplicao necessitar do nmero de registo do utilizador ela passa a ler o valor cifrado do registo do Windows. Posteriormente decifra o valor lido utilizando a cifra AES em modo ECB com chave derivada de um dos MAC Address do PDA. O MAC Address escolhido lendo sequencialmente as interfaces de rede do dispositivo e extraindo o MAC Address da primeira interface identicada como sendo do tipo Ethernet ou WiFi. De notar que quer a leitura dos MAC Address como a derivao de chaves em Compact Framework s possvel graas utilizao da biblioteca OpenNetCF citada no captulo 3. Menu 1 No caso do registo do Windows no conter o nmero de registo do uti-

54

Cliente Windows Mobile

Figura 5.2: Menu principal da aplicao Windows Mobile

lizador ento surge um primeiro menu de boas vindas interrogando o utilizador quanto ao seu estado de registo. Se o utilizador j estiver registado segue para um menu de login, se no segue para um menu de registo. Menu Registo No menu de registo solicitada uma password ao utilizador que deve ser repetida para conrmao. Se as mesmas forem idnticas e diferentes de uma password vazia ento a aplicao cliente cifra a password recorrendo cifra MD5 com salt derivado da prpria password. Essa password enviada para o Web Service que devolve o nmero de registo do utilizador criado. Esse nmero cifrado usando a cifra AES em modo ECB com chave derivada de um MAC Address do dispositivo, tal como foi explicado anteriormente. Assim que o valor est cifrado o mesmo adicionado ao registo e a aplicao lanada normalmente para o menu principal. Menu Login No menu de login o utilizador tem de fornecer a sua password e o prprio nmero de registo. A password cifrada, pelo processo j explicado, e

5.1 Registo/Login

55

Figura 5.3: Menu 1 da aplicao Windows Mobile

Figura 5.4: Menu de login da aplicao Windows Mobile

56

Cliente Windows Mobile

enviada juntamente com o nmero de registo para um Web Service. Se existir uma correspondncia ento a aplicao cifra o nmero de registo e armazena-o no registo do Windows, tal como no menu anterior. Assim que esse processo completado a aplicao inicia normalmente para o menu principal.

5.2

Horrios

A opo dos horrios permite ter acesso lista dos transportes e dos seus horrios tendo em considerao trs dados relevantes. O primeiro o tipo de transporte desejado, o segundo a paragem de origem e o terceiro a paragem de destino. Este menu foi feito de maneira a que inicialmente no sejam listadas paragens de destino ou de origem. Essas paragens s so listadas assim que o tipo de transporte seleccionado. Primeiro passo Aps seleco do tipo de transporte so listadas todas as paragens relacionadas com esse tipo de transporte quer nas paragens de origem como destino. Assim neste primeiro passo no existe uma distino entre paragens de origem ou de destino uma vez que todas as listadas so provveis paragens de destino ou de origem. Segundo passo Ao seleccionar uma das paragens no destino ou na origem a lista oposta actualizada com paragens que tenham a relao pretendida com a seleccionada. Por exemplo se for seleccionada uma determinada paragem de origem a aplicao cliente recebe do servidor a lista das possveis paragens de destino e vice-versa. Terceiro passo O terceiro, e ltimo passo, consiste em seleccionar a outra paragem. A aplicao verica se as listas possuem todas valores seleccionados e passa a listar os horrios respectivos tendo em considerao a hora actual. Assim apenas so listados horrios a partir da hora actual e nunca horrios que j passaram.

5.3 Amigos

57

Figura 5.5: Menu horrios da aplicao Windows Mobile

5.3

Amigos

Na opo dos amigos o utilizador pode consultar a lista dos amigos presentes num determinado transporte. Mais uma vez, primeiro preciso seleccionar o tipo de transporte aps isso a lista dos transportes actualizada e basta ao utilizador escolher um dos transportes para saber em que lugares do transporte vo os seus amigos. Isto claro se existirem utentes dentro desse transporte pertencentes ao mesmo grupo que o dono do PDA.

5.4

Histrico

O histrico permite ao utilizador recuperar os nomes de alguns contedos visualizados nas suas interaces com a aplicao a correr no interior dos transportes pblicos. O funcionamento do menu bastante simples bastando ao utilizador seleccionar qual o tipo de contedo que pretende visualizar e qual a data de utilizao para de seguida lhe ser apresentada a lista com a informao desejada.

58

Cliente Windows Mobile

Figura 5.6: Menu amigos da aplicao Windows Mobile

Figura 5.7: Menu histrico da aplicao Windows Mobile

5.5 Mobile Info

59

Figura 5.8: Menu Mobile Info da aplicao Windows Mobile

5.5

Mobile Info

Por m, mas no menos importante, o menu de informao sobre o registo do utilizador. Este menu acaba por ser o nico dos menus, exceptuando o registo/login, que requer a introduo da password. Como foi previamente explicado os MAC Address so guardados na Base de Dados de forma cifrada. Uma vez que quer o IV como a chave usada, para cifrar e decifrar o MAC Address, so derivadas da password do utilizador torna-se necessrio pedir a mesma. de realar o facto da password apenas ser necessria para a apresentao da lista dos MAC Address registados. A restante informao aparece assim que o menu aberto, sem qualquer necessidade de introduo da password.

5.6

Concluso

Este captulo descreveu o trabalho desenvolvido na aplicao cliente para Windows Mobile. Nesse trabalho consta a descrio de todo o processo

60

Cliente Windows Mobile

de registo/login do utilizador aquando de uma primeira utilizao da aplicao, contemplando o RNF01 (ver 3.1.2) e o RNF06 (ver 3.1.2). Bem como a descrio dos restantes menus seguindo o RF06 (ver 3.1.1). A aplicao foi testada e demonstrou-se estvel. Inclusivamente foi possvel validar o correcto tratamento de diversas excepes. No captulo seguinte passa-se a descrever a outra aplicao cliente, desta vez para Windows.

Captulo 6 Cliente Windows


Descreve-se neste captulo a aplicao a funcionar no interior dos transportes pblicos. Cada utente tem sua disposio um ecr tctil a partir do qual consegue interagir com a interface da aplicao. Esta foi pensada e desenvolvida tendo em ateno o facto de no existir teclado ou rato disposio do utente tal como cou patente no requisito RNF05 (ver 3.1.2). O trabalho realizado foca-se apenas na primeira parte do funcionamento da aplicao. Isto , na parte de reconhecimento e autenticao dos utilizadores.

Processo de desenvolvimento semelhana do que aconteceu com o desenvolvimento da aplicao para Windows Mobile o trabalho desenvolvido nesta aplicao foi feito com base em documentos informais e nos requisitos. Destaca-se ainda o facto de inicialmente no ter sido previsto o desenvolvimento da interface recorrendo ao Expression Blend como tal at foram desenvolvidas parcialmente duas verses desta aplicao. Uma baseada em forms do Windows mais tradicionais e outra aqui apresentada com uma interface muito mais apelativa.

Diagrama do Visual Studio Tal como foi feito no captulo 4 e 5, apresenta-se na gura 6.1 o diagrama com as classes e mtodos desenvolvidos. Como muitos mtodos esto 61

62

Cliente Windows

Figura 6.1: Diagrama do VS2008 da aplicaao Windows

relacionados com aces de botes e questes relativas ao ambiente grco os mesmos no vo ser descritos exaustivamente.

6.1

BTLib

Antes de se descrever o menu de login propriamente dito, convm referir a biblioteca que serviu de apoio no processo. A biblioteca baseia-se na API bluetooth feita em C++ do Windows SDK. Acontece que essa API revelou-se bastante instvel, alm de no permitir chamadas directamente do CSharp usando as funcionalidades do .NET. Motivao O uso da API e o desenvolvimento de uma biblioteca de apoio foi

6.2 Login

63

necessrio por se ter considerado que os utilizadores de dispositivos mveis (PDA, Telemvel), com bluetooth, deviam utilizar o mesmo como uma espcie de chave. Todo o processo de login podia ser feito esquecendo o dispositivo. Bastava usar o nmero de registo juntamente com a password e o utente entrava no sistema. Mas parte da segurana pretendida perdiase uma vez que o utilizador deixava de necessitar de um objecto que o identicasse.

Biblioteca A biblioteca BTLib justica-se de forma a juntar numa nica DLL todo o cdigo C++ necessrio para descoberta de dispositivos bluetooth e recolha dos seus MAC Address. Apesar do cdigo desta biblioteca ser diminuto o desenvolvimento do mesmo necessitou algum esforo para car funcional. As falhas da API da Microsoft resumem-se quantidade de problemas que surgem com ligeiras alteraes no cdigo e fraca documentao existente. Limitando o uso da biblioteca numa DLL em C++, com mtodos capazes de serem invocados pela Framework .Net, consegue-se controlar o ambiente de funcionamento da API. Esta DLL ca assim facilmente importvel para qualquer projecto do Visual Studio e com duas ou trs linhas de cdigo consegue-se fazer a descoberta de dispositivos.

6.2

Login

O menu de login bastante simples e intuitivo de utilizar. Do ponto de vista do utente dos transportes pblicos basta que o seu dispositivo tenha o bluetooth ligado e visvel a todos para que o mesmo seja listado na interface. De seguida s lhe resta seleccionar o nome do seu dispositivo, introduzir a password utilizando o teclado virtual e premir o boto entrar.

Actualizao de dispositivos Do ponto de vista da aplicao o que na realidade acontece que a todo o momento existe uma thread responsvel por actualizar a lista de dispositivos encontrados. Sempre que essa pesquisa terminada a lista dos dispositivos, que surge na interface, actualiza (ver gura 6.2).

64

Cliente Windows

Figura 6.2: Lista de dispositivos

Teclado Virtual Por sua vez o teclado virtual s activado quando um utente selecciona o nome de um dispositivo presente na lista. O teclado permite ao utente introduzir a sua password podendo a qualquer momento mudar o mesmo de posio ou at fecha-lo. De notar que o teclado volta a ser aberto se for seleccionado novamente o nome do dispositivo. No entanto se for seleccionado outro nome a password ca vazia.

Entrar Assim que o utente tiver introduzido a sua password s lhe resta premir o boto para entrar. Nesta fase o MAC Address do dispositivo seleccionado cifrado usando a cifra AES em modo CBC e a password cifrada com MD5 e salt. Este processo feito de forma anloga ao descrito para a aplicao Windows Mobile, recorrendo tambm biblioteca criptogrca apresentada no captulo anterior. Por m os dados so enviados ao servidor que ter a responsabilidade de os validar ou no. Se forem validados o utilizador passa a ter acesso ao menu principal, caso contrrio a password ca vazia e o utilizador informado que os dados no esto correctos (ver gura 6.4).

6.2 Login

65

Figura 6.3: Teclado virtual

Figura 6.4: Exemplo de uma autenticao falhada

66

Cliente Windows

Entrar Annimo Existe ainda a possibilidade de qualquer utente entrar no sistema de forma annima, no entanto este modo de utilizao limitado. Sair Quando um utente decide sair da aplicao basta-lhe premir o boto sair e automaticamente o menu de login activado. Voltando ao menu de login a password ca vazia para evitar que enquanto o dispositivo se encontre em alcance algum consiga entrar no sistema usando as credenciais do utente anterior

6.3

Concluso

Neste captulo apresentou-se o trabalho desenvolvido para a aplicao Windows. As duas aplicaes cliente combinadas com o servidor representam o ponto forte desta plataforma ubqua. Todas as aplicaes apresentadas foram devidamente testadas e esto funcionais como constatvel pelas imagens. No captulo seguinte naliza-se o relatrio e apresentam-se as ltimas concluses.

Captulo 7 Concluso
Implementao de uma plataforma inovadora Tal como est referido na proposta do projecto, este pretende "implementar uma plataforma inovadora que permite melhorar a experincia de utilizao do utente de transportes pblicos". Resta dizer que o objectivo principal de implementar tal plataforma cou cumprido semelhana dos restantes objectivos.

Desenho e implementao A parte do projecto que constava realizar de forma independente consistiu em desenhar e implementar a plataforma de comunicao mvel e disponibilizao de contedos. Por outras palavras, o ncleo da arquitectura do carFree.ubi que pode ser consultado no captulo 3, bem como o trabalho apresentado nos captulos 4, 5 e 6.

Plano de trabalho No plano de trabalho constavam quatro tpicos que foram todos cumpridos. Relativamente anlise de requisitos a mesma pode ser consultada no captulo 3, enquanto a denio da estrutura do programa a desenvolver juntamente com a descrio da implementao e testes esto concentrados nos captulos 4, 5 e 6. Como possvel constatar pela estrutura do relatrio ainda foram feitos alguns estudos tericos sobre tecnologias e paradigmas. 67

68

Concluso

Desao Este projecto representou um desao muito aliciante devido necessidade de aplicar um conjunto bastante largo de conhecimentos adquiridos ao longo do curso e pela possibilidade de desenvolver outros, como a computao ubqua. Sendo este um curso de Engenharia Informtica, um projecto como este tudo o que qualquer um podia desejar. Para alm do projecto ter tido uma componente de instalao e congurao de sistemas, permitiu apurar conhecimentos sobre programao para .NET 3.5, CSharp, FSharp, SQL, ADO .NET, Web Services, Windows Presentation Foundation (WPF), Drawing de interfaces e dispositivos mveis. Contemplando parte de matrias de disciplinas como Base de Dados, Programao Orientada a Objectos, Sistemas Operativos, Redes, Engenharia de Software, Interaco Humana Com o Computador, Sistemas Distribudos, Segurana Informtica, Compiladores, Organizao e Gesto de Empresas e ainda Aspectos Prossionais da Informtica. Diculdades Como em qualquer projecto existiram obviamente muitas diculdades na implementao da plataforma idealizada. Neste momento difcil enumera-las todas, no entanto destaca-se o facto de o projecto ter um perodo de desenvolvimento curto (cerca de quatro meses com relatrio). Algumas opes tiveram de ser tomadas rapidamente e nem sempre foi feita a devida ponderao. O importante que todas as diculdades foram superadas. Desde a questo de lidar com dispositivos bluetooth usando uma API pouco estvel, passando pelas falhas de segurana detectadas e corrigidas ao longo da implementao. Como pela necessidade de lidar com tecnologias com as quais apenas se est familiarizado de nome e s vezes nem isso. Por m preciso no esquecer que a disciplina de projecto teve de ser combinada com outras disciplinas, o que limitou um pouco o espao evolutivo da plataforma.

7.1

Resultados

Participao na nal nacional do Imagine CUP 2008 O resultado mais evidente da realizao deste projecto a prpria plataforma. Em segundo plano ca a participao e apuramento para

7.2 Trabalho Futuro

69

a nal nacional do Imagine CUP em representao da Universidade da Beira Interior (UBI). A nal deste concurso decorreu em Lisboa na Culturgest dia 20 de Maio de 2008. O processo de seleco das equipas que foram apuradas para a nal nacional teve duas etapas que apuraram sete equipas participantes. Enriquecimento Pessoal Tal como se pretendia foi possvel melhorar conhecimentos sobre as diculdades reais no desenvolvimento de aplicaes ubquas. A organizao e diviso de tarefas pelo grupo de trabalho referido no primeiro captulo tambm se revelaram interessantes. A interaco e coordenao no desenvolvimento da plataforma foram uma mais-valia como experincia. Bem como os conhecimentos adquiridos e expostos ao longo do relatrio. Sem esquecer o que cou por dizer como as horas passadas na Universidade, quer de noite como alguns ns-de-semana, a trabalhar para o desenvolvimento da plataforma. Bem como a ida a Lisboa, o nervosismo de enfrentar jornalistas e um jri constitudo por elementos de prestgio nas mais diversicadas reas.

7.2

Trabalho Futuro

Apesar de o carFree.ubi estar funcional, o mesmo no est totalmente concludo. Como trabalho futuro ca a necessidade de construir uma aplicao ou pgina web de administrao da base de dados do sistema. Uma vez que o objectivo era ter a plataforma funcional os dados de teste foram introduzidos por intermdio de scripts. Outra funcionalidade que ca como trabalho futuro o desenvolvimento de uma pgina Web para divulgao e download da aplicao, isto no caso de o carFree.ubi conseguir cativar algum da rea dos transportes. Ficam ainda sugestes de expanso da plataforma a redes de marketing que possam dirigir as suas publicidades a cada utilizador de forma moderada e controlada pelo mesmo. Isto com o objectivo de potenciar a baixa de preo dos transportes aproveitando as receitas geradas pela rede de publicidade. Como ltima sugesto ca tambm a introduo de uma ferramenta de deteco de roubos de dispositivos. Uma vez que cada dispositivo de um utilizador ca registado no sistema pelo seu MAC Address cifrado com a password do utilizador.

70

Concluso

Torna-se possvel, caso o mesmo solicite, alterar o MAC cifrado para possibilitar que este seja detectado pelo sistema e assim se tenha conhecimento da posio do mesmo.

Bibliograa
[1] Central Intelligence Agency. Appendix B - International Organizations and Groups, 6 2008. https://www.cia.gov/library/publications/ the-world-factbook/appendix/appendix-b.html. [2] American Public Transportation Association. Annual study shows trac congestion 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 Mobile Computing Research, 2000. [5] Stefano Russo Domenico Cotroneo, Almerindo Graziano. Security Requirements in Service Oriented Architectures for Ubiquitous Computing, 2004. [6] Yang Li and James A. Landay. Exploring Activity-Based Ubiquitous Computing: Interaction Styles, Models and Tool Support, 2006. [7] Switzerland LIFT07 conference in Geneva. Everyware: Further down the 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 support to localized activities, 2005. 71

72

BIBLIOGRAFIA

[10] Studies and Observations. About the Author | Everyware: The dawning 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.

You might also like