processo atinge seu objetivo, deixando uma transi¸c˜ao pendente, entre as atividades D e E.
A defini¸c˜ao das atividades em PROMELA, apresentada na se¸c˜ao 3.1 consiste em uma repeti¸c˜ao, que ´e parada pela ativa¸c˜ao da vari´avel “final reached”. Quando essa vari´avel n˜ao ´e verdadeira, as transi¸c˜oes de entrada da atividade s˜ao testadas, e o seu corpo de execu¸c˜ao ´e liberado, ou n˜ao, dependendo do estado do processo. Como visto tamb´em na se¸c˜ao 3.1, todas as atividades s˜ao inicializadas ao mesmo tempo, simulando threads simultˆaneas em um programa, travadas a espera de uma condi¸c˜ao. Uma vez inicializado o processo, as atividades v˜ao sendo executadas at´e que o estado final seja satisfeito, somente ap´os isso, a vari´avel “final reached” ´e declarada verdadeira, liberando a execu¸c˜ao das atividades pendentes. Note que, neste ponto, o crit´erio de termina¸c˜ao completa pode ser relaxado, porque se assumirmos que se o processo pode terminar corretamente, ou seja, atingiu o estado de Objetivo do processo, ent˜ao se ainda existem atividades pendentes, elas devem somente ser ignoradas, pois n˜ao afetam a corre¸c˜ao do processo.
Voltando ao exemplo da figura A.1. O fato de o processo terminar com o cancelamento da compra, deixa uma transi¸c˜ao pendente, entre as atividades de preparo do produto (atividade D) e de entrega do produto (atividade E). No entanto o processo n˜ao pode ser julgado incorreto, uma vez que atingiu o objetivo, que era o de terminar a compra, seja com ou sem sucesso. Apesar de um exemplo simples, nota-se que o crit´erio de termina¸c˜ao completa ´e muito forte para processos reais.
Para se relaxar o crit´erio de termina¸c˜ao completa, basta n˜ao realizar o procedimento descrito na se¸c˜ao 3.2.3, ou seja, n˜ao restringir a verifica¸c˜ao com a f´ormula LTL proposta naquela se¸c˜ao. Fica a crit´erio do usu´ario, definir se permite ou n˜ao a termina¸c˜ao completa como um crit´erio de corre¸c˜ao do processo de workflow.
3.7
Compara¸c˜ao de Desempenho
Nesta se¸c˜ao ´e feita uma compara¸c˜ao entre o desempenho da verifica¸c˜ao de workflows atrav´es da modelagem proposta neste trabalho, utilizando o Spin, e o desempenho do Woflan [17], verificador baseado em redes de Petri. Apenas como crit´erio de compara¸c˜ao, somente a verifica¸c˜ao estrutural ´e utilizada, uma vez que o Woflan faz este tipo de veri- fica¸c˜ao apenas.
A compara¸c˜ao foi feita em duas etapas: primeiro com processos corretos, e posterior- mente com processos que continham pelo menos uma falha (um deadlock, por exemplo). Um exemplo de processo utilizado para a aferi¸c˜ao de tempo ´e apresentado a seguir, na figura 3.9. Este exemplo ´e um dos processos mais complexos apresentados aos verifi- cadores. Apesar da grande quantidade de atividades, e do n´umero de transi¸c˜oes, n˜ao h´a falhas sint´aticas, ou seja, todas as atividades possuem transi¸c˜oes de entrada e sa´ıda; e
34 Cap´ıtulo 3. Verifica¸c˜ao de Workflows
tamb´em n˜ao h´a falhas estruturais, ou seja, sem tarefas mortas, ou deadlocks, nem ter- mina¸c˜ao incompleta (apesar da discuss˜ao da se¸c˜ao 3.6, de que termina¸c˜ao incompleta n˜ao deveria sempre ser considerada uma falha no processo).
Figura 3.9: Exemplo de processo correto usado para medir o desempenho da verifica¸c˜ao. Assim, processos como o apresentado anteriormente na figura 3.9, foram verifica- dos pelo Spin (baseado na modelagem e procedimento propostos neste trabalho), e pelo WoFlan, variando o n´umero de atividades e transi¸c˜oes presentes em cada processo apenas. Os tempos de verifica¸c˜ao podem ser vistos no gr´afico da figura 3.10. Para todos os casos, ambos os verificadores constataram corretamente que os processos n˜ao possu´ıam falhas.
Tabela 3.1: Resultados para processos sem falhas
Nro. Atividades Spin WoFlan
7 0.02 0 15 0.58 0 21 0.57 0 24 18.6 0 25 38.8 0 26 83.8 0 32 4.68 38 27.18
A varia¸c˜ao do n´umero de atividades se d´a tomando sub-processos do processo apresen- tado na figura 3.9. Como pode ser visto na figura 3.10, tanto o desempenho em verifica¸c˜ao
3.7. Compara¸c˜ao de Desempenho 35
Figura 3.10: Resultado de desempenho para ambos os verificadores testados. para o Woflan, quanto para o Spin, sofre um aumento no tempo de execu¸c˜ao, conforme o processo cresce em n´umero de atividades e transi¸c˜oes. No entanto, o aumento no tempo dos resultados para o Spin foi mais acentuado, al´em de ter atingido tempos mais altos com menos atividades que o Woflan.
No entanto, para processos com falhas estruturais, o cen´ario muda. Por exemplo, um processo com uma falha estrutural pode ser visto na figura 3.12. A falha estrutural ´e explicitada pela transi¸c˜ao em vermelho no processo. ´E poss´ıvel notar que, independente da escolha do caminho a seguir ap´os a atividade R, em nenhuma possibilidade a atividade U pode ser executada partindo de R, caracterizando assim um deadlock.
Tabela 3.2: Resultados para processos com falhas
Nro. Atividades Spin WoFlan
7 0 0 15 0 0 21 0 0 24 0 0 25 0 0 26 0 0 32 0 3.15 38 0 24.03
Assim, os mesmos processos corretos utilizados para a medi¸c˜ao de desempenho dos verificadores anteriormente, foram modificados, inserindo-se pelo menos uma falha es- trutural, e reavaliados pelos verificadores. Os tempos de execu¸c˜ao para cada processo verificado pode ser visto na figura 3.11. Assim como o teste anterior, os dois verificadores constataram o erro no processo, como deveria ser.
36 Cap´ıtulo 3. Verifica¸c˜ao de Workflows
Figura 3.11: Resultado de desempenho para processos incorretos.
Note que para processos com falha, a situa¸c˜ao se inverte. A verifica¸c˜ao proposta consegue definir com muita velocidade quanto `a corre¸c˜ao do processo, enquanto o Woflan leva praticamente o mesmo tempo que para processos corretos do mesmo tamanho.
3.7. Compara¸c˜ao de Desempenho 37
Figura 3.12: Exemplo de processos incorreto usado para medir o desempenho da veri- fica¸c˜ao.
Cap´ıtulo 4
Conclus˜oes
Verifica¸c˜oes sint´aticas de workflows s˜ao triviais para a maioria dos sistemas de gerenci- amento de workflows. No entanto, verificar a ausˆencia de deadlocks e a ocorrˆencia de tarefas mortas ´e o objetivo de muitas pesquisas. As solu¸c˜oes mais comuns para esse prob- lema usam o crit´erio de termina¸c˜ao completa, que se mostra muito forte para processos reais. Al´em disso, essas solu¸c˜oes pecam pela falta de verifica¸c˜oes mais complexas, de car´ater semˆantico, como as verifica¸c˜oes propostas neste trabalho.
Assim, foi apresentado neste trabalho um verificador formal de workflows, que usa o Spin model checker, como ferramenta b´asica. Para isso, foi definida uma modelagem de processos de workflow em PROMELA, a linguagem utilizada no Spin. Isso torna poss´ıvel a verifica¸c˜ao sint´atica de processos de workflow via Spin, como checar se todas as atividades possuem transi¸c˜oes de entrada ou sa´ıda, a ausˆencia de deadlocks e de tarefas mortas. Al´em disso, possibilitou tamb´em a verifica¸c˜ao de quest˜oes semˆanticas como quest˜oes ad- hoc espec´ıficas do processo, verifica¸c˜ao de conflitos ao acesso a recursos e verifica¸c˜ao de restri¸c˜oes de custo.
Alguns trabalhos na literatura lidam com as verifica¸c˜oes semˆanticas propostas aqui. No entanto, a contribui¸c˜ao deste trabalho se concentra na capacidade de realizar todas essas verifica¸c˜oes sint´aticas e semˆanticas em uma ´unica ferramenta. Este trabalho foca a pluralidade de verifica¸c˜oes poss´ıveis em um processo, desde quest˜oes b´asicas de seu funcionamento, at´e complexas verifica¸c˜oes semˆanticas.
Como trabalhos futuros, h´a a necessidade de automa¸c˜ao na verifica¸c˜ao de quest˜oes ad-hoc por exemplo. Quest˜oes ad-hoc s˜ao verifica¸c˜oes feitas atrav´es de f´ormulas LTL testadas no Spin. Para isso ´e necess´ario formular corretamente essas restri¸c˜oes. Alguns exemplos, como ordena¸c˜ao de atividades, condicionamento de execu¸c˜ao de uma atividade com a execu¸c˜ao de outra, foram apresentados e podem ser usados apenas trocando as atividades em quest˜ao.
Apˆendice A
Descri¸c˜ao de Processos
A seguir a apresentado o c´odigo em PROMELA do processo de exemplo apresentado na se¸c˜ao 3.3. O processo representado pode ser visto na figura A.1. A representa¸c˜ao gr´afica pode ser revista aqui:
Figura A.1: Exemplo de processo de workflow.
/*---*/ /* Attribute declaration */ /*---*/ byte t0,t1,t2,t3,t4,t5,t6,t7,t8,t9; byte final_reached; byte exec_a,exec_b,exec_c,exec_d,exec_e,exec_f,exec_g; byte rejected,accepted; byte cost;
#define burst (cost>100)
/*---*/
/* Declara¸c~ao das atividades */
/*---*/ proctype A() { do :: (final_reached==1) -> break; :: (t0==1) -> atomic { /* precondition */ printf("EscolhaProduto\n"); 41
42 Apˆendice A. Descri¸c˜ao de Processos
t0=0; /* release preconsition */ t1=1;t2=1; /* effect */
exec_a=1; /* action executed */ cost=cost+20; /* cost updated */ }; od; } proctype B() { do :: (final_reached==1) -> break; :: (t1==1) -> atomic { /* precondition */ printf("VerificaCredito\n"); t1=0; /* release preconsition */ if /* effect */ :: t3=1;rejected=1; :: t4=1;accepted=1; fi;
exec_b=1; /* action executed */ cost=cost+20; /* cost updated */ }; od; } proctype C() { do :: (final_reached==1) -> break; :: (t2==1) -> atomic { /* precondition */ printf("ProdutoEstoque\n"); t2=0; /* release preconsition */ t5=1; /* effect */
exec_c=1; /* action executed */ cost=cost+20; /* cost updated */ }; od; } proctype D() { do :: (final_reached==1) -> break; :: (t5==1) -> atomic { /* precondition */ printf("EmbalaProduto\n"); t5=0; /* release preconsition */ t6=1; /* effect */
exec_d=1; /* action executed */ cost=cost+20; /* cost updated */ }; od; } proctype E() { do :: (final_reached==1) -> break;
:: (t4==1 && t6==1) -> atomic { /* precondition */ printf("RealizaVenda\n");
t4=0;t6=0; /* release preconsition */
t7=1; /* effect */
exec_e=1; /* action executed */ cost=cost+20; /* cost updated */ };
od; }
43 proctype F() { do :: (final_reached==1) -> break; :: (t3==1) -> atomic { /* precondition */ printf("CancelaCompra\n"); t3=0; /* release preconsition */ t8=1; /* effect */
exec_f=1; /* action executed */ cost=cost+30; /* cost updated */ }; od; } proctype G() { do :: (final_reached==1) -> break; :: (t7==1 || t8==1) -> atomic { /* precondition */ printf("TerminaCompra\n"); t7=0;t8=0; /* release preconsition */ t9=1; /* effect */
exec_g=1; /* action executed */ cost=cost+20; /* cost updated */ }; od; } init { /*---*/ /* Workflow initialization */
/* All variables should be initialized with 0 */ /*---*/ final_reached=0; t0=0;t1=0;t2=0;t3=0;t4=0;t5=0;t6=0;t7=0;t8=0;t9=0; exec_a=0;exec_b=0;exec_c=0;exec_d=0;exec_e=0;exec_f=0;exec_g=0; rejected=0;accepted=0; cost=0;
IS: /* Initial State */ t0=1;
printf("Start\n");
Body: /* Launching activities */ run A(); run B(); run C(); run D(); run E(); run F(); run G(); FS: /* Final State */ (t9==1) -> printf("End\n"); /*---*/ /* Workflow termination: */
/* Variable final_reached releases pending activities */ /*---*/
final_reached=1; }
Referˆencias Bibliogr´aficas
[1] Henry H. Bi and J. Leon Zhao. Applying propositional logic to workflow verification.
Information Technology and Management, 5(3):293–318, 2004.
[2] Christopher Walton Centre. Model checking multi-agent web services. 2004.
[3] Gerard J. Holzmann. The model checker SPIN. Software Engineering, 23(5):279–295, 1997.
[4] Gerard J. Holzmann. The model checker SPIN. Software Engineering, 23(5):279–295, 1997.
[5] G.J. Holzmann. An analysis of bitstate hashing. Formal Methods in Systems Design, 1998.
[6] G.J. Holzmann and D. Peled. An improvement in formal verification. Proc. FORTE
1994 Conference, 1994.
[7] M. Kamath and K. Ramamritham. Correctness issues in workflow management.
Distributed Systems Engineering Journal, Special issue on Workflow Management Systems, 3(4):213–221, 1996.
[8] C Karamanolis, D Giannakopoulou, J Magee, and S.M. Wheater. Model checking of workflow schemas. Enterprise Distributed Object Computing Conference, 2000.
EDOC 2000. Proceedings. Fourth International, pages 170–179, 2000.
[9] H. Li and Y. Yang. Dynamic checking of temporal constraints for concurrent work- flows. Electronic Commerce Research and Applications, 4(2):124–142, 2005.
[10] Yang Y. Li, H. and T.Y. Chen. Resource constraints analysis of workflow specifica- tions. Journal of Systems and Software, 73(2):271–285, 2004.
[11] Shiyong Lu, Arthur Bernstein, and Philip Lewis. Automatic workflow verification and generation. Theoretical Computer Science, 353(1-3):71–92, 2006.
46 REFER ˆENCIAS BIBLIOGR ´AFICAS
[12] S. Nakajima. Model-checking verification for reliable web service. Proc. of OOP-
SLA’02 Workshop on Object-Oriented Web Services, 2002.
[13] A. Puri and G.J. Holzmann. A minimized automaton representation of reachable states. Software Tools for Technology Transfer, 3(1), 1999.
[14] W. Sadiq and M.E. Orlowska. On Correctness Issues in Conceptual Modeling of Workflows, 1997.
[15] W M P van der Aalst. Structural characterizations of sound workflow nets. Com-
puting Science Reports, 1996.
[16] W M P van der Aalst. The application of petri nets to workflow management. The
Journal of Circuits, Systems and Computers, 8(1):21–66, 1998.
[17] W.M.P. van der Aalst. Woflan: A petri-net-based workflow analyzer. Systems Anal-
ysis - Modelling - Simulation, 35(3):345 - 357, 1999.
[18] W.M.P. van der Aalst. Verification of workflow nets. Application and Theory of Petri
Nets, volume 1248 of Lecture Notes in Computer Science, Springer, 2000.
[19] W.M.P. Van Der Aalst and A.H.M. Ter Hofstede. Verification of workflow task structures: A petri-net-based approach. Information Systems, 25(1):43–69, 2000. [20] W.M.P. van der Aalst and A.H.M. ter Hofstede. Verification of workflow task struc-
tures: A petri-net-based approach. Information Systems, 25(1):43 - 69, 2000. [21] Workflow Management Coalition. Workflow management coalition terminology and
glossary (wfmc-tc-1011). Technical report, 1996.
[22] Workflow Management Coalition. Workflow management coalition terminology and glossary (wfmc-tc-1011). Technical report, 1996.
[23] Shingo Yamaguchi, Munenori Yamaguchi, and Minoru Tanaka. A soundness veri- fication tool based on the spin model checker for acyclic workflow nets. The 23rd
International Technical Conference on Circuits/Systems, Computers and Communi- cations (ITC-CSCC 2008), 2008.
[24] Buyya R. Yu, J. and C.K. Tham. Qos-based scheduling of workflow applications on service grids. Proc. 1st IEEE International Conference on e-Science and Grid
REFER ˆENCIAS BIBLIOGR ´AFICAS 47
[25] J. Yu and R. Buyya. A novel architecture for realizing grid workflow using tu- ple spaces. Proc. 5th IEEE/ACM International Workshop on Grid Computing (GRID’04), 0:119–128, 2004.
[26] J. Yu and R. Buyya. A taxonomy of scientific workflow systems for grid computing.