projeto final de programação - inf.puc-rio.brrvasconcelos/projeto final/documentação... · o...
TRANSCRIPT
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].