Relatório de Projecto de Licenciatura
Upcoming SlideShare
Loading in...5
×
 

Relatório de Projecto de Licenciatura

on

  • 2,520 views

 

Statistics

Views

Total Views
2,520
Views on SlideShare
2,520
Embed Views
0

Actions

Likes
1
Downloads
41
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Relatório de Projecto de Licenciatura Relatório de Projecto de Licenciatura Document Transcript

  • 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
  • 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
  • Conteúdo Agradecimentos i Conteúdo iii Lista de Figuras vii Acrónimos ix 1 Introdução 1 1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 carFree.ubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Contributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Organização do relatório . . . . . . . . . . . . . . . . . . . . . 8 2 Estado de Arte 11 2.1 Discussão existente . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Framework adoptada . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3 Plataforma carFree.ubi 17 3.1 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . 18 iii
  • iv CONTEÚDO 3.1.2 Requisitos não funcionais . . . . . . . . . . . . . . . . 20 3.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.1 Ecrãs tácteis . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 PDA com ou sem GPS . . . . . . . . . . . . . . . . . . 22 3.2.3 Telemóvel . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Tecnologias e Ferramentas . . . . . . . . . . . . . . . . . . . . 23 3.4 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.2 Móvel e Carro . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.3 Transportes Públicos . . . . . . . . . . . . . . . . . . . 30 3.4.4 Casa e Trabalho . . . . . . . . . . . . . . . . . . . . . . 32 3.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4 Servidor 33 4.1 Base De Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.1 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.2 Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.3 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.5 Conteúdos . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.6 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 38 4.1.7 Transportes . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 Privacidade e Segurança . . . . . . . . . . . . . . . . . . . . . 40 4.3 Métodos e Classes . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.1 Diagrama do Visual Studio . . . . . . . . . . . . . . . 42 4.3.2 Classe: Com . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.3 Classe: LigacaoBD . . . . . . . . . . . . . . . . . . . . 46 4.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
  • CONTEÚDO v 5 Cliente Windows Mobile 49 5.1 Registo/Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.1.1 CryptoLib . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.1.2 Passos do Processo . . . . . . . . . . . . . . . . . . . . 53 5.2 Horários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3 Amigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.4 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.5 Mobile Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6 Cliente Windows 61 6.1 BTLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7 Conclusão 69 7.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Bibliografia 73
  • Lista de Figuras 3.1 Esquema da plataforma carFree.ubi . . . . . . . . . . . . . . 26 3.2 Web Services Description Language (WSDL) do Servidor . . 27 3.3 Menu principal da aplicação PDA . . . . . . . . . . . . . . . 30 3.4 Menu principal da aplicação Windows . . . . . . . . . . . . . 31 4.1 Diagrama da Base de Dados . . . . . . . . . . . . . . . . . . . 35 4.2 Diagrama do VS2008 do Servidor . . . . . . . . . . . . . . . . 42 5.1 Diagrama do VS2008 da aplicação Windows Mobile . . . . . 50 5.2 Menu principal da aplicação Windows Mobile . . . . . . . . 53 5.3 Menu 1 da aplicação Windows Mobile . . . . . . . . . . . . . 54 5.4 Menu de login da aplicação Windows Mobile . . . . . . . . . 55 5.5 Menu horários da aplicação Windows Mobile . . . . . . . . . 56 5.6 Menu amigos da aplicação Windows Mobile . . . . . . . . . 57 5.7 Menu histórico da aplicação Windows Mobile . . . . . . . . 58 5.8 Menu Mobile Info da aplicação Windows Mobile . . . . . . . 59 6.1 Diagrama do VS2008 da aplicaçao Windows . . . . . . . . . 62 6.2 Lista de dispositivos . . . . . . . . . . . . . . . . . . . . . . . 64 6.3 Teclado virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.4 Exemplo de uma autenticação falhada . . . . . . . . . . . . . 66 vii
  • Acrónimos DS Desenvolvimento Sustentável SI Sistema de Informação GPS Global Positioning System VS2008 Visual Studio 2008 DEA Diagrama de Entidade-Associaçao WSDL Web Services Description Language PDA Personal Digital Assistant MAC Media Access Control API Application Programming Interface DC Developed Countries RFID Radio Frequency Identification SOA Service Oriented Architecture DLL Dynamic-link library IDE Integrated Development Environment SDK Software Development Kit IIS Internet Information Services HTTP Hypertext Transfer Protocol ix
  • x Acrónimos HTTPS HyperText Transfer Protocol Secure FTP File Transfer Protocol SMTP Simple Mail Transfer Protocol NMTP Negotiable Mail Transfer Protocol GUI Graphical User Interface IA Inteligência Artificial GDI Graphics Device Interface SQL Structured Query Language WPF Windows Presentation Foundation UBI Universidade da Beira Interior WSE Web Services Enhancements XML Extensible Markup Language IV Initialization Vector AES Advanced Encryption Standard CBC Cipher-block Chaining ECB Electronic CodeBook MD5 Message-Digest algorithm 5
  • Capítulo 1 Introdução Objectivo do 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.
  • 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.
  • 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.
  • 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
  • 6.2 Login 63 necessário por se ter considerado que os utilizadores de dispositivos móveis (PDA, Telemóvel), com bluetooth, deviam utilizar o mesmo como uma es- pécie de chave. Todo o processo de login podia ser feito esquecendo o dispositivo. Bastava usar o número de registo juntamente com a password e o utente entrava no sistema. Mas parte da segurança pretendida perdia- se uma vez que o utilizador deixava de necessitar de um objecto que o identificasse. Biblioteca A biblioteca BTLib justifica-se de forma a juntar numa única DLL todo o código C++ necessário para descoberta de dispositivos bluetooth e recolha dos seus MAC Address. Apesar do código desta biblioteca ser diminuto o desenvolvimento do mesmo necessitou algum esforço para ficar funcional. As falhas da API da Microsoft resumem-se à quantidade de problemas que surgem com ligeiras alterações no código e à fraca documentação existente. Limitando o uso da biblioteca numa DLL em C++, com métodos capazes de serem invocados pela Framework .Net, consegue-se controlar o ambiente de funcionamento da API. Esta DLL fica assim facilmente importável para qualquer projecto do Visual Studio e com duas ou três linhas de código consegue-se fazer a descoberta de dispositivos. 6.2 Login O menu de login é bastante simples e intuitivo de utilizar. Do ponto de vista do utente dos transportes públicos basta que o seu dispositivo tenha o bluetooth ligado e visível a todos para que o mesmo seja listado na interface. De seguida só lhe resta seleccionar o nome do seu dispositivo, introduzir a password utilizando o teclado virtual e premir o botão entrar. Actualização de dispositivos Do ponto de vista da aplicação o que na realidade acontece é que a todo o momento existe uma thread responsável por actualizar a lista de dispositivos encontrados. Sempre que essa pesquisa é terminada a lista dos dispositivos, que surge na interface, actualiza (ver figura 6.2).
  • 64 Cliente Windows Figura 6.2: Lista de dispositivos Teclado Virtual Por sua vez o teclado virtual só é activado quando um utente selecciona o nome de um dispositivo presente na lista. O teclado permite ao utente introduzir a sua password podendo a qualquer momento mudar o mesmo de posição ou até fecha-lo. De notar que o teclado volta a ser aberto se for seleccionado novamente o nome do dispositivo. No entanto se for seleccionado outro nome a password fica vazia. Entrar Assim que o utente tiver introduzido a sua password só lhe resta premir o botão para entrar. Nesta fase o MAC Address do dispositivo seleccionado é cifrado usando a cifra AES em modo CBC e a password cifrada com MD5 e salt. Este processo é feito de forma análoga ao descrito para a aplicação Windows Mobile, recorrendo também à biblioteca criptográfica apresentada no capítulo anterior. Por fim os dados são enviados ao servidor que terá a responsabilidade de os validar ou não. Se forem validados o utilizador passa a ter acesso ao menu principal, caso contrário a password fica vazia e o utilizador é informado que os dados não estão correctos (ver figura 6.4).
  • 6.2 Login 65 Figura 6.3: Teclado virtual Figura 6.4: Exemplo de uma autenticação falhada
  • 66 Cliente Windows Entrar Anónimo Existe ainda a possibilidade de qualquer utente entrar no sistema de forma anónima, no entanto este modo de utilização é limitado. Sair Quando um utente decide sair da aplicação basta-lhe premir o botão sair e automaticamente o menu de login é activado. Voltando ao menu de login a password fica vazia para evitar que enquanto o dispositivo se encontre em alcance alguém consiga entrar no sistema usando as credenciais do utente anterior 6.3 Conclusão Neste capítulo apresentou-se o trabalho desenvolvido para a aplicação Windows. As duas aplicações cliente combinadas com o servidor represen- tam o ponto forte desta plataforma ubíqua. Todas as aplicações apresen- tadas foram devidamente testadas e estão funcionais como é constatável pelas imagens. No capítulo seguinte finaliza-se o relatório e apresentam-se as últimas conclusões.
  • Capítulo 7 Conclusão Implementação de uma plataforma inovadora Tal como está referido na proposta do projecto, este pretende "implemen- tar uma plataforma inovadora que permite melhorar a experiência de utilização do utente de transportes públicos". Resta dizer que o objectivo principal de implementar tal plataforma ficou cumprido à semelhança dos restantes objectivos. Desenho e implementação A parte do projecto que constava realizar de forma independente con- sistiu em desenhar e implementar a plataforma de comunicação móvel e disponibilização de conteúdos. Por outras palavras, o núcleo da arquitec- tura do carFree.ubi que pode ser consultado no capítulo 3, bem como o trabalho apresentado nos capítulos 4, 5 e 6. Plano de trabalho No plano de trabalho constavam quatro tópicos que foram todos cumpri- dos. Relativamente à análise de requisitos a mesma pode ser consultada no capítulo 3, enquanto a definição da estrutura do programa a desenvolver juntamente com a descrição da implementação e testes estão concentrados nos capítulos 4, 5 e 6. Como é possível constatar pela estrutura do relatório ainda foram feitos alguns estudos teóricos sobre tecnologias e paradigmas. 67
  • 68 Conclusão Desafio Este projecto representou um desafio muito aliciante devido à necessi- dade de aplicar um conjunto bastante largo de conhecimentos adquiridos ao longo do curso e pela possibilidade de desenvolver outros, como a computação ubíqua. Sendo este um curso de Engenharia Informática, um projecto como este é tudo o que qualquer um podia desejar. Para além do projecto ter tido uma componente de instalação e configuração de sis- temas, permitiu apurar conhecimentos sobre programação para .NET 3.5, CSharp, FSharp, SQL, ADO .NET, Web Services, Windows Presentation Foundation (WPF), Drawing de interfaces e dispositivos móveis. Contemp- lando parte de matérias de disciplinas como Base de Dados, Programação Orientada a Objectos, Sistemas Operativos, Redes, Engenharia de Soft- ware, Interacção Humana Com o Computador, Sistemas Distribuídos, Se- gurança Informática, Compiladores, Organização e Gestão de Empresas e ainda Aspectos Profissionais da Informática. Dificuldades Como em qualquer projecto existiram obviamente muitas dificuldades na implementação da plataforma idealizada. Neste momento é difícil enumera-las todas, no entanto destaca-se o facto de o projecto ter um período de desenvolvimento curto (cerca de quatro meses com relatório). Algumas opções tiveram de ser tomadas rapidamente e nem sempre foi feita a devida ponderação. O importante é que todas as dificuldades foram superadas. Desde a questão de lidar com dispositivos bluetooth usando uma API pouco estável, passando pelas falhas de segurança detectadas e corrigidas ao longo da implementação. Como pela necessidade de lidar com tecnologias com as quais apenas se está familiarizado de nome e às vezes nem isso. Por fim é preciso não esquecer que a disciplina de projecto teve de ser combinada com outras disciplinas, o que limitou um pouco o espaço evolutivo da plataforma. 7.1 Resultados Participação na final nacional do Imagine CUP 2008 O resultado mais evidente da realização deste projecto é a própria plataforma. Em segundo plano fica a participação e apuramento para
  • 7.2 Trabalho Futuro 69 a final nacional do Imagine CUP em representação da Universidade da Beira Interior (UBI). A final deste concurso decorreu em Lisboa na Cul- turgest dia 20 de Maio de 2008. O processo de selecção das equipas que foram apuradas para a final nacional teve duas etapas que apuraram sete equipas participantes. Enriquecimento Pessoal Tal como se pretendia foi possível melhorar conhecimentos sobre as difi- culdades reais no desenvolvimento de aplicações ubíquas. A organização e divisão de tarefas pelo grupo de trabalho referido no primeiro capítulo também se revelaram interessantes. A interacção e coordenação no desen- volvimento da plataforma foram uma mais-valia como experiência. Bem como os conhecimentos adquiridos e expostos ao longo do relatório. Sem esquecer o que ficou por dizer como as horas passadas na Universidade, quer de noite como alguns fins-de-semana, a trabalhar para o desenvolvi- mento da plataforma. Bem como a ida a Lisboa, o nervosismo de enfrentar jornalistas e um júri constituído por elementos de prestígio nas mais di- versificadas áreas. 7.2 Trabalho Futuro Apesar de o carFree.ubi estar funcional, o mesmo não está totalmente con- cluído. Como trabalho futuro fica a necessidade de construir uma aplicação ou página web de administração da base de dados do sistema. Uma vez que o objectivo era ter a plataforma funcional os dados de teste foram in- troduzidos por intermédio de scripts. Outra funcionalidade que fica como trabalho futuro é o desenvolvimento de uma página Web para divulgação e download da aplicação, isto no caso de o carFree.ubi conseguir cativar alguém da área dos transportes. Ficam ainda sugestões de expansão da plataforma a redes de marketing que possam dirigir as suas publicidades a cada utilizador de forma moderada e controlada pelo mesmo. Isto com o objectivo de potenciar a baixa de preço dos transportes aproveitando as receitas geradas pela rede de publicidade. Como última sugestão fica também a introdução de uma ferramenta de detecção de roubos de dis- positivos. Uma vez que cada dispositivo de um utilizador fica registado no sistema pelo seu MAC Address cifrado com a password do utilizador.
  • 70 Conclusão Torna-se possível, caso o mesmo solicite, alterar o MAC cifrado para possi- bilitar que este seja detectado pelo sistema e assim se tenha conhecimento da posição do mesmo.
  • Bibliografia [1] Central Intelligence Agency. Appendix B - International Organizations and Groups, 6 2008. https://www.cia.gov/library/publications/ the-world-factbook/appendix/appendix-b.html. [2] American Public Transportation Association. Annual study shows traffic congestion worsening in cities large and small, 3 2008. http://www. publictransportation.org/resources/2207_tti_report.asp. [3] Palo Alto Research Center. In memory of Dr. Mark Weiser, 3 2008. http://www2.parc.com/csl/members/weiser/. [4] Guanling Chen and David Kotz. A Survey of Context-Aware Mobile Computing Research, 2000. [5] Stefano Russo Domenico Cotroneo, Almerindo Graziano. Security Requirements in Service Oriented Architectures for Ubiquitous Computing, 2004. [6] Yang Li and James A. Landay. Exploring Activity-Based Ubiquitous Computing: Interaction Styles, Models and Tool Support, 2006. [7] Switzerland LIFT07 conference in Geneva. Everyware: Further down the rabbit hole, 3 2008. http://light.vpod.tv/?s=0.0.133764. [8] Francisco Javier Arias Moreno. An approach of wearable computing, 2006. [9] Helder Pinto and Rui José. Activity-centered ubiquitous computing sup- port to localized activities, 2005. 71
  • 72 BIBLIOGRAFIA [10] Studies and Observations. About the Author | Everyware: The dawning age of ubiquitous computing, 3 2008. http://www. studies-observations.com/everyware/about_the_author.html. [11] Mark Weiser. The Computer for the Twenty-First Century, 1991. [12] Mark Weiser. Hot Topics: Ubiquitous Computing, 1993. [13] Mark Weiser. Some Computer Science Problems in Ubiquitous Computing, 1993. [14] Mark Weiser. The world is not a desktop, 1994.