4 Ambiente de Certifica¸ c˜ ao
4.1 Arquitetura do Ambiente de Certifica¸c˜ ao
4.1.3 M´ odulo Certifier
O m´odulo Certifier contˆem as implementa¸c˜oes das funcionalidades centrais do m´etodo de certifica¸c˜ao. A Figura 24 ilustra a sequˆencia de tarefas executadas durante o processo de certifica¸c˜ao.
Figura 24: Diagrama de Atividades do Processo de Certifica¸c˜ao.
A implementa¸c˜ao de cada uma das atividades ´e dada pelas classes contidas no m´odulo
Certifier. As atividades descritas no diagrama de atividades foram implementadas com
base no padr˜ao de projeto Visitor. Como pode ser observado no diagrama de pacotes da Figura 23, todas as classes do m´odulo Certifier estendem (direta ou indiretamente) a classe SemanticPEWSVisitorAdapter, a qual provˆe uma implementa¸c˜ao vazia dos m´etodos relacionados `a aplica¸c˜ao do padr˜ao de projeto Visitor.
A listagem 4.1 a seguir ilustra a assinatura padr˜ao do m´etodo que implementa o padr˜ao de projeto Visitor para cada s´ımbolo da gram´atica da linguagem de workflow considerada neste trabalho. O m´etodo visit assume dois parˆametros de entrada (node e data) e produz como resultado um objeto. O tipo do parˆametro node (i.e., ASTxxx) varia de acordo com o construtor da linguagem em quest˜ao. Por exemplo, na assinatura do m´etodo visit relativo ao n´o da ´arvore sint´atica abstrata representando o construtor condicional (i.e., if ), o tipo associado ao parˆametro node ´e dado por ASTif, e assim por diante. Para cada construtor da linguagem, existe um m´etodo visit correspondente cujo tipo do parˆametro node ´e dependente do construtor em quest˜ao. O parˆametro data ´e um parˆametro de prop´osito geral, cuja aplica¸c˜ao ´e dependente de cada situa¸c˜ao.
1 p u b l i c O b j e c t v i s i t ( ASTxxx node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 . . . 3 }
Listagem 4.1: Assinatura do m´etodo implementando o padr˜ao Visitor para os construtores da gram´atica.
A classe SemanticPEWSVisitorAdapter fornece uma implementa¸c˜ao vazia para o m´etodo visit relativo `a cada construtor da linguagem de workflow. Em cada imple- menta¸c˜ao do m´etodo visit, o tipo do parˆametro node varia de acordo com o construtor considerado (p.ex., ASTontology, ASTsws, ASTinv, ASTchoice, ASTsequence, etc).
Atividade “Load Resources”. A primeira atividade executada no processo de cer- tifica¸c˜ao ´e a atividade Load Resources, conforme ilustrado na Figura 24. Esta atividade ´e respons´avel pelo carregamento das ontologias e das defini¸c˜oes dos servi¸cos web semˆanticos usados na defini¸c˜ao do workflow. Em rela¸c˜ao `as ontologias, somente os axiomas termi- nol´ogicos (TBox) s˜ao extra´ıdos, uma vez que os axiomas de ABox originalmente contidos na ontologia, se existirem, n˜ao s˜ao relevantes para representar o estado inicial considerado no processo de certifica¸c˜ao. O estado inicial ´e representado unicamente pelas asser¸c˜oes descritas na pr´e-condi¸c˜ao da especifica¸c˜ao (i.e., as asser¸c˜oes aparecendo no contexto do identificador @Pre no c´odigo do workflow).
Esta atividade ´e implementada pela classe LoadResourcesVisitor ilustrada na Fi- gura 23 (m´odulo Certifier ). A implementa¸c˜ao desta classe ´e (parcialmente) descrita na listagem 4.2, a qual estabelece que somente os n´os da ´arvore sint´atica relativos `a decla- rac˜ao de ontologias e de servi¸cos web semˆanticos devem ser processados (identificados pelas constantes ONTOLOGIES DEF e SWSS DEF ), de acordo com as linhas 3 e 4 da listagem a seguir.
1 p u b l i c O b j e c t v i s i t ( ASTprogram programNode , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 // c a r r e g a a s o n t o l o g i a s e a s d e f i n i c o e s dos s e r v i c o s s e m a n t i c o s 3 programNode . j j t G e t C h i l d ( I n d e x e s . ONTOLOGIES DEF) . j j t A c c e p t ( t h i s , data ) ; 4 programNode . j j t G e t C h i l d ( I n d e x e s . SWSS DEF) . j j t A c c e p t ( t h i s , data ) ;
5 r e t u r n data ;
6 }
Listagem 4.2: Implementa¸c˜ao da atividade “Load Resources”
A execu¸c˜ao desta atividade visa otimizar o processo de certifica¸c˜ao atrav´es do carrega- mento antecipado das defini¸c˜oes dos servi¸cos web semˆanticos e das ontologias de dom´ınio empregadas na defini¸c˜ao do c´odigo do workflow.
Atividade “Validate URLs”. Esta atividade ´e respons´avel pela valida¸c˜ao dos elementos definidos na se¸c˜ao de declara¸c˜oes do workflow. A valida¸c˜ao consiste em verificar se as URLs associadas aos identificadores definidos na se¸c˜ao de declara¸c˜ao do workflow correspondem (sintaticamente) `aquelas definidas nas ontologias de dom´ınio.
Esta atividade ´e implementada pela classe URLCertifier da Figura 23 (m´odulo Cer-
tifier ). A classe URLCertifier estende a classe abstrata CertifierVisitor, a qual provˆe
defini¸c˜oes e implementa¸c˜oes comuns das tarefas relacionadas com a certifica¸c˜ao do work- flow. Como pode-se observar na listagem 4.3, s˜ao validadas as URLs associadas aos conceitos, propriedades e indiv´ıduos definidos na se¸c˜ao de declara¸c˜oes do workflow (iden-
tificados pelas constantes TYPES DEF, PROPERTIES DEF e INDIVIDUALS DEF ). A valida¸c˜ao de cada tipo de defini¸c˜ao (i.e., conceitos, propriedades e indiv´ıduos) ´e reali- zada visitando-se os n´os-filho de cada um dos tipos de declara¸c˜oes. A linha 2, 3 e 4 do c´odigo abaixo expressam, respectivamente, o processamento das defini¸c˜oes dos conceitos, propriedades e indiv´ıduos.
1 p u b l i c O b j e c t v i s i t ( ASTprogram node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 node . j j t G e t C h i l d ( I n d e x e s . TYPES DEF) . j j t A c c e p t ( t h i s , data ) ;
3 node . j j t G e t C h i l d ( I n d e x e s . PROPERTIES DEF) . j j t A c c e p t ( t h i s , data ) ;
4 node . j j t G e t C h i l d ( I n d e x e s . INDIVIDUALS DEF) . j j t A c c e p t ( t h i s , data ) ;
5 r e t u r n data ;
6 }
Listagem 4.3: Valida¸c˜ao das URLs relativas `a declara¸c˜ao de conceitos, propriedades e indiv´ıduos do workflow.
Atividade “Certify Invocation”. Conforme discutido na se¸c˜ao 3.2.2, a certifica¸c˜ao da dimens˜ao base visa garantir a corre¸c˜ao das invoca¸c˜oes dos servi¸cos web semˆanticos, i.e., certificar que as invoca¸c˜oes de servi¸cos est˜ao em conformidade com suas respectivas declara¸c˜oes no que diz respeito aos argumentos dados na invoca¸c˜ao e aqueles declarados na defini¸c˜ao do servi¸co. Como discutido na se¸c˜ao mencionada acima, os argumentos da invoca¸c˜ao n˜ao precisam ter uma correspondˆencia exata, no que diz respeito `a ordem e ao tipo, com os parˆametros formais da defini¸c˜ao do servi¸co web semˆantico. A atividade
Certify Invocation representa a implementa¸c˜ao da certifica¸c˜ao da dimens˜ao base.
Esta atividade ´e implementada pela classe InvokeCertifierVisitor ilustrada na Fi- gura 23 (pacote Certifier.dimensions.base). Esta classe herda as defini¸c˜oes e imple- menta¸c˜oes providas pela super-classe abstrata CertifierVisitor. A implementac˜ao da classe
InvokeCertifierVisitor depende fundamentalmente da funcionalidade provida pela inter-
face Matchmaker (do m´odulo KnowledgeBase). Esta interface ´e respons´avel por computar o grau de similaridade semˆantica entre dois conceitos ontol´ogicos, cuja funcionalidade de- sempenha um papel central para a certifica¸c˜ao das invoca¸c˜oes de servi¸cos web semˆanticos, conforme discutido na se¸c˜ao 3.2.2.
A certifica¸c˜ao da dimens˜ao base ´e realizada a partir do processamento do n´o da ´arvore sint´atica relativo `a defini¸c˜ao do workflow (constante WORKFLOW DEF ), conforme linha 3 da listagem 4.4. A partir deste n´o, s˜ao processados (visitados) todos os n´os-filhos que referem-se `a invocac˜ao de servi¸co. Este processamento ´e dado pela implementa¸c˜ao do se- gundo m´etodo (a partir da linha 8) da listagem 4.4. A constante INPUTLIST DEF usada na linha 17, estabelece que deve ser processado o n´o-filho da invoca¸c˜ao correspondente `a
lista dos argumentos de entrada do servi¸co invocado. Estes argumentos de entrada s˜ao comparados com os parˆametros formais de entrada declarados na defini¸c˜ao do servi¸co a fim de determinar o mapeamento entre os identificadores dados na invoca¸c˜ao (IDinv) e os
identificadores dados na defini¸c˜ao do servi¸co (IDdef). Este mapeamento ´e individualizado
para cada invoca¸c˜ao de servi¸co web semˆantico. Os mapeamentos produzidos durante este processamento formam o mapeamento Γ empregado no contexto das regras do c´alculo de Hoare para certificar a dimens˜ao funcional do workflow.
A implementa¸c˜ao das atividades relacionadas a certifica¸c˜ao do workflow podem pro- duzir exce¸c˜oes para indicar alguma situa¸c˜ao de erro no processo de certifica¸c˜ao. No caso da atividade “Certify Invocation”, a implementa¸c˜ao pode gerar a exce¸c˜ao Invoca-
tionException para indicar que n˜ao existe correspondˆencia (num´erica e semˆantica) entre
os argumentos da invoca¸c˜ao e os parˆametros formais da defini¸c˜ao do servi¸co (conforme linhas 19 a 22).
1 p u b l i c O b j e c t v i s i t ( ASTprogram node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 // v a l i d a a s i n v o c a c o e s de s e r v i c o s
3 node . j j t G e t C h i l d ( I n d e x e s .WORKFLOW DEF) . j j t A c c e p t ( t h i s , data ) ;
4 r e t u r n data ;
5 } 6
7//−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
8 p u b l i c O b j e c t v i s i t ( ASTinv node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
9 10 STC s t I n v = (STC) s t . g e t ( node . j j t G e t V a l u e ( ) ) ; 11 // c a p t u r a a URL c o n t e n d o a d e f i n i c a o do s e r v i c o 12 S t r i n g s w s U r l = ( S t r i n g ) s t I n v . g e t V a l u e ( ) ; 13 sws = k b S e r v i c e s . r e a d S e r v i c e ( URI . c r e a t e ( s w s U r l ) ) ; 14 P r o f i l e p r o f i l e = sws . g e t P r o f i l e ( ) ; 15 16 // obtem o s p a r a m e t r o s f o r m a i s de e n t r a d a do s e r v i c o
17 L i s t <Match> i n p u t M a t c h e s = ( L i s t <Match>) node . j j t G e t C h i l d (INPUTLIST DEF) . j j t A c c e p t ( t h i s
, p r o f i l e . g e t I n p u t s ( ) ) ;
18
19 i f ( i n p u t M a tc h e s . s i z e ( ) != p r o f i l e . g e t I n p u t s ( ) . s i z e ( ) ) {
20 s o m e I n v o c a t i o n F a i l e d = t r u e ;
21 throw new I n v o c a t i o n E x c e p t i o n ( ” As e n t r a d a s do s e r v i c o [”+ node . j j t G e t V a l u e ( ) +”] nao foram c e r t i f i c a d a s ! ” ) ; 22 } 23 24 // p r o c e s s a m e n t o s i m i l a r o c o r r e para a s s a i d a s do s e r v i c o , o q u a l f o i o m i t i d o n e s t a l i s t a g e m de c o d i g o 25 26 r e t u r n data ; 27 }
4.1.3.1 Atividade “Certify Workflow”.
A dimens˜ao funcional corresponde `a parte central do m´etodo de certifica¸c˜ao, conforme discutido na se¸c˜ao 3.2.3. Com base nela, ´e poss´ıvel verificar se um workflow cumpre (ou n˜ao) uma especifica¸c˜ao dada na forma de uma tripla de Hoare. A atividade Certify
Workflow representa a implementa¸c˜ao da dimens˜ao funcional do m´etodo de certifica¸c˜ao.
Esta atividade ´e implementada pela classe WorkflowCertifierVisitor ilustrada na Fi- gura 23 (pacote Certifier.dimensions.functional ). Esta classe tamb´em herda as defini¸c˜oes e implementa¸c˜oes providas pela super-classe abstrata CertifierVisitor.
Conforme ilustrado na listagem 4.5, a certifica¸c˜ao funcional requer o processamento dos n´os da ´arvore sint´atica relativos `a pr´e-condi¸c˜ao, workflow e p´os-condi¸c˜ao (os quais s˜ao identificados, respectivamente, pelas constantes PRE DEF, WORKFLOW DEF e
POST DEF ). O processamento destes n´os ´e expresso pelas linhas 3, 5 e 10 do c´odigo
ilustrado a seguir.
1 p u b l i c O b j e c t v i s i t ( ASTprogram node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 Set<OWLAxiom> preAxioms = ( Set<OWLAxiom>)
3 node . j j t G e t C h i l d ( I n d e x e s . PRE DEF) . j j t A c c e p t ( t h i s , data ) ;
4 Set<OWLAxiom> postAxioms = ( Set<OWLAxiom>)
5 node . j j t G e t C h i l d ( I n d e x e s . POST DEF) . j j t A c c e p t ( t h i s , data ) ;
6 L i s t <Set<OWLAxiom>> t r i p l e = new A r r a y L i s t <Set<OWLAxiom>>() ;
7 t r i p l e . add ( preAxioms ) ; 8 t r i p l e . add ( postAxioms ) ; 9
10 node . j j t G e t C h i l d ( I n d e x e s .WORKFLOW DEF) . j j t A c c e p t ( t h i s , t r i p l e ) ;
11 r e t u r n data ;
12 }
Listagem 4.5: Certifica¸c˜ao da estrutura do workflow
Processamento da pr´e-condi¸c˜ao. A certifica¸c˜ao da dimens˜ao funcional inicia-se pelo processamento da lista de asser¸c˜oes dadas na pr´e-condi¸c˜ao da especifica¸c˜ao (linha 3 da listagem 4.5). O resultado do processamento da pr´e-condi¸c˜ao da especifica¸c˜ao ´e um conjunto de axiomas de ABox expressos em OWL.
O processamento das asser¸c˜oes dadas na pr´e-condi¸c˜ao da especifica¸c˜ao ´e realizado pela aplica¸c˜ao do padr˜ao Visitor em cada uma das asser¸c˜oes contidas na lista de asser¸c˜oes da pr´e-condi¸c˜ao, conforme ilustrado pelo c´odigo da listagem 4.6.
1 p u b l i c O b j e c t v i s i t ( A S T p r e A s s e r t i o n L i s t node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 Set<OWLAxiom> axioms = new HashSet ( ) ;
3 f o r ( i n t i =0; i <node . jjtGetNumChildren ( ) ; i ++){
5 axioms . add ( axiom ) ;
6 }
7 r e t u r n axioms ;
8 }
Listagem 4.6: Processamento das asser¸c˜oes da pr´e-condi¸c˜ao da especifica¸c˜ao.
Este conjunto de axiomas OWL (representando as asser¸c˜oes da pr´e-condi¸c˜ao da espe- cifica¸c˜ao) ´e usado na verifica¸c˜ao da corre¸c˜ao do workflow, conforme ilustrado nas linhas 6 a 10 da listagem 4.5. Naquele trecho de c´odigo, os axiomas OWL relativos `a pr´e-condi¸c˜ao s˜ao passados como argumento (i.e., o argumento triple) para o m´etodo respons´avel pelo processamento da estrutura do workflow (linha 10).
O passo seguinte refere-se ao processamento das asser¸c˜oes da p´os-condi¸c˜ao da especi- fica¸c˜ao, conforme descrito na se¸c˜ao a seguir.
Processamento da p´os-condi¸c˜ao. O processamento das asser¸c˜oes da p´os-condi¸c˜ao da especifica¸c˜ao ocorre de forma semelhante `a da pr´e-condi¸c˜ao. O c´odigo da listagem 4.7 mostra a implementa¸c˜ao desta tarefa.
1 p u b l i c O b j e c t v i s i t ( A S T p o s t A s s e r t i o n L i s t node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n
{
2 Set<OWLAxiom> axioms = new HashSet ( ) ;
3 f o r ( i n t i =0; i <node . jjtGetNumChildren ( ) ; i ++){
4 OWLAxiom axiom = (OWLAxiom) node . j j t G e t C h i l d ( i ) . j j t A c c e p t ( t h i s , data ) ;
5 axioms . add ( axiom ) ;
6 }
7 r e t u r n axioms ;
8 }
Listagem 4.7: Processamento das asser¸c˜oes da p´os-condi¸c˜ao da especifica¸c˜ao.
Da mesma forma como no processamento da pr´e-condi¸c˜ao, o resultado produzido pelo m´etodo ´e um conjunto de axiomas OWL expressando as asser¸c˜oes dadas na p´os-condi¸c˜ao da especifica¸c˜ao.
A partir dos dois conjuntos de axiomas OWL resultantes do processamento das as- ser¸c˜oes dadas nas pr´e- e p´os-condi¸c˜oes da especifica¸c˜ao (linhas 3 e 5 da listagem 4.5), ´e realizada a certifica¸c˜ao do workflow. Conforme discutido na se¸c˜ao 3.2.3, esta certifica¸c˜ao requer a an´alise de todos os construtores empregados na defini¸c˜ao do workflow. A pr´oxima se¸c˜ao descreve como as regras do c´alculo proposto foram implementadas.
Processamento do workflow. Ap´os o processamento das pr´e- e p´os-condi¸c˜oes da especifica¸c˜ao, inicia-se o processamento do workflow visando estabelecer se a especifica¸c˜ao de corre¸c˜ao parcial ´e deriv´avel. As regras do c´alculo empregado na deriva¸c˜ao da especi- fica¸c˜ao tamb´em foram implementadas com base no padr˜ao de projeto Visitor.
A aplica¸c˜ao das regras na deriva¸c˜ao da especifica¸c˜ao ´e dependente da ´arvore sint´atica abstrata do workflow, i.e., as regras a serem aplicadas dependem do n´o da ´arvore sint´atica em quest˜ao. Antes da aplica¸c˜ao de uma regra na deriva¸c˜ao, as pr´e- e p´os-condi¸c˜oes s˜ao passadas atrav´es do parˆametro data aparecendo em todas as implementa¸c˜oes do m´etodo
visit, conforme ilustrado nas linhas 6 a 10 da listagem 4.5.
O processamento segue a estrutura dada pela ´arvore sint´atica abstrata do workflow a ser verificado. Aplica-se, iterativamente, a regra do c´alculo de acordo com o construtor sint´atico aparecendo na raiz da (sub-) ´arvore, at´e que um n´o-folha seja alcan¸cado (i.e., um n´o representando uma invoca¸c˜ao de servi¸co web semˆantico).
A seguir, s˜ao descritos os aspectos centrais da implementa¸c˜ao de cada uma das regras do c´alculo.
Primeiramente, consideremos o caso em que a raiz da ´arvore ´e dada por uma invoca¸c˜ao de servi¸co web semˆantico. Neste caso, ´e executado o c´odigo ilustrado na listagem 4.8 referente `a regra de invoca¸c˜ao de servi¸co. Como mencionado anteriormente, todas as implementa¸c˜oes das regras recebem um par de asser¸c˜oes (representando as pr´e- e p´os- condi¸c˜oes da especifica¸c˜ao) atrav´es do parˆametro data, conforme ilustrado nas linhas 2 a 4 da listagem 4.8. Os axiomas dados na pr´e-condi¸c˜ao da especifica¸c˜ao descrevem o estado sobre o qual ser´a realizado o racioc´ınio sobre a aplicabilidade do servi¸co invocado (linha 6). O servi¸co invocado ´e diretamente aplic´avel na deriva¸c˜ao se suas pr´e-condi¸c˜oes e efeitos s˜ao sintaticamente unific´aveis com as pr´e-condi¸c˜oes e p´os-condi¸c˜oes dadas na especifica¸c˜ao (linhas 12 a 14). No caso em que as referidas asser¸c˜oes n˜ao s˜ao unific´aveis, aplica-se a regra do consequente para verificar (semanticamente) se o servi¸co ´e aplic´avel na deriva¸c˜ao da especifica¸c˜ao. Este caso est´a coberto pelas linhas 15 a 28 da listagem 4.8. Quando necess´ario aplicar a regra do consequente, s˜ao verificadas ambas as obriga¸c˜oes de prova geradas por sua aplica¸c˜ao. A primeira obriga¸c˜ao de prova diz respeito `a veri- fica¸c˜ao se a pr´e-condi¸c˜ao do servi¸co ´e consequˆencia semˆantica da pr´e-condi¸c˜ao da especi- fica¸c˜ao, conforme descrito pela linha 16 da listagem 4.8 Al´em da verifica¸c˜ao da obriga¸c˜ao de prova acima, ´e requerido verificar a obriga¸c˜ao de prova relativa `a p´os-condi¸c˜ao da espe- cifica¸c˜ao. Esta obriga¸c˜ao ´e provada a partir da verifica¸c˜ao de que a p´os-condi¸c˜ao da espe- cifica¸c˜ao ´e consequˆencia semˆantica do estado (ABox) resultante da atualiza¸c˜ao semˆantica
com os efeitos do servi¸co (linhas 18 e 19). Caso ambas as consequˆencias semˆanticas se verifiquem, a invoca¸c˜ao do referido servi¸co ´e aplic´avel `a deriva¸c˜ao da especifica¸c˜ao. Caso contr´ario, uma exce¸c˜ao ´e gerada para indicar o motivo da falha (linhas 23 e 26).
1 p u b l i c O b j e c t v i s i t ( ASTinv node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 L i s t <Set<OWLAxiom>> t r i p l e = ( L i s t <Set<OWLAxiom>>) data ; 3 Set<OWLAxiom> p r e c o n d i t i o n A x i o m s = t r i p l e . g e t ( 0 ) ; 4 Set<OWLAxiom> p o s t c o n d i t i o n A x i o m s = t r i p l e . g e t ( 1 ) ; 5 6 g e t S t a t e O n t o l o g y ( ) . addABoxAxioms ( p r e c o n d i t i o n A x i o m s ) ; 7 8 S e r v i c e sws = htSws . g e t ( node . j j t G e t V a l u e ( ) ) ; 9 Set<OWLAxiom> s e r v i c e P r e A x i o m s = translatePreconditionToOWLAxiom ( sws ) ; 10 Set<OWLAxiom> s e r v i c e E f f e c t A x i o m s = translateEffectsToOWLAxiom ( sws , p r e c o n d i t i o n A x i o m s ) ; 11 12 i f ( u n i f i c a b l e ( s e r v i c e P r e A x i o m s , p r e c o n d i t i o n A x i o m s ) && 13 u n i f i c a b l e ( s e r v i c e E f f e c t A x i o m s , p o s t c o n d i t i o n A x i o m s ) ) { 14 r e t u r n t r u e ; 15 } e l s e { 16 b o o l e a n p r e S a t i s f i e d = g e t S t a t e O n t o l o g y ( ) . i s E n t a i l e d ( s e r v i c e P r e A x i o m s ) ; 17 i f ( p r e S a t i s f i e d ) { 18 g e t S t a t e O n t o l o g y ( ) . update ( s e r v i c e E f f e c t A x i o m s ) ; 19 b o o l e a n p o s S a t i s f i e d = g e t S t a t e O n t o l o g y ( ) . i s E n t a i l e d ( s e r v i c e P r e A x i o m s ) ; 20 i f ( p o s S a t i s f i e d ) { 21 r e t u r n t r u e ; 22 } e l s e {
23 throw new C e r t i f i c a t i o n E x c e p t i o n ( ” [ERRO] − S e r v i c o NAO e s t a b e l e c e a pos− c o n d i c a o dada : ” + node . j j t G e t V a l u e ( ) ) ;
24 }
25 } e l s e {
26 throw new C e r t i f i c a t i o n E x c e p t i o n ( ” [ERRO] − S e r v i c o NAO a p l i c a v e l : ” + node . j j t G e t V a l u e ( ) ) ;
27 }
28 }
29 r e t u r n f a l s e ;
30 }
Listagem 4.8: Regra de invoca¸c˜ao de servi¸co web semˆantico.
Caso o n´o raiz da ´arvore sint´atica seja dada pelo construtor sequencial, ´e executado o c´odigo da listagem 4.9. A asser¸c˜ao intermedi´aria (θ) requerida na aplica¸c˜ao da regra de sequˆencia ´e assumida ser dada como parte do c´odigo do workflow. Dessa forma, quando aplicada a regra de sequˆencia na deriva¸c˜ao, a asser¸c˜ao intermedi´aria ´e extra´ıda da ´arvore sint´atica (conforme linha 6). As asser¸c˜oes (pr´e- e p´os-condi¸c˜ao) dadas como entrada do m´etodo atrav´es do parˆametro data (linhas 2 a 4), juntamente com a asser¸c˜ao intermedi´aria, s˜ao usadas para expressar ambas as especifica¸c˜oes nas premissas da regra de sequˆencia (linhas 7 e 21). A deriva¸c˜ao das especifica¸c˜oes dadas nas premissas s˜ao realizadas a partir da execu¸c˜ao das linhas 15 e 26. Caso n˜ao seja poss´ıvel derivar alguma das especifica¸c˜oes
da premissa (i.e., se alguma exce¸c˜ao for gerada durante sua deriva¸c˜ao), a implementa¸c˜ao da regra gera uma exce¸c˜ao indicando qual das premissas n˜ao foi poss´ıvel derivar.
1 p u b l i c O b j e c t v i s i t ( ASTseq node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 L i s t <Set<OWLAxiom>> t r i p l e = ( L i s t <Set<OWLAxiom>>) data ; 3 Set<OWLAxiom> p r e c o n d i t i o n T r i p l e = t r i p l e . g e t ( 0 ) ;
4 Set<OWLAxiom> p o s t c o n d i t i o n T r i p l e = t r i p l e . g e t ( 1 ) ;
5
6 OWLAxiom i n t e r m e d i a t e A s s e r t i o n = (OWLAxiom) node . j j t G e t C h i l d (INTERMEDIATE ASSERTION) . j j t A c c e p t ( t h i s , data ) ;
7 L i s t <Set<OWLAxiom>> t r i p l e W 1 = new A r r a y L i s t <Set<OWLAxiom>>() ; 8 t r i p l e W 1 . add ( p r e c o n d i t i o n T r i p l e ) ;
9 Set<OWLAxiom> i n t e r m e d i a t e A x i o m s = new HashSet ( ) ;
10 11 i n t e r m e d i a t e A x i o m s . add ( i n t e r m e d i a t e A s s e r t i o n ) ; 12 t r i p l e W 1 . add ( i n t e r m e d i a t e A x i o m s ) ; 13 t r y { 14 // W1 15 node . j j t G e t C h i l d (SEQ W1) . j j t A c c e p t ( t h i s , t r i p l e W 1 ) ; 16 } c a t c h ( C e r t i f i c a t i o n E x c e p t i o n c e ) {
17 S t r i n g rho = ( S t r i n g ) node . j j t G e t C h i l d ( 1 ) . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( new S o u r c e C o d e V i s i t o r ( ) , t h i s . s t ) ;
18 throw new C e r t i f i c a t i o n E x c e p t i o n ( ”ERRO! Nao eh p o s s e v e l c e r t i f i c a r a p r i m e i r a
p a r t e da s e q u e n c i a ! [”+ rho +”]”) ;
19 }
20
21 L i s t <Set<OWLAxiom>> t r i p l e W 2 = new A r r a y L i s t <Set<OWLAxiom>>() ;
22 t r i p l e W 2 . add ( i n t e r m e d i a t e A x i o m s ) ; 23 t r i p l e W 2 . add ( p o s t c o n d i t i o n T r i p l e ) ; 24 t r y { 25 // W2 26 node . j j t G e t C h i l d (SEQ W2) . j j t A c c e p t ( t h i s , t r i p l e W 2 ) ; 27 } c a t c h ( C e r t i f i c a t i o n E x c e p t i o n c e ) {
28 S t r i n g rho = ( S t r i n g ) node . j j t G e t C h i l d ( 1 ) . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( new S o u r c e C o d e V i s i t o r ( ) , t h i s . s t ) ;
29 throw new C e r t i f i c a t i o n E x c e p t i o n ( ”ERRO! Nao eh p o s s i v e l c e r t i f i c a r a segunda p a r t e da s e q u e n c i a ! [”+ rho +”]”) ;
30 }
31 r e t u r n t r u e ;
32 }
Listagem 4.9: Aplica¸c˜ao da regra de sequˆencia
Caso o n´o raiz da ´arvore seja dado pelo construtor condicional (if ), ´e executado o c´odigo da listagem 4.10. Da mesma forma que a implementa¸c˜ao da regra de sequˆencia, a implementa¸c˜ao desta regra assume que o parˆametro data contˆem as asser¸c˜oes da pr´e- e da p´os-condi¸c˜ao da especifica¸c˜ao a ser derivada. A conjun¸c˜ao da condi¸c˜ao dada no construtor condicional (linha 7), juntamente com a pr´e-condi¸c˜ao da especifica¸c˜ao, formam a pr´e-condi¸c˜ao da especifica¸c˜ao relativa `a parte then do construtor condicional (linhas 9 a 15). A deriva¸c˜ao da especifica¸c˜ao referente `a parte then ´e realizada na linha 18.
Caso a parte else esteja presente no construtor condicional, os passos executados s˜ao semelhantes aos anteriores, diferenciando-se apenas na forma¸c˜ao da pr´e-condi¸c˜ao. Neste caso, a pr´e-condi¸c˜ao ´e formada pela conjun¸c˜ao da pr´e-condi¸c˜ao da especifica¸c˜ao e pela nega¸c˜ao da condi¸c˜ao do construtor condicional (linha 28). Nas linhas 29 a 33, ´e formulada a especifica¸c˜ao relativa `a parte else. A deriva¸c˜ao da especifica¸c˜ao relativa `a parte else (se presente) ´e realizada na linha 36.
1 p u b l i c O b j e c t v i s i t ( ASTifThenElse node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 L i s t <Set<OWLAxiom>> t r i p l e = ( L i s t <Set<OWLAxiom>>) data ; 3 Set<OWLAxiom> p r e c o n d i t i o n T r i p l e = t r i p l e . g e t ( 0 ) ;
4 Set<OWLAxiom> p o s t c o n d i t i o n T r i p l e = t r i p l e . g e t ( 1 ) ;
5
6 // axioma r e l a t i v o aa c o n d i c a o do IF
7 OWLAxiom a x i o m C o n d i t i o n = (OWLAxiom) node . j j t G e t C h i l d (CONDITION) . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( t h i s , data ) ;
8
9 L i s t <Set<OWLAxiom>> t r i p l e W 1 = new A r r a y L i s t <Set<OWLAxiom>>() ;
10 // a d i c i o n a tambem a guarda na pre−c o n d i c a o
11 Set<OWLAxiom> preW1 = new HashSet ( ) ;
12 preW1 . a d d A l l ( p r e c o n d i t i o n T r i p l e ) ; 13 preW1 . add ( a x i o m C o n d i t i o n ) ; 14 t r i p l e W 1 . add ( preW1 ) ; 15 t r i p l e W 1 . add ( p o s t c o n d i t i o n T r i p l e ) ; 16 t r y { 17 // W 1 18 node . j j t G e t C h i l d (THEN) . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( t h i s , t r i p l e W 1 ) ; 19 } c a t c h ( C e r t i f i c a t i o n E x c e p t i o n c e ) {
20 S t r i n g cond = ( S t r i n g ) node . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( new S o u r c e C o d e V i s i t o r ( ) , data ) ; 21 throw new C e r t i f i c a t i o n E x c e p t i o n ( c e . g e t M e s s a g e ( ) ) ; 22 } 23 24 // v e r i f i c a s e o ELSE e s t a p r e s e n t e 25 i f ( node . jjtGetNumChildren ( ) == 3 ) {
26 L i s t <Set<OWLAxiom>> t r i p l e W 2 = new A r r a y L i s t <Set<OWLAxiom>>() ;
27 // a d i c i o n a tambem a n e g a c a o da guarda na pre−c o n d i c a o
28 OWLAxiom complementCondition = (OWLAxiom) node . j j t G e t C h i l d (CONDITION) . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( new ComplementVisitor ( s t ) , data ) ;
29 Set<OWLAxiom> preW2 = new HashSet ( ) ; 30 preW2 . a d d A l l ( p r e c o n d i t i o n T r i p l e ) ;
31 preW2 . add ( complementCondition ) ;
32 t r i p l e W 2 . add ( preW2 ) ; 33 t r i p l e W 2 . add ( p o s t c o n d i t i o n T r i p l e ) ; 34 t r y { 35 // W 2 36 node . j j t G e t C h i l d (ELSE) . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( t h i s , t r i p l e W 2 ) ; 37 } c a t c h ( C e r t i f i c a t i o n E x c e p t i o n c e ) {
38 S t r i n g cond = ( S t r i n g ) node . j j t G e t C h i l d ( 0 ) . j j t A c c e p t ( new S o u r c e C o d e V i s i t o r ( ) , data ) ;
39 throw new C e r t i f i c a t i o n E x c e p t i o n ( c e . g e t M e s s a g e ( ) ) ;
40 } 41 }
42 r e t u r n t r u e ;
43 }
Listagem 4.10: Aplica¸c˜ao da regra do condicional
Caso o n´o raiz da ´arvore seja dado pelo construtor iterativo (while), ´e executado o c´odigo da listagem 4.11. Semelhante `as outras regras, a implementa¸c˜ao desta regra assume que o parˆametro data contˆem as asser¸c˜oes contemplando as pr´e- e p´os-condi¸c˜oes da especifica¸c˜ao a ser derivada.
Como descrito na se¸c˜ao 3.2.3, a regra de itera¸c˜ao requer que seja estabelecido o in- variante da itera¸c˜ao. Supomos, assim como no caso da asser¸c˜ao intermedi´aria da regra de sequˆencia, que o invariante ´e dado juntamente com o c´odigo do workflow, o qual ´e extra´ıdo na linha 7. A condi¸c˜ao da itera¸c˜ao ´e extra´ıda na linha 10. A pr´e-condi¸c˜ao da es- pecificac˜ao (da premissa) a ser derivada ´e formulada a partir da conjun¸c˜ao do invariante e da condi¸c˜ao da itera¸c˜ao, enquanto que a p´os-condi¸c˜ao ´e dada apenas pelo invariante (linhas 11 a 18 da listagem 4.11).
A deriva¸c˜ao da especifica¸c˜ao da premissa da regra de itera¸c˜ao ´e realizada na linha 21. Caso n˜ao seja poss´ıvel derivar a referida especifica¸c˜ao a partir do workflow dado no corpo da itera¸c˜ao, uma exce¸c˜ao ´e gerada indicando que a especifica¸c˜ao n˜ao ´e deriv´avel a partir do invariante dado (linha 23).
1 p u b l i c O b j e c t v i s i t ( A S T i t e r a t i o n node , O b j e c t data ) throws C e r t i f i c a t i o n E x c e p t i o n {
2 L i s t <Set<OWLAxiom>> t r i p l e = ( L i s t <Set<OWLAxiom>>) data ;
3 Set<OWLAxiom> p r e c o n d i t i o n T r i p l e = t r i p l e . g e t ( 0 ) ;
4 Set<OWLAxiom> p o s t c o n d i t i o n T r i p l e = t r i p l e . g e t ( 1 ) ; 5
6 // i n v a r i a n t e da i t e r a c a o
7 OWLAxiom a x i o m I n v a r i a n t = (OWLAxiom) node . j j t G e t C h i l d (LOOP INVARIANT) . j j t A c c e p t ( t h i s , data ) ;
8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−
9 // p r o v a r { I ˆ B} W { I }
10 OWLAxiom a x i o m C o n d i t i o n = (OWLAxiom) node . j j t G e t C h i l d (CONDITION) . j j t A c c e p t ( t h i s , data )
;
11 Set<OWLAxiom> preW = new HashSet ( ) ;
12 preW . add ( a x i o m C o n d i t i o n ) ;
13 preW . add ( a x i o m I n v a r i a n t ) ;
14 Set<OWLAxiom> postW = new HashSet ( ) ;
15 postW . add ( a x i o m I n v a r i a n t ) ;
16 L i s t <Set<OWLAxiom>> t r i p l e W = new A r r a y L i s t <Set<OWLAxiom>>() ;
17 t r i p l e W . add ( preW ) ;
18 t r i p l e W . add ( postW ) ;
19 t r y {
20 // W
21 node . j j t G e t C h i l d (LOOP BODY) . j j t A c c e p t ( t h i s , t r i p l e W ) ; 22 } c a t c h ( C e r t i f i c a t i o n E x c e p t i o n c e ) {
23 throw new C e r t i f i c a t i o n E x c e p t i o n ( ”ERRO! Corpo do l a c o nao e s t a b e l e c e o INVARIANTE[ ” + ( ( SimpleNode ) node . j j t G e t C h i l d (LOOP INVARIANT) ) . j j t G e t V a l u e ( ) + ” ] ” ) ;
24 } 25
26 r e t u r n t r u e ;
27 }
Listagem 4.11: Aplica¸c˜ao da regra de itera¸c˜ao
Caso o n´o raiz da ´arvore seja dado pelo construtor de escolha guardada (+), ´e execu- tado o c´odigo da listagem 4.12. Semelhante `as outras regras, a implementa¸c˜ao desta regra assume que o parˆametro data contˆem as asser¸c˜oes contemplando as pr´e- e p´os-condi¸c˜oes da especifica¸c˜ao a ser derivada (linhas 2 a 4). A deriva¸c˜ao de uma especifica¸c˜ao contendo uma escolha guardada ´e realizada a partir da deriva¸c˜ao de cada um dos workflows guar- dados integrando a escolha guardada. Este aspecto est´a contemplado pela itera¸c˜ao na linha 8 da listagem 4.12 Os workflows guardados s˜ao iterativamente derivados atrav´es da extra¸c˜ao de sua respectiva guarda (linha 10), a partir da qual ´e formulada a especifica¸c˜ao