• Nenhum resultado encontrado

Gestão e monitorização de redes de sensores sem fios via dispositivos móveis

N/A
N/A
Protected

Academic year: 2020

Share "Gestão e monitorização de redes de sensores sem fios via dispositivos móveis"

Copied!
114
0
0

Texto

(1)

João Nuno Gomes da Rocha de Castro Mota

Gestão e Monitorização de Redes de

Sensores Sem Fios via Dispositivos Móveis

João N uno Gomes da R oc ha de Cas tr o Mo ta Ges tão e Monitor ização de R edes de Sensor es Sem F

ios via Dispositiv

os Mó

(2)
(3)

Tese de Mestrado

Ciclo de Estudos Integrados Conducentes ao Grau de

Mestre em Engenharia Eletrónica Industrial e Computadores

Trabalho efetuado sob a orientação do

Professor Doutor Jorge Cabral

João Nuno Gomes da Rocha de Castro Mota

Gestão e Monitorização de Redes de

(4)
(5)

As primeiras palavras de agradecimento v˜ao para os meus pais e para a minha irm˜a, Nuno, Maria Manuela e Ana Cl´audia Mota, pelo amor, for¸ca, coragem, mo-tiva¸c˜ao, apoio educacional, financeiro, e acima de tudo pela confian¸ca que deposita-ram em mim, n˜ao s´o durante o meu percurso acad´emico, mas ao longo de toda a minha vida. Muito obrigado por tudo!

Quero tamb´em agradecer ao meu orientador Professor Doutor Jorge Cabral, pela orienta¸c˜ao, apoio, tempo, confian¸ca e compreens˜ao que teve n˜ao s´o ao longo da ela-bora¸c˜ao da disserta¸c˜ao como ao longo de v´arias etapas do meu percurso acad´emico.

Um agradecimento muito especial tamb´em `a minha namorada, Sara Campos, pela paciˆencia e compreens˜ao que teve comigo, pelos bons e carinhosos momentos que me proporcionou, e tamb´em por toda a motiva¸c˜ao e for¸ca que me deu nos momentos mais complicados.

`

As minhas primas, Daniela Gomes e Joana Magalh˜aes, por todo o apoio psi-col´ogico, carinho e bons momentos de descontra¸c˜ao que me proporcionaram durante esta etapa.

A todos os meus amigos, em especial ao Bruno Gomes, Catarina Veiga, Jaime Costa, Jos´e Costa, Jo˜ao Tavares, Manuel Costa, Nuno Alcobia, Nuno Gil Veiga, Renato Sim˜oes e Renato Vieira, por tudo e mais alguma coisa, mas principalmente por serem os melhores amigos do mundo!

Por ´ultimo, quero tamb´em agradecer n˜ao s´o todas as pessoas ligadas ao Embedded Systems Research Group como a todos os meus companheiros e colegas de curso, que direta ou indiretamente contribu´ıram para o meu sucesso acad´emico.

(6)
(7)

Um dos principais motivos para as redes de sensores sem fios ( WSN - Wireless Sensor Networks) serem consideradas uma tecnologia emergente, ´e o facto de apre-sentarem um amplo dom´ınio de aplica¸c˜ao, permitindo que v´arios tipos de dispositivos de rede se liguem a si e interajam com o meio envolvente.

Dada a necessidade de desenvolver ferramentas de interface com as WSNs, e uma vez que os dispositivos m´oveis, como os smartphones e os tablets, se estabeleceram como um dos meios mais comuns de acesso `a Internet, o objetivo principal desta disserta¸c˜ao ´e propor uma solu¸c˜ao para o desenvolvimento de um sistema que per-mita gerir e monitorizar remotamente este tipo de redes de sensores atrav´es de um dispositivo m´ovel.

O cen´ario exemplo escolhido, e para o qual o desenvolvimento deste sistema ser´a orientado, surge no contexto do projeto SustIMS. Este projeto est´a a ser realizado pelo ESRG (Embedded Systems Research Group) e tem em vista o desenvolvimento de um sistema de dete¸c˜ao de colis˜oes em rails de prote¸c˜ao rodovi´aria em co-promo¸c˜ao com a empresa Ascendi.

A arquitetura da solu¸c˜ao proposta ´e composta, para al´em da WSN, por uma base de dados, um servidor e uma aplica¸c˜ao m´ovel. A base de dados do sistema foi im-plementada em MySQL e o servidor foi implementado em JAVA com recurso a web services do tipo REST. Posteriormente, tanto o servidor MySQL como o servidor GlassFish onde foram colocados os web services, foram alojados na cloud da Amazon (Amazon EC2 - Amazon Elastic Compute Cloud ). A aplica¸c˜ao m´ovel foi desenvol-vida para a plataforma Android, e oferece ao utilizador a possibilidade de gerir toda a base de dados do sistema assim como a capacidade de monitorizar as colis˜oes em n´os sensores das redes a que este tenha acesso, com recurso a servi¸cos como o GCM (Google Cloud Messaging) e o Google Maps.

(8)

Palavras-chave: Redes de sensores sem fios; dete¸c˜ao de colis˜oes; Internet ; servidor; web services; cloud ; gest˜ao; monitoriza¸c˜ao; interface gr´afico de utilizador; dispositivo m´ovel; aplica¸c˜ao; Android.

(9)

One of the main reasons for wireless sensor networks to be considered as an emerging technology, is the fact that they present a wide application domain, by allowing many kinds of network devices to establish a connection with them and interact with the environment.

Given the need to develop interface tools in order to manage WSNs, and since mobile devices, such as smartphones and tablets, established themselves as one of the most common means of access to the Internet, the aim of this thesis is to propose a system to remotely manage and monitor sensor networks through a mobile device.

The demonstration scenario chosen for the implementation of the proposed sys-tem is part of the SustIMS project. This project is undertaken by ESRG (Embedded Systems Research Group) and aims to develop a vehicle collision detection system on road protection rails in co-promotion with the company Ascendi.

The system architecture consists of, besides the WSN, a database, a server and a mobile application. The database was implemented in MySQL and the server in JAVA, using REST type web services. The MySQL and GlassFish servers were then used to run the web services, and hosted on the Amazon Elastic Compute Cloud ). The mobile application was developed for Android, offering the user not only the pos-sibility to manage the whole system’s database but also the pospos-sibility to be notified whenever a collision is detected in sensor nodes that he can access to, using services as GCM (Google Cloud Messaging) and Google Maps.

Keywords: wireless sensor networks; collision detection; Internet ; server; web servi-ces; cloud; management; monitoring; graphical user interface; mobile device; appli-cation; Android.

(10)
(11)

1 Introdu¸c˜ao 1

1.1 Motiva¸c˜ao . . . 1

1.2 Objetivos . . . 2

1.3 Estrutura da disserta¸c˜ao . . . 2

2 Estado da Arte 3 2.1 Solu¸c˜oes Atuais . . . 3

2.1.1 A Ubiquitous Model for Wireless Sensor Networks Monitoring 3 2.1.2 @Sensor - Mobile Application to Monitor a WSN . . . 6

2.2 Redes de sensores sem fios . . . 10

2.3 Bases de Dados . . . 11

2.3.1 Modelos de Base de Dados . . . 12

2.3.2 Sistemas de Gest˜ao de Base de Dados . . . 14

2.4 Web Services . . . 16 2.4.1 Arquitetura SOAP . . . 17 2.4.2 Arquitetura REST . . . 18 2.5 Plataformas M´oveis . . . 18 2.5.1 iOS . . . 19 2.5.2 Android . . . 20 2.6 Cloud Computing . . . 20

3 An´alise e Modela¸c˜ao do Sistema 23 3.1 Requisitos do Sistema . . . 23

3.1.1 Requisitos funcionais . . . 23

3.1.2 Requisitos n˜ao funcionais . . . 24

(12)

3.3 Casos de Uso . . . 25

3.4 Especifica¸c˜ao de Software . . . 26

3.4.1 Base de Dados . . . 26

3.4.2 Servidor . . . 28

3.4.3 Aplica¸c˜ao M´ovel . . . 32

4 Implementa¸c˜ao e Resultados do Sistema 39 4.1 Base de Dados . . . 39 4.2 Servidor . . . 44 4.2.1 Model . . . 45 4.2.2 DAO . . . 46 4.2.3 Web Services . . . 49 4.3 Cloud . . . 62 4.4 Aplica¸c˜ao M´ovel . . . 63 4.4.1 MainActivity . . . 64 4.4.2 MenuActivity . . . 66 4.4.3 List*Activity . . . 69 4.4.4 New*Activity . . . 71 4.4.5 Log*Fragment . . . 74 4.4.6 ViewUserFragment . . . 74 4.4.7 ViewWsnFragment . . . 76 4.4.8 ViewNodeFragment . . . 78 4.4.9 ViewCompFragment . . . 80 4.4.10 Edit*Activity . . . 82 4.4.11 Notifica¸c˜ao de Colis˜ao . . . 83 4.4.12 Pedidos HTTP . . . 85

5 Conclus˜oes e Trabalho Futuro 87 5.1 Conclus˜oes . . . 87

5.2 Trabalho Futuro . . . 88

(13)

2.1 Diagrama arquitetural do sistema [1] . . . 4

2.2 Rede de testes [1] . . . 5

2.3 Aplica¸c˜ao para o sistema operativo m´ovel Android [1] . . . 6

2.4 Arquitetura do sistema @Sensor [2] . . . 7

2.5 WSN do sistema @Sensor [2] . . . 8

2.6 Control Station do sistema @Sensor [2] . . . 8

2.7 Android device do sistema @Sensor [2] . . . 9

2.8 Intera¸c˜ao entre componentes do sistema @Sensor [2] . . . 9

2.9 Wireless Sensor Network . . . 11

2.10 Modelo de Base de Dados Hier´arquica . . . 13

2.11 Modelo de Base de Dados em Redes . . . 13

2.12 Tabelas do Modelo Relacional . . . 14

2.13 Diagrama Cliente-Servidor . . . 17

3.1 Arquitetura do Sistema . . . 24

3.2 Diagrama de casos de uso da aplica¸c˜ao m´ovel . . . 25

3.3 Diagrama Entidade Relacionamento simplificado da base de dados do sistema . . . 27

3.4 Diagrama de camadas do servidor . . . 28

3.5 Diagrama de servi¸cos dos Utilizadores . . . 30

3.6 Diagrama de servi¸cos das WSN . . . 31

3.7 Diagrama de servi¸cos dos N´os . . . 31

3.8 Diagrama de servi¸cos dos Componentes . . . 32

3.9 Diagrama estados do ciclo de vida de uma atividade Android . . . 33

3.10 Esbo¸co do menu de login . . . 34

(14)

3.12 Esbo¸co do menu de utilizador comum . . . 34

3.13 Esbo¸co do menu de listagem de Utilizadores, WSN, N´os ou Componentes 35 3.14 Esbo¸co do menu de cria¸c˜ao de uma entidade . . . 35

3.15 Esbo¸co do menu de visualiza¸c˜ao de um utilizador (tab de informa¸c˜ao) 36 3.16 Esbo¸co do menu de visualiza¸c˜ao de um utilizador (tab de acesso a WSN) 36 3.17 Esbo¸co do menu de visualiza¸c˜ao de uma WSN ou N´o (tab de informa¸c˜ao) 37 3.18 Esbo¸co do menu de visualiza¸c˜ao de uma WSN ou N´o (tab de conte´udo da entidade) . . . 37

3.19 Esbo¸co do menu de visualiza¸c˜ao de uma WSN ou N´o (tab de localiza¸c˜ao) 37 3.20 Esbo¸co do menu de visualiza¸c˜ao de um componente (tab de informa¸c˜ao) 37 3.21 Esbo¸co do menu de visualiza¸c˜ao de um componente (tab de defini¸c˜oes) 37 3.22 Esbo¸co do menu de edi¸c˜ao de uma entidade . . . 38

4.1 Diagrama Entidade Relacionamento da base de dados . . . 40

4.2 Diagrama de camadas do servidor . . . 45

4.3 Diagrama de classes da camada model . . . 46

4.4 Diagrama de classes da camada DAO . . . 47

4.5 Diagrama de classes da camada Web Services . . . 50

4.6 Diagrama sequencial generalizado de um servi¸co . . . 56

4.7 Fluxograma do processo de login . . . 57

4.8 Fluxograma do processo de cria¸c˜ao, edi¸c˜ao, e remo¸c˜ao de um registo . 58 4.9 Fluxograma do m´etodo findAll . . . 59

4.10 Fluxograma do m´etodo findByID . . . 60

4.11 Fluxograma do m´etodo sendNot . . . 61

4.12 Terminal da m´aquina virtual (Amazon Linux AMI ) . . . 62

4.13 Classes da aplica¸c˜ao Android . . . 63

4.14 Fluxo das atividades (menus) da aplica¸c˜ao Android . . . 64

4.15 Layout associado `a classe MainActivity (menu de login) . . . 65

4.16 Fluxograma da classe MainActivity . . . 66

4.17 Layout associado `a classe MenuActivity (menu de administrador) . . 67

4.18 Layout associado `a classe MenuActivity (menu de utilizador) . . . 67

4.19 Fluxograma da classe MenuActivity . . . 68

4.20 Layout associado `a classe UserInfoActivity . . . 68

4.21 Layout associado `a classe ListUserActivity (menu de Utilizadores) . . 69 4.22 Layout associado `a classe ListWsnActivity (menu de WSNetworks) . 69

(15)

4.25 Fluxograma das classes List*Activity . . . 71 4.26 Layout associado `a classe NewUserActivity (cria¸c˜ao de Utilizador) . . 72 4.27 Layout associado `a classe NewWsnActivity (cria¸c˜ao de WSN ) . . . . 72 4.28 Layout associado `a classe NewNodeActivity (cria¸c˜ao de N´o) . . . 72 4.29 Layout associado `a classe NewCompActivity (cria¸c˜ao de Componente) 72 4.30 Fluxograma das classes New*Activity . . . 73 4.31 Layout associado `a classe Log*Fragment (log de um registo) . . . 74 4.32 Layout associado `a classe ViewUserFragment (tab de Informa¸c˜ao) . . 75 4.33 Layout associado `a classe ViewUserFragment (tab de acesso a WSNs) 75 4.34 Fluxograma da classe ViewUserFragment . . . 76 4.35 Layout associado `a classe ViewWsnFragment (tab de Informa¸c˜ao) . . 77 4.36 Layout associado `a classe ViewWsnFragment (tab de n´os da WSN ) . 77 4.37 Layout associado `a classe ViewWsnFragment (tab de mapa da WSN ) 77 4.38 Fluxograma da classe ViewWsnFragment . . . 78 4.39 Layout associado `a classe ViewNodeFragment (tab de

Informa¸c˜ao) . . . 79 4.40 Layout associado `a classe ViewNodeFragment (tab de componentes do

N´o) . . . 79 4.41 Layout associado `a classe ViewNodeFragment (tab da localiza¸c˜ao do

N´o) . . . 79 4.42 Layout associado `a classe ViewCompFragment (tab de Informa¸c˜ao) . 80 4.43 Layout associado `a classe ViewCompFragment (tab de Defini¸c˜oes) . . 80 4.44 Fluxograma da classe ViewCompFragment . . . 81 4.45 Layout associado `a classe EditUserActivity (edi¸c˜ao de Utilizador) . . 82 4.46 Layout associado `a classe EditWsnActivity (edi¸c˜ao de WSN) . . . 82 4.47 Layout associado `a classe EditNodeActivity (edi¸c˜ao de N´o) . . . 83 4.48 Layout associado `a classe EditCompActivity (edi¸c˜ao de Componente) 83 4.49 Processos associados ao servi¸co GCM . . . 83 4.50 Alerta de colis˜ao na barra de notifica¸c˜oes . . . 85 4.51 Layout associado `a classe NotificationActivity (menu de informa¸c˜ao da

colis˜ao) . . . 85 4.52 Fluxograma da classe *AsyncTask . . . 86

(16)
(17)

2.1 Quota de mercado dos sistemas operativos m´oveis no 3o trimestre de

2013 [3] . . . 19

4.1 Atributos da entidade user . . . 41

4.2 Atributos da entidade wsn . . . 42

4.3 Atributos da entidade node . . . 43

4.4 Atributos da entidade component . . . 44

4.5 URI dos web services da classe AuthREST . . . 51

4.6 URI dos web services da classe UserREST . . . 51

4.7 URI dos web services da classe WsnREST . . . 51

4.8 URI dos web services da classe NodeREST . . . 52

4.9 URI dos web services da classe ComponentREST . . . 53

4.10 URI dos web services da classe LogREST . . . 53

(18)
(19)

3.1 Objecto JSON de um utilizador . . . 29

4.1 M´etodo create da classe WsnDAO . . . 48

4.2 Servi¸co de listagem de todos os utilizadores . . . 54

(20)
(21)

AP I Application Programming Interface

DAO Data Access Object

DBM S Database Management System

EC2 Elastic Compute Cloud

ESRG Embedded Systems Research Group

GU I Graphical User Interface

HT T P Hypertext Transfer Protocol

HT T P S HyperText Transfer Protocol Secure

IBM International Business Machines

IDE Integrated Development Environment

IDM S Integrated Database Management System

IM S Information Management System

J DK Java Development Kit

J SON JavaScript Object Notation

M D5 Message-Digest algorithm 5

P L Procedural Language

(22)

RP C Remote Procedure Call

SDK Software Development Kit

SDL Software Development Laboratories

SGBD Sistemas de Gest˜ao de Bases de Dados

SM T P Simple Mail Transfer Protocol

SOAP Simple Object Access Protocol

SOC System On Chip

SQL Structured Query Language

SSL Secure Sockets Layer

U RI Uniform Resource Identifier

W SN Wireless Sensor Network

(23)

Introdu¸

ao

Neste cap´ıtulo ´e descrita a motiva¸c˜ao, os objetivos e a estrutura desta dis-serta¸c˜ao.

1.1

Motiva¸

ao

As redes de sensores sem fios (WSN - Wireless Sensor Networks) s˜ao cada vez mais utilizadas, tendo v´arios dom´ınios de aplica¸c˜ao, que v˜ao desde a monitoriza¸c˜ao de pontes e viadutos at´e `a monitoriza¸c˜ao e controlo de processos industriais cr´ıticos. As wireless sensor networks tˆem sido alvo de v´arios estudos devido ao seu grande potencial e ao largo n´umero de servi¸cos que podem fornecer.

Com este trabalho de disserta¸c˜ao pretende-se analisar e desenvolver uma solu¸c˜ao que permita gerir e monitorizar remotamente este tipo de redes de sensores, obtendo informa¸c˜oes de um modo r´apido e simples, que auxiliem a sua instala¸c˜ao e manu-ten¸c˜ao.

Os dispositivos m´oveis tˆem um papel cada vez mais importante na vida das pessoas, e com o cont´ınuo crescimento deste mercado, ´e de esperar que no futuro, o acesso `a Internet se estabele¸ca quase exclusivamente atrav´es de dispositivos m´oveis. Raz˜ao pela qual o interface gr´afico de utilizador ser´a desenvolvido para uma plata-forma m´ovel.

O sistema foi concebido de tal forma que possa ser adaptado a qualquer cen´ario do mundo real, sem que para isso seja necess´ario realizar grandes altera¸c˜oes `a sua arquitetura.

(24)

1.2. Objetivos

orientado, surge no contexto do projeto SustIMS. Este projeto est´a a ser levado a cabo pelo ESRG (Embedded Systems Research Group) e tem em vista o desenvolvimento de um sistema de dete¸c˜ao de colis˜oes em rails de prote¸c˜ao rodovi´aria em co-promo¸c˜ao com a empresa Ascendi.

1.2

Objetivos

O principal objetivo desta disserta¸c˜ao ´e desenvolver um sistema capaz de gerir e monitorizar uma rede de sensores sem fios atrav´es de um dispositivo m´ovel para o cen´ario exemplo de um sistema de dete¸c˜ao de colis˜oes em rails de prote¸c˜ao rodovi´aria. Para tal, ser´a necess´ario implementar uma base de dados, uma aplica¸c˜ao para um dispositivo m´ovel, e um servidor, sendo que este ser´a respons´avel pela comunica¸c˜ao entre a WSN, a base de dados e o dispositivo m´ovel. A aplica¸c˜ao dever´a ser imple-mentada de tal modo que forne¸ca ao utilizador a possibilidade de gerir toda a base de dados do sistema, e, uma vez que o cen´ario escolhido ´e uma WSN associada a um sistema de dete¸c˜ao de colis˜oes, o sistema dever´a ser desenvolvido para este contexto e ser capaz de detetar e notificar os utilizadores sempre que ocorra uma colis˜ao.

1.3

Estrutura da disserta¸

ao

No pr´oximo cap´ıtulo, o cap´ıtulo 2, ser´a realizada uma an´alise te´orica sobre os principais conceitos e tecnologias abordados nesta disserta¸c˜ao, assim como a an´alise de algumas solu¸c˜oes atuais para sistemas de gest˜ao e monitoriza¸c˜ao de redes de sen-sores sem fios.

De seguida, no cap´ıtulo 3 ´e descrita a an´alise e a modela¸c˜ao do sistema, isto ´e, a sua arquitetura, requisitos e casos de uso. S˜ao tamb´em especificadas as tecnologias escolhidas para integrar as componentes do sistema.

No cap´ıtulo 4 ´e descrito do modo como as principais componentes do sistema foram implementadas, assim como os resultados da aplica¸c˜ao desenvolvida.

Por ´ultimo, no cap´ıtulo 5 s˜ao apresentadas as principais conclus˜oes e algumas sugest˜oes de trabalho futuro a aplicar ao sistema implementado.

(25)

Estado da Arte

Neste cap´ıtulo ser˜ao analisadas solu¸c˜oes atuais para sistemas de monitoriza¸c˜ao de redes de sensores sem fios atrav´es de dispositivos m´oveis, e seguidamente ser´a feita uma an´alise te´orica detalhada sobre os principais conceitos e tecnologias abordados por esta disserta¸c˜ao.

2.1

Solu¸

oes Atuais

Ser˜ao agora descritas duas solu¸c˜oes propostas em artigos cient´ıficos, para siste-mas semelhantes ao proposto.

2.1.1

A Ubiquitous Model for Wireless Sensor Networks

Monitoring

A utiliza¸c˜ao das Wireless Sensor Networks no contexto de computa¸c˜ao ub´ıqua tem vindo a emergir nos ´ultimos anos com o enorme aumento do n´umero de dispo-sitivos e sistemas operativos m´oveis. Estes dispositivos m´oveis, mais especificamente os smartphones s˜ao elementos chave no controlo de redes sem fios ub´ıquas.

No artigo ”A Ubiquitous Model for Wireless Sensor Networks Monitoring” [1], ´e proposto um modelo ub´ıquo para o controlo de uma rede de sensores sem fios atrav´es de um web service do tipo REST com recurso `as tecnologias HTTP e XML. Ser´a utilizada uma base de dados para guardar toda a informa¸c˜ao das WSNs, e ser´a criado um web service segundo uma arquitetura por m´odulos que permita e facilite a adi¸c˜ao de funcionalidades, assim como uma maior escalabilidade. O servi¸co utiliza

(26)

2.1. Solu¸c˜oes Atuais

o formato de dados XML para transmitir informa¸c˜ao para os dispositivos m´oveis independentemente da plataforma do cliente.

A arquitetura proposta ´e composta por trˆes componentes: base de dados; ser-vidor e uma aplica¸c˜ao m´ovel, como ilustra a figura 2.1.

Figura 2.1: Diagrama arquitetural do sistema [1]

Para a base de dados foi utilizado o sistema de gest˜ao de base de dados MySQL. Este SGBD ´e open source, fi´avel, de grande escalabilidade e ´e suportado pela maioria dos sistemas operativos. A base de dados est´a estruturada em trˆes grupos. Um grupo de tabelas para os utilizadores e as suas permiss˜oes. Outro grupo para as informa¸c˜oes das redes de sensores sem fios, e por fim, por um grupo de tabelas com as amostras dos v´arios sensores.

Para o desenvolvimento dos web services foi escolhida a arquitetura REST-ful [4] e para o seu desenvolvimento foi utilizada a framework open-source Jersey, disponibilizando uma API (Application Programming Interface) que ser´a utilizada para aceder `as funcionalidades do mesmo. Os web services est˜ao estruturado em trˆes m´odulos: o m´odulo da base de dados, que ´e respons´avel por aceder e manipular os dados existentes na base de dados; o m´odulo de recursos, que representa os v´arios sensores registados no sistema bem como as fun¸c˜oes a eles inerentes, e pelo m´odulo de parsing, que converte os resultados em XML para serem enviados para os clientes. O formato de dados escolhido para a comunica¸c˜ao entre os web services e a

(27)

aplica¸c˜ao cliente foi o XML, pelo facto de ser suportado por um vasto n´umero de arquiteturas cliente/servidor.

O cliente envia um pedido HTTP GET ou POST ao servidor, este valida o pedido e executa a query correspondente na base de dados, retornando ao cliente a resposta no formato XML.

A figura 2.2 ilustra a rede de teste que foi criada para demonstrar e avaliar o sistema proposto. A rede apresenta v´arios tipos de sensores, tais como: temperatura; humidade e luminosidade.

Figura 2.2: Rede de testes [1]

Como GUI (Graphical User Interface) de cliente foi desenvolvida uma aplica¸c˜ao para o sistema operativo m´ovel Android. Na figura 2.3 ao lado esquerdo ´e poss´ıvel identificar o menu de login. Se a autentica¸c˜ao for bem sucedida o utilizador ser´a encaminhado para outro menu, tamb´em vis´ıvel no lado direito da figura, onde este ter´a acesso a v´arias funcionalidades organizadas por separadores/tabs.

(28)

2.1. Solu¸c˜oes Atuais

Figura 2.3: Aplica¸c˜ao para o sistema operativo m´ovel Android [1]

O separador dos sensores lista todas as redes acess´ıveis ao utilizador autenticado. Ao selecionar uma rede dessa lista, o utilizador ser´a encaminhado para um menu onde ser˜ao listados todos os sensores dessa rede e poder´a assim aceder `as funcionalidades disponibilizadas para cada sensor. No separador de hist´orico podem ser visualizadas atrav´es de um gr´afico as amostras para um determinado intervalo de tempo definido pelo utilizador. Por ultimo, no separador de configura¸c˜oes, pode ser ativada ou desativada a amostragem do estado dos sensores, assim como redefinido o intervalo de tempo entre as amostras de modo a controlar o gasto de energia e dados de rede. Em suma, foi desenvolvido um modelo de monitoriza¸c˜ao de uma rede de sensores sem fios que permite aos utilizadores a monitoriza¸c˜ao remota de uma WSN, acesso ao hist´orico e ao valor atual de um sensor. A arquitetura REST e a utiliza¸c˜ao do formato de dados XML permite a utiliza¸c˜ao dos web services por um vasto n´umero de plataformas cliente. Os testes `a aplica¸c˜ao mostraram que esta ´e fi´avel e corre sem problemas em v´arios dispositivos Android diferentes.

2.1.2

@Sensor - Mobile Application to Monitor a WSN

No artigo ”@Sensor - Mobile Application to Monitor a WSN” [2] ´e apresentada uma solu¸c˜ao para um sistema com requisitos muito semelhantes aos desta disserta¸c˜ao, por´em, com um cen´ario exemplo diferente. Esta solu¸c˜ao tamb´em prop˜oe o desenvol-vimento de uma aplica¸c˜ao m´ovel para fins de monitoriza¸c˜ao remota de uma rede de sensores sem fios.

(29)

A arquitetura desta solu¸c˜ao, ilustrada pela figura 2.4, ´e muito semelhante `a da solu¸c˜ao descrita anteriormente. Os v´arios componentes comunicam entre eles recolhendo informa¸c˜ao dos sensores de modo a monitorizar e controlar a WSN atrav´es de um dispositivo m´ovel.

Figura 2.4: Arquitetura do sistema @Sensor [2]

Os sensores podem ser instalados em v´arias ´areas de monitoriza¸c˜ao que podem ou n˜ao conter cˆamaras para capturar a ocorrˆencia de eventos. Os eventos ocorrem uma vez que sejam lidos valores que excedam valores previamente definidos. Uma vez que ocorra um evento, a esta¸c˜ao de controlo ´e informada. A WSN utilizada corresponde a um prot´otipo desenvolvido no Centro de Investiga¸c˜ao em Ciˆencia de Computa¸c˜ao e Comunica¸c˜ao de Leiria, 2.5, que se baseia no TinyOS e cont´em n´os sensores iMote2.

(30)

2.1. Solu¸c˜oes Atuais

Figura 2.5: WSN do sistema @Sensor [2]

A Control Station representa um interface entre a aplica¸c˜ao m´ovel e a rede de sensores sem fios, figura 2.6. Todas as comunica¸c˜oes entre a Control Station e os dispositivos moveis s˜ao feitas atrav´es de web services. A arquitetura de web services utilizada foi tamb´em a RESTful, que como referido anteriormente, n˜ao necessita da instala¸c˜ao de ferramentas adicionais no dispositivo m´ovel, uma vez que utiliza o pro-tocolo de comunica¸c˜ao HTTP. Os web services foram alojados no servidor Glassfish, uma vez que ´e de utiliza¸c˜ao livre e pode ser instalado em diversas plataformas.

Figura 2.6: Control Station do sistema @Sensor [2]

A aplica¸c˜ao desenvolvida permite aos utilizadores consultar os valores dos sen-sores e as cˆamaras digitais de uma determinada ´area de monitoriza¸c˜ao, e tamb´em consultar o hist´orico de alertas. ´E poss´ıvel consultar o estado dos sensores atrav´es da

(31)

planta de uma casa, pelo andar onde se situa ou por tipo de sensor. A informa¸c˜ao apresentada corresponde ao nome, valor atual, valor de alerta, localiza¸c˜ao, entre ou-tros. Como ilustrado na figura 2.7, no dispositivo m´ovel foi utilizada uma base de dados local SQLite. Esta base de dados armazena no pr´oprio dispositivo as cre-denciais do utilizador e o hist´orico de alertas dos sensores a que o utilizador est´a associado.

Figura 2.7: Android device do sistema @Sensor [2]

A figura 2.8 representa a comunica¸c˜ao entre componentes do sistema uma vez que o cliente efetue um pedido do valor de um sensor. Este pedido chega aos web services sobe a forma de um pedido HTTP GET com a identifica¸c˜ao do sensor alvo. O servi¸co comunica com a WSN para receber o valor atual, depois envia-o para o utilizador atrav´es de uma resposta em formato XML.

(32)

2.2. Redes de sensores sem fios

Ser´a agora feita uma recolha do estado da arte e an´alise te´orica das tecnologias que esta disserta¸c˜ao aborda. Ser˜ao descritos alguns modelos e sistemas de gest˜ao de base de dados, assim como arquiteturas de web services, plataformas m´oveis e o conceito de cloud computing.

2.2

Redes de sensores sem fios

Os sensores s˜ao uma tecnologia omnipresente que det´em a capacidade de am-plificar os sentidos humanos atrav´es da convers˜ao de valores f´ısicos em sinais mais simples e percet´ıveis. Hoje em dia, na maior parte dos casos, os sensores encontram-se embebidos em objetos do dia a dia e muitas vezes as pessoas n˜ao tˆem perce¸c˜ao da sua existˆencia ou sequer das implica¸c˜oes que a sua utiliza¸c˜ao acarreta. Enquanto que antes, a utiliza¸c˜ao de sensores era representada pelo interface direto entre o mundo f´ısico e a perce¸c˜ao humana, este conceito evoluiu, foram inseridas camadas de pro-cessamento e abstra¸c˜ao entre o utilizador e o mundo f´ısico. Isto ´e, os dados obtidos por um sensor s˜ao processados e at´e combinados com outro tipo de informa¸c˜ao at´e que esta seja apresentada ao utilizador, facilitando assim a sua compreens˜ao [5].

Atualmente existem v´arios meios de transmiss˜ao de informa¸c˜ao, entre os quais a transmiss˜ao sem fios [6]. Nos ´ultimos anos, os avan¸cos em minimiza¸c˜ao, projetos de baixa potˆencia, equipamentos de comunica¸c˜ao sem fios, e fontes de energia de pequena escala combinaram-se com a redu¸c˜ao dos custos de fabrica¸c˜ao tornando poss´ıvel uma nova vis˜ao tecnol´ogica: Wireless Sensor Networks [7].

As Wireless Sensor Networks s˜ao cada vez mais utilizadas e tˆem sido alvo de v´arios estudos devido ao seu grande potencial e ao largo n´umero de servi¸cos que podem fornecer.

Atualmente, a rapidez no desenvolvimento de dispositivos de comunica¸c˜ao sem fios e microprocessadores tem vindo a permitir a aplica¸c˜ao das WSNs em v´arios dom´ınios [8].

O lan¸camento de standards, tais como o IEEE 802.15.4 e o ZigBee, trouxe-ram esta tecnologia para fora dos laborat´orios de investiga¸c˜ao, estimulando assim o desenvolvimento de in´umeros produtos comerciais [9].

Uma WSN ´e definida por um conjunto de n´os que comunicam entre si. Os n´os sensores recolhem a informa¸c˜ao e transmitem-na para um n´o coordenador atrav´es de uma rede sem fios (figura 2.9), segundo uma determinada topologia [6].

(33)

Figura 2.9: Wireless Sensor Network

Comummente, as WSNs s˜ao utilizadas para monitorizar um valor carater´ıstico de um ambiente em particular. Estes valores podem ser obtidos atrav´es de sensores de diferentes tipos, tais como: temperatura, humidade, posi¸c˜ao, luminosidade, press˜ao, som, entre outros. A maior parte do trabalho de investiga¸c˜ao ligado a esta ´area foca-se na implementa¸c˜ao das WSNs e n˜ao na sua intera¸c˜ao com dispositivos atrav´es da rede.

2.3

Bases de Dados

´

E poss´ıvel generalizar, e dizer que uma base de dados ´e representada por qual-quer conjunto de dados que se relacionam de acordo com um sentido. Este sentido ga-rante que os dados crus possam ser visualizados de modo a representarem informa¸c˜ao ´

util. Nas ultimas d´ecadas as bases de dados assumiram um papel important´ıssimo para as empresas e tornaram-se a principal componente de um sistema de informa¸c˜ao [10, 11].

As bases de dados s˜ao criadas e mantidas com o objetivo estruturar dados, e a sua gest˜ao ´e realizada atrav´es de um Sistema de Gest˜ao de Bases de Dados (SGBD ) ou Database Management System (DBMS ). Estes sistemas s˜ao respons´aveis pela apresenta¸c˜ao de respostas a pedidos de informa¸c˜ao por parte do utilizador [12],

(34)

2.3. Bases de Dados

para isso disponibilizam linguagens tais como:

• Data Definition Language (DDL): Defini¸c˜ao do tipo de dados e a rela¸c˜ao entre eles;

• Data Query Language (DQL): Obten¸c˜ao e processamento da informa¸c˜ao; • Data Manipulation Language (DML): Inser¸c˜ao, modifica¸c˜ao e remo¸c˜ao de

dados.

Cada vez mais os SGBD camuflam estas linguagens com a inclus˜ao de camadas de abstra¸c˜ao entre os utilizadores e as bases de dados atrav´es de interfaces gr´aficos. Evolu´ıram, tornando-se sistemas extremamente complexos, em que o seu desenvolvi-mento requer anos de trabalho [13].

O SGBD ´e respons´avel por manter a integridade e a seguran¸ca dos dados ar-mazenados, assim como a sua recupera¸c˜ao em caso de falha do sistema. Em conjunto com a base de dados, age em conformidade com os princ´ıpios de um determinado modelo de dados [14].

2.3.1

Modelos de Base de Dados

Analise-se agora alguns modelos de dados utilizados pelos SGBD :

• Modelo Hier´arquico: O modelo Hier´arquico, criado pela IBM em meados dos anos 60, foi o primeiro modelo de dados a ser reconhecido [15]. Os dados apare-cem organizados numa estrutura em ´arvore, esta estrutura permite representar a informa¸c˜ao atrav´es rela¸c˜oes hier´arquicas de pai/filho, figura 2.10. Por´em, desta estrutura resultam limita¸c˜oes. Cada filho apenas prov´em de um pai, isto ´e, apenas s˜ao permitidas liga¸c˜oes de um para muitos [12]. Este modelo torna-se muito lento uma vez que os pedidos de informa¸c˜ao impliquem que se compare dados de v´arias hierarquias, pois para que um determinado registo possa estar associado a v´arias hierarquias ´e necess´ario replica-lo. Portanto, cada vez que seja necess´ario fazer algum tipo de altera¸c˜ao a esse registo, ser´a necess´ario alte-rar todos os registos desse tipo, em todas as hiealte-rarquias. O Windows Registry da Microsoft e o Information Management System (IMS) da IBM s˜ao as bases de dados hier´arquicas mais amplamente utilizadas do momento;

(35)

Figura 2.10: Modelo de Base de Dados Hier´arquica

• Modelo em Rede: O modelo em Rede, figura 2.11, criado por Charles Ba-chman, surgiu em 1969 como uma extens˜ao do modelo hier´arquico [12, 15], eliminando o conceito de hierarquia e permitindo que cada registo possa agir como um registo independente que pode ser relacionado com qualquer registo de qualquer outra hierarquia, evitando assim, qualquer tipo de redundˆancia nos dados armazenados [16]. Os modelo de dados em rede mais populares a n´ıvel comercial s˜ao o IDS (Integrated Data Store) pelo pr´oprio Charles Bachman e o IDMS (Integrated Database Management System) da Computer Associates [15];

Figura 2.11: Modelo de Base de Dados em Redes

• Modelo Relacional: O modelo Relacional ´e atualmente a tecnologia de arma-zenamento de dados mais utilizada [12]. Tem por base a teoria dos conjuntos e ´algebra relacional [15]. Foi sugerido na d´ecada de 1970 por Edgar Frank

(36)

2.3. Bases de Dados

Codd [17], um investigador da IBM, e deu origem a um projeto de onde resul-taram: o SGBD DB2 e a linguagem SQL (Structured Query Language) [16]. Ao contr´arios dos modelos analisados anteriormente, o modelo relacional n˜ao tem caminhos pr´e-definidos para aceder aos dados armazenados [15]. A sua estrutura consiste na disposi¸c˜ao de dados armazenados por rela¸c˜ao, ou tabela, como ilustra a figura 2.12. Cada tabela corresponde a uma rela¸c˜ao de atributos.

Figura 2.12: Tabelas do Modelo Relacional

2.3.2

Sistemas de Gest˜

ao de Base de Dados

Ser´a agora feita uma an´alise das principais carater´ısticas de alguns SGBD atu-almente utilizados.

Oracle

O Oracle ´e um SGBD que utiliza o modelo objeto-relacional [18]. A sua primeira vers˜ao surgiu em 1977 quando Larry Ellison e seus colegas de trabalho Bob Miner e Ed Oates criaram a sua empresa SDL (Software Development Laboratories) [19].

De acordo com a Gartner, a Oracle possu´ıa em 2011 50% do mercado dos SGBD [20]. Esta destaca-se ainda pela utiliza¸c˜ao da linguagem PL/SQL (Procedural Language/Structured Query Language, utilizada no processamento de transa¸c˜oes. O

(37)

SGBD da Oracle ´e utilizado por praticamente todos os sistemas de grande escala, havendo destaque para a sua forte presen¸ca em sistemas banc´arios.

Veja-se agora algumas das caracter´ısticas deste SGBD [21]:

• Todos os resultados de uma transa¸c˜ao s˜ao comprometidos ou revertidos; • A base de dados ´e transformada de um estado v´alido para outro estado v´alido.

Havendo alguma transa¸c˜ao n˜ao permitida ou alguma restri¸c˜ao que seja violada, toda a transa¸c˜ao ´e revertida;

• Os resultados de uma transa¸c˜ao s˜ao invis´ıveis para qualquer outra transa¸c˜ao at´e que esta seja completada, aumentando a seguran¸ca dos dados;

• Assim que uma transa¸c˜ao seja realizada, os seus resultados s˜ao permanentes e s˜ao mantidos mesmo que haja falhas no sistema, garantindo a manuten¸c˜ao e a prote¸c˜ao dos dados.

SQL Server

No inicio da d´ecada de 90, a Microsoft entra no mercado dos SGBD ao comprar o c´odigo do SQL Server `a Sysbase. O Microsoft SQL Server ´e um sistema de gest˜ao de base de dados relacional.

De salientar que este SGBD :

• ´E considerado desde 2002 como o SGBD mais seguro [22];

• Tem uma ´otima rela¸c˜ao qualidade/pre¸co, uma vez que o seu pre¸co ´e mais baixo que os principais concorrentes;

• Inclui o Microsoft SQL Server Management Studio Express. MySQL

MySQL ´e o SGBD relacional de utiliza¸c˜ao livre mais popular e conta com mais de 100 milh˜oes de c´opias transferidas ou distribu´ıdas ao longo da do seu ciclo de vida. ´

E a escolha mais comum no contexto de aplica¸c˜oes web [23].

Pontos fortes do sistema de gest˜ao de base de dados MySQL [24]:

• F´acil de utilizar, pois ´e poss´ıvel instalar e configurar de um servidor MySQL em muito pouco tempo;

(38)

2.4. Web Services

• Oferece uma configura¸c˜ao especifica para cada sistema atrav´es de utilit´arios de carregamento de dados, gest˜ao de mem´oria cache, entre outros;

• Pode ser instalado em praticamente todos os Sistemas Operativos;

• O MySQL ´e de utiliza¸c˜ao livre e gratuita;

• Inclui o MySQL Workbench Visual Database Designer.

2.4

Web Services

Um web service ´e um gateway de comunica¸c˜ao entre dispositivos de rede. ´E baseado no conceito de servi¸co que est´a sempre dispon´ıvel num certo local (endere¸co) e que pode ser acedido remotamente com o objetivo de obter informa¸c˜oes ou alterar o estado da maquina onde este corre (upload de dados, altera¸c˜ao de campos em bases de dados, e outros).

O objetivo de um web service ´e o de disponibilizar uma forma padronizada de interoperabilidade entre diferentes sistemas. Estes sistemas estar˜ao possivelmente implementados em tecnologias e ferramentas diferentes, correndo sobre plataformas distintas. Desta forma permite-se a integra¸c˜ao de v´arios agentes da web que ser˜ao arbitrariamente distintos, atrav´es de um meio de comunica¸c˜ao comum [25].

Definem-se genericamente num sistema assente em web services duas entidades, o cliente e o servidor. O servidor ser´a algu´em que disponibiliza o web service com a finalidade de dar acesso a alguma informa¸c˜ao ou funcionalidade que possa ser relevante para o cliente. Por exemplo, uma entidade noticiosa que disponibiliza por interm´edio de um web service a obten¸c˜ao das suas not´ıcias, e neste caso um cliente que poder´a ser por exemplo uma aplica¸c˜ao m´ovel que obt´em estas not´ıcias para as apresentar ao utilizador, 2.13.

(39)

Figura 2.13: Diagrama Cliente-Servidor

2.4.1

Arquitetura SOAP

O SOAP (Simple Object Access Protocol ) ´e um protocolo para troca de in-forma¸c˜oes estruturadas, utilizando a linguagem XML (eXtensible Markup Language). Este protocolo ´e normalmente assente sobre outros protocolos da camada de aplica¸c˜ao como o HTTP (Hypertext Transfer Protocol ) e o SMTP (Simple Mail Transfer Pro-tocol ). Tem como objetivo disponibilizar um conjunto de ferramentas b´asicas para a constru¸c˜ao de web services.

O que o SOAP permite na pr´atica ´e a execu¸c˜ao de fun¸c˜oes predefinidas do lado do servidor do web service, por parte do cliente. Esta dinˆamica est´a associada ao conceito de RPC (Remote Procedure Call ), sendo o SOAP uma implementa¸c˜ao dela. A grande vantagem do SOAP face a outras implementa¸c˜oes de RPC ´e a sua abstra¸c˜ao da plataforma e protocolo sobre o qual assenta. O seu ´unico requerimento ´e a capacidade de troca de mensagens textuais que permitam codificar objetos XML, que servir˜ao de base `a representa¸c˜ao de um “envelope” SOAP.

O suporte para utiliza¸c˜ao de SOAP ´e dado por parte das linguagens e siste-mas de desenvolvimento em que est´a a ser desenvolvida a aplica¸c˜ao, podendo existir esse suporte ou n˜ao. No caso do iOS e do Android, n˜ao existe de forma nativa o suporte para SOAP, sendo necess´aria a adi¸c˜ao de bibliotecas pr´oprias para a correta codifica¸c˜ao das mensagens.

(40)

2.5. Plataformas M´oveis

2.4.2

Arquitetura REST

A utiliza¸c˜ao da arquitetura REST (Representational State Transfer ) para cria¸c˜ao de web services ´e de certa forma uma evolu¸c˜ao do conceito SOAP, ao qual adiciona bastante liberdade.

Tal como no SOAP, existe uma abstra¸c˜ao da plataforma e do protocolo sobre o qual assenta, embora apare¸ca quase sempre associado ao protocolo HTTP. A troca de mensagens ´e textual, sendo comummente utilizado o formato de dados XML ou JSON (JavaScript Object Notation) para codificar os dados enviados por cada uma das partes.

Uma das caracter´ısticas mais importantes da arquitetura REST ´e a ausˆencia de estado por parte do servidor. Se o servidor for desligado e ligado novamente a meio de intera¸c˜ao com clientes que est˜ao a fazer uso dos web services, n˜ao dever´a ser notada nenhuma perda de funcionalidade.

Um dos conceitos base do REST ´e o de recurso. Um recurso ´e algo que pode ser acedido por interm´edio de um URI tal como uma qualquer p´agina web atrav´es de um pedido HTTP. Com este recurso podem ser executadas opera¸c˜oes POST, GET, PUT e DELETE, a partir do envio de alguns dados em JSON que descrevam a opera¸c˜ao que se pretende efetuar.

Uma das grandes vantagens da arquitetura REST face a SOAP ´e que para implementa¸c˜ao de REST apenas ´e necess´ario o suporte de HTTP e XML/JSON, sendo que ambos s˜ao suportados de base tanto por iOS como por Android. Por esse motivo, pela sua simplicidade, e pela liberdade de implementa¸c˜ao, o REST ´e a arquitetura mais utilizada no desenvolvimento de web services.

2.5

Plataformas M´

oveis

Em 1993 a IBM d´a o primeiro passo ao criar o que poder´a ser considerado o primeiro smartphone, o IBM Simon [26], que incorporava j´a um ecr˜a t´atil e capaci-dades de voz e dados. Desde ent˜ao rapidamente se seguiram novas empresas como a Palm, a Nokia e recentemente a Apple, que foram cada uma delas respons´aveis por melhorar e fazer avan¸car a no¸c˜ao de smartphone at´e ao que conhecemos hoje.

Os smartphones desde cedo tinham uma capacidade de processamento muito consider´avel para a sua escala reduzida, assim como a capacidade de comunicar atrav´es de uma liga¸c˜ao de dados, facultando o acesso `a Internet. Este facto tornou-os

(41)

alvos de muito valor para as empresas que queriam criar servi¸cos para os seus clientes que pudessem ser utilizados em qualquer lugar e contexto.

Hoje em dia, mesmo num smartphone de gama baixa poderemos encontrar uma capacidade de processamento compar´avel `a de um computador port´atil de h´a cinco anos atr´as, tendo ainda um diverso conjunto de funcionalidades como GPS, bluetooth, Wi-Fi, infravermelhos, girosc´opio, aceler´ometro, cˆamara fotogr´afica e de v´ıdeo, leitor de impress˜oes digitais, entre outros.

Atualmente o mercado dos smartphones est´a distribu´ıdo entre alguns sistemas operativos, sendo desde h´a algum tempo dominado pelo Android e iOS, com a recente adi¸c˜ao do Windows Phone que come¸ca a ganhar algum relevo. A tabela 2.1 descreve a quota de mercado de cada um dos sistemas operativos.

Tabela 2.1: Quota de mercado dos sistemas operativos m´oveis no 3o trimestre de 2013 [3]

Sistema Operativo Quota de mercado Android 81.3% iOS 13.4% Windows Phone 4.1% Blackberry 1.0% Outros 0.2%

2.5.1

iOS

O iOS ´e o sistema operativo propriet´ario da Apple. A sua primeira vers˜ao foi lan¸cada em 2007 junto com o primeiro iPhone. Esta primeira vers˜ao corria apenas as funcionalidades implementadas de raiz no sistema operativo. Permitia j´a o acesso a paginas web num formato equivalente a um computador de secret´aria e fazia uso de um teclado no ecr˜a como ´unica forma de introdu¸c˜ao de texto.

Em 2008 a Apple lan¸ca a segunda vers˜ao do iOS, e simultaneamente dispo-nibiliza publicamente o iPhone SDK (Software Development Kit ) e abre a loja de aplica¸c˜oes da Apple (Apple AppStore) que permite a qualquer empresa ou pessoa individual desenvolver aplica¸c˜oes para a plataforma e publica-las de forma paga ou gratuita ao p´ublico geral, incendiando assim o rastilho do mercado das aplica¸c˜oes para dispositivos m´oveis que atingir´a em 2013 uma escala de cerca de 20 mil milh˜oes de euros [27].

(42)

2.6. Cloud Computing

sendo apenas poss´ıvel desenvolver para esta plataforma num computador Mac, uti-lizando o iOS SDK, no IDE (Integrated Development Environment ) Xcode. A lin-guagem de programa¸c˜ao utilizada ´e Objective-C. O desenvolvimento e publica¸c˜ao de aplica¸c˜oes na loja requer a subscri¸c˜ao do programa de developer da Apple que tem um custo de 100$ anuais.

2.5.2

Android

O sistema operativo Android aparece como a aposta da Google para se introdu-zir no mercado dos smartphones. Come¸ca com a aquisi¸c˜ao da empresa Android Inc em 2005 e culmina com o lan¸camento do primeiro smartphone Android em 2008, o HTC Dream.

Um dos grandes fatores diferenciadores do Android ´e ser de c´odigo aberto, disponibilizado sob a licen¸ca Apache. Este facto permite que qualquer empresa de dispositivos m´oveis possa distribui-lo nos seus aparelhos, adicionando-lhe ainda mo-difica¸c˜oes pr´oprias como forma de adicionar vantagens competitivas sobre as outras marcas (Ex: HTC Sense, TouchWiz, etc).

Em 2009 a Google disponibilizou tamb´em o Android SDK e abriu o Android Market (atualmente Play Store), permitindo assim aos developers criar aplica¸c˜oes e distribu´ı-las, tal como na Apple AppStore. Embora lan¸cada um ano mais tarde, o Android Market ultrapassou em Outubro de 2012 a Apple AppStore em n´umero de aplica¸c˜oes dispon´ıveis na loja, e recentemente, em Junho de 2013, o n´umero total de downloads de aplica¸c˜oes, embora ficando ainda substancialmente atr´as nas receitas geradas [28].

O desenvolvimento de aplica¸c˜oes para Android pode ser realizado em qualquer uma das principais plataformas de desktop, seja ela Windows, Linux ou Mac OS, uti-lizando uma variedade de IDEs como o Eclipse, o IntelliJ, o Netbeans e recentemente o Android Studio.

2.6

Cloud Computing

O conceito de cloud computing ´e utilizado para descrever uma variedade de re-cursos computacionais partilhados e configur´aveis que podem ser acedidos atrav´es da Internet [29]. Estes recursos podem ser, por exemplo, de armazenamento, servidores, aplica¸c˜oes e servi¸cos.

(43)

Para utilizar este servi¸co ´e normalmente requerida a cria¸c˜ao de uma conta e ´e pedido ao utilizador que escolha uma m´aquina virtual com a plataforma que mais se adeque aos seus requisitos, dependendo da plataforma e da m´aquina, o servi¸co da cloud pode ou n˜ao ser gratuito. O cliente poder´a depois instalar e configurar as ferramentas e recursos que pretende que estejam dispon´ıveis na sua m´aquina, atrav´es do acesso remoto ao terminal da m´aquina por SSH (Secure Shell ).

Ser˜ao agora descritas cinco das principais carater´ısticas do modelo de cloud computing [30]:

• Um cliente pode a qualquer momento ajustar as carater´ısticas da m´aquina virtual de acordo as suas necessidades sem que para isso seja necess´ario requerer a intera¸c˜ao humana por parte da entidade prestadora do servi¸co;

• Os seus recursos est˜ao dispon´ıveis atrav´es da Internet, e s˜ao acedidos por me-canismos standard que possibilitam o acesso a partir de v´arias plataformas diferentes;

• Os recursos virtuais e f´ısicos s˜ao atribu´ıdos dinamicamente a clientes diferentes consoante estes ajustam as suas necessidades;

• As suas capacidades s˜ao fornecidas r´apida e elasticamente, isto ´e, s˜ao normal-mente ilimitadas e podem ser adquiridas a qualquer momento;

(44)
(45)

An´

alise e Modela¸

ao do Sistema

No cap´ıtulo anterior foram estudados os principais conceitos e tecnologias que envolvem este projeto de disserta¸c˜ao. Foi assim poss´ıvel perceber e definir quais as melhores op¸c˜oes a tomar de acordo com os objetivos definidos. Neste cap´ıtulo ´e descrita a an´alise e modela¸c˜ao do sistema, isto ´e, qual a sua arquitetura, quais os seus requisitos, os casos de uso, assim como a descri¸c˜ao das tecnologias escolhidas para integrar as componentes do sistema:

• Base de dados; • Servidor;

• Aplica¸c˜ao M´ovel.

3.1

Requisitos do Sistema

O sistema deve cumprir os seguintes requisitos:

3.1.1

Requisitos funcionais

• Dever˜ao existir dois tipos de utilizadores: administrador e utilizador comum. O utilizador comum apenas dever´a ser capaz de monitorizar as WSNs `as quais lhe foi garantido acesso, o administrador dever´a ser capaz de gerir a base de dados e monitorizar todas as WSNs;

(46)

3.2. Arquitetura do Sistema

• O utilizador dever´a ser notificado atrav´es de um alerta, cada vez que ocorra uma colis˜ao em algum dos n´os sensores pertencentes a uma WSN a que este tenha acesso;

• Cada utilizador dever´a poder visualizar um hist´orico de eventos e alertas (log); • Dever´a ser criado um registo no hist´orico sempre que ocorra um alerta ou seja

realizada uma altera¸c˜ao a qualquer entidade da base de dados.

3.1.2

Requisitos n˜

ao funcionais

• Comunica¸c˜ao sem fios; • Baixo custo.

3.2

Arquitetura do Sistema

A arquitetura do sistema ´e constitu´ıda por quatro componentes: cliente, servi-dor, rede de sensores sem fios e base de dados, como ilustra a figura 3.1.

Figura 3.1: Arquitetura do Sistema

Ser´a assim desenvolvida uma aplica¸c˜ao para um dispositivo m´ovel que repre-sentar´a o interface gr´afico de utilizador para gerir e monitorizar uma rede de sensores sem fios composta por n´os sensores de colis˜oes para rails de prote¸c˜ao rodovi´aria. O cliente faz pedidos ao servidor e este, por sua vez, comunica com o servidor de base

(47)

de dados e devolve uma resposta ao cliente. Cada vez que ocorre uma colis˜ao, a rede de sensores faz um pedido ao servidor, que por sua vez regista um evento na base de dados e notifica o cliente.

3.3

Casos de Uso

Abordemos agora os casos de uso do sistema: casos de uso para os utilizadores autenticados (administradores e utilizadores comuns) e n˜ao autenticados da aplica¸c˜ao m´ovel, figura 3.2.

Figura 3.2: Diagrama de casos de uso da aplica¸c˜ao m´ovel

(48)

3.4. Especifica¸c˜ao de Software

que podem aceder a diferentes funcionalidades da aplica¸c˜ao m´ovel. Um utilizador n˜ao autenticado poder´a apenas abrir a aplica¸c˜ao e proceder ao login, tornando-se desta forma um utilizador autenticado. Uma vez que o processo de autentica¸c˜ao termine, no caso do utilizador comum, este ter´a acesso ao menu de WSNs, n´os e componentes, e poder´a visualizar as entidades `as quais lhe tenha sido garantido acesso. Poder´a tamb´em ver os logs das mesmas e redefinir os valores de alerta dos sensores a partir dos quais ser´a notificado. Quanto ao administrador, para al´em das funcionalidades dispon´ıveis ao utilizador comum, este ter´a tamb´em acesso ao menu de utilizadores e poder´a tamb´em gerir todas as entidades da base de dados, isto ´e, criar, editar e remover utilizadores, WSNs, n´os e componentes, assim como garantir/remover o acesso de utilizadores a redes.

3.4

Especifica¸

ao de Software

3.4.1

Base de Dados

Esta componente ´e respons´avel pelo armazenamento e gest˜ao de acesso dos dados do sistema. Dada a necessidade deste sistema de relacionar um elevado n´umero de entidades, o modelo de dados escolhido foi o modelo relacional, pois este facilita muito a rela¸c˜ao de atributos atrav´es de tabelas.

O sistema de gest˜ao de base de dados escolhido foi o MySQL, pelas seguintes raz˜oes: ´e capaz de suportar quantidades muito elevadas de dados; ´e flex´ıvel, pois permite ser executado em v´arias plataformas Linux, UNIX e Windows; apresenta uma elevada performance uma vez que possibilita configura¸c˜oes distintas para cada sistema, desde utilit´arios de carregamentos de dados a alta velocidade, gest˜ao da mem´oria cache, entre outros; oferece recursos de seguran¸ca excecionais que garantem a prote¸c˜ao absoluta dos dados, pois s˜ao fornecidos protocolos como SSH e SSL que garantem conex˜oes seguras e protegidas, assim como ferramentas de recupera¸c˜ao e backup de dados; ´e muito f´acil de utilizar e gerir, uma vez que ´e poss´ıvel obter, instalar e configurar um sistema MySQL em menos de 15 minutos; por ´ultimo, e n˜ao menos importante, o SGBD MySQL ´e de utiliza¸c˜ao livre e gratuita [31].

A figura 3.3 representa o diagrama simplificado da base de dados do sistema. Este diagrama representa um esbo¸co do modelo que se pretende obter, do qual se destacam cinco tabelas: user ; wsn; node; component e log.

(49)

Figura 3.3: Diagrama Entidade Relacionamento simplificado da base de dados do sistema

A tabela user cont´em os atributos correspondentes aos dados pessoais de um utilizador, entre os quais, alguns de preenchimento obrigat´orio como o nome, as suas credenciais de autentica¸c˜ao e a chave estrangeira com o id do n´ıvel de permiss˜ao do utilizador guardado na tabela user level. A tabela user tem uma rela¸c˜ao com a tabela wsn de muitos para muitos, o que implica a cria¸c˜ao de uma tabela auxiliar, user on wsn, esta tabela cont´em apenas duas chaves estrangeiras que permitem a um utilizador estar associado a v´arias redes e a mesma rede estar associada a v´arios utilizadores. Por sua vez, a tabela wsn relaciona-se com a tabela node atrav´es de uma liga¸c˜ao de um para um muitos, uma vez que uma rede pode conter diversos n´os mas um n´o apenas pode estar associado a uma rede. Esta rela¸c˜ao ´e muito semelhante `a

(50)

3.4. Especifica¸c˜ao de Software

rela¸c˜ao da tabela node com a tabela component que tamb´em se relacionam atrav´es de uma liga¸c˜ao de um para muitos. Numa fase inicial, as tabelas wsn, node e component apresentam atributos muito abstratos, no entanto, ´e claro que ser´a essencial cada entidade conter atributos que identifiquem e caraterizem distintamente cada um dos registos, tais como descri¸c˜ao, mac address, entre outros. No caso do n´o e da wsn ´e tamb´em relevante conter atributos que permitam localizar geograficamente cada um dos seus elementos. Cada vez que ocorra algum tipo de altera¸c˜ao aos registos das outras tabelas assim como a ocorrˆencia de uma colis˜ao, dever´a ser criado um registo na tabela log, raz˜ao pela qual esta tabela desempenha um papel fundamental no que toca `a monitoriza¸c˜ao da rede. Tem como principais atributos: a mensagem, onde ser´a descrito o evento ocorrido; a data de registo; o id do utilizador que realizou a opera¸c˜ao e a chave estrangeira com o id do tipo de mensagem, uma vez que este se encontra guardado numa tabela `a parte.

3.4.2

Servidor

Conforme o diagrama da figura 3.4, o servidor ser´a desenvolvido em trˆes cama-das.

Figura 3.4: Diagrama de camadas do servidor

• Camada Model : Respons´avel pelas classes que caracterizam as tabelas da base de dados;

(51)

• Camada DAO (Data Access Object : Respons´avel pelas classes que englo-bam os m´etodos de acesso `a base de dados atrav´es de queries;

• Camada Web Services: Respons´avel pela gest˜ao de pedidos e respostas por parte do cliente e base de dados.

Os web services s˜ao respons´aveis pela comunica¸c˜ao entre o cliente e a base de dados e desempenham um papel fundamental neste projeto. Ap´os a an´alise realizada no cap´ıtulo 2, chegou-se `a conclus˜ao que a escolha deveria recair sobre a arquite-tura REST (Representational State Transfer ), devido `a sua escalabilidade, desempe-nho, flexibilidade e principalmente devido `a sua simplicidade, uma vez que comunica atrav´es do protocolo HTTP. O protocolo HTTP permite realizar pedidos atrav´es de m´etodos CRUD (Create, Read, Update, Delete), respetivamente, POST, GET, PUT e DELETE que podem ser executados a partir da aplica¸c˜ao cliente sem que para isso seja necess´aria a instala¸c˜ao de qualquer tipo de ferramenta complementar. ´E atrav´es destes pedidos que o utilizador ´e capaz de manipular a base de dados assim como receber informa¸c˜oes da rede. As respostas aos pedidos HTTP ser˜ao dadas no formato JSON, um formato de dados em texto simples e por isso leve, de enorme facilidade de parse e manipula¸c˜ao com recurso a bibliotecas especificas, e de grande flexibilidade uma vez que ´e independente de qualquer tipo de linguagem. O c´odigo da listagem 3.1 ´e referente ao objeto JSON do registo de um utilizador.

Listagem 3.1: Objecto JSON de um utilizador 1 {

2 "user":{ 3 "idUser":1,

4 "name":"Joao Nuno",

5 "birthDate":"555375600000", 6 "phone":"914157372",

7 "email":"jngrcm@gmail.com",

8 "address":"Rua Prof. Aurora Araujo Almeida n19", 9 "regDate":"1377468338467", 10 "username":"admin", 11 "idUserLevel":{ 12 "idUserLevel":1, 13 "permission":"admin" 14 } 15 } 16 }

(52)

3.4. Especifica¸c˜ao de Software

Foi realizado um esbo¸co dos diagramas dos servi¸cos que ser˜ao necess´arios para operar sob as principais entidades/tabelas da base de dados. S˜ao descritos os seus m´etodos, o URI (Uniform Resource Identifier ) e a maneira como estes se relacionam.

A figura 3.5 representa o diagrama dos servi¸cos relacionados com o recurso User. Ser˜ao necess´arios servi¸cos para: execu¸c˜ao do login e logout do utilizador; cria¸c˜ao, edi¸c˜ao e remo¸c˜ao de um utilizador; garantir/remover o acesso de um utilizador a uma WSN ; pesquisa de um utilizador, lista de utilizadores, log e lista de acessos de um utilizador.

Figura 3.5: Diagrama de servi¸cos dos Utilizadores

A figura 3.6 ilustra o diagrama dos servi¸cos relacionados com o recurso Wsn. Ser˜ao necess´arios servi¸cos para: cria¸c˜ao, edi¸c˜ao e remo¸c˜ao de uma WSN ; pesquisa de uma WSN, log de uma WSN, lista de WSNs, n´os de uma WSN e da lista de WSNs a que um determinado utilizador tem acesso.

(53)

Figura 3.6: Diagrama de servi¸cos das WSN

A figura 3.7 representa o diagrama dos servi¸cos relacionados com o recurso Node. Ser˜ao necess´arios servi¸cos para: cria¸c˜ao, edi¸c˜ao e remo¸c˜ao de um n´o; altera¸c˜ao da WSN a que um n´o pertence; pesquisa de um n´o, log de um n´o, lista de n´os, de componentes de um n´o e de n´os a que um determinado utilizador tem acesso.

(54)

3.4. Especifica¸c˜ao de Software

A figura 3.8 representa o diagrama dos servi¸cos relacionados com o recurso Component. Ser˜ao necess´arios servi¸cos para: cria¸c˜ao, edi¸c˜ao e remo¸c˜ao de um com-ponente; alterar o n´o a que um componente pertence e o valor de alerta dos sensores a partir do qual o utilizador ´e notificado; pesquisa de um componente, log de um com-ponente, lista de componentes e lista de componentes associados a um determinado utilizador.

Figura 3.8: Diagrama de servi¸cos dos Componentes

3.4.3

Aplica¸

ao M´

ovel

O sistema operativo escolhido para o desenvolvimento da aplica¸c˜ao m´ovel foi o Android. Esta decis˜ao foi tomada tendo em conta alguns aspetos analisados no cap´ıtulo 2, tais como: a enorme ascens˜ao que o sistema operativo teve nos ´ultimos anos; a quota que assumiu rapidamente no mercado; a flexibilidade multi plataforma em que o seu ambiente de desenvolvimento pode ser utilizado e tamb´em o baixo custo de um dispositivo Android quando comparado a um dispositivo iOS.

Esta decis˜ao implica que a linguagem de programa¸c˜ao a utilizar seja JAVA e o ambiente de desenvolvimento escolhido foi o Eclipse IDE, pois apresenta in´umeras ferramentas que facilitam o desenvolvimento de aplica¸c˜oes para dispositivos Android. A figura 3.9 ilustra o diagrama de estados do ciclo de vida de uma atividade Android [32]. Apesar de uma atividade poder realizar m´ultiplas transi¸c˜oes entre os v´arios estados do seu ciclo de vida, ela apenas se pode manter est´atica em um destes

(55)

trˆes:

• Resumed: Neste estado a atividade est´a a ser apresentada ao utilizador e este poder´a interagir com ela;

• Paused: Neste estado a atividade est´a a ser executada em segundo plano, ta-pada por uma atividade parcialmente transparente que se encontra em primeiro plano. O utilizador apenas poder´a interagir com a atividade em primeiro plano;

• Stopped: Neste estado a atividade est´a completamente escondida do utilizador, continuando a ser considerada como estando em background, a sua instˆancia ´e retida, no entanto, n˜ao pode executar nenhum c´odigo.

Figura 3.9: Diagrama estados do ciclo de vida de uma atividade Android

Nesta fase, com recurso `a ferramenta FluidUI, foram desenhados alguns esbo¸cos de como ser˜ao os menus da aplica¸c˜ao, tentando criar menus user friendly que ao mesmo tempo sejam capazes de satisfazer todos os requisitos do sistema.

A figura 3.10 representa o primeiro menu que ir´a surgir ao utilizador uma vez que inicie a aplica¸c˜ao, o menu de login, onde o utilizador dever´a introduzir as suas credenciais e proceder `a autentica¸c˜ao.

(56)

3.4. Especifica¸c˜ao de Software

Figura 3.10: Esbo¸co do menu de login

Uma vez terminado o processo de autentica¸c˜ao, o utilizador dever´a avan¸car para o menu principal, esse menu ter´a duas vertentes dependendo do seu n´ıvel de permiss˜ao. Poder´a ser lan¸cado o menu de administrador ou o menu de utilizador comum, figura 3.11 e 3.12 respetivamente.

Figura 3.11: Esbo¸co do menu de

administrador

Figura 3.12: Esbo¸co do menu de

utilizador comum

Neste ponto, o utilizador poder´a, dependendo da sua permiss˜ao, optar por seguir para diferentes menus consoante o bot˜ao pressionado: ”Utilizadores”;

(57)

”WS-Networks”; ”N´os”; ou ”Componentes”. Cada um desses bot˜oes levar´a o utilizador a um menu semelhante, figura 3.13, onde ser˜ao listados todos os registos da respetiva entidade e o utilizador ter´a ao seu dispor a op¸c˜ao de criar um novo registo, visualizar um registo, ou o respetivo log.

Figura 3.13: Esbo¸co do menu de listagem de Utilizadores, WSN, N´os ou Componentes

No caso do utilizador ter escolhido criar um novo registo, ser´a lan¸cado um menu como o da figura 3.14.

(58)

3.4. Especifica¸c˜ao de Software

Se a op¸c˜ao tiver sido visualizar um registo, dependendo da entidade, surgiram menus diferentes. Caso seja um utilizador, ser´a lan¸cado o menu das figuras 3.15 e 3.16. Este menu ter´a dois separadores/tabs, onde ser´a poss´ıvel visualizar os dados do utilizador, as WSNs a que este tem acesso, e tamb´em editar ou remover o seu registo na base de dados.

Figura 3.15: Esbo¸co do menu de

visualiza¸c˜ao de um utilizador (tab de

informa¸c˜ao)

Figura 3.16: Esbo¸co do menu de

visualiza¸c˜ao de um utilizador (tab de

acesso a WSN)

Caso seja uma WSN ou um n´o, ser´a lan¸cado um menu semelhante ao das figuras 3.17, 3.18 e 3.19. Este menu ter´a trˆes tabs onde ser´a poss´ıvel visualizar os dados da WSN /n´o, os n´os/componentes a si associados, a localiza¸c˜ao do n´o ou n´os (pertencentes) no caso de se tratar de um registo de uma WSN, e tamb´em editar ou remover o seu registo na base de dados.

(59)

Figura 3.17: Esbo¸co do menu de visualiza¸c˜ao de uma WSN ou N´o (tab de informa¸c˜ao) Figura 3.18: Esbo¸co do menu de visualiza¸c˜ao de uma WSN ou N´o (tab de

conte´udo da entidade)

Figura 3.19: Esbo¸co do

menu de visualiza¸c˜ao de

uma WSN ou N´o (tab de

localiza¸c˜ao)

Caso o registo selecionado seja um componente, ser´a lan¸cado o menu das figuras 3.20 e 3.21. Este menu ter´a dois tabs onde ser´a poss´ıvel visualizar os dados do componente, alterar o valor de alerta para as notifica¸c˜oes desse componente (no caso de ser um sensor), e editar ou remover o seu registo na base de dados.

Figura 3.20: Esbo¸co do menu de

visualiza¸c˜ao de um componente (tab de

informa¸c˜ao)

Figura 3.21: Esbo¸co do menu de

visualiza¸c˜ao de um componente (tab de

(60)

3.4. Especifica¸c˜ao de Software

Aquando da visualiza¸c˜ao de um registo, se o utilizador desejar edita-lo, poder´a fazˆe-lo pressionando o bot˜ao ”Editar”. Ser´a ent˜ao lan¸cado um menu semelhante ao menu de cria¸c˜ao desse registo, ilustrado pela figura 3.22, em que difere apenas no facto dos campos de introdu¸c˜ao surgirem preenchidos com os dados atuais desse mesmo registo.

(61)

Implementa¸

ao e Resultados do

Sistema

No cap´ıtulo 3 foi descrita a an´alise e a modela¸c˜ao da solu¸c˜ao proposta para um sistema de gest˜ao e monitoriza¸c˜ao de uma rede de sensores sem fios para este cen´ario particular. Foram definidas as tecnologias a utilizar e tamb´em algumas estrat´egias para a implementa¸c˜ao da base de dados, do servidor, e da aplica¸c˜ao Android. Neste cap´ıtulo ´e feita uma descri¸c˜ao detalhada da maneira como estas trˆes componentes foram implementadas, assim como dos resultados da aplica¸c˜ao desenvolvida.

4.1

Base de Dados

Como referido no cap´ıtulo 3, o sistema de gest˜ao de base de dados escolhido foi o MySQL. Para a implementa¸c˜ao de uma base de dados em MySQL existe uma ferramenta muito ´util, o MySQL Workbench 5.2 CE, que facilita muito a sua imple-menta¸c˜ao uma vez que permite desenhar o diagrama ER (Entidade Relacionamento), isto ´e, desenhar as tabelas e as liga¸c˜oes que especificam a maneira como estas relacio-nam, possibilitando, atrav´es de uma funcionalidade de forward engineering, a gera¸c˜ao do c´odigo SQL (Structured Query Language) a partir do diagrama ER, e posterior-mente a sua exporta¸c˜ao para o servidor MySQL.

(62)

4.1. Base de Dados

Figura 4.1: Diagrama Entidade Relacionamento da base de dados

A base de dados foi implementada de modo a satisfazer todos os requisitos do sistema de uma forma bastante intuitiva e flex´ıvel. Proceda-se ent˜ao `a an´alise mais detalhada de cada entidade, consoante os seus atributos e a maneira como estes se relacionam com outras tabelas.

(63)

Do diagrama ER destacam-se cinco entidades/tabelas: user ; wsn; node; com-ponent e log.

A entidade user ´e respons´avel pelos registos de utilizadores, os seus atributos s˜ao referentes aos dados pessoais de cada um deles, de onde se destacam o username e a password, que representam as credenciais necess´arias para o login.

A tabela 4.1 descreve mais detalhadamente os atributos da entidade user.

Tabela 4.1: Atributos da entidade user

Atributo Descri¸c˜ao Tipo

id user Chave prim´aria int

name Nome string

birth date Data de nascimento long phone N´umero de telefone string

email E-mail string

address Morada string

reg date Data de Registo long password Palavra-passe string username Nome de utilizador string id user level Chave estrangeira da tabela user level int id log entity Chave estrangeira da tabela log entity int

Esta entidade/tabela relaciona-se com quatro outras: user level ; user device; user on wsn e log entity.

• user level : esta entidade ´e respons´avel por armazenar os n´ıveis de permiss˜ao de utilizador (administrador e utilizador comum), tem uma rela¸c˜ao de um para muitos com a entidade user, pois a mesma permiss˜ao pode estar associada a v´arios utilizadores mas cada utilizador tem apenas um n´ıvel de permiss˜ao;

• user device: esta entidade ´e respons´avel por armazenar o ID dos dispositivos m´oveis associados a cada utilizador, ´e necess´aria para o envio de notifica¸c˜oes para os dispositivos em que cada utilizador ter´a efetuado login. A sua rela¸c˜ao com a entidade user ´e de muitos para um, uma vez que cada utilizador pode ter a si associados v´arios dispositivos mas cada dispositivo apenas pode estar associado a um utilizador;

• user on wsn: esta entidade ´e respons´avel para associa¸c˜ao entre utilizadores e WSNs, isto ´e, representa as WSNs a que cada utilizador tem acesso. A sua

(64)

4.1. Base de Dados

existˆencia ´e imperativa j´a que no modelo relacional n˜ao ´e poss´ıvel estabelecer liga¸c˜oes de muitos para muitos e uma vez que cada utilizador dever´a poder ter acesso a m´ultiplas WSNs, e cada WSN tamb´em dever´a poder estar associada a m´ultiplos utilizadores. Esta tabela surge relacionando-se com a tabela user e a tabela wsn atrav´es de liga¸c˜oes de muitos para um, em que cada registo tem apenas como atributos a chave prim´aria de ambas as entidades;

• log entity : esta entidade ´e respons´avel pelo registo de um log, associado a cada registo das entidades user, wsn, node e component, e por isso relaciona-se com cada uma delas atrav´es de liga¸c˜oes de um para muitos.

A entidade wsn ´e respons´avel pelos registos das WSNs. A tabela 4.2 descreve detalhadamente os atributos da entidade wsn.

Tabela 4.2: Atributos da entidade wsn

Atributo Descri¸c˜ao Tipo

id wsn Chave prim´aria int

description Descri¸c˜ao string

location Localidade string

route Estrada string

reg date Data de Registo long id log entity Chave estrangeira da tabela log entity int

Esta entidade relaciona-se com trˆes outras: user on wsn; node e log entity. A suas rela¸c˜oes com as entidades user on wsn e log entity j´a s˜ao conhecidas, pelo que se ir´a analisar a tabela node, com a qual tem um relacionamento de nenhum ou um para muitos, uma vez que cada WSN poder´a conter nenhum, um ou v´arios n´os, mas cada n´o apenas poder´a existir no m´aximo em uma WSN.

A entidade node ´e respons´avel pelos registos dos n´os. Os seus atributos especi-ficam n˜ao s´o as carater´ısticas de cada n´o mas tamb´em a sua localiza¸c˜ao geogr´afica.

Imagem

Figura 2.1: Diagrama arquitetural do sistema [1]
Figura 2.3: Aplica¸ c˜ ao para o sistema operativo m´ ovel Android [1]
Figura 2.12: Tabelas do Modelo Relacional
Figura 2.13: Diagrama Cliente-Servidor
+7

Referências

Documentos relacionados

Os interessados em adquirir quaisquer dos animais inscritos nos páreos de claiming deverão comparecer à sala da Diretoria Geral de Turfe, localizada no 4º andar da Arquibancada

psicológicos, sociais e ambientais. Assim podemos observar que é de extrema importância a QV e a PS andarem juntas, pois não adianta ter uma meta de promoção de saúde se

Ficou com a impressão de estar na presença de um compositor ( Clique aqui para introduzir texto. ), de um guitarrista ( Clique aqui para introduzir texto. ), de um director

In this work, improved curves are the head versus flow curves predicted based on the correlations presented in Table 2 and improved by a shut-off head prediction

Segundo o mesmo autor, a animação sociocultural, na faixa etária dos adultos, apresenta linhas de intervenção que não se esgotam no tempo livre, devendo-se estender,

In this study clay mineral assemblages, combined with other palaeoenvironmental data, were studied in a core recovered from the outer sector of the Ria de Vigo, a temperate

Dessa forma, a partir da perspectiva teórica do sociólogo francês Pierre Bourdieu, o presente trabalho busca compreender como a lógica produtivista introduzida no campo