PUC

Projeto Final de Programação

Mecanismo para Criação e Gerenciamento de Grupos no Middleware de Comunicação do

ContextNet

Rafael Oliveira Vasconcelos

Professor Orientador:

Markus Endler

Professor Coordenador:

Arndt von Staa

Departamento de Informática

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO

RUA MARQUÊS DE SÃO VICENTE, 225 - CEP 22453-900

RIO DE JANEIRO - BRASIL

ii

Sumário

1. Introdução .............................................................................................................. 1

2. GroupDefiner ......................................................................................................... 4

3. PoA-Manager ........................................................................................................ 7

4. Gateway .............................................................................................................. 10

5. MTD Service ........................................................................................................ 12

6. Roteiro de Testes ................................................................................................ 15

7. Acompanhamento de Execução .......................................................................... 17

8. Comentários de Controle de Versão .................................................................... 18

Bibliografia .................................................................................................................. 26

1

1. Introdução

O trabalho proposto faz parte do projeto ContextNet [1] desenvolvido no LAC (Laboratory for Advanced Collaboration). Este projeto tem como objetivo desenvolver serviços de distribuição de informações de contexto e de raciocínio autônomo para colaboração pervasiva em sistemas móveis de larga escala com suporte a monitoramento, comunicação e coordenação das atividades dos nós móveis em tempo real. O ContextNet tem como foco principal o desenvolvimento de tecnologias de middleware para distribuição escalável das informações de contexto entre centenas de milhares de nós produtores e consumidores de conteúdo, como também técnicas de raciocínio inerentemente distribuídas e capazes de detectar situações compostas de contexto – resultado do agrupamento de situações primárias – que sejam relevantes para as aplicações. Como exemplo, é possível citar padrões de movimentação entre os nós e detecção da área de cobertura de equipes de resgate.

Dentre as diversas camadas do ContextNet, este trabalho desenvolveu um novo mecanismo de criação e gerenciamento de grupos para o núcleo da camada de distribuição de dados SDDL [2] [3] [4] [5]. Esta camada conecta nós estacionários DDS [6] em uma rede cabeada (denominado de núcleo – core – do SDDL) a nós móveis usando conexão sem fio. Dentro do core SDDL a comunicação entre os nós é realizada através do padrão DDS e cada nó tem uma função específica (são exemplos definição de grupos, monitoramento e controle dos nós móveis, agregação de dados e gerência de mensagens não entregues aos nós móveis). A Error! Reference source not found. ilustra a arquitetura do SDDL aplicada no projeto de rastreamento de veículos InfoPAE Móvel desenvolvido em parceria com o laboratório Tecgraf.

A camada SDDL utiliza como implementação do padrão DDS o middleware

CoreDX DDS [7].

Figura 1. Arquitetura do SDDL

2

O objetivo geral deste projeto final de programação foi alterar a modo como os grupos eram criados e gerenciados para flexibilizar a utilização da camada SDDL.

Os objetivos do novo modelo foram:

Permitir a criação de grupos baseado em informações de contexto produzidas pelos nós móveis

Permitir a criação de grupos explícitos, ou seja, grupos criados arbitrariamente pelo administrador do sistema.

Para atender os objetivos citados, foram considerados os seguintes requisitos:

Possibilitar que a lógica da definição dos grupos pudesse ser facilmente alterada;

Possibilitar a inserção agentes definidores de grupos (GroupDefiner) com lógicas diferentes na arquitetura do SDDL, ou seja, permitir que houvesse GroupDefiners com implementações diferentes para a definição dos grupos;

Criar uma solução de baixo custo computacional.

Para permitir que a lógica da definição dos grupos pudesse ser facilmente alterada, a lógica da definição dos grupos é implementada como um módulo (Group Selection Module) que o GroupDefiner utiliza, desta forma o GroupDefiner fica genérico e permite que o desenvolvedor implemente um módulo contendo apenas a lógica de como os nós móveis devem ser agrupados.

Cada módulo de seleção de grupo possui um identificador único que é utilizado como chave composta do grupo, o que possibilita que outro módulo funcione na arquitetura SDDL sem o perigo de conflitos de identificadores.

Por fim, é mostrado em [5] que o modelo atual dos grupos é mais performático que o modelo anterior e que a nova solução apresenta baixo custo computacional. Os experimentos realizados mostram que em menos de 20 milissegundos após o recebimento do dado de contexto produzido pelo nó móvel, a infraestrutura do SDDL é capaz de atualizar os grupos que o nó móvel pertence.

A alteração da criação e gerenciamento dos grupos impactou em três outros serviços do SDDL além do GroupDefiner: (i) Gateway, (ii) Mobile Temporary Disconnection Service (MTD) e (iii) Points of Attachment-Manager (PoA-Manager). Um novo GroupDefiner foi projetado e implementado, enquanto os demais serviços foram adaptados para trabalharem com o novo modelo de grupos. Nas próximas seções são apresentados os projetos de cada um destes serviços.

3

Figura 2. Casos de uso da camada SDDL

A Figura 2 mostra os casos de uso da camada SDDL aplicada ao InfoPAE Móvel. Atualmente toda a interação do usuário móvel com o sistema ou supervisor é generalizada para o envio/recebimento de mensagens.

Figura 3. Organização dos dados trafegados no núcleo do SDDL

A Figura 3 mostra a organização dos tópicos que são trafegados dentro do núcleo do SDDL. A Figura 4 mostra os dados que são trocados entre os nós móveis e a arquitetura.

4

Figura 4. Organização dos dados trocados entre o nó móvel e o núcleo do SDDL

2. GroupDefiner

Este trabalho de Projeto Final de Programação desenvolveu um GroupDefiner totalmente novo, o que possibilitou a criação de pequenos módulos internos, melhor documentação e legibilidade do código.

A Figura 5 mostra uma visão de alto nível do GroupDefiner e suas interações com o núcleo do SDDL. O GroupDefiner se comunica apenas com o Gateway, que é quem recebe e repassa as informações de contexto produzidas pelos nós móveis.

5

Figura 5. Arquitetura de alto nível do GroupDefiner

A Figura 6 exibe a arquitetura interna do GroupDefiner. Ele possui dois módulos distintos, o Group Selection Module e o Group Membership G-Diff Message. O Group Selection Module é contém toda a lógica utilizada na definição dos grupos. É ele quem efetivamente processa as informações. Este módulo é implementado pelo desenvolvedor da aplicação, conhecedor da lógica de negócio, e deve ser passado no momento da inicialização.

Já o Group Membership G-Diff Message é responsável analisar a diferença sofrida nos grupos que o nó móvel pertence e gerar a G-Diff message. Resumidamente, esta mensagem contém os grupos que foram adicionados ou removidos do nó móvel. Caso não haja mudança, não é produzida a mensagem.

O GroupDefiner fica então responsável apenas por receber as mensagens de contexto e enviar a mensagem G-Diff para o núcleo do SDDL. O GroupDefiner conta ainda com um módulo chamado InfoPAE DDS Manager, que é responsável por gerenciar o uso do CoreDX DDS, o que facilita o seu uso por parte aplicação.

Figura 6. Arquitetura interna do GroupDefiner

Os diagramas de classe do GroupDefiner são mostrados na Figura 7.

6

Figura 7. Diagramas de classe do GroupDefiner

A organização dos dados manipulados pelo GroupDefiner são exibidos na Figura 8.

7

Figura 8. Organização dos dados usados pelo GroupDefiner

3. PoA-Manager

O PoA-Manager (Points of Attachment-Manager) é responsável por balancear a carga dos Gateways. Ele faz a análise da carga de cada Gateway e caso haja um desbalanceamento, manda uma mensagem (PoA-Object) para um conjunto de nós móveis informando que eles devem se conectar a outro Gateway (handover mandatório). É também o PoA-Manager encarregado de informar aos nós móveis quais são os Gateways disponíveis na arquitetura.

Este trabalho apenas adaptou o PoA-Manager para trabalhar com o novo modelo de grupos. Optou-se por ser o menos intrusivo possível no código. Por este motivo, não houve muito esforço na engenharia do PoA-Manager, entretanto toda a documentação foi realizada neste projeto final.

A Figura 9 mostra uma visão de alto nível do PoA-Manager e suas interações com o núcleo do SDDL. Ele se comunica apenas com o Gateway, que é quem recebe e repassa as informações de contexto produzidas pelos nós móveis e as mensagens para os nós móveis contendo o PoA-Object.

8

Figura 9. Arquitetura de alto nível do PoA-Manager

A Figura 10 exibe os módulos do PoA-Manager. Além do InfoPAE DDS Manager, comum a todos os nós do núcleo SDDL, o PoA-Manager possui o Load Report Analyzer e Planning Executor.

O Load Report Analyzer é o módulo responsável por analisar a carga de todos os Gateways e definir quantos nós móveis devem ficar conectados em cada Gateway. Já o Planning Executor é encarregado de escolher quais nós móveis sofrerão um handover mandatório, qual o novo Gateway de cada um deles e de criar as mensagens contendo PoA-Object.

Figura 10. Arquitetura interna do PoA-Manager

Os diagramas de classe do PoA-Manager são mostrados em Figura 11.

9

Figura 11. Diagramas de classe do PoA-Manager

A organização dos dados manipulados pelo PoA-Manager é exibida na Figura 12.

Figura 12. Organização dos dados usados pelo PoA-Manager

10

4. Gateway

Responsável por manter a conexão dos veículos com o domínio DDS, um gateway pode receber e manter múltiplas conexões MR-UDP. Ele é responsável por conectar os nós móveis ao núcleo do SDDL. O Gateway é capaz de enviar mensagens através de unicast, groupcast ou broadcast. Por utilizar o protocolo MR-UDP para a comunicação com os nó móveis e também fazer parte do domínio DDS (núcleo do SDDL), o Gateway é considerado um tipo de broker. Este serviço é quem faz a comunicação do núcleo com o mundo exterior.

Foram alteradas as formas de armazenamento, gerenciamento e comunicação de grupos no Gateway, renomeados métodos e variáveis e realizada toda a documentação do código.

Figura 13. Arquitetura de alto nível do Gateway

A Figura 13 mostra uma visão de alto nível do Gateway e suas interações com o núcleo do SDDL. Ele se comunica com todos os outros e é considerado o elemento mais complexo do SDDL.

A Figura 14 ilustra a arquitetura interna do Gateway. Ele possui 4 módulos distintos: (i) Load Monitor, (ii) Pong Manager, (iii) MR-UDP e (iv) InfoPAE DDS Manager. O primeiro módulo é responsável por monitorar a carga do Gateway e periodicamente fazer o envio da sua carga para o PoA-Manager. O segundo módulo é responsável por gerenciar as respostas de um pacote do tipo Ping. Quando, por exemplo, é enviado um pacote Ping para todos os nós móveis, o Gateway espera a resposta de todos os nós móveis a ele conectados para enviar um único pacote Pong (resposta de um pacote Ping) ao domínio. Isto aumenta o desempenho geral da arquitetura e facilita o desenvolvimento das aplicações, pois estas já recebem o dado sumarizado do Gateway. O MR-UDP é responsável por gerenciar o protocolo utilizado para a comunicação com os nós móveis. O ultimo módulo, InfoPAE DDS Manager, já foi explicado nas seções anteriores.

11

Figura 14. Arquitetura interna do Gateway

Figura 15. Organização dos dados usados pelo Gateway

Os dados manipulados pelo Gateway são mostrados em Figura 15. Os diagramas de classe do Gateway são exibidos na Figura 16.

12

Figura 16. Diagramas de classe do Gateway

5. MTD Service

O Mobile Temporary Disconnection Service (MTD Service) é o serviço responsável armazenar as mensagens que por algum motive não puderam ser enviadas para os nós móveis. Em uma situação onde o nó móvel perde sua conexão e após uma hora volta a se comunicar com algum Gateway, todas as mensagens que deveriam ser entregues a este nó móvel serão enviadas no momento da reconexão. Quando o Gateway não consegue fazer o envio de alguma mensagem, ele avisa ao domínio qual foi a

13

mensagem, deste modo o MTD Service armazena estas mensagens. Após uma conexão do nó móvel, o Gateway também notifica o domínio sobre este evento, o qual é recebido pelo MTD Service. O MTD é o serviço mais simples da camada SDDL.

Não foi objetivo deste projeto aplicar uma reengenharia no MTD Service, o esforço foi empregado para fazer as alterações necessárias e sua devida documentação.

A Figura 17 mostra uma visão de alto nível do MTD Service e suas interações com o Gateway, único elemento que o MTD Service tem comunicação.

Figura 17. Arquitetura de alto nível do MTD Service

Figura 18. Arquitetura interna do MTD Service

Por ser o elemento mais simples, o MTD não possui módulos além do InfoPAE DDS Manager, como exibido na Figura 18. Os diagramas de classe do MTD Service são exibidos na Figura 19.

14

Figura 19. Diagramas de classe do MTD Service

A organização dos dados manipulados pelo MTD Service é exibida na Figura 20.

15

Figura 20. Organização dos dados usados pelo MTD Service

6. Roteiro de Testes

Por ser uma implementação totalmente nova do GroupDefiner, este foi o elemento mais testado por este projeto final. Foram realizados testes de caixa branca, preta, testes unitários e automatizados. Por ser uma arquitetura distribuída de comunicação, houve uma maior dificuldade na criação de testes unitários e automatizados. Outro fator que dificultou a realização dos testes foi a natureza paralela e assíncrona do GroupDefiner. Alguns eventos são disparados assincronamente e processados paralelamente, o que algumas vezes inviabiliza a realização de um teste unitário automatizado.

Atualmente a nova implementação já está sendo utilizada e não há o conhecimento de bugs. Os resultados de desempenho foram publicados em [5] e submetidos para o “26th International Symposium on Distributed Computing (DISC)”. Outros testes de desempenho foram realizados em [3] e submetidos para a “ACM/IFIP/USENIX 13th International Conference on Middleware”, entretanto não foram específicos para os serviços mencionados por este projeto final.

Foram realizados testes unitários automatizados nos seguintes métodos do módulo Group Membership G-Diff Message: GetGroupCollection, AddAllGroups e GetGDiffMessage. Também foi realizado um teste automatizado que produzia informações de contexto e verificava a corretude da resposta (mensagem G-Diff criado), quando aplicado. A Figura 21 contém os logs produzidos pelos testes automatizados.

16

Figura 21. Log gerado pelos testes automatizados do GroupDefiner

O MTD Service foi testado com técnicas de caixa branca e preta, além de testes automatizados. Por ser um serviço simples, poucos foram os casos de testes realizados. O teste automatizado consistiu em simular o aviso perda de mensagens e de conexão dos nós móveis a fim de garantir que todas as mensagens foram entregues aos devidos nós. O log dos testes é mostrando na Figura 22.

Figura 22. Log gerado pelos testes automatizados do MTD Service

O PoA-Manager, por ser um serviço de balanceamento de carga, raramente produz algum dado. Na maior parte do tempo este serviço fica recebendo os dados sobre a carga dos Gateways e quando ele detecta um desbalanceamento, pode enviar PoA Objects para os nós móveis. Não há como saber de antemão quais serão os nós móveis escolhidos para sofrerem handover e nem como saber qual será seu novo Gateway. Outro fator que dificultou a realização de testes automatizados é que mesmo que haja um desbalanceamento na arquitetura do SDDL, o PoA-Manager pode decidir não enviar as mensagens de handover, pois o intervalo entre as ações foi considerada curta ou o desbalanceamento não atingiu um limite mínimo. Por tais motivos, foram realizados apenas testes de caixa branca e preta. Em ambos os testes, foram levantados alguns Gateways e simuladores de nós móveis para que fossem realizados os testes. Por vezes o uso de processador dos Gateways era artificialmente aumentando com o uso de programas externos que utilizassem parte dos recursos da máquina.

A atual arquitetura do Gateway inviabilizou a execução de testes unitários e automatizados. Grande parte dos métodos do Gateway é privada e não há retorno, os métodos públicos são utilizados apenas para a notificação de eventos por parte dos listeners, como por exemplo, o recebimento de um dado enviado por um nó móvel. Estes métodos também não possuem retorno. Optou-se então por realizar apenas testes de caixa branca e preta. Nos testes de caixa preta e branca foram utilizados simuladores dos nós móveis e dispositivos reais para verificar o fluxo de execução no Gateway, seu estado, possíveis erros gerados e saída de dados.

17

Com exceção do GroupDefiner, que foi implementado por completo, todos os testes realizados tiveram como foco verificar a existência de erros nas partes que sofreram alteração.

Por fim, foram realizados também testes de integração e de sistema. Todos os serviços estão operando normalmente nos experimentos realizados dentro do LAC. Vale destacar que já foram realizadas duas demonstrações, uma realizada pela equipe do LAC e outra pela equipe do InfoPAE Móvel do Tecgraf, com a versão atual do SDDL.

7. Acompanhamento de Execução

Para conclusão deste trabalho final de programação, foram realizadas as seguintes tarefas:

1. Definir a estrutura do grupo, alterar e compilar a IDL;

2. Implementar um novo GroupDefiner para trabalhar com a nova estrutura de

grupo e informar as operações de lista (G-Diff Message) ao Gateway;

3. Testar a implementação do GroupDefiner;

4. Alterar a implementação do Gateway para trabalhar com operações sobre listas

(G-Diff Message) e a nova estrutura de grupo;

5. Realizar teste do GroupDefiner e Gateway;

6. Alterar a implementação do MTD Service para funcionar com a nova estrutura

de grupo;

7. Realizar teste do GroupDefiner, Gateway e MTD Service;

8. Alterar a implementação do PoA-Manager para funcionar com a nova estrutura

de grupo;

9. Realizar teste do GroupDefiner, Gateway, MTD Service e PoA-Manager;

10. Realizar teste de sistema;

11. Fazer testes de desempenho entre a versão antiga e nova do SDDL;

12. Preparar documentação;

As tarefas 1, 3, 5, 6 e 7 foram classificadas com dificuldade 1 em uma escala que vai de 1 até 3. As tarefas 2, 9, 10, 11 e 12 foram classificados com dificuldade 2. As outras tarefas, 4 e 8, foram classificadas com nível de dificuldade 3.

O cronograma das tarefas é mostrado em Tabela 1.

18

Tabela 1. Cronograma de tarefas

Mês Abril Maio Junho

Tarefa/Semana 1 2 3 4 1 2 3 4 1 2 3 4

1

2

3

4

5

6

7

8

9

10

11

12

8. Comentários de Controle de Versão

A seguir são mostrados todos os comentários de versões que foram realizados no GitHub, ferramenta de controle de versão utilizada pelo LAC. O histórico dos commits está organizado em ordem decrescente, ou seja, do mais recente para o mais antigo.

Jun 23, 2012

1. Traducao do Javadoc do MTD Service …

Alguns comentarios estavam em portugues. Todos foram traduzidos para ingles.

1f0d131535Browse code

rafaelov authored 6 days ago

Jun 19, 2012

1. Traducao do Javadoc do GroupDefinerV2 …

Toda a documentacao do projeto do GroupDefinerV2 foi feita em portugues pensando no

Projeto Final, entretanto para seguir o padrao da linguagem adotada na programacao e

das demais documentacoes do projeto, o Javadoc do GroupDefiner foi traduzido

completamente para ingles

19

c46a9ed445Browse code

rafaelov authored 10 days ago

2. Refatoracao no nome de variavies …

Classe Gateway.java:

Renomeada a variavel LOAD_REPORT_OBSERVER_REFRESH_INTERVAL para

LOAD_REPORT_OBSERVER_REFRESH_INTERVAL_IN_SECS

Renomeada a variavel SEND_LOAD_REPORT_INTERVAL para SEND_LOAD_REPORT_INTERVAL_IN_SECS

Classe PongThread.java:

Renomeada a variavel TIMEOUT para TIMEOUT_IN_SECS

Classe LoadReportObserverTask.java:

Renomeada a variavel freeMemory para freeMemoryInMB

Renomeada a variavel participantIp para participantIpAndPort

22c7bf5b5eBrowse code

rafaelov authored 10 days ago

3. Melhoria no Javadoc do Gateway …

Varios metodos e classes nao possuiam documentacao. Foram realizadas melhorias na

documentacao daquelas classes que ja possuiam Javadoc e criado Javadoc do zero

naquelas que nao possuiam documentacao.

Todas as classes e metodos agora possuem documentacao.

de6f807516Browse code

rafaelov authored 10 days ago

Jun 15, 2012

1. Realizada documentacao do projeto PoAManager …

O projeto possuia pouca documentacao. Foi realizado a documentacao por meio de

Javadoc em todas as classes, atributos e metodos.

38446b51beBrowse code

rafaelov authored 14 days ago

2. Refatoracao da classe PlanningExecutorTask …

20

A classe PlanningExecutorTask foi renomeada para PlanningExecutor por nao se tratar

de uma task.

2c5fc94bc2Browse code

rafaelov authored 14 days ago

Jun 11, 2012

1. Melhoria no Javadoc do GroupDefinerV2 …

Realizada melhoria no texto do Javadoc do metodo receiveTruckInformationTopic().

f2cd8b3370Browse code

rafaelov authored 18 days ago

Jun 08, 2012

1. Melhoria no Javadoc do MTD Service …

Muitos métodos não possuiam documentacao

Feita a documentacao de varias linhas de codigo

8f0710f995Browse code

rafaelov authored 21 days ago

2. Inserido Javadoc na classe GroupDefinerV2Test

e1fa75e81dBrowse code

rafaelov authored 21 days ago

3. Correcao no Javadoc da classe GroupMembershipDiffMessageTask …

Realizada a correcao para alterar os trechos ondem apareciam referencia a classe

TruckInformationTopicTask

677fab75a6Browse code

rafaelov authored 21 days ago

4. Refatoracao do nome da classe TruckInformationTopicTask para GroupMem… …

…bershipDiffMessageTask

Esta alteracao melhora a legibilidade do codigo e fica em conformidada com o padrao

adotado nos artigos

14f489e754Browse code

21

rafaelov authored 21 days ago

May 25, 2012

1. Criacao do javadoc das classes ContextGroupSelectionModule, DISCSelec… …

…tionModule e MiddlewareSelectionModule

d0a6f58db9Browse code

rafaelov authored a month ago

2. Alteracao no javadoc da interface GroupSelectionModuleInterface …

Alterado o termo "veículo" para "mobile node"

cf6728aa99Browse code

rafaelov authored a month ago

3. Refatoracao do nome de variaveis e melhorias no javadoc do GroupDefin… …

…erV2

O nome de algumas variaveis foram alteradas para melhorar a legibilidade do codigo e

seguirem a nomenclatura utilizada nos artigos.

Melhorada a descrição no javadoc da classe GroupDefinerV2

9193e74a06Browse code

rafaelov authored a month ago

4. Melhoramento no javadoc do listener do GroupDefinerV2 …

Revisao do texto no javadoc do método onNewData() da classe GroupDefinerListener

e430da552cBrowse code

rafaelov authored a month ago

5. Refatoracao da interface GroupSelectionInterface no GroupDefiner …

A interface GroupSelectionInterface foi renomeada para GroupSelectionModuleInterface

9b6b548a8eBrowse code

rafaelov authored a month ago

22

May 23, 2012

1. Corrigido o envio de mensagens G-cast no GW

51e7effb8fBrowse code

rafaelov authored a month ago

2. Implementacao de um novo Group Selection Module para o GroupDefiner …

Novo modulo sera utilizado nos testes para a Middleware 2012. Este modulo cria grupos

com 10%, 25% e 50% dos veiculos.

Os grupos com 10% dos veiculos tem IDs entre 10 e 19.

Os grupos com 25% tem IDs entre 20 e 23.

Os grupos com 50% tem IDs entre 50 e 51.

O groupType deste modulo eh 3.

292845b128Browse code

rafaelov authored a month ago

May 22, 2012

1. Normalizacao dos IDs dos grupos gerados …

94d96ce583Browse code

rafaelov authored a month ago

May 21, 2012

1. Atualizacao do Monitor vindo da V2 do InfoPAE …

Adicionado o PingMonitor com suporte a grupo

Alterado o Web Monitor para permitir que o operador informe quantos veiculos serao

exibidos

627d02c549Browse code

rafaelov authored a month ago

2. Refatoracao do metodo generateOperationList() no GD2 …

O metodo generateOperationList() no GroupDefinerV2 foi renomeado para

getGDiffMessage()

bddd952b0bBrowse code

rafaelov authored a month ago

23

3. Adicionado o campo lastLUReceivedTime para realizacao do RTD entre o … …

…Gateway e GroupDefiner

19de98c8a7Browse code

rafaelov authored a month ago

4. Alteracao no Gateway para testes do DISC, Ping de Grupo e checagens d… …

…e nulo

Foram adicionados trechos de codigo para realizar medicao do RTD do momento que um LU

eh recebido ate o momento que o GW realiza a atualizacao das suas estruturas de dados

apos recebimento dos grupos pelo GroupDefiner.

No recebimento de um PingTopic agora eh realizada tambem a verificacao se o Ping se

destina a um grupo.

Adicionada uma verificao de nulo no metodo removeVehicleFromGroups(). Um

processamento anomalo no GroupDefiner poderia causar erro no Gateway

c7c606688dBrowse code

rafaelov authored a month ago

5. Alterada a aplicacao de teste do GroupDefiner …

Foi realizada uma alteracao na aplicacao que testa o GroupDefiner para utilizar o

modulo de selecao do DISC

7cdb4ca1afBrowse code

rafaelov authored a month ago

6. Implementacao de um Group Selection Module novo chamado DISCSelection… …

…Module

Este novo modulo realiza o processamento dos grupos utilizando latitude, longitude e

ID do No Movel.

Este modulo DISC foi utilizado para realizacao dos testes feitos para o DISC

96c9f529c0Browse code

rafaelov authored a month ago

7. Alteracao no processamento do GroupDefiner v1 …

24

Foi criada uma nova classe (GroupDefinerDISCTask) para realizar o processamento dos

grupos utilizados nos testes do DISC

c1ed609039Browse code

rafaelov authored a month ago

May 18, 2012

1. Criacao dos JARs para teste do SDDL v3

6d5eb78cdbBrowse code

rafaelov authored a month ago

2. Refatoracao de packages e nomenclatura do Group Selection Module …

O que antes era chamado de "group processor" passou a ser chamado de "group selection

module"

Feita alteracao da package "processor" para "selectionmodule"

Alteracao da interface "GroupProcessorInterface" para "GroupSelectionInterface"

Alteracao da classe "ContextGroupProcessor" para "ContextGroupSelectionModule"

83eb262e1fBrowse code

rafaelov authored a month ago

3. Testes de caixa preta no MTD Service …

Foram criados testes de caixa preta para o MTD Service

ca9cfc7653Browse code

rafaelov authored a month ago

4. Testes unitarios e de caixa preta no GroupDefinerV2 …

Foram implementados testes unitarios e de caixa preta para o GroupDefinerV2

3ba97fb2fbBrowse code

rafaelov authored a month ago

May 14, 2012

1. Criacao da versão 3 do protótipo do InfoPAE …

Implementado os novos grupos no SDDL. Implementacao do GroupDefinerV2 e alteracoes no

Gateway e PoA-Manager.

Importacao dos outros projetos para a nova versao v3.

25

7790de4f59Browse code

rafaelov authored 2 months ago

May 05, 2012

1. Implementado o processamento da lista de grupos e corrigida as as pac… …

…kges

Todo o processo de recebimento do topico e criacao da lista com as operacoes a serem

realizadas pelo GW foi implementado.

As packages contiam um erro digitacao e por isto foram refatoradadas para

lac.infopae.groupdefiner.XXX

9a9a327cd0Browse code

rafaelov authored 2 months ago

Apr 30, 2012

1. Realizada a subscricao do GroupDefiner v2 (GD2) …

Foi realizada a implementacao que permite ao GD2 receber os LUs transmitidos pelos

GWs

GD2 esta preparada a infraestrutura para a escrita do topico GroupAdvertisementTopic

pelo GD2

83dac42cd1Browse code

rafaelov authored 2 months ago

2. Adicao de novos metodos na classe "Helper" InfoPAEDDSManager …

Foram adicionados os metodos que permitem a criacao do DataReader/Write, bem como a

escrita do topico GroupAdvertisementTopic no dominio DDS

74acc77522Browse code

rafaelov authored 2 months ago

3. Compilacao da IDL do ContextNet contendo o topico GroupAdvertisementT… …

…opic

Novas classes foram geradas para permitir o uso do topico GroupAdvertisementTopic

pelo CoreDX DDS

ed7de145c0Browse code

rafaelov authored 2 months ago

26

4. Criacao do topico GroupAdvertisementTopic que sera utilizado pelo Gro… …

…upDefiner v2 para anuncio da lista de operacoes sobre os grupos do veiculo que o

Gateway deve executar

ef3b965705Browse code

rafaelov authored 2 months ago

5. Criacao e configuracao do projeto do novo GroupDefiner do ContextNet …

Foi criado o projeto do GroupDefiner v2 bem como realizada as configurações basicas

do projeto (e.g. importacao de JARs e dependencias de projetos)

28999928e7Browse code

rafaelov authored 2 months ago

Bibliografia

[1] M. Endler et al., “ContextNet: Context Reasoning and Sharing Middleware for Large-scale Pervasive Collaboration and Social Networking,” in Proceedings of the Workshop on Posters and Demos Track - PDT ’11, 2011, pp. 1-2.

[2] L. David, R. Vasconcelos, L. Alves, R. André, G. Baptista, and M. Endler, “A Communication Middleware for Scalable Real-time Mobile Collaboration,” in IEEE 21st International WETICE, Track on Adaptive and Reconfigurable Service-oriented and component-based Applications and Architectures (AROSA), 2012.

[3] M. Endler, R. O. Vasconcelos, L. David, R. André, and L. Alves, “A DDS-based middleware for scalable tracking and communication of wireless-connected mobile nodes in a WAN.” Monografias em Ciência da Computação - MCC 06/2012, Dep. de Informática, PUC-Rio, ISSN 0103-9741, Rio de Janeiro, 2012.

[4] L. David, R. Vasconcelos, L. Alves, R. André, and G. Baptista, “A Large-scale Communication Middleware for Fleet Tracking and Management,” in Salão de Ferramentas, Brazilian Symposium on Computer Networks and Distributed Systems (SBRC 2012), 2012.

[5] R. O. Vasconcelos, L. David, L. Alves, R. André, and M. Endler, “Real-time Group Management and Communication for Large-scale Pervasive Applications.” Monografias em Ciência da Computação - MCC 05/2012, Dep. de Informática, PUC-Rio, ISSN 0103-9741, Rio de Janeiro, 2012.

[6] OMG, “Data Distribution Service for Real-time Systems.” 2007. [7] T. O. C. Inc, “CoreDX DDS Data Distribution Service Middleware Twin Oaks

Computing, Inc,” 2012. [Online]. Available: http://www.twinoakscomputing.com/coredx. [Accessed: 12-Jun-2012].