Sammenligning av budsjettall, kapitler og poster. Rammeområde 13

Numa visão geral, a aplicação gráfica terá de ser capaz permitir, conforme acordado nos requisitos, adicionar novas tags ao sistema, remover tags previamente adicionadas no sistema e monitorizar qualquer uma das tags existentes.

Tanto adicionar como remover são funcionalidades fáceis de implementar, nas quais, a primeira consiste em adicionar uma nova tag apenas se esta ainda não existir no sistema e a segunda consiste em apenas remover a placa existente no sistema sendo que estas verificações são verificadas através do MAC address da mesma, mas o mesmo não se passa na monitorização da mesma. Quando é referida a monitorização de uma placa, esta envolve uma diversidade de valores que têm de ser enviados por parte de cada tag. O primeiro dos quais e para que seja possível identificar a tag que enviou a informação, será enviado o seu respetivo MAC address. Para além disso, e para que seja possível a monitorização de cada um delas, estas vão enviar também uma lista com um conjunto de APs que estas detetaram em seu redor, isto é, a tag vai realizar um scan e vai, de cada rede encontrada ao seu redor, enviar:

 o MAC address do respetivo Access Point identificado;

 o RSSI da rede;

 o SSID da rede.

Com estes valores será então possível monitorizar cada tag identificando as redes existentes à sua volta, assim como estimar a distância a cada um dos APs que as criam.

Para este processo de monitorização foi desenvolvido o seguinte mockup para sugestão do aspeto gráfico da aplicação final.

33

Figura 4.3 Mockup sugestiva para o interface gráfico da aplicação

Assim sendo, pela observação da figura anterior, são de fácil identificação as duas áreas distintas referentes à adição de uma nova placa e remoção de uma placa existente, bem como a área de monitorização, na qual será possível escolher a tag a monitorizar dentro de um conjunto de tags existentes no sistema.

No que toca à tabela e ao gráfico, através da primeira o utilizador vai ser capaz de interagir com o segundo, isto é, o utilizador pode, através da tabela escolher quais serão as redes que serão representadas no gráfico. Esta opção é, portanto, uma funcionalidade extra que não estava nos requisitos do sistema, mas que pode ser bastante útil na identificação das redes permitindo ao utilizador, por exemplo, representar no gráfico apenas as redes cujo sinal é mais forte, facilitando assim a sua leitura.

Para além disso, vai ainda ser implementado uma outra funcionalidade que consiste em, cada vez que é iniciada uma nova monitorização, a tabela é automaticamente atualizada com a última leitura e o gráfico com até as últimas 5 leituras recebidas relativamente à placa escolhida. Desta forma, o utilizador tem a possibilidade de verificar quais foram os últimos APs detetados por uma determinada tag podendo assim estimar a sua posição atual ou, em caso de anomalia, o último sitio em que esta se encontrava funcional.

34

Para além dos valores já referidos, outros vão também ser enviados por cada tag, sendo estes o estado em que esta se encontra (“IDLE”, ”MOVEMENT_DETECTED”, ”ACTIVE” ou ”NO_MOVEMENT”)3 _{e, relativamente ao acelerómetro, os seus valores de} inclinação nos eixos X, Y e Z, bem como o estado do TRIGGER que identifica se foi detetado movimento (TRIGGER = 1) ou não (TRIGGER = 0).

Tendo em conta todos estes valores recebidos pela aplicação, o seguinte diagrama de classes foi criado com os tipos de relações entre objetos, bem como a sua multiplicidade.

Figura 4.4 Diagrama de classe UML relativo ao sistema

O sistema será então composto por 2 classes principais que são “Board” e “AP_scan” que são as tags existentes e as mensagens enviadas por estas, respetivamente. Na classe “Board” temos o MAC address da mesma e o nome do seu portador e quanto à classe “AP_scan” temos a data em que a mensagem foi recebida, a lista de leituras com o conjunto de APs detetados e o MAC address da placa que enviou essa mesma mensagem, tendo estas uma relação de associação de multiplicidade 1 para 0 ou vários, uma vez que uma placa pode ter 0 ou muitas leituras, enquanto uma leitura é sempre de uma só placa.

Para além disso, existem duas outras classes (“List_AP_Scans” e “List_Boards”) que vão ser constituídas por listas de cada um dos tipos de objetos anteriores, isto é, uma lista de

3 _{Estes são os possíveis estados em que a WiFi tag se pode encontrar e estão devidamente explicitados}

35

tags e uma lista das mensagens. Vai ser ainda criado uma classe relativa unicamente aos

valores obtidos pelo scan “Reading” porque cada mensagem recebida pode conter uma lista de leituras efetuadas e, como tal, a classe “AP_scan” tem de possuir um atributo que será uma lista de leituras. Por esse mesmo motivo existe uma ligação de composição de multiplicidade 1 para 0 ou muitos entre “AP_scan” e “Reading” pois o primeiro pode conter 0 ou vários objetos do tipo “Reading”.

Quanto às classes criadas relativas às listas ambas são constituídas apenas por uma lista, contudo as listas são de tipos diferentes. A lista das placas é uma lista simples uma vez que o acesso a esta é sempre feito de forma aleatória e, não existindo funcionalidades extras, este acesso é mais eficiente neste tipo de listas.

Já a lista das mensagens é uma lista ligada uma vez que este tipo de lista possibilita certos métodos implementados na respetiva classe que não estão implementados na primeira, tais como adicionar ou remover um elemento no início ou no fim da lista e estes serão necessários para cumprir a funcionalidade de carregar os últimos scans relativos a uma determinada placa como iremos verificar mais à frente nesta dissertação. Para além disso, esta lista terá uma propriedade distinta em relação à lista das placas; a esta lista será imposta um limite máximo de leituras para cada placa, isto é, nesta apenas serão armazenados até ao máximo de 5 leituras para cada placa, sendo estas, como é óbvio, as últimas 5 leituras recebidas. Esta foi uma opção tomada na linha de pensamento que esta se trata de uma aplicação onde o objetivo será verificar a localização de uma determinada placa em tempo real e não o seu histórico.

Para que os dados estejam disponíveis sempre que requisitados estes têm que ser armazenados e guardados e para esta finalidade foi escolhido guardar os mesmos em ficheiros binários uma vez que estes permitem uma enorme facilidade de manipulação e acesso aos dados em comparação, por exemplo, com os ficheiros de texto em que o acesso tem de ser sequencial. Diversos métodos estão à disposição do utilizador para facilitar, por exemplo, a abertura, a escrita e a leitura de ficheiros.

Para a gravação dos dados, dois ficheiros terão de ser criados em que um vai ser responsável pelo armazenamento da lista de tags (“List_Boards”) e o outro pelo armazenamento da lista de scans das tags (“List_AP_Scans”).

Como tal, para gravar os dados, uma thread vai ser criada com a simples função de carregar os dados para os respetivos ficheiros de 10 em 10 minutos, como é demonstrado pelo diagrama de atividade da figura seguinte.

36

Figura 4.5 Diagrama de atividade para a thread para gravar os dados para ficheiro

Para além disso, outra thread tem de ser criada para o servidor UDP que vai estar constantemente a escutar num determinado port por mensagens. Para este efeito o port escolhido foi o 50000 e terá então de ser este o port de destino de envio por parte de cada tag. Depois de uma mensagem ser recebida, todo um processo terá de ser desencadeado e é precisamente isso que o diagrama de atividade da figura seguinte descreve.

37 Através da figura anterior pode-se verificar que assim que uma nova mensagem é recebida, o primeiro passa a ser feito é fazer o parsing dessa mesma string para um objeto com formatação JSON, sendo este processo explicado melhor no subcapítulo seguinte. De seguida, e tendo já os dados bem organizados e facilmente acessíveis será necessário verificar se o MAC address da tag emissora que consta na mensagem recebida, se encontra na lista de

tags (“List_Boards”), caso contrário a mensagem será ignorada. Em caso positivo, essa tag

encontra-se no sistema e desta forma o próximo passo será guardar os valores recebidos na lista de scans das tags (“List_AP_Scans”). Temos ainda mais um possível passo a executar e este prende-se com o facto da respetiva tag estar sob monitorização e, neste caso, os valores da tabela e do gráfico terão de ser atualizados com os novos dados recebidos.

Muito importante salientar que, uma vez que esta thread irá estar a “correr” em paralelo com a thread principal, todo o sistema de recepção do pacote, parsing e armazenamento do novo scan na lista vai estar sempre a acontecer, isto é, quer um utilizador esteja a monitorizar uma tag ou não, os todas as mensagens recebidas estarão a ser adicionadas à lista de scans.