Faculdade dos GuararapesPaulo Sergio B. Salvador26/04/2012

Métodos Formais

Vale a pena utilizar métodos formais? E se não utilizarmos? O que poderia acontecer?

Eis alguns exemplos onde o destino dos eventos poderia ser diferente:

Em julho de 1996 o foguete Ariane 5 (projeto europeu), que carregava satélites científicos explodiu poucos segundos após seu lançamento. Aos 37 segundos de voo, o software do sistema de navegação (SRI), que foi reutilizado do Ariane 4, emitiu sinais incorretos aos motores, estes giraram sobre um eixo de tal maneira que os controladores de terra iniciaram a autodestruição e o foguete e a sua carga foram destruídos. Continha quatro satélites que custavam ao todos U$ 500 milhões. A falha do software ocorreu em uma tentativa de converter um número 64-bits de ponto flutuante para um inteiro 16-bits, fazendo com que ocorresse um erro numérico muito conhecido na computação, o (overflow), logo a anomalia ocorrida não foi devida a um erro aleatório e sim a um erro de projeto.

Sistema de triagem/controle de bagagem do aeroporto internacional de Denver (EUA). O sistema atrasou a inauguração do aeroporto. O custo do sistema foi de U$193 milhões. A inauguração estava prevista para out/1993. Em junho de 1994 o sistema ainda não estava funcionando. No começo de 1995 um controle MANUAL de bagagem foi instalado para que o aeroporto pudesse ser inaugurado (com atraso de mais de um ano).

O Therac-25, um equipamento de radioterapia controlado por computador, aplicou doses fatais de radiação em alguns pacientes de câncer.

Quando decidiram testar o subsistema de desligamento de emergência da Sizewell-B, uma usina nuclear na Inglaterra, obtiveram falha em mais de 50% das vezes. Não conseguiram encontrar a razão da falha nas 100.000 linhas de código.

Com estes exemplos, entre outros, devemos pensar o quão indispensável é o uso de métodos formais em sistemas de alta integridade. Se nestes projetos tivessem sido usados métodos formais, o custo seria ainda maior, porém, até que ponto a economia fala mais alto do que prejuízos e/ou vidas?

Com ela é possível analisar, com poucas linhas, implementações com milhares de linhas de código. Não especifica como os estados são constituídos, ou como a execução leva de um estado para outros, mas como o novo estado se relaciona com o anterior.

Métodos formais leves

Alguns especialistas acreditam que a comunidade de métodos formais tem super enfatizado toda formalização da especificação ou desenvolvimento. Eles afirmam que a expressividade da linguagem envolvida, assim como a complexidade dos sistemas sendo modelados, torna toda formalização uma tarefa difícil e cara. Como alternativa foi-se proposto vários métodos formais leves, os quais enfatizam especificações parciais e aplicações focadas. Exemplos desta aproximação leve aos métodos formais incluem a Alloy object modelling notation.

Linguagem Alloy

O Alloy é uma linguagem de especificação formal, orientada a objetos, direcionada para a criação de micro-modelos, que nos possibilita a análise e verificação formal, através da ferramenta associada Alloy Analyzer.

Relativamente à sua sintaxe, esta foi criada com a contribuição de outras linguagens, entre elas o OCL. No entanto, denota-se uma influência acentuada da notação Z, direcionado para a criação de micro-modelos.

Ela permite escolher as abstrações que mais se adequam ao desenho do produto de software, bem como descartar incoerências e inconsistências que possam surgir aquando do processo de implementação. Permite a declaração de objetos, factos, procedimentos e funções que compõem o sistema a modelar.

UML2ALLOY

O Alloy é uma linguagem de modelação baseada na lógica de primeira ordem, inspirada no método Z, com suporte à análise automática. O objetivo da utilização de modelos não é a descrição total de um sistema, mas sim, modelar aspectos, definir restrições e verificar propriedades.

O UML2Alloy é uma ferramenta que permite a tradução de diagramas de classes UML/OCL em modelos Alloy. O UML2Alloy tem três ferramentas que servem de suporte à tradução de diagramas de classes em especificações Alloy. A primeira ferramenta permite editar modelos UML/OCL e exportar esses modelos para um arquivo do tipo XMI. Este arquivo é submetido à segunda ferramenta que o transforma num arquivo de texto, servindo de dados de entrada à terceira ferramenta: o analisador automático Alloy Analyzer. Este permite a simulação e verificação de modelos. Ao nível da simulação, esta é realizada através de uma declaração de lógica de primeira ordem, correspondendo ao comando run. Através deste comando o analisador gera uma instância em conformidade com o modelo proposto.

Ao nível sintático, o Alloy é compatível com UML. A expressividade e complexidade do UML tornam-no ambíguo, porque proporciona várias interpretações sobre o mesmo modelo, por sua vez, o Alloy é preciso, abstrato e conciso.

Referencias:http://wiki.sapo.pt/wiki/M%C3%A9todos_Formais

http://pt.wikipedia.org/wiki/M%C3%A9todos_formais

www.cin.ufpe.br/~lmf/seminars/ Alloy _Micro_ME_2.ppt

http://run.unl.pt/bitstream/10362/3981/1/Ferreira_2010.pdf