Resultados e discussão

Após a etapa de implementação, o plug-in foi testado aplicando-o a obrigações de prova dos projetos listados abaixo. Um resumo das POs presentes nestes projetos pode ser observado na Tabela 6.

• Uma solução para o estudo de caso do ABZ 2014 (BONIOL; WIELS, 2014), que con-

siste na modelagem de um sistema de equipamento de pouso. O modelo utilizados foi aquele produzido para o estudo empírico do ProB Disprover (KRINGS; BENDIS- POSTO; LEUSCHEL, 2014);

• Modelo para um mecanismo de controle para um sistema de tanque aquático (BU- TLER, 2009);

• Uma solução para o modelo de controle de acesso a locais presente em Abrial (2010), disponibilizado em Jastram (2012).

Os testes foram realizados em uma máquina com Linux Mint 16, processador AMD Phenom II X4 3,2GHz e 8GB de RAM, com timeout do plug-in configurado para um se- gundo. Os solucionadores utilizados foram os seguintes: veriT 4.3.2, Z3 4.3.2, CVC3 2.4.1, CVC4 1.5 (BARRETT et al., 2011), Alt-Ergo 0.95.1, SMTInterpol 2.1 (CHRIST; HOENICKE; NUTZ, 2012) e Yices2 2.2.2 (DUTERTRE, 2014). A escolha levou em consideração a lista de

Tabela 6: Resumo das obrigações de prova Projeto Quantidade de

POs

Número de POs altera- das por injeção de erros Krings, Bendisposto e

Leuschel (2014) 241 36 Butler (2009) 163 49 Jastram (2012) 108 22

Total 512 107

dois provadores participantes da SMT-COMP 2014 1_{. Na Tabela 7, a seguir, encontra-}

se um comparativo geral das funcionalidades presentes nos solucionadores citados e que foram exploradas no plug-in.

Tabela 7: Resumo das características dos solucionadores utilizados Solucionador Unsat-cores Valores e atri-

buições

Razão unk- nown

Alt-Ergo Não Não Não

CVC3 Não Não Não

CVC4 Sim Sim Sim

SMTInterpol Sim Sim Sim

veriT Sim (não SMT- LIB)

Não Não

Yices2 Sim Sim Sim

Z3 Sim Sim Sim

Obviamente, foi preciso testar o plug-in com obrigações de prova inválidas. Para tanto, injetaram-se erros às especificações contidas nos projetos utilizados. Especificamente, fo- ram criados alguns erros de tipagem, por exemplo trocando-se o tipo de uma variável de natural para inteira. Nas figuras 21 e 22, é ilustrada a maneira como contra-exemplos são exibidos na árvore de prova.

Figura 21: Detalhe do nó pendente na árvore de prova

O nó pendente da árvore de prova, exibido na Figura 21, indica, após simplificações automáticas do sequente original, que o provador não foi capaz de provar automaticamente que a subtração das variáveis C e A é um número maior ou igual a 0. Isto se deve ao fato de que foi injetado à especificação um erro em que ambas as variáveis tiveram sua tipagem modificada de números naturais para inteiros.

Figura 22: Detalhe do nó com contra-exemplo após aplicação do solucionador SMT

Na Figura 22 é possível observar a saída do plug-in quando sua tática é aplicada ao nó pendente descrito acima, isto é, o usuário selecionou o nó 0 ≤ C −A e escolheu a tática SMT Solvers para aplicação. Um nó vazio pendente contém o contra-exemplo encontrado para o sequente não provado. Uma mensagem é exibida indicando este fato, seguido de dois conjuntos:

• O primeiro contém cada um dos pares variável/valor atribuídos às variáveis do contra-modelo; para o exemplo em questão, foram encontrados, pelo solucionador, as seguintes atribuições possíveis de valores: 0 para a variável A e −1 para a variável C; desta forma, foi possível provar que a proposição 0 ≤ C − A não é válida para todos os valores possíveis da teoria em que a PO foi considerada;

• O segundo contém os valores-verdade das hipóteses contidas no sequente; neste caso, para os valores exibidos no contra-modelo, a única hipótese do nó 0 ≤ C − A teve o valor booleano verdadeiro (true) atribuído pelo solucionador.

A partir deste feedback, um usuário poderia se voltar à especificação em busca de possíveis erros na parte a que o sequente não provado se refere (invariante, guarda, etc.), em especial à declaração e uso das variáveis A e C. Identificado o erro de tipagem, como o injetado ao modelo, uma correção seria aplicada de modo que a PO pudesse ser verificada. Resultados unknown referem-se a alguma limitação do solucionador utilizado (como explicado na Seção 4.3.3) e não necessariamente a algum erro de especificação. Nesse caso, apenas exploraram-se as obrigações de prova nos diferentes solucionadores, registrando

aquelas com resultado unknown. Na Figura 23, é possível observar de que forma mostra- se a saída na interface de Rodin.

É possível notar em que parte da PUI o erro é exibido, isto é, logo abaixo do Controle de Prova. Este espaço é reservado, por convenção, na Plataforma Rodin (não é um padrão do framework Eclipse) para exibir saídas de erro de aplicação de táticas. Exemplos de erro para tais saídas são táticas mal configuradas, versões de provadores não instaladas, timeout, etc. A saída para erro unknown do plug-in SMT mantém-se, então, uniforme em relação aos demais retornos da PUI para falhas relacionadas ao funcionamento do raciocionador utilizado.

No exemplo ilustrado na Figura 23, é possível notar que o nó pendente na árvore de prova representa uma fórmula mais extensa, com estruturas complexas de teoria dos conjuntos, tais como pertinência em relação a uma função construída com uso de sequên- cias, pares ordenados e expressões aritméticas. Solucionadores SMT apresentam, de forma geral, um suporte bastante limitado em relação à teoria dos conjuntos. Este fato é expli- citado pelo resultado incomplete (incompleto) retornado pelo solucionador utilizado na tática SMT Solvers sobre o sequente em questão.

De posse desta informação, o usuário poderia tomar a decisão de utilizar um solucio- nador SMT com um suporte melhor à teoria de conjuntos para tentar provar o sequente ou ainda utilizar uma outra tecnologia de verificação. Como enfatizado na Seção 4.2.3, os provadores de Atelier-B são os mais indicados para provar este tipo de obrigação de prova.