• Nenhum resultado encontrado

Verifica¸c˜ ao Formal de Programas

A verifica¸c˜ao formal de programas tem como objetivo fornecer uma prova formal de que um programa satisfaz uma especifica¸c˜ao desejada [46]. A deriva¸c˜ao da prova requer que o programa seja modelado atrav´es de uma estrutura matem´atica, a qual forma a base para a aplica¸c˜ao de um processo de racioc´ınio que permita derivar propriedades sobre a mesma.

Em geral, as t´ecnicas de verifica¸c˜ao formais s˜ao compostas por trˆes partes distin- tas [47]: i) uma linguagem de descri¸c˜ao que permita modelar o programa, ii) uma lingua- gem de especifica¸c˜ao que permita expressar as propriedades desejadas, e iii) um m´etodo de verifica¸c˜ao para determinar se o programa satisfaz a propriedade.

A principal diferen¸ca entre as abordagens de verifica¸c˜ao formal diz respeito `a escolha do formalismo matem´atico empregado no processo de racioc´ınio. Estas abordagens podem ser classificadas como [48]: i) baseadas em modelos e ii) baseadas em provas.

Nas abordagens baseadas em modelos [49], o programa ´e descrito por um modelo M, geralmente representado por um sistema de transi¸c˜ao [50]. O processo de racioc´ınio em- pregado pelas abordagens desta categoria se caracteriza por determinar se a consequˆencia l´ogica M |= ϕ se verifica, onde M ´e o modelo do programa e ϕ ´e uma f´ormula (geral- mente expressa em l´ogica temporal [51, 52]) representando a propriedade a ser verificada. O m´etodo de verifica¸c˜ao consiste, primeiramente, na representa¸c˜ao do programa atrav´es de um modelo M expresso na linguagem de descri¸c˜ao empregada pelo model checker con- siderado. Ent˜ao, a propriedade ϕ a ser verificada ´e formulada usando a linguagem de especifica¸c˜ao empregada pelo referido model checker. O model checker ´e executado a fim de verificar se a rela¸c˜ao de satisfa¸c˜ao M |= ϕ se verifica. O resultado produzido pelo mo-

del checker ´e uma resposta positiva se M |= ϕ, ou uma resposta negativa caso contr´ario.

Caso a resposta seja negativa, a maioria dos model checkers tamb´em geram um trace do programa cujo comportamento gerou a falha. A verifica¸c˜ao de programas empregando a t´ecnica baseada em modelos ´e adequada para a verifica¸c˜ao de programas cuja ˆenfase principal ´e o fluxo de controle do programa, i.e., a maior parte do c´odigo do programa ´e constitu´ıda de estruturas de controle (por ex., comandos condicionais) operando em tipos de dados simples [46].

As t´ecnicas baseadas em provas se caracterizam por transformar o problema da veri- fica¸c˜ao em um problema de prova de teorema. Nesta abordagem, a descri¸c˜ao do programa ´e dada por um conjunto de f´ormulas Γ expressas em um formalismo l´ogico, enquanto que a especifica¸c˜ao ´e dada por outra f´ormula ϕ expressa tamb´em neste formalismo. A prova do teorema (i.e., a verifica¸c˜ao) ´e realizada com base no c´alculo de prova subjacente ao formalismo l´ogico empregado. Formalmente, o m´etodo de verifica¸c˜ao consiste na tenta- tiva de encontrar uma prova que Γ ⊢ ϕ. Um aspecto importante desta abordagem ´e a necessidade da orienta¸c˜ao e do conhecimento especializado do usu´ario para desenvolver a prova de problemas de maior complexidade.

Uma das ´areas em que a t´ecnica baseada em prova tem encontrado grande aplicabi- lidade ´e na l´ogica de programas. A l´ogica de programas tem suas origens nos trabalhos desenvolvidos em [53, 54]. O objetivo principal desta abordagem ´e simplificar a verifica¸c˜ao por meio da abstra¸c˜ao dos detalhes da execu¸c˜ao do programa do processo de verifica¸c˜ao em si. As id´eias propostas naqueles trabalhos formam a base para a defini¸c˜ao do estilo de especifica¸c˜ao conhecido como semˆantica axiom´atica.

As provas desenvolvidas em l´ogica de programas combinam dois n´ıveis l´ogicos dis- tintos. O primeiro n´ıvel est´a diretamente relacionado com os construtores da linguagem de programa¸c˜ao (atribui¸c˜ao, composi¸c˜ao sequencial, condicional, etc), a partir dos quais s˜ao definidas as regras de dedu¸c˜ao. O segundo n´ıvel diz respeito `a l´ogica subjacente `a linguagem de especifica¸c˜ao empregada para descrever as propriedades sobre o programa. Na pr´oxima se¸c˜ao ´e apresentado o principal formalismo empregado para raciocinar sobre a corre¸c˜ao de programas imperativos.

2.1.2.1 L´ogica de Hoare

A L´ogica de Hoare [54] ´e um formalismo para raciocinar sobre a corre¸c˜ao de programas imperativos, tendo como base a l´ogica de primeira ordem. A l´ogica de Hoare trata com a no¸c˜ao de corre¸c˜ao, relativa a uma especifica¸c˜ao que consiste de pr´e- e p´os-condi¸c˜ao. A corre¸c˜ao de um programa em rela¸c˜ao a uma especifica¸c˜ao ´e obtida atrav´es da constru¸c˜ao de uma deriva¸c˜ao no sistema de inferˆencia da L´ogica de Hoare, a qual usa pr´e-condi¸c˜oes, p´os-condi¸c˜oes e invariantes.

A corre¸c˜ao de um programa ´e definida em rela¸c˜ao a uma dada especificac˜ao para aquele programa. Os elementos principais para a defini¸c˜ao de especifica¸c˜oes s˜ao as pr´e-

dadeiras quando a execu¸c˜ao do programa ´e iniciada. Por outro lado, as p´os-condi¸c˜oes s˜ao asser¸c˜oes que devem ser verdadeiras quando a execu¸c˜ao do programa terminar. Deste modo, uma especifica¸c˜ao pode ser definida como um par de asser¸c˜oes (P,Q), onde P ´e a pr´e-condi¸c˜ao e Q ´e a p´os-condi¸c˜ao. Uma especifica¸c˜ao de corre¸c˜ao relativa a um programa C ´e convencionalmente expressa no formato de uma tripla {P }C{Q}.

Uma tripla {P }C{Q} ´e chamada de especificac˜ao de corre¸c˜ao parcial. Esta especi- fica¸c˜ao ´e considerada parcial porque n˜ao diz nada a respeito do t´ermino do programa C, ou seja, para que {P }C{Q} seja verdadeiro n˜ao ´e requerido o t´ermino da execu¸c˜ao do programa C quando iniciado em um estado satisfazendo P. ´E somente requerido que, caso o programa C termine, a p´os-condi¸c˜ao Q se verifica no estado final.

Uma especifica¸c˜ao de corre¸c˜ao mais rigorosa ´e a corre¸c˜ao total. A nota¸c˜ao usada para expressar uma especifica¸c˜ao de corre¸c˜ao total ´e [P] C [Q]. Uma especificac˜ao de corre¸c˜ao total [P] C [Q] ´e verdadeira se e somente se as duas condi¸c˜oes a seguir se aplicam:

• se o programa C ´e executado em um estado satisfazendo a pr´e-condi¸c˜ao P, ent˜ao o programa C termina.

• Ap´os o t´ermino da execu¸c˜ao do programa C, a p´os-condi¸c˜ao Q se verifica no estado final.

O relacionamento entre corre¸c˜ao parcial e total pode ser informalmente expresso como: Corre¸c˜ao T otal = Corre¸c˜ao P arcial + T ermina¸c˜ao

onde a validade de uma especifica¸c˜ao de corre¸c˜ao total pode ser estabelecida atrav´es das provas da corre¸c˜ao parcial e do t´ermino da execu¸c˜ao, separadamente.

No contexto da certifica¸c˜ao de composi¸c˜oes de servi¸cos web semˆanticos, consideramos somente especifica¸c˜oes de corre¸c˜ao parcial.

As pr´oximas se¸c˜oes descrevem os principais trabalhos relacionados `a verifica¸c˜ao for- mal de programas, mais especificamente, enfatizando a verifica¸c˜ao de propriedades de composi¸c˜oes de servi¸cos web.

2.2

Verifica¸c˜ao de Composi¸c˜oes de Servi¸cos Web

A verifica¸c˜ao da corre¸c˜ao de composi¸c˜ao de servi¸cos web tem sido abordada a partir da aplicac˜ao de diferentes formalismos. A maioria ´e baseada em sistemas de transi¸c˜ao de

estado, tais como redes de Petri [55]. Outra abordagem formal empregada ´e a prova de teoremas. Ambas as abordagens visam verificar propriedades de uma especifica¸c˜ao.

Esta se¸c˜ao apresenta uma revis˜ao dos principais trabalhos descritos na literatura abor- dando a verifica¸c˜ao formal de composi¸c˜oes de servi¸cos web. Os trabalhos revisados se enquadram na classifica¸c˜ao descrita na se¸c˜ao 2.1.2, i.e., baseados em prova de teoremas e baseados em model checking.

2.2.1

Abordagens baseadas em Prova de Teorema

Abordagens baseadas em prova de teoremas tem sido empregadas para a verifica¸c˜ao formal de propriedades de composi¸c˜oes de servi¸cos web. Os trabalhos revisados empregam os mais diversos formalismos l´ogicos para expressar o modelo do sistema assim como as propriedades a serem verificadas s˜ao diversas.

Os autores em [56] prop˜oem um sistema axiom´atico baseado na L´ogica de Hoare para a verifica¸c˜ao de processos BPEL. O foco da verifica¸c˜ao se centra nos mecanismos de compensa¸c˜ao e falhas providos por BPEL. O m´etodo de verifica¸c˜ao proposto apresenta limita¸c˜oes, como considerar que os fluxos paralelos do processo n˜ao compartilham vari´aveis (ou seja, s˜ao independentes). Al´em disso, a aplica¸c˜ao do m´etodo de verificac˜ao n˜ao pode ser totalmente automatizada, pois algumas regras de inferˆencia do sistema axiom´atico proposto n˜ao tem a propriedade de sub-f´ormula3.

Em [57], os autores prop˜oem uma abordagem de verifica¸c˜ao de workflow baseada na semˆantica de Hoare (dada por pr´e- e p´os-condi¸c˜oes). As tarefas orquestradas no workflow s˜ao expressas tamb´em por uma especifica¸c˜ao dada por uma pr´e-condi¸c˜ao e um conjunto de a¸c˜oes (onde cada a¸c˜ao representa um efeito poss´ıvel da tarefa), denominada frame

semantics. A a¸c˜ao a ser aplicada, em resposta `a execu¸c˜ao da tarefa, ´e escolhida de

forma n˜ao-determin´ıstica. O modelo do workflow ´e representado atrav´es de um grafo dirigido, onde os v´ertices representam as tarefas orquestradas e as arestas descrevem o fluxo de execu¸c˜ao das tarefas. A verifica¸c˜ao da corre¸c˜ao do workflow (i.e., se o workflow cumpre uma dada especifica¸c˜ao) ´e realizada atrav´es da anota¸c˜ao das arestas do grafo com f´ormulas representando as condi¸c˜oes que s˜ao requeridas serem verdadeiras naquele ponto do workflow. O workflow ´e validado se a anota¸c˜ao de todas as arestas ´e poss´ıvel e se a f´ormula associada a cada aresta representando as sa´ıdas do workflow (calculada com

3

Uma regra de inferˆencia tem a propriedade de sub-f´ormulase todas as f´ormulas contidas nas premissas aparecem tamb´em na conclus˜ao da regra. Esta propriedade ´e fundamental para a automa¸c˜ao do sistema axiom´atico, uma vez que todas as f´ormulas a serem manipuladas s˜ao previamente conhecidas quando uma regra ´e aplicada.

base na semˆantica assercional proposta para o modelo) implicam a p´os-condi¸c˜ao dada na especifica¸c˜ao. As pr´e- e p´os-condi¸c˜oes s˜ao dadas por f´ormulas da l´ogica de primeira ordem.

Em [58], os autores apresentam um modelo baseado na l´ogica de Hoare para espe- cificar formalmente a semˆantica de workflows e suas tarefas compostas descritas como processos abstratos BPEL. ´E proposto um conjunto de regras de inferˆencia para deduzir a p´os-condi¸c˜ao mais forte e a pr´e-condi¸c˜ao mais fraca de um workflow, assim como um algoritmo para a verifica¸c˜ao autom´atica de workflow considerando algumas restri¸c˜oes na manipula¸c˜ao dos dados (atribui¸c˜ao opaca) em um processo abstrato. No modelo proposto, as asser¸c˜oes s˜ao expressas atrav´es de f´ormulas da l´ogica proposicional.

Os trabalhos descritos em [59, 60] empregam um formalismo l´ogico similar para a gera¸c˜ao de composi¸c˜oes de servi¸cos web. Ambos expressam o problema da composi¸c˜ao de servi¸cos web semˆanticos como um problema de prova de teoremas em uma variante da l´ogica linear [61]. Em [59], os servi¸cos web semˆanticos s˜ao descritos em DAML-S [62] e convertidos para axiomas da l´ogica linear intuicionista, enquanto que em [60], os servi¸cos s˜ao convertidos para axiomas da l´ogica linear cl´assica. A composi¸c˜ao dos servi¸cos ´e ex- pressa, em ambos os casos, atrav´es de ´algebra de processos, especificamente, o pi-calculus. O problema da gerac˜ao de composi¸c˜oes de servi¸cos web semˆanticos ´e tratado como um problema de prova de teoremas, onde a partir dos servi¸cos dispon´ıveis (i.e., dos axiomas em l´ogica linear), busca-se uma deriva¸c˜ao que permite concluir que a requisi¸c˜ao (dada tamb´em por uma f´ormula em l´ogica linear) pode ser derivada a partir dos servi¸cos dis- pon´ıveis. Em ambos os trabalhos, o provador de teorema da l´ogica linear empregado ´e adaptado para interagir com um raciocinador semˆantico a fim de inferir as rela¸c˜oes de sub- sun¸c˜ao entre os conceitos usados para anotar os parˆametros dos servi¸cos web semˆanticos visando decidir a compatibilidade entre eles. A composi¸c˜ao de servi¸cos web ´e extra´ıda a partir da prova completa (se existir) gerada pelo provador de teorema e ent˜ao expressa como um processo pi-calculus. Se forem geradas, ´e garantido que as composi¸c˜oes satisfa- zem as respectivas requisi¸c˜oes, uma vez que o provador de teorema ´e consistente (sound ). Entretanto, o n´ıvel de complexidade das composi¸c˜oes geradas (i.e., os padr˜oes de workflow aparecendo na composi¸c˜ao) ´e restrito aos padr˜oes sequencial e paralelo. Esta limita¸c˜ao ´e decorrente do n´ıvel de expressividade provido pelo formalismo l´ogico empregado pelos trabalhos, no caso, a l´ogica linear.

Documentos relacionados