A especificação do Simple buffer em Circus é usada para armazenar números naturais. O tamanho do buffer é delimitado por maxbuff, uma constante global declarada no parágrafo axiomático. Dois canais tipados input e output são declarados para permitir apenas números naturais em suas comunicações.
values
maxbuff : nat = 3 channel
input , output : nat
Em seguida, um processo explicitamente especificado, chamado de Buffer, é definido. Neste processo existem duas variáveis de estado buff e size. O estado inicial do processo é composto por um buffer vazio onde buff inicialmente é uma sequência vazia e size uma variável que inicialmente recebe o valor 0 e só pode assumir valores inferiores ou iguais aos de maxbuff.
process Buffer = begin s t a t e b u f f : seq o f nat s i z e : nat := 0 operations I n i t : ( ) ==> ( ) I n i t ( ) == b u f f := < > ; s i z e := 0 inputCmd : nat ==> ( ) inputCmd ( x ) == i f ( s i z e < maxbuff ) { b u f f := concat ( buff , x ) ; s i z e := s i z e + 1 } outputCmd : ( ) ==> ( ) outputCmd ( ) == i f ( s i z e > 0) { b u f f := t a i l ( b u f f ) ; s i z e := s i z e ´ 1 } actions
X = ( [ s i z e < maxbuff ] & input ?x ´> inputCmd ( x ) ; X) [ ]
( [ s i z e > 0 ] & output ! headbuff ´> outputCmd ( ) ; X) @
I n i t ( ) ; X
end
No Simple buffer, existem duas operações definidas: InputCmd e OutputCmd. Elas são invocadas por suas expressões correspondentes (InputCmd) e (OutputCmd) nos lados esquerdo e direito, respectivamente, da escolha externa. O comportamento do Buffer é
especificado por sua principal ação: é inicializado o estado inicial; Depois disso, ele fornece a entrada (no caso de o buffer não estar completo) e de saída (no caso de o buffer não estar vazio) eventos para o seu ambiente de forma contínua. Desta forma, armazena a mensagem de entrada no final da sequencia e incrementa seu tamanho em mais um, ou executa um tail na sequencia e diminui seu tamanho para menos um. É necessário destacar que adicionamos os construtores concat e tail para operações sobre sequencias para simplificar o parser. O primeiro construtor recebe como parâmetro uma sequencia de dados do tipo T , um valor de mesmo tipo e tem como saída a concatenação deste valor no final da sequencia (concatpra, bs, cq “ą ra, b, cs). Enquanto o segundo, recebe como parâmetro uma sequencia
de dados e tem como retorno a cauda desta sequencia (tailra, b, cs “ą rb, cs).
Na Tabela3 são apresentados alguns dados experimentais, medidos em segundos, sobre o comparativo de performance da ferramenta resultante deste presente trabalho de dissertação que foi desenvolvida em K, a ferramenta ProB (como descrito em [8]) e FRD 2 [9]. Neste comparativo foi executado o exemplo do Buffer 10 vezes para cada verificador onde se pode observar a média aritmética (µ) e o desvio padrão (σ) das execuções. Infelizmente, os dados referentes a ferramenta ProB foram coletadas do experimento descrito em [8] e como neste trabalho o verificador foi executado apenas uma vez, justifica o desvio padrão igual a zero.
Ferramenta Sis. Operacional Processador Memória Tempo de Análise
K-Circus OS X El Captain 2.5 GHz 4 GB µ=2.46 (σ=0.15)
ProB Ubuntu 12.04 2.5 GHz 2 GB µ=2.15 (σ=0)
FDR 2 OS X El Captain 2.5 GHz 4 GB µ=1.07 (σ=0.04)
Tabela 3 – Comparação entre os verificadores de modelo K-Circus, ProB e FRD
Nos dados dos experimentos existentes na (Tabela3) é possível notar a incomparável performance da ferramenta FDR frente às outras. Isto se deve, principalmente pelo fato de esta ferramenta ter sido implementada de forma extremamente otimizada com base em refinamento. Em se tratando de tempo de análise da propriedade de deadlock, o verificador de modelos objeto de estudo desta dissertação obteve um desempenho semelhante ao da ferramenta ProB muito embora para um experimento mais fidedigno as ferramentas deveriam ser executadas em uma mesma máquina como foi o caso das ferramentas:
FORMULA, FDR e o verificador K-Circus, e mesmo sistema operacional.
Levando em consideração os dados referentes aos ambientes que foram exempli- ficados na Tabela 3, foram realizadas outras analises entre as ferramentas K-Circus e
ProB modificando o delimitador maxbuff. Neste cenário, pode-se perceber que K-Circus é aparentemente mais lento que ProB quando o tamanho do buffer é limitado a um, mas é
bastante semelhante com as demais variações como pode ser evidenciado na Tabela 4.
maxbuff Ferramenta Tempo de Análise
1 K-Circus µ=0.498 ProB µ=0.122 2 K-Circus µ=0.603 ProB µ=0.538 4 K-Circus µ=29.467 ProB µ=28.022
Tabela 4 – Comparação entre os verificadores de modelo K-Circus e ProB
Com respeito aos aspectos qualitativos, tanto K quanto FORMULA proveem meios de se obter um verificador com base na semântica formal da linguagem de interesse, o que confere maior confiança na ferramenta resultante. ProB eFDR, por exemplo, foram desenvolvidos utilizando engenharia de software tradicional, o que os tornam mais propensas a erros. É importante frisar ainda o esforço de desenvolvimento da ferramenta ProB para reescrever a especificação da semântica formal de Circus. Não se pode avaliar tal esforço, mas se pode facilmente pensar em algumas horas de trabalhos manuais potencialmente propensos a erros.
Um outro aspecto a ser destacado é a expressividade do framework K no que tange descrever uma linguagem formal baseada em tipos abstratos de dados. A ferramenta desenvolvida em FORMULA, por exemplo, não foi incluída no segundo experimento (Seção
4.3) pois não consegue lidar de forma fácil com tipos de dados mais ricos. Como estes tipos são bastante exigidos e necessários para uma linguagem como Circus, FORMULA se torna inviável (de maneira geral) como framework de construção de um verificador de modelos completo para Circus, ao ponto que K disponibiliza a grande maioria destes tipos
5 CONCLUSÃO E TRABALHOS FUTUROS
Este trabalho de dissertação apresentou uma forma sistemática de criar uma ferramenta de verificação de modelos que apoia a sintaxe de um subconjunto de Circus e segue fielmente a SOS desta linguagem. Dentre as possíveis técnicas de verificação formal, escolhemos a técnica de verificação de modelos (model checking). Esta decisão foi tomada considerando o potencial de automação, formalismo, qualidade dos resultados produzidos e a crescente aplicação desta técnica tanto na academia quanto na indústria.
Além do suporte a um subconjunto da linguagemCircus, obteve-se uma preocupação em desenvolver uma verificador de modelos prático, intuitivo e sobretudo, que obtivesse um desempenho satisfatório diante de outras ferramentas para análise de linguagens baseadas em CSP existentes na academia. Para tal, foi utilizado o framework K por se tratar de
uma estrutura semântica baseada em reescrita que permite produzir interpretadores e analisadores de linguagens além de fornecer um verificador de modelos nativo baseado em Maude.
A experiência como usuário do framework K foi bastante satisfatória no que diz respeito à expressividade desta ferramenta para especificação de linguagem e desempenho dos módulos de verificaçãoLTL. Um aspecto a ser melhorado é a interface disponível entre K
e Maude, pois a maior dificuldade encontrada no uso deste framework durante a construção do verificador de modelos resultante desta dissertação foi a utilização dos módulos de verificação de modelos herdados de Maude. Neste sentido, mesmo o K fornecendo uma interface mais amigável que o uso direto de Maude, a definição de uma determinada propriedade, por exemplo, não é de fácil compreensão. Este situação é acentuada por que a literatura não dispõe de uma documentação detalhada para uso e estudos sobre tais módulos.
Como resultados, pode-se perceber que a ferramenta resultante do atual trabalho apresentou um ótimo desempenho frente as outra ferramentas analisadas, com exceção de FDR como pode ser evidenciado nos dados preliminares encontrados no Capítulo 4
no que se refere à velocidade de processamento para análise de deadlock. Vale destacar que se tratam de dados preliminares. Por exemplo, a ferramenta ProB executou seus testes em uma máquina diferente dos que foram realizados neste trabalho, o que de certa forma deixa os dados aqui disponíveis necessitando de mais experimentos controlados em trabalhos futuros. Outro fato relevante é o referente ao esforço de desenvolvimento da ferramenta ProB para reescrever a especificação da semântica formal de Circus. Não se pode avaliar tal esforço, mas se pode facilmente pensar em algumas horas de trabalhos manuais potencialmente propensos a erros.