Verificação formal de workflows com spin

(1)

(2)

FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DO IMECC DA UNICAMP Bibliotecária: Maria Fabiana Bezerra Müller – CRB8 / 6162

André, Amaury Bosso

An25v Verificação formal de workflows com spin/Amaury Bosso André-- Campinas, [S.P. : s.n.], 2010.

Orientador : Jacques Wainer.

Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação.

1.Fluxo de trabalho. 2. Métodos formais (Ciência da computação). 3.Modelos spin. 4.PROMELA . I. Wainer, Jacques. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título.

Título em inglês: Formal workflow verification with spin

Palavras-chave em inglês (Keywords): 1.Workflow. 2. Formal methods (Computer science). 3. Spin models. 4. PROMELA.

Área de concentração: Inteligência artificial, Verificação e Validação Titulação: Mestre em Ciência da Computação

Banca examinadora: Prof. Dr. Jacques Wainer (IC – UNICAMP) Profa. Dra. Lucinéia Heloisa Thom (Inf – UFRGS) Prof. Dr. Arnaldo Vieira Moura (IC - UNICAMP)

Data da defesa: 21/06/2010

(3)

(4)

Instituto de Computa¸c˜ao Universidade Estadual de Campinas

Verifica¸

c˜

ao formal de Workflows com Spin

Amaury Bosso Andr´

e

1

Maio de 2010

Banca Examinadora:

• Jacques Wainer (Orientador) • Lucin´eia H. Thom

• Arnaldo Moura • Maria Beatriz Toledo • Duncan D. Ruiz

1

Suporte financeiro de: Bolsa da FAPESP (processo 07/57995-3) 2008–2010

(5)

Resumo

O gerenciamento de workflows é uma realidade atualmente, mas os sistemas atuais care-cem de suporte à verifica¸cão de corre¸cão em modelos de workflow. Este trabalho visa a realiza¸cão de verifica¸cões em processos, objetivando a deteçcão de erros sintáticos, como a existência de atividades mal modeladas, ou seja, sem condi¸cões de entrada ou de sa´ıda. ´

E objetivo deste trabalho também a defini¸cão de verifica¸cões de ordem estrutural, como detectar se o processo de workflow não possui deadlocks (estado em que o processo trava sem possibilidade de progredir), ou verificar se existem atividades mortas no processo (atividades imposs´ıveis de serem executadas), ou se há termina¸cões incompletas, ou seja, transi¸cões pendentes após o processo ter atingido seus objetivos.

Além de verifica¸cões sintáticas e estruturais, é necessário também a realiza¸cão de veri-fica¸cões semânticas do modelo, ou seja, é importante que os processos possam ser validados quanto a caracter´ısticas que dizem respeito à sua organiza¸cão lógica, a um n´ıvel um pouco mais alto de informa¸cão do que simplesmente estrutural. Por exemplo, é diretamente im-pactante na qualidade do modelo de um processo, definir se este possui conflitos ao acesso de recursos. Dessa forma, um processo estruturalmente correto, pode ficar travado em um deadlock, devido à concorrência quanto ao acesso de um recurso comum entre atividades distintas. Além disso, verifica¸cões de restri¸cões de custo, por exemplo, também podem inviabilizar um processo. Todas essas verifica¸cões são importantes para decidir se um processo de workflow é correto.

A maior contribui¸cão deste trabalho, é então a defini¸cão de uma modelagem de pro-cessos de workflow que possibilite a verifica¸cão de problemas sintáticos, estruturais e semânticos, todos em uma única ferramenta, que se mostra escalável para processos reais, além de possibilitar a verifica¸cão de questões ad-hoc, espec´ıficas de cada instância, como verificar ordena¸cões entre atividades espec´ıficas, etc.

(6)

Abstract

Workflow management is a reality nowadays, but today’s systems give very little support to verify correctness in workflow models. This work aims to perform formal verification, with the goal of detecting syntactic errors, like the existence of activities poorly modeled, in other words, activities with no precondition or effect. It is a goal too, the definition of workflows structural verification, as to detect if the process does not have deadlocks (state in which the process is stuck with no possibility of getting any further), or verifying if there are dead activities in the process (activities impossible to be reached), or if exist incomplete terminations, ie, pending transitions after the process reached its objectives.

Besides syntactic and structural verifications, it is necessary too, to perform semantic verifications in the process, in other words, it is important to validate the processes in respect to characteristics of its logical organization, in a higher level of information than simply structural verification. For example, it is directly impacting in the quality of the process model the definition if it has resource access conflicts. In this way, a process that is structurally correct, can be stuck in a deadlock, due to the concurrency in the access of a common resource of distinct activities. Besides that, verifications of costs restrictions, for example, can spoil a process. All these verifications are important to decide if a workflow model is correct.

The main contribution of this work is the definition of workflow processes modeling that makes it possible to perform syntactic, structural and semantic verifications, all in a unique tool, that is showed to be scalable for real process, and even possible to verify ad-hoc questions, specific to the model, as checking activities ordering, for example.

(7)

Agradecimentos

Gostaria de agradecer o apoio de meus familiares e amigos, com quem sempre pude contar, e agradecer meu orientador, pelos caminhos abertos em minha vida acadˆemica e profissional.

(8)

Sum´

ario

Resumo vii Abstract ix Agradecimentos xi 1 Introdu¸cão 1 1.1 Objetivos . . . 2 1.1.1 Verifica¸cão Estrutural . . . 2 1.1.2 Verifca¸cão de Recursos . . . 2

1.1.3 Verifca¸c˜ao de Restri¸c˜oes de Custo . . . 3

1.2 Proposta . . . 3 1.3 Trabalhos relacionados . . . 4 1.4 Estrutura da disserta¸c˜ao . . . 5 2 Principais Fundamentos 7 2.1 Workflow . . . 7 2.1.1 Estado . . . 7 2.1.2 Atividade . . . 7 2.1.3 Transi¸c˜ao . . . 8 2.1.4 Recurso . . . 9

2.1.5 Estado inicial e Objetivo . . . 9

2.2 Promela . . . 10 2.3 Lógica LTL . . . 12 2.3.1 Operadores básicos . . . 12 2.3.2 Operadores temporais . . . 13 2.4 Spin . . . 14 2.4.1 Caminhada aleatória . . . 14 2.4.2 Caminhada Iterativa . . . 14 2.4.3 Explora¸cão exaustiva . . . 14 xiii

(9)

2.4.4 Utiliza¸cão . . . 15 3 Verifica¸cão de Workflows 17 3.1 Modelagem . . . 17 3.1.1 Transi¸cão sequencial . . . 18 3.1.2 Transi¸cão paralela . . . 19 3.1.3 Transi¸cão Condicional . . . 19 3.1.4 Transi¸cão Iterativa . . . 21 3.2 Verifica¸cão Estrutural . . . 22

3.2.1 Atividades sem condi¸c˜oes de entrada ou sa´ıda . . . 22

3.2.2 Deadlock . . . 23

3.2.3 Termina¸c˜ao Completa . . . 25

3.3 Quest˜oes Ad-hoc . . . 26

3.4 Verifica¸c˜ao de Recursos . . . 29

3.5 Verifica¸c˜ao de Restri¸c˜oes de Custo . . . 30

3.6 Relaxa¸cão do critério de Termina¸cão Completa . . . 32

3.7 Compara¸c˜ao de Desempenho . . . 33

4 Conclus˜oes 39

A Descri¸c˜ao de Processos 41

Bibliografia 44

(10)

Cap´ıtulo 1

Introdu¸

c˜

ao

A necessidade de se manterem competitivas no mercado trouxe à tona para as empresas a carência de documenta¸cão, comunica¸cão e transferência de conhecimento, assim como a necessidade de uma profunda e objetiva modelagem de seus processos de negócio mais importantes. Além disso, nos últimos anos, a automa¸cão de processos tem se tornado uma constante, objetivando a redu¸cão de custos, de tempo de execu¸cão e aumento na confiabilidade de processos. Segundo a WfMC [21], a automa¸cão do processo de negócio, na sua totalidade ou em partes, onde documentos, informa¸cões ou tarefas são passadas de um participante para o outro para execu¸cão de uma a¸cão, de acordo com um conjunto de regras de procedimentos, define um workflow. A WfMC define também os WFMS (Workflow Management Systems), sistemas que definem, gerenciam e executam work-flows, fornecendo maior automa¸cão para os processos de negócios. Consequentemente, as empresas passaram a ter maior aten¸cão na modelagem e coordena¸cão de seus processos, com maior ênfase a verifica¸cão e corre¸cão de suas rotinas mais impactantes.

Processos de negócio tem tomado grandes propor¸cões dentro das empresas, crescendo em tamanho e complexidade. Com isso a probabilidade de ocorrência de erros aumenta, e um processo mal projetado pode causar grandes perdas financeiras, retrabalho, problemas legais, problemas gerenciais, etc. Para evitar esses problemas, é necessário fazer uma verifica¸cão da corre¸cão de processos de workflow antes deles se tornarem operacionais. A maioria dos sistemas comerciais checam erros sintáticos em workflows, como a não existência de transi¸cões de entrada ou sa´ıda em atividades. No entanto, verifica¸cões mais complexas devem ser realizadas, e os sistemas de gerenciamento de workflows ainda não são capazes de tratar verifica¸cões sofisticadas, por exemplo: checar se um processo eventualmente termina, ou seja, se não há deadlocks, se um trace de execu¸cão é poss´ıvel, se não há atividades inating´ıveis em qualquer instância do processo, entre outros, são valida¸cões importantes não tratadas nos sistemas atuais de gerenciamente de workflows [8].

(11)

2 Cap´ıtulo 1. Introdu¸c˜ao

Apesar de um grande passo, verificar a ausência da possibilidade de deadlock e de tarefas mortas, são verifica¸cões que dizem respeito somente a parte sintática do processo. Verifica¸cões ainda mais sofisticadas, que dizem respeito a semântica do processo deve-riam ser tratadas. Semântica envolve ordena¸cão de atividades, concorrência por recursos, verifica¸cão de restri¸cões tang´ıveis, como limites de custo por exemplo. Todos esses aspec-tos comprometem a corre¸cão e viabilidade de processos, porém são pouco abordados nas ferramentas de verifica¸cão existentes. O objetivo principal deste trabalho é oferecer o fer-ramental necessário para a verifica¸cão de critérios sintáticos em workflows, mas também de critérios semânticos, que permitam uma análise muito mais completa de corre¸cão do processo, mas também de adequa¸cão a limites previamente estabelecidos como de custo, de acesso a recursos, ou seja, restri¸cões sempre presentes num processo real.

1.1 Objetivos

A seguir, é apresentada uma descri¸cão breve dos objetivos, organizados em tópicos, abor-dados no decorrer do texto.

1.1.1 Verifica¸

c˜

ao Estrutural

A verifica¸cão de estrutura aborda as principais inconsistências de Workfows, como dead-locks, falta de sincronismo, uso incorreto de estruturas, objetivos pendentes (ou ter-mina¸cão incompleta) e atividades mortas. As principais referências na proposta de solu¸cões para essa classe de problemas são os trabalhos de Van der Aalst [16, 15, 19, 18, 20].

1.1.2 Verifca¸

c˜

ao de Recursos

Outro assunto importante na verifca¸cão de Workfows é o que diz respeito a conflitos de recursos entre atividades distintas. Ou seja, entre atividades de um mesmo workflow ou de workflows diferentes, deve-se evitar que haja competi¸cão pelo mesmo recurso, que pode ser um documento, dados, máquinas ou até mesmo pessoas.

Assim, uma distin¸cão é levada em considera¸cão: a presen¸ca de recursos que sejam compartilháveis, e recursos exclusivos. Por exemplo, a informa¸cão de um documento pode ser compartilhada entre atividades concorrentes, no entanto, a altera¸cão dessa in-forma¸cão não pode ser permitida a múltiplas atividades ao mesmo tempo, possibilitando a ocorrência de “race conditions”.

(12)

1.2. Proposta 3

1.1.3 Verifca¸

c˜

ao de Restri¸

c˜

oes de Custo

Em processos de workflow reais, há normalmente uma restri¸cão de or¸camento, seja para o processo como um todo, ou para etapas do processo. Dessa forma, é necessária a verifica¸cão de restri¸cões de custo a fim de checar se os processos podem cumprir as limita¸cões de or¸camento previamente definidas. Alguns processo podem ter várias re-stri¸cões expl´ıcitas, inclusive rere-stri¸cões de custo atividade a atividade, enquanto outros processos apenas uma restri¸cão global.

Na literatura não são muitos trabalhos que lidam com a verifica¸cão de custo, porém há alguns avan¸cos importantes como em [25, 24, 26].

1.2 Proposta

Uma proposta de verifica¸cão formal de workflows foi desenvolvida neste trabalho, usando um model checker (verificador de modelos) chamado Spin. Para isso, a modelagem do pro-cesso de workflow é traduzida para o PROMELA (Process Meta Language), a linguagem utilizada no verificador. Para isso, um processo modelado em XPDL por exemplo, tem de passar por uma ferramenta de tradu¸cão, para ser convertido para o Promela. Os principais elementos dessa linguagem serão descritos nas se¸cões que se seguem, assim a conversão entre as linguagens é meramente um trabalho de tradu¸cão direta. Para este trabalho foi desenvolvida uma ferramenta de conversão entre o XPDL e o Promela. Como desen-volvimento futuro, pretende-se extender essa ferramenta para converter também processos modelados em BPMN. A estrutura do sistema proposto pode ser visto na figura 1.1.

Figura 1.1: Estrutura de modelagem de processos.

A proposta visa a realiza¸cão de verifica¸cões sintáticas, como checar a corre¸cão de ativi-dades quanto as suas precondi¸cões e efeitos (transi¸cões de entrada e sa´ıda), realizar veri-fica¸cões estruturais, como a ausência de deadlocks e tarefas mortas, além de veriveri-fica¸cões

(13)

4 Cap´ıtulo 1. Introdu¸c˜ao

de questões semânticas, como a checagem de questões ad-hoc de natureza espec´ıfica do problema, verifica¸cão de conflitos ao acesso de recursos, verifica¸cão de restri¸cões de custo, além da relaxa¸cão do critério de termina¸cão completa.

O foco do trabalho está na pluralidade e complexidade de verifica¸cões poss´ıveis em modelos de workflow, ao invés de grandes ganhos em eficiência. Porém, o Spin é notoria-mente uma ferramenta de model checking que possui um bom desempenho, mesmo para modelos grandes, como mostram alguns trabalho da literatura [23]. Uma compara¸cão também é realizada neste trabalho, levando em conta as mesmas funcionalidades (veri-fica¸cões estruturais apenas) entre a modelagem desenvolvida e o Woflan [17], principal verificador de workflows utilizado, e mais citado da literatura.

1.3 Trabalhos relacionados

Como descrito anteriormente, este trabalho visa a aplica¸cão de um model checker na verifica¸cão de workflows, porém, na literatura, outras linhas relevantes de pesquisas que atacam o mesmo problema de verifica¸cão, são propostas. Assim, algumas das linhas mais relevantes nesta área de verifica¸cão de workflows são apresentados nesta se¸cão.

A primeira linha de pesquisa busca relacionar a verifica¸cão de workflows com a veri-fica¸cão de corre¸cão em transa¸cões de banco de dados, aplicando o critério ACID (atomici-dade, consistência, isola¸cão e durabilidade) de forma relaxada para modelos de workflow. Do ponto de vista de banco de dados, workflows são tratados como transa¸cões de longa dura¸cão, dessa forma, o critério ACID pode ser aplicado tanto para falhas do sistema e falhas lógicas. Esse esquema é utilizado em [7], e diz respeito a workflows transacionais somente, e pesquisas adicionais devem ser feitas para incorporar objetos e execu¸cões não transacionais.

Uma abordagem diferente é usada por Van der Aalst em seus trabalhos [16, 15, 19, 18, 20]. Neles essencialmente uma verifica¸cão de três propriedades é feita: ausência de deadlocks, de livelocks e de termina¸cão completa. Para isso, o modelo de workflow é traduzido para um tipo particular de redes de Petri, a WorkFlow Net, ou simplesmente WF-net, utilizada para a verifica¸cão através do Woflan [17]. A ausência de deadlocks é a propriedade que nenhuma poss´ıvel execu¸cão do workflow resulta na situa¸cão onde nenhuma atividade pode ser executada, antes do workflow ter terminado. Termina¸cão completa descreve a situa¸cão quando um dos ramos de execu¸cão do workflow atinge o fim do processo, e não sobram atividades em execu¸cão [18].

Os outros artigos abordam mais questões sobre o sequenciamento das atividades no modelo do processo (usando várias defini¸cões de como o processo é representado) e pro-priedades dessas sequências. Por exemplo, [11] trata apenas de modelos de representa¸cão de processos balanceados, onde os OR-split/join estão no escopo de AND-split/join e vice

(14)

1.4. Estrutura da disserta¸c˜ao 5

versa, e verifica apenas algumas propriedades triviais nesses modelos. (Sendo justo com os autores, a enfase do artigo é na gera¸cão automática de workflows, e não na verifica¸cão). [14] apresenta algumas defini¸cões de corre¸cão que podem ser verificadas sintaticamente nos modelos de workflows, como por exemplo, o uso de AND ou OR-joins com apenas um arco de chegada, ou splits com apenas um arco de sa´ıda, etc.

Em [1] é apresentado um framework teórico para a aplica¸cão de lógica proposicional na verifica¸cão de workflows. Através disso, é poss´ıvel detectar anomalias nos modelos de workflow. Ele mapeia workflows ac´ıclicos em expressões lógicas e propriedades de corre¸cão são verificadas por um provador automático de teoremas.

Por fim, outra linha de verifica¸cão é através de model checkers, ou verificadores de modelos, e um número crescente de trabalhos vêm relacionando este tipo de verifica¸cão com workflows e web services, como em [12, 2, 23]. Neles o Spin é utilizado, mas somente para verifica¸cão estrutural. Em [2] a verifica¸cão é aplicada em web-services multi agentes, em [12] como um verificador da semântica comportamental da linguagem BPEL4WS, e em [23] uma compara¸cão é realizada entre o Spin e o Woflan.

1.4 Estrutura da disserta¸

c˜

ao

No cap´ıtulo 2 são apresentados os fundamentos principais abordados neste trabalho, como a apresenta¸cão dos conceitos relacionados a Workflow na se¸cão 2.1, a linguagem utilizada o Spin, o PROMELA, na se¸cão 2.2, e uma breve descri¸cão de fórmula¸cões em LTL (Lógica Temporal Linear) na se¸cão 2.3, fórmulas necessárias para verifica¸cões mais complexas. Ainda, é apresentado na se¸cão 2.4 uma descri¸cão do Spin, o verificador utilizado neste trabalho.

Feita a apresenta¸cão dos fundamentos básicos deste trabalho, o cap´ıtulo 3 descreve as verifica¸cões de workflow, de acordo com os objetivos tra¸cados na se¸cão 1.1. Para tanto, primeiramente é descrita a modelagem de processos de workflows em PROMELA, na se¸cão 3.1. Uma vez modelado o processo, então são apresentados os métodos de verifica¸cão propostos, dividos nas se¸cões que se seguem. Além dos procedimentos de verifica¸cão, é apresentada uma argumenta¸cão quanto ao critério de termina¸cão completa e sua relaxa¸cão neste trabalho, na se¸cão 3.6.

Por fim, alguns teste são apresentados com o intuito de comparar o desempenho do verificador proposto com o Woflan, na se¸cão 3.7, além das conclusões do trabalho, no cap´ıtulo 4.

(15)

Cap´ıtulo 2

Principais Fundamentos

2.1 Workflow

A WfMC é uma organiza¸cão global engajada no desenvolvimento de Workflow e na Mod-elagem de Processos de Negócios (do inglês, Business Process Modeling - BPM). Segundo a WfMC (Workflow Management Coalition) [22], Workflow é a automa¸cão de processos de negócio, na sua totalidade ou em partes, onde documentos, informa¸cões ou tarefas são passadas de um participante para o outro, de acordo com um conjunto de regras e procedimentos para atingir um objetivo de negócio.

Um Workflow consiste em uma sequência de passos conectados, ou seja, uma sequência de opera¸cões, que pode ser o trabalho de uma pessoa, de um grupo de pessoas, ou de uma organiza¸cão. Dessa forma, um workflow pode ser tratado como a execu¸cão de uma ordem parcial de tarefas de um processo de negócio. A seguir, os principais elementos de um workflow são relatados e brevemente descritos.

2.1.1 Estado

Estado é a representa¸cão das condi¸cões internas que define o status do processo em um certo momento no tempo. Conforme a execu¸cão do processo avan¸ca, ele segue uma série de transi¸cões entre estados, e o conjunto completo de estados e transi¸cões define o com-portamento interno, assim como todas as possibilidades de execu¸cão que um processo pode seguir.

2.1.2 Atividade

´

E a descri¸cão de uma por¸cão de trabalho que corresponde a um passo lógico e indivis´ıvel dentro de um processo. Uma atividade é definida pelos requisitos que são necessários para

(16)

8 Cap´ıtulo 2. Principais Fundamentos

que ela possa ser executada, ou seja, suas precondi¸cões, e os resultados de sua execu¸cão, ou seja, seus efeitos. Precondi¸cões e efeitos definem as transi¸cões de entrada e sa´ıda da atividade, através de controles de fluxo, como definidas no tópico a seguir.

2.1.3 Transi¸

c˜

ao

Transi¸cões definem o encadeamento de atividades em um processo, controlando assim o fluxo de execu¸cão das atividades. Existem quatro tipos de transi¸cões entre estados e atividades, como pode ser visto na figura 2.1 .

Figura 2.1: Transi¸c˜oes.

Sequencial

Uma transi¸cão sequencial é caracterizada quando atividades são executadas uma direta-mente após a outra. Na figura 2.1.a, a atividade B é executada sodireta-mente depois que a tarefa A é terminada.

Paralela

Transi¸cões paralelas acontecem quando duas ou mais atividades são iniciadas concor-rentemente após a execu¸cão de uma atividade. Na figura 2.1.b, as atividades B e C são executadas em paralelo, ou seja, B e C são executadas ao mesmo tempo, ou em qualquer ordem. Para modelar uma transi¸cão paralela, dois blocos são definidos: AND-split e AND-join. O AND-split habilita as atividades B e C a serem executadas após o término da atividade A, enquanto o AND-join sincroniza o fluxo de execu¸cão, esperando o término dos ramos de entrada para depois somente liberar a execu¸cão da próxima atividade. No exemplo da figura 2.1.b, a atividade A possui um AND-split e a atividade D possui um AND-join.

(17)

2.1. Workflow 9

Condicional

A trasi¸cão condicional é utilizada quando há a necessidade de escolha entre dois ou mais fluxos a se seguir. Na figura 2.1.c, após o término da atividade A, ou a atividade B ou a C será executada. Da mesma forma que para transi¸cões paralelas, para modelar as transi¸cões condicionais são necessários dois blocos: OR-split e OR-join. O bloco OR-split define qual dos dois fluxos de execu¸cão será escolhido, na figura 2.1.c, entre as atividades B ou C, e o bloco OR-join libera a execu¸cão do fluxo que se segue quando pelo menos um dos dois ou mais fluxos que o precedem for verdadeiro. No exemplo da figura 2.1.c, há um OR-split após a atividade A e um OR-join antes da atividade D.

No contexto deste trabalho, o OR-split é modelado como um ou-exclusivo, ou seja, após a atividade A, ou a atividade B ou a C será executada, mas não ambas. Assim, consideraremos o bloco de controle split, como na verdade, um Xsplit. O OR-join, no entanto, não tem essa mesma restri¸cão para esse trabalho, podendo ser ativado por um, ou mais fluxos de execu¸cão.

Iterativa

Transi¸cões iterativas são usadas quando é necessário executar a mesma tarefa, ou o mesmo grupo de tarefas, múltiplas vezes. Na figura 2.1.d, a tarefa B é executada uma ou mais vezes.

2.1.4 Recurso

Recursos são definidos como entidades associadas a workflows, e requeridas em tempo de execu¸cão para auxiliar na execu¸cão de uma ou mais atividades. Consideraremos recursos como dados, informa¸cões, documentos, máquinas ou pessoas.

2.1.5 Estado inicial e Objetivo

Além dos elementos descritos anteriormente, ainda fazem parte da modelagem de workflow a defini¸cão do Estado inicial e do Objetivo do processo que definem, respectivamente, as condi¸cões de inicializa¸cão do processo e o estado desejado após o seu encerramento. Resumo

Um workflow, então, define um processo através dos objetivos de negócio que ele satisfaz, das condi¸cões iniciais, ou seja, de um retrato do estado em que as variáveis utilizadas no processo se encontram antes do in´ıcio da execu¸cão, e através das atividades, que transformam o estado inicial em estados transitórios, até que, dada uma sequência de

(18)

transi¸cões, atinja o objetivo desejado, independente das circunstâncias enfrentadas e das escolhas tomadas no decorrer da execu¸cão. Isso é o que se espera de um processo de workflow correto e bem modelado.

2.2 Promela

PROMELA, abrevia¸cão para Process Meta Language, é uma linguagem de modelagem de processos que permite definir a cria¸cão dinâmica de processos concorrentes, de forma que, dado um programa em PROMELA, é poss´ıvel usar um verificador simbólico para determinar a sua corre¸cão.

Programas em PROMELA são constitu´ıdos por processos, canais de mensagens e variáveis. Processos são objetos globais que podem ser executados concorrentemente. Canais de mensagens e variáveis podem ser globais ou declarados localmente, dentro de um processo.

O estado de uma variável ou de um canal de mensagem só pode ser alterado por um processo. O processo é definido em PROMELA através da seguinte declara¸cão:

proctype A() { estado = 3; }

No exemplo anterior, ´e declarado um processo A, que altera o valor de uma vari´avel

estado.

O processo é declarado através de um proctype, mas não executado. No in´ıcio, somente um processo é executado, o processo declarado como init. E a partir dele, os outros processos podem ser chamados. Para isso, é necessário utilizar o comando run, como no exemplo a seguir:

init { run A(); }

Como descrito anteriormente, os processos podem ser executados concorrentemente, e assim suas instru¸cões internas podem ser intercaladas. Para evitar que isso aconte¸ca, ou seja, para indicar que uma sequência de instru¸cões seja executada sem intercala¸cões, como uma unidade indivis´ıvel, deve-se usar o comando atomic, e entre chaves as instru¸cões que devem ser atômicas, como por exemplo:

atomic { instru¸c~oes; }

(19)

2.2. Promela 11

Além das defini¸cões anteriores, são parte da linguagem os controladores de fluxo, como condicionais, repeti¸cões e implica¸cões.

Uma implica¸cão condiciona a continuidade do fluxo de execu¸cão. Por exemplo, a instru¸cão a seguir será executada somente se o valor da variável estado for igual a 1, e caso contrário, o processo fica travado.

proctype B() {

(estado==1) -> estado=2; }

O comando condicional apresentado a seguir seleciona qual fluxo a execu¸cão do pro-cesso deve tomar. Os fluxos são definidos com dois pontos duplos antes da instru¸cão ou conjunto de instru¸cões. E a escolha é feita de forma não determin´ıstica. Por exemplo:

proctype C() { if :: estado = 1; :: estado = 2; fi }

Na defini¸cão anterior, após a execu¸cão do processo C, o valor da variável estado pode ser 1 ou 2, devido ao fato da escolha ser não-determin´ıstica.

O ´ultimo controlador de fluxo define repeti¸cões, e é definido através do comando do, através da estrutura exemplificada a seguir:

proctype D() { byte estado = 0; do :: estado = estado + 1; :: (estado==3) -> break; od }

Assim como o comando condicional, a estrutura de repeti¸cão do PROMELA seleciona uma op¸cão de fluxo somente para execu¸cão a cada itera¸cão. Para terminar a repeti¸cão o comando break é utilizado. Assim, no exemplo anterior, a cada repeti¸cão um dos dois fluxos poss´ıveis é selecionado não-deterministicamente, até que a condi¸cão de termina¸cão seja satisfeita. Note que para o exemplo anterior, é poss´ıvel que essa condi¸cão nunca seja satisfeita: suponha que por mais de três vezes o fluxo escolhido seja o primeiro. Mesmo que o segundo fluxo seja escolhido posteriormente, jamais o valor da variável estado será três novamente. Este é apenas um exemplo da complexidade que esta modelagem pode atingir.

(20)

Resumo

Os principais elementos de PROMELA foram apresentados nesta se¸c˜ao. No entanto de-scri¸c˜oes muito mais detalhadas podem ser obtidas em manuais online123_{. As estruturas}

ap-resentadas nesta se¸cão serão as utilizadas neste trabalho para a modelagem de atividades e processos de workflows, como pode ser visto nas se¸cões que se seguem, principalmente na se¸cão 3.1.

2.3 L´

ogica LTL

A lógica temporal denominada LTL (Linear Temporal Logic) utiliza proposi¸cões atômicas, operadores booleanos e operadores temporais para construir fórmulas que fazem referência a uma ordena¸cão total de eventos. Com ela, é poss´ıvel verificar se propriedades serão verdadeiras eventualmente em algum momento do futuro, ou se uma condi¸cão é verdadeira até que outro fato se torne verdadeiro, etc.

Formula¸cões em LTL são utilizadas para diversas verifica¸cões em processos de work-flows. Algumas delas estruturais, mas a maioria das formula¸cões visam a verifica¸cão de questões semânticas do processo, como ordena¸cões impróprias, concorrências indevidas, precedência, entre várias outras possibilidades relatadas no cap´ıtulo de verifica¸cões deste texto.

Para isso, são apresentados aqui os operadores e suas funcionalidades na defini¸cão de fórmulas LTL.

2.3.1 Operadores b´

asicos

Os operadores básicos, são os operadores de AND e OR lógicos, além de implica¸cão lógica, equivalência e nega¸cão. Esses operadores são representados através dos seguintes s´ımbolos:

1. (x && y) AND 2. (x || y) OR

3. (x -> y) implica¸c~ao lógica 4. (x <-> y) equivalência lógica 5. (!x) nega¸c~ao

A utiliza¸cão desses operadores para verifica¸cão segue o uso comum, por exemplo: a primeira fórmula, com AND lógico, é verdadeira se todos os termos da expressão forem verdadeiros, ou seja se as variáveis x e y são ambas verdadeiras. Para a segunda fórmula,

1 http://spinroot.com/spin/Man/promela.html 2 http://www.dai-arc.polito.it/dai-arc/manual/tools/jcat/main/node168.html 3 http://cnx.org/content/m12318/latest/

(21)

2.3. L´ogica LTL 13

com o OR lógico, basta um termo ser verdadeiro para a expressão também ser verdadeira (a variável x ou a variável y).

A terceira fórmula é definida verdadeira, caso a variável x seja verdadeira e a variável y também seja verdadeira, ou seja: a veracidade da primeira variável implica que a segunda também seja verdadeira, ou caso a variável x seja falsa. Para uma equivalência lógica, no entanto, além de uma implica¸cão entre a variável x e y, é necessário também que a rec´ıproca seja verdadeira, ou seja, que haja uma implica¸cão entre y e x, ou seja, que as variáveis tenham os mesmo valor lógico.

O operador nega¸cão inverte o valor lógico da variável, assim a fórmula 5 é verdadeira caso a variável x seja falsa.

2.3.2 Operadores temporais

Além dos operadores básicos, são definidos operadores temporais na formula¸cão LTL. Os s´ımbolos que definem esses operadores são apresentados a seguir.

1. ()x seguinte 2. <>x eventualmente

3. []x sempre

4. x U y verdade at´e 5. x R y falso ap´os

Uma fórmula com o operador seguinte é verdadeira se uma condi¸cão é verdadeira no estado seguinte, por exemplo, a fórmula 1 é verdadeira, se no próximo estado a variável x for verdadeira. Já a fórmula 2, com o operador eventualmente, é verdadeira se a variável x é verdadeira agora ou em algum momento posterior, não necessariamente o próximo. Para a fórmula 3, com o operador sempre, o princ´ıpio é o mesmo, no entanto a formula é verdadeira somente se a variável x for verdadeira para o estado atual e todos os estados seguintes.

Os operadores verdade até e falso após, ao contrário dos operadores anteriores, são binários, ou seja, são definidos para dois termos. A fórmula 4, com o operador verdade

até, é definida verdadeira se a variável x for verdade pelo menos até o estado em que y se

torne verdadeira. No entanto, para a fórmula 5 ser verdadeira, a variável x deve deixar de ser verdadeira a partir do momento em que a variável y se torne verdadeira.

Resumo

Com os operadores temporais em conjunto com os operadores básicos é poss´ıvel formular restri¸cões com rela¸cão ao tempo para atividades dentro de um processo de workflow. Dessa forma, a capacidade de verifica¸cão pode ser estendida para além de verifica¸cões sintáticas ou estruturais. Para isso, fórmulas LTL serão usadas como pode ser visto adiante no cap´ıtulo 3, onde as verifica¸cões de processos de workflows são descritas.

(22)

2.4 Spin

Processos definidos em PROMELA podem ser analizados com o SPIN (Simple PROMELA Interpreter) [3], um verificador formal open-source bastante difundido, para verificar se o sistema modelado produz o comportamento desejado.

Dado um programa em PROMELA, o SPIN verifica a corre¸cão do modelo através de três tipos de abordagens: caminhada aleatória pelos traces de execu¸cão, caminhada interativa, ou explora¸cão exaustiva de todos os traces. A verifica¸cão exaustiva é executada através da gera¸cão de um programa em código C, gerado a partir do modelo descrito em PROMELA. As verifica¸cões realizadas pelo Spin têm por finalidade checar e existência de deadlocks no modelo e trechos de código não ating´ıveis.

A seguir cada uma das abordagens de verifica¸c˜ao poss´ıveis no Spin s˜ao explicadas com um pouco mais de detalhes.

2.4.1 Caminhada aleat´

oria

Um processo definido em PROMELA pode ser representado também por uma árvore com-putacional, de forma que diferentes traces de execu¸cão representam diferentes caminhadas na árvore. Em uma caminhada aleatória, o Spin aleatoriamente toma um caminho em um ponto de escolha. Em cada bifurca¸cão da árvore computacional, o Spin decide qual fluxo seguir, gerando um trace de execu¸cão aleatório. Note que neste modo, algumas vezes o Spin pode encontrar um erro, mas na maioria das vezes não.

2.4.2 Caminhada Iterativa

A caminhada iterativa se assemelha a aleatória, com a diferen¸ca de que a responsabilidade de escolher qual fluxo seguir nos pontos de escolha é transferida ao usuário. Dessa forma, o Spin pode ser guiado em dire¸cão ao erro, mas isso requer um conhecimento a priori da falha, ou pelo menos que o usuário reconhe¸ca onde é mais provável que o erro ocorra.

2.4.3 Explora¸

c˜

ao exaustiva

O Spin realiza uma busca em profundidade na árvore computacional para a verifica¸cão do processo. Porém, ao contrário dos outros model-checkers, o Spin não realiza de fato uma verifica¸cão de modelo, mas sim gera códigos em C para verifica¸cão. Esta técnica poupa memória e aumenta a eficiência. O Spin também oferece um grande número de op¸cões para acelerar a verifica¸cão do processo como:

(23)

2.4. Spin 15

Redu¸c˜ao de ordem parcial ´

E sabido que a busca em profundidade exaustiva para verifica¸cão de propriedades como ausência de deadlock é redundante, devido as muitas possibilidades de intercala¸cão entre atividades concorrentes independentes. Em [6], um algoritmo para redu¸cão estática é apresentado, algoritmo este que preserva a capacidade do verificador em checar as pro-priedades desejadas.

Compress˜ao de estados

Em [13], um método que representa estados na forma de autômatos determin´ısticos é apresentado, em conjunto com um algoritmo que armazena ou remove uma string de um conjunto de estados, preservando a minimalidade do autômato. Esta técnica diminui a utiliza¸cão de memória do processo de verifica¸cão.

Bitstate hashing

Ao invés de armazenar todos os estados, somente o hash code é guardado. Assim como a técnica de compressão de estados, a utiliza¸cão do bitstate hashing ajuda a diminuir a utiliza¸cão de memória durante a verifica¸cão. Bitstate hashing, ao invés de armazenar todos os estados do processo, guarda somente o hash code de cada um. Em [5], uma aproxima¸cão anal´ıtica da cobertura esperada do método de bitstate hashing e uma compara¸cão com duas outras estratégias é apresentada.

2.4.4 Utiliza¸

c˜

ao

A utiliza¸cão do Spin via explora¸cão exaustiva se dá a partir dos seguintes comandos:

spin -a model.promela gcc pan.c -o pan ./pan

Caso haja uma falha no processo, um arquivo do tipo model.promela.trail, com o exato trace de execu¸cão que ocasionou a falha é criado, e assim é poss´ıvel executar o trace que gerou a falha através do comando a seguir, para uma visualiza¸cão idêntica a uma caminhada iterativa.

spin -t model.promela

No modo de explora¸cão exaustiva é posspivel ainda checar restri¸cões temporais, definidas a partir de fórmulas LTL, como descrito na se¸cão 2.3. Para isso, a fórmula que se deseja verificar no processo deve ser passada como parâmetro, por exemplo:

(24)

spin -a -f "<>(x && y)" model.promela gcc pan.c -o pan

./pan

No exemplo anterior, é inserida uma restri¸cão ao processo: caso a variável x e a variável y sejam verdadeiras ao mesmo tempo, em algum estado do processo, então este possui uma falha. É importante ressaltar que a satisfa¸cão da fórmula, constitui em uma falha no processo.

Resumo

Nesta se¸cão foi apresentado o Spin, verificador que será utilizado como ferramenta básica para a verifica¸cão de workflows. A modelagem de processos de workflows, para serem verificados no Spin, assim como as técnicas de verifica¸cão necessárias para se atingir os objetivos propostos na se¸cão 1.1 podem ser vistos no cap´ıtulo seguinte.

(25)

Cap´ıtulo 3

Verifica¸

c˜

ao de Workflows

Para a verifica¸cão de workflows é proposto neste trabalho a utiliza¸cão do Spin [4], um verificador formal. Para isso, a modelagem de processos de workflow em PROMELA se faz necessária. Nesta se¸cão, será apresentada como é feita a modelagem de processos de workflow em PROMELA, sem perda de representatividade do processo.

3.1 Modelagem

Os principais elementos na modelagem de workflow são as atividades. Atividades de work-flow são definidas em PROMELA através da declara¸cão de um proctype. Um proctype define um processo que pode ser executado concorrentemente com outros processos.

Como as atividades de um workflow podem ser executadas mais de uma vez, a sua modelagem em PROMELA ´e feita com uma estrutura de repeti¸c˜ao, como pode ser visto a seguir:

1. proctype A() {

2. do

3. :: (final_reached==1) -> break;

4. :: (t0==1) -> atomic { /* transi¸c~ao de entrada */

5. t0=0; /* desfaz precondi¸c~oes */

6. t1=1;t2=1; /* transi¸c~ao de sa´ıda */ 7. exec_a=1; /* a¸c~ao executada */

8. cost+=20; /* atualiza¸c~ao do custo global */

9. };

10. od;

11. }

As variáveis t0, t1 e t2 modelam transi¸cões, como descrito nas se¸cões que se seguem. A variável exec a é atualizado com o valor 1, indicando que a tarefa foi executada, e a variável cost tem seu valor atualizado com o custo de execu¸cão da atividade modelada. Todas essas variáveis serão mais detalhadas no decorrer do texto.

(26)

18 Cap´ıtulo 3. Verifica¸c˜ao de Workflows

Da defini¸cão da atividade anterior é poss´ıvel notar que somente duas condi¸cões liberam a execu¸cão da atividade: o fato de o processo ter sido terminado, quando a variável

final reached for verdadeira; ou o fato da transi¸c˜ao que define a precondi¸c˜ao da atividade

ser verdadeira. Na primeira situa¸cão, o loop é quebrado e a atividade termina. Na segunda, a transi¸cão de precondi¸cão é liberada, e as transi¸cões subsequentes se tornam verdadeiras, liberando o fluxo de execu¸cão.

A defini¸cão de atomicidade na execu¸cão da atividade vem da própria defini¸cão de atividades em workflow, como descrito na se¸cão 2.1, onde atividade representa “uma por¸cão de trabalho que corresponde a um passo lógico e indivis´ıvel dentro de um processo”. Assim, a declara¸cão atomic antes do corpo de execu¸cão garante a inviolabilidade nas trocas de transi¸cões, garantindo que não aconte¸ca condi¸cões de concorrência na atualiza¸cão das transi¸cões.

Além do conceito de atividades, a modelagem de processos de workflow em PROMELA deve contemplar os quatro modos de transi¸cão descritos na se¸cão 2.1.

3.1.1 Transi¸

c˜

ao sequencial

Note que o controle do fluxo de execu¸cão é feito na condi¸cão de libera¸cão do corpo de execu¸cão da atividade, linha 3 do código descrito anteriormente (transi¸cão de entrada), e dentro do corpo de execu¸cão, na linha 6 (transi¸cão de sa´ıda). São nesses pontos da modelagem que se definem o comportamento da transi¸cão.

Para transi¸cões sequenciais, somente uma transi¸cão é liberada no corpo da atividade precedente, e uma transi¸cão aguardada pela atividade seguinte. Por exemplo, as ativi-dades X e Y a seguir têm uma transi¸cão sequêncial entre elas (transi¸cão t1 ), de forma que a atividade Y só é executada após a atividade X.

Figura 3.1: Transi¸c˜ao sequencial.

proctype X() { proctype Y() {

do do

:: (final_reached==1) -> break; :: (final_reached==1) -> break; :: (t0==1) -> atomic { :: (t1==1) -> atomic { t0=0; t1=0; t1=1; t2=1; exec_x=1; exec_y=1; }; }; od; od; } }

(27)

3.1. Modelagem 19

3.1.2 Transi¸

c˜

ao paralela

Para transi¸cões paralelas é necessária a defini¸cão dos blocos descritos na se¸cão 2.1 de AND-split e AND-join. Um AND-join é definido em PROMELA através de:

(t3==1 && t4==1)

Enquanto um AND-split ´e modelado por:

t1=1;t2=1;

Dessa forma, ´e poss´ıvel modelar atividades paralelas como mostra o exemplo a seguir:

Figura 3.2: Transi¸c˜ao paralela.

proctype X() { proctype W() {

do do

:: (final_reached==1) -> break; :: (final_reached==1) -> break; :: (t0==1) -> atomic { :: (t2==1) -> atomic { t0=0; t2=0; t1=1;t2=1 t4=1; exec_x=1; exec_w=1; }; }; od; od; } }

proctype Y() { proctype Z() {

do do

:: (final_reached==1) -> break; :: (final_reached==1) -> break; :: (t1==1) -> atomic { :: (t3==1 && t4==1) -> atomic {

t1=0; t3=0;t4=0; t3=1; t5=1; exec_y=1; exec_z=1; }; }; od; od; } }

3.1.3 Transi¸

c˜

ao Condicional

Assim como em transi¸cões paralelas, para as transi¸cões condicionais também é necessário definir os blocos OR-split e OR-join, como descritos na se¸cão 2.1. Um OR-join é definido por:

(28)

(t3==1 || t4==1)

Enquanto um OR-split ´e definido por:

if :: t0==1; :: t1==1; fi

Assim, atividades condicionais como o processo de exemplo a seguir podem ser definidas como:

Figura 3.3: Transi¸c˜ao condicional.

proctype X() { proctype W() {

do do

:: (final_reached==1) -> break; :: (final_reached==1) -> break; :: (t0==1) -> atomic { :: (t2==1) -> atomic { t0=0; t2=0; if t4=1; :: t1=1; exec_w=1; :: t2=1; }; fi od; }; } od; }

proctype Y() { proctype Z() {

do do

:: (final_reached==1) -> break; :: (final_reached==1) -> break; :: (t1==1) -> atomic { :: (t3==1 || t4==1) -> atomic { t1=0; t3=0;t4=0; t3=1; t5=1; exec_y=1; exec_z=1; }; }; od; od; } }

(29)

3.1. Modelagem 21

3.1.4 Transi¸

c˜

ao Iterativa

Para transi¸cões iterativas não é necessário definir nenhum bloco excepcional. Para a sua modelagem as estruturas anteriores podem ser utilizadas. Um exemplo de um processo com transi¸cões iterativas pode ser observado a seguir:

Figura 3.4: Transi¸c˜ao iterativa.

proctype X() { do :: (final_reached==1) -> break; :: (t0==1 || t1==1) -> atomic { t0=0;t1=0; if :: t1=1; :: t2=1; fi exec_x=1; }; od; }

Uma vez definidas as atividades, transi¸cões e fluxos de execu¸cão do processo, é necessário modelar as condi¸cões iniciais, os objetivos e a instancia¸cão dos processo em PROMELA, para que o workflow seja completamente modelado. Como descrito na se¸cão 2.2, os pro-cessos são definidos com o comando proctype porém não executados. O único processo executado no in´ıcio é processo inicial, declarado como init, em PROMELA.

Na modelagem proposta neste trabalho, o processo init deve ser definido como:

init { /*---*/ /* Inicializa¸c~ao do Workflow */ /*---*/ final_reached=0; t0=0;t1=0;t2=0; (...) exec_a=0;exec_b=0; (...) cost=0;

EI: /* Estado Inicial */ t0=1; printf("Start\n"); Corpo: /* Lan¸ca as atividades */

(30)

EF: /* Estado Final (Objetivo) */ (t9==1) -> printf("End\n"); /*---*/ /* Termina¸c~ao do Workflow */ /*---*/ final_reached=1; }

Note uma etapa de inicializa¸cão das variáveis, desabilitando as transi¸cões; uma etapa de ajuste do Estado inicial, habilitando a transi¸cão inicial; a instancia¸cão das atividades (processos); uma etapa em que o processo init espera que os processos alcancem o Estado final (objetivo - no exemplo modelado anteriormente, o objetivo é modelado através da transi¸cão t9 ); e por fim, uma etapa em que a variável final reached é habilitada, sinal-izando que o processo atingiu seus objetivos, e que as atividades podem ser liberadas do loop.

O estado é modelado em PROMELA através de variáveis. O valor de todas as variáveis do processo em um determinado momento no tempo representa o estado corrente do processo. As variáveis são declaradas de forma global na modelagem proposta, assim todos os processos ou atividades podem acessá-las.

3.2 Verifica¸

c˜

ao Estrutural

Muitos trabalhos quando lidam com verifica¸cão de workflows estão na verdade realizando uma verifica¸cão estrutural. Van der Aalst descreve em seu livro [18] os principais proble-mas estruturais encontrados em workflows, e eles são representados na figura 3.5.

A figura 3.5 apresenta exemplos clássicos de problemas estruturais, entre eles Ativi-dades sem condi¸cões de entrada ou sa´ıda, deadlocks, ativiAtivi-dades mortas e termina¸cão incompleta. A seguir, cada uma dessas falhas estruturais serão comentadas, assim como a estratégia de verifica¸cão proposta usando a modelagem definida anteriormente na se¸cão 3.1 e o Spin.

3.2.1 Atividades sem condi¸

c˜

oes de entrada ou sa´ıda

Quando uma atividade não tem precondi¸cões, ou seja, nenhuma transi¸cão de entrada, não fica claro se ela será executada. Da mesma forma, se a atividade não tem transi¸cões de sa´ıda, ela não contribui para se atingir os objetivos do processo. A figura 3.5.a contém uma atividade sem transi¸cões de entrada (atividade B) e uma atividade sem transi¸cões de sa´ıda (atividade D).

(31)

3.2. Verifica¸c˜ao Estrutural 23

Figura 3.5: Exemplos de processos com falhas estruturais.

A verifica¸cão de existência desse tipo de atividade é feita ainda na etapa de modelagem. Caso a transcri¸cão do processo constate a existência de uma atividade sem transi¸cões de entrada ou sa´ıda, então o processo é reprovado pelo verificador quanto à sua corre¸cão estrutural.

3.2.2 Deadlock

Um deadlock caracteriza uma situa¸cão em que ocorre um impasse e duas ou mais ativi-dades ficam impedidas de continuar suas execu¸cões, ou seja, ficam bloqueadas. Por ex-emplo, na figura 3.5.b, a atividade A ativa somente uma das suas transi¸cões de sa´ıda, e em momento algum as duas transi¸cões de entrada da atividade B estarão ativadas para que ela seja executada, caracterizando assim um deadlock no processo. Somente caso a ´

ultima transi¸cão seja ativada, direto para o estado final, que o deadlock seria evitado. O processo da figura 3.5.b pode ser modelado sem problemas em PROMELA, descar-tando a possibilidade de existência de atividades sem transi¸cões de entrada ou sa´ıda, como no processo da figura 3.5.a, por exemplo. Assim, a verifica¸cão estrutural deve ser realizada pelo Spin, a fim de detectar a falha do processo.

(32)

O processo é submetido a uma explora¸cão exaustiva do Spin, e é constatada a presen¸ca de um erro, como pode ser visto a seguir, do resultado da execu¸cão do Spin.

State-vector 32 byte, depth reached 15, errors: 1 15 states, stored

0 states, matched

15 transitions (= stored+matched) 1 atomic steps

Assim como descrito na se¸cão 2.4, o processo de explora¸cão exaustiva do Spin faz uma busca em profundidade na árvore computacional do processo, em busca de falhas de execu¸cão. Para o exemplo da figura 3.5.b, a profundidade atingida foi de 15 passos, até o verificador encontrar uma falha (no caso o deadlock evidenciado anteriormente). Nesse estado, o Spin constatou que não havia possibilidade de prosseguimento, e o processo não tinha atingido seu fim, caracterizando assim um deadlock, como sugerido.

Como apresentado também na se¸cão 2.4, o erro na explora¸cão exaustiva gera um arquivo .trail, que contém o trace de execu¸cão que ocasionou a falha verificada. Com isso, é poss´ıvel executar o Spin simulando este trace de falha, e o resultado é apresentado a seguir:

Start A

spin: trail ends after 18 steps #processes: 4 t1 = 0 t2 = 1 t3 = 0 t4 = 0 t5 = 0 t6 = 0 final_reached = 0 exec_a = 1 exec_b = 0 exec_c = 0

18: proc 3 (C) line 40 "vda1" (state 10) 18: proc 2 (B) line 29 "vda1" (state 10) 18: proc 1 (A) line 15 "vda1" (state 13) 18: proc 0 (:init:) line 66 "vda1" (state 16) 4 processes created

Note que no trace de execu¸cão é apresentado o estado em que o processo teria falhado. Na figura 3.5.b, o OR-split após a atividade A teria selecionado a segunda transi¸cão (t2 ), e assim, nem a atividade C pode ser executada, nem a atividade B. Resultando assim num deadlock.

O motor básico de verifica¸cão do Spin é responsável pela deteçcão de falhas como dead-locks, assim, assume-se aqui que dada uma modelagem correta, o processo de verifica¸cão de deadlocks é correto.

(33)

3.2. Verifica¸c˜ao Estrutural 25

3.2.3 Termina¸

c˜

ao Completa

Van der Aalst e a maioria da literatura definem o critério de termina¸cão completa como determinante na corre¸cão de um processo. Esse critério estabelece que, para um processo ser bem definido, ao atingir o seu estado final, ele não deve possuir atividades ou transi¸cões pendentes. Por exemplo, na figura 3.5.c, as atividades B e C são executadas após a condi¸cão final ter sido satisfeita, violando o critério de termina¸cão completa.

Determinar se um processo tem ou não termina¸cão completa é poss´ıvel através da for-mula¸cão de uma restri¸cão em LTL, verificada na explora¸cão exaustiva do Spin. A fórmula que define se o processo tem ou não termina¸cão completa é estabelecida de maneira bas-tante intuitiva, como pode ser visto a seguir:

"<>(final_reached && (t0 || t1 || t2 || ... || tn)"

Ou seja, o critério de termina¸cão completa é violado caso a expressão anterior seja verdadeira, e para isso, é preciso que alguma transi¸cão ainda esteja ativada após o processo ter atingido seu fim (ou seja, após a variável final reached ter se tornado verdadeira). Para a verifica¸cão é necessário saber a priori todas as transi¸cões do processo, o que é poss´ıvel, dada a modelagem proposta em 3.1.

Para analisar o funcionamento da verifica¸cão do critério de termina¸cão completa, ve-jamos os seguintes exemplos. Primeiro, um processo correto, que termina completamente, como pode ser visto na figura 3.6.

Figura 3.6: Exemplo de processo que termina completamente.

O resultado da verifica¸cão no Spin, com a restri¸cão em LTL proposta anteriormente pode ser visto a seguir. Note que nenhum erro é identificado, como o esperado.

134 states, matched

hash conflicts: 0 (resolved) 2.501 memory usage (Mbyte)

Já o processo a presentado a seguir, na figura 3.7, o critério de termina¸cão completa é violado, pois há a possibilidade do processo terminar e ainda existirem transi¸cões pen-dentes, como mostra o trace de execu¸cão de contra-exemplo do Spin.

(34)

Figura 3.7: Exemplo de processo que n˜ao termina completamente.

51 states, matched

hash conflicts: 0 (resolved)

A seguir o trace de execu¸c˜ao da falha:

Start A C D B End D spin: trail ends after 90 steps #processes: 5

t0 = 0;t1 = 0;t2 = 0;t3 = 0;t4 = 0;t5 = 1; final_reached = 1

exec_a = 1;exec_b = 1;exec_c = 1;exec_d = 1

Note que, devido ao OR-join do processo, a atividade D foi executada mais de uma vez, e uma delas inclusive após o processo ter atingido o seu fim, caracterizando assim em uma viola¸cão do critério de termina¸cão completa.

3.3 Quest˜

oes Ad-hoc

A verifica¸cão estrutural checa se o workflow tem defeitos sintáticos. Verifica¸cões sintáticas são importantes para analisar o correto funcionamento do processo, mas verifica¸cões mais completas do workflow são desejáveis. Além de verifica¸cões sintáticas, é importante também realizar verifica¸cões semânticas, que dizem respeito ao contexto do processo, do que somente sua estrutura. Verifica¸cões semânticas podem ser modeladas através de questões genéricas, como “uma atividade de venda sempre é precedida por uma atividade de aprova¸cão?”, ou então “uma atividade A é sempre executada antes de uma atividade

(35)

3.3. Quest˜oes Ad-hoc 27

B?”. Estas questões ad hoc são verifica¸cões semânticas simples, que podem ser descritas através de fórmulas LTL.

Como descrito anteriormente, o Spin verifica se fórmulas LTL são verdadeiras para um processo, e assim, para um workflow modelado em PROMELA. A seguir, um processo exemplo é descrito, assim como sua representa¸cão gráfica. A modelagem deste processo em PROMELA pode ser observado no apêndice A.1.

Figura 3.8: Exemplo de processo de workflow.

O exemplo da figura A.1 representa um processo de venda de um produto. Primeiro é definida a compra através da escolha das caracter´ısticas do produto (atividade A), e então, em paralelo, uma verifica¸cão de crédito do consumidor é realizada (atividade B), em concorrência com a retirada do produto do estoque (atividade C) e a sua prepara¸cão pra ser entregue (atividade D). Se o consumidor tiver o crédito aprovado, o produto é entregue (atividade E) e o processo é terminado (atividade G). Caso contrário, do consumidor não ter o crédito aprovado, então a compra é cancelada (atividade F) e o processo termina (atividade G).

Para este exemplo, uma questão semântica interessante seria: “a atividade de entrega do produto (atividade E) pode ser executada se o crédito do consumidor for rejeitado?”. Tendo o conhecimento do contexto do processo, e da modelagem de todas as atividades que o compõe, a resposta a essa pergunta para este exemplo simples parece trivial. No entanto, para sistemas de verifica¸cão automáticos, essas inferências que dizem respeito a semântica do processo não são diretas, e representam complexidade considerável.

A questão anterior, pode ser traduzida em uma fórmula LTL, e então, verificada através do Spin. O Spin traduz cada fórmula LTL em uma “never claim” de forma provar ou rejeitar a fórmula para um determinado processo de forma eficiente. Assim, como o Spin gera “never claims” para as fórmulas LTL, a sua formula¸cão deve ser negada, para produzir o resultado desejado. Assim, para a questão anterior, a fórmula LTL inserida no Spin é:

(36)

Note que rejected é um dos poss´ıveis efeitos da atividade B, e exec e é uma variável que indica se a atividade E foi executada. Assim, traduzindo a fórmula anterior para o português seria: se rejected for verdadeiro então nunca a tarefa E é executada. Se eventualmente essa afirma¸cão for falsa, então a fórmula é rejeitada pelo Spin.

Note que, se invertermos a lógica da pergunta, ou seja “a atividade de entrega do produto (atividade E) pode ser executada se o crédito do consumidor for aceito?”, ter´ıamos que obter também uma resposta contrária do verificador, uma vez que evetualmente a variável exec e será verdade se o crédito for aprovado. O resultado do Spin, apresentado a seguir, comprova a corre¸cão da fórmula utilizada.

322 states, matched

hash conflicts: 0 (resolved) Trace de contra-exemplo: Start EscolhaProduto ProdutoEstoque EmbalaProduto VerificaCredito RealizaVenda spin: trail ends after 85 steps

#processes: 8

t0 = 0;t1 = 0;t2 = 0;t3 = 0;t4 = 0;t5 = 0;t6 = 0;t7 = 1;t8 = 0;t9 = 0 final_reached = 0

exec_a = 1;exec_b = 1;exec_c = 1;exec_d = 1;exec_e = 1;exec_f = 0;exec_g = 0 rejected = 0

accepted = 1

Outro tipo de questionamento comum para processos de workflow diz respeito a precedência entre atividades, por exemplo: “a atividade de preparo do produto (ativi-dade D) é executada somente após a ativi(ativi-dade de retirada do estoque (ativi(ativi-dade C)?”, ou “a atividade de preparo (atividade D) é executada somente após a atividade de verifica¸cão de crédito (atividade B)?”. Essas questões podem ser formuladas em LTL como a seguir:

never claim: <> !(!exec_d U exec_c) never claim: <> !(!exec_d U exec_b)

Para o processo anterior, a primeira fórmula é verificada como verdadeira, porém para a segunda, a verifica¸cão através do Spin acusa uma viola¸cão, pois existe uma ordena¸cão parcial entre as atividades D e B, e assim, existe a possibilidade da atividade D ser executada antes da atividade B. O trace de execu¸cão em que esta restri¸cão é violada pode ser visto a seguir:

(37)

3.4. Verifica¸c˜ao de Recursos 29

0 states, matched

hash conflicts: 0 (resolved) Trace de contra-exemplo: Start EscolhaProduto ProdutoEstoque EmbalaProduto VerificaCredito spin: trail ends after 78 steps #processes: 8

accepted = 0

Note que a formula¸cão anterior permite a verifica¸cão de ordena¸cão entre quaisquer duas atividades do processo, podendo ser bastante útil na verifica¸cão ad-hoc de processos de workflow.

3.4 Verifica¸

c˜

ao de Recursos

Verifica¸cão de recursos em workflow pode ser reduzida ao problema de exclusão mutua em processos concorrentes. No entanto, para realizar esse tipo de verifica¸cão, os recursos que cada atividade usa devem ser conhecidos a priori, e assim, modelados juntamente com o processo de workflow.

Sabendo os recursos utilizados pelas atividades, a verifica¸cão por concorrência ao uso desses recursos é feita no Spin seguindo o procedimento formal proposto a seguir:

VERIFICA_RECURSO(ATIVIDADES do processo) BEGIN FOR X in ATIVIDADES

FOR Y in ATIVIDADES

IF (X != Y) && (X e Y acessam o mesmo recurso)

spin -a -f ’<> (preconditions of X && preconditions of Y)’ processo END IF

END FOR END FOR END

Note que duas atividades são concorrentes quando existe a possibilidade de suas pre-condi¸cões, ou seja, de suas transi¸cões de entrada serem verdadeiras ao mesmo tempo. Assim, a verifica¸cão de recursos é feita através da questão em LTL que verifica essa condi¸cão, como apresentado anteriormente, para todas as atividades que compartilhem

(38)

de um mesmo recurso. Se nenhuma viola¸cão é detectada no procedimento, o processo é livre de conflitos.

Argumenta¸cão: vamos supor que um processo verificado como correto pelo procedi-mento anterior tenha um conflito de recurso. Se o conflito aconteceu, então pelo menos duas atividades que utilizam do mesmo recurso estavam sendo executadas ao mesmo tempo. Como as atividades são declaradas como atômicas (ou seja, indivis´ıveis), para que as atividades conflitantes sejam executadas concorrentemente, as transi¸cões de entrada de ambas, em algum trace de execu¸cão foram verdadeiras ao mesmo tempo. Sendo assim, o procedimento de verifica¸cão de conflitos de recurso proposto teria apontado uma viola¸cão.

3.5 Verifica¸

c˜

ao de Restri¸

c˜

oes de Custo

Outro tipo de verifica¸cão semântica poss´ıvel é checar restri¸cões de execu¸cão em workflows. A maioria dos processos possuem restri¸cões que limitam seu escopo, seja com rela¸cão a custos, a tempo de execu¸cão, a quantidade de pessoas envolvidas, etc. Restri¸cões essas que podem ser globais, ou seja, limitantes do processo como um todo, ou locais, que definem restri¸cões para partes independentes do processo, ou até mesmo para atividades espec´ıficas de um processo.

Uma restri¸cão comum em processos modelados em workflow, é a restri¸cão de custo. Custo pode ser entendido como custo financeiro ou custo em mão de obra, por exemplo, avaliado a partir do número de horas de trabalho que cada atividade despende. Assim, checar se um processo não estoura um or¸camento pré estabelecido, ou se cada atividade é executada dentro de um limite de custo, é uma necessidade para viabilizar a modelagem do processo.

Para a verifica¸cão de restri¸cões de custo, é preciso ter definido a priori os custos de cada atividade. No exemplo da figura A.1, suponha que cada atividade tenha um custo de 20 unidades, exceto a atividade F, que custa 30 unidades. Podemos supor agora que a atividade G somente pode ser executada caso o custo total até então não tenha excedido 120 unidades. Essa restri¸cão pode ser verificada através de uma fórmula LTL, como a seguir:

<> !(!burst U exec_g)

A variável burst é uma regra definida juntamente com as variáveis globais do sistema, através da declara¸cão a seguir:

#define burst (cost<120)

O valor do estouro de or¸camento (burst), é passado como parâmetro para o verificador. A variável cost é global, inicializada com zero no in´ıcio do processo, e é acrescentado a ela o

(39)

3.5. Verifica¸c˜ao de Restri¸c˜oes de Custo 31

valor de custo assim que cada atividade é executada, como pode ser visto na modelagem de atividades em PROMELA, na se¸cão 3.1. Sendo assim, a fórmula LTL anterior é rejeitada se eventualmente acontecer um estouro do or¸camento antes da execu¸cão da atividade G. No exemplo da figura A.1, com os valores de custos propostos anteriormente, este estouro não acontece, como pode ser visto do resultado da verifica¸cão a seguir.

1956 states, matched

hash conflicts: 0 (resolved)

No entanto, se definirmos o limite para 100 unidades, existe um trace de execu¸cão do processo que estouraria este or¸camento. O trace de execu¸cão pode ser visto a seguir, e o valor total do custo para este trace atinge 110 unidades antes da execu¸cão da atividade G e 130 após a sua execu¸cão, resultando na viola¸cão da fórmula LTL verificada, como mostra o resultado da verifica¸cão a seguir.

0 states, matched

hash conflicts: 0 (resolved) Trace de contra-exemplo: Start EscolhaProduto ProdutoEstoque EmbalaProduto VerificaCredito CancelaCompra TerminaCompra spin: trail ends after 86 steps

#processes: 8

accepted = 0 cost = 130

A verifica¸cão de custos é relativamente direta, levando-se em considera¸cão o fato de que o custo de cada atividade, seja ele medido em termos financeiros ou em horas de trabalho, por exemplo, é sempre acumulativo, independente do encadeamento das tarefas. Uma vez executada, a tarefa deve somar o seu custo individual ao custo global.

Para mostrar que a verifica¸cão de restri¸cões de custo é correta, temos que assumir que as seguintes condi¸cões são verdadeiras:

(40)

1. Sempre que uma tarefa ´e executada, seu custo ´e adicionado ao custo global do processo.

2. Não há interferência ao acesso a esta variável entre atividades concorrentes. 3. Não é feita altera¸cão no valor do custo exceto pelas atividades do processo.

Garantindo que essas premissas são verdadeiras, podemos afirmar que o valor da variável custo é sempre correto, entre a execu¸cão de quaisquer atividades do processo, e em decorrência disso, após o término do processo também. As premissas 1 e 2 são garantidas pela modelagem das atividades, proposta na se¸cão 3.1, através da linha 8 no código da defini¸cão da atividade, onde é feita a atualiza¸cão da variável custo, e da linha 4, onde o comando atomic é utilizado, impedindo a concorrência entre atividades para esta atualiza¸cão.

Como visto em 3.1, um processo é composto pela modelagem das atividades, e pela modelagem do processo principal (init) , que inicializa as variáveis necessárias, instancia as atividades, atribui o estado inicial do processo, para que este seja iniciado, e fica travado até que a execu¸cão das atividades do processo atinja os objetivos. Dessa forma, pode-se observar que, após a inicializa¸cão da variável cost para zero, ela não é mais alterada no

init, voltando a ser alterada somente no corpo das atividades, garantindo assim a premissa

de n´umero 3.

A argumenta¸cão anterior mostra que o valor do custo é correto entre a execu¸cão das atividades. Para garantir agora que a verifica¸cão através da fórmula LTL proposta seja verdadeira, devemos apenas garantir que, dentro da execu¸cão da atividade, a atualiza¸cão do custo seja feita antes da atualiza¸cão da variável que define que a atividade já foi executada. O que acontece, seguindo a modelagem proposta na se¸cão 3.1. Com isso, a varável custo pode ser considerada correta entre a execu¸cão das atividades, mas também durante a sua execu¸cão. Garantindo a validade da verifica¸cão proposta nesta se¸cão para a restri¸cão de custos de um processo de workflow.

3.6 Relaxa¸

c˜

ao do crit´

erio de Termina¸

c˜

ao Completa

O critério de termina¸cão completa, como visto na literatura, indica que, para um processo correto, nenhum ramo de execu¸cão deve ficar pendente após a termina¸cão do processo, assim como descrito na se¸cão 3.2.3.

Porém, no exemplo da figura A.1, pode-se notar que esse critério é muito forte, tanto para processos simples, quanto para processos mais complexos do mundo real. Normal-mente o processo da figura A.1 seria verificado como incorreto na maioria dos sistemas de verifica¸cão de workflows, pois caso a atividade B libere a transi¸cão para a atividade F, o