No capítulo 2 desta tese foram apresentadas as linguagens de modelação utilizadas em cada uma das metodologias que serão abordadas neste estudo. Os capítulos 4 e 5 apresentam respectivamente os modelos em PROMELA e AMN que foram construídos com base no modelo UML do serviço de urgência constante da tese de doutoramento do Mestre Carlos Santos [SC07]. O presente capítulo e o próximo visam apresentar a verificação destes modelos segundo os diferentes paradigmas. Neste capítulo será utilizado o modelo descrito no capítulo 4 com o objectivo de fazer a sua prova formal utilizando um model checker.
O model checker utilizado nesta fase do trabalho foi já apresentado no capítulo de apresentação das metodologias, como parte do artigo escrito para a cadeira de Introdução à Investigação. Assim, iremos agora explorar o tentar validar o modelo utilizando o SPIN.
Requisitos
A ferramenta utilizada para a verificação encontra-se disponível na Internet no endereço http://spinroot.com/ e é compatível com diversas plataformas como sistemas Unix, Windows PC e MacOS.
Para poder executar a aplicação é necessário instalar algum software adicional como seja um compilador de C. Para facilitar a interacção com a ferramenta, encontra-se disponível no site referido anteriormente uma interface gráfica cuja utilização requer a instalação de um interpretador de Tcl (Tool Command Language).
A plataforma utilizada neste estudo foi WindowsXP. A instalação resume-se a descarregar os ficheiros do site e colocá-los numa pasta. Para utilizar a interface gráfica basta descarregar o ficheiro executável Tcl disponibilizado no mesmo site. Quanto ao compilador de C, foi instalada uma versão do Cygwin. Esta aplicação encontra-se disponível em http://www.cygwin.com/ e é descrita como sendo “a Linux-like environment for Windows” e contém um compilador de C bem como outras ferramentas disponibilizadas por um sistema Linux.
Procedimento
Todo o processo de simulação e prova do modelo foi feito recorrendo à interface gráfica disponibilizada pela ferramenta. Esta apresenta uma janela conforme a da figura 3.
Figura 2 - Janela de interacção do Xspin
O modelo que se pretende verificar deve ser introduzido nesta janela. O modelo pode ser encontrado na sua totalidade no anexo A1. A ferramenta inclui uma funcionalidade que faz a correcção sintáctica do modelo. Este pormenor é bastante importante, ainda mais quando o utilizador é uma pessoa que não domina a linguagem de modelação utilizada. No entanto, o PROMELA é uma linguagem de fácil compreensão.
Ao construir um modelo, frequentemente o modelador sente necessidade de executá-lo para verificar se ele realmente funciona como pretendido. Na maioria das vezes os modelos são construídos apenas em papel e a execução do modelo é impossível. No entanto, uma vez que esta ferramenta se destina à verificação automático do modelo, dispõe também de um simulador. Este simulador oferece uma gama de opções que vão desde a informação que se pretende visualizar durante a simulação até à opção de executar uma simulação aleatória ou com base numa que seja mais interessante. Ao iniciar a simulação, é-nos dada a opção de realizá-la passo a passo ou toda de seguida, podendo ser interrompida quando necessário. As opções predefinidas mostram o estado das variáveis do modelo e a sua evolução, bem como um diagrama das mensagens enviadas entre os processos. Esta foi nomeadamente uma das formas que usei para testar se o modelo estava a executar exactamente como era pretendido.
Figura 3 - Simulação de um modelo no Xspin
Se a simulação não indicar nenhum erro no modelo (ou depois de corrigidos todos os indicados) passamos então à verificação propriamente dita. É nesta fase que, embora transparentemente para o utilizador, o SPIN cria os autómatos finitos que foram referidos na secção 2.1. Também o verificador apresenta uma série de opções que vão desde o que se pretende verificar até técnicas de compressão para facilitar o processo. É também nesta fase que são introduzidas (se for o caso) as propriedades em lógica temporal contra as quais será testada a correcção do modelo.
A verificação que levámos a cabo tinham como objectivo comprovar propriedades de correcção do modelo. Ou seja, pretendiam verificar se o modelo não chegava a estados inválidos bem como se as asserções presente no código não eram violadas. Mais, a verificação deveria indicar se existia alguma porção de código inatingível no modelo.
Pela forma como o model checker funciona, a memória do computador utilizado deve ser um factor fundamental a ter em conta. No caso particular deste estudo, o computador usado tinha uma memória RAM disponível de cerca de 480 MB. O modelo a verificar executa 5 processos doente, 2 processos admin, 1 processo auxiliar e 1 processo atende. Mantendo uma margem de segurança, foi permitido que a verificação utilizasse até 300 MB (este valor pode ser definido nas propriedades). Com esta configuração, apenas foi possível obter resultados na opção ‘Bitstate’. Após 16 minutos a verificação automática termina sem encontrar nenhum erro no modelo. Experimentou-se fazer a mesma verificação nos outros dois modos de procura disponíveis (Exhaustive e Hash-compact), sendo que nenhum destes
apresentou resultados conclusivos – a procura nunca foi concluída por falta de memória. No entanto, o checker apresentava como resultado o facto de não ter encontrado qualquer erro até ao ponto onde a memória existente permitiu que a verificação chegasse.
Resultados
O model checking foi executado num computador com tecnologia Intel, num Sistema operativo WindowsXP e com cerca de 300MB de memória RAM disponibilizados para a prova.
Da análise dos resultados da simulação do modelo surgiram algumas correcções ao modelo. Estas deveram-se a incorrecções do modelo relativamente ao comportamento que era esperado (e que se encontrava de acordo com o que acontece na realidade). O processo de simulação foi repetido até chegar a um modelo que não apresentasse deficiências aparentes. Após atingir esse modelo, passou-se à verificação formal.
Figura 4 - Resultado da verificação do modelo da urgência no Xspin
Devido às restrições de memória apresentadas pelo método em questão, foi necessário utilizar a opção da ferramenta que obriga ao menor consumo de memória (supertrace/bitstate). Neste modo, ao fim de aproximadamente 14 minutos a ferramenta termina a verificação do modelo e indica que não foram encontrados quaisquer erros. No entanto, antes de chegar a este resultado, várias foram as vezes em que o model checker encontrou erros no modelo. Nesta situação, era apresentado um guião de simulação com o contra-exemplo, possibilitando assim ao utilizador a compreensão e correcção do erro detectado. É de referir que a ferramenta necessitou apenas de 17MB para completar a prova.
Nos outros modos disponibilizados pela ferramenta para verificar o modelo (exhaustive e hash- compact) a memória da máquina utilizada era insuficiente para completar o processo. Ao atingir o limite de memória disponível, o checker indicava que até onde lhe foi possível chegar, não tinha sido detectado nenhum erro mas seria necessária mais memória para poder concluir a verificação.