Este documento descreve um projeto desenvolvido para a disciplina de Projeto na Universidade da Beira Interior. O objetivo do projeto foi construir uma plataforma que permitisse melhorar a experiência de utilização dos transportes públicos através da computação ubíqua. A equipa desenvolveu uma arquitetura complexa que inclui um servidor, aplicações móveis e clientes Windows para fornecer informações aos utilizadores. O relatório detalha o trabalho realizado em cada componente para alcançar este objetivo.
Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...
Relatório de Projecto de Licenciatura
1. Departamento de Informática
da Universidade da Beira Interior
carFree.ubi
Computação ubíqua ao serviço dos transportes públicos
Joel Silva Carvalho
Orientador do Projecto:
Prof. Doutor Simão Melo de Sousa
Covilhã, Junho de 2008
3. Agradecimentos
A todos os que contribuíram de alguma forma para este projecto, aqui fica
o meu forte agradecimento.
Não vale a pena citar nomes, porque foram muitas as pessoas que deram
a sua contribuição por mínima que tenha sido.
Obrigado a todos!
i
9. Lista de Figuras
3.1 Esquema da plataforma carFree.ubi . . . . . . . . . . . . . . 26
3.2 Web Services Description Language (WSDL) do Servidor . . 27
3.3 Menu principal da aplicação PDA . . . . . . . . . . . . . . . 30
3.4 Menu principal da aplicação Windows . . . . . . . . . . . . . 31
4.1 Diagrama da Base de Dados . . . . . . . . . . . . . . . . . . . 35
4.2 Diagrama do VS2008 do Servidor . . . . . . . . . . . . . . . . 42
5.1 Diagrama do VS2008 da aplicação Windows Mobile . . . . . 50
5.2 Menu principal da aplicação Windows Mobile . . . . . . . . 53
5.3 Menu 1 da aplicação Windows Mobile . . . . . . . . . . . . . 54
5.4 Menu de login da aplicação Windows Mobile . . . . . . . . . 55
5.5 Menu horários da aplicação Windows Mobile . . . . . . . . . 56
5.6 Menu amigos da aplicação Windows Mobile . . . . . . . . . 57
5.7 Menu histórico da aplicação Windows Mobile . . . . . . . . 58
5.8 Menu Mobile Info da aplicação Windows Mobile . . . . . . . 59
6.1 Diagrama do VS2008 da aplicaçao Windows . . . . . . . . . 62
6.2 Lista de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 Teclado virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4 Exemplo de uma autenticação falhada . . . . . . . . . . . . . 66
vii
11. Acrónimos
DS Desenvolvimento Sustentável
SI Sistema de Informação
GPS Global Positioning System
VS2008 Visual Studio 2008
DEA Diagrama de Entidade-Associaçao
WSDL Web Services Description Language
PDA Personal Digital Assistant
MAC Media Access Control
API Application Programming Interface
DC Developed Countries
RFID Radio Frequency Identification
SOA Service Oriented Architecture
DLL Dynamic-link library
IDE Integrated Development Environment
SDK Software Development Kit
IIS Internet Information Services
HTTP Hypertext Transfer Protocol
ix
12. x Acrónimos
HTTPS HyperText Transfer Protocol Secure
FTP File Transfer Protocol
SMTP Simple Mail Transfer Protocol
NMTP Negotiable Mail Transfer Protocol
GUI Graphical User Interface
IA Inteligência Artificial
GDI Graphics Device Interface
SQL Structured Query Language
WPF Windows Presentation Foundation
UBI Universidade da Beira Interior
WSE Web Services Enhancements
XML Extensible Markup Language
IV Initialization Vector
AES Advanced Encryption Standard
CBC Cipher-block Chaining
ECB Electronic CodeBook
MD5 Message-Digest algorithm 5
13. Capítulo 1
Introdução
Objectivo do documento
Este relatório descreve detalhadamente o trabalho desenvolvido para a
disciplina de Projecto do curso de Engenharia Informática na Universidade
da Beira Interior. O documento condensa um conjunto de conhecimentos
adquiridos e justifica as abordagens seguidas na sua implementação.
Objectivo do projecto
Ao longo do percurso académico pretende-se que o aluno adquira di-
versas competências que se reflectem no desenvolvimento de um projecto
à sua escolha. Escolha esta que foi previamente construída e desenvolvida
em colaboração com o Professor orientador, culminando no objectivo de
construir uma plataforma inovadora que permitisse melhorar a experiên-
cia de utilização do utente de transportes públicos. Este projecto nasceu
da combinação de inúmeros factores e resultou na participação da final
nacional do concurso da Microsoft (Imagine CUP1 ) que tinha por tema:
"Imagina um mundo onde a tecnologia possibilita um ambiente sustentável"2 .
Aprendizagem complementar
Para além deste projecto representar um grande desafio na construção
de uma ideia que fosse verdadeiramente contributiva ao ambiente, ele
1
http://www.microsoft.com/portugal/imaginecup/vencedoresnacionais.mspx
2
http://imaginecup.com/PT/SD.aspx
1
14. 2 Introdução
surgiu também no seguimento da vontade de estudar sistemas ubíquos
(ver capítulo 2). Este tipo de sistemas, apesar de ter uma importância
crescente, não é abordado no plano curricular actual do curso. O que
por si também foi factor decisivo na escolha do projecto e do orientador.
A vontade de enriquecer e complementar o conhecimento adquirido é
insaciável.
Equipa
Dada a exigência do desenvolvimento de raíz de uma arquitectura tão
vasta, considerou-se fundamental construir uma equipa capaz de desen-
volver um trabalho com impacto suficiente para uma participação na final
nacional do Imagine CUP. A equipa que se passou a designar por Ubiquista
ficou constituída pelos seguintes elementos: André Passos, Joaquim Tojal,
João Oliveira e Joel Carvalho. Cada qual com um conjunto de respons-
abilidades e tarefas específicas (ver 1.2) providenciando independência no
trabalho. Sendo dois destes alunos do projecto ImagineCup@ubi (Joaquim
Tojal e Joel Carvalho) ficou-lhes atribuído maior quota de trabalho no pro-
jecto global.
1.1 Motivação
Computação Ubíqua
Este projecto tem uma origem um quanto peculiar comparativamente
aos restantes. Da curiosidade e vontade de estudar a computação ubíqua
conciliada com a abertura do Professor orientador surgiu esta necessidade.
Assimilados os conceitos e a filosofia, tornou-se a dada altura imperativo
pensar num caso de estudo que permitisse enfrentar as dificuldades e peri-
gos referidos na literatura (ver capítulo 2). Desenvolver uma arquitectura
que pretende integrar diversos tipos de dispositivos conciliando diversas
formas de utilização não é algo trivial nem pode ser descurado. A pri-
vacidade dos dados tem de ser garantida e o sistema deve adaptar-se ao
utilizador, nunca o contrário.
Imagine CUP 2008
Uma vez que o desenvolvimento deste projecto é focado no enriquec-
15. 1.1 Motivação 3
imento pessoal dos alunos, em detrimento de produção científica (mais
adequada para Mestrado), torna-se evidente que a participação num con-
curso é uma mais-valia. O Imagine CUP para além de ser um desafio é uma
janela de oportunidade, quer para promoção pessoal como institucional.
Sendo que desde cedo o Imagine CUP fez sentido, especialmente quando
a temática do concurso deste ano foca um assunto que nos preocupa a
todos. Está-se claro a falar do ambiente numa vertente em que não se
pretendem posições extremistas mas sim pensadas no Desenvolvimento
Sustentável (DS).
SI’s ao serviço do ambiente
O desafio de produzir um Sistema de Informação (SI) capaz de con-
tribuir para o ambiente foi uma motivação extra. Mas não foi fácil escolher
uma ideia a desenvolver que fosse suficientemente boa e inovadora. In-
clusivamente no processo de selecção de ideias foram descartadas uma
quantidade substancial delas já que o objectivo da participação no con-
curso era conseguir-se pelo menos um apuramento para a final nacional.
O problema dos SI’s é que estes não são de todo a maneira mais intuitiva de
colaborar para um melhor ambiente. Mais facilmente se pensa em sistemas
electromecânicos, electrotécnicos e energéticos para melhorar o ambiente
do que em SI’s.
Ideias abandonadas
Nas ideias que ficaram para trás destacam-se algumas que até são de
algum interesse, no entanto foram consideradas como insuficientes ou de-
masiado óbvias. Nomeadamente um sistema ubíquo de apoio ao consum-
idor. A ideia deste sistema consistia em classificar os produtos alimentares
disponíveis nos supermercados como sendo mais ou menos ecológicos
tendo em conta a sua origem e outras informações. Outra ideia passava
pela implementação de um sistema ubíquo de informação e sensibiliza-
ção ambiental, no qual se pretendia criar rotas verdes e desviar tráfego de
zonas com níveis de poluição elevados.
16. 4 Introdução
1.2 carFree.ubi
Descrição 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 públicos em detrimento dos
transportes particulares recorrendo a diversas tecnologias presentes no
quotidiano. Apesar de actualmente ser na verdade mais confortável uti-
lizar o veículo particular, isso não quer dizer que os transportes públicos
não possam superar esse conforto. O carFree.ubi pretende até contribuir na
melhoria desse conforto fornecendo, ao utilizador de transportes públicos,
conteúdos multimédia exclusivos no interior do próprio transporte. Isso
é feito recorrendo a uma aplicação a correr em cada ecrã táctil instalado
por todos os lugares. O carFree.ubi pretende também facilitar a escolha
do transporte mais rápido ou económico com base numa aplicação em
Windows Mobile que serve de extensão do sistema de Global Positioning
System (GPS) e que fornece informações em tempo real sobre a rede de
transportes públicos. Pretende-se com isto agitar e alterar a forma como
os transportes públicos são vistos e utilizados. O tempo dispensado nas
viagens quer-se produtivo e enriquecedor, coisa que actualmente não se
consegue na plenitude recorrendo ao transporte particular. É providenci-
ada uma descrição mais detalhada, sobre como o carFree.ubi faz isso tudo,
no capítulo 3 e seguintes.
Impacto dos 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 utilização massiva
dos transportes públicos tem várias consequências ambientais, sociais e
económicas. Sabendo que o DS é construído sobre estes três pilares inter-
dependentes e mutuamente sustentadores tornou-se evidente que uma
solução como o carFree.ubi já devia existir há mais tempo. Como prova
disso é interessante constatar como recentemente a questão do preço dos
combustíveis veio abanar os transportes. Um estudo americano[2] feito
à pouco mais de seis meses veio revelar, para além do impacto directo
da poluição, dados impressionantes. Por exemplo foi divulgado que o
custo provocado pelos congestionamentos das metrópoles, apenas nos
17. 1.2 carFree.ubi 5
Estados Unidos, era avaliado em 78 mil milhões de dólares. Valor que
corresponde a 4.2 mil milhões de horas perdidas e 10.97 mil milhões de
litros de combustível perdido.
Vantagens
Para além de tudo o que já se possa imaginar pela argumentação feita
até ao momento. A vantagem do carFree.ubi em instrumentalizar uma
ferramenta que pode apoiar medidas políticas para a limitação da utiliza-
ção dos transportes particulares no interior dos centros urbanos é também
uma mais-valia incontestável. Ao contrário do que foi feito noutras áreas é
importante melhorar as soluções existentes antes de tomar medidas mais
duras. Mas a verdade é incontornável, se o crescimento dos transportes
particulares continuar a aumentar, mesmo que estes não sejam poluentes,
vai chegar-se a um ponto de saturação em que ninguém vai fazer distancias
curtas em tempos considerados decentes. Muitas cidades europeias já pos-
suem os centros urbanos cortados a trânsito rodoviário excepto transportes
públicos e abastecimento de comércios. Essa realidade vai fazer parte do
futuro de todas as cidades e os transportes públicos vão ter que se adaptar
de modo a servir as necessidades dos utentes. O carFree.ubi enquadra-se
perfeitamente numa solução que consegue suportar melhor essa neces-
sidade, para mais informações pode consultar documentos referidos na
secção contributo.
Dificuldades
Uma das questões que acabou por surgir, incide no facto do que possa
acontecer se realmente este sistema conseguir resultados. Existe o receio,
por parte de quem avaliou a ideia, do carFree.ubi se tornar inutilizável
em caso de saturação dos transportes públicos. Como só existem ecrãs
tácteis nos assentos, quem fica de pé não tem acesso ao sistema. A ideia
do carFree.ubi é de um sistema adaptado às necessidades dos utentes,
promovendo qualidade de vida e melhorando a experiência de utilização
dos transportes públicos. Um caso de saturação de transporte público,
para além de comportar uma situação ilegal, é a antítese da plataforma
carFree.ubi. Qualquer rede de transportes públicos que trabalhe para o
benefício dos utentes e queira um sistema como este, de certeza que não
vai aceitar que os seus transportes estejam constantemente sobre saturação.
18. 6 Introdução
Os transportes públicos, para além de terem a obrigação de se adaptar às
necessidades dos utentes, devem servi-los com a máxima qualidade. Se
as transportadoras e os governos querem resolver o problema dos con-
gestionamentos nos grandes centros urbanos só existe uma solução! Não
permitir o transito de veículos particulares no centro das cidades. Por con-
seguinte torna-se necessário aumentar a frota de transportes e melhorar o
incentivo da utilização dos mesmos. Decisão esta que pode ser sustentada
com a plataforma carFree.ubi.
Divisão de trabalho
Como foi referido anteriormente o carFree.ubi foi desenvolvido por qua-
tro elementos de forma independente, no entanto ligada. A arquitectura do
carFree.ubi é apresentada no capítulo 3, mas em forma de breve antevisão
apresenta-se desde já a divisão do trabalho.
• André Passos - Responsável pelo desenho da interface da aplicação
cliente em Windows.
• Joaquim Tojal - Responsável por:
• Desenho da interface da aplicação cliente em Windows Mobile.
• Desenvolvimento da parte relativa à extensão do sistema GPS.
Sistema que consiste resumidamente em fornecer rotas alter-
nativas ao transporte particular indicando ao condutor onde
estacionar o carro, qual a paragem a tomar para chegar ao seu
destino e posteriormente conseguir voltar. Tudo dentro dos
horários que ele pretenda cumprir. Para mais informações con-
sultar relatório número 54.
• João Oliveira - Responsável pela componente de inteligência artificial.
• Joel Carvalho - Responsável por:
• Desenho da arquitectura do sistema e da base de dados, bem
como a forma como a comunicação entre os clientes e servidor
é feita.
• Definição das políticas de segurança e privacidade, incluindo o
modo como os utilizadores são identificados pelo sistema,
19. 1.3 Contributo 7
• Desenvolvimento da aplicação servidor.
• Desenvolvimento de parte da aplicação cliente do Windows no
que respeitou o login.
• Desenvolvimento de parte da aplicação Windows Mobile no que
respeitou o registo do utilizador no sistema e configuração de
primeira utilização da aplicação Mobile bem como desenvolvi-
mento de algumas opções como a consulta de horários, 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é à execução, todo o trabalho foi feito de raiz e o
resultado possui potencialidades futuras que não podem ser ignoradas.
Esta plataforma colmata necessidades existentes nos centros urbanos que
já possuem uma boa rede de transportes públicos.
BTLib
Para além do que foi referido anteriormente, ainda foram desenvolvidas
duas bibliotecas. Durante o desenvolvimento do carFree.ubi cada um foi-
se deparando com algumas dificuldades. Dessas dificuldades resultou a
necessidade de criação e utilização de uma biblioteca .NET (desenvolvida
em C++) capaz de descobrir dispositivos como Telemóveis e Personal
Digital Assistant (PDA)’s através 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 sensível a algumas manipulações (ver capítulo 6).
Esta biblioteca ficou designada por BTLib e encontra-se em processo de
avaliação para publicaçao na SourceForge3 .
CryptoLib
A outra biblioteca surgiu da necessidade de facilitar a utilização da
3
http://sourceforge.net/projects/btlib/
20. 8 Introdução
API criptográfica da Framework .NET, no sentido que a mesma revela-se
necessária para algumas partes fundamentais do projecto e considerou-se
mais útil desenvolver esta biblioteca de forma a ser totalmente reutilizável
quer pela aplicação Windows como Windows Mobile. Mais uma vez trata-se
de uma bilbioteca .NET (desenvolvida em FSharp) que ficou designada
por CryptoLib, sendo que a mesma se encontra em processo de avaliação
para publicaçao na SourceForge4 .
Documentos
Ainda foi necessário realizar e apresentar alguns documentos5 no âm-
bito do concurso que se decidiu publicar quer para futuros alunos que
pretendam participar no Imagine CUP como também para divulgação do
projecto. Existem também referências feitas na página oficial da Microsoft6
com alguma informação sobre o projecto.
1.4 Organização do relatório
Este relatório divide-se em capítulos. No primeiro capítulo optou-se por
fazer uma breve introdução ao projecto.
Cap 2 - Estado de Arte
No segundo capítulo são introduzidos os princípios e a filosofia agregada
ao sistema desenvolvido.
Cap 3 - Plataforma carFree.ubi
No terceiro capítulo descreve-se a plataforma carFree.ubi bem como a
análise de requisitos, as tecnologias e os dispositivos utilizados.
4
http://sourceforge.net/projects/cryptolib/
5
http://skydrive.live.com/
6
http://www.microsoft.com/portugal/presspass/press/2008/mai08/
05-21imaginecup2008.mspx
21. 1.4 Organização do relatório 9
Cap 4 - Servidor
No quarto capítulo aborda-se de forma mais detalhada o trabalho de-
senvolvido no Servidor onde se inclui a descrição da Base de Dados da
plataforma.
Cap 5 - Cliente Windows Mobile
No quinto capítulo apresenta-se e descreve-se a aplicação cliente para
Windows Mobile bem como uma biblioteca criptográfica desenvolvida.
Cap 6 - Cliente Windows
No sexto capítulo descreve-se o trabalho desenvolvido no cliente Win-
dows que funciona no interior dos transportes públicos e uma biblioteca
para descoberta de dispositivos bluetooth.
Cap 7 - Conclusão
No último capítulo fazem-se as últimas conclusões e finaliza-se o re-
latório.
23. Capítulo 2
Estado de Arte
Dispositivos computacionais
A proliferação massiva de dispositivos com capacidades computacionais
tem-se alargado um pouco por todas as áreas. Os computadores já não são
apenas peças de Hardware volumosas de ter em casa junto da secretária.
Qualquer cidadão de um país dito desenvolvido segundo padrões con-
sumistas (Developed Countries (DC)[1]) possuí pelo menos um disposi-
tivo com capacidades computacionais. Esses dispositivos são actualmente
muito diversificados desde PDA’s, Telemóveis, Smart Card’s, Radio Fre-
quency Identification (RFID)’s, entre muitos outros.
Princípios 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 computação
ubíqua[3], publicou em 1991 e 1993 alguns documentos com citações
inspiradoras[14][12][13][11]. Desses documentos destacam-se citações 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
24. 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 afford
better privacy protection than exists today."[11]
• "Unlike PDA’s, ubiquitious computing envisions a world of fully connected
devices, with cheap wireless networks everywhere; unlike PDA’s, it postu-
lates that you need not carry anything with you, since information will be
accessable everywhere."[12]
Tecnologia
Passado uma década Mark Weiser começa a ganhar uma importância
fundamental. Afinal a sua visão dos computadores estarem em todo o
lado e comunicarem essencialmente por redes sem fios tornou-se uma re-
alidade. Como exemplo basta pegar nos PDA’s. Estes são hoje uma junção
dos descritos, na última citação de Mark Weiser, no entanto com a inte-
gração de capacidades atribuídas aos telefones móveis mais tradicionais e
com a grande vantagem de terem acesso a redes sem fios. O PDA que Mark
Weiser refere em 1993 é bem diferente do PDA actual. O actual está incriv-
elmente mais próximo da visão de sistemas ubíquos do que muitos outros
dispositivos, mesmo sendo um dispositivo que pode ser transportado.
O Futuro
O culminar da filosofia apresentada por Mark Weiser, onde todos os
dispositivos computacionais passam a servir as populações de forma in-
visível, vai dar-se quando se perder a consciência completa da tecnologia
que se utiliza e se focar meramente na tarefa. Pode imaginar-se que o
tal PDA sofre mais uma evolução e passa a fazer parte dos óculos que
muitas pessoas usam. As pessoas precisam dos óculos para corrigir uma
dificuldade visual, mas porque não dar-lhe uma funcionalidade extra?
Continuando a ficcionar, imagine-se que os mesmos recebem instruções
vocais que processam e executam acções. Essas acções podem ter um out-
put visual, numa parte da lente dos óculos, e um ouput sonoro, produzido
por vibrações transmitidas pela armação fazendo chegar o som ao ouvido
sem que ninguém se aperceba.
25. 2.1 Discussão existente 13
Computação Ubíqua
No entanto os sistemas ubíquos precisam de software, sem ele os dis-
positivos não passam de meros objectos com funcionalidades próximas de
uma pedra. Não basta ter as tecnologias, é preciso integrar as mesmas e
fazer com que elas realmente sirvam a população. A computação ubíqua
defendida por Mark Weiser tem um papel importantíssimo no desenvolvi-
mento futuro de aplicações. Já chega de desenvolver aplicações e sistemas
sem pensar nas consequências. É preciso defender os interesses e direitos
dos utilizadores de modo a que estes realmente gostem, queiram e tenham
proveito na utilização das tecnologias sem sequer pensarem nelas. Cada
vez mais a privacidade das pessoas é invadida, todos os dias existem mil-
hares de câmaras a vigiar as cidades. Todos os dias deixamos rastos do
que fazemos, quando fazemos, como fazemos só falta registas o porquê.
Mas afinal porque é que os sistemas não evoluem de modo a salvaguardar
a privacidade das pessoas?
Paradigmas
A grande dificuldade actual encontrada no desenvolvimento de com-
putação ubíqua é, precisamente, como praticá-la correctamente e com base
em que paradigma. Ainda não se pode dizer que exista um modelo rígido
que defina como e quando se deve praticar computação ubíqua. Isto
porque derivaram da computação ubíqua diversos paradigmas, nomeada-
mente o Wearable Computing[8], o Activity-Based Centered Ubiquitous
Computing[6], ou ainda o Context Aware Mobile Computing[4].
2.1 Discussão existente
Adam Greenfield[10] é um escritor reconhecido a nível internacional e
é uma das pessoas que mais tem participado activamente para um de-
bate aberto sobre a computação ubíqua. Já publicou um livro intitulado:
"Everyware: The dawning age of ubiquitous computing". Algumas das suas
palestras[7] para além de apresentarem a temática, abordam uma serie de
preocupações com as quais se deve ter algum cuidado. Tal como Mark
Weiser, Adam Greenfield considera que o desenvolvimento de tais sis-
temas deve ser cuidado por diversos motivos que vão ser apresentados de
seguida.
26. 14 Estado de Arte
Inadvertência
Um deles é a inadvertência dos utilizadores. Imaginando um sistema
ubíquo que permite difundir a localização do utilizador para um conjunto
limitado de pessoas ou para todas as pessoas. O facto do utilizador poder
enganar-se num botão, e em vez de divulgar a sua posição apenas para um
conjunto limitado de pessoas o fizer 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 consideração é o desconhecimento, por parte dos
utilizadores, do sistema. Eles podem não saber da existência do mesmo ou
podem não conhecer todas as suas funcionalidades. Consequentemente
não sabem que informações o sistema recolhe, o que é feito com essas
informações ou até mesmo quem as guarda e com que objectivo. Apesar
de isso ter um lado positivo, porque torna-se invisível para o utilizador,
não o interrompe na sua tarefa nem molda a sua maneira de actuar. Na
verdade pode constituir um problema, porque todos possuem o direito de
saber o que é feito com os dados que são recolhidos das suas interacções.
Rejeição
Segundo Adam Greenfield, este é o tema mais controverso. O facto de
uma pessoa rejeitar a utilização de um sistema, seja por qual motivo for,
deve ser um direito inquestionável. Ninguém deve ser obrigado a utilizar
algo que não quer. No entanto nem sempre se aceita esta premissa no
desenvolvimento de sistemas ubíquos. Muitas vezes parte-se do princípio
errado de que todos vão aceitar e querer utilizar o sistema. Existem muitos
exemplos de sistemas que não são propriamente ubíquos mas obrigam o
utilizador a aceitar algo que pode não querer. As câmaras de vigilância são
um exemplo disso. No entanto se for evitável repetir erros actuais deve-se
evoluir para soluções que garantam a privacidade das pessoas, já que é
um direito constitucional.
Epílogo
O importante a reter actualmente é precisamente o perigo que pode advir
de um sistema ubíquo pouco pensado. A discussão sobre o tema contínua
27. 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 computação ubíqua só consegue ter o seu sucesso se for cen-
trada nas pessoas. Quer no que elas precisam como nas suas preocupações.
Como exemplo a seguir, se um sistema ubíquo regista alguns dados de in-
teracção do utilizador o ideal será nunca saber ao certo quem é o utilizador
(ver capítulo 3).
2.2 Framework adoptada
Framework .NET
A computação ubíqua, dada a sua natureza, permanece em desenvolvi-
mento contínuo. Existem no meio académico algumas frameworks desen-
volvidas e outras em desenvolvimento como o caso do ActivitySpot[9].
Todavia a abordagem adoptada no desenvolvimento do sistema foi orien-
tada pela necessidade de usar as ferramentas da Microsoft uma vez que 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 particulari-
dade de permitir a utilização de Web Services em .NET tal como era exigido
para efeitos de concurso e possibilita o desenvolvimento de um sistema
que não fica dependente da Framework. Simultaneamente o SOA potencia
o desenvolvimento de aplicações com base na computação ubíqua.
2.3 Conclusão
Este capítulo introduziu o contexto da plataforma ubíqua que vai passar
a ser descrita no capítulo seguinte. Para além do estudo teórico apresen-
tado, muitas das ideias presentes neste capítulo vão servir de suporte para
escolhas tomadas no desenvolvimento do carFree.ubi.
29. Capítulo 3
Plataforma carFree.ubi
Objectivo
O carFree.ubi consiste numa plataforma ubíqua que interliga uma série
de dispositivos e tecnologias de modo a fornecer ao utente de transportes
públicos informações e serviços considerados úteis em qualquer lugar.
Tal como foi referido, o objectivo principal do carFree.ubi é incentivar
a utilização dos transportes públicos 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 distribuídos. Nesta arquitectura incluem-se três
tipos de clientes distintos. Um dos tipos de clientes é uma aplicação para
Windows Mobile que para além de possibilitar a consulta de horários e
outras informações em tempo real, também é um autêntico assistente de
viagens para transportes públicos. Outro cliente é uma aplicação Windows
que funciona com ecrãs tácteis e que permite a consulta de conteúdos
multimédia exclusivos. O último cliente é simplesmente uma página Web
institucional, isto é, pode ser simplesmente a página Web da empresa que
gere os transportes públicos. Esta arquitectura é descrita com maior detalhe
na secção 3.4.
17
30. 18 Plataforma carFree.ubi
3.1 Análise de Requisitos
Antes de se passar a uma maior descrição da plataforma em si, apresenta-se
a análise de requisitos feita. Esta análise foi realizada avaliando informal-
mente as necessidades de um conjunto de pessoas de confiança. Desta
forma foi possível perceber em que medida um sistema ubíquo podia cor-
responder às suas necessidades mantendo uma certa descrição em toda
a fase de desenvolvimento. Esta descrição foi necessária uma vez que
se pretendia chegar ao Imagine CUP com uma ideia totalmente distinta e
original.
3.1.1 Requisitos funcionais
RF01 - Conteúdos multimédia
Algo que ficou imediatamente identificado foi a necessidade de tornar
o tempo dispendido dentro dos transportes públicos de maior qualidade
e utilidade. Numa sociedade em constante evolução os transportes, inde-
pendentemente do tipo, possuem uma importância crescente. Pensando e
olhando para os utilizadores de transportes públicos actuais, constata-se
facilmente que alguns tentam passar esse tempo ocupando-se. Alguns
lêem jornais, outros jogam no telemóvel, outros telefonam ou falam com
amigos, etc. É claro que existe sempre quem dedique o tempo da viagem
a fazer uma reflexão interna e não queira outra solução. O requisito que
aqui fica identificado é a necessidade do sistema possibilitar (e não obri-
gar) aos utentes a consulta de conteúdos multimédia dentro dos próprios
transportes.
RF02 - Assistente de viagens
Outra questão pertinente e que rapidamente se fez transparecer foi a ne-
cessidade de melhorar o conforto e a comodidade dos transportes públicos.
Isto porque, estes dois factores são responsáveis por muitos condutores não
abdicarem dos seus veículos particulares. Relativamente à comodidade,
identificou-se como requisito a possibilidade de integração dum assistente
de viagens. Este deve fornecer, de forma simples e intuitiva, alternativas
ao percurso a realizar com o veículo particular. Isto é, o condutor deixa de
se preocupar onde vai estacionar o carro e se as ruas X e Y estão ou não
31. 3.1 Análise de Requisitos 19
congestionadas. Antes de entrar numa cidade, o condutor utiliza o assis-
tente de viagens de modo a que este lhe indique um local onde estacionar
o carro e qual o transporte público a seguir para chegar mais facilmente ao
seu destino dentro da hora pretendida.
RF03 - Conteúdos adaptáveis
Relativamente ao conforto identificou-se como requisito a possibilidade
de utilizar métodos de inteligência artificial para ajustar os conteúdos
multimédia ao comportamento do utente. À semelhança do que é feito
em alguns sistemas Web é possível classificar os utilizadores pelo que
visualizam. Deste modo, consegue-se sugerir conteúdos que possam ser
do seu interesse.
RF04 - Conteúdos recuperáveis
Algo que ficou assente no seguimento dos requisitos anteriores é que
torna-se necessário guardar de alguma forma o estado do último conteúdo
visualizado pelo utente. Isto para permitir que um conteúdo que tenha
ficado em aberto seja recuperado no mesmo estado aquando de uma nova
sessão por parte daquele utente.
RF05 - Agrupamento de utilizadores
Os SI’s são muitas vezes acusados de fechar as pessoas num mundo à
parte. Uma vez que este sistema já pretende integrar uma componente de
inteligência artificial, surgiu como requisito a possibilidade de tentar criar
uma rede de socialização dos utentes. Esta rede que passa a ser designada
por rede de amigos tem como objectivo o agrupamento de utilizadores
pelos conteúdos visualizados.
RF06 - Informação em qualquer lugar
A exigência da sociedade manifesta-se perante os SI’s com a necessidade
de ter acesso a qualquer informação em qualquer lugar. No âmbito deste
sistema, a consequência dessa exigência é a identificação de um requisito
que permita a qualquer utilizador aceder a informações pertinentes onde
quer que esteja. Isto é, considera-se útil que o utilizador possa aceder às
seguintes informações:
32. 20 Plataforma carFree.ubi
• Histórico dos conteúdos visualizados nos transportes públicos.
• Horários dos transportes públicos.
• Lista de amigos presentes num determinado transporte público.
• Dados sobre o registo do utilizador no sistema.
RF07 - Página Web institucional
Como vem sendo comum em qualquer organização ou empresa, fica
como ultimo requisito a necessidade de associação do sistema a uma página
institucional. Na qual devem constar, para além das informações sobre a
empresa gestora da rede de transportes, informações detalhadas sobre o
funcionamento do carFree.ubi e condições de utilização.
3.1.2 Requisitos não funcionais
RNF01 - Segurança
Como ficou patente nos requisitos funcionais, é necessário ter utilizadores
no sistema. Cada utilizador deve ser identificado por um dos dois con-
juntos de pares, password e dispositivo móvel (Telemóvel ou PDA) ou
password e número de registo. Por motivos de segurança a password é
privada e cifrada. Por motivos de privacidade o identificador do disposi-
tivo, neste caso o MAC Address, também é cifrado.
RNF02 - Privacidade
Em momento algum são utilizados dados pessoais do utilizador. O
sistema não precisa nem deve solicitar ou armazenar dados como nome,
morada e outros. Cada utilizador é essencialmente identificado pelos
dispositivos que utiliza. Apesar de os dispositivos possuírem um MAC
Address que é público apenas o próprio utilizador pode fazer a associação
entre o MAC Address e o número de registo.
RNF03 - Portabilidade
Apesar de o sistema ser desenvolvido para um concurso com as fer-
ramentas da Microsoft pretende-se como requisito que o mesmo tenha
33. 3.2 Dispositivos 21
alguma portabilidade. Nesse sentido deve utilizar-se o paradigma SOA
para possibilitar uma futura utilização do servidor noutras plataformas
que não Windows.
RNF04 - Manutenção
Um sistema com uma dimensão como este exige que a programação seja
feita por partes e com documentação suficiente. Neste caso, pelo menos,
comentários aos métodos e uso de dll’s para algumas componentes da
aplicação.
RNF05 - Usabilidade
Qualquer aplicação deve ser feita pensando na forma como o utilizador
vai interagir com a mesma e com o meio envolvente. A aplicação para PDA
deve ser confortável na sua utilização, não exigindo demasiado escrita de
texto por parte do utilizador. Por sua vez a aplicação Windows deve ser
pensada e realizada considerando que não existe nenhum teclado ao dispor
do utente. Portanto a interface deve ser desenhada tendo em conta que o
utente tem um ecrã táctil à sua frente, no qual, caso seja necessário deve
ser utilizado um teclado virtual.
RNF06 - Fiabilidade
Pela natureza ubíqua da aplicação torna-se evidente a indispensabili-
dade do utilizador ter acesso, em qualquer lado, a uma rede privada sem
fios ou a uma rede internet sem fios. O sistema deve ser visto como um
sistema adaptado e enquadrado às cidades mais modernas, que no entanto
vão tornar-se comuns em breve.
3.2 Dispositivos
No seguimento dos requisitos foram identificados os dispositivos a utilizar
nesta plataforma. De notar que, apesar da escolha feita, outras soluções
foram avaliadas como por exemplo smartcard’s sem contacto à semelhança
dos passes utilizados no Porto. No entanto, e apesar de serem mais seguros,
os mesmos não são de fácil acesso. Sendo a plataforma algo complexa e
34. 22 Plataforma carFree.ubi
o tempo de desenvolvimento curto, optou-se por recorrer a equipamentos
de acesso mais imediato. Mas numa futura implementação do sistema
estas soluções não são de desprezar.
3.2.1 Ecrãs tácteis
Apesar de não terem sido utilizados, o desenvolvimento da aplicação
a correr no interior dos transportes públicos, foi pensada neste tipo de
equipamento. Este tipo de dispositivos é ideal para servir de interface
num ambiente urbano. Para além de ocuparem um espaço muito limitado
permitem uma interacção mais intuitiva. À semelhança de muitas tarefas
que são realizadas no dia-a-dia com um ecrã táctil descarta-se qualquer
necessidade de objectos supérfluos como o rato e o teclado. Este disposi-
tivo enquadra-se nos objectivos dos requisitos RF01 (ver 3.1.1), RF03 (ver
3.1.1), RF04 (ver 3.1.1). Para além de servir como meio de identificação do
utilizador (RFN01, ver 3.1.2) perante os ecrãs tácteis existente no interior
dos transportes.
3.2.2 PDA com ou sem GPS
Este não é um dispositivo muito comum mas a verdade é que o seu preço
começa a aproximar-se cada vez mais ao dos telemóveis. Tendo mais
funcionalidades, é uma questão de tempo até existir uma fusão dos dois
dispositivos ou dos telemóveis 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
existência de GPS integrado ou de um dispositivo GPS externo. Mas
apesar de poderem funcionar na mesma aplicação o RF06 e RF02 são
independentes.
3.2.3 Telemóvel
Uma vez que existe a consciência de nem todos disporem de PDA’s e
assim o utilizador já não conseguir ter acesso às funcionalidades próprias
da aplicação Mobile. Pretende-se que o mesmo possa pelo menos usufruir
35. 3.3 Tecnologias e Ferramentas 23
dos serviços no interior do autocarro. Deste modo o telemóvel ou outro
dispositivo comunicante bluetooth pode servir como meio de identificação
do utilizador (RFN01, ver 3.1.2).
3.3 Tecnologias e Ferramentas
Contextualização
Esta plataforma mexe com múltiplas técnicas e tecnologias mas nem to-
das foram introduzidas. De seguida são apresentadas muito brevemente
todas as tecnologias que estão de uma ou outra forma integradas na apli-
cação.
VS2008
O Visual Studio 2008 (VS2008) é um Integrated Development Environment
(IDE) da Microsoft que permite desenvolver aplicações usando um leque
interessante de linguagens para diversas situações. O VS2008 permite criar
bibliotecas, aplicações para consola ou aplicações gráficas para Windows e
Windows Mobile. Através deste IDE foi possível utilizar e integrar lingua-
gens como o C++, CSharp e FSharp no desenvolvimento da plataforma.
Windows SDK
O Windows Software Development Kit (SDK) reúne um conjunto de
bibliotecas, API’s e exemplos para desenvolvimento de aplicações em Win-
dows. Este SDK foi necessário para o uso da API Bluetooth da Microsoft.
Framework .NET 3.5
A Framework .NET é uma componente integrante dos sistemas oper-
ativos da Microsoft. Esta é talvez um dos maiores pontos favoráveis ao
desenvolvimento de aplicações em Windows, uma vez que aglomera um
conjunto enorme de bibliotecas. Para além disso, a Framework é expansível
e pode ser usada em múltiplas linguagens flexibilizando a programação.
Compact Framework .NET 3.5
A Compact Framework .NET é a versão Framework .NET da Microsoft
36. 24 Plataforma carFree.ubi
para dispositivos móveis e embebidos. Apesar de serem muito semel-
hantes é preciso ter algum cuidado porque nem todas as funcionalidades
da Framework .NET existem nesta versão.
IIS 6.0
O Internet Information Services (IIS) é um servidor Hypertext Transfer
Protocol (HTTP) HyperText Transfer Protocol Secure (HTTPS), File Trans-
fer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) e 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
disponíveis pela internet.
MS SQL Server 2005
O Microsoft MSQL Server é um servidor de Base de Dados para Windows
com uma interface de gestão completa. Uma vez que a plataforma necessita
de armazenar dados no servidor, a solução adoptada foi recorrer à base de
dados da Microsoft.
Microsoft Expression Blend 2
Para o desenvolvimento da interface gráfica da aplicação Windows
optou-se por utilizar o Microsoft Expression Blend 2. Este Graphical User
Interface (GUI) builder facilita a criação 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 extensão do GPS. Esta ferramenta permite integrar, editar e visualizar
mapas. Ela penas foi utilizada pelo Joaquim Tojal, como tal, maiores
referências e explicações são feitas no relatório 54.
OpenNetCF
A OpenNetCF desenvolveu e disponibilizou uma extensão da Compact
Framework .NET da Microsoft. Esta extensão teve de ser usada devido a
dois factores fundamentais:
37. 3.4 Arquitectura 25
• Em primeiro pelo facto da Compact Framework não incluir os méto-
dos da Framework .NET para derivação de chaves.
• Em segundo porque esta foi a solução mais prática que se encontrou
para conseguir recolher internamente o MAC Address das interfaces
de rede do PDA.
Epílogo
Como é possível constatar todas as ferramentas utilizadas são da Mi-
crosoft, não porque fosse considerado que eram as melhores mas porque
assim era exigido para efeitos de concurso. No entanto, isso não consti-
tuiu nenhuma limitação no desenvolvimento da plataforma, muito pelo
contrário.
3.4 Arquitectura
Finalmente passa-se a apresentar a arquitectura que foi idealizada para esta
plataforma ubíqua. A arquitectura baseia-se numa arquitectura cliente/servidor
e está dividida em módulos segundo alguns padrões de funcionamento.
3.4.1 Servidor
Objectivo
No centro encontra-se o servidor, uma vez que esta é a peça nuclear
da arquitectura. Se o servidor falhar, falha toda a plataforma. Ou melhor,
toda a plataforma fica parcialmente inutilizável já que as aplicações clientes
precisam de respostas do servidor. Por exemplo: a aplicação a funcionar
no PDA deixa de fazer sentido se não conseguir receber respostas do
servidor, no entanto a mesma continua a funcionar sem conseguir fornecer
informação ao utilizador. Já a aplicação a correr no interior dos transportes
públicos pode continuar a funcionar quase normalmente se tiver uma cache
de conteúdos locais. Esta situação não foi implementada mas pode vir
a ser adicionada futuramente. Para uma implementação comercial desta
plataforma seria necessário difundir o servidor por diversos computadores
de modo a que se algum falhasse, esse fosse compensado pelos restantes.
38. 26 Plataforma carFree.ubi
Figura 3.1: Esquema da plataforma carFree.ubi
39. 3.4 Arquitectura 27
Figura 3.2: WSDL do Servidor
Sem claro esquecer a redundância que seria necessária com BackBones e
Routers.
Componentes
Pelo diagrama 3.1 consegue-se perceber que o servidor possui três com-
ponentes distintas mas interligadas e acessíveis por Web Services, são elas
a Base de Dados, os WebServives e a Inteligência Artificial (IA). Em mo-
mento algum um cliente comunica directamente com a Base de Dados ou
com a classe de IA.
Segurança
Se um cliente quer alguma informação da Base de Dados a aplicação faz
esse pedido aos Web Services e eles tratam do resto. Optou-se por esta abor-
dagem por motivos de segurança. Em momento algum se pretende dar
informação mais do que o necessário a um atacante. Com esta metodologia
tudo o que está para além dos Web Services é uma autêntica caixa negra
para qualquer atacante externo.
40. 28 Plataforma carFree.ubi
Inteligência Artificial
Pouco se vai adiantar sobre a parte de inteligência artificial, uma vez que
a mesma foi desenvolvida pelo João Oliveira. Apenas fica mais uma breve
explicação sobre a motivação para esta componente existir na arquitectura.
Como ficou identificado nos requisitos, considerou-se necessário ter uma
componente que permitisse adaptabilidade por parte da aplicação cliente
a correr nos transportes públicos. Também se considerou pertinente classi-
ficar os utilizadores pelas suas interacções com a mesma aplicação cliente
de modo a proporcionar uma maior socialização dos utentes, caso eles
assim o desejem. Com esta componente designada por rede de amigos
torna-se muito mais fácil as pessoas ficarem a conhecer outras com os
mesmos gostos.
Base de Dados
A Base de Dados pode ser considerada como outra peça nuclear da
plataforma e a mesma é descrita com maior precisão no capítulo 4 já que
foi parte integrante do trabalho desenvolvido.
Web Services
Os Web Services podem ser vistos na relação Cliente/Servidor como o
Front-End do sistema. Tal como foi referido previamente, estes é que
são responsáveis 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 acessível para o cliente e que tenha todos os serviços activos. Parte
dos Web Services são descritos com maior detalhe no capítulo 4, aqueles que
acabaram por ser feitos pelo Joaquim Tojal, devido às suas necessidades,
não são apresentados neste relatório.
3.4.2 Móvel e Carro
Objectivo
Estas duas componentes da arquitectura apesar de estarem divididas
estão na verdade integradas numa só aplicação. Aplicação que pretende
fornecer ao utilizador as seguintes funcionalidades:
41. 3.4 Arquitectura 29
Figura 3.3: Menu principal da aplicação PDA
• Assistente de viagens GPS para transportes públicos como alternativa
ao particular (Joaquim tojal).
• Processo de primeira utilização da aplicação que pode servir para
gerar ou recuperar um registo.
• Horários dos transportes públicos indicando o tipo do transporte e a
paragem de origem e destino.
• Lista de amigos presentes e lugar que ocupam, num determinado
transporte público em tempo real.
• Histórico dos conteúdos visualizados nos transportes públicos, dada
uma data de utilização e um tipo de conteúdo.
• Dados sobre o registo do utilizador no sistema, como a data de reg-
isto, o número de registo e os MAC Address dos seus dispositivos
registados.
42. 30 Plataforma carFree.ubi
Componentes
O objectivo da divisão destas duas componentes é a de vincar a diferença
entre o trabalho do Joaquim Tojal referente ao RF02 (ver 3.1.1) e o que vai
ser descrito com maior detalhe no capítulo 5 referente ao RF06 (ver 3.1.1).
Optou-se por, comodidade do utilizador, juntar tudo numa só aplicação,
mas como vai ser possível verificar a mesma está dividida e funciona de
forma independente. Isto é, se o PDA não tiver GPS a parte relativa ao
RF06 funciona, mas a parte relativa ao RF02 não.
Interface
Para se chegar ao resultado apresentado na figura 3.3 bem como no
capítulo 5 foi necessário recorrer a um processo de "desenho"de interfaces
(GDI) integrado com controlos. Os créditos da pesquisa desta técnica e
do desenho da interface principal vão para o Joaquim Tojal. Apesar de
cada um ter feito a sua parte da aplicação era obviamente incompatível
apresentar duas interfaces distintas. Deste modo, o trabalho apresentado
no capítulo 5 faz uso da técnica citada.
3.4.3 Transportes Públicos
Objectivos
Tal como ficou estabelecido no RF01 (ver 3.1.1), RF03 (ver 3.1.1), RF04
(ver 3.1.1) e RF05 (ver 3.1.1) esta aplicação pretende, de forma genérica,
disponibilizar conteúdos multimédia (música, livros, jornais, revistas, etc.)
de preferência exclusivos num ecrã táctil. O facto de fornecer conteúdos
multimédia não representa grande inovação, por mais bonita que possa
ser a interface. No entanto, o facto de isso ser feito num ecrã com qualidade
e com uma interface agradável para o utilizador, conjugado com conteúdos
que não estão disponíveis noutro lugar e uma certa adaptabilidade da
interface é sem dúvida uma mais-valia. Uma parte fundamental incidente
sobre a disponibilização de conteúdos para esta aplicação está relatada no
capítulo 4 através da descrição da Base de Dados. O restante processo, que
ainda não foi descrito, incide sobre a identificação do utilizador perante o
sistema e será explicado no capítulo 6.
43. 3.4 Arquitectura 31
Figura 3.4: Menu principal da aplicação Windows
Interface
Os créditos da pesquisa da técnica utilizada para desenvolvimento da
interface (utilização do expression blend), bem como o desenho da interface
principal vão para o André Passos. O trabalho apresentado no capítulo 6
sobre a parte referente ao login desta aplicação usa as técnicas anteriores.
3.4.4 Casa e Trabalho
Esta é a componente da arquitectura referente ao RF07 (ver 3.1.1) que
se acabou por valorizar menos. A ideia desta componente consiste na
implementação/reutilização de uma página institucional. Esta página pode
inclusivamente ser a página da empresa que queira utilizar esta plataforma.
Infelizmente, devido à falta de tempo, ninguém acabou por desenvolver
esta componente ficando a mesma para trabalho futuro.
44. 32 Plataforma carFree.ubi
3.5 Conclusão
Neste capítulo ficou descrito a plataforma carFree.ubi. Como é possível
perceber ao longo do capítulo as preocupações foram mais focadas para
a arquitectura em si do que para questões sobre a interface devido ao
trabalho desenvolvido. Neste tipo de projectos o trabalho apesar de ser
independente não pode ser desconexo. Como tal, uns preocuparam-se
mais com a interface e outras questões como foi o caso do Joaquim Tojal
para a aplicação PDA e do André Passos para aplicação Windows enquanto
o João Oliveira se preocupou com a parte de Inteligência Artificial. Sem
o trabalho de todos seria impossível chegar onde se chegou. Até aqui
foi descrito o trabalho mais teórico realizado no âmbito deste projecto.
Enquanto nos capítulos seguintes será descrito todo o trabalho prático
desenvolvido.
45. Capítulo 4
Servidor
Servidor Windows
Tal como foi referido, o servidor é a peça nuclear do sistema. Desde
cedo optou-se por configurar e trabalhar directamente com um servidor
Windows existente na sala 6.10. Este servidor não foi instalado de raíz
por motivos de licenças, sendo que o sistema operativo de base foi o
Windows XP que já se encontrava instalado na máquina. Foi concedido
temporariamente acesso exterior ao porto 80 da máquina uma vez que é
aquele com que se trabalha para disponibilização dos Web Services.
Configuração
O processo de configuração da máquina passou assim pela instalação
do IIS 6.0 e do SQL Server 2005. Para além da instalação foi necessário
proceder a algumas configurações de modo a manter um nível de segu-
rança considerado mínimo. Essas configurações passaram por limitar o
acesso à Base de Dados e à página 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 configurações 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 necessário focar a atenção noutras partes do
projecto.
1
http://193.136.67.242:50001/Servidor/Service.asmx
33
46. 34 Servidor
4.1 Base De Dados
Até ao momento ainda não foi especificada a Base de Dados. Todavia
isso vai ser feito nesta secção uma vez que o desenho e implementação da
mesma integraram-se no trabalho relativo à implementação do servidor.
4.1.1 Diagrama
A Base de Dados possui alguma complexidade como é possível verificar na
figura 4.1. Para uma melhor compreensão optou-se por dividir a descrição
da Base de Dados por componentes.
Processo de desenvolvimento
O processo de desenvolvimento da Base de Dados não pode ser con-
siderado tradicional uma vez que o diagrama foi directamente desenhado
na ferramenta administrativa do MS! (MS!) SQL Server (Microsoft SQL
Server Management Studio Express). Assim, não foi desenhado nenhum
Diagrama de Entidade-Associaçao (DEA), no entanto é de salientar que
estes diagramas são 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 criação da
BD! (BD!) em MS! SQL Server. Possivelmente até existem outras ferramen-
tas com esta potencialidade, mas esta acabou por ser a que se identificou
e explorou primeiro. Tendo-se revelado suficiente, para as necessidades e
objectivos pretendidos, não se exploraram outras ferramentas.
Vantagens
Para além da geração de scripts através do diagrama, outra grande van-
tagem de desenhar o diagrama com recurso a esta ferramenta consiste
no facto de que quem desenvolve a Base de Dados se pode abstrair total-
mente com a apresentação das tabelas. Isto é, a ferramenta possibilita tanto
um escalonamento do diagrama como disposição automática das tabelas.
Quem desenvolve só se preocupa com aquilo que realmente interessa que
é com as tabelas, os elementos das tabelas, as relações e restrições.
47. 4.1 Base De Dados 35
Figura 4.1: Diagrama da Base de Dados
48. 36 Servidor
Esclarecimentos
Para facilitar a descrição do diagrama introduzem-se alguns esclareci-
mentos sobre os símbolos presentes. No interior de cada tabela junto a de-
terminados elementos existe um símbolo de chave dourada. Isso significa
que os elementos em questão são chave primária da tabela em questão.
No caso desta Base Dados os elementos chave podem ser únicos, em pares
ou triplos. Relativamente às relações entre as tabelas, também surgem
dois símbolos distintos. Uma chave dourada e um símbolo infinito que
podem aparecer combinados de múltiplas formas. Sempre que surge uma
chave numa extremidade e uma chave na outra extremidade, significa que
a relação das tabelas é de 1 para 1. Sempre que numa extremidade surge
uma chave e noutra extremidade um infinito, significa que a relação das
tabelas é de 1 para N e vice-versa.
4.1.2 Utilizadores
Começando pelo ponto central desta Base de Dados, a tabela Utilizador
possui cinco relações distintas com outras tabelas que vão ser explicadas
mais à frente. O importante nesta tabela é que cada utilizador vai possuir
um ID_Utilizador único que o vai identificar, em algumas situações este
ID é designado por número de registo de modo a ser mais amigável para o
utilizador do sistema. Não existe nesta tabela, ou em outra qualquer, um
único elemento relativo a dados pessoais do utilizador. O sistema, tal como
está especificado no RNF02, não precisa de conhecer o nome, morada ou
qualquer outro dado pessoal do utilizador. No entanto o ID_Utilizador
nunca é suficiente para validar a identidade do utilizador tal como ficou
especificado no RNF01, sendo necessário recorrer a uma pass cifrada tam-
bém ela presente na tabela.
4.1.3 Grupos
Ainda na tabela Utilizador é possível verificar a existência de um ID_Grupo.
Esse ID_Grupo está relacionado com a tabela Grupos, na qual são iden-
tificados os grupos de utilizadores reconhecidos pela IA (Tarefa do João
Oliveira). Assim permite-se que cada utilizador apenas pertença a um
grupo, mas que cada grupo tenha vários utilizadores. De notar também
49. 4.1 Base De Dados 37
que, sempre que um Utilizador se regista, o mesmo fica a pertencer a um
grupo de pessoas ditas "indeterminadas".
4.1.4 Interface
Uma das outras relações existentes com o utilizador é a da tabela Interface.
Nesta tabela pode verificar-se a relação de 1 para 1, permitindo que um uti-
lizador não tenha estado e quando tenha apenas possua um. Isto verifica-se
no acto do registo, quando o utilizador nunca recorreu à interface existente
no interior dos transportes públicos e como tal não possui um estado de-
terminado. Este estado serve para permitir que os utilizadores tenham um
conjunto de configurações de interface ao seu dispor. Esta funcionalidade
não está patente nos requisitos tendo sido acrescentada posteriormente.
4.1.5 Conteúdos
Utilizador_Conteudo
Outra das relações feitas com o utilizador tem a ver com os conteúdos
que o mesmo já visualizou. Cada utilizador pode ter visualizado vários
conteúdos e pode inclusivamente ver o mesmo conteúdo em instantes
diferentes. A partir do momento que um conteúdo é aberto insere-se um
registo na tabela Utilizador_Conteudo que vai actualizando o elemento
estado até o mesmo sair desse conteúdo. Esse estado refere-se ao estado
propriamente do conteúdo. Se é um livro qual a página aberta, se for
um vídeo em que minuto do vídeo se encontra e por ai fora. A partir do
momento em que um utilizador sai da aplicação e deixa um conteúdo em
aberto o mesmo fica com um estado diferente de zero que posteriormente
pode ser recuperado tal como foi especificado no RF04 (ver 3.1.1). Caso um
conteúdo seja encerrado para dar lugar à visualização de outro o estado é
colocado a 0 não sendo feita mais nenhuma actualização a esse registo.
Conteudo
A tabela Conteudo está no centro dos conteúdos como está o utilizador
no centro da Base Dados. Essa tabela possui relações com tabelas de Autor,
Genero, Tipo, Editora, sendo estas do mesmo tipo de relação e outra relação
50. 38 Servidor
distinta com a tabela anteriormente vista. Isto faz com que cada conteúdo
possa pertencer a vários registos da tabela Utilizador_Conteudo. Como é
ainda possível constatar pelo diagrama, a tabela Conteudo possui vários
elementos que identificam o conteúdo. De notar que a tabela embute o
conteúdo em si, não faz nenhuma referência à localização dos conteúdos.
Isto torna a Base de Dados mais pesada, mas considerou-se que seria a
forma mais correcta de proceder.
Autor, Genero, Tipo, Editora
Todas estas tabelas foram criadas de modo a que cada conteúdo possa
ter um autor, um género, um tipo e uma editora e que cada uma destas car-
acterísticas possa estar presente em conteúdos diferentes. Relativamente
ao tipo dos conteúdos estes existem para distinguir as músicas dos livros,
etc.
4.1.6 Dispositivos
A componente relativa aos dispositivos divide-se em duas tabelas muito
simples. Numa, designada por Dispositivo, adicionam-se os diversos
dispositivos registados. Noutra, designada por Utilizador_Dispositivo,
estabelece-se a relação entre os utilizadores e os dispositivos. Isto é, esta
tabela de relação serve para permitir que cada utilizador tenha mais do
que um dispositivo. No entanto um utilizador pode não ter um disposi-
tivo associado, bem como a determinada altura, um dispositivo pode ser
desvinculado de um utilizador para passar a pertencer a outro ou simples-
mente deixar de existir. De notar ainda que, um dispositivo fica identifi-
cado pelo seu MAC Address cifrado e combinado com a chave pode servir
em determinadas situações de identificação do utilizador tal como ficou
especificado no RNF01 (ver 3.1.2) e RNF02 (ver 3.1.2).
4.1.7 Transportes
A componente dos transportes, tal como as restantes, também se rela-
ciona com o utilizador tendo como facto de que se pretende saber se
um utilizador está presente num transporte ou não. Assim a tabela de
51. 4.1 Base De Dados 39
relação Utilizador_Transporte permite que um utilizador esteja num qual-
quer transporte ocupando um determinado lugar, como pode não estar em
nenhum. De notar ainda que cada transporte possui um tipo, por exemplo
autocarro, metro, etc., e que cada tipo pode ter vários transportes. Para
além de um transporte ter um nome, uma matrícula, o número de lugares,
o mesmo possui uma latitude e longitude que se quer actualizada à medida
que o transporte se move.
Rotas
Outra parte importante na relação dos transportes é o facto dos mesmos
terem horários, isto é rotas. Esta parte é talvez a mais complexa da Base de
Dados e decidiu-se para simplificar 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 consideração que num dia apenas um transporte pode fazer
essa rota. No de um transporte fazer um percurso em contínuo durante o
dia inteiro deve-se partir essa rota de modo a que o transporte não repita
nenhuma paragem.
Paragens
As paragens juntam duas situações que se consideram compatíveis 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 possível 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 relações com as rotas dos transportes, no caso de a paragem ser um
estacionamento então esta vai possuir um preço.
52. 40 Servidor
4.2 Privacidade e Segurança
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 aplicação cliente. Isto evita
que um atacante tenha conhecimento sobre a estrutura da Base de Dados e
que sobre efeito de alguma técnica consiga injectar SQL para extrair ainda
mais informações.
Dados cifrados
Como foi possível perceber noutros pontos do relatório existem dados
cifrados na Base de Dados, nomeadamente as passwords dos utilizadores
e os MAC Address dos dispositivos. No capítulo 5 faz-se uma descrição
detalhada de como esses dados são cifrados. De momento o importante
é o motivo para a existência desses dados cifrados. Qualquer pessoa
que escute comunicações não cifradas vai conseguir interceptar e tratar os
dados passados na comunicação.
Password cifrada
Se a password não estiver cifrada basta ao atacante descobrir qual o MAC
Address do utilizador juntamente com a password não cifrada, emular esse
MAC Address e assim conseguir identificar-se nos ecrãs tácteis como sendo
alguém que não é. O perigo disso é que um atacante pode conseguir sem
autorização perceber quais são os gostos de uma outra pessoa, coisa que
do ponto de vista dos sistemas ubíquos é totalmente indesejável.
MAC Address cifrado
Já o MAC Address é cifrado por um motivo ligeiramente diferente. Hoje
em dia confia-se demasiado nas empresas que possuem a informação, mas
alguma informação não deve ser totalmente confiada. Do ponto de vista
das redes tanto existem perigos de ataque de pontos externos à rede como
de pontos internos. Inclusivamente os internos até são mais perigosos
do que os externos. Imaginando que o MAC Address não era cifrado,
53. 4.3 Métodos e Classes 41
qualquer administrador do sistema podia ter acesso à Base de Dados e
fazer associações entre utilizadores e os seus MAC Address. Cifrando estes
dados, um administrador consegue na mesma recolher muita informação
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 autenticação. Isto impossibilita que
os Web Services desenvolvidos no projecto sejam utilizados por terceiros
sem a devida autorização. Limita-se com isto, a possibilidade de atacantes
desenvolverem código que invoque os Web Services para extrair informação
de forma automatizada.
Epílogo
A segurança é um tema que despertou interesse e representou mais
um desafio na realização deste projecto, no entanto não é apresentada
aqui nenhuma solução milagrosa. Acredita-se que mais cedo ou mais
tarde seja possível contornar as barreiras implementadas. Sendo que,
considera-se necessário recorrer a uma avaliação externa para apurar até
que ponto as medidas são ou não eficientes. Apesar de tudo as medidas
não foram implementadas em vão, existe uma forte convicção sobre as
mesmas terem a sua eficiência, apesar de possivelmente existirem falhas
que até ao momento não foram detectadas.
4.3 Métodos e Classes
Em termos de desenvolvimento convêm esclarecer que os métodos apre-
sentados de seguida não foram realizados pela sequência apresentada no
relatório. Isto é, apesar de o servidor ter uma importância significativa e
estar apresentado em primeiro no relatório na verdade os métodos foram
desenvolvidos à medida que se foram tornando necessários.
54. 42 Servidor
Figura 4.2: Diagrama do VS2008 do Servidor
4.3.1 Diagrama do Visual Studio
Na figura 4.2 apresenta-se o diagrama das classes e métodos automati-
camente gerado pelo Visual Studio. De notar a presença de uma Classe
IA desenvolvida pelo João Oliveira, como tal não são apresentados nem
métodos nem maiores explicações sobre a mesma. O diagrama só con-
templa métodos desenvolvidos na realização deste projecto para evitar
qualquer tipo de confusão sobre a autoria dos mesmos. Outros métodos
foram usados para o funcionamento de partes de trabalho desenvolvidas
pelos restantes elementos, mas os mesmos não se encontram aqui listados.
4.3.2 Classe: Com
Os Web Services são, como referido anteriormente, o que vai transparecer
para fora do servidor. Eles são como uma ponte entre todas as componentes
do servidor e as aplicações cliente, pelo que todos os métodos presentes
na classe Com (do tipo Web Service) são do tipo Web Method.
55. 4.3 Métodos e Classes 43
connect
O método connect existe no âmbito do projecto para testes. Este método
basicamente estabelece a ligação entre o cliente e o servidor devolvendo
um valor booleano, sem receber qualquer tipo de argumentos.
userVal
Este método recebe um número de registo e uma password cifrada de
modo a devolver um valor booleano indicando se existe ou não um uti-
lizador com tal correspondência.
userVal2
Semelhante ao método anterior mas desta vez para validar um par difer-
ente. Mais precisamente o MAC Adress já cifrado com uma password
cifrada.
userLastTravel
Método responsável por devolver uma string devidamente formatada
correspondente à data em que um determinado utilizador viajou num
transporte público. Há que ter em conta que, para que seja possível saber
quando foi a ultima vez que um determinado utente viajou num transporte,
implica necessariamente que este tenha interagido com os ecrãs tácteis do
sistema. Por outras palavras, o método devolve a data da última interacção
com o sistema presente no interior dos transportes públicos.
userAdd
Método que permite, recebendo uma password cifrada, adicionar um
novo utilizador ao sistema. O valor devolvido por este método é um
inteiro que corresponde ao número de registo do utilizador.
transportationsType
Este método já difere um pouco dos anteriores uma vez que necessita
de devolver uma lista de dados. O método em si devolve a lista de todos
os tipos de transportes. Para isso devolve o resultado em XmlDataDoc-
ument. Integrado com o cabeçalho Extensible Markup Language (XML)
gerado automaticamente pelo Web Service o que o método faz é preencher
56. 44 Servidor
o XML com os dados de interesse. Esta técnica foi seguida sempre que
houve necessidade de trabalhar com tipos de dados mais sofisticados do
que um inteiro, uma string ou um booleano. Isto permite tornar os méto-
dos compatíveis 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
Método que devolve em XML todas as paragens de um determinado
tipo de transporte.
contentsType
Método que devolve em XML a lista de todos os tipos de conteúdos
existentes.
contentsDateList
Método que lista em XML todas as datas de visualização de conteúdos
de um determinado utilizador. De notar que as datas na Base de Dados
possuem horas, minutos e segundos, no entanto o que sai deste método
são apenas as datas com dia, mês e ano em que o utilizador recorreu ao
sistema.
transportationsList
Método 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 método recebe o número de registo de um utilizador e devolve em
XML alguns dados sobre esse registo, nomeadamente a data em que o
utilizador se registou e o grupo a que pertence.
57. 4.3 Métodos e Classes 45
devicesList
Método responsável por devolver a lista dos dispositivos de um de-
terminado utilizador. De notar que os MAC Address devolvidos estão
cifrados, ficando à responsabilidade da aplicação cliente pedir a password
ao utilizador de modo a conseguir decifrar os dados.
friendsIn
Método que dado um número de registo e o nome de um transporte
devolve a lista dos amigos presentes nesse transporte. Relembra-se que
os amigos são as pessoas que foram classificadas como sendo do mesmo
grupo.
contentsViewed
Este método devolve a lista dos conteúdos visualizados por um uti-
lizador num determinado dia e de um dado tipo. Mais uma vez, o método
recebe o número de registo do utilizador, o nome do tipo e a data devi-
damente formatada, sendo que devolve, como nos restantes casos, o XML
com a lista.
stationsStart
Método responsável por devolver as possíveis paragens de origem com
ligação a uma paragem de destino. Consegue-se fazer a diferença entre
uma paragem de origem ou destino consoante a hora em que está previsto
o transporte passar nas mesmas.
stationsEnd
Método semelhante ao anterior, mas desta vez para uma paragem de
origem o método devolve a lista das possíveis paragens de destino.
transportationsList2
Método que recebe diversos argumentos de entrada como o nome do
tipo de um transporte, o nome de uma paragem de origem e o nome de uma
paragem de destino. Para posteriormente devolver a lista dos possíveis
transportes que contemplem os requisitos introduzidos.
58. 46 Servidor
4.3.3 Classe: LigacaoBD
Esta classe é que na verdade implementa todas as chamadas à Base de
Dados necessárias. Assim optou-se, sempre que necessário, por duplicar
os nomes dos métodos da classe Com, para a classe LigacaoBD, de modo a
estes serem invocados pelos Web Services. Esta abordagem foi seguida quer
por motivos de organização como de estruturação do código desenvolvido.
De notar ainda que em cada método é aberta e fechada uma ligação à Base
de Dados.
Uma vez que já se sabe, da secção anterior, o que cada método deve fazer
apenas basta acrescentar umas ligeiras informações. Nomeadamente, é de
referir que em muitos casos a query a ser processada pela Base de Da-
dos gera o XML automaticamente. Isso faz-se adicionando se seguinte
instrução "FOR XML PATH (’Elemento’), root(’Utilizador’)" no fim de cada
query.
De seguida listam-se todos os métodos que invocaram directamente
query’s à Base de Dados.
• userVal
• userVal2
• userLastTravel
• transportationsType
• stationsList
• contentsType
• contentsDateList
• transportationsList
• userData
• devicesList
59. 4.4 Conclusão 47
Por fim surgem os métodos que necessitaram a criação e utilização de
procedimentos por serem um pouco mais complexos de implementar.
• userAdd
• friendsIn
• contentsViewed
• stationsStart
• stationsEnd
• transportationsList2
4.4 Conclusão
Este capítulo introduziu o trabalho e as preocupações tidas em consider-
ação no desenvolvimento do servidor, nomeadamente as preocupações ao
nível de segurança no armazenamento e na comunicação dos dados. Foi
também apresentada a estrutura quer da Base de Dados como do Servi-
dor e por fim a forma como os Web Services ligam todas as componentes
presentes no servidor. No capítulo seguinte será descrito o trabalho de-
senvolvido na aplicação cliente a correr em Windows Mobile, isto é o cliente
para PDA.
61. Capítulo 5
Cliente Windows Mobile
Tal como foi referido anteriormente esta aplicação possui duas compo-
nentes distintas. Numa a aplicação pretende servir de assistente de viagens
para condutores de veículos particulares, para mais informações consultar
projecto 54. Na outra, aqui descrita, a aplicação pretende fornecer infor-
mações consideradas pertinentes. No entanto, antes sequer de a aplicação
ser lançada em modo de funcionamento normal é preciso passar por um
processo de registo. Tudo isto vai ser descrito neste capítulo com maior
detalhe.
Processo de desenvolvimento
O processo de desenvolvimento foi baseado nos requisitos apresentados
e na documentação produzida de forma informal. Nessa documentação
informal consta, alguns fluxogramas, story boards da interface, cenários
de interacção e outros apontamentos.
Diagrama do Visual Studio
Para efeito informativo apresenta-se na figura 5.1 o diagrama com as
classes e métodos desenvolvidos. Ao contrário do que foi feito com o
servidor aqui não se pretende descrever cada um dos métodos uma vez
que muitos estão relacionados com acções de botões e questões relativas ao
ambiente gráfico. A abordagem vai ser mais demonstrativa e explicativa
até porque, ao contrário do servidor, nesta aplicação pode-se recorrer às
imagens da interface.
49
62. 50 Cliente Windows Mobile
Figura 5.1: Diagrama do VS2008 da aplicação Windows Mobile
63. 5.1 Registo/Login 51
5.1 Registo/Login
Começando pelo mais importante tendo em conta que o registo/login da
aplicação representa um aspecto bastante ponderado por motivos de se-
gurança. Surgiram várias abordagens possíveis para esta tarefa. Todavia
a que acabou por parecer mais eficiente e segura consiste em armazenar e
usar o número de registo do utilizador directamente no registo do Windows.
Registo do Windows
Inicialmente tinha-se pensado em recorrer a um ficheiro no qual se colo-
caria o número de registo cifrado. Nesse processo o número de registo era
cifrado e decifrado derivando a chave de um MAC Address do disposi-
tivo. No entanto rapidamente se encontraram falhas a esta implementação.
Para começar o ficheiro podia facilmente ser copiado de PDA para PDA
bastando a um atacante conhecer e conseguir emular os MAC address.
Sem excluir a possibilidade de inadvertidamente o ficheiro poder ser apa-
gado. Sendo que decidiu-se usar precisamente o mesmo processo mas
guardando o número de registo cifrado no próprio registo do Windows.
Vantagens e desvantagens
A vantagem de cifrar o número de registo directamente para o registo
do Windows é que o mesmo não se copia nem apaga com tanta facilidade,
uma vez que é preciso ter acesso local ao PDA para realizar tal operação.
A desvantagem continua a manter-se no facto de este método não impedir
que o número de registo seja replicado.
5.1.1 CryptoLib
Para proceder à cifragem e decifragem, quer nesta aplicação como na
aplicação que vai ser apresentada no capítulo seguinte, optou-se por criar
uma biblioteca criptográfica com métodos para cifrar e decifrar com toda
a comodidade. Esta biblioteca foi desenvolvida em FSharp e baseia-se na
biblioteca criptográfica do .NET.
64. 52 Cliente Windows Mobile
Objectivo
Optou-se por criar uma biblioteca auxiliar porque cada vez que se pre-
tende instanciar algum objecto da classe criptográfica do .NET para cifrar
ou decifrar é necessário manipular streams entre outras coisas. Com esta
biblioteca auxiliar facilita-se todo o processo. Basta instanciar a classe e de
seguida chamar o método adequado para cifrar ou decifrar fornecendo-
lhe o texto a cifrar ou o array de byte a decifrar, a chave e o Initialization
Vector (IV) caso necessário. A classe criada possui vários métodos para
permitir cifrar em vários 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 não esconder padrões quando as mensagens
a cifrar são grandes. No entanto como aqui não é o caso esse problema
não se verifica. Este modo não requer IV e é utilizado para cifrar e decifrar
o número de registo do utilizador na aplicação do PDA. De notar ainda
que com este modo é utilizado um padding aleatório que faz com que um
texto cifrado várias vezes com a mesma chave só resulte num criptograma
idêntico se o padding aleatório se repetir.
AES-CBC
O modo CBC por sua vez permite esconder padrões e requer a utilização
de um IV. Para além de, ao contrário do modo ECB, não necessitar de
padding aleatório 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 suficiente em
algumas situações. No caso de cifrar e decifrar o MAC Address, o modo
ECB já não é assim tão suficiente. Para além do MAC Address originar
dois blocos, logo a necessidade de esconder padrões, o facto do IV variar
é uma mais-valia para esta situação. O modo CBC é assim utilizado para
cifrar e decifrar os MAC Address dos dispositivos.
MD5 com Salt
Apesar da cifra Message-Digest algorithm 5 (MD5) ter sido quebrada há
65. 5.1 Registo/Login 53
algum tempo, ela continua a ser viável com algumas alterações, nomeada-
mente com a introdução de Salt. O MD5 ao contrário do AES é uma cifra
One-Way, ou seja irreversível, no entanto devido à descoberta de colisões
passou a ser possível explorar o MD5. Inclusivamente é possível encon-
trar Rainbow-Tables, tabelas que permitem obter o texto plano através do
criptograma, do MD5. No entanto, essas tabelas de nada servem quando
adicionado um salt ao texto a cifrar. Se o salt for fixo ainda existem algu-
mas possibilidades de tentar explorar a falha do MD5, mas variando o salt
o processo torna-se impossível (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 derivação da chave.
5.1.2 Passos do Processo
Arranque da aplicação
Dito isto pode-se finalmente descrever por completo o processo de reg-
isto/login. Quando a aplicação é executada o primeiro passo consiste em
verificar a existência do número de registo do utilizador no registo do Win-
dows. Se este existir é feito o processo de arranque do menu principal sem
sequer se decifrar o número de registo, todavia o login fica virtualmente
feito.
Decifrar o número de registo
Sempre que a aplicação necessitar do número 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 identificada como sendo do tipo Ethernet ou
WiFi. De notar que quer a leitura dos MAC Address como a derivação
de chaves em Compact Framework só é possível graças à utilização da
biblioteca OpenNetCF citada no capítulo 3.
Menu 1
No caso do registo do Windows não conter o número de registo do uti-
66. 54 Cliente Windows Mobile
Figura 5.2: Menu principal da aplicação Windows Mobile
lizador então surge um primeiro menu de boas vindas interrogando o
utilizador quanto ao seu estado de registo. Se o utilizador já estiver regis-
tado segue para um menu de login, se não segue para um menu de registo.
Menu Registo
No menu de registo é solicitada uma password ao utilizador que deve ser
repetida para confirmação. Se as mesmas forem idênticas e diferentes de
uma password vazia então a aplicação cliente cifra a password recorrendo
à cifra MD5 com salt derivado da própria password. Essa password é
enviada para o Web Service que devolve o número de registo do utilizador
criado. Esse número é 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 aplicação é lançada normalmente para o menu principal.
Menu Login
No menu de login o utilizador tem de fornecer a sua password e o próprio
número de registo. A password é cifrada, pelo processo já explicado, e
67. 5.1 Registo/Login 55
Figura 5.3: Menu 1 da aplicação Windows Mobile
Figura 5.4: Menu de login da aplicação Windows Mobile
68. 56 Cliente Windows Mobile
enviada juntamente com o número de registo para um Web Service. Se
existir uma correspondência então a aplicação cifra o número de registo e
armazena-o no registo do Windows, tal como no menu anterior. Assim que
esse processo é completado a aplicação inicia normalmente para o menu
principal.
5.2 Horários
A opção dos horários permite ter acesso à lista dos transportes e dos seus
horários tendo em consideração três 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
não sejam listadas paragens de destino ou de origem. Essas paragens só
são listadas assim que o tipo de transporte é seleccionado.
Primeiro passo
Após selecção do tipo de transporte são listadas todas as paragens rela-
cionadas com esse tipo de transporte quer nas paragens de origem como
destino. Assim neste primeiro passo não existe uma distinção entre para-
gens de origem ou de destino uma vez que todas as listadas são prováveis
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 relação pretendida com a selec-
cionada. Por exemplo se for seleccionada uma determinada paragem de
origem a aplicação cliente recebe do servidor a lista das possíveis paragens
de destino e vice-versa.
Terceiro passo
O terceiro, e último passo, consiste em seleccionar a outra paragem. A
aplicação verifica se as listas possuem todas valores seleccionados e passa
a listar os horários respectivos tendo em consideração a hora actual. Assim
apenas são listados horários a partir da hora actual e nunca horários que
já passaram.
69. 5.3 Amigos 57
Figura 5.5: Menu horários da aplicação Windows Mobile
5.3 Amigos
Na opção dos amigos o utilizador pode consultar a lista dos amigos pre-
sentes num determinado transporte. Mais uma vez, primeiro é preciso
seleccionar o tipo de transporte após isso a lista dos transportes é actual-
izada e basta ao utilizador escolher um dos transportes para saber em que
lugares do transporte vão os seus amigos. Isto claro se existirem utentes
dentro desse transporte pertencentes ao mesmo grupo que o dono do PDA.
5.4 Histórico
O histórico permite ao utilizador recuperar os nomes de alguns conteú-
dos visualizados nas suas interacções com a aplicação a correr no interior
dos transportes públicos. O funcionamento do menu é bastante simples
bastando ao utilizador seleccionar qual o tipo de conteúdo que pretende
visualizar e qual a data de utilização para de seguida lhe ser apresentada
a lista com a informação desejada.
70. 58 Cliente Windows Mobile
Figura 5.6: Menu amigos da aplicação Windows Mobile
Figura 5.7: Menu histórico da aplicação Windows Mobile
71. 5.5 Mobile Info 59
Figura 5.8: Menu Mobile Info da aplicação Windows Mobile
5.5 Mobile Info
Por fim, mas não menos importante, o menu de informação sobre o registo
do utilizador. Este menu acaba por ser o único dos menus, exceptuando o
registo/login, que requer a introdução da password. Como foi previamente
explicado os MAC Address são 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, são derivadas da password do utilizador torna-se necessário
pedir a mesma. É de realçar o facto da password apenas ser necessária
para a apresentação da lista dos MAC Address registados. A restante
informação aparece assim que o menu é aberto, sem qualquer necessidade
de introdução da password.
5.6 Conclusão
Este capítulo descreveu o trabalho desenvolvido na aplicação cliente para
Windows Mobile. Nesse trabalho consta a descrição de todo o processo
72. 60 Cliente Windows Mobile
de registo/login do utilizador aquando de uma primeira utilização da apli-
cação, contemplando o RNF01 (ver 3.1.2) e o RNF06 (ver 3.1.2). Bem como
a descrição dos restantes menus seguindo o RF06 (ver 3.1.1). A aplicação
foi testada e demonstrou-se estável. Inclusivamente foi possível validar o
correcto tratamento de diversas excepções. No capítulo seguinte passa-se
a descrever a outra aplicação cliente, desta vez para Windows.
73. Capítulo 6
Cliente Windows
Descreve-se neste capítulo a aplicação a funcionar no interior dos trans-
portes públicos. Cada utente tem à sua disposição um ecrã táctil a partir
do qual consegue interagir com a interface da aplicação. Esta foi pensada
e desenvolvida tendo em atenção o facto de não existir teclado ou rato
à disposição do utente tal como ficou patente no requisito RNF05 (ver
3.1.2). O trabalho realizado foca-se apenas na primeira parte do funciona-
mento da aplicação. Isto é, na parte de reconhecimento e autenticação dos
utilizadores.
Processo de desenvolvimento
À semelhança do que aconteceu com o desenvolvimento da aplicação
para Windows Mobile o trabalho desenvolvido nesta aplicação foi feito com
base em documentos informais e nos requisitos. Destaca-se ainda o facto
de inicialmente não ter sido previsto o desenvolvimento da interface recor-
rendo ao Expression Blend como tal até foram desenvolvidas parcialmente
duas versões desta aplicação. Uma baseada em forms do Windows mais
tradicionais e outra aqui apresentada com uma interface muito mais apela-
tiva.
Diagrama do Visual Studio
Tal como foi feito no capítulo 4 e 5, apresenta-se na figura 6.1 o diagrama
com as classes e métodos desenvolvidos. Como muitos métodos estão
61
74. 62 Cliente Windows
Figura 6.1: Diagrama do VS2008 da aplicaçao Windows
relacionados com acções de botões e questões relativas ao ambiente gráfico
os mesmos não vão ser descritos exaustivamente.
6.1 BTLib
Antes de se descrever o menu de login propriamente dito, convêm 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 instável, além de não permitir chamadas directamente do CSharp
usando as funcionalidades do .NET.
Motivação
O uso da API e o desenvolvimento de uma biblioteca de apoio foi