Neste capítulo vai ser demonstrada a verificação do modelo do nosso caso de estudo segundo a metodologia de theorem proving. O modelo que serve de base a esta verificação encontra-se descrito no capítulo 5 e está na sua totalidade no anexo A2.
Requisitos
Tal como referido no capítulo anterior, a simulação é uma fase importante na construção de um modelo. Uma vez que, para fazer a verificação segundo o theorem proving é necessário construir outro modelo, torna-se necessário dispor de um simulador para a linguagem utilizada. Desta forma, foi utilizada para esse fim uma ferramenta académica, o ProB, que se encontra disponível para download em http://users.ecs.soton.ac.uk/mal/systems/ProB_Download/.
Para poder executar esta ferramenta torna-se necessário instalar algum software adicional, nomeadamente um interpretador de Tcl (Tool Command Language).
A ferramenta ProB dispões de um model checker mas não dispõe de um theorem prover. Este facto obrigou à utilização de uma outra ferramenta para verificar o modelo. Essa ferramenta dá pelo nome de B4free e encontra-se disponível para download em http://www.b4free.com/. A instalação deste programa em WindowsXP obrigava à instalação de uma imagem de um sistema Linux, no qual o B4free seria executado. Por considerar que seria mais fácil instalar uma distribuição de Linux do que configurar uma imagem de Linux em Windows, instalou-se o Linux da distribuição Ubuntu.
A instalação da ferramenta em Linux é bem menos assustadora. Após concluídos todos os passos da instalação, é necessário instalar uma interface gráfica: Click’n’Prove. No site do B4free encontra-se um link através do qual se acede aos ficheiros de instalação da interface. Tal como no caso do B4free, basta seguir os passos indicados nas instruções de instalação para que tudo funcione correctamente. Para que a interface funcione é apenas necessário dispor do programa Xemacs instalado.
Procedimento
Tal como o Xspin, o ProB recebe o modelo a verificar (desta feita na linguagem AMN). Durante a simulação, estão disponíveis para o utilizador os valores de todas as variáveis da máquina, todas as operações executáveis a cada instante e um historial das operações que foram executadas ao longo da simulação. Sempre que a execução de uma operação violar o invariante, esse acontecimento é indicado.
Figura 5 - Janela de interacção do ProB com o modelo da urgência
A ferramenta ProB dispõe também de um model checker para verificar o modelo AMN. No entanto, este processo obriga à criação de restrições nas variáveis do modelo para evitar o fenómeno de state space explosion. O theorem proving não enfrenta este problema, visto que a metodologia utilizada permite verificar sistemas com estados infinitos. Desta forma, a opção de model checking da ferramenta foi ignorada.
Tal como no caso do modelo em PROMELA, muitas foram as simulações do modelo AMN até atingir uma máquina que efectivamente apresentasse o comportamento desejado.
O passo seguinte no nosso procedimento consiste em executar a prova do modelo com a ferramenta B4free e com a interface Click’n Prove. Ao executar a interface, são-nos apresentadas duas janelas, uma com os comandos e outra que apresenta os resultados e os erros. Para poder proceder a qualquer verificação é necessário criar um projecto que deverá ter o mesmo nome que a máquina a verificar (fará mais lógica que seja a máquina a ter o mesmo nome que o projecto). Após criado o projecto, o ficheiro que contém a máquina AMN deve ser colocado na pasta source do projecto. Depois deste passo é necessário, na aplicação, adicionar uma máquina ao projecto e seleccionar o ficheiro que colocámos na pasta.
Figura 6 - Interface gráfica Click'n Prove
O passo seguinte consiste em verificar (automaticamente) os tipos do modelo. Desta forma a ferramenta verifica se há algum erro a este nível no modelo. Em seguida segue-se a criação das proof obligations. As proof obligations são os teoremas que têm de ser verificadas para considerar o modelo correcto. No caso concreto do modelo da urgência, são criadas 66 proof obligations das quais 60 são consideradas óbvias.
Para que se perceba o conceito de proof obligation, apresenta-se um exemplo:
MACHINE Exemplo Proof Obligations:
INVARIANT I [A] I INITIALIZATION A I ^ P => [S] I OPERATION Op = PRE P THEN S END END
As proof obligations significam que em primeiro lugar, a inicialização da máquina tem de respeitar o invariante ([A] I). Em segundo lugar, na execução da operação op num estado em que o invariante se verifica (I ^ P), a execução de S deve manter i invariante ([S] I). É segundo este esquema que são geradas as proof obligations para uma máquina AMN.
Figura 7 – Relatório apresentado após a geração dos teoremas
A ferramenta dispõe de dois motores de prova com “forças” diferentes. O primeiro é o p0 e funciona com um conjunto reduzido de hipóteses enquanto que o segundo, p1, tem em conta um conjunto mais alargado de hipóteses [AJR03].
O primeiro passo no processo de prova dos teoremas consiste em correr o motor de prova mais fraco, p0. Como resultado, dos 60 teoremas restam apenas 10 que não foram provados pelo motor. Em seguida, deve executar-se o motor mais forte. No caso concreto deste modelo, p1 não consegui provar nenhum dos 10 teoremas que p0 também não provou. Desta forma, a única maneira de provar a correcção do modelo é através de uma prova interactiva. Algumas destas provas podem ser triviais, mas outras podem ser bastante complexas.
Os 10 teoremas resultantes podem ser agrupados visto que a forma de resolução é idêntica. Basicamente resume-se ao mesmo problema mas em secções distintas do modelo. Assim, será apresentado apenas o primeiro caso de cada um destes grupos e a respectiva solução.
O primeiro teorema é o seguinte e é relativo à operação Chegar:
(T1)
O teorema diz que se adicionarmos à variável
estado
o valor{dd
→aTransportar}
, a variávelestado
pertence à relaçãodoente→/
ESTADO
. O valor actual dedoente
édoente∪{ }dd
. Embora o teorema pareça óbvio mediante uma análise do modelo AMN, o motor de prova não conseguiu prová- lo. A resolução deste problema consiste em detectar no modelo uma condição ou propriedade que confirme o teorema. Consultando o modelo (anexo A.2), consta do invariante uma expressão que comprova exactamente que a variávelestado
é do tipo indicado no teorema. Assim, deve fazer-se uma procura no modelo a expressões relacionadas com . Ao encontrar a expressão pretendida,adiciona-se essa expressão à prova e executa-se p0. O resultado deste processo é a prova do teorema assinalada pela palavra SUCCESS.
Figura 8 - Prova do teorema T1
Existe mais um teorema semelhante a este para provar. Outros dois teoremas há cujo método de resolução é igual. A única diferença é o facto de não ser referir à variável
estado
mas sim à variáveltipo
. Apresenta-se em seguida o teorema cuja interpretação e solução podem ser derivadas de T1. (T2)
O segundo tipo de teoremas está relacionado com a manipulação do tempo e é o seguinte: (T3)
A prova deste modelo não exige qualquer exercício de dedução, sendo apenas necessário executar o motor de prove a p0. O resultado apresentado é o seguinte:
Figura 9 - Prova do teorema T3
O terceiro tipo de prova, que consiste num único teorema, relaciona-se directamente com o invariante. Apresenta-se o teorema em T4.
(T4)
Tal como no caso anterior, a prova deste teorema faz-se apenas recorrendo ao motor de prova p0.
Após estas dez provas interactivas, o modelo está provado e a ferramenta apresenta uma mensagem que é significativa do alívio do utilizador ao provar o modelo na totalidade: BINGO!