Descrição do Projeto da Disciplina

T´ecnicas de Projeto e Implementa¸c˜ao de Sistemas I

Descri¸

c˜

ao do Projeto da Disciplina

1

Introdu¸

c˜

ao

Redes de Sensores Sem Fio s˜ao redes utilizadas para monitorar alguma informa¸c˜ao ou parˆametro de interesse em cen´arios espec´ıficos. Por exemplo, estas redes podem ser utilizadas para moni-torar a qualidade do ar (concentra¸c˜ao de CO2) em grandes metr´opoles, para detectar queimadas

em florestas ou para monitorar o estado estrutural de constru¸c˜oes. A ideia ´e que dispositivos computacionais pequenos, chamados sensores, s˜ao espalhados de forma a cobrir uma regi˜ao de interesse. Estes sensores s˜ao equipados com hardware capaz de detectar determinados eventos (como incˆendios) ou medir alguma grandeza (como a concentra¸c˜ao de CO2 no ar). Os dispositivos

possuem ainda um r´adio, possibilitando a transmiss˜ao dos dados coletados para uma esta¸c˜ao base, que realiza algum tratamento (por exemplo, gerando alertas) e os armazena. A Figura 1 ilustra o conceito.

Estação Base

Região de Interesse

Em geral, o r´adio utilizado pelos sensores ´e de curto alcance (devido a restri¸c˜oes de consumo de energia) e a regi˜ao de interesse se torna muito grande para que cada sensor possa se comunicar diretamente com a esta¸c˜ao base. Por este motivo, os sensores formam uma rede de m´ultiplos saltos. Isto significa que sensores mais distantes da esta¸c˜ao base utilizam outros sensores pr´oximos como intermedi´arios na comunica¸c˜ao. A Figura 1, por exemplo, exibe (em azul) uma hipot´etica rota utilizada por um sensor distante da esta¸c˜ao base, passando por 3 outros sensores da rede. Cada vez que este sensor distante realiza uma medi¸c˜ao, ele encapsula a informa¸c˜ao gerada em um pacote que ´e enviado para um sensor vizinho. Este sensor vizinho recebe o pacote e realiza o encaminhamento para o pr´oximo sensor. O processo se repete at´e que o ´ultimo sensor no caminho consegue entregar a mensagem at´e a esta¸c˜ao base.

Uma caracter´ıstica marcante deste tipo de rede ´e a baixa capacidade energ´etica dos sensores. Estes equipamentos operam por uma bateria que muitas vezes n˜ao pode ser recarregada ou subs-titu´ıda. Por este motivo, os n´os precisam economizar energia para que a rede possa operar pelo maior tempo poss´ıvel.

Dentre as v´arias t´ecnicas para economia de energia utilizadas em redes de sensores, uma bas-tante imporbas-tante ´e o duty cycle do r´adio. Esta t´ecnica consiste em ligar e desligar o r´adio do sensor (um dos componentes que mais consome energia) de acordo com algum padr˜ao de atividade. Estes padr˜oes discretizam o tempo em unidades chamadas de slots, que podem assumir os estados “ligado” (r´adio ficar´a ligado durante o slot ) ou “desligado” (r´adio fica desligado durante o slot ). Tais padr˜oes podem ser gerados por diversas t´ecnicas distintas.

Quando um sensor faz uma medi¸c˜ao (ou detecta um evento), ele gera um pacote e espera a ocorrˆencia do pr´oximo slot no qual seu r´adio ser´a ligado (para que a transmiss˜ao possa ser feita). O sensor ent˜ao realiza a transmiss˜ao, que s´o ser´a bem sucedida se as seguintes duas condi¸c˜oes forem satisfeitas simultaneamente:

1. o sensor vizinho (para o qual o pacote foi enviado) est´a tamb´em com o seu r´adio ligado no mesmo slot ; e

2. n˜ao h´a falha na transmiss˜ao (uma transmiss˜ao tem falha com uma determinada probabilidade (1 − p)).

Quando um sensor precisa encaminhar um pacote de outro sensor, o processo ´e an´alogo.

2

Cen´

ario

Suponha que a Prefeitura da cidade do Rio de Janeiro, com o objetivo de garantir a qualidade da ´agua da Lagoa Rodrigo de Freitas para as competi¸c˜oes de remo nos Jogos Ol´ımpicos de 2016, decide implantar uma Rede de Sensores Sem Fio para monitorar o n´ıvel de oxigena¸c˜ao da ´agua em v´arios pontos. Para isso, ´e contratada uma equipe de especialistas em diversas ´areas, incluindo uma equipe de desenvolvimento de software que consiste no seu grupo para este trabalho.

´

e que este software seja capaz de realizar simula¸c˜oes simplificadas do funcionamento da rede, levando em considera¸c˜ao os eventos de medi¸c˜ao de dados, envio de pacotes e duty cycle do r´adio dos sensores. Este simulador ser´a ent˜ao utilizado por outra equipe do projeto para avaliar qual o padr˜ao de atividade mais adequado e qual a capacidade de bateria necess´aria para os n´os.

3

Especifica¸

c˜

ao do Sistema

O sistema consiste em um simulador simplificado de rede de sensores operando com duty cycle. A interface com o usu´ario ´e de livre escolha do grupo, desde de que permita que o usu´ario, de alguma forma, seja capaz de:

• especificar um arquivo de configura¸c˜ao do qual devem ser lidos os parˆametros de simula¸c˜ao (e.g., n´umero de n´os, padr˜oes de atividade a serem usados);

• pausar a simula¸c˜ao para ver resultados parciais;

• recome¸car a simula¸c˜ao quando pausada (do ponto atual); • terminar a simula¸c˜ao.

3.1

Arquivo de Configura¸

c˜

ao

O arquivo de configura¸c˜ao tem o seguinte formato:

<# de n´os> <probabilidade> <trace_eventos> <lista_bd>

<tecnica_dc_1_no_0> <dc_1_no_0>[,<tecnica_dc_2_no_0> <dc_2_no_0>...] <tecnica_dc_1_no_1> <dc_1_no_1>[,<tecnica_dc_2_no_1> <dc_2_no_1>...] ... Links <no_x> <no_y> <no_y> <no_w> <no_w> <no_z> ...

dois sensores (o complemento da probabilidade de que uma transmiss˜ao falhe). A terceira linha especifica um nome de arquivo com um trace de eventos relacionados ao n´ıvel de oxigena¸c˜ao da ´

agua (vide Se¸c˜ao 3.1.1 para mais detalhes). A quarta linha especifica o nome de um arquivo a partir do qual devem ser lidos os Block Designs a serem suportados pelo simulador (Block Designs s˜ao uma das fam´ılias de padr˜oes de atividade que dever˜ao ser implementadas no simulador; vide Se¸c˜ao 3.1.2 para mais detalhes).

As pr´oximas n linhas (onde n ´e o n´umero de n´os da simula¸c˜ao) especificam o padr˜ao de atividade de cada n´o. A especifica¸c˜ao ´e na forma de uma lista de pares que especificam uma t´ecnica de gera¸c˜ao de padr˜ao e um valor de duty cycle (vide Se¸c˜ao 3.1.2 para mais detalhes). Em cada par, a t´ecnica ´e especificada por uma string (o nome da t´ecnica, como especificado na Se¸c˜ao 3.1.2) e um valor num´erico real no intervalo (0, 1] (propor¸c˜ao de tempo em que o r´adio deve ficar ligado), separados por exatamente um espa¸co. Para um mesmo n´o, podem ser especificados diversos pares, que ser˜ao compostos como descrito na Se¸c˜ao 3.1.2 para determinar o padr˜ao de atividade. Os diferentes pares s˜ao separados por v´ırgula.

Cada n´o da rede deve possuir um identificador num´erico (ID). Os identificadores come¸cam em 0 e v˜ao at´e n − 1. Estas n linhas, que cont´em a especifica¸c˜ao do padr˜ao de atividade de cada n´o, implicitamente determinam o ID (i.e., o n´o especificado na i-´esima linha deste conjunto, deve ter o ID i − 1). O n´o de ID n − 1 (ID mais alto) sempre representa a esta¸c˜ao base.

Ap´os estas n linhas, encontra-se uma linha com a palavra chave “Links” (sem aspas). Esta palavra chave demarca que, a partir da pr´oxima linha, ser˜ao especificados os links sem fio uti-lizados por cada sensor. Cada sensor utiliza exatamente um link para transmiss˜ao ao longo de toda a simula¸c˜ao, com exce¸c˜ao da esta¸c˜ao base, que nunca realiza envios (apenas recep¸c˜oes). A especifica¸c˜ao de um link ´e na forma de um par de IDs, separados por exatamente um espa¸co. Esta se¸c˜ao do arquivo necessariamente conter´a n − 1 linhas (um link por n´o, exceto pela esta¸c˜ao base). Os links podem aparecer em qualquer ordem.

Um exemplo de um arquivo de configura¸c˜ao simples ´e dado a seguir:

4 0.8

eventos.txt bd.txt

As pr´oximas se¸c˜oes descrevem elementos mais espec´ıficos do simulador. 3.1.1 Trace de Eventos

O arquivo de trace de eventos especifica mudan¸cas nos valores de oxigena¸c˜ao lidos por cada um dos sensores ao longo de toda a simula¸c˜ao. Cada linha do arquivo ´e composta por uma tupla da forma < slot, ID, medicao > que significa que no tempo slot (o tempo de simula¸c˜ao ´e discretizado em slots), o valor de oxigena¸c˜ao da ´agua medido pelo n´o de id ID passa a ser medicao.

O valor slot ´e um n´umero inteiro maior ou igual a zero. O ID ´e um valor inteiro entre 0 e n − 2 (onde n ´e o n´umero de n´os da rede). O valor medi¸c˜ao ´e um n´umero real n˜ao-negativo.

Os eventos listados no arquivo s˜ao ordenados pelo tempo de ocorrˆencia. Note que o arquivo obrigatoriamente cont´em as n − 1 primeiras linhas especificando os valores iniciais das medi¸c˜oes para cada n´o (slot = 0), exceto para a esta¸c˜ao base (a esta¸c˜ao base n˜ao realiza medi¸c˜oes).

Um exemplo do arquivo, considerando uma simula¸c˜ao de 4 n´os, ´e dado a seguir.

0 0 1.3 0 1 5.3 0 2 3.3 17 2 3.6 23 0 2.6 54 1 2.5 78 2 3.8

3.1.2 Padr˜oes de Ativa¸c˜ao

O padr˜ao de ativa¸c˜ao de um n´o especifica para cada slot de tempo qual deve ser o estado do r´adio do n´o: ligado ou desligado. Os padr˜oes de ativa¸c˜ao podem ser gerados por in´umeras t´ecnicas. A seguir s˜ao explicadas as que devem ser implementadas pelo sistema.

• Grid: Em um grid de ordem m, um n´o deve ligar seu r´adio em um slot s se, e somente se: 1. (s mod m2_{) < m; ou}

2. (s mod m2_{) ≡ 0 (mod m).}

O valor do duty cycle de um grid de ordem m ´e dado por 2m−1_m2 .

O tamanho do ciclo de um grid de ordem m ´e dado por m2_.

No arquivo de configura¸c˜ao do simulador, um padr˜ao do tipo grid ´e identificado pela string Grid.

1. (s mod m2_{) ≤ b}m 2c; ou

2. (s mod m2) ≡ 0 (mod m).

O valor do duty cycle de um torus de ordem m ´e dado por (aproximadamente) _m1 +_2m1 . O tamanho do ciclo de um torus de ordem m ´e dado por m2_.

No arquivo de configura¸c˜ao do simulador, um padr˜ao do tipo torus ´e identificado pela string Torus.

• BlockDesign: Um Block Design com parˆametros v, λ e k, um n´o deve ligar seu r´adio em um slot s se, e somente se:

1. (s mod v) ∈ S,

onde S ´e um conjunto de valores inteiros de 0 a v − 1 tabelados, espec´ıficos para cada Block Design. O sistema deve ler um conjunto de poss´ıveis Block Designs a partir de um arquivo como o a seguir: 7,3,1,0,1,3 13,4,1,0,1,3,9 21,5,1,0,3,4,9,11 31,6,1,0,4,10,23,24,26 57,8,1,0,1,6,15,22,26,45,55 73,9,1,0,1,12,20,26,30,33,35,57 91,10,1,0,2,6,7,18,21,31,54,63,71 133,12,1,0,9,10,12,26,30,67,74,82,109,114,120 183,14,1,0,12,19,20,22,43,60,71,76,85,89,115,121,168 273,17,1,0,1,22,33,83,122,135,141,145,159,175,200,226,229,231,238,246 307,18,1,0,1,3,30,37,50,55,76,98,117,129,133,157,189,199,222,293,299

Neste formato, cada linha representa um Block Design. Os trˆes primeiros valores separados por v´ırgula s˜ao os parˆametros v, λ e k. Os demais representam os elementos do conjunto S para o respectivo Block Design.

O valor do duty cycle de um Block Design ´e dado por λ_v. O tamanho do ciclo de um Block Design ´e dado por v.

No arquivo de configura¸c˜ao do simulador, um padr˜ao do tipo Block Design ´e identificado pela string BlockDesign.

...

...

...

...

...

...

Ciclo = 4 Ciclo = 4 Ciclo = 4 Ciclo = 4

Ciclo = 9 Ciclo = 16 Ciclo = 9 Ciclo = 16 Ciclo = 7 Ciclo = 7 Rádio Desligado Rádio Ligado

Figura 2: Exemplo de padr˜oes gerados por cada uma das t´ecnicas a serem implementadas com diversos parˆametros.

O padr˜ao de ativa¸c˜ao de um n´o pode ser gerado a partir de uma ´unica t´ecnica ou pelo aninha-mento (combina¸c˜ao) de v´arios padr˜oes. A Figura 3 mostra um exemplo de um padr˜ao de ativa¸c˜ao gerado pelo aninhamento dos padr˜oes Grid com m = 2 e Grid com m = 3. Neste caso, cada slot do padr˜ao gerado pelo Grid com m = 2 pode ser visto como um superslot, composto por 9 subslots (tamanho do ciclo de um padr˜ao de atividade gerado pelo Grid com m = 3). Para cada superslot ativo, os 9 subslots correspondem a um ciclo do padr˜ao de atividade gerado pelo Grid com m = 3. Para um superslot inativo, todos os 9 subslots que o comp˜oem s˜ao tamb´em inativos. Na parte de baixo da Figura 3 ´e ilustrado o padr˜ao final resultante do aninhamento.

...

Grid, m = 2; Grid, m = 3

Superslot

Subslot Padrão de Atividade Resultante

...

Superslot 0 Superslot 1 Superslot 2 Superslot 3 Superslot 4 Superslot 5

Figura 3: Exemplo de padr˜ao aninhado gerado pela combina¸c˜ao entre os padr˜oes Grid com m = 2 e Grid com m = 3.

que o processo de aninhamento pode ser feito v´arias vezes. No exemplo da Figura 3, por exemplo, cada subslot poderia ser dividido em subsubslots com qualquer outro padr˜ao de atividade.

O sistema a ser implementado, portanto, deve determinar as componentes do duty cycle a ser realizado por cada n´o a partir a partir da especifica¸c˜ao feita pelo usu´ario no arquivo de configura¸c˜ao. Por exemplo, considere que, para um dado n´o, o arquivo de configura¸c˜ao do sistema especifica o seguinte padr˜ao de ativa¸c˜ao:

BlockDesign 0.30,BlockDesign 0.45,Grid 0.4

O primeiro passo ´e identificar, a partir dos valores de duty cycle e nomes das t´ecnicas especifica-dos pela configura¸c˜ao, quais s˜ao as componentes do padr˜ao de ativa¸c˜ao a ser gerado. Considerando a lista de Block Designs apresentada nesta se¸c˜ao (vide a explica¸c˜ao sobre Block Designs), estes componentes s˜ao:

1. Block Design com v = 13, λ = 4 e k = 1 (duty cycle resultante ´e 0.307, o mais pr´oximo ao valor especificado).

2. Block Design com v = 7, λ = 3 e k = 1 (duty cycle resultante ´e 0.428, o mais pr´oximo ao valor especificado).

especifica¸c˜ao do arquivo de configura¸c˜ao, padr˜oes mais a esquerda representam componentes mais externas no aninhamento.

Para determinar se um n´o, seguindo um padr˜ao de ativa¸c˜ao com α componentes aninhadas, deve ligar o r´adio em um dado slot s, pode-se usar os seguintes passos:

1. Come¸ca-se pela componente mais externa (mais `a esquerda, na especifica¸c˜ao do arquivo de configura¸c˜ao).

2. Calcule o valor Vtcomo sendo o produt´orio dos tamanhos dos ciclos das componentes internas

`

a componente atual (mais `a direita, na especifica¸c˜ao do arquivo de configura¸c˜ao). 3. Calcule s0 = bs/Vtc.

4. Aplicando a defini¸c˜ao da t´ecnica usada na componente atual, verifique se o slot s0 ´e um slot “ligado” para a componente atual.

5. Se for:

(a) Se esta ´e a componente mais interna, retorne “slot ligado”. (b) Fa¸ca s = (s mod Vt).

(c) Passe para a pr´oxima componente (imediatamente `a direita, na especifica¸c˜ao do arquivo de configura¸c˜ao).

(d) Volte ao passo 2.

6. Sen˜ao, retorne “slot desligado”.

Aplicando estes passos ao exemplo para um slot s = 167, obtemos:

• Para a primeira componente, Vt = 7 · 16 = 112 e s0 = 1. Para o Block Design com v = 13,

λ = 4 e k = 1, o slot s0 = 1 ´e “ligado”. Como ainda h´a componentes mais internas, s ´e recalculado como 167 mod 112 = 55, e o algoritmo prossegue.

• Para a segunda componente, Vt = 16 e s0 = b55/16c = 3. Para o Block Design com v = 7,

λ = 3 e k = 1, o slot s0 = 3 ´e “ligado”. Como ainda h´a componentes mais internas, s ´e recalculado como 55 mod 16 = 7, e o algoritmo prossegue.

• Para a terceira componente, Vt = 1 e s0 = b7/1c = 7. Para o grid de ordem 4, o slot s0 = 7

´

e “desligado”. Logo, para este padr˜ao de ativa¸c˜ao, o slot 167 ´e “desligado”.

3.1.3 Contagem de Tempo

A simula¸c˜ao deve manter um “contador de tempo” global. Este contador deve ser iniciado em 0 e contar em unidades de slots. A cada slot de tempo marcado pelo contador de tempo global, o simulador deve, sequencialmente e nesta ordem:

1. atualizar a oxigena¸c˜ao da ´agua na Lagoa (considerando os eventos do arquivo de trace agen-dados para o slot atual);

2. dar uma oportunidade para cada n´o, em ordem crescente de ID, atualizar seu rel´ogio local (vide Se¸c˜ao 3.1.4);

3. dar uma oportunidade para cada n´o, em ordem crescente de ID, atualizar o estado do seu r´adio; e

4. dar uma oportunidade para cada n´o, em ordem crescente de ID, realizar uma nova medida do n´ıvel de oxigena¸c˜ao da ´agua.

5. dar uma oportunidade para cada n´o, em ordem crescente de ID, realizar uma ´unica tentativa de transmiss˜ao de pacote usando seu respectivo link.

3.1.4 Funcionamento de um N´o

Cada n´o deve manter um “contador de tempo” local, potencialmente diferente do contador de tempo global. Este contador de tempo local deve ser iniciado com um valor inteiro sorteado aleatoriamente do intervalo [0, 10000]. Note que n´os diferentes podem ter seus contadores locais iniciados com valores distintos (em outras palavras, o simulador deve fazer um sorteio para cada n´o). Al´em do contador de tempo local, o n´o deve armazenar uma fila de pacotes com capacidade de armazenar at´e 10 pacotes. Outra informa¸c˜ao armazenada pelo n´o ´e para qual outro n´o da simula¸c˜ao seus pacotes devem ser transmitidos quando houver a oportunidade. Esta informa¸c˜ao ´

e baseada na informa¸c˜ao dos links especificados no arquivo de configura¸c˜ao. Note um dado n´o sempre transmite pacotes para um ´unico outro n´o.

S˜ao funcionalidades de um n´o da simula¸c˜ao:

1. Atualizar o estado do seu r´adio: verificar se o slot de tempo atual, segundo seu rel´ogio local, ´e um slot “ligado” ou “desligado” de acordo com seu padr˜ao de atividade.

2. Realizar medi¸c˜oes da oxigena¸c˜ao da ´agua: caso o valor medido seja diferente do anterior, gerar um novo pacote e inseri-lo no final da fila de pacotes.

3. Tentativa de transmiss˜ao: se h´a ao menos um pacote na fila e o r´adio est´a ligado, tentar transmitir o primeiro pacote da fila atrav´es do seu link.

r´adio esteja ligado), ele deve sortear um valor aleat´orio no intervalo [0, 1]: se o valor sorteado for menor que a probabilidade especificada no arquivo de configura¸c˜ao, a transmiss˜ao ´e bem sucedida. Caso contr´ario, a transmiss˜ao falha.

Se uma transmiss˜ao ´e bem sucedida, o n´o que a efetuou deve remover o pacote da sua fila. Analogamente, o n´o receptor adiciona o pacote ao fim da sua fila. Se uma transmiss˜ao falha (por qualquer motivo), o n´o que tentou efetuar a transmiss˜ao mant´em o pacote no in´ıcio da sua fila para realizar uma nova tentativa em um pr´oximo slot de tempo.

Caso um n´o gere um novo pacote (por conta de uma nova medi¸c˜ao do n´ıvel de oxigena¸c˜ao) ou receba com sucesso um pacote de um outro vizinho, ele deve inserir o pacote no final da sua fila. No entanto, caso a fila esteja com a capacidade m´axima (10 pacotes), o pacote que estava na ´

ultima posi¸c˜ao imediatamente antes da inser¸c˜ao deve ser removido e descartado (perda de pacote). Uma exce¸c˜ao a estas regras ´e o n´o que representa a esta¸c˜ao base: este n´o nunca gera pacotes (n˜ao faz medi¸c˜oes) e quando recebe pacotes de n´os vizinhos simplesmente os contabiliza (n˜ao h´a fila, nem tentativas de transmiss˜ao).

3.1.5 Resultados da Simula¸c˜ao

Quando o usu´ario do simulador requisita a interrup¸c˜ao parcial (pausa da simula¸c˜ao) ou total (encerramento da simula¸c˜ao), o sistema deve apresentar, para cada sensor da rede, as seguintes informa¸c˜oes atrav´es da interface:

• n´umero de pacotes gerados (originados no n´o) at´e aquele ponto da simula¸c˜ao;

• n´umero de pacotes (originados no n´o) efetivamente entregues `a esta¸c˜ao base at´e aquele ponto da simula¸c˜ao;

• n´umero de pacotes descartados da fila do n´o at´e aquele ponto da simula¸c˜ao; e

• atraso m´edio dos pacotes (originados no n´o) efetivamente entregues `a esta¸c˜ao base at´e aquele ponto da simula¸c˜ao.

O atraso de um pacote ´e o intervalo de tempo decorrido desde a gera¸c˜ao do pacote no seu sensor de origem at´e o momento em que o pacote ´e recebido pela esta¸c˜ao base. Neste sistema, este tempo deve ser calculado em n´umero de slots.

3.2

Lista de Requisitos

Em resumo, o sistema apresenta a seguinte lista de requisitos: • Requisitos Funcionais:

1. O sistema deve receber as configura¸c˜oes a partir de um arquivo de entrada com formato especificado na Se¸c˜ao 3.1.

3. O sistema deve receber uma lista de Block Designs suportados a partir de um arquivo com formato especificado na Se¸c˜ao 3.1.2.

4. O sistema deve permitir que o usu´ario pause a simula¸c˜ao a qualquer momento; neste caso, o sistema deve exibir as estat´ısticas listadas na Se¸c˜ao 3.1.5 na interface com o usu´ario.

5. O sistema deve permitir que, quando pausada, a simula¸c˜ao seja reiniciada de acordo com um comando do usu´ario.

6. O sistema deve permitir que o usu´ario interrompa a simula¸c˜ao a qualquer momento; neste caso, o sistema deve exibir as estat´ısticas listadas na Se¸c˜ao 3.1.5 na interface com o usu´ario e encerrar a execu¸c˜ao.

7. O tempo de simula¸c˜ao deve ser discretizado em slots.

8. O sistema deve garantir que cada n´o gere um novo pacote sempre que este verificar mudan¸cas na oxigena¸c˜ao da ´agua.

9. Cada n´o deve transmitir seus pacotes sempre atrav´es do mesmo link, conforme especi-ficado no arquivo de configura¸c˜ao.

10. N´os devem ter referˆencias de tempo locais, potencialmente diferentes daquelas dos de-mais n´os.

11. O r´adio de cada n´o deve ser ligado e desligado atrav´es de um padr˜ao de atividade; o padr˜ao de atividade de cada n´o ´e obtido atrav´es da combina¸c˜ao de uma ou mais t´ecnicas de duty cycle especificadas no arquivo de configura¸c˜ao; RN1: a determina¸c˜ao de se um n´o est´a ou n˜ao com seu r´adio ligado deve ser feita com base na referˆencia de tempo local do n´o; RN2: o sistema deve dar suporte a utiliza¸c˜ao das seguintes t´ecnicas para gera¸c˜ao dos padr˜oes: Block Designs, Grid e Torus.

12. Enquanto esperam a oportunidade de transmiss˜ao, pacotes devem ser armazenados em uma fila com capacidade m´axima de 10 pacotes; RN3: pacotes sempre s˜ao inseridos no final da fila; RN4: pacotes sempre s˜ao removidos (para transmiss˜ao) do in´ıcio da fila; RN5: caso a fila esteja cheia e o n´o tente inserir um novo pacote, o ´ultimo pacote atualmente na fila deve ser removido e descartado.

13. Uma transmiss˜ao s´o ´e bem sucedida se ambos os r´adios, do transmissor e do recep-tor, est˜ao ligados simultaneamente. Se isso ´e verdade, o sucesso da transmiss˜ao ainda depende do acaso e s´o ocorre com uma probabilidade p, especificada no arquivo de configura¸c˜ao.

14. Cada n´o deve ser representado por um ID, variando de 0 a n − 1 (onde n ´e o n´umero de n´os, incluindo a esta¸c˜ao base); RN6: os IDs dos n´os s˜ao dados implicitamente pelo arquivo de configura¸c˜ao, conforme detalhado na Se¸c˜ao 3.1; RN7: a esta¸c˜ao base tem sempre ID n − 1 (consequentemente, ´e o ´ultimo n´o especificado no arquivo de configura¸c˜ao).

• Requisitos N˜ao Funcionais:

1. O sistema deve ser implementado na linguagem Java.

2. O sistema deve ser estruturado de forma a permitir a f´acil adi¸c˜ao de padr˜oes de atividade gerados a partir de outras t´ecnicas (i.e., diferentes dos Block Designs, do Grid e do Torus).

3. O sistema deve implantar, ao menos, dois padr˜oes de projeto estudados ao longo da disciplina.

4

Entrega do Trabalho e Avalia¸

c˜

ao

O trabalho deve ser entregue at´e o dia 30 de novembro. A entrega pode ser feita pessoalmente atrav´es de alguma m´ıdia f´ısica (CD, DVD, pendrive, etc.) ou, preferencialmente, por e-mail. Note que, se a entrega for realiza por e-mail, ser´a considerada a data de chegada da mensa-gem (sugest˜ao: enviem com alguma antecedˆencia e garantam que a mensagem foi efetivamente recebida).

O material entregue deve conter os seguintes itens:

1. c´odigo fonte completo do sistema e eventuais outros arquivos necess´arios a sua compila¸c˜ao; 2. arquivo do tipo readme contendo instru¸c˜oes (resumidas) sobre a compila¸c˜ao e uso do sistema,

al´em da especifica¸c˜ao de em que parte do sistema e por qual raz˜ao foram adotados os padr˜oes de projeto utilizados;

3. relat´orios individuais (um para cada integrante do grupo) listando sua participa¸c˜ao e con-tribui¸c˜oes no desenvolvimento do sistema; e

4. diagrama de classes (UML) com o projeto do sistema.

Cada componente do grupo receber´a uma nota de 0 a 10 pelo trabalho. A nota do trabalho ser´a composta pela avalia¸c˜ao dos seguintes itens:

• qualidade do projeto do sistema, avaliado de acordo com o diagrama de classes entregue (2 ponto);

• aderˆencia aos requisitos especificados neste documento, exceto requisito n˜ao-funcional 3 (at´e 3 pontos);

• utiliza¸c˜ao justificada de padr˜oes de projeto vistos ao longo do curso (at´e 4 pontos, sendo at´e 1 ponto para cada padr˜ao de projeto utilizado, citado no arquivo readme e justificado); • qualidade da documenta¸c˜ao do c´odigo e do arquivo readme (at´e 2 pontos);

Note que as notas s˜ao individuais, podendo cada integrante do grupo obter uma nota diferente com base no item 5. Note ainda que a soma dos itens de avalia¸c˜ao corresponde a um total de 13 pontos. Caso a nota de um integrante do grupo seja maior que 10, este ter´a a nota final do trabalho truncada para 10. Trabalhos incompletos ser˜ao avaliados, por´em os itens n˜ao implementados/entregues ter˜ao nota 0.

Parte do trabalho inclui o entendimento da especifica¸c˜ao. Caso haja alguma d´uvida em rela¸c˜ao `