Depois de aplicar as duas metodologias apresentadas no capítulo 2 ao modelo do serviço de urgência (capítulo 3), o próximo passo consiste em estabelecer uma comparação entre ambas. Diversos factores podem ser comparados no processo de verificação formal de um sistema, desde a construção do modelo à verificação final, passando pela simulação do modelo e correcção dos erros encontrados.
Modelação
Neste estudo em particular, foram utilizadas duas ferramentas que seguem diferentes paradigmas. Como tal, os modelos construídos para cada uma delas foram especificados em duas linguagens de modelação diferentes, sendo que uma aborda aspectos particulares que a outra descura e vice-versa. Não conhecia nenhuma das linguagens, no entanto não tive dificuldade em adaptar-me a elas visto que em ambos os casos, já tinha lidado com alguma tecnologia semelhante. Relativamente ao PROMELA, trata-se de uma linguagem bastante semelhante ao C. Embora o C não use o conceito de processo mas sim de função, estes dois conceitos são bastante semelhantes. A existência dos canais de comunicação foi uma novidade à qual facilmente me adaptei. Por outro lado, a notação AMN tem algumas semelhanças com a programação orientada a objectos. Uma máquina AMN assemelha-se a um objecto que tem estado e tem operações que podem alterar o estado e pode também herdar de outras máquinas. Por outro lado, não há nenhum mecanismo que permita a criação dinâmica de máquinas e o número de instâncias existentes é definido à partida.
Se o conceito AMN é facilmente compreensível, já a forma usada para codificar o modelo pode não ser muito intuitiva. Todo o modelo é escrito numa mistura entre código tipo C (if then else, e outras instruções semelhantes) e teoria de conjuntos. A princípio, é um pouco confuso idealizar um sistema especificado em teoria de conjuntos. Num modelo como o utilizado neste estudo, o processo não é demasiado complexo. No entanto, há que ter em conta que em sistemas cuja complexidade seja superior (em outro tipo de sistemas, poderá ser mesmo bastante superior) pode ser necessário recorrer a ajuda especializada. Isto porque, embora a teoria dos conjuntos seja suficientemente forte para representar um sistema complexo, a forma de fazê-lo pode tornar-se quase tão complexa como o próprio sistema. Assim, será necessária alguma formação inicial neste campo para que um engenheiro possa modelar um sistema com alguma complexidade em AMN.
Ainda relativamente à modelação, no model checking é necessário não só simplificar o modelo mas mesmo limitar o âmbito das variáveis para que a verificação possa ser realizada. Por exemplo, não permitir que um inteiro assuma valores acima de um limite, normalmente baixo. O mesmo não acontece no theorem proving que consegue provar máquinas com estados infinitos.
Especificação de propriedades a verificar
Se a modelação do sistema é relativamente fácil, já a especificação das propriedades a verificar pode não ser tão simples, uma vez que depende da complexidade do modelo e do que se pretende verificar. No caso do model checking (tal como foi indicado no capítulo correspondente) as propriedades a verificar são escritas numa lógica temporal (Linear Temporal Logic). O modelo utilizado neste estudo é bastante simples. Assim, não foi necessário recorrer à LTL para verificar a sua correcção. Bastou a inserção de uma instrução assert no próprio modelo. No entanto, ao contrário deste exemplo meramente académico, a verificação formal é utilizada em sistemas reais e muito mais complexos, nomeadamente os sistemas considerados críticos. Neste tipo de sistemas, as propriedades a verificar têm tendência a ser bastante complexas. Se descrever algumas propriedades em LTL (como as exemplificadas no capítulo em que esta lógica é apresentada) pode ser simples, a crescente complexidade do sistema em análise implica um igualmente crescente complexidade das propriedades a verificar.
Simulação
O passo a seguir à especificação do modelo é a sua simulação. Embora o objectivo seja verificar formalmente a correcção do modelo, uma simulação ajuda a compreender o seu funcionamento e a detectar alguns erros. Assim, o SPIN dispõe de um simulador de modelos e no caso do AMN recorremos a uma ferramenta concebida para o efeito.
O SPIN é uma ferramenta destinada a fazer model checking de modelos de sistemas concorrentes. Desta forma, a simulação do modelo executa instruções por uma ordem aleatória. Ou seja, se num determinado momento se encontram em execução 3 processos (por exemplo), qualquer instrução desses 3 processos pode ser executada. Este facto dificulta o acompanhamento da simulação por parte do utilizador, pelo menos num período inicial. No entanto é este mecanismo que permite simular a concorrência no modelo. Por outro lado, a informação apresentada durante a simulação facilita e ajuda a compreensão da linha de execução seguida na simulação. Essa informação consiste nos valores das variáveis do modelo bem como um gráfico das mensagens trocadas entre os processos. Em resumo, a simulação é fácil de fazer e de compreender.
A ferramenta utilizada para simular o modelo AMN, o ProB, apresenta também os valores das variáveis do modelo. Desta feita, não são executadas instruções mas sim operações (que podem ser compostas por várias instruções). Assim, a ferramenta apresenta, a cada momento, uma lista com as operações que podem ser executadas (conforme as pré-condições definidas em cada uma), tal como um historial de todas as operações já realizadas.
Ambas as ferramentas de simulação são fáceis de usar e de compreender. A única vantagem que vejo no ProB relativamente ao SPIN é o facto de poder escolher que operação executar.
Verificação dos modelos
Finalmente, a última fase do processo é precisamente a prova dos modelos. No que toca ao model checking, a verificação é extremamente simples. Basta correr o motor de verificação e esperar que o modelo seja provado com sucesso ou que seja detectado algum erro. Se for esse o caso, é apresentado um guião de simulação para exemplificar o erro. O único problema deste método é a memória necessária. Como foi indicado no capítulo 6, verificar o modelo usando uma procura exaustiva não foi possível com um computador com 300 MB de RAM disponíveis para a prova. Tendo em conta que este modelo é bastante simples e reflecte também um sistema simples, este facto pode ser um problema para a utilização deste método em situações de projectos reais. Embora o modelador abstraia do modelo tudo o que não for relevante, ainda assim o modelo pode ser demasiado complexo para que seja possível realizar uma busca exaustiva. No entanto, as alternativas apresentadas pela ferramenta obtêm um resultado igualmente satisfatório sem realizar a busca completa. Foi assim que se realizou a prova neste estudo. [HG98] refere que a técnica de bitstate hashing apresenta uma alta cobertura em verificações usando memória que pode ser algumas ordens de magnitude inferior à requerida para realizar uma verificação exaustiva.
O método de theorem proving é mais complexo do que o model checking. A ferramenta analisa o modelo, define os teoremas que têm de ser provados para verificar o modelo e prova alguns automaticamente. Em primeiro lugar, o elevado número de teoremas gerado neste caso simples da urgência faz pensar que num sistema complexo, serão gerados muitos mais teoremas. No entanto, o problema consiste nos teoremas que o motor de prova não consegue provar. Estes podem até parecer triviais para o utilizador, mas se a ferramenta não consegue prová-los, é necessário intervir manualmente. Para levar a cabo a prova interactiva de teoremas é necessário ter não só uma grande experiência de teoria de conjuntos mas também um enorme experiência na ferramenta utilizada (neste caso o Click’n Prove [AJR03]). Na minha opinião, aprender a manejar a ferramenta não é uma tarefa muito árdua. Já fazer as provas necessárias é bastante mais complicado. Em todas as provas feitas neste estudo num estado inicial do modelo necessitei de ajuda experiente. Relativamente ao estado final, provar os teoremas não provados pela ferramenta foi relativamente fácil, tendo em conta a simplicidade dos teoremas e a experiência que eu já detinha.
Tempo dispendido
Um factor que pode ser importante na escolha de uma metodologia de verificação formal é o tempo dispendido com cada uma. Tal como referido em [BD] (trata-se igualmente de uma comparação entre theorem proving e model checking) o processo de theorem proving é mais moroso do que o model checking. No entanto, pode ser útil analisar onde cada uma das metodologias “perde” mais tempo.
Enquanto que no model checking, a maior parte do tempo é passada a simplificar o modelo para facilitar (ou mesmo possibilitar) a verificação, o maior percentagem de tempo empregue no theorem proving é relativa à prova dos teoremas.
Experiência necessária
Como referi nos parágrafos anteriores, qualquer dos dois métodos requer a intervenção de pessoas experientes no campo, embora em partes diferentes do processo. No entanto, é necessário que esta pessoa experiente tenha algum conhecimento do modelo para poder pôr em prática os seus conhecimentos. A experiência no campo da matemática de nada serve para especificar propriedades em LTL se a pessoa não conhecer o modelo, da mesma forma que se a pessoa não conhecer o modelo AMN, dificilmente conseguirá provar os teoremas do theorem proving.
Comparação com estudos anteriores
A experiência que levei a cabo ao longo deste trabalho foi de encontro às conclusões atingidas em [BD]. Embora o modelo final em AMN tenha sindo facilmente provado pelo método de theorem proving, isto foi resultado de uma simplificação considerável do modelo que antes era mais complexo e mais difícil de provar. O domínio quer da ferramenta quer da linguagem de modelação e de teorias matemáticas é fundamental para o theorem proving.
Considerações finais
De todos estes aspectos, os que me parecem ser mais importantes na escolha de uma metodologia para verificar um modelo são a simplicidade do processo de verificação, o tipo de sistema a verificar e a sua dimensão. No que toca à simplicidade, parece-me óbvio que será preferível trabalhar com a ferramenta/metodologia que for menos complexa. Neste caso, o model checking. No entanto, é necessário ter em conta o tipo de sistema em causa. Se considerarmos um semelhante ao usado neste estudo em que, embora a manipulação de informação seja importante mas foi propositadamente descurada, o model checking, para além de simples, adequa-se e oferece resultados satisfatórios. Se, pelo contrário, a informação for mais importante, o model checking pode não ser suficientemente poderoso para verificar o modelo. Assim, neste tipo de situações, se possível, dever-se-á sacrificar a simplicidade de uma ferramenta pela competência da outra no campo em estudo.
Frente à necessidade de verificar formalmente um modelo e de escolher uma metodologia para esse efeito, eu faria uma opção conforme descrevi no último parágrafo, tendo em conta os vários aspectos que considero importantes na escolha e recorrendo até aos que considero menos importantes.
Deste estudo concluo que a metodologia de model checking é mais fácil e mais acessível do que o theorem proving.
Devo referir que julgo ser importante a realização de estudos neste ramo dos métodos formais, visto que estes ocupam (ou deviam ocupar) um papel importante no desenvolvimento de software. Este tipo de metodologias permite descobrir e corrigir no início do processo de desenvolvimento erros que de outra maneira seriam descobertos muito mais tarde (na fase de experimentação do cliente, por exemplo), diminuindo assim o possível custo do projecto. Embora a verificação formal não possa garantir que o software é perfeito, é uma potente ferramenta para melhorá-lo.