Dimens˜ ao Funcional - 3 O M´ etodo de Certifica¸ c˜ ao de

3 O M´ etodo de Certifica¸ c˜ ao de

3.2.3 Dimens˜ ao Funcional

A segunda dimensão do método de certifica¸cão é denominada dimensão funcional. A dimensão funcional tem por objetivo verificar a funcionalidade da estrutura do workflow mediante a verifica¸cão das pré- e pós-condi¸cões do mesmo. A estrutura do workflow é dada pela composi¸cão dos elementos da base (S(I, O)), conforme definido na gramática da Figura 3. O s´ımbolo terminal S(I, O) define o elemento base da estrutura do workflow, representando as invoca¸cões de servi¸cos dadas na implementa¸cão do workflow. Assume-se que as invoca¸cões de servi¸cos aparecendo no workflow estão associadas a uma descri¸cão dada em conformidade com a defini¸cão 3.1.2. As asser¸cões (s´ımbolo não-terminal A na

Figura 3) aparecendo nos elementos estruturais do workflow representam axiomas de ABox formulados em conformidade com o fragmento ALC da l´ogica descritiva.

Esta dimensão visa certificar que um workflow cumpre uma determinada especifica¸cão dada na forma de pré- e pós-condi¸cões. Para realizar a certifica¸cão funcional, emprega- se um cálculo de programa baseado na lógica de Hoare [54], onde as especifica¸cões de corre¸cão parcial são dadas na forma de triplas:

{ϕ} W {ψ} (3.23)

onde ϕ e ψ são asser¸cões de ABox representando a pré-condi¸cão e a pós-condicão, respectivamente, e W representa um workflow.

O cálculo de Hoare proposto permite derivar especifica¸cões de corre¸cão parcial válidas. As regras de inferência do cálculo de programa proposto estão descritas na Figura 10. As regras de inferência assumem duas informa¸cões como contexto:

• uma base de conhecimento K = hT , Ai composta por um TBox T e por um ABox A. A base de conhecimento K tem um papel importante na deriva¸cão das especifica¸cões de corre¸cão parcial, especificamente na prova das obriga¸cões geradas a partir da aplica¸cão das regras. A base K fornece a terminologia e os fatos iniciais usados nas inferências realizadas para provar as obriga¸cões.

• um mapeamento Γ, dado pelas fun¸cões injetivas, representa o mapeamento dos iden- tificadores usados em cada invoca¸cão de servi¸co, conforme descrito na se¸cão 3.2.2. O mapeamento Γ é fundamental para que as inferências envolvendo identificadores diferentes, porém representando um mesmo indiv´ıduo, sejam realizadas corretamente pelo raciocinador DL.

No contexto desta tese, a nota¸cão K, Γ |= φ é usada para expressar que uma fórmula φ é consequência lógica de uma base de conhecimento K, considerando o mapeamento provido por Γ.

As regras do cálculo seguem, basicamente, a estrutura da gramática da linguagem de workflow proposta para expressar as composi¸cões de servi¸cos web semânticos. O axi- oma de servico representa um esquema englobando todas as defini¸cões de servi¸cos web semânticos aplicáveis nas deriva¸cões das provas de corre¸cão parcial. Em outras palavras, cada defini¸cão de servi¸co web semântico dispon´ıvel é considerada uma instância deste es- quema, representada por suas pré-condi¸cões (P re) e efeitos (E). A regra do consequente

serve como um mecanismo para combinar provas parciais de forma a compor a prova final, através do fortalecimento da pré-condi¸cão e do enfraquecimento da pós-condi¸cão. A regra de sequência permite que uma especifica¸cão dada por uma sequência de workflows seja derivada a partir de suas especifica¸cões individuais. A regra requer que seja estabelecida uma asser¸cão intermediária θ, a partir da qual seja poss´ıvel derivar as especifica¸cões indi- viduais. A regra paralelo estabelece que uma especifica¸cão dada pela composi¸cão paralela de workflows pode ser derivada a partir de suas deriva¸cões independentes, observadas as condi¸cões impostas pela regra. A regra if estabelece que uma especifica¸cão dada por uma estrutura condicional if-then-else pode ser derivada a partir das deriva¸cões de ambos os branches, considerando os respectivos valores de verdade da condi¸cão na deriva¸cão de cada branch. A regra de escolha estabelece que uma especifica¸cão contendo escolha guar- dada pode ser derivada a partir das deriva¸cões de cada branch desde que estabele¸cam a mesma pós-condi¸cão. A regra while permite que uma especifica¸cão contendo itera¸cão seja derivada a partir da inferência de um invariante adequado para a itera¸cão.

(servico)

K, Γ ⊢ {P re ∧ ECk} S(I, O) {ELk}

S = hI, O, P re, Ei∧ | Si inv| = | I ∪ O | (cons) K, Γ ⊢ {ϕ′} W {ψ′} K, Γ ⊢ {ϕ} W {ψ} (K ∪ {ϕ}, Γ |= ϕ′_)∧ (update(K, ψ′_{), Γ |= ψ)} (sequencia) K, Γ ⊢ {ϕ} W1 {θ} K, Γ ⊢ {θ} W2 {ψ} K, Γ ⊢ {ϕ} W1; W2 {ψ} (paralelo) K, Γ ⊢ {ϕ′} W1 {ψ′} K, Γ ⊢ {ϕ′′} W1 {ψ′′} K, Γ ⊢ {ϕ} W1k W2 {ψ} K ∪ {ϕ}, Γ |= ϕ′_{∪ ϕ}′′_∧ update(K, ψ′_{∪ ψ}′′_{), Γ |= ψ} (if ) K, Γ ⊢ {ϕ ∪ A1} W1 {ψ} K, Γ ⊢ {ϕ ∪ ¬A1} W2 {ψ} K, Γ ⊢ {ϕ} if A1thenW1elseW2 {ψ} (escolha) K, Γ ⊢ {ϕ ∪ A1} W1 {ψ} K, Γ ⊢ {ϕ ∪ A2} W2 {ψ} K, Γ ⊢ {ϕ} [A1]W1+ [A2]W2 {ψ} (while) K, Γ ⊢ {θ ∪ A1} W {θ} K, Γ ⊢ {θ} while A1doW {¬A1∪ θ}

Figura 10: C´alculo de Hoare para a linguagem de workflow.

As subse¸cões a seguir discutem a aplicabilidade de cada uma das regras na deriva¸cão de especifica¸cões de corre¸cão parcial. A discussão de cada regra é complementada com sua respectiva aplica¸cão no running example descrito no in´ıcio desta se¸cão. As provas dos exemplos discutidos a seguir estão representadas na forma de árvore, onde a conclusão representa a especifica¸cão a ser provada e as sub-árvores representam a aplica¸cão de regras na deriva¸cão da prova. Nos exemplos envolvendo árvores de prova mais complexas requerendo mais espa¸co para sua representa¸cão, as sub-árvores (deriva¸cões parciais) são

ilustradas separadamente e fornecida uma indica¸cão associando-a com a árvore principal. Nestes casos, a deriva¸cão da prova é dada pela agrega¸cão (jun¸cão) de todas as sub-árvores. 3.2.3.1 Regra de Invocacão de Servi¸co

No cálculo proposto, considera-se cada servi¸co semântico como um contrato, ou seja, tem-se acesso a ele somente através de sua interface publicada, sem o conhecimento de seu funcionamento interno. Todo o racioc´ınio envolvendo os servi¸cos semânticos é realizado com base em sua interface publicada, uma vez que não pode-se assumir que seu código- fonte esteja dispon´ıvel (como no caso de servi¸cos terceirizados). A partir desta perspectiva, cada defini¸cão de servi¸co semântico é tratada como um axioma no cálculo proposto, o qual é generalizado pelo esquema de axioma englobando sua pré-condi¸cão P re e seus efeitos condicionais E, conforme ilustrado no axioma abaixo (transcrito da Figura 10).

(servico)

K, Γ ⊢ {P re ∧ ECk} S(I, O) {ELk}

S = hI, O, P re, Ei∧ | Si

inv | = | I ∪ O |

onde Si

inv ∈ Γ representa a fun¸cão de mapeamento da i-ésima invoca¸cão do servi¸co S e

a nota¸c˜ao “| • |” expressa a cardinalidade de um conjunto. Os identificadores ECk e ELk

denotam o k-´esimo efeito condicional do servi¸co S (i.e., {ECk/ELk} ∈ E).

Intuitivamente, a regra de invoca¸cão de servi¸co expressa que sua aplica¸cão na deriva¸cão de uma especifica¸cão requer a existência da defini¸cão do servi¸co S invocado e a respectiva fun¸cão de mapeamento Si

inv ∈ Γ. Uma vez que estas condi¸c˜oes s˜ao verificadas

(existência da defini¸cão do servi¸co e da fun¸cão de mapeamento), o axioma de invoca¸cão de servi¸co (instanciado com a defini¸cão do servi¸co S) pode ser empregado na deriva¸cão de especifica¸cões de corre¸cão parcial.

No caso de servi¸cos web semânticos com múltiplos efeitos condicionais, cada efeito condicional é considerado individualmente quando a regra de servi¸co é empregada na deriva¸cão de especifica¸cões. Esta no¸cão é dada pela conclusão da regra de invoca¸cão de servi¸co, a qual expressa que o efeito ELk é garantido ser verdadeiro após a invoca¸cão do

servi¸co S se a pr´e-condi¸c˜ao P re ∧ ECk se verifica no estado inicial (i.e., o estado anterior

à invoca¸cão do servi¸co). Resumidamente, cada efeito condicional de um servi¸co web semântico (juntamente com a pré-condi¸cão) é tratado individualmente como uma instância do axioma de invoca¸cão de servi¸co. Dessa forma, quando uma deriva¸cão de especifica¸cão envolve um servi¸co web semântico com múltiplos efeitos condicionais, é necessário que

1 @pre[ e x i s t s h a s P r o d u c t A v a i l a b l e . Product ( ps ) ] 2

3 s e a r c h (<ps >, <p>)

5 @post[ I n S t o c k ( p ) ]

Figura 11: Exemplo de uma especifica¸cão válida com invoca¸cão de servi¸co com efeitos condicionais.

somente uma dentre as (poss´ıveis) instâncias do axioma de invoca¸cão para o referido servi¸co se verifique (devido à suposi¸cão de que os múltiplos efeitos condicionais do servi¸co são mutualmente exclusivos) para concluir a validade da deriva¸cão.

O exemplo da Figura 11 ilustra uma especifica¸cão de corre¸cão parcial cujo workflow é composto apenas por uma invoca¸cão de servi¸co web semântico com múltiplos efeitos condicionais (no caso, o servi¸co search). A defini¸cão do servi¸co search é descrita a seguir (transcrita do running example apresentado na se¸cão 3.2.1):

search = h{P roductSpecif ication(prodSpec)}, {P roduct(prod)}, {⊤}, {∃hasP roductAvailable.P roduct(prodSpec)/InStock(prod), ¬∃hasP roductAvailable.P roduct(prodSpec)/OutOf Stock(prod)}i Neste caso, de acordo com a especifica¸cão dada, a deriva¸cão pode ser conclu´ıda com a aplica¸cão do axioma de invoca¸cão de servi¸co instanciado com a defini¸cão do servi¸co

search. Considerando que a defini¸c˜ao do servi¸co search estabelece dois efeitos condicionais,

o axioma de invoca¸cão deve ser instanciado duas vezes, uma para cada efeito condicional. A Figura 13 ilustra as duas deriva¸cões (inv1 e inv2) geradas a partir da aplica¸cão da regra

de invoca¸cão considerando os efeitos condicionais definidos pelo servi¸co search. Para concluir a validade da especifica¸cão, é suficiente que uma das deriva¸cões seja válida. No exemplo considerado aqui, a deriva¸cão inv1 na Figura 13 é uma deriva¸cão válida para a

especifica¸c˜ao dada na Figura 11.

Observe que a fun¸c˜ao de mapeamento search1

inv ∈ Γ no contexto do axioma de in-

voca¸cão é fundamental para decidir a correspondência exata entre as pré- e pós-condi¸cões da especifica¸cão e da defini¸cão do servi¸co. A fun¸cão de mapeamento search1

inv define o

conjunto {hproduct, pi, hprodSpec, psi}.

1 @pre[ A u t h o r i z a t i o n ( a ) ] 2

3 pay (<a >, <i >)

5 @post[ P a i d I n v o i c e ( i ) ]

Figura 12: Exemplo de especifica¸cão inválida com invoca¸cão de servi¸co.

pay dada a seguir:

pay = h{P aymentM ethod(pm)}, {Invoice(inv)}, {⊤}, {hasP ayment(inv, pm)}i

Neste caso, a especifica¸cão dada não pode ser provada com a simples aplica¸cão do axioma de invoca¸cão instanciado com a defini¸cão do servi¸co pay, ao contrário do que foi demonstrado no cenário anterior. Aqui, as pré- e pós-condi¸cões dadas na especifica¸cão e na defini¸cão do servi¸co não são sintaticamente unificáveis [101], uma vez que os concei- tos envolvidos em suas defini¸cões são distintos. A pré-condi¸cão da especifica¸cão garante um estado inicial onde o indiv´ıduo a é parte do dom´ınio do conceito Authorization, enquanto que a defini¸cão do servi¸co pay requer um estado no qual o individuo a (considere a fun¸cão de mapeamento pay1

inv = {hpm, ai, hinv, ii} ∈ Γ) ´e parte do dom´ınio do conceito

P aymentM ethod, sendo que os conceitos são sintaticamente incompat´ıveis. O mesmo problema de incompatibilidade ocorre com os conceitos usados nas asser¸cões dadas como pós-condi¸cões da especifica¸cão e da defini¸cão do servi¸co (P aidInvoice e Invoice, respectivamente).

Concluindo, a aplica¸cão do axioma de servi¸co requer um cenário bastante restrito, onde a pré- e a pós-condi¸cão da especifica¸cão correspondam exatamente à pré-condi¸cão e efeitos da defini¸cão do servi¸co, o que limita consideravelmente sua aplica¸cão na deriva¸cão da prova de especifica¸cões de corre¸cão. Entretanto, como pode ser observado no último cenário (Figura 12), a especifica¸cão faz sentido uma vez que o estado garantido/requerido pela mesma é mais restrito/geral do que àquele requerido/produzido pela aplica¸cão do axioma de servi¸co pay. Ou seja, a especifica¸cão é válida porém não é derivável somente com a aplica¸cão do axioma de invoca¸cão de servi¸co.

Para tratar com situa¸c˜oes desta natureza, propomos a regra do consequente, conforme descrito a seguir.

| {hproduct, pi, hprodSpec, psi} | = | {ps} ∪ {p} |

(inv2)

K@, Γ ⊢ {¬∃hasP roductAvailable.P roduct(ps)} search(hpsi, hpi) {OutOf Stock(p)}

search = h{P roductSpecif ication(prodSpec)}, {P roduct(prod)}, {⊤}, {∃hasP roductAvailable.P roduct(prodSpec)/InStock(prod), ¬∃hasP roductAvailable.P roduct(prodSpec)/OutOf Stock(prod)}i∧

| {hproduct, pi, hprodSpec, psi} | = | {ps} ∪ {p} |

Figura 13: Exemplo de instancia¸cão da regra de invoca¸cão para um servi¸co com múltiplos efeitos condicionais.

(cons)

(inv)

K@, Γ ⊢ {P aymentM ethod(pm)} pay(hauthi, hinvi) {Invoice(inv), hasP ayment(inv, pm)}

K@, Γ ⊢ {Authorization(a)} pay(hai, hii) {P aidInvoice(i)}

K@∪ {Authorization(a}, Γ |= P aymentM ethod(pm)∧

update(K@, {Invoice(inv), hasP ayment(inv, pm)}), Γ

|= P aidInvoice(i)

Figura 14: Exemplo de deriva¸c˜ao da prova para invoca¸c˜ao de servi¸co.

(cons)

(inv)

K@, Γ ⊢ {Registered(c)} signIn(hci, hsi) {OpenSession(s), hasLogin(c, s)}

K@, Γ ⊢ {θ} signIn(hci, hsi) {Logged(c)}

K@∪ θ, Γ |= Registered(c)∧

update(K@, {OpenSession(s), hasLogin(c, s)}), Γ

|= Logged(c)

(cons)

(inv)

K@, Γ ⊢ {Credential(c), ¬Registered(c)} createAcct(hci, hsi) {ClosedSession(s), hasLogin(c, s)}

K@, Γ ⊢ {Credential(c), ¬Registered(c)} createAcct(hci, hsi) {θ}

K@∪ {Credential(c), ¬Registered(c)}, Γ |= {Credential(c), ¬Registered(c)} ∧ update(K@, {ClosedSession(s), hasLogin(c, s)}), Γ |= θ (seq) . . .

K@, Γ ⊢ {Credential(c), ¬Registered(c)} createAcct(hci, hsi) {θ}

. . .

K@, Γ ⊢ {θ} signIn(hci, hsi) {Logged(c)}

K@, Γ ⊢ {Credential(c), ¬Registered(c)} createAcct(hci, hsi); signIn(hci, hsi) {Logged(c)}

3.2.3.2 Regra do Consequente

Como ilustrado nos exemplos da se¸cão anterior, a aplica¸cão do axioma de servi¸co na derivacão de prova restringe-se à situa¸cões espec´ıficas onde existe uma correspondência (sintática) exata entre os conceitos usados para definir as asser¸cões aparecendo nas pré- e pós-condi¸cões da especifica¸cão e da defini¸cão do servi¸co. Esta restri¸cão r´ıgida na aplicabilidade do axioma de invoca¸cão de servi¸co impede que o mesmo seja aplicado na derivacão de especifica¸cões que empregam conceitos sintaticamente distintos, porém semanticamente compat´ıveis, na formula¸cão das pré- e pós-condi¸coes. O exemplo descrito na Figura 12 ilustra esta situa¸cão, onde a pós-condi¸cão da especifica¸cão refere-se ao con- ceito PaidInvoice enquanto que a pós-condi¸cão do servi¸co refere-se ao conceito Invoice e a propriedade hasPayment. Nitidamente, estes conceitos e propriedades são sintatica- mente distintos, mas semanticamente compat´ıveis se observada a terminologia T@ dada

no exemplo (i.e., P aidInvoice ≡ Invoice ⊓ ∃hasP ayment.P aymentM ethod).

A regra do consequente desempenha um papel importante na deriva¸cão da prova, permitindo ajustar as asser¸cões das provas parciais de forma a compor a árvore de prova completa. Em essência, a regra do consequente permite que especifica¸cões já provadas (i.e., teoremas) sejam usados na deriva¸cão de novas especifica¸cões através do enfraquecimento ou fortalecimento das pré- e pós-condi¸cões, respectivamente. Uma asser¸cão ϕ é dita ser mais forte que uma asser¸cão ϕ′ _{se ϕ ⇒ ϕ}′ _{se verifica. Por outro lado, diz-se que a}

asser¸cão ϕ′ _{é mais fraca que a asser¸cão ϕ. A regra do consequente apresentada a seguir}

foi transcrita da Figura 10.

(cons) K, Γ ⊢ {ϕ

′_{} W {ψ}′_}

K, Γ ⊢ {ϕ} W {ψ}

(K ∪ {ϕ}, Γ |= ϕ′_)∧

(update(K, ψ′_{), Γ |= ψ)}

A regra estabelece que uma especifica¸c˜ao {ϕ} W {ψ} pode ser derivada a partir de um teorema {ϕ′_{} W {ψ}′_{} uma vez que as condi¸c˜oes se verificam. Para isso, basta provar}

que a asser¸cão ϕ é mais forte que a asser¸cão ϕ′ _{considerando a base de conhecimento K,}

e por outro lado, que a asser¸cão ψ é consequência lógica da asser¸cão ψ′ _{considerando a}

base de conhecimento K. Ambas as condi¸cões representam as obriga¸cões de prova para a aplica¸cão da regra do consequente.

Retomando o exemplo apresentado na Figura 12, a especifica¸cão dada poderia ser derivada com a aplica¸cão conjunta da regra do consequente e do axioma de invoca¸cão de servi¸co. A deriva¸cão da prova para o exemplo é ilustrada na Figura 14. As obriga¸cões de

prova geradas pela aplica¸c˜ao da regra do consequente s˜ao listadas a seguir.

K@∪ {Authorization(a)}, Γ |= P aymentM ethod(pm) (3.24)

update(K@, {Invoice(inv), hasP ayment(inv, pm)}), Γ |= P aidInvoice(i) (3.25)

A verifica¸cão das obriga¸cões de prova é modelada como um problema de inferência, ou seja, um problema de decidir se a consequência semântica se verifica a partir da base de conhecimento dada (neste exemplo, K@). Observe que os indiv´ıduos aparecendo na

fórmula 3.24 são distintos, ou seja, seriam tratados como diferentes indiv´ıduos pelo raciocinador DL. Dessa forma, a fun¸cão de mapeamento pay1

inv ∈ Γ dada no contexto permite

ajustar os nomes dos indiv´ıduos de forma que sejam tratados como sendo o mesmo indiv´ıduo (i.e., pm 7→ a). Dessa forma, após a substituicão dos identificadores, a validade da obriga¸cão de prova 3.24 é dada pela verifica¸cão se a consequência semântica

K@∪ {Authorization(a)}, Γ |= P aymentM ethod(a)

se verifica. A partir da base de conhecimento dada por K@, a obriga¸c˜ao de prova 3.24

se verifica, uma vez que ´e poss´ıvel inferir o relacionamento hier´arquico Authorization ⊑ P aymentM ethod a partir da terminologia T@ (conforme ilustrado na Figura 7).

A prova da obriga¸cão 3.25 requer (após a substitui¸cão dos identificadores) a verifica¸cão se a consequência lógica

update(K@, {Invoice(i), hasP ayment(i, a)}), Γ |= P aidInvoice(i)

se verifica. Assumindo que a base de conhecimento K@ contˆem as asser¸c˜oes dadas na

pré-condi¸cão do servi¸co pay (i.e., P aymentM ethod(a)), conclui-se que a obriga¸cão de prova se verifica. Esta conclusão é inferida devido à presen¸ca do axioma de equivalência

PaidInvoice ≡ Invoice ⊓ ∃ hasPayment.PaymentMethod na terminologia T@ da base

de conhecimento K@. Considerando a base de conhecimento resultante da execu¸c˜ao da

opera¸cão de atualiza¸cão update, a consequência lógica verificada para esta obriga¸cão pode ser sintetizada por

{Invoice(i), hasP ayment(i, a), P aymentM ethod(a)}), Γ |= P aidInvoice(i)

Observe novamente que o problema da divergência de nomes dos identificadores (por ex., “i” e “inv” na fórmula 3.25) é resolvido pela aplica¸cão da fun¸cão de mapeamento pay1

1 @pre[ C r e d e n t i a l ( c ) , not R e g i s t e r e d ( c ) ] 2 3 c r e a t e A c c t (<c >, <s >) ; 4 s i g n I n (<c >, <s >) 5 6 @post[ Logged ( c ) ]

Figura 16: Especifica¸cão de corre¸cão parcial com sequência de servi¸cos.

Portanto, a partir da verifica¸cão de ambas as obriga¸cões de prova, conclui-se que a especifica¸cão de corre¸cão parcial dada na Figura 12 é válida.

3.2.3.3 Regra de Sequˆencia

Esta regra permite que uma especifica¸cão de corre¸cão parcial para uma sequência {ϕ} W1; W2 {ψ} seja derivada a partir das especifica¸cões para W1 e W2. Para isso, faz-se

necessário inferir uma asser¸cão intermediária θ que permita a deriva¸cão da prova para as especifica¸cões de W1 e W2 individualmente.

(sequencia) K, Γ ⊢ {ϕ} W1 {θ} K, Γ ⊢ {θ} W2 {ψ} K, Γ ⊢ {ϕ} W1 ; W2 {ψ}

O código ilustrado na Figura 16 expressa uma especifica¸cão de corre¸cão parcial envolvendo a composi¸cão sequencial de workflows, neste caso, as invoca¸cões dos servi¸cos createAcct e signIn. O objetivo é verificar se a composi¸cão sequencial dos servi¸cos sa- tisfaz a especifica¸cão dada, ou seja, se a execu¸cão do workflow permite obter um estado onde um determinado usuário c está logado (Logged(c)).

A deriva¸cão da prova para este exemplo é ilustrada na Figura 15. A deriva¸cão da prova inicia pela aplica¸cão da regra da sequência, uma vez que o elemento topo (a raiz da árvore sintática) do workflow é dado pelo construtor sequencial. A aplica¸cão da regra de sequência requer que seja inferida uma asser¸cão intermediária θ, conforme ilustrado na deriva¸cão (parcial) na parte inferior da Figura 15. No entanto, a deriva¸cão da prova segue sem a atribui¸cão de uma asser¸cão concreta para θ, mantendo-se o s´ımbolo θ onde for necessário referenciar a asser¸cão intermediária. A defini¸cão da asser¸cão concreta para θ será dada a seguir, quando discutida a verifica¸cão da validade das obriga¸cões de prova. O próximo passo consiste na deriva¸cão da prova para as premissas da regra da sequência aplicada anteriormente. Ambas as deriva¸cões para as premissas estão ilustradas na parte superior da Figura 15 (as duas primeiras deriva¸cões). Tendo em vista que o workflow dado em cada premissa a ser provada envolve a invoca¸cão de um servi¸co (um s´ımbolo

terminal da linguagem), aplica-se o axioma de invoca¸cão de servi¸co em cada deriva¸cão, instanciados com as defini¸cões dos servi¸cos correspondentes. Como discutido na se¸cão anterior, a falta de correspondência sintática entre as pré- e pós-condi¸cões dos servi¸cos e da especifica¸cão requer a aplica¸cão da regra do consequente em ambas as deriva¸cões. Observe que no caso da deriva¸cão referente ao servi¸co createAcct, não foi necessário o fortalecimento da pré-condi¸cão, uma vez que houve a correspondência exata entre elas ({Credential(c), ¬Registered(c)} ⇒ {Credential(c), ¬Registered(c)}).

Assim, as obriga¸cões de prova geradas na deriva¸cão para este exemplo são as seguintes: update(K@, {ClosedSession(s), hasLogin(c, s)}), Γ |= θ (3.26)

K@∪ θ, Γ |= Registered(c) (3.27)

update(K@, {OpenSession(s), hasLogin(c, s)}), Γ |= Logged(c) (3.28)

Para provar as obriga¸cões geradas na deriva¸cão (e assim concluir a validade da especifica¸cão), faz-se necessário primeiramente inferir a asser¸cão intermediária θ. A inferência da asser¸cão intermediária θ depende da estratégia escolhida para raciocinar sobre a deriva¸cão da prova, ou seja, se é aplicada a estratégia backward (partindo da pós-condi¸cão da espe- cifica¸cão) ou forward (partindo da pré-condi¸cão da especifica¸cão). ´E importante observar que o axioma de invoca¸cão de servi¸co não pré-estabelece uma estratégia de racioc´ınio espec´ıfica para verificar a validade da especifica¸cão, podendo-se optar por qualquer uma delas. No caso do emprego da estratégia backward, assume-se que a asser¸cão intermediária θ é dada pela pré-condi¸cão do último workflow da sequência. Por outro lado, se for empre- gada a estratégia forward, assume-se θ como sendo a pós-condi¸cão do primeiro workflow

No documento Certificação de composições de serviços web semânticos (páginas 67-87)