Ubiratam Carvalho de Paula Junior Rafaelli de Carvalho Coutinho

Universidade Federal Fluminense Pólo Universitário de Rio das Ostras Faculdade Federal de Rio das Ostras Bacharelado em Ciência da Computação Ubiratam Carvalho de Paula Junior Rafaelli de Carvalho Coutinho Um Ambiente Interativo para a Visualização de Topologias de Redes Rio das Ostras-RJ 2009

ii UBIRATAM CARVALHO DE PAULA JUNIOR RAFAELLI DE CARVALHO COUTINHO UM AMBIENTE INTERATIVO PARA A VISUALIZAÇÃO DE TOPOLOGIAS DE REDES MÓVEIS Monografia apresentada ao Curso de Bacharelado em Ciência da Computação da Faculdade Federal de Rio das Ostras da Universidade Federal Fluminense, como requisito parcial para obtenção do Grau de Bacharel. Área de Concentração: Redes e Algoritmos Distribuídos. Orientador: Prof. Dr. CARLOS BAZILIO MARTINS Rio das Ostras-RJ 2009

iii UBIRATAM CARVALHO DE PAULA JUNIOR RAFAELLI DE CARVALHO COUTINHO UM AMBIENTE INTERATIVO PARA A VISUALIZAÇÃO DE TOPOLOGIAS DE REDES MÓVEIS Monografia apresentada ao Curso de Bacharelado em Ciência da Computação da Faculdade Federal de Rio das Ostras da Universidade Federal Fluminense, como requisito parcial para obtenção do Grau de Bacharel. Área de Concentração: Redes e Algoritmos Distribuídos. Aprovada em MÊS de 2009. BANCA EXAMINADORA Prof. Dr. CARLOS BAZILIO MARTINS - Orientador UFF Prof. NOME DO PROFESSOR INSTITUIÇÃO Prof. NOME DO PROFESSOR INSTITUIÇÃO Prof. NOME DO PROFESSOR INSTITUIÇÃO Rio das Ostras-RJ 2009

Espaço reservado para a dedicatória. iv

Agradecimentos v

Lista de Figuras 2.1 Arquitetura incrementada..................................... 2 2.2 Diagrama ilustrando o modelo de referência de visualização da informação............ 3 4.1 O simulador da ferramenta UPPAAL................................ 8 4.2 Janela do NAM (Network Animator)................................ 9 4.3 Interface gráfica do SPIN, o jspin.................................. 10 B.1 Janela principal do TopVis..................................... 19 B.2 Clique com o botão direito fora do grafo.............................. 20 B.3 Clique com o botão direito em um nó............................... 20 B.4 Clique com o botão direito em uma aresta............................. 20 B.5 Uso da ação Everyone para envio em Broadcast a partir do nó 0................. 21 B.6 Uso da ação Neighbours para envio aos vizinhos do nó 14.................... 21 B.7 Janela principal mais janela auxiliar da simulação......................... 21 vi

Lista de Tabelas vii

Sumário Agradecimentos Lista de Figuras Lista de Tabelas Resumo Abstract v vi vii x xi 1 Introdução 1 1.1 Objetivo.............................................. 1 1.2 Motivação............................................. 1 1.3 Organização............................................ 1 2 Descrição do Ambiente 2 2.1 Objetivo Principal........................................ 2 2.2 prefuse............................................... 3 2.3 LEP................................................ 4 2.4 Características.......................................... 5 3 Implementação 7 3.1 Detalhes da Implementação................................... 7 3.2 Problemas Encontrados..................................... 7 3.3 Testes Realizados......................................... 7 4 Trabalhos Relacionados 8 4.1 UPPAAL............................................. 8 4.2 ns-2................................................ 9 4.3 jspin................................................ 10 5 Trabalhos Futuros 12 6 Conclusão 13 viii

A Gramática em BNF de LEP 14 ix B Manual 18 B.1 Instalação............................................. 18 B.2 Visão geral do TopVis...................................... 18 B.3 Utilizando o TopVis....................................... 19 B.3.1 Gerando a visualização da topologia.......................... 19 B.3.2 Envios de mensagens em broadcast e para nós vizinhos................ 20 B.3.3 Simulando uma especificação LEP........................... 20 Referências Bibliográficas 22

Resumo O processo usual de verificação formal de algoritmos distribuídos e protocolos, através de verificação de modelos [5], demanda normalmente um grande esforço por parte dos projetistas destes protocolos. Algumas justificativas para este esforço são: a complexidade inerente destes protocolos e algoritmos, a escassez de ferramentas de propósito específico e a pouca afinidade dos projetistas de protocolos com ferramentas de verificação formal. Com isso, a validação destes algoritmos usualmente é feita utilizando ferramentas de simulação, as quais são mais simples de se manusear, mas que não garantem formalmente os resultados obtidos. De forma a atenuar esta dificuldade no manuseio dessas ferramentas formais, neste projeto foi projetado um ambiente visual interativo, chamado TopVis, que servirá como interface para a arquitetura proposta em [1, 2], a qual permite a especificação e verificação formal de protocolos e algoritmos distribuídos. Este ambiente utiliza LEP como entrada, uma linguagem para especificação de protocolos similar a SDL [14], mas com construções com maior poder de expressão. A saída inicial será a visualização gráfica da topologia descrita na especificação LEP. Na especificação são utilizados recursos gráficos de forma a tornar mais amigável o processo de especificação e verificação formal e, também, os resultados obtidos. A dificuldade da primeira parte reside, não apenas na representação gráfica das topologias de rede, como também na dinâmica destas. A segunda parte apresenta como desafio retornar os resultados de uma verificação de forma tão abstrata quanto a linguagem de especificação das consultas para a verificação. O estágio atual da ferramenta permite a visualização da topologia e a simulação das ações presentes na especificação em LEP. Entretanto, uma vez que sejam feitas adequações nas partes intermediárias da arquitetura alvo [1], etapa que não estava no escopo deste trabalho, o resultado da verificação no nível do ambiente será facilmente recuperado, gerando as modificações necessárias na visualização da topologia. Além da importância deste ambiente para a manipulação da arquitetura de verificação formal, sua utilização também parece interessante em cursos voltados para a área de algoritmos distribuídos. Isto é justificado pois, além de servir como interface para a arquitetura citada, também possui uma ferramenta de simulação, a qual executa as ações presentes na especificação LEP ilustrando trocas de mensagens na visualização da topologia. Palavras-chave: Linguagem de especificação, Verificação Formal, Protocolos de Rede, LEP. x

Abstract The usual process of formal verification of distributed algorithms and protocols, through model checking [5], usually demand a great effort by the designers of these protocols. Some reasons for this effort are: the inherent complexity of these protocols and algorithms, the lack of tools for specific purpose and little affinity for designers of protocols with tools for formal verification. Therefore, the validation of these algorithms is usually done using simulation tools, which are easier to handle, but not formally guarantee the results. In order to alleviate this difficulty in handling these formal tools, in this project was designed a visual interactive environment, called TopVis to serve as an interface to the architecture proposed in [1, 2], which allows the formal specification and verification protocols and distributed algorithms. This environment uses LEP as input, a language for specifying protocols similar to SDL [14], but with a greater power of expression. The initial output will be viewing of the topology described in the specification LEP. The specification using graphical features are used in order to make the process more friendly for formal specification and verification, and also the results. In the specification, the difficulty lies not only on the graphical representation of the network topologies, but also on the dynamics of these. In the verification, the challenge is to return the results of the verification so abstract as the language for specification of queries for verification. The current stage of the tool allows the visualization of the topology and simulation of actions in the specification in LEP. However, once adjustments are made in parts of the intermediate target architecture [1], stage that wasn t in the scope of this work, the result of verification in the environment will be easily recovered, generating the necessary changes in the topology display. In addition to the importance of an environment for the manipulation of formal verification of architecture, its use seems also interesting in courses towards the area of distributed algorithms. This is justified because, besides serving as an interface to the architecture above, it also has a tool for simulation, which executes the actions specified in the LEP illustrating exchanges of messages in the visualization of topology. Keywords: Specification language, formal verification, network protocol, LEP. xi

Capítulo 1 Introdução 1.1 Objetivo 1.2 Motivação 1.3 Organização

Capítulo 2 Descrição do Ambiente 2.1 Objetivo Principal O objetivo principal do ambiente TopVis é prover uma ambiente interativo para a arquitetura de especificação e verificação formal de protocolos proposta em [1]. Esta arquitetura, agora incrementada com o ambiente, é ilustrada na figura 2.1. Figura 2.1: Arquitetura incrementada A figura 2.1 descreve o processo de verificação proposto em [1]. Inicialmente, é inserida no ambiente uma especificação em LEP (seção 2.3) que contém a descrição da topologia de rede para qual o protocolo é projetado, a especificação do protocolo e a especificação das propriedades a serem verificadas. O módulo LEP2CI, traduz esta especificação para um código intermediário. O código intermediário obtido é passado para algum dos módulos de conversão de forma que a associada ferramenta de verificação possa ser utilizada com o modelo convertido. Tem-se então o processo de verificação de modelos tradicional.

3 O resultado desta verificação é passado a outro módulo, que fará a interpretação do mesmo, gerando o código intermediário respectivo. Este, por sua vez, é processado para que a resposta seja dada em termos de LEP. Finalmente, a partir desta resposta em LEP, uma visualização é gerada no ambiente TopVis. O TopVis, além de ser uma interface projetada para o processo de especificação e verificação formal de protocolos, também possui uma ferramenta de simulação da especificação. Está ferramenta não verifica as propriedades, apenas realiza as ações de uma possível linha de execução da especificação. Estas ações são ilustradas na visualização da topologia. No ambiente TopVis, a biblioteca prefuse (seção 2.2) é usada para gerar, tanto a visualização gráfica da topologia utilizada, quanto o resultado da simulação da especificação em LEP. 2.2 prefuse O prefuse [7] é uma biblioteca para construção de aplicações de visualização de informação interativa. Ela foi escrita na linguagem Java, usando a biblioteca gráfica Java 2D, e é facilmente integrado em aplicações Java Swing ou em applets web. Está licenciado sob os termos de uma licença BSD, e pode ser livremente utilizado tanto para propósitos comerciais como não-comerciais. O prefuse tem a intenção de simplificar os processos de representação e manipulação eficiente de dados, mapeando dados para representações visuais (por exemplo, através da posição espacial, tamanho, forma, cor, etc), e permitindo a manipulação direta dos dados visualizados. O seu design se baseia no modelo de referência de visualização da informação, um padrão de arquitetura de software que divide a visualização do processo em uma série de passos discretos, a partir da aquisição de dados e da modelagem para a codificação visual de dados para a apresentação de displays interativos. Este processo é ilustrado na figura 2.2. Figura 2.2: Diagrama ilustrando o modelo de referência de visualização da informação Na figura 2.2, dados fontes são mapeados em tabelas de dados. Estas tabelas de dados são então utilizadas para construir uma abstração visual de dados, modelando propriedades visuais como posição, cor e geometria. A abstração visual é então usada para criar visualizações interativas, com a interação do usuário potencialmente afetando em mudanças em qualquer nível da estrutura. Por exemplo, um arquivo xml contendo as informações de um grafo pode ser utilizado para preencher as tabelas de dados. Como se trata de um grafo, são preenchidas duas tabelas. A primeira é referente ao nós do grafo, onde cada linha representa um nó, e cada coluna representa as informações do nó, como nome e tipo. A segunda tabela é referente às arestas do grafo, onde cada linha representa uma aresta, e cada coluna contém, além dos identificadores dos nós que a compõem, informações como tipo

4 e nome. Tendo estas tabelas preenchidas, é criada uma abstração visual para o grafo. Nesta abstração visual são definidos a geometria e as cores dos nós e arestas, além de como estes componentes irão se comportrar. Após criada a abstração visual, são definidos mecanismos de interação. Estes mecanismos podem ser ações de movimentação do grafo e de zoom. 2.3 LEP LEP (Linguagem de Especificação de Protocolos) [1, 2] é uma linguagem de domínio específico para especificação de protocolos e algoritmos distribuídos. Ela é similar a SDL [14], mas com construções, chamadas pronomes, as quais possuem maior poder de expressão. Pronomes podem ser vistos como uma forma geral e uniforme de referenciarmos um conjunto de elementos (nós de uma rede), tornando a especificação mais compacta, legível e precisa. Um exemplo de pronome chama-se everyone, o qual pode ser utilizado para o envio de uma mensagem broadcast. Uma especificação em LEP pode ser dividida em três partes: a primeira trata da definição da topologia sobre a qual a especificação será baseada; a segunda refere-se à especificação da interação dos elementos da rede, ou seja, a essência do protocolo, e; a terceira refere-se à linguagem de especificação de propriedades a serem verificadas. Na parte referente à topologia, podemos especificar tanto topologias para redes móveis ad hoc quanto para redes estruturadas. As topologias inicialmente previstas em LEP são: Star (topologia em estrela), Ring (topologia em anel), Sequence (topologia em seqüência), Complete (topologia totalmente conectada), Arbitrary (topologia gerada aleatoriamente). Além destas, neste trabalho também foram adicionadas as topologias Mobile (topologia estruturada para estações base e móveis), Bus (topologia em barramento), Tree (topologia em árvore) e Mesh (topologia para redes em malha). Cada tipo de topologia possui parâmetros específicos. Código 1 : Exemplo de especificação LEP 01 topology is star(commander:1; soldier: 6); 02 module Commander 03 init-> everyone!agree; 04 this?yes(any(3)) -> everyone!consensus; 05 this?no -> everyone!cancel; 06 endmodule 07 module Soldier 08 this?agree -> sender!yes; 09 this?agree -> sender!no; 10 this?consensus -> 11 this?cancel -> 12 endmodule No código 1 é mostrado um exemplo de especificação LEP sem a terceira parte, a qual se refere à especificação de propriedades a serem verificadas formalmente.

5 Neste código, a linha 1 (referente a primeira parte de LEP) indica a topologia estrela, onde o nó central é denominado commander e os demais denominados soldier, totalizando 7 (sete) elementos. Na linha 2, começa o primeiro módulo, nomeado commander, o qual possui como ação inicial o envio da mensagem agree em broadcast (linha 3). Depois, o nó que executa este módulo fica esperando o recebimento de mensagens. Caso receba 3 (três) mensagens yes, ele enviará novamente em broadcast a mensagem consensus (linha 4). Caso receba mensagens no, ele enviará em broadcast a mensagem cancel (linha 4). O segundo módulo, nomeado soldier, começa na linha 7, e todos os nós que o executam (6 (seis) neste exemplo), ao receberem a mensagem agree, enviam, não-deterministicamente, mensagens yes ou no ao remetente (linhas 8 e 9). Se estes receberem mensagens cancel ou consensus não executam ação alguma (linhas 10 e 11). O módulo termina na linha 12. Para que a ferramenta de simulação do TopVis fosse capaz de simular este código, foram discutidos e resolvidos alguns problemas conceituais sobre a funcionalidade deste protocolo, os quais são abordados na seção 3.2. Neste exemplo de código, é possível observar algumas características de LEP. Primeira, na especificação, a descrição geral do comportamento de um nó é feita independentemente de sua quantidade na topologia. Segunda, pode-se ter especificações incompletas, como mostrado nas linhas 10 e 11 do código 1. Terceira, o uso do pronome any para análise de histórico das mensagens recebidas, assim, a pré-condição só será satisfeita quando o nó receber a quantidade de mensagens indicada no parâmetro do pronome any. 2.4 Características O ambiente proposto, TopVis, foi implementado na linguagem Java e utiliza a biblioteca prefuse. Sua entrada é uma especificação escrita em LEP. Este ambiente consiste de uma janela principal que possui uma área para a visualização da topologia e do resultado da simulação (e futuramente o da verificação) e 3 (três) áreas para entrada da especificação LEP (uma para cada parte). No ambiente é possível gerar a visualização da topologia e executar a simulação descritas na especificação LEP. Entretanto, para executar a simulação é necessário antes ter sido gerada a visualização da topologia. Também existe a opção de realizar ações de envios em broadcast e para os nós vizinhos utilizando o menu actions. As topologias, tanto as previstas em LEP quanto as que foram disponibilizadas, foram criadas modularmente, permitindo sua reutilização para criação de possíveis novas topologias. Por exemplo, ao ser disponibilizada a topologia mobile, foram utilizadas as topologias já existentes (previstas em LEP) Ring, para as torres (estações base), e Star para os celulares (estações móveis). O TopVis, além de exibir a visualização da topologia, permite que esta seja modificada pelo usuário da seguinte forma: inserindo novos nós (componentes da rede), arestas (ligação entre componentes da rede), nós filhos, reconectando nós existentes, removendo ou renomeando nós e alterando a cor das arestas. Neste ambiente também é possível realizar operações de zoom e pan, as quais são operações

6 padrão de manipulação deste tipo de estrutura, como descrito em [8]. As topologias aceitas pelo ambiente utilizam um modelo de mobilidade (layout de apresentação definido na biblioteca prefuse) que se baseia na simulação física de forças de interação. Neste modelo, os nós se repelem, as arestas funcionam como molas e o arraste de nós simula a resistência do ar. De forma a tornar mais realística a visualização das topologias, é proposto como trabalho futuro a implementação de novos modelos mobilidade [4], os quais poderão ser disponibilizados como extensões da biblioteca.

Capítulo 3 Implementação 3.1 Detalhes da Implementação 3.2 Problemas Encontrados 3.3 Testes Realizados

Capítulo 4 Trabalhos Relacionados Existem diversas ferramentas de visualização de topologias para redes, tanto redes móveis quanto estruturadas [15, 6]. Entretanto, a maioria destas está voltada apenas para ambientes de simulação. Como o processo de verificação formal de modelos demanda apenas uma quantidade representativa de informação para validação de propriedades [1], serão discutidos os ambientes de visualização voltados para a verificação formal (UPPAAL e jspin) e apenas um ambiente de simulação (ns-2 ). 4.1 UPPAAL A ferramenta UPPAAL [3] é um verificador formal para sistemas de tempo-real, o qual pode ser utilizado para criação de modelos como rede de autômatos temporizados. Esta ferramenta possui 3 (três) partes principais: uma linguagem de descrição, um simulador e um verificador de modelo. Figura 4.1: O simulador da ferramenta UPPAAL. A linguagem de descrição é uma linguagem não-determinística de comando guardado com variáveis de relógio de valor real e tipo simples de dados. Esta serve como linguagem modelo ou projeto para descrever o comportamento do sistema de rede de autômatos estendido com relógio e variáveis de dados. Basicamente, consiste em um autômato finito temporizado. O simulador é uma ferramenta de validação,

9 a qual permite a examinação de execuções possivelmente dinâmicas de um sistema durante os estágios iniciais do projeto (ou modelagem). O verificador de modelos é utilizado para verificar propriedades invariantes explorando o espaço de estados possíveis. O TopVis é similar a esta ferramenta em 2 (dois) aspectos principais. Primeiro, utilizam uma linguagem para descrever o comportamento dos componentes da rede. UPPAAL utiliza autômatos finitos temporizados, enquanto que o TopVis utiliza LEP, a qual possui nível de abstração maior, o que simplifica o processo de simulação e, futuramente, de verificação. Segundo, ambos possuem ferramenta de simulação. Entretanto, TopVis e UPPAAL se diferem também em 2 (dois) aspectos. Primeiro, a topologia da rede representada por um grafo é gerada a partir de um código LEP no TopVis. Já na ferramenta UPPAAL, é necessário construir um autômato finito correspondente à topologia desejada. Segundo, o TopVis não possui verificador de modelos. Este servirá com interface gráfica (frontend) para a arquitetura de verificação formal citada em [1]. Já a ferramenta UPPAAL possui um verificador de modelos próprio. 4.2 ns-2 O ns-2 [11] (Network Simulator) é uma simulador baseado em eventos discretos direcionado para a pesquisa de redes de computadores. É orientado a objetos e escrito em C++ com um interpretador OTcl [12] (extensão orientada a objetos do Tcl - Tool Command Language) como frontend. Fornece suporte para simulação de TCP, roteamento e protocolos multicast sobre redes wired e wireless (local e satélite). Implementa filas de roteamento e abordagens para QoS. Possui uma ferramenta de animação, o NAM [10] (Network Animator), uma ferramenta de plotagem, o xgraph, e utiliza arquivo de trace, onde são armazenados resultados de cada evento da simulação. Figura 4.2: Janela do NAM (Network Animator). O processo de simulação é composto por 3 (três) partes. A primeira compreende a elaboração de um arquivo script em OTcl, no qual contém a criação do simulador, a abertura de arquivos de trace, a definição da topologia da rede, a geração do tráfego da rede, a programação dos escalonadores e timers, e o fechamento da simulação e animação. A segunda parte consiste na execução desse script, o que gera os arquivos de trace. E a terceira é a parte após a conclusão da simulação, em que se pode imprimir estatísticas, visualizar eventos utilizando o NAM e analisar arquivos de trace.

10 O TopVis é similar a este simulador em 3 (três) aspectos. Primeiro, ambos utilizam uma linguagem de entrada para definir os componentes da simulação. No caso de ns-2, um script em OTcl é utilizado para, dentre outras configurações do simulador (citadas acima), definir a topologia da rede. Segundo, possuem animação da simulação. O ns-2 utiliza o NAM, e o TopVis a própria visualização da topologia, que utiliza a biblioteca prefuse [7]. Terceiro, utilizam arquivo de trace, onde é armazenado as informações e etapas da simulação. Entretando, o ns-2 se difere do TopVis em 1 (um) aspecto principal. Como o ns-2 é um simulador de redes, este possui propriedades e configuração mais específicas para simular uma rede de comunicação real, como largura de banda dos enlaces e filas de roteamentos. Já o TopVis, utiliza a visualização do grafo apenas para ilustrar a topologia utilizada e envio/recebimento de mensagens, sem considerar características específicas dos nós, enlaces e roteadores. Além disso, este último servira como interface para uma arquitetura de especificação e verificação formal. 4.3 jspin O SPIN [9] é uma ferramenta para análise de consistência de sistemas concorrentes (em particular protocolos de comunicação de dados) que são especificados usando a linguagem Promela [13] (Process Meta Language). Ou seja, não há visualização gráfica da topologia de entrada. A sua saída, no caso de erro, são contra-exemplos apresentados como diagramas de sequência de mensagens (MSC - Message Sequence Charts). Entretanto, a quantidade de informação pouco abstrata presente nos contra-exemplos (por consequência da linguagem de entrada Promela) dificulta o entendimento destes. Figura 4.3: Interface gráfica do SPIN, o jspin. O jspin é uma interface gráfica de usuário para o verificador de modelo SPIN. Este foi escrito na linguagem de programação Java para permitir a portabilidade. A interface do usuário de jspin é simples, consistindo de uma única janela com menus, uma barra de ferramentas e três áreas de texto ajustáveis. O TopVis é similar a esta ferramenta em 2 (dois) aspectos principais. Primeiro, ambos utilizam uma linguagem para definir a topologia e código a ser simulado. No entanto, no TopVis é possível

11 gerar a visualização da topologia a partir da linguagem, no caso, LEP. Segundo, possuem ferramenta de simulação. Entretanto, o TopVis difere do jspin, pois não possui verificador de modelo. Inclusive, o objetivo deste ambiente é ser um interface para a arquitetura de especificação e verificação proposta em [1], onde, no baixo-nível, é possivel usar o SPIN como ferramenta de verificação.

Capítulo 5 Trabalhos Futuros Como trabalhos futuros, têm-se: adequação dos módulos intermediários da arquitetura incrementada (figura 2.1), adição da opção de simulação guiada, melhorar o desempenho da simulação e implementar novos modelos de mobilidade. Para que a arquitetura incrementada (figura 2.1) funcione integralmente, são necessárias adequações em seus módulos intermediários. Estes módulos são responsáveis pela tradução de LEP para CI (código intermediário), e de CI para a linguagem de entrada do verificador (por exemplo, Promela [13] para o SPIN [9]). Uma vez que estas adequações sejam realizadas, o resultado do verificador será facilmente recuperado ao nível do ambiente TopVis. Lembrando que este resultado será um contra-exemplo, caso a propriedade a ser verificada seja falsa, ou apenas uma mensagem de que a propriedade é verdadeira. Atualmente, a simulação realizada no TopVis é feita sem nenhuma interação com o usuário. Isto é, quando a simulação é iniciada, este não pode controlar a ordem com que as ações são simuladas, nem mesmo escolher a ação a ser simulada quando existe um não-determinismo (por exemplo, quando o recebimento de uma mesma mensagem gera duas ou mais ações possíveis), que é feita de forma aleatória. Para aumentar esta interatividade, será disponibilizada a opção de simulação guiada. Esta, basicamente, consiste em, a cada etapa da simulação, mostrar que ações podem ser realizadas. Assim, o usuário pode decidir a ordem de execução das ações, bem como escolher a ação desejada quando existir nãodeterminismo. Possibilitando a observação de casos específicos de interesse do mesmo. O ambiente TopVis utiliza threads para realizar a simulação da especificação em LEP. É criada uma thread para cada nó da topologia definida. Com isso, cada thread executa as ações do módulo do nó que esta representa. Assim, os envios/recebimentos de mensagens são refletidos com troca de mensagens entre as threads. No caso, estas trocas de mensagens são feitas através de variáveis compartilhadas, e assim, fazendo-se necessário o uso de exclusão mútua. Então, como um outro trabalho futuro, será realizado um estudo sobre possíveis otimizações nesta ferramenta de simulação. No TopVis, a visualização da topologia utiliza o modelo de mobilidade padrão do prefuse (conforme mencionado na seção 2.4). A fim de tornar mais realística esta visualização, como trabalho futuro, é proposto a implementação de novos modelos de mobilidade, os quais serão disponibilizados como extensões da biblioteca.

Capítulo 6 Conclusão

Apêndice A Gramática em BNF de LEP Definição de lista de elementos LIST(X) ::= X, LIST(X) X Espec ::= <Top> { <Mod> } + { <Prop> } Especificação da topologia Top ::= topology is <Topologia> ; Topologia ::= <TopSimples> <TopDuplo> <TopVariavel> TopSimples ::= <TipoTopSimples> ( <Id> : <Num> ) TipoTopSimples ::= ring sequence arbitrary bus mesh TopDuplo ::= <TipoTopDuplo> ( <Id> : <Num> ; <Id> : <Num> ) 14

15 TipoTopDuplo ::= star tree TopVariavel ::= mobile ( <ParamTopVar> ) ParamTopVar::= <Id> : <Num> ; <ParamTopVar> <Id> : <Num> Especificação dos módulos Mod ::= module <Id> [<Locals>] { <Trans> } + endmodule Locals ::= { <Tipo> LIST(<Id>) } Tipo ::= int bool <Id> <Tipo> # <Tipo> seq: <Tipo> set: <Tipo> ( <Tipo> ) Trans ::= <Pre-Cond> -> { <Acao> } Pre-Cond ::= <Recebimento> <Bool-Expr> init true default Recebimento ::= <Ident>? <Id> ( { LIST(<Id>) } ) Ident ::= <Id> [ [ (<Id> <Num>) ] ] [ # <Num>] [. (<ComandosSet> <ComandosSeq>)] <PronomeColetivo> [. (<ComandosSet> <ComandosSeq>)] <Pronome> [ ( (<Num> <Id> <Pronome>) ) ]

16 ComandosSet ::= add ( <Ident> ) remove ( <Ident> ) contains ( <Ident> ) clean empty size ComandosSeq ::= next previous first last range ( <Ident>, <Ident> ) <ComandosSet> Pronome ::= this any anyother sender none <PronomeColetivo> PronomeColetivo ::= everyone neighbours Acao ::= <Atrib> <Envio> ; <If> <While> <Executa> <Termina> <Trans> <Ident> ;

17 Atrib ::= <Ident> = <Expr> ; <Ident> = <Executa> ; Envio ::= <Ident>! <Id> [ ( LIST(<Expr>) ) ] If ::= if <Bool-Expr> then { <Acao> } [ else { <Acao> } ] endif While ::= while <Bool-Expr> do { <Acao> } endwhile Executa ::= start <Ident> ; Termina ::= stop [ <Pronome> ] ; Expr ::= <Bool-Expr> <Int-Expr> { LIST(<Expr>) } <Ident> Bool-Expr ::= ( <Comp-Expr> <Oper-Bool> <Bool-Expr> ) <Comp-Expr> Comp-Expr ::= ( not <Bool-Expr> ) ( <Int-Expr> <Oper-Comp> <Int-Expr> ) ( <Ident> ) ( <Ident>. <Ident> ) Oper-Bool ::= and or Int-Expr ::= ( <Id> <Num> ) <Oper-Int> <Int-Expr> ( <Id> <Num> ) Oper-Int ::= + - * / Oper-Comp ::= == <> > < >= <= Id ::= { <Idm>, <IdM> } + Idm ::= { a,.., z } IdM ::= { A,.., Z } Num ::= { 0,.., 9 } + Especificação das propriedades Prop ::= <Quantif> <Prop> <Sub-Formula> [<Oper-Prop> <Prop>] ( <Prop> ) Sub-Formula ::= <Bool-Expr> <Recebimento> <Envio> <Id> $ <Ident> $ Quantif ::= eventually always Oper-Prop ::= implies strong until weak until

Apêndice B Manual Neste apêndice será explicado como o ambiente TopVis é instalado e utilizado com todas ou apenas uma parte de suas funcionalidades. B.1 Instalação Os passos para realizar a instalação do TopVis são: Windows (qualquer versão) 1. Faça o download do TopVis no site: http://www.ic.uff.br/~bazilio/projetos/topvis.exe. 2. Execute o arquivo para realizar a extração. Selecione a pasta desejada para a qual serão extraídos os arquivos e pastas necessários. 3. Clique no arquivo TopVis.jar. Linux (qualquer distribuição) 1. Faça o download do TopVis no site: http://www.ic.uff.br/~bazilio/projetos/topvis.zip. 2. Faça a extração do arquivo para uma pasta desejada. 3. Execute o arquivo TopVis.jar como aplicativo Java. Ou então, no terminal, na pasta onde foram extraídos os arquivos, execute o comando: java - jar TopVis.jar. B.2 Visão geral do TopVis O ambiente TopVis consiste de uma janela principal, como mostra a figura B.1. Esta janela possui: uma área para visualização da topologia (1), 3 (três) áreas de texto para entrada da especificação em LEP (2) e um combobox para as topologias recentemente usadas (3). Além de botões para: gerar a visualização da topologia (4), verificar a corretude da sintaxe (5), iniciar a simulação (6), e futuramente verificar a propriedade (7). 18

19 Figura B.1: Janela principal do TopVis A janela do TopVis também possui, além dos menus tradicionais (File, Edit e About) (8), o menu Actions (9). Este último realiza ações de envio de mensagens em broadcast ou para os vizinhos neighbours simuladas na vizualização da topologia. B.3 Utilizando o TopVis O TopVis pode ser utilizado de 3 (três) formar: apenas para gerar a visualização da topologia, para demonstrar envios de mensagens em broadcast e para nós vizinhos, e para simular uma especificação em LEP. Futuramente, o TopVis também poderá ser utilizado com interface para a arquitetura de especificação e verificação formal proposta em [1]. B.3.1 Gerando a visualização da topologia Para gerar a visualização da topologia, é preciso escrever a parte da especificação LEP, a qual trata da definição da topologia sobre a qual a especificação será baseada, na área de texto Topology. Após isto, basta clicar o botão de play. Se a sintaxe estiver correta (conforme a gramática da linguagem), a visualização será gerada. Caso contrário, uma mensagem de erro será exibida. É possível interagir com a visualização gerada de 3 (três) formas: Clicando com o botão direito do mouse em cima de um nó (central ou periférico, para o exemplo ilustrado) tem-se as opções de remoção do nó, inserção de um nó filho, renomeação, inserção de aresta, e reconexão a outro nó, conforme mostrado na figura B.3. Clicando com o botão direito fora do grafo tem-se a opção de inserção de um novo nó, conforme mostrado na figura B.2.

Clicando com o botão direito em qualquer aresta tem-se a opção mudar sua cor, conforme mostrado na figura B.4. 20 Figura B.2: Clique com o botão direito fora do grafo Figura B.3: Clique com o botão direito em um nó Figura B.4: Clique com o botão direito em uma aresta B.3.2 Envios de mensagens em broadcast e para nós vizinhos Uma vez que a visualização da topologia foi gerada, é possível realizar envios de mensagens em broadcast (figura B.5) e para os nós vizinhos (figura B.6). Para isto, é necessário usar as opções Broadcast e Neighbours do menu actions. Tendo sido escolhida uma das duas opções, uma janela será exibida para a entrada do nó do grafo que iniciará o envio. B.3.3 Simulando uma especificação LEP Para realizar uma simulação de uma especificação em LEP, é necessário que toda a especificação esteja escrita ou carregada de um arquivo nas áreas de texto do ambiente. Feito isto, a visualização da topologia deve ser gerada para, então, iniciar a simulação da especificação (clicando no botão Load Simulation). Uma nova janela é exibida (ver figura B.7), contendo as etapas da simulação, mostrando a mensagem e a

21 Figura B.5: Broadcast a partir do nó 0 Uso da ação Everyone para envio em Figura B.6: Uso da ação Neighbours para envio aos vizinhos do nó 14 linha da especificação em questão. A visualização da simulação inicia-se com o botão Start, e cada passo é avançado com o botão Next. Por fim, esta é encerrada com o botão End, fechando esta janela auxiliar. A fim de facilitar a escrita da especificação, o usuário pode utilizar o botão Check Sintax para verificar a corretude da sintaxe antes de iniciar a simulação. Este recurso pode ser utilizado sem que a visualização da topologia seja gerada. Figura B.7: Janela principal mais janela auxiliar da simulação

Referências Bibliográficas [1] C. Bazilio. Análise formal de protocolos e algoritimos distribuídos : uma abordagem baseada em linguagem; orientador: Edward hermann haeusler, 2005. Tese (Doutorado em Informática) - Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2005. [2] C. Bazilio, E. H. Haeusler, and M. Endler. Language-oriented formal analysis: a case study on protocols and distributed systems. Electr. Notes Theor. Comput. Sci., 184:189 207, 2007. [3] J. Bengtsson, K. G. Larsen, F. Larsson, P. Pettersson, and W. Yi. UPPAAL - a tool suite for automatic verification of real-time systems. In Hybrid Systems, páginas 232 243, 1995. [4] T. Camp, J. Boleng, and V. Davies. A survey of mobility models for ad hoc network research. Wireless Communications & Mobile Computing (WCMC): Special issue on Mobile Ad Hoc Networking: Research, Trends and Applications, 2(5):483 502, 2002. [5] E. M. Clarke, O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, 2000. [6] K. Fall. Network emulation in the VINT/NS simulator. In Proceedings of the fourth IEEE Symposium on Computers and Communications, 1999. [7] J. Heer, S. K. Card, and J. A. Landay. prefuse: a toolkit for interactive information visualization. In CHI 05: Proceedings of the SIGCHI conference on Human factors in computing systems, páginas 421 430, New York, NY, USA, 2005. ACM. [8] I. Herman, G. Melançon, and M. S. Marshall. Graph visualization and navigation in information visualization: A survey. IEEE Transactions on Visualization and Computer Graphics, 6(1):24 43, 2000. [9] G. J. Holzmann. The model checker spin. IEEE Trans. Softw. Eng., 23(5):279 295, 1997. [10] NAM. Network animator. [Online], 2009. Disponível: http://www.isi.edu/nsnam/nam/ [Acessado em 13.04.2009]. [11] ns-2. The network simulator - ns-2. [Online], 2009. Disponível: http://www.isi.edu/nsnam/ns/ [Acessado em 13.04.2009]. [12] OTcl. Object tool command language. [Online], 2009. Disponível: http://otcl-tclcl.sourceforge.net/otcl/ [Acessado em 13.04.2009]. [13] C. Weise. An incremental formal semantics for promela, 1997. [14] Z.100. Specification and description language, 2002. Z.100 ITU-T Recommendation - Status: in force (08/02). [15] X. Zeng, R. Bagrodia, and M. Gerla. Glomosim: A library for parallel simulation of large-scale wireless networks. In Workshop on Parallel and Distributed Simulation, páginas 154 161, 1998. 22