net) tamb´em ´e, finalmente, pode-se afirmar que a nova IOWF-net aumentada apresen- tada na Figura 4.27 se tornou localmente e globalmente sound, e o cen´ario que levava a situa¸c˜ao de deadlock foi removido pela adi¸c˜ao da nova WorkFlow net CWF. Como ne- nhum outro cen´ario de deadlock apareceu, podemos afirmar que este modelo aumentado da IOWF-net apresentado na Figura 4.2 est´a livre de situa¸c˜oes de deadlock.
4.5
Resumo do m´etodo
Como primeiro passo do m´etodo foi encontrada a situa¸c˜ao de deadlock e os sif˜oes associa- dos a esta situa¸c˜ao. Em seguida, inseriu-se o controle supervis´orio nos sif˜oes encontrados impedindo-os de ficarem vazios. Ap´os isto, foi inclu´ıdo o lugar de controle na IOWF-net original e validado se realmente controlou a situa¸c˜ao de deadlock e se nenhuma outra situa¸c˜ao foi gerada. Por fim, foi identificado o invariante de lugar gerado pelo acr´escimo do lugar CP2 para verifica¸c˜ao de quais transi¸c˜oes que fariam parte da nova arquitetura com a inser¸c˜ao da WF-net de controle no modelo inicial, transformando-o num modelo aumentado e controlado. Para garantir que tudo estivesse correto, ou seja, que a ar- quitetura fosse realmente livre de bloqueio, a propriedade Soundness e a vivacidade da rede foram verificadas.
Do m´etodo proposto, foi apresentado o procedimento de detec¸c˜ao de deadlock nas WorkFlow nets interorganizacionais e mostrado que estas situa¸c˜oes de deadlock est˜ao relacionadas `as estruturas em forma de sif˜ao que se esvaziam. Tamb´em foi apresentado o procedimento de controle supervis´orio de sif˜oes para remover as situa¸c˜oes de deadlock e a valida¸c˜ao destes controladores quando inseridos no modelo inicial. Finalmente foi elaborado um modelo de arquitetura distribu´ıda livre de deadlock.
Podemos concluir que a hip´otese inicial foi validada. Ou seja, que as situa¸c˜oes de deadlock est˜ao relacionadas `a presen¸ca de estruturas chamadas sif˜oes que se esvaziam, ficando livre de fichas. Conclui-se tamb´em que o procedimento sistem´atico apresentado para a detec¸c˜ao e corre¸c˜ao dessas situa¸c˜oes nas IOWF-nets foi v´alido, e colaborou efetivamente para controlar a execu¸c˜ao do modelo impedindo-o de alcan¸car os estados de total travamento. E por ´ultimo, a constru¸c˜ao da arquitetura distribu´ıda por meio da inser¸c˜ao do controle com uma WF-net acrescentada ao modelo se mostrou eficiente e consideravelmente simples, o que facilita a utiliza¸c˜ao deste procedimento para outras IOWF-net.
Cap´ıtulo 5
Estudo de Caso
A ideia deste cap´ıtulo ´e apresentar a abordagem proposta no Cap´ıtulo 4 por meio de um estudo de caso aplicado a uma WorkFlow net interorganizacional (IOWF-net) com trˆes processos locais.
5.1
Apresenta¸c˜ao
A IOWF-net escolhida como estudo de caso ´e semelhante `a utilizada para apresentar o m´etodo no cap´ıtulo anterior e se diferencia basicamente pelo acr´escimo de uma terceira WF-net local (LWF-net NP), que se comunica por meio de lugares de comunica¸c˜ao ass´ıncrona com a LWF-net PC. Outros lugares e transi¸c˜oes tamb´em foram acrescentados no final de cada processo para receber a resposta da comunica¸c˜ao com NP. A IOWF-net que ser´a abordada neste estudo de caso ´e apresentada na Figura 5.1.
Na Figura 5.1, a LWF-net AU representa o processo do autor ao realizar a submiss˜ao de um projeto para avalia¸c˜ao de um comitˆe avaliador. O processo do autor resume-se em enviar o projeto, aguardar a confirma¸c˜ao do recebimento do projeto pelo comitˆe avaliador e aguardar resposta da avalia¸c˜ao do projeto. Se aprovado, o autor deve preparar a vers˜ao final e enviar novamente ao comitˆe; se reprovado ou receber alguma notifica¸c˜ao de rejei¸c˜ao, o autor deve aguardar at´e receber uma mensagem final do comitˆe e enfim, encerrar seu processo.
A LWF-net PC representa o processo do comitˆe avaliador. O processo do comitˆe compreende as atividades de receber o projeto, enviar o projeto para um avaliador externo, enviar uma notifica¸c˜ao de recebimento ao autor, avaliar o projeto, comunicar ao autor e ao avaliador externo se o projeto foi aceito, rejeitado ou se n˜ao h´a mais
Figura 5.1: IOWF-net com trˆes processos locais: AU, PC e NP.
tempo para public´a-lo, receber a vers˜ao final do autor, receber uma notifica¸c˜ao final do avaliador externo e finalizar o processo.
O novo processo acrescentado ao se fazer uso da LWF-net NP pode ser interpretado como um complemento ao processo de avalia¸c˜ao. Por exemplo, uma avalia¸c˜ao externa contratada pelo comitˆe avaliador. Desta forma, quando o projeto ´e enviado por AU e recebido por PC, este o envia a NP por meio do lugar de comunica¸c˜ao ass´ıncrono AC, que o analisa (np1) e devolve como resposta `a PC a informa¸c˜ao (AC2); por exemplo, uma informa¸c˜ao que especifica se o projeto est´a nos padr˜oes exigidos pela conferˆencia. Ap´os isso, NP fica aguardando o resultado da avalia¸c˜ao do projeto (np2) pelo comitˆe. Terminada a avalia¸c˜ao, se o projeto for rejeitado por PC, uma notifica¸c˜ao ´e enviada ao autor (reject) e outra ao NP (AC3). Caso o projeto seja aceito e uma vers˜ao final for entregue ao PC, uma notifica¸c˜ao ´e enviada a NP (AC4) junto `a vers˜ao final do projeto. Se o projeto for recebido tardiamente e o comitˆe n˜ao for mais public´a-lo, NP ´e
5.2. Verifica¸c˜ao das propriedade Soundness e vivacidade 125