SlideShare uma empresa Scribd logo
1 de 84
Baixar para ler offline
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
Relatório de Projecto de Licenciatura
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
Relatório de Projecto de Licenciatura
Conteúdo

Agradecimentos                                                                      i

Conteúdo                                                                          iii

Lista de Figuras                                                                  vii

Acrónimos                                                                         ix

1   Introdução                                                                     1
    1.1   Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      2
    1.2   carFree.ubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    4
    1.3   Contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     7
    1.4   Organização do relatório . . . . . . . . . . . . . . . . . . . . .       8

2   Estado de Arte                                                                11
    2.1   Discussão existente . . . . . . . . . . . . . . . . . . . . . . . .     13
    2.2   Framework adoptada . . . . . . . . . . . . . . . . . . . . . . .        15
    2.3   Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     15

3   Plataforma carFree.ubi                                                        17
    3.1   Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . .     18
          3.1.1   Requisitos funcionais . . . . . . . . . . . . . . . . . . .     18

                                         iii
iv                                                                   CONTEÚDO

           3.1.2   Requisitos não funcionais . . . . . . . . . . . . . . . .       20
     3.2   Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . .    21
           3.2.1   Ecrãs tácteis . . . . . . . . . . . . . . . . . . . . . . . .   22
           3.2.2   PDA com ou sem GPS . . . . . . . . . . . . . . . . . .          22
           3.2.3   Telemóvel . . . . . . . . . . . . . . . . . . . . . . . . .     22
     3.3   Tecnologias e Ferramentas . . . . . . . . . . . . . . . . . . . .       23
     3.4   Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . .    25
           3.4.1   Servidor . . . . . . . . . . . . . . . . . . . . . . . . . .    25
           3.4.2   Móvel e Carro . . . . . . . . . . . . . . . . . . . . . . .     28
           3.4.3   Transportes Públicos . . . . . . . . . . . . . . . . . . .      30
           3.4.4   Casa e Trabalho . . . . . . . . . . . . . . . . . . . . . .     32
     3.5   Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     32

4    Servidor                                                                      33
     4.1   Base De Dados . . . . . . . . . . . . . . . . . . . . . . . . . . .     34
           4.1.1   Diagrama . . . . . . . . . . . . . . . . . . . . . . . . .      34
           4.1.2   Utilizadores . . . . . . . . . . . . . . . . . . . . . . . .    36
           4.1.3   Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . .    36
           4.1.4   Interface . . . . . . . . . . . . . . . . . . . . . . . . . .   37
           4.1.5   Conteúdos . . . . . . . . . . . . . . . . . . . . . . . . .     37
           4.1.6   Dispositivos . . . . . . . . . . . . . . . . . . . . . . . .    38
           4.1.7   Transportes . . . . . . . . . . . . . . . . . . . . . . . .     38
     4.2   Privacidade e Segurança . . . . . . . . . . . . . . . . . . . . .       40
     4.3   Métodos e Classes . . . . . . . . . . . . . . . . . . . . . . . . .     41
           4.3.1   Diagrama do Visual Studio . . . . . . . . . . . . . . .         42
           4.3.2   Classe: Com . . . . . . . . . . . . . . . . . . . . . . . .     43
           4.3.3   Classe: LigacaoBD . . . . . . . . . . . . . . . . . . . .       46
     4.4   Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     47
CONTEÚDO                                                                          v


5   Cliente Windows Mobile                                                        49
    5.1   Registo/Login . . . . . . . . . . . . . . . . . . . . . . . . . . .     51
          5.1.1   CryptoLib . . . . . . . . . . . . . . . . . . . . . . . . .     51
          5.1.2   Passos do Processo . . . . . . . . . . . . . . . . . . . .      53
    5.2   Horários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    55
    5.3   Amigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    57
    5.4   Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   57
    5.5   Mobile Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   58
    5.6   Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     58

6   Cliente Windows                                                               61
    6.1   BTLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   62
    6.2   Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   63
    6.3   Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     67

7   Conclusão                                                                     69
    7.1   Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    70
    7.2   Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . .     71

Bibliografia                                                                       73
Relatório de Projecto de Licenciatura
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
Relatório de Projecto de Licenciatura
Acrónimos

DS     Desenvolvimento Sustentável

SI     Sistema de Informação

GPS    Global Positioning System

VS2008 Visual Studio 2008

DEA    Diagrama de Entidade-Associaçao

WSDL Web Services Description Language

PDA    Personal Digital Assistant

MAC    Media Access Control

API    Application Programming Interface

DC     Developed Countries

RFID   Radio Frequency Identification

SOA    Service Oriented Architecture

DLL    Dynamic-link library

IDE    Integrated Development Environment

SDK    Software Development Kit

IIS    Internet Information Services

HTTP Hypertext Transfer Protocol

                                    ix
x                                          Acrónimos


HTTPS HyperText Transfer Protocol Secure

FTP   File Transfer Protocol

SMTP Simple Mail Transfer Protocol

NMTP Negotiable Mail Transfer Protocol

GUI   Graphical User Interface

IA    Inteligência Artificial

GDI   Graphics Device Interface

SQL   Structured Query Language

WPF   Windows Presentation Foundation

UBI   Universidade da Beira Interior

WSE   Web Services Enhancements

XML   Extensible Markup Language

IV    Initialization Vector

AES   Advanced Encryption Standard

CBC   Cipher-block Chaining

ECB   Electronic CodeBook

MD5   Message-Digest algorithm 5
Capítulo 1

Introdução

Objectivo do 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
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-
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.
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
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.
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,
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/
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
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.
Relatório de Projecto de Licenciatura
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
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.
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.
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
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.
Relatório de Projecto de Licenciatura
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
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
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:
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
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
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
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
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:
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.
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 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.
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:
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.
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.
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.
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.
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
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.
4.1 Base De Dados                                           35




                    Figura 4.1: Diagrama da Base de Dados
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
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
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
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.
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,
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.
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.
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
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.
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.
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
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.
Relatório de Projecto de Licenciatura
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
50                                           Cliente Windows Mobile




     Figura 5.1: Diagrama do VS2008 da aplicação Windows Mobile
5.1 Registo/Login                                                      51


5.1     Registo/Login

Começando pelo mais importante tendo em conta que o registo/login 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.
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á
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-
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
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
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.
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.
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
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
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.
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
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
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura
Relatório de Projecto de Licenciatura

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Livro angular2
Livro angular2Livro angular2
Livro angular2
 
K19 k11-orientacao-a-objetos-em-java
K19 k11-orientacao-a-objetos-em-javaK19 k11-orientacao-a-objetos-em-java
K19 k11-orientacao-a-objetos-em-java
 
Br Office Writer
Br Office WriterBr Office Writer
Br Office Writer
 
Drivers de Dispositivos Linux
Drivers de Dispositivos LinuxDrivers de Dispositivos Linux
Drivers de Dispositivos Linux
 
Scilab programacao
Scilab programacaoScilab programacao
Scilab programacao
 
Caelum java-testes-xml-design-patterns-fj16
Caelum java-testes-xml-design-patterns-fj16Caelum java-testes-xml-design-patterns-fj16
Caelum java-testes-xml-design-patterns-fj16
 
DissertacaoMScValterFinal20070216
DissertacaoMScValterFinal20070216DissertacaoMScValterFinal20070216
DissertacaoMScValterFinal20070216
 
K19 k21-persistencia-com-jpa2-e-hibernate
K19 k21-persistencia-com-jpa2-e-hibernateK19 k21-persistencia-com-jpa2-e-hibernate
K19 k21-persistencia-com-jpa2-e-hibernate
 
Manualipdoc4 pt
Manualipdoc4 ptManualipdoc4 pt
Manualipdoc4 pt
 
K19 k31-csharp-e-orientacao-a-objetos
K19 k31-csharp-e-orientacao-a-objetosK19 k31-csharp-e-orientacao-a-objetos
K19 k31-csharp-e-orientacao-a-objetos
 
Apostila solid edge
Apostila solid edgeApostila solid edge
Apostila solid edge
 
Comsol 2008
Comsol 2008Comsol 2008
Comsol 2008
 
Alternativas ao Software Proprietário
Alternativas ao Software ProprietárioAlternativas ao Software Proprietário
Alternativas ao Software Proprietário
 
K19 k03-sql-e-modelo-relacional
K19 k03-sql-e-modelo-relacionalK19 k03-sql-e-modelo-relacional
K19 k03-sql-e-modelo-relacional
 
K19 k12-desenvolvimento-web-com-jsf2-e-jpa2
K19 k12-desenvolvimento-web-com-jsf2-e-jpa2K19 k12-desenvolvimento-web-com-jsf2-e-jpa2
K19 k12-desenvolvimento-web-com-jsf2-e-jpa2
 
Curso estatistica descritiva no r
Curso   estatistica descritiva no rCurso   estatistica descritiva no r
Curso estatistica descritiva no r
 
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejbK19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
K19 k23-integracao-de-sistemas-com-webservices-jms-e-ejb
 
Apostila latex
Apostila latexApostila latex
Apostila latex
 

Destaque

Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)Joel Carvalho
 
Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)Joel Carvalho
 
Verificação Automatizada de STR com UPPAAL
Verificação Automatizada de STR com UPPAALVerificação Automatizada de STR com UPPAAL
Verificação Automatizada de STR com UPPAALJoel Carvalho
 
Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)Joel Carvalho
 
Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)Joel Carvalho
 
Verificação de Sistemas de Tempo Real
Verificação de Sistemas de Tempo RealVerificação de Sistemas de Tempo Real
Verificação de Sistemas de Tempo RealJoel Carvalho
 
Dissertação Mestrado
Dissertação MestradoDissertação Mestrado
Dissertação MestradoJoel Carvalho
 

Destaque (8)

Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)
 
Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)
 
Verificação Automatizada de STR com UPPAAL
Verificação Automatizada de STR com UPPAALVerificação Automatizada de STR com UPPAAL
Verificação Automatizada de STR com UPPAAL
 
Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)
 
Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)
 
Tutorial de Uppaal
Tutorial de UppaalTutorial de Uppaal
Tutorial de Uppaal
 
Verificação de Sistemas de Tempo Real
Verificação de Sistemas de Tempo RealVerificação de Sistemas de Tempo Real
Verificação de Sistemas de Tempo Real
 
Dissertação Mestrado
Dissertação MestradoDissertação Mestrado
Dissertação Mestrado
 

Semelhante a Relatório de Projecto de Licenciatura

Apostila cdtc dotproject
Apostila cdtc dotprojectApostila cdtc dotproject
Apostila cdtc dotprojectTiago
 
Intro redes
Intro redesIntro redes
Intro redesTiago
 
Linguagem c
Linguagem cLinguagem c
Linguagem cTiago
 
Ncl e Lua - desenvolvendo aplicações interativas para tv digital
Ncl e Lua - desenvolvendo aplicações interativas para tv digitalNcl e Lua - desenvolvendo aplicações interativas para tv digital
Ncl e Lua - desenvolvendo aplicações interativas para tv digitalRafael Carvalho
 
Python gtk
Python gtkPython gtk
Python gtkTiago
 
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão FinalTcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Finalimpalador69
 
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...bentow
 
Javascript
JavascriptJavascript
JavascriptTiago
 
Planejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemasPlanejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemasTiago
 
Tunelamento
TunelamentoTunelamento
TunelamentoTiago
 

Semelhante a Relatório de Projecto de Licenciatura (20)

Apostila cdtc dotproject
Apostila cdtc dotprojectApostila cdtc dotproject
Apostila cdtc dotproject
 
Sql
SqlSql
Sql
 
Intro redes
Intro redesIntro redes
Intro redes
 
Arquitetura computadores
Arquitetura computadoresArquitetura computadores
Arquitetura computadores
 
Introdução às redes
Introdução às redesIntrodução às redes
Introdução às redes
 
Linguagem c
Linguagem cLinguagem c
Linguagem c
 
Apostila geo gebra
Apostila geo gebraApostila geo gebra
Apostila geo gebra
 
Zope
ZopeZope
Zope
 
Poojava
PoojavaPoojava
Poojava
 
Ncl e Lua - desenvolvendo aplicações interativas para tv digital
Ncl e Lua - desenvolvendo aplicações interativas para tv digitalNcl e Lua - desenvolvendo aplicações interativas para tv digital
Ncl e Lua - desenvolvendo aplicações interativas para tv digital
 
Python gtk
Python gtkPython gtk
Python gtk
 
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão FinalTcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
 
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de...
 
Javascript
JavascriptJavascript
Javascript
 
Manual sobre a ferramenta Kate - Linux
Manual sobre a ferramenta Kate - LinuxManual sobre a ferramenta Kate - Linux
Manual sobre a ferramenta Kate - Linux
 
Planejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemasPlanejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemas
 
Php
PhpPhp
Php
 
Tunelamento
TunelamentoTunelamento
Tunelamento
 
Samba
SambaSamba
Samba
 
Relatório Técnico: .NET Framework, ASP.NET MVC 3 e Silverlight
Relatório Técnico: .NET Framework, ASP.NET MVC 3 e SilverlightRelatório Técnico: .NET Framework, ASP.NET MVC 3 e Silverlight
Relatório Técnico: .NET Framework, ASP.NET MVC 3 e Silverlight
 

Mais de Joel Carvalho

Apoio ao Projecto DSAS (CET, 12º)
Apoio ao Projecto DSAS (CET, 12º)Apoio ao Projecto DSAS (CET, 12º)
Apoio ao Projecto DSAS (CET, 12º)Joel Carvalho
 
Apresentação Dissertação Mestrado
Apresentação Dissertação MestradoApresentação Dissertação Mestrado
Apresentação Dissertação MestradoJoel Carvalho
 
Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)Joel Carvalho
 
Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)Joel Carvalho
 
Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)Joel Carvalho
 
Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)Joel Carvalho
 
Minimização Autômatos
Minimização AutômatosMinimização Autômatos
Minimização AutômatosJoel Carvalho
 
Car Free Apresentacao
Car Free ApresentacaoCar Free Apresentacao
Car Free ApresentacaoJoel Carvalho
 

Mais de Joel Carvalho (12)

Apoio ao Projecto DSAS (CET, 12º)
Apoio ao Projecto DSAS (CET, 12º)Apoio ao Projecto DSAS (CET, 12º)
Apoio ao Projecto DSAS (CET, 12º)
 
Apresentação Dissertação Mestrado
Apresentação Dissertação MestradoApresentação Dissertação Mestrado
Apresentação Dissertação Mestrado
 
Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)Arquitectura de Computadores 4 (EFA, 9º ano)
Arquitectura de Computadores 4 (EFA, 9º ano)
 
Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)Arquitectura de Computadores 3 (EFA, 9º ano)
Arquitectura de Computadores 3 (EFA, 9º ano)
 
Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)Arquitectura de Computadores 2 (EFA, 9º ano)
Arquitectura de Computadores 2 (EFA, 9º ano)
 
Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)Arquitectura de Computadores 1 (EFA, 9º ano)
Arquitectura de Computadores 1 (EFA, 9º ano)
 
Minimização Autômatos
Minimização AutômatosMinimização Autômatos
Minimização Autômatos
 
carFree2
carFree2carFree2
carFree2
 
Car Free Apresentacao
Car Free ApresentacaoCar Free Apresentacao
Car Free Apresentacao
 
Sensor Networks
Sensor NetworksSensor Networks
Sensor Networks
 
Prog Din08
Prog Din08Prog Din08
Prog Din08
 
Spec#
Spec#Spec#
Spec#
 

Último

aula 1.pptx Ementa e Plano de ensino Filosofia
aula 1.pptx Ementa e  Plano de ensino Filosofiaaula 1.pptx Ementa e  Plano de ensino Filosofia
aula 1.pptx Ementa e Plano de ensino FilosofiaLucliaResende1
 
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARXA CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARXHisrelBlog
 
Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024gilmaraoliveira0612
 
Caça palavras - BULLYING
Caça palavras  -  BULLYING  Caça palavras  -  BULLYING
Caça palavras - BULLYING Mary Alvarenga
 
Ressonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptxRessonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptxPatriciaFarias81
 
Poema sobre o mosquito Aedes aegipyti -
Poema sobre o mosquito Aedes aegipyti  -Poema sobre o mosquito Aedes aegipyti  -
Poema sobre o mosquito Aedes aegipyti -Mary Alvarenga
 
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...Colaborar Educacional
 
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...Colaborar Educacional
 
Aula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptxAula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptxMarceloDosSantosSoar3
 
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123JaineCarolaineLima
 
EBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdf
EBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdfEBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdf
EBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdfIBEE5
 
Poder do convencimento,........... .
Poder do convencimento,...........         .Poder do convencimento,...........         .
Poder do convencimento,........... .WAGNERJESUSDACUNHA
 
FORMAÇÃO POVO BRASILEIRO atividade de história
FORMAÇÃO POVO BRASILEIRO atividade de históriaFORMAÇÃO POVO BRASILEIRO atividade de história
FORMAÇÃO POVO BRASILEIRO atividade de históriaBenigno Andrade Vieira
 
Depende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxDepende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxLuzia Gabriele
 
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxQUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxAntonioVieira539017
 
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptxSlides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptxLuizHenriquedeAlmeid6
 
Apresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptxApresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptxtaloAugusto8
 
Cruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegyptiCruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegyptiMary Alvarenga
 

Último (20)

aula 1.pptx Ementa e Plano de ensino Filosofia
aula 1.pptx Ementa e  Plano de ensino Filosofiaaula 1.pptx Ementa e  Plano de ensino Filosofia
aula 1.pptx Ementa e Plano de ensino Filosofia
 
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARXA CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
A CONCEPÇÃO FILO/SOCIOLÓGICA DE KARL MARX
 
Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024Atividade de matemática para simulado de 2024
Atividade de matemática para simulado de 2024
 
Caça palavras - BULLYING
Caça palavras  -  BULLYING  Caça palavras  -  BULLYING
Caça palavras - BULLYING
 
Ressonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptxRessonancia_magnetica_basica_slide_da_net.pptx
Ressonancia_magnetica_basica_slide_da_net.pptx
 
Poema sobre o mosquito Aedes aegipyti -
Poema sobre o mosquito Aedes aegipyti  -Poema sobre o mosquito Aedes aegipyti  -
Poema sobre o mosquito Aedes aegipyti -
 
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
Apresente de forma sucinta as atividades realizadas ao longo do semestre, con...
 
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
PROJETO DE EXTENSÃO - SEGURANÇA, INOVAÇÃO E SUSTENTABILIDADE PARA O BEM COMUM...
 
Aula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptxAula 6 - O Imperialismo e seu discurso civilizatório.pptx
Aula 6 - O Imperialismo e seu discurso civilizatório.pptx
 
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
SEMIOSES DO OLHAR - SLIDE PARA ESTUDO 123
 
EBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdf
EBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdfEBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdf
EBOOK LINGUAGEM GRATUITO EUDCAÇÃO INFANTIL.pdf
 
Poder do convencimento,........... .
Poder do convencimento,...........         .Poder do convencimento,...........         .
Poder do convencimento,........... .
 
FORMAÇÃO POVO BRASILEIRO atividade de história
FORMAÇÃO POVO BRASILEIRO atividade de históriaFORMAÇÃO POVO BRASILEIRO atividade de história
FORMAÇÃO POVO BRASILEIRO atividade de história
 
Depende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsxDepende De Nós! José Ernesto Ferraresso.ppsx
Depende De Nós! José Ernesto Ferraresso.ppsx
 
(42-ESTUDO - LUCAS) DISCIPULO DE JESUS
(42-ESTUDO - LUCAS)  DISCIPULO  DE JESUS(42-ESTUDO - LUCAS)  DISCIPULO  DE JESUS
(42-ESTUDO - LUCAS) DISCIPULO DE JESUS
 
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptxQUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
QUIZ - GEOGRAFIA - 8º ANO - FASES DO CAPITALISMO.pptx
 
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptxSlides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
Slides Lição 1, CPAD, O Início da Caminhada, 2Tr24, Pr Henrique.pptx
 
Apresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptxApresentação sobrea dengue educação.pptx
Apresentação sobrea dengue educação.pptx
 
Cruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegyptiCruzadinha da dengue - Mosquito Aedes aegypti
Cruzadinha da dengue - Mosquito Aedes aegypti
 
Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...
Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...Abordagens 4 (Problematização) e 5 (Síntese pessoal) do texto de Severino (20...
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
  • 5. Conteúdo Agradecimentos i Conteúdo iii Lista de Figuras vii Acrónimos ix 1 Introdução 1 1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 carFree.ubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Organização do relatório . . . . . . . . . . . . . . . . . . . . . 8 2 Estado de Arte 11 2.1 Discussão existente . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Framework adoptada . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3 Plataforma carFree.ubi 17 3.1 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . 18 iii
  • 6. iv CONTEÚDO 3.1.2 Requisitos não funcionais . . . . . . . . . . . . . . . . 20 3.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.1 Ecrãs tácteis . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 PDA com ou sem GPS . . . . . . . . . . . . . . . . . . 22 3.2.3 Telemóvel . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Tecnologias e Ferramentas . . . . . . . . . . . . . . . . . . . . 23 3.4 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.2 Móvel e Carro . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.3 Transportes Públicos . . . . . . . . . . . . . . . . . . . 30 3.4.4 Casa e Trabalho . . . . . . . . . . . . . . . . . . . . . . 32 3.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4 Servidor 33 4.1 Base De Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.1 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.2 Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.3 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.5 Conteúdos . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.6 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 38 4.1.7 Transportes . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 Privacidade e Segurança . . . . . . . . . . . . . . . . . . . . . 40 4.3 Métodos e Classes . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.1 Diagrama do Visual Studio . . . . . . . . . . . . . . . 42 4.3.2 Classe: Com . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.3 Classe: LigacaoBD . . . . . . . . . . . . . . . . . . . . 46 4.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
  • 7. CONTEÚDO v 5 Cliente Windows Mobile 49 5.1 Registo/Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.1.1 CryptoLib . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.1.2 Passos do Processo . . . . . . . . . . . . . . . . . . . . 53 5.2 Horários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3 Amigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.4 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.5 Mobile Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6 Cliente Windows 61 6.1 BTLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7 Conclusão 69 7.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Bibliografia 73
  • 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