3.4 Especifica¸c˜ ao de Software
3.4.3 Aplica¸c˜ 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
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.
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”; ”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.
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.
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
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.
Implementa¸c˜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.
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.
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
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.
Tabela 4.3: Atributos da entidade node
Atributo Descri¸c˜ao Tipo
id node Chave prim´aria int
reg date Data de Registo long
description Descri¸c˜ao string
mac address Endere¸co f´ısico string km Ponto kilom´etrico onde se encontra
direction Sentido da autoestrada onde est´a instalado string
coord latitude Latitude string
coord longitude Longitude string
id wsn Chave estrangeira da tabela wsn int id inst state Chave estrangeira da tabela installation state int id node state Chave estrangeira da tabela node state int id node type Chave estrangeira da tabela node type int id log entity Chave estrangeira da tabela log entity int
Esta entidade relaciona-se com sete outras: wsn; installation state; node state; node type; sample; component e log entity. A suas rela¸c˜oes com as entidades wsn e log entity j´a s˜ao conhecidas. Analise-se ent˜ao a sua rela¸c˜ao com as outras entidades:
• installation state, node state e node type: estas entidades s˜ao respons´aveis por armazenar os estados da instala¸c˜ao de um n´o (instalado ou n˜ao instalado), o estado do n´o (ligado ou desligado) e o tipo do n´o (coordenador ou end de- vice), as trˆes tˆem uma rela¸c˜ao de um para muitos com a entidade node, pois o estado ou tipo, estar´a associado a v´arios n´os mas cada n´o apenas poder´a estar associado a um destes registos num determinado momento;
• sample: esta entidade ´e respons´avel por armazenar as amostras dos valores lidos pelos sensores cada vez que ocorra um alerta, isto ´e, uma colis˜ao. A sua rela¸c˜ao com a entidade node ´e de muitos para um, uma vez que um n´o poder´a estar associado a m´ultiplas amostras.
Proceda-se agora `a an´alise mais detalhada da tabela component, com a qual a entidade node tem um relacionamento de nenhum ou um para muitos, uma vez que cada node poder´a conter nenhum, um ou v´arios componentes, mas cada componente apenas poder´a existir no m´aximo em um n´o.
A entidade component ´e respons´avel pelos registos dos componentes. A tabela 4.4 descreve detalhadamente os atributos da entidade component.
4.2. Servidor
Tabela 4.4: Atributos da entidade component
Atributo Descri¸c˜ao Tipo
id component Chave prim´aria int description Descri¸c˜ao string reg date Data de Registo long id node Chave estrangeira da tabela node int id comp type Chave estrangeira da tabela comp type int id log entity Chave estrangeira da tabela log entity int
Esta entidade relaciona-se com quatro outras: node; comp type; comp field value e log entity. J´a foram explicadas as suas liga¸c˜oes com as entidades node e log entity.
´
E relevante referir que neste sistema apenas s˜ao utilizados componentes de dois tipos: SOC (System On Chip) e aceler´ometro. No entanto, e devido `a necessidade de fazer variar os atributos consoante o tipo de componente, a implementa¸c˜ao da entidade component foi realizada de tal modo que possibilite ao administrador da base de da- dos inserir novos tipos de componentes e respetivos atributos, sem que para isso seja necess´ario adicionar novas tabelas `a base de dados. Esta implementa¸c˜ao encontra-se diretamente relacionada com as entidades comp type e comp field value, que por sua vez se relacionam com a entidade comp field. Analise-se ent˜ao as rela¸c˜oes entre estas entidades:
• comp type: esta entidade ´e respons´avel por armazenar os tipos de compo- nentes que a base de dados conhece, pelo que a sua liga¸c˜ao com a entidade component ´e de um para muitos, uma vez que podem existir v´arios componen- tes do mesmo tipo;
• comp field e comp field value: a entidade comp field armazena os atributos referentes a cada registo da entidade comp type, cada tipo existente na base de dados pode conter um ou mais atributos, e o valor dos atributos ´e registado na entidade comp field value que por sua vez associa esses valores a um registo da entidade component, atrav´es de uma rela¸c˜ao de muitos para um.
4.2
Servidor
A implementa¸c˜ao do servidor ser´a dividida em trˆes camadas: model, DAO e web services.
A figura 4.2 ilustra o diagrama de camadas do servidor de uma forma mais completa do que na fase da modela¸c˜ao.
Figura 4.2: Diagrama de camadas do servidor
O IDE (Integrated Development Environment ) escolhido para implementar o servidor foi o NetBeans 7.3.1. Esta ferramenta foi escolhida pois vem integrada com o servidor Glassfish onde o servidor ficar´a a correr, e tamb´em porque facilita a cria¸c˜ao da camada model, uma vez que, atrav´es de um wizard, possibilita a conex˜ao `a base de dados para proceder `a importa¸c˜ao das tabelas de modo a gerar automaticamente o c´odigo das classes da camada model.
4.2.1
Model
Relembrando o que se especificou no cap´ıtulo 3, a camada model contem as classes que caraterizam os atributos e as rela¸c˜oes de cada entidade/tabela da base de dados. A figura 4.3 representa o diagrama de classes das principais entidades da camada model.
4.2. Servidor
Figura 4.3: Diagrama de classes da camada model
4.2.2
DAO
A camada DAO (Data Access Object ) ´e respons´avel pela conex˜ao e queries, isto ´
e, pedidos `a base de dados. Engloba as classes que que implementam os m´etodos de conex˜ao e queries referentes a cada entidade. Estes m´etodos executam opera¸c˜oes de cria¸c˜ao, edi¸c˜ao, remo¸c˜ao e pesquisa de um ou mais registos na base de dados. A figura 4.4 ilustra o diagrama de classes da camada DAO.
Figura 4.4: Diagrama de classes da camada DAO
Para melhor entender como se processa a execu¸c˜ao das queries, segue como exemplo a listagem 4.1 do c´odigo do m´etodo create, correspondente `a query de cria¸c˜ao de uma nova WSN.
4.2. Servidor
Listagem 4.1: M´etodo create da classe WsnDAO
1 public int create(JSONObject jsonWsn) throws JSONException
2 { 3 Connection c = null; 4 PreparedStatement ps; 5 int idWsn=0; 6 7 try { 8 c = ConnectionHandler.getConnection(); 9
10 ps = c.prepareStatement("INSERT INTO wsn (description, location, "
11 + "route, reg_date, id_log_entity) VALUES (?, ?, ?, ?, ?)" 12 , Statement.RETURN_GENERATED_KEYS);
13 ps.setString(1, jsonWsn.getString("description")); 14 ps.setString(2, jsonWsn.getString("location"));
15 ps.setString(3, jsonWsn.getString("route"));
16 ps.setString(4, String.valueOf(System.currentTimeMillis())); 17 LogDAO log = new LogDAO();
18 ps.setInt(5, log.createLogEntity(2)); 19 20 ps.executeUpdate(); 21 ResultSet rs = ps.getGeneratedKeys(); 22 if (rs.next()) { 23 idWsn = rs.getInt(1); 24 } 25 }catch (Exception e) {
26 throw new RuntimeException(e);
27 } finally { 28 ConnectionHandler.close(c); 29 } 30 31 return idWsn; 32 }
O m´etodo create recebe como argumento o objeto JSON (JavaScript Object Notation) com os dados do novo registo e retorna o ID da WSN criada. O c´odigo da linha 8 corresponde `a execu¸c˜ao do m´etodo que estabelece a liga¸c˜ao com a base de dados. Da linha 10 `a 15 ´e realizada a especifica¸c˜ao e prepara¸c˜ao da query com o valor dos atributos do objeto JSON, e na linha 20 ´e executada a query. De real¸car que na linha 17 e 18 ´e executado o m´etodo createLogEntity da classe LogDAO dada
a necessidade de atribuir um registo de log ao novo registo de WSN. Da linha 21 `a 24 ´e obtido o ID de registo referente `a nova WSN. Caso tenha havido falha na cria¸c˜ao da WSN o valor do ID retornado ´e 0.
4.2.3
Web Services
Seguidamente ser´a descrita a maneira como foi implementada a camada dos web services, a componente mais importante do servidor, pois ´e respons´avel pela rece¸c˜ao e processamento dos pedidos por parte do cliente, e pelo envio dos respetivos dados de resposta. Como referido no cap´ıtulo anterior, estes pedidos s˜ao realizados atrav´es do protocolo HTTP, com recurso aos m´etodos: POST ; GET ; PUT e DELETE. Estes m´etodos permitem inserir, pesquisar, atualizar ou remover registos da base de dados.
No cap´ıtulo 3 foram desenhados os diagramas dos web services com os m´etodos essenciais associados `as entidades: user ; wsn; node e component. Nesta fase, optou-se por retirar os servi¸cos de login e logout da classe UserREST e associa-los a uma nova classe, nomeadamente, a classe AuthREST. Dada tamb´em a necessidade de incluir as entidades log e sample, os servi¸cos foram implementados em sete classes: AuthREST ; UserREST ; WsnREST ; NodeREST ; ComponentREST ; LogREST e SampleREST, caraterizadas pelos atributos e m´etodos descritos pelo diagrama de classes da figura 4.5.
4.2. Servidor
Figura 4.5: Diagrama de classes da camada Web Services
Cada web service tem a si associado um URI (Uniform Resource Identifier ) e ´
e atrav´es deles que o cliente executa os pedidos.
As tabelas 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11 descrevem o m´etodo e a opera¸c˜ao associada aos URIs das classes AuthREST, UserREST, WsnREST, NodeREST, Com- ponentREST, LogREST e SampleREST respetivamente. Para realizar um pedido ´e necess´ario adicionar `a esquerda de cada um destes URIs o endere¸co HTTP do servi- dor.
Tabela 4.5: URI dos web services da classe AuthREST
URI M´etodo Opera¸c˜ao Content-type */auth/login POST Login de Utilizador JSON
/auth/logout POST Logout JSON
Tabela 4.6: URI dos web services da classe UserREST
URI M´etodo Opera¸c˜ao Content-type
*/user GET Listar utilizadores JSON
/user POST Criar utilizador JSON
/user PUT Editar utilizador JSON
/user/{idUser} DELETE Apagar utilizador JSON /user/{idUser} GET Listar utilizador ID={idUser} JSON /user/log/{idUser} GET Listar log do utilizador
ID={idUser}
JSON
/user/onwsn GET Lista de acessos a WSN JSON /user/access POST Garante/Remove o acesso de
um utilizador a uma WSN
JSON
/user/remwsn POST Remove o acesso a uma WSN JSON
Tabela 4.7: URI dos web services da classe WsnREST
URI M´etodo Opera¸c˜ao Content-type
*/wsn GET Listar WSN JSON
/wsn POST Criar WSN JSON
/wsn PUT Editar WSN JSON
/wsn/{idWsn} DELETE Apagar WSN JSON
/wsn/{idWsn} GET Listar WSN
ID={idWsn}
JSON
/wsn/node/{idWsn} GET Listar n´os da WSN ID={idWsn}
JSON
/wsn/user/{idUser} GET Listar WSN a que do