Pós-Graduação em Ciência da Computação...Figura 3.12: Exemplo do uso do gateway inclusivo....

Pós-Graduação em Ciência da Computação

UMA ABORDAGEM PARA A TRANSFORMAÇÃO DA

NOTAÇÃO BPMN PARA A NOTAÇÃO DE REDES DE PETRI

Por

JESSE JAMES MATOS SOARES

Dissertação de Mestrado Profissional

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Jesse James Matos Soares

UMA ABORDAGEM PARA A TRANSFORMAÇÃO

DA NOTAÇÃO BPMN PARA A NOTAÇÃO DE

REDES DE PETRI

ORIENTADOR(A): Prof. Ricardo Massa Ferreira de Lima, PhD

Este trabalho foi apresentado à Pós-Graduação em Ciência da

Computação do Centro de Informática da Universidade Federal de

Pernambuco como requisito parcial para obtenção do grau de Mestre

Profissional em Ciência da Computação.

Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571

Soares, Jesse James Matos Uma abordagem para a transformação de notação BPMN para a notação de redes de Petri/ Jesse James Matos Soares. - Recife: O Autor, 2014. 191 f., fig., tab., quadro Orientador: Ricardo Massa Ferreira de Lima.

Dissertação (mestrado profissional) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2014. Inclui referências e anexo. 1. Engenharia de Software. 2. Modelagem de Processos e Negócios. 3. Redes de Petri. I. Lima, Ricardo Massa Ferreira de (orientador). I. Título. 005.1 CDD (23. ed.) MEI2014 – 118

Dissertação de Mestrado Profissional apresentada por Jesse James Matos Soares à

Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade

Federal de Pernambuco, sob o título, “Uma abordagem para a transformação da

notação BPMN para a notação de Redes de Petri”, orientada pelo Professor Ricardo

Massa Ferreira Lima e aprovada pela Banca Examinadora formada pelos professores:

_______________________________________________

Prof. Paulo Romero Martins Maciel

Centro de Informática / UFPE

______________________________________________

Prof. Fernando Antonio Aires Lins

Universidade Federal Rural de Pernambuco

______________________________________________

Prof. Ricardo Massa Ferreira Lima

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 25 de abril de 2014.

___________________________________________________

Profª. EDNA NATIVIDADE DA SILVA BARROS

Coordenadora da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Dedico esse trabalho à minha família, especialmente à minha esposa Jacqueline e aos meus filhos Giovana e Davi, que tiveram que suportar a minha ausência durante a preparação desse trabalho. Dedico também à Dra Sheila Milena, minha irmã que teve que suportar a minha presença durante boa parte dessa etapa. Por fim dedico à minha mãe Eula Alves Matos, que me deu a oportunidade de chegar tão longe mesmo não estando mais aqui para ver.

Agradecimentos

A realização desse trabalho em muito se deve à colaboração de

inúmeras pessoas, às quais transmito os mais sinceros agradecimentos;

Ao Professor Dr. Ricardo Massa pela orientação dedicada e

compromissada, e pelo precioso conhecimento transmitido;

Ao meu coorientador virtual, Dr. César Augusto Lins de Oliveira, pela

valiosa ajuda, sem a qual esse trabalho não teria sido feito;

À amiga Luciana e à minha irmã Milena Soares por cederem

moradia, comida e paciência;

Aos colegas Luiz Manzella, Luis Vieira e Marcelo pelas diversas

caronas e pela amizade;

A Henrique Pimentel pela simpatia, amizade e gentileza.

A Thiago Bessa, Eduardo Freire e Lutiano pelo nosso grupo

vencedor.

Aos demais colegas cujas dicas e incentivo me forçaram a dar

prosseguimento a essa tarefa.

A John Bohman, John Paul Jones, Jimmy Page e Robert Plant,

dentre tantos outros que embalaram as horas solitárias de estudo e

desenvolvimento desse trabalho.

“Oh, let the sun beat down upon my face Stars to fill my dream

I am a traveler of both time and space To be where I have been

Led Zeppelin

Resumo

A adoção da Gestão de Processos de Negócios vem crescendo nos mais

diversos tipos de instituições em geral, nos últimos anos, principalmente a partir

da criação da BPMN como ferramenta gráfica para o desenho dos processos.

A BPMN (Business Process Model and Notation) se destaca dentre várias

notações pela sua simplicidade e facilidade de entendimento. Apesar da sua

força como notação gráfica, a BPMN carece de um formalismo matemático que

possa avaliar a eficiência de um determinado fluxo de processo. Por outro lado

as redes de Petri como uma notação madura, com forte formalismo

matemático, de larga aceitação na descrição de sistemas discretos e bastante

popular no meio acadêmico mas pouco conhecida e utilizada entre as pessoas

de negócios, não só tem uma notação gráfica eficiente como possui várias

formas de avaliação formal de desempenho dos grafos criados. O presente

trabalho vem juntar-se a várias iniciativas de unir essas duas notações para

tentar obter o melhor que ambas oferecem, ou seja para ter em mãos tanto a

facilidade de uso e entendimento da BPMN quanto o formalismo matemático e

simplicidade gráfica das Redes de Petri. Para isso é apresentado um modelo

de transformação e seu respectivo protótipo capaz de transformar um diagrama

BPMN para o seu equivalente em um diagrama baseado em redes de Petri,

mais especificamente uma GSPN (Generalized Stochastic Petri Net),

permitindo, dessa forma que avaliações de correção e análise de desempenho

específicos das redes resultantes sejam aplicados ao processo transformado.

Palavras-chave: Negócio. Processo. Gerenciamento. BPMN. Redes de Petri.

Transformação. GSPN.

Abstract

The adoption of Business Process Management has been growing in

various types of institutions in general, in recent years, especially since the

creation of the BPMN as a graphical tool for the design of processes. BPMN

(Business Process Model and Notation) stands out among several notations for

its simplicity and ease of understanding. Despite its strength as a graphical

notation, BPMN lacks a mathematical formalism that can evaluate the efficiency

of a given process flow. On the other hand, Petri nets as a mature notation, with

a strong mathematical formalism, with wide acceptance in the description of

discrete systems and quite popular in academia but little known and used

among business people, not only it has an efficient graphical notation but also

several kinds of formal performance evaluation of the graphs created. This

study joins a number of initiatives to unite these two notations to try to get the

best both offer, that is to have on hands both ease of use and understanding of

BPMN regarding the mathematical formalism and graphic simplicity of Petri

Nets. For this, it is presented a transformational model and its corresponding

prototype capable of transforming such a BPMN diagram to its equivalent in a

system based on Petri nets, more specifically a GSPN (Generalized Stochastic

Petri Net), thereby allowing that correctness evaluation and performance

analysis of the resulting networks are applied to the transformed process.

Keywords: Business. Process. Management. BPMN. Petri Nets.

Transformation. GSPN

Lista de Siglas e Abreviações

BPMN Process Model and Notation

RdP Redes de Petri

JAXB Java Architeture for XML Binding

GSPN Generalized Stochastic Petri Nets

XML Extensible Markup Language

DTD Document Type Definition

UML Unified Modeling Language

XMPL Experimental Media Performance Language

XPDL XMPL Process Description Language

BPEL Business Process Execution Language

URI Universal Resource Identifier

EDSPN Extended Deterministic and Stochastic Petri Nets

SCPN Stochastic Colored Petri Nets

Lista de Figuras

Figura 3.1: Relacionamento entre os principais elementos de um processo.

Fonte: (Oliveira C. A., 2008) ............................................................................. 35

Figura 3.2: Principal restrição em Redes de Petri ............................................ 39

Figura 3.3: Semáforo único representado em uma Rede de Petri. .................. 39

Figura 3.4: Um exemplo de arco inibidor .......................................................... 44

Figura 3.5: Exemplo de evento intermediário temporal. Fonte: (iProcess, 2011)

......................................................................................................................... 52

Figura 3.6: Evento de borda interrompível. Fonte: (iProcess, 2011) ................ 53

Figura 3.7: Evento intermediário de borda temporal não interrompível. Fonte:

(iProcess, 2011) ............................................................................................... 53

Figura 3.8: Marcadores de Atividades .............................................................. 54

Figura 3.10: Exemplo do uso do gateway exclusivo. Fonte: (iProcess, 2011) . 58

Figura 3.11: Exemplo do uso do gateway paralelo. Fonte: (iProcess, 2011) ... 59

Figura 3.12: Exemplo do uso do gateway inclusivo. Fonte: (iProcess, 2011) .. 59

Figura 4.1: Diagrama simplificado das classes geradas no processo de binding

para as redes eDSPN. ..................................................................................... 66


para as redes SCPN. ....................................................................................... 66

Figura 4.3: Listagem das classes das redes a) EDSPN e b) SCPN ................. 67


para BPMN ....................................................................................................... 69

Figura 4.5: Listagem das classes da BPMN ..................................................... 70

Figura 5.1: Diagrama simplificado das classes de transformação de BPMN para

EDSPN ............................................................................................................. 72

Figura 5.2: Eventos de Início presentes no Bonita Open Solution .................. 74

Figura 5.3: Início do processo segundo a proposta de (Raedits, Petkovic,

Usenko, Werf, & Jan Friso Groote, 2007) ........................................................ 75

Figura 5.4: Transformação de um evento inicial BPMN em uma transição de

Redes de Petri. ................................................................................................. 75

Figura 5.5: Eventos de Fim presentes no Bonita Open Solution ...................... 76

Figura 5.6: Transformação de um Evento Final para a representação em uma

RdP .................................................................................................................. 76

Figura 5.7: Transformação de duas raias em lugares de RdP ......................... 78

Figura 5.8: Raia Empregado com 3 papéis definidos ....................................... 79

Figura 5.9: Tipos de Tarefas do BoS ................................................................ 80

Figura 5.10: Transformação de uma tarefa ...................................................... 82

Figura 5.11: Teste de geração de um processo simples. ................................. 83

Figura 5.12: Transformação de um processo simples ...................................... 83

Figura 5.13: O processo gerado sendo executado no TimeNet ....................... 84

Figura 5.14: Eventos intermediários do Bonita Soft ......................................... 85

Figura 5.15: Transformação de eventos de lançamento de mensagem para

RdP .................................................................................................................. 86

Figura 5.16: Eventos intermediários do fluxo normal ....................................... 86

Figura 5.17: Transformação de um evento intermediário de captura ............... 86

Figura 5.18: Eventos que podem se acoplar à borda das atividades ............... 86

Figura 5.19: Modelo de atividade cancelável segundo (Oliveira C. A., 2008). . 87

Figura 5.20: Mapeamento de uma tarefa com exceção proposta em (Remco M.

Dijkman, 2008) ................................................................................................. 88

Figura 5.21: Mapeamento de um evento de borda interrompível. .................... 88

Figura 5.22: Um processo Un ........................................................................... 89

Figura 5.23: Gateways (desvios) presentes no BoS ........................................ 89

Figura 5.24: Composição de caminhos alternativos (XOR). Fonte: (Oliveira C.

A., 2008). .......................................................................................................... 90

Figura 5.25: Transformação de um fluxo contendo caminhos alternativos

exclusivos. ........................................................................................................ 91

Figura 5.26: junção com gateway exclusivo ..................................................... 92

Figura 5.27: Transformação de um bloco com dois gateways exclusivos. ....... 92

Figura 5.28: Exemplo de transformação XOR usando o protótipo ................... 93

Figura 5.29: Composição em Paralelo (AND). Fonte: (Oliveira C. A., 2008). ... 94

Figura 5.30: A transformação de um par de gateways paralelos ..................... 95

Figura 5.31: Gateway paralelo nas duas situações separadas. ....................... 96

Figura 5.32: Um exemplo de transformação de gateway paralelo ................... 96

Figura 5.33: Composição de múltiplos caminhos com sincronização (OR)

proposto por ..................................................................................................... 98

Figura 5.34: mapeamento de gateway inclusivo proposto por (Ramadan,

Elmongui, & Hassan, 2011) .............................................................................. 99

Figura 5.35: Tranformação de gateway inclusivo ........................................... 100

Figura 5.36: Um exemplo de uma transformação de um gateway inclusivo .. 102

Figura 5.37: Representação de um loop em BPMN ....................................... 103

Figura 6.1: Processo de lançamento de IPVA – Veículo Novo em BPMN ..... 105

Figura 6.2: Estudo de caso transformado para a notação de Rdes de Petri .. 108

Figura 6.3 Resultado das simulações do processo Lançamento de IPVA no

BOS. ............................................................................................................... 110

Figura 6.4: Tempo de execução de instâncias por dia gerados pelo BOS. .... 110

Figura 6.5: Tempo de execução da atividade Encaminhar para Vistoria. ...... 111

Figura 6.6: Tempo de espera da atividade Pagar Taxas e impostos. ............ 112

Figura 6.7: Tempo de execução das instâncias de Realizar Vistoria. ............ 112

Figura 6.8: Custo de arrecadador por dia ....................................................... 112

Figura 6.9: Validando a GSPN gerada ........................................................... 114

Figura 6.10: taxas de chegadas internas por tarefa ....................................... 115

Figura A.1: Paleta do Bonita Open Solution ................................................... 122

Figura A.2: Visão geral do Bonita Open Solution ........................................... 123

Figura A.3: O menu de exportação dos diagramas no formato BPMN 2.0 ..... 124

Figura A.4: Edição de propriedades dos elementos no BoS. ......................... 124

Figura A.5: Erro de validação no BOS ........................................................... 126

Figura A.6: Inserção de parâmetros de dados no BOS .................................. 127

Figura A.7: Inserindo um parâmetro de dado no BOS ................................... 127

Figura A.8: Parâmetros de simulação do BOS ............................................... 128

Figura A.9: Inserção de recursos em um elemento ........................................ 129

Figura A.10: Adicionando recursos a um elemento ........................................ 130

Figura A.11: Tela de gerenciamento de recursos ........................................... 131

Figura A.12: tela de inserção/edição de recursos do BOS ............................. 131

Figura A.13: Tela de edição de disponibilidade de recursos. ......................... 132

Figura A.14: Primeira tela de edição do perfil de carregamento. .................... 133

Figura A.15: Segunda tela do perfil de carregamento .................................... 133

Figura A.16: Parâmetros de execução de uma simulação ............................. 134

Figura A.17: Exemplo de gráfico de simulação do BOS. Fonte: (BonitaSoft ,

2011) .............................................................................................................. 134

Figura A.18: Visão geral do TimeNet ............................................................. 136

Figura A.19: Site da ferramenta TimeNet ....................................................... 137

Figura A.20: Botões dos objetos para as redes EDSPN. ............................... 138

Figura A.21: O botão de lugar e suas propriedades. ...................................... 140

Figura A.22: Propriedades das Transições Imediatas .................................... 140

Figura A.23: Propriedades das Transições Exponenciais .............................. 141

Lista de Tabelas

Tabela 2.1: Relação de algumas das anotações JAXB. Adaptado de (Ballem,

2011). ............................................................................................................... 30

Tabela 3.1: Elementos básicos de uma Rede de Petri genérica. Fonte:

Adaptado de (Reisig, 2013) .............................................................................. 37

Tabela 3.2: Elementos Complementares à notação Básica de Redes de Petri 38

Tabela 3.3: Elementos básicos da BPMN ........................................................ 47

Tabela 3.4: Tipos de eventos de acordo com o local de ocorrência. ................ 50

Tabela 3.5: Eventos por tipo de disparador. ..................................................... 51

Tabela 3.6: Diferentes formas de se iniciar um processo. Fonte: (iProcess,

2011). ............................................................................................................... 52

Tabela 3.7: Tipos de atividades e seus marcadores. ....................................... 54

Tabela 3.8: Tipos de tarefas e seus marcadores ............................................. 55

Tabela 3.9: Tipos de desvio condicional (gateways) ........................................ 57

Tabela 3.10: Tipos de fluxos internos do processo. ......................................... 60

Tabela 5.1: Códigos definidos para dados de execução. ................................. 80

Tabela 6.1: Histórico do Lançamento de IPVA ............................................... 109

Tabela A.1: Elementos gráficos das EDSPN na TimeNet .............................. 139

Lista de Códigos

Código 2.1: Exemplo de Documento XML. Fonte: (Resfnes Data, 1999) ........ 26

Código 2.2: Um XML de uma livraria. Fonte: Adaptado de (Resfnes Data, 1999)

......................................................................................................................... 27

Código 2.3: Um exemplo de DTD. Fonte: (Resfnes Data, 1999) ...................... 28

Código 2.4: Exemplo do código 2.1 com o DTD. .............................................. 28

Código 2.5: Exemplo de uso de namespaces .................................................. 29

Código 4.1: Comandos para realizar o binding. Fonte: (Java Arquiteture for

XML Biding (JAXB), 2009) ............................................................................... 65

Código 4.2: Comando para a geração das classes do BPMN 2.0 .................... 68

Lista de Quadros

Quadro 5.1: Definições utilizadas para Lugar Inicial e Transições de Partida.

Fonte: (Oliveira C. A., 2008). ............................................................................ 74

Quadro 5.2: definição de conjunto de papéis. Fonte: (Oliveira C. A., 2008) ..... 77

Quadro 5.3: definição formal do Modelo de Atividade. Fonte: (Oliveira C. A.,

2008). ............................................................................................................... 81

Quadro 5.4: Definição formal de Equivalência de Papéis. Fonte: (Oliveira C. A.,

2008) ................................................................................................................ 82

Quadro 5.5: Definição de Operador Caminho Alternativo (Xor). Fonte: (Oliveira

C. A., 2008) ...................................................................................................... 90

Quadro 5.6: Definição do Operador Paralelismo – AND. Fonte: (Oliveira C. A.,

2008) ................................................................................................................ 94

Sumário

Capítulo 1 Introdução ................................................................................ 19

1.1 Contexto e Motivação .......................................................................... 19

1.2 Caracterização do Problema ............................................................... 20

1.3 Objetivos ............................................................................................. 21

1.3.1 Objetivo Geral .................................................................................. 21

1.3.2 Objetivos Específicos ....................................................................... 21

1.4 Trabalhos Relacionados ...................................................................... 22

1.5 Estrutura do Documento ..................................................................... 23

Capítulo 2 Fundamentos de programação .............................................. 24

2.1 Java ..................................................................................................... 24

2.2 XML ..................................................................................................... 25

2.2.1 Validação de XML ............................................................................. 28

2.2.2 Entendendo Namespaces ................................................................. 29

2.3 JAXB ................................................................................................... 29

2.4 Considerações Finais .............................................................................. 31

Capítulo 3 Processos de Negócios .......................................................... 32

3.1 Gerenciamento de Processos de Negócios ........................................ 33

3.2 Definições e terminologias .................................................................. 33

3.2.1 Estruturas de Controle de Fluxo ...................................................... 35

3.3 Abordagens para o desenho de processos ......................................... 36

3.4 Introdução às Redes de Petri .............................................................. 36

3.4.1 Componentes das Redes de Petri ................................................... 37

3.5 Introdução às Generalized Stochastic Petri Nets ................................ 41

3.6 Introdução à BPMN ............................................................................. 45

3.6.1 A Especificação BPMN .................................................................... 45

3.6.2 Elementos Básicos da Busines Process Model and Notation .......... 47

3.6.3 Elementos de Processos ................................................................. 49

3.6.4 Definindo Eventos ............................................................................ 49

3.6.5 Definindo Atividades ........................................................................ 53

3.6.6 Definindo Tarefas ............................................................................. 55

3.6.7 Definindo Desvios (gateways) .......................................................... 56

3.6.8 Definindo Fluxos Internos do processo ............................................ 59

3.6.9 Considerações Finais Sobre BPMN ................................................. 60

3.7 Avaliação de Fluxos ............................................................................ 61

3.8 Avaliação de desempenho .................................................................. 62

3.9 Considerações finais sobre workflow .................................................. 63

Capítulo 4 A Criação das Classes Básicas ............................................. 64

4.1 As notações XML usadas no projeto ................................................... 64

4.1.2 A notação do TimeNet ..................................................................... 64

4.1.3 A notação do Bonita ......................................................................... 68

4.2 Conclusões ......................................................................................... 70

Capítulo 5 Transformação de BPMN para GSPN .................................... 71

5.1 Criando o módulo de transformação ................................................... 71

5.2 A estrutura do pacote do módulo de transformação ........................... 72

5.3 Definição da transformação de início de processo .............................. 74

5.4 Definição da transformação de fim de processo ................................. 76

5.5 Mapeamento de Pools e Raias ........................................................... 77

5.6 Mapeamento das Tarefas ................................................................... 80

5.7 Transformação de eventos intermediários .......................................... 84

5.8 Definição de notação de subprocessos ............................................... 89

5.9 Transformação de gateways ............................................................... 89

5.9.1 Transformação de gateways exclusivos .......................................... 90

5.9.2 Transformação de gateways paralelos ............................................ 93

5.9.3 Transformação de gateways inclusivos ........................................... 97

5.10 Transformação de Iterações .......................................................... 102

5.11 Considerações Finais .................................................................... 103

Capítulo 6 Estudo de Caso ..................................................................... 104

6.1 Descrição do Processo de Lançamento de IPVA .............................. 105

6.1.1 Exportação e transformação do processo...................................... 107

6.1.2 Simulação do processo no Bonita .................................................. 108

6.2 Avaliação do processo exportado ..................................................... 113

6.3 Conclusões sobre o estudo de caso ................................................. 115

Capítulo 7 Conclusões ............................................................................ 118

7.1 Conclusões ....................................................................................... 118

7.2 Trabalhos Futuros ............................................................................. 120

ANEXO A Ferramentas utilizadas ............................................................... 121

A.1 Introdução à Ferramenta Bonita Open Solution.................................... 121

A.1.1 Validação do processo no Bonita Open Solution ............................... 125

A.1.2 Simulação do processo no Bonita Open Solution .............................. 126

A.1.2.1 Definindo parâmetros de simulação ............................................... 126

A.1.2.2 Definindo perfil de carregamento .................................................... 132

A.1.2.3 Executando a simulação ................................................................. 133

A.2 Introdução à Ferramenta TimeNet ....................................................... 136

A.2.1 O suporte da TimeNet para as redes EDSPN ................................... 138

A.2.2 Elementos de desenho das EDSPN .................................................. 138

A.2.3 Validação de workflow ....................................................................... 143

A.2.4 Avaliação do workflow ....................................................................... 144

A.3 Considerações Finais ........................................................................... 144

ANEXO B Arquivos XML gerados no Estudo de Caso da Sefaz-PI .......... 145

ANEXO C Código Fonte das Classes de Transformação do Protótipo ... 175

Referências ................................................................................................... 189

19

Capítulo 1

Introdução

Uma área que vem obtendo visibilidade nas últimas décadas é a de

gerenciamento de processos de negócios (ou Business Process Management –

BPM) (Jeston & Nelis, 2008). Os estudos e pesquisas dessa área procuram

definir uma metodologia capaz de, por si só, desenhar, analisar, sugerir e

implantar melhorias em processos de negócios.

Várias notações foram propostas ao longo dos anos, algumas atingiram

certa visibilidade nos ambientes técnicos enquanto outras tiveram um certo

sucesso no ambiente de negócios mas nenhuma, até agora, teve tanta

penetração em ambos os mundos quanto a BPMN (Business Process Model

and Notation) (OMG, 2013).

Por outro lado uma notação matemática, formal e simples como Redes

de Petri (RdP) (Reisig, 2013), apesar do poder de concisão e da possibilidade

de verificação matemática dos fluxos gerados não obteve tanta penetração em

nenhum dos dois ambientes, ficando restrita a nichos e ao ambiente acadêmico

de pesquisa.

1.1 Contexto e Motivação

As notações de fluxo de trabalho (workflow em inglês) são bastante

comuns nas tentativas de mapeamento dos processos de trabalho dos mais

diversos campos, e várias dessas notações surgem a cada dia, cada uma com

suas características, forças e fraquezas.

Toda notação criada tem seus pontos fortes e seus pontos fracos,

algumas tem artefatos simples e bem definidos mas pouco funcionais, outras

tem artefatos funcionais mas complexos. Há as que tem uma forte notação

20

matemática enquanto outras tem um forte componente empírico. Muitas dessas

forças e fraquezas são complementares.

Outro aspecto importante é a análise de desempenho dos workflows.

Apesar da BPMN já possuir algumas formas de avaliar os processos

mapeados, e principalmente de algumas ferramentas possuírem formas de

avaliar automaticamente esses processos, essas técnicas ainda estão em fase

inicial, ao passo que no ambiente das redes de Petri e particularmente nas

GSPN (Generalized Stochastic Petri Nets) (Marshan, Balbo, Conte, Donatelli, &

Franceschinis, 1998) existem algumas técnicas de avaliação já bem

consolidadas que podem ser auxiliares às técnicas de BPMN ou uma forma de

validação de resultados obtidos nas novas técnicas de avaliação criadas para

BPMN.

1.2 Caracterização do Problema

É nesse contexto que essa pesquisa se apresenta: um estudo

teórico/prático com o objetivo de criar uma forma de transformar um diagrama

de fluxo de trabalho de uma notação de negócios (no caso BPMN) em outro

diagrama de fluxo de trabalho com um aspecto matemático mais formal como

as GSPN.

Posto de outra forma, a proposta desse trabalho é prover uma maneira

de transformar um workflow desenhado em BPMN em um modelo baseado e

em RdP (mais especificamente uma GSPN), e assim tornar possível a análise

do workflow utizando técnicas dessa rede de destino.

A principal contribuição dessa proposta é que será feita

automaticamente uma conversão que, atualmente é executada manualmente,

facilitando o estudo do comportamento de processos BPMN mapeados em

uma rede de Petri.

21

1.3 Objetivos

Nesta seção serão descritos os objetivos deste trabalho, separados

entre objetivo geral e objetivos específicos.

1.3.1 Objetivo Geral

O objetivo geral desta dissertação e criar uma metodologia de

transformação de um processo de negócio de uma notação BPMN para um

processo em Redes de Petri, tornando possível que métodos de avaliação de

desempenho já estabelecidos para as GSPN sejam aplicados a um processo

gerado a partir de um outro inicialmente criado em BPMN. Dessa forma é

possível que se desenhe um processo em BPMN, um formato mais amigável

ao analista de negócio e que se teste sua eficácia e eficiência em um modelo

GSPN.

1.3.2 Objetivos Específicos

Para atingir o objetivo geral desta dissertação, alguns objetivos

específicos foram perseguidos no decorrer do desenvolvimento deste trabalho.

Foram eles:

Analisou-se os detalhes estruturais das notações BPMN e RdP

para tornar possível a criação da estrutura de classes das duas

notações e, dessa forma ter essa estrutura descrita em uma

linguagem de programação.

Criou-se um pacote que extrai um fluxo de um arquivo gravado

em uma notação e transforme esse fluxo em objetos das classes

definidas no primeiro passo.

Definiu-se uma forma de mapear objetos de uma notação para

outra, baseado em modelos propostos em trabalhos anteriores,

adicionando-se contribuições próprias ao modelo, de forma que

22

os resultados de saída sejam os mesmos para as mesmas

entradas em ambas as notações.

Criou-se um pacote que faz a transformação dos objetos obtidos

a partir do fluxo anteriormente gerado, aplicando o mapeamento

definido e com isso gerando um arquivo que possa ser lido e

utilizado por uma ferramenta da notação de destino.

Testou-se as transformações definidas usando as ferramentas de

desenho de cada notação para verificar a corretude e a

capacidade de transformação dos mapeamentos definidos e

programados.

Aplicou-se métodos de análise de desempenho nas redes GSPN

geradas a partir das redes BPMN.

Testou-se o uso do protótipo em, pelo menos, um estudo de caso.

1.4 Trabalhos Relacionados

Para a realização deste documento alguns trabalhos foram analisados,

dentre eles (Oliveira, 2008). O referido trabalho propõe a criação de um modelo

baseado em GSPN para a respresentação de workflow, a partir de uma parte

das idéias desse trabalho forma geradas boa parte das transformações do

presente trabalho.

Outro trabalho que foi estudado e avaliado tanto a sua parte teórica

quanto a ferramenta que foi gerada é o trabalho de (André, 2009), no qual é

criado um compilador que transforma uma especificação BPEL (Business

Process Execution Language) (White, 2005) para GSPN. A ideia foi uma das

inspirações para o trabalho atual embora a implementação não seja a mesma.

O trabalho de (Vasconcelos, 2012) utiliza o trabalho de (Oliveira, 2008)

para definir uma forma de avaliação de processos de desenvolvimento de

software. Este trabalho foi usado nos testes do protótipo, embora não conste

no estudo de caso.

23

Varias transformações de BPMN para alguma outra notação foram alvo

de estudos. Uma das transformações mais populares encontradas durante a

pesquisa foram as transformações envolvendo BPMN e BPEL. No trabalho de

(White, 2005) o autor propõe um mapeamento de BPMN para BPEL, (Ouyang,

Dumas, Hofstede, & Aalst, 2006) propõe o mapeamento de BPMN para web

services BPEL e (Recker & Mendling, 2006) são analisam as características

das transformações entre BPMN e BPEL.

No trabalho de (Remco M. Dijkman, 2008) os autores propõem uma

semântica formal para a BPMN criando mapeamentos para redes de Petri e

gerando códigos em PNML (Petri Net Markup Language). Parte desse estudo

foi aproveitado para o presente trabalho. Uma semântica também é proposta

por (Takemura, 2008) e também utiliza redes de Petri para esse propósito mas,

no trabalho citado, restringe-se a transações e suas compensações.

Outros trabalhos também foram avaliados em menor grau para a

elaboração deste trabalho no entanto a lista apresentada tem a relação dos

trabalhos mais relevantes e mais significativos para que os objetivos fossem

alcançados.

1.5 Estrutura do Documento

Esta dissertação está organizada da seguinte maneira:

Capítulo 2: são explicados em uma breve introdução alguns dos

fundamentos de programação e as linguagens utilizadas no desenvolvimento

do protótipo. Capítulo 3 apresenta uma breve introdução aos processos de

negócios e notações de workflow, particularmente as duas notações utilizadas

no desenvolvimento do trabalho. Capítulo 4 são apresentadas rapidamente as

ferramentas que servirão como base para os testes definidos e criados durante

a execução do trabalho. Capítulo 5 está descrita a execução do trabalho em si,

com todas as dificuldades e decisões que nortearam essa dissertação. Capítulo

6 é apresentada a aplicação das transformações desenvolvidas no trabalho em

um estudo prático. Capítulo 7 são apresentadas as conclusões, contribuições

deste trabalho assim como as sugestões para trabalhos futuros.

24

Capítulo 2

Fundamentos de programação

Nesta seção serão apresentadas brevemente algumas das tecnologias

utilizadas para a elaboração prática do presente trabalho. Não se pretende aqui

fazer uma análise profunda de nenhum dos tópicos apresentados,

principalmente em relação aos itens mais genéricos como Java e XML. Optou-

se por uma maior ênfase na apresentação do JAXB por que ele engloba os

conceitos de Java e XML.

Uma consideração inicial que servirá a todos os capítulos desse

documento é que sempre que se usar a palavra “deve” isso indicará que o item

mencionado é obrigatório e sempre que se usar a palavra “pode”, isso indicará

um item opcional.

2.1 Java

Não se pretende nessa seção fazer uma apresentação de Java uma vez

que um resumo seria desnecessário e redundante e não seria capaz de

apresentar devidamente a tecnologia. Será feita apenas uma apresentação das

características da linguagem que fizeram com que fosse escolhida para o

desenvolvimento do protótipo.

Java é uma linguagem de programação multiplataforma, orientada a

objetos e gratuita. Dentre suas características destacam-se simplicidade,

robustez, segurança, portabilidade e alto desempenho (Horstmann & Cornell,

2012).

A sua escolha como elemento de programação para a elaboração do

presente trabalho se deu também por sua popularidade e consequente

possibilidade de continuidade do trabalho aqui iniciado. Além disso, a base de

25

conhecimento anterior é composta por protótipos desenvolvidos também nessa

linguagem, adicionando-se o fato de que boa parte das ferramentas de

modelagem de processos foram desenvolvidas e são mantidas nessa

linguagem, tais como Oracle BPM, Bonita Open Solution, TimeNet e outras

2.2 XML

A Extensible Markup Language (XML) é uma caixa de ferramentas de

armazenamento de dados, um veículo configurável para transportar qualquer

tipo de informação, um padrão aberto e em evolução que vem sendo adotado

por vários tipos diferentes de usuários (Ray, 2001).

Atualmente o padrão XML tem aplicação nas mais diversas áreas, desde

programação para celulares, bancos de dados, web services e como extensão

de linguagens de apresentação como o HTML. As vantagens do uso de XML

são muitas (Ray, 2001):

Organizar qualquer tipo de informação em qualquer tipo de

organização dos dados;

Como um padrão aberto ela pode ser usada livremente;

Como se utiliza unicode como padrão de caracteres ela pode ser

usada em qualquer língua

Os dados gravados usando XML podem ser checados de

diversas formas, como regras de sintaxe, checagem de links

internos, comparação com modelos de documentos e tipos de

dados utilizados.

É fácil de ser lida tanto por máquinas quanto por pessoas.

Pode-se acrescentar como motivo principal (ou na verdade O Motivo) o

fato de que ambas as notações utilizadas neste trabalho serem gravadas nesse

formato pelas ferramentas utilizadas nos testes do protótipo.

26

Um exemplo de um arquivo XML pode ser visto no Código 2.1.

Analisando-o, vê-se na linha 1 o elemento obrigatório que identifica a versão do

XML e identifica o documento como um arquivo XML. A cláusula encoding é

opcional mas recomendável. Nos documentos utilizados nesse trabalho o valor

desse elemento é encoding=”UTF-8”, pois significa que se usa o padrão

unicode para a codificação de caracteres.

Código 2.1: Exemplo de Documento XML. Fonte: (Resfnes Data, 1999)

01

02

03

04

05

06

07

<?xml version="1.0" encoding="ISO-8859-1"?>

<note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget me this weekend!</body>

</note>

Na linha 02 há o elemento raiz (root), que define o documento e que

deve ser fechado na última linha do documento com a adição da barra (no caso

<note> é o elemento raiz e </note> o finalizador do documento.

Nas linhas 03 a 06 estão os elementos filhos (child elements) do

elemento raiz. Esse documento segue regras, das quais algumas são listadas

abaixo (W3C, 2010):

Todos os elementos devem ser fechados ou marcados como

vazios.

Elementos vazios podem ser fechados normalmente (exemplo:

<from></from>) ou pode ser usada a forma curta (<from />).

Os elementos podem conter atributos mas o valor atribuído a eles

deve estar entre aspas (ex.: <heading title=”Titulo”>).

Todo documento XML deve ter um elemento raiz (root element)

que deve englobar todos os outros elementos com um

componente de abertura e um de fechamento no início (após o

cabeçalho) e no final do documento (ex.: <note> e </note>).

27

Qualquer elemento pode ter elementos filhos e elementos do

mesmo nível são chamados de irmãos.

No Código 2.2 está representado um exemplo de XML para o

armazenamento de uma biblioteca. Neste exemplo o termo <biblioteca> é o

elemento raiz, fechando o documento no final com </biblioteca>, possuindo o

elemento <livro> como seu elemento filho, possuindo esse, por sua vez os

elementos <titulo>. <autor>, <ano> e <preco>. Os elementos <livro> e <titulo>

possuem os atributos categoria e língua, respectivamente.

É importante ressaltar que o XML não define nenhuma tag, ficando a

cargo do usuário criar suas próprias tags, conforme sua necessidade, seguindo

as regras já citadas. Segundo (Marchal, 2000) esse é o X da XML, ela é

extensível porque permite que o autor crie as tags necessárias para a sua

aplicação.

Código 2.2: Um XML de uma livraria. Fonte: Adaptado de (Resfnes Data, 1999)

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

19

20

21

<?xml version="1.0" encoding="UTF-8"?>

<livraria>

<livro categoria="CULINÁRIA">

<titulo lingua="inglês">Cozinha

Italiana</titulo>

<autor>Giada De Laurentiis</autor>

<ano>2005</ano>

<preco>30,00</preco>

</livro>

<livro categoria="INFANTIL">

<titulo lingua="inglês">Harry Potter</titulo>

<autor>J K. Rowling</autor>

<ano>2005</ano>


</livro>

<livro categoria="WEB">

<titulolingua = inglês ">

Learning XML

</titulo>

<autor>Erik T. Ray</autor>

<ano>2003</ano>


</livro>

</livraria>

28

2.2.1 Validação de XML

Um XML com a sintaxe correta é um XML bem formado (Resfnes Data,

1999). Para validar um documento XML deve ser definido uma DTD (Document

Type Definition) para esse arquivo. Um determinado DTD conterá as regras

para validar um documento XML específico.

No código 2.3 pode-se ver o DTD correspondente ao XML definido no

código 2.1.

Código 2.3: Um exemplo de DTD. Fonte: (Resfnes Data, 1999)

01

02

03

04

05

06

07

08

<!DOCTYPE note

[

<!ELEMENT note (to,from,heading,body)>

<!ELEMENT to (#PCDATA)>

<!ELEMENT from (#PCDATA)>

<!ELEMENT heading (#PCDATA)>

<!ELEMENT body (#PCDATA)>

]>

Para fazer uso desse DTD é necessário que o Código 2.1 seja

modificado para o código exibido no Código 2.4, com isso o parser XML será

instruído a verificar o documento comparando o que está construído com a

regra definida no DTD. Não será considerado para o escopo desse trabalho um

estudo sobre a formação do DTD. Na linha 2 da listagem há a referência ao

DTD previamente criado (gravado com o nome “note.dtd”)

Código 2.4: Exemplo do código 2.1 com o DTD.

01

02

03

04

05

06

07

08

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE note SYSTEM "Note.dtd">

<note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget me this weekend!</body>

</note>

29

2.2.2 Entendendo Namespaces

Um outro conceito bastante utilizado neste trabalho é o de namespaces.

Segundo (McLaughlin & Edelson, 2007) Um namespace em XML é um meio de

se associar um ou mais elementos em um documento XML com uma URI

(Universal Resource Identifier). Isso se faz necessário para que um mesmo

nome, utilizado em notações diferentes não entrem em conflito, como no

exemplo do código 2.5, no qual a tag autor existe em dois diferentes

namespaces.

Código 2.5: Exemplo de uso de namespaces

01

02

03

04

05

06

07

08

…

<rdf:RDF xmlns:rss="http://www.w3.org/1999/02/22-rdf-

syntax-ns#"

xmlns:jornal="http://www.neilgaiman.com/entries">

…

<rss:autor>Maria</rss:autor>

<jornal:autor>Manoel</jornal:autor>

…

Tendo visto o básico para o entendimento dos arquivos XML utilizados

no decorrer do trabalho, somente serão tratados aspectos quanto a esse tópico

quando necessários para o esclarecimento de algum item em particular.

2.3 JAXB

Segundo (Ballem, 2011), JAXB (Java Architeture for XML Binding) “e

uma biblioteca Java que possibilita a conversão de arquivos XML em objetos

java ou vice-versa”.

A utilização de JAXB simplifica a transformação de arquivos XML em

Java e de objetos Java em arquivos XML usando o núcleo da sua API com

interfaces definidas como Marshaling, Unmarshalling e validação de arquivos,

utilizando conceitos de Java como objetos POJO e anotações (McLaughlin &

Edelson, 2007).

30

Pode-se trabalhar com o arquivo XML diretamente, criando

manualmente as classes necessárias para a sua manipulação ou se pode usar

um arquivo DTD (Document Type Definition) e o comando de linha xjc, sendo a

função deste comando a geração das classes a partir da estrutura definida no

arquivo DTD. As principais anotações do JAXB estão listadas na Tabela 2.1.

À geração das classes Java a partir de um documento DTD dá-se o

nome de binding, um procedimento de linha de comando utilizando o comando

xjc. A partir de parâmetros e da correta indicação dos arquivos se consegue as

extrair as classes e seus relacionamentos (Java Arquiteture for XML Biding

(JAXB), 2009).

Tabela 2.1: Relação de algumas das anotações JAXB. Adaptado de (Ballem, 2011).

Anotação Função

@XmlRootElement Indica a classe que representa o elemento raiz do documento XML.

@XmlAcessorType Indica se as anotações estão nos atributos ou nos métodos das classes POJO.

@XmlType Indica a informação que a classe mapeia no arquivo XML.

@XmlElement Relaciona um atributo ou método a uma tag do documento XML.

@XmlElementWrapper Mapeia um objeto do tipo lista

No caso da geração das classes usando o comando xjc as classes

geradas (a partir da versão 2.0 do JAXB) serão POJOS anotados (McLaughlin

& Edelson, 2007).

Para executar o procedimento de unmarshal de um documento XML é

necessário que antes seja criado um contexto JAXB. A função do unmarshal é

transpor os dados contidos no arquivo XML para objetos instanciados a partir

das classes anotadas criadas.

Os objetos criados podem ser manipulados como qualquer objeto POJO

de Java, podendo assim passar as alterações para um novo arquivo XML (ou

31

alterar o mesmo arquivo). Esse processo é definido como marshalling (JAXB

user Guide, 2010).

2.4 Considerações Finais

Nesse capítulo foram introduzidos os conceitos computacionais básicos

das linguagens usadas no presente trabalho. Não se pretendeu cobrir todos os

aspectos de cada uma das tecnologias envolvidas, mas apenas dar uma noção

básica para que ao se mencionar tais tecnologias não se perca tempo em

definições básicas nos capítulos que narram a execução do projeto em si.

32

Capítulo 3

Processos de Negócios

O trabalho nas empresas é guiado por processos de negócios, mesmo

quando estas não os controlam ou não se dão conta de como esses processos

se desenrolam, todo produto ou serviço oferecido por uma empresa está

apoiado em um ou vários processos de negócios (Gonçalves, 2000).

Em uma definição formal um processo é um conjunto de atividades

executadas em uma sequência lógica para produzir um bem ou serviço que

terá alguma validade para um grupo de clientes (Gonçalves, 2000).

Existem fluxos de processo que não tem uma sequência definida, nos

quais os passos a serem executadas não são previsíveis e as atividades não

seguem nenhum fluxo, podendo ocorrer em qualquer ordem e a qualquer

momento. Este tipo de processo não faz parte do conjunto do qual este

trabalho trata.

Os processos que podem ser melhorados de alguma forma são aqueles

nos quais as etapas são previsíveis mas não necessariamente determinadas.

Estes são os processos de interesse deste trabalho. Exemplos desse tipo de

processo podem ser: A obtenção de um título de propriedade em um órgão

público, a abertura de uma conta em um banco ou o processo de fabricação de

um carro. Todos esses processos possuem etapas conhecidas e bem definidas

mas a sua execução pode ser influenciada por fatores externos.

Outro conceito importante a ser elucidado é a diferença entre processos

e projetos. Uma vez que um processo é uma atividade habitual, repetível e

controlada, um projeto é uma atividade particular, única e portanto imprevisível

quanto ao seu início e ao seu final.

33

3.1 Gerenciamento de Processos de Negócios

As organizações atuais precisam entender os seus processos para que,

uma vez os tenha entendido, possam providenciar meios de aprimorá-los para

redesenhá-los. É basicamente desse processo de conhecimento, melhoria e

redesenho do qual trata a BPM (Business Process Management), mas nesse

ponto deve-se ter em mente que BPM não é uma solução de software como

vários vendedores de tecnologia podem dar a entender, mas uma metodologia

que pode ser definida como em (Jeston & Nelis, 2008): a realização dos

objetivos de uma organização através da melhoria, gestão e controle dos

processos de negócios essenciais.

Dentre outras características (Jeston & Nelis, 2008) afirma ainda que

BPM é mais do que modelar, também é sobre a execução de processos, tarefa

essa que requer análise.

Um processo de negócio pode ser entendido, mapeado e analisado

empiricamente. Pode-se avaliar sua eficiência e eficácia através da observação

da sua execução, no entanto, nem sempre isso é possível, rápido, barato ou

simples.

Outro ponto importante é a adoção de uma visão de processos em todos

os níveis, desde o acompanhamento do desempenho de cada participante até

o planejamento estratégico a longo prazo. Os processos devem estar alinhados

à estratégia da empresa. Para isso é preciso que todos passem a ter a visão

processual e não a departamental tradicional. Tendo como objetivo não só

entender mas melhorar os processos aos quais lhe são atribuídas as

responsabilidades.

É nesse ponto que as ferramentas de avaliação são úteis, elas podem

prover uma forma mais rápida, eficiente e segura de analisar um processo.

3.2 Definições e terminologias

Algumas definições serão importantes para o entendimento do trabalho,

além do entendimento do conceito de processo. São elementos que fazem

34

parte de qualquer processo para que o mesmo seja eficaz. São eles (Oliveira,

2008):

Instância de Processo ou Case: Representa uma execução em

particular de um processo. O termo Case é utilizado em modelos formais e

poderá ser usado concomitante à expressão instância de processo.

Atividade: É o equivalente a uma unidade de trabalho, uma parte da

execução delimitada, encapsulada mas não necessariamente indivisível.

Participante: É algo ou alguém que executa uma atividade de um

processo. Geralmente é tratado como um recurso a ser consumido durante a

execução de um processo

Instância de Atividade: É uma execução particular de uma atividade,

em outras palavras é uma atividade sendo executada em determinado instante.

Papel: É a definição dada a um grupo de recursos que representam as

mesmas qualidades, atributos e habilidades. Um cargo, um departamento ou

qualquer outro conjunto que defina um conjunto de participantes, pode definir

um papel.

Worklist: Uma lista de itens aguardando que um participante o execute

em uma atividade. Cada item da lista é executado pelo participante quando o

mesmo estiver livre para executar uma instância da atividade, quando isso

ocorre o participante informa da necessidade de se tirar o item da worklist.

Work Item: Cada item que compõe uma work list.

Subprocesso: Um processo interno a outro processo. Geralmente

subprocessos são utilizados na modularização de processos, permitindo, assim

o reuso de estruturas comuns a vários processos.

Evento: A ocorrência de algo independente do sistema e externo a este.

A ocorrência de um evento está relacionada a dois elementos: um gatilho, que

define as condições necessárias para que o evento corresponda a uma ação e

a ação, que corresponde à resposta do sistema ao disparo do gatilho.

35

Exceção: É um evento que cujo gatilho é um erro na execução do

processo e a ação é um procedimento de recuperação.

A Figura 3.1 representa o relacionamento entre esses elementos.

Figura 3.1: Relacionamento entre os principais elementos de um processo. Fonte: (Oliveira, 2008)

3.2.1 Estruturas de Controle de Fluxo

Além dos elementos apresentados anteriormente devem ser destacados,

os elementos que dão a verdadeira força das notações de workflow: as

estruturas que controlam o fluxo, fazendo com que se possa mapear não só um

fluxo linear e inflexível, mas todas as possibilidades de um determinado

processo.

As principais estruturas comuns a diversos workflows são:

36

Escolha (Xor): Representa um ponto em que o fluxo se divide em

vários caminhos cuja execução é exclusiva, ou seja, se um fluxo

for executado os outros não o serão.

Fusão ou Junção: São pontos onde fluxos paralelos, exclusivos

ou não se encontram para dar prosseguimento a um único

caminho.

Paralelismo (And): É um ponto de desvio do fluxo no qual um

único fluxo se divide em vários (dois ou mais) que serão

executados simultaneamente.

Iteração: corresponde à repetição de um fluxo dentro de um

mesmo case.

Para o escopo deste trabalho, as estruturas de fusão, quando unem

fluxos paralelos também representam um ponto onde tais fluxos serão

sincronizados.

3.3 Abordagens para o desenho de processos

Existem diversas abordagens para o desenho de processos, entre várias

pode-se citar Diagrams de atividades da UML (Unified Modeling Language),

XMPL Process Description Language (XPDL), Business Process Execution

Language (BPEL), várias outras representações apresentadas por

pesquisadores ao longo de vários trabalhos (Oliveira, 2008).

As abordagens que serão o centro deste trabalho são BPMN (Business

process Model and Notation) e GSPN (Generalized Stochastic Petri Nets).

3.4 Introdução às Redes de Petri

Modelo proposto por Carl Petri no final do ano de 1950 no Departamento

de Matemática Instrumental da Universidade de Bonn, Alemanha para modelar

a comunicação entre autômatos, representando sistemas baseados em

eventos discretos (Cardoso & Valette, 1997). Redes de Petri são ferramentas

37

gráficas e matemáticas usadas para descrição formal de sistemas. Elas se

caracterizam por propriedades como concorrência, paralelismo, sincronização,

distribuição, assincronismo e não-determinismo.

Na tese “Kommunikation mit Automaten” (Comunicação com autômatos),

Petri demonstrou a possibilidade de construir um sistema que poderia ser

expandido indefinidamente, neste primeiro trabalho o conceito de rede de Petri

era puramente matemático, sem uma representação gráfica (Reisig, 2013).

3.4.1 Componentes das Redes de Petri

Uma Rede de Petri é composta por uma pequena quantidade de

componentes, formando um conjunto compacto de elementos com funções

bem definidas e regras simples.

Tabela 3.1: Elementos básicos de uma Rede de Petri genérica. Fonte: Adaptado de (Reisig, 2013)

Figura Nome - Função

Lugar

Um lugar p (place em inglês) sempre modela um componente passivo, pois pode guardar, acumular ou mostrar coisas. Um lugar tem estados discretos. Um lugar sempre será um elemento circular. Na figura ao lado dois lugares P1 e P2 estão representados.

Transição Uma transição t sempre modela um elemento ativo. Ela produz, consome, transporta ou muda coisas. Uma transição sempre será representada por um elemento retangular.Na figura ao lado há 5 transições nomeadas de T1 a T5.

Arco É o elemento de ligação entre lugares e transições. Um arco nunca liga duas transições ou dois lugares diretamente. Um arco não necessariamente é uma linha reta.Um arco com um círculo na extremidade inibe a ação de uma determinada transição e deve sair de um lugar. Este tipo de arco é utilizado em extensões das RdP, principalmente na GSPN.

38

As Redes mais simples, sem especializações, por exemplo, têm apenas

três tipos de componentes, conforme se vê na Tabela 3.1.

Nesta tabela estão representados os elementos necessários para a

criação de uma rede de Petri, ou seja, é possível modelar determinados

sistemas apenas com esses elementos, no entanto, os modelos resultantes

seriam limitados na sua representação.

Na Tabela 3.2 estão apresentados elementos complementares á

notação básica. São elementos que podem ser omitidos ou excluídos, mas que

trazem mais clareza e torna possível a criação de modelos de redes mais

complexas.

Esses são os elementos básicos que compõem uma rede de Petri. O

seu comportamento é definido pela semântica.

Tabela 3.2: Elementos Complementares à notação Básica de Redes de Petri


Tokens os tokens ou fichas são elementos que geralmente representam algum recurso presente em um lugar específico. O disparo de uma transição poderá criar tokens, assim como destruir tokens de um lugar e construir em outro. Eles são representados geralmente como círculos preenchidos ou como números. A quantidade de círculos indica a quantidade de tokens ou o número representa a quantidade de tokens.

Formalmente, as RdP são um tipo particular de grafo, possuindo um

estado inicial M0, um grafo N, direcionado, ponderado e bipartido, composto por

dois tipos de nós chamados de locais (places, denotados aqui por p) e

transições (transictions, denotados aqui por t), interligados por arcos (a) que

podem conter seus respectivos pesos (k, cujo valor é um inteiro com padrão

mínimo 1 não é indicado na notação). Um arco com peso k deve ser

interpretado como o equivalente a k arcos paralelos e simultâneos. (Murata,

1989).

39

Os arcos ligam transições a lugares e vice-versa, não sendo possível

transições do tipo representado na Figura 3.2 (Reisig, 2013):

Figura 3.2: Principal restrição em Redes de Petri

Neste ponto será possível dar uma definição formal à notação gráfica

apresentada.

Definição 3.1 (Rede de Petri): Segundo (Aalst & Stahl, 2011) uma rede

de Petri é 𝑢𝑚 𝑡𝑟𝑖𝑜 𝑁 (𝑃, 𝑇, 𝐹), 𝑛𝑜 𝑞𝑢𝑎𝑙:

1. 𝑃 é 𝑢𝑚 𝑐𝑜𝑛𝑗𝑢𝑛𝑡𝑜 𝑓𝑖𝑛𝑖𝑡𝑜 𝑑𝑒 𝑙𝑢𝑔𝑎𝑟𝑒𝑠;

2. 𝑇 é 𝑢𝑚 𝑐𝑜𝑛𝑗𝑢𝑛𝑡𝑜 𝑓𝑖𝑛𝑖𝑡𝑜 𝑑𝑒 𝑡𝑟𝑎𝑛𝑠𝑖çõ𝑒𝑠;

3. 𝐹 ⊆ (𝑃 × 𝑇) ∪ (𝑇 × 𝑃) é 𝑢𝑚𝑎 𝑟𝑒𝑙𝑎çã𝑜 𝑑𝑒 𝑓𝑙𝑢𝑥𝑜.

Embora a definição 3.1 sirva para os elementos básicos, alguns

conceitos já citados carecem de definição.

Figura 3.3: Semáforo único representado em uma Rede de Petri.

Na Figura 3.3 há um exemplo de uma rede de Petri que atende à

definição 3.1. Ela é uma RdP que representa a transição de luzes de um

semáforo e foi adaptada de (Aalst & Stahl, 2011). Neste exemplo os lugares

Vermelho, Verde e Amarelo representam os estados das luzes acesas do

40

semáforo. As transições V2V, V2A e A2V representam as transições da luz

Vermelha para a Verde, da Verde para a Amarela e da Amarela para a Verde.

Na Figura 3.3 existe um elemento para o qual não foi dada uma

definição formal (embora os tokens estejam no Quadro 3.2).

Definição 3.2 (Marcação): Uma marcação de uma rede de Petri (𝑃, 𝑇, 𝐹)

é uma função 𝑚: 𝑃 → ℕ, atribuindo a cada lugar 𝑝 𝜖 𝑃 o número 𝑚(𝑝) de tokens

a esse lugar. O conjunto M de todas as marcações desta rede é o conjunto

dessas funções (Aalst & Stahl, 2011).

Com este conceito em mãos pode-se definir mais um termo.

Definição 3.3 (habilitação): Em uma rede de Petri(𝑃, 𝑇, 𝐹), uma

transição 𝑡 ∈ 𝑇 estará habilitada se houver uma quantidade de tokens em seu

lugar de origem de tal modo que o número de tokens seja maior ou igual à

cardinalidade do arco de origem desse lugar.

Um outro conceito referente a redes de Petri necessário a esse trabalho

é o de disparo de uma transição.

Definição 3.4 (disparo de transição): Para uma rede de Petri(𝑃, 𝑇, 𝐹) ,

sendo 𝑤 a função de peso e 𝑚: 𝑃 → ℕ a marcação atual. Uma transição 𝑡 ∈ 𝑇

pode disparar se e somente se ela estiver habilitada em 𝑚 (Aalst & Stahl,

2011).

E, finalmente, para que as definições básicas necessárias ao presente

trabalho sejam estabelecidas, o conceito das redes de Petri aqui geradas

necessita de mais uma definição:

Definição 3.5 (Sistema de Rede de Petri): Um sistema de Rede de

Petri (𝑃, 𝑇, 𝐹, 𝑀0) consiste em uma Rede de Petri (𝑃, 𝑇, 𝐹) e um conjunto de

marcações iniciais 𝑀0 (Aalst & Stahl, 2011).

As definições vistas nesta seção não são suficientes, nem pretendem

ser, para definir as redes de Petri utilizadas nesse trabalho, uma vez que será

utilizado um subconjunto dessas redes citado anteriormente, as GSPN.

41

3.5 Introdução às Generalized Stochastic Petri Nets

No seu trabalho original Carl Petri não incluiu o conceito de tempo nas

RdP, sendo esse modelo original uma descrição de causalidade no qual um

evento a é a causa de um evento b. Essa é uma forma de se introduzir o

conceito de tempo de forma quantitativa, com isso o conceito de tempo é

associado apenas à sequência de transições. O acréscimo de dados temporais

traz às redes de Petri a variável tempo na parte do controle da rede em vez de

ficar restrito à parte de dados.

Dentre vários outros, existem dois grandes conjuntos de modelos de

redes temporizadas:

Rede de Petri Temporal: a cada transição é associada um par de datas

(min,max), representando, respectivamente uma duração mínima de

sensibilização da transição antes do disparo e o cálculo da duração máxima de

sensibilização.

Rede de Petri Temporizada: Também chamada de rede de Petri com

transição temporizada pois cada transição possui uma duração.

Quando se associa um tempo de duração a uma transição, está se

indicando que essa transição não é mais um evento instantâneo, mas uma

atividade com tempo de início e tempo de fim. Considera-se, entretanto que tal

atividade não é interrompível.

Definição 3.6 (Rede de Petri Temporizada): Uma rede de Petri

temporizada é um par 𝑁𝑡 = {𝑁, 𝜃𝑓}, onde:

N é uma rede de Petri (P, T, F) com marcação M0;

𝜃𝑓: 𝑇 → ℚ+ é a função duração de disparo, que associa a cada

transição um número racional positivo que descreve a duração do

disparo.

42

Definição 3.7 (Rede de Petri Temporal): Uma rede de Petri temporal é

um par 𝑁𝑡𝑙 = {𝑁, 𝐼}, onde:

𝑁 é uma rede de Petri (𝑃, 𝑇, 𝐹) com marcação 𝑀0;

𝜃(𝑡) = [𝜃𝑚𝑖𝑛(𝑡), 𝜃𝑚𝑎𝑥(𝑡)] é uma função que, a cada transição 𝑡

associa um intervalo fechado racional que descreve uma duração.

A introdução de tempo no formalismo das redes de Petri permitiu a

definição das redes de Petri estocásticas, uma extensão proposta que permite

a análise de desempenho. As redes de Petri estocásticas (Stochastic Petri Nets

– SPN) diferem das redes temporizadas e temporais pelo fato de que nas SPN

os tempos associados às transições são distribuídos exponencialmente.

Às SPN foram acrescentadas as transições imediatas, que são, como o

nome indica, transições que são disparadas imediatamente após serem

habilitadas, com tempo de atraso para a execução com valor nulo. Nesse tipo

de RdP podem ser atribuídas às transições níveis de prioridade, sendo que a

prioridade de disparo das transições imediatas é superior à das transições

temporizadas. As prioridades das transições imediatas podem ser diferentes

entre si para solucionar situações de conflito. As redes de Petri estocásticas

generalizadas podem ser consideradas redes isomórficas às SPN, portanto a

próxima definição é a de GSPN (Marshan, Balbo, Conte, Donatelli, &

Franceschinis, 1998).

Os termos presentes na Definição 3.8 caracterizam as GSPN e as

diferenciam das redes de Petri puras. Esse é a subclasse de RdP que foi alvo

da transformação neste trabalho.

A função de peso representa o peso (𝑤𝑡) das transições imediatas e a

taxa (𝜆𝑡) das transições temporizadas.

43

Definição 3.8 (Rede de Petri Estocástica Generalizada): Uma GSPN

é definida como uma 8-tupla 𝐺𝑆𝑃𝑁 = (𝑃, 𝑇, Π, 𝐼, 𝑂, 𝐻, 𝑀0, 𝑊), onde:

𝑃 é 𝑜 𝑐𝑜𝑛𝑗𝑢𝑛𝑡𝑜 𝑑𝑒 𝑙𝑢𝑔𝑎𝑟𝑒𝑠;

𝑇 é 𝑜 𝑐𝑜𝑛𝑗𝑢𝑛𝑡𝑜 𝑑𝑒 𝑡𝑟𝑎𝑛𝑠𝑖çõ𝑒𝑠, 𝑃⋂𝑇 = ∅;

Π ∶ 𝑇 → ℕ é 𝑢𝑚𝑎 𝑓𝑢𝑛çã𝑜 𝑝𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑𝑒, 𝑜𝑛𝑑𝑒:

Π(t) = {≥ 1, 𝑠𝑒 𝑡 é 𝑢𝑚𝑎 𝑡𝑟𝑎𝑛𝑠𝑖çã𝑜 𝑖𝑚𝑒𝑑𝑖𝑎𝑡𝑎;

0, 𝑐𝑎𝑠𝑜 𝑐𝑜𝑛𝑡𝑟á𝑟𝑖𝑜}

𝐼 ∶ (𝑇 × 𝑃) → ℕ 𝑠ã𝑜 𝑜𝑠 𝑎𝑟𝑐𝑜𝑠 𝑑𝑒 𝑒𝑛𝑡𝑟𝑎𝑑𝑎;

𝑂 ∶ (𝑇 × 𝑃) → ℕ 𝑠ã𝑜 𝑜𝑠 𝑎𝑟𝑐𝑜𝑠 𝑑𝑒 𝑠𝑎í𝑑𝑎;

𝐻 ∶ (𝑇 × 𝑃) → ℕ 𝑠ã𝑜 𝑜𝑠 𝑎𝑟𝑐𝑜𝑠 𝑖𝑛𝑖𝑏𝑖𝑑𝑜𝑟𝑒𝑠;

𝑀𝑜 ∶ 𝑃 → ℕ é 𝑎 𝑓𝑢𝑛çã𝑜 𝑑𝑒 𝑚𝑎𝑟𝑐𝑎çã𝑜 𝑖𝑛𝑖𝑐𝑖𝑎𝑙;

𝑊 ∶ (𝑇 × (𝑃 → ℕ)) → ℝ+∗1

é 𝑎 𝑓𝑢𝑛çã𝑜 𝑑𝑒 𝑝𝑒𝑠𝑜;

Elementos novos foram introduzidos nessa definição sem uma prévia

explicação do que se tratam. Descrevendo em termos simples tem-se os

conceitos de:

Transições temporizadas: São transições cujo disparo ocorre após um

período que tem uma distribuição estocástica e cuja execução dura um tempo

definido (um delay).

Transições imediatas: São as mesmas transições que já existiam nas

redes de Petri, mas foram renomeadas para diferenciar das transições

temporizadas. Essas transições têm precedência de execução sobre as

transições temporizadas.

Arcos inibidores: São arcos cuja origem é em um Lugar (p) e cujo

destino é uma Transição (t), sempre que o lugar (p) possuir uma marcação

(token) que seja igual ou superior ao peso (w) do arco então o arco impedirá

1 ℝ+

∗ são os reais não negativos.

44

que a transição T dispare. Na Figura 3.4 o lugar P1 impede que a transição T1

dispare, mesmo com o lugar P0 a habilitando.

Figura 3.4: Um exemplo de arco inibidor

Uma característica importante das GSPN é quanto ao seu

comportamento quando múltiplos tokens habilitam uma transição, permitindo

mais de um disparo nessa transição, quando isso ocorre a transição irá se

comportar de acordo com um dos comportamentos a seguir:

Single server: as marcações são processadas em série. Logo após o

primeiro disparo da transição, o temporizador reinicia como se ela tivesse sido

habilitada de novo.

Multiple server: as marcações são processadas com um grau máximo

K de paralelismo. Caso o grau de habilitação seja maior do que K, nenhum

novo temporizador será criado para processar o tempo para o novo disparo até

que o grau de habilitação tenha diminuído abaixo de K. Os componentes

excedentes ficarão em fila.

Infinite server: o valor de K é infinito, todas as marcações são

processadas em paralelo, e as temporizações associadas são decrementadas

a zero em paralelo.

As definições dadas até o momento são suficientes para o objetivo

dessa seção que é definir as GSPN.

45

3.6 Introdução à BPMN

BPMN (Business Process Model and Notation) é a sigla em inglês para

Notação e Modelo de Processo de Negócio e é um dos modelos de mais

aceitação tanto entre os profissionais que estão mais distantes da tecnologia

quanto para os profissionais de tecnologia.

Segundo (Reis, 2008) BPMN é um padrão em evolução, mas é uma das

notações que mantém a maior concordância com a indústria . Apesar disso, ela

não tem nenhum formato de armazenamento específico totalmente

desenvolvido, assim como falta a conclusão de especificação matemática

formal que permita uma real avaliação de um processo de negócio, como é

possível com outras notações de workflow.

Há um candidato forte a esse posto: BPEL (Business Process Execution

Language) (Sarang, Juric, & Mathew, 2006), no entanto esse não foi um

formato criado juntamente com a BPMN, mas apenas adaptado (e adaptando-

se) ao formato gráfico como uma linguagem de execução auxiliar. Há iniciativas

de mapear processos BPMN para BPEL mas os dois formatos têm propósitos

diferentes. Neste trabalho não será tratada a relação entre BPMN e BPEL,

apesar de uma boa quantidade de pesquisas com a intenção de mapear BPMN

para um processo BPEL como em (White, 2005).

3.6.1 A Especificação BPMN

Segundo (OMG, 2013) a BPMN tem como objetivo primário prover uma

notação que seja facilmente compreensível desde os analistas de negócios que

criam os rascunhos do processo, passando pelos desenvolvedores

responsáveis por implementar essa tecnologia até o profissional de negócio

responsável pelo gerenciamento e monitoramento desse processo.

Outro objetivo citado por (OMG, 2013) é que a linguagem XML

desenhada para a execução de processos, tais como WS-BPEL (Web Services

Business Execution Language), seja visualizada por uma notação voltada a

negócios.

46

Muitos softwares foram construídos com o objetivo de atingir os objetivos

propostos acima. Apesar de muitos atingirem razoavelmente bem a primeira

parte: a conformidade com os elementos gráficos e sua utilização nos

diagramas, a grande maioria falha em algum ponto no momento de automatizar

ou de adotar medidas de cálculo para a melhoria de processos, uma vez que a

conformidade com a execução dos processos não é um item obrigatório para

que uma ferramenta BPMN esteja de acordo com a especificação da OMG.

Neste trabalho não serão abordados elementos de coreografia,

colaboração, conversação ou de dados da BPMN, portanto serão descritos,

para fins de conformidade com os objetivos do trabalho, apenas os elementos

da BPMN utilizados no desenvolvimento.

A documentação de BPMN disponível no site www.omg.org não impõe

limitações quanto ao uso de cores, tamanhos ou posição de texto dos

elementos da BPMN, além de permitir extensões próprias de cada ferramenta.

Quando necessário serão exibidos elementos específicos ou com visual

específico da ferramenta BonitaStudio (ou Bonita Open Solution, como é

chamada nas versões mais recentes), descrita no Anexo A, mas, sempre que

possível, os exemplos usando BPMN serão em preto e branco.

Este trabalho está baseado na versão 2.0.1 da BPMN, cuja

especificação foi disponibilizada no site da OMG em setembro de 2013. Este

documento é, em muitos aspectos similar a sua versão de março de 2013, a

qual foi a fonte inicial de informação.

Existem três tipos de submodelos na BPMN:

Processos, que incluem:

o Processos privados internos não executáveis

o Processos privados internos executáveis

o Processos públicos

Coreografias

47

Colaborações.

Este trabalho concentra-se em processos privados internos (executáveis

ou não). Mais detalhes sobre esses tipos de modelos podem ser obtidos em

(OMG, 2013).

3.6.2 Elementos Básicos da Business Process Model and Notation

Nessa seção serão descritos os elementos básicos da BPMN,

apresentados na Tabela 3.3, a partir dos quais serão apresentadas as suas

variações e subdivisões nas seções posteriores. Por exemplo: Os eventos da

Tabela 3.3 se dividem em iniciais, intermediários e finais e estes, por sua vez

tem subdivisões. O detalhamento dos elementos importantes para esse

trabalho será apresentado em sequencia.

Os conceitos serão apresentados dentro do escopo desse trabalho, ou

seja, serão definidos os elementos em função de processos. Alguns elementos

não pertencentes ao escopo serão apresentados apenas como citação. Em

todas as definições serão apresentados os nomes dos elementos na língua

inglesa entre parênteses.

Tabela 3.3: Elementos básicos da BPMN


Evento (Event)

Um evento é algo que pode determinar o início de um processo, ocorrer durante sua execução (interrompendo ou não sua execução) ou definir o fim ou a terminação do sistema.2 Existem 3 tipos de eventos: de início, intermediário e final.

Atividade (Activity)

É um termo genérico para o trabalho realizado em um processo. É o elemento central da ação do processo. Uma atividade pode representar uma ação única ou um conjunto de ações. Dois tipos de atividades existentes em um modelo são subprocessos e tarefas.

2O termo terminação será utilizado para determinar a execução de um evento final ou terminal, cujo conceito será explicado mais à frente neste documento.

48

Desvio (Gateway)

É o elemento utilizado para controlar tanto a divergência quanto a convergência de fluxo em um processo. Podem vir em pares, sendo um a divergência e outro a convergência.

Fluxo de sequência (Sequence Flow)

É utilizado para mostra a ordem na qual as atividades serão executadas.

Fluxo de Mensagem (Message Flow)

Um fluxo de mensagem é utilizado para mostrar o fluxo de mensagens entre dois participantes, ou seja, mensagens entre processos diferentes (ou pools diferentes).

Associação (Association)

Uma associação serve para ligar informações e artefatos com os elementos gráficos da BPMN. A Associação poderá ter uma seta, o que indicará o fluxo de dados quando necessário.

Piscina (Pool)3

Uma pool representa um participante de um processo. É um container de elementos BPMN e representa uma swimlane, uma guia para o processo. Uma pool pode apresentar ou não seus elementos internos (os elementos que representam a parte do processo da qual ela é responsável). Pode-se utilizar a pool como sinônimo de um processo, mas não há obrigação em se fazer isso. Algumas traduções utilizam o termo Divisão para pool.

Raia (Lane)

Outro elemento cujo nome usualmente utilizado é o original em inglês. Uma raia representa um partipante de um processo, como as raias de uma piscina. Uma raia pode representar qualquer recurso que atue no processo, mas pode representar um conjunto de participantes. Algumas traduções utilizam o termo Compartimento para o termo. (BPM Offensive, 2013)

Objeto de Dados (Data Object)

Provê informações sobre quais atividades são requeridas para serem executadas e/ou o que elas produzem. Podem representar um único objeto ou uma coleção de objetos.

3O termo piscina não será utilizado por não ser a terminologia comumente utilizada. Apesar disso foi incluída a sua tradução apenas para manter o padrão estabelecido.

49

Mensagem (Message)

É usada para descrever o conteúdo da comunicação entre dois participantes.

Grupo (Group)

Agrupa elementos gráficos que estão em uma mesma categoria

Anotação de Texto (Text Annotation)

Servem para exibir informações adicionais sobre o diagrama BPMN.

3.6.3 Elementos de Processos

A Tabela 3.3 contém os elementos básicos gerais conforme a

especificação BPMN da OMG (OMG, 2013). Nesta seção serão apresentados

elementos específicos mas não exclusivos do subconjunto no qual se

concentra esse trabalho. Serão apresentados apenas os elementos que fazem

parte do presente estudo, ou elementos que não fazem parte mas que sejam

necessários para a compreensão do mesmo.

Neste escopo os elementos podem ser divididos em 4 categorias: (1)

eventos, (2) atividades e (3) desvios, ligados entre si por (4) elementos de

fluxo. Nas seções a seguir são descritas as particularidades de cada uma das

categorias.

3.6.4 Definindo Eventos

Conforme descrito na Tabela 3.4, os eventos representam alguma coisa

que acontece durante o curso de um processo. Eles são divididos em três

tipos, de acordo com o momento em que ocorrem, são eles: eventos de início,

intermediário ou de fim.

50

Tabela 3.4: Tipos de eventos de acordo com o local de ocorrência.


Evento de início Indica o início de um processo. Só pode haver um por processo. Sua existência não é obrigatória, mas se ocorrer obrigará a existência de um evento de fim.

Evento intermediário Pode ocorrer entre um evento de início e um de fim. Mas não pode iniciar nem finalizar um processo

Evento de fim Indica um ponto final do processo. Pode haver mais de um. Não indica a terminação do processo, o que significa que qualquer atividade sendo executada continuará sua execução até atingir seu evento de fim.

Além da classificação pela localização, um evento pode receber

modificadores que lhe adicionam significado, por exemplo: eventos com borda

tracejada indicam que os mesmos não interrompem a execução do processo.

Na Tabela 3.5 há uma relação com todas as possibilidades de modificadores.

Esses modificadores não serão relevantes para o escopo deste trabalho, sendo

apresentados apenas para informação.

Dois tipos merecem comentários à parte. O tipo conector não é

exatamente um evento mas apenas um elemento de ligação do diagrama,

utilizado em diagramas muito extensos, já o tipo Terminal (terminator em

inglês), chamado também de final, quando ocorre em um processo provoca a

paralização de qualquer atividade em execução. Esse e outros dos elementos

apresentados não foram mapeados, os motivos são explicados no capítulo

sobre o desenvolvimento do protótipo.

A forma de ocorrência pode ser de dois tipos: um evento que ocorre no

fluxo normal do processo (e eventualmente ocorrerá na execução normal do

processo) ou um evento acoplado a uma atividade, podendo interromper ou

não a execução da atividade (linha externa tracejada), Essas e outras

diferenças serão vistas nos exemplos das tabelas a seguir.

51

Tabela 3.5: Eventos por tipo de disparador.

Captura Envio Não interrompível

Tipo Inicio Interm. Interm. Final Início Interm.

Mensagem

Temporizador

Erro

Escalável

Cancelamento

Compensação

Condicional

Conector

Sinal

Terminal

Multiplo

Multiplo paralelo

A maioria dos exemplos foram obtidos de (iProcess, 2011), inclusive as

figuras.

Na Tabela 3.6 estão representadas as diferentes formas de se iniciar um

processo (além do início normal sem modificadores). Outros modificadores

existem e seu significado e exemplos podem ser vistos em (OMG, 2013), a

mesma observação vale para os outros exemplos desta seção.

52

Tabela 3.6: Diferentes formas de se iniciar um processo. Fonte: (iProcess, 2011).

Figura Descrição

É o mais comum. Indica apenas o ponto inicial do processo. A regra diz que ele não é obrigatório, mas se ocorrer o processo deve ter, pelo menos, um evento de fim.

Exemplo ao lado a tarefa Planejar Atividades da Semana deverá ocorrer todas as segunda-feiras, ou seja, sempre que for segunda feira o processo será iniciado.

Nesse caso quando um novo currículo for recebido a tarega Avaliar Candidato será executada, iniciando o processo ao qual ela pertence.

A tarefa acionar alarme e consequentemente o processo ao qual ela pertence serão iniciados quando o evento condicional Reator Superaquecido ocorrer.

Os eventos intermediários possuem uma diferenciação na sua

ocorrência, podem pertencer ao fluxo normal do processo como na Figura 3.5

na qual o processo é interrompido por um período, ou seja, após a tarefa

preparar viagem for concluída o processo aguardará até que chegue a data de

início da viagem, quando, então o processo poderá executar a próxima tarefa,

Realizar Viagem.

Figura 3.5: Exemplo de evento intermediário temporal. Fonte: (iProcess, 2011)

No processo da Figura 3.6 também há um temporizador, só que este

está acoplado na borda de uma atividade, isso indica que a ocorrência desse

evento interrompe a execução da tarefa, ou seja, se a tarefa confirmar

53

recebimento de mercadorias ocorrer antes da data prevista de entrega o

processo segue o fluxo normal, caso contrário, a tarefa será interrompida e

será executado o cancelamento do pedido. Nesse tipo de evento podem

acontecer duas situações: a tarefa principal nem ser iniciada (o caso do

exemplo) ou ela ser iniciada e ser interrompida (neste caso, geralmente se trata

de um subprocesso ou atividade não atômica).

Figura 3.6: Evento de borda interrompível. Fonte: (iProcess, 2011)

Outro exemplo de evento intermediário de borda pode ser visto na

Figura 3.7. Trata-se de um evento com suas bordas tracejadas, o que indica

que o mesmo não interrompe a tarefa à qual está acoplado. No exemplo se a

tarefa Avaliar Pedido não for concluída após 2 dias uteis, a tarefa receber aviso

de atraso na avaliação será executada sem prejuízo da execução e finalização

da tarefa avaliar pedido e de todo o restante do processo.

Figura 3.7: Evento intermediário de borda temporal não interrompível. Fonte: (iProcess, 2011)

3.6.5 Definindo Atividades

Atividades são os elementos para os quais os diagramas são

construídos. O objetivo principal de um diagrama BPMN é identificar e detalhar

as atividades de um processo e o relacionamento delas entre si e com os

54

demais elementos presentes na BPMN. É o único elemento da BPMN que tem

um executor (Silver, 2012).

Atividades podem conter marcadores que modificam seu significado. Na

Figura 3.8 estão listados os tipos de marcadores que podem ocorrer nas

atividades.

Figura 3.8: Marcadores de Atividades

O significado desses marcadores, assim como a sua utilização nas

atividades estão na Tabela 3.7.

Tabela 3.7: Tipos de atividades e seus marcadores.


Subprocesso Indica a existência de atividades ou tarefas a serem executadas na atividade marcada. O marcador de subprocesso não pode ser utilizado em tarefas.

Repetição Indica que a atividade ou tarefa representa um laço de repetição.

Instâncias Multiplas em Paralelo Indica que a atividade realiza tarefas em múltiplas instâncias e que essas instâncias ocorrem em paralelo

Instâncias Multiplas em Sequência Indica que a atividade realiza tarefas em múltiplas instâncias e que essas instâncias ocorrem em sequência.

Atividade Ad Hoc Indica uma atividade para a qual não há uma forma ou um tempo definidos de execução

Atividade de Compensação Marcador utilizado para indicar uma tarefa sendo executada após algum evento de exceção.

55

3.6.6 Definindo Tarefas

Uma atividade pode ser atômica, ocasião em que é chamada de tarefa;

ou ser composta, quando recebe o nome de subprocesso. Os subprocessos de

BPMN são apenas conjuntos de tarefas e não estão no escopo do presente

trabalho, podendo ser fruto de complemento do estudo atual.

Tabela 3.8: Tipos de tarefas e seus marcadores


Tarefa Abstrata É uma tarefa genérica, sem um tipo específico.

Tarefa de Envio de Mensagem É uma tarefa que envia uma mensagem a um participante externo. O envio da mensagem finaliza a tarefa

Tarefa de Recebimento de Mensagem É uma tarefa cujo objetivo é esperar uma mensagem de um participante externo. Uma vez que a mensagem for recebida a tarefa estará concluída.

Tarefa de usuário É a tarefa típica de um workflow. Essa tarefa é executada por um usuário de um sistema de software automatizado.

Tarefa Manual É uma tarefa que não é auxiliada pela execução de nenhum mecanismo de execução de processo de negócio ou aplicação.

Tarefa de Regra de Negócio Fornece um mecanismo para o processo prover entradas para um mecanismo de regra de negócio e para capturar a saída de cálculos que esse mecanismo possa prover.

Tarefa de Invocação de Serviço É uma tarefa que usa algum tipo de serviço, seja ele um web service ou uma aplicação automatizada.

Tarefa de Script É executada por um mecanismo de processo de negócio. Esse script deve ser escrito pelo modelador em uma linguagem que o mecanismo possa interpretar.

56

Uma tarefa representa uma ação única ou um conjunto de ações que é

tratada no processo como uma ação única e atômica e é representada pelo

mesmo retângulo de cantos arredondados das atividades. Na prática não há

uma diferença visual entre os dois componentes.

Os tipos de tarefas, assim como na seção anterior estão mostrados e

explicados na Tabela 3.8

3.6.7 Definindo Desvios (gateways)

O terceiro grupo é composto pelos elementos que representam desvios

ou junções. Assim como nos elementos anteriores, serão apresentadas as

suas sintaxes, sem preocupação com a sua semântica ou sua interação entre

si ou os outros elementos.

Isso será feito com o mesmo objetivo dos elementos anteriores: primeiro

serão apresentados os elementos e seus significados isoladamente e mais

adiante a sua interação dentro de um diagrama.

Dada a complexidade e o escopo desse projeto nem todos os elementos

serão mostrados nos exemplos e nem todos terão uma explicação mais

profunda. Apenas os elementos que fazem parte do presente estudo e,

principalmente somente aqueles presentes na ferramenta Bonita serão fruto de

uma apresentação mais detalhada.

Conforme já feito para os elementos anteriores, a Tabela 3.9 resume os

desvios ou gateways.

Resta fazer uma ressalva: É boa prática que um desvio condicional que

divide o processo seja sucedido em algum ponto por uma junção do mesmo

tipo. Não é uma regra, podendo haver o caso em que não se use, mas o uso

ou não uso implicará em um funcionamento diferente do fluxo, conforme pode

ser concluído pela leitura da tabela.

57

Tabela 3.9: Tipos de desvio condicional (gateways)


Desvio Condicional Exclusivo (Ou Exclusivo)

Quando é uma ramificação do processo indica que apenas um dos ramos do processo deverá ser executado. Quando se trata de uma convergência indica apenas um ponto de convergência, ou seja, neste caso, a sua não utilização não mudará o significado do processo. Em alguns casos podendo ser melhor até não utilizá-lo. Tanto o losango vazio quanto o losango com um “X” no seu interior são válidos.

Ativação Incondicional em Paralelo Quando é uma ramificação do processo indica que a partir daquele ponto os processos saindo desse registro serão executados em paralelo. Quando se trata de uma convergência indica uma sincronização, ou seja, o fluxo só continua quando a execução de todos os processos em paralelo chegarem a esse desvio. Pode não ser usado mas alterará a semântica do fluxo.

Ativação Inclusiva Condicional Quando é uma ramificação do processo indica que um ou mais dos caminhos serão ativados, devendo, pelo menos um ser ativado. Quando se trata de uma convergência indica que o processo deverá aguardar que os caminhos que foram executados cheguem ao ponto de convergência.

Desvio Exclusivo Baseado em Evento Cada ocorrência de um dos eventos subsequentes inicia uma nova instância do processo.

Desvio Condicional por Evento Quando é uma ramificação do processo indica que apenas um dos ramos do processo deverá ser executado. Quando se trata de uma convergência indica apenas um ponto de convergência. A diferença em relação ao ou exclusivo é que o destino dos fluxos de saída só podem ser eventos ou tarefas de envio de mensagens

Desvio Paralelo Baseado em Eventos Na ocorrência de todos os eventos de saída é que se inicia uma nova instância do processo

Desvio Complexo Utilizado para condições complexas de ramificação ou convergência as quais outros desvios não são capazes de tratar

58

Da mesma forma que foi feito na seção sobre eventos serão inseridos

aqui alguns exemplos de uso de alguns dos gateways da BPMN, resumindo-se,

basicamente aos elementos que serão mapeados nesse trabalho para iniciar

seu entendimento antes da sua utilização no trabalho. Novamente os exemplos

aqui apresentados foram obtidos de (iProcess, 2011).

Na Figura 3.10 está representado um uso de um gateway exclusivo, no

caso o fluxo ao chegar ao gateway Resultado da Avaliação segue um dos três

fluxos (e apenas um deles). Um dos fluxos retorna ao processo anterior ao

gateway formando um loop e os outros dois são “sincronizado”4 no segundo

gateway. Deve-se observar o uso de diferentes tipos de tarefas nesse

processo.

Figura 3.9: Exemplo do uso do gateway exclusivo. Fonte: (iProcess, 2011)

Na Figura 3.11 foi representado o uso de um gateway paralelo. Neste

processo o gateway divide o fluxo em dois processos paralelos logo depois da

tarefa definir tema de artigo, sendo esses processos sincronizados pelo

gateway que antecede o processo realizar diagramação, que só será

executado após os dois fluxos chegarem ao gateway que faz a sincronização.

4 Não é uma sincronização real pois apenas um dos fluxos estará ativo.

59

Figura 3.10: Exemplo do uso do gateway paralelo. Fonte: (iProcess, 2011)

O terceiro exemplo é o de um gateway inclusivo. Nele pode haver a

execução de um ou mais fluxos, sendo necessário que, pelo menos um seja

executado. Na Figura 3.12 pode-se ver que após a tarefa Identificar

Documentação Necessária o gateway indica a necessidade de definir que tipo

de documento será necessário para a continuação do processo. Os fluxos que

prosseguirem o farão em paralelo e serão sincronizados pelo gateway que

antecede a tarefa analisar validade dos documentos. Pode-se observar que

nesse caso não há garantia explícita de que, pelo menos um documento será

necessário, tudo depende da regra de negócio.

Figura 3.11: Exemplo do uso do gateway inclusivo. Fonte: (iProcess, 2011)

3.6.8 Definindo Fluxos Internos do processo

Os fluxos são os elementos que ligam os elementos básicos já

apresentados. Os fluxos são de dois tipos: fluxos de processo e fluxos de

mensagem. Ambos já foram apresentados na Tabela 3.3. Esta seção

60

apresentará os três tipos de fluxos de processo, uma vez que são esses os

fluxos que tem alguma relação com o presente trabalho. Os fluxos são

apresentados na Tabela 3.10.

Tabela 3.10: Tipos de fluxos internos do processo.


Fluxo de Sequência É o mais comum. Utilizado entre todos os elementos e define a ordem de execução das atividades

Fluxo Padrão Geralmente utilizado em situações em que o fluxo se ramifica. Representa o caminho default (padrão) quando nenhum dos outros é seguido.

Fluxo Condicional Possui uma condição associada que define se o caminho será seguido ou não.

3.6.9 Considerações Finais Sobre BPMN

Esta introdução à BPMN mal tocou a superfície do que representa o

padrão. Embora boa parte da notação tenha sido mostrada o que se procurou

apresentar foi somente a porção que foi usada no trabalho ou que representa

algum conceito a ser usado nos capítulos que descrevem o desenvolvimento

do mesmo.

As relações entre os elementos, assim como os exemplos de processos

serão exibidas durante a apresentação do trabalho realizado, uma vez que as

explicações dessas interações serão melhor compreendidas dentro do universo

do estudo aqui apresentado.

Esta seção está longe de ser uma real introdução à BPMN mas servirá

ao propósito deste trabalho. Como sugestão de leitura ficam os textos de

(Campos, 2013) e (Panagacos, 2012) além da bibliografia já citada.

61

3.7 Avaliação de Fluxos

Uma das tarefas primordiais no trabalho com processos é conseguir que

se faça uma análise tanto das propriedades quanto da eficiência dos fluxos de

trabalho gerados. Essa análise requer o entendimento dos conceitos inerentes

a essa tarefa na geração dos processos.

Esta seção é um resumo da teoria sobre estas atividades. Aqui algumas

propriedades serão definidas apenas para deixar claro que a transformação

dos fluxos irá permitir que fluxos oriundos da BPMN sejam avaliados quanto a

essas propriedades no fluxo gerado para GSPN, i.e. um fluxo transformado

poderá ser melhorado com a aplicação dessas avaliações.

A primeira propriedade a ser considerada é a propriedades soundness

(Aalst & Hee, 2002).

Soundness: Um processo é considerado logicamente correto (Sound)

se ele não contém nenhuma tarefa desnecessária e se todo Case iniciado pelo

processo é totalmente concluído em algum momento, não restando nenhuma

referência a ele (nenhum token remanescente) no sistema.

A propriedade soundness pode ser avaliada usando-se a ferramenta

TimeNet, conforme será visto no próximo capítulo. Os fluxos transformados

usando a ferramenta foram avaliados quanto a essa e outras propriedades, tais

como:

Alcançabilidade: É a possibilidade de uma determinada marcação ser

alcançada a partir de uma marcação inicial, através do disparo de um número

finito de transições.

Limitação: Uma rede é dita k-limitada se as marcações em todos os

seus lugares não ultrapassarem um número limite de k tokens.

Segurança: Uma rede limitada é segura se o valor de k for igual a 1.

Liveness: Uma rede é considerada live se, independente das

marcações que sejam alcançáveis a partir da marcação inicial sempre for

62

possível disparar qualquer transição da rede através de uma sequência de

transições.

Deadlock: É a impossibilidade do disparo de qualquer transição da

rede. Um sistema sem deadlocks não implica em um sistema live, no entanto

um sistema live é um sistema livre de deadlocks.

As avaliações dos fluxos feitas aqui neste trabalho serão criadas

apenas para o teste dos modelos gerados, não constando como uma nova

idéia para a área.

3.8 Avaliação de desempenho

Uma vez que os fluxos gerados estejam corretos eles podem ser

medidos quanto à sua eficiência, sendo este um dos objetivos do presente

trabalho: possibilitar o teste de processos criados em BPMN com técnicas e

ferramentas de redes de Petri, mais especificamente GSPN.

Duas abordagens de avaliação de desempenho podem ser utilizadas:

Transiente: Avalia o comportamento do sistema durante um

período de tempo a partir do estado inicial;

Estacionária: Avalia o comportamento do sistema no estado de

equilíbrio.

Estas duas abordagens são explicadas na seção sobre a ferramenta

TimeNet. Uma GSPN pode ser avaliada através de simulação, que utiliza

resultados aproximados ou através da solução de sua cadeia de Markov, que

oferece a solução exata do sistema.

Apesar de a solução analítica ser a ideal, a geração da cadeia de

Markov pode não ser possível quando o modelo possui um número muito

grande ou infinito de estados. Nestes casos, apenas a simulação pode ser

realizada.

63

3.9 Considerações finais sobre workflow

Neste capítulo foram apresentados os conceitos básicos de workflow,

assim como as bases das notações envolvidas no processo desenvolvido neste

trabalho.

Além disso foi introduzido brevemente alguns tópicos sobre a avaliação

e análise de processos, dada a sua aplicação no final do desenvolvimento do

protótipo.

64

Capítulo 4

A Criação das Classes Básicas

Nesta seção será descrita a fase de criação da base de software que

servirá para a fase seguinte deste trabalho que é a criação das transformações.

Para desenvolver as ações deste capítulo houve uma pesquisa sobre as

notações utilizadas. Baseado nessas notações foram extraídas as classes Java

de cada uma delas, sendo essas as classes básicas para a criação dos objetos

que irão auxiliar as transformações.

Sendo assim, aqui, estão apresentados os procedimentos do trabalho

para que fosse possível a criação das transformações, que são o foco deste

estudo.

4.1 As notações XML usadas no projeto

Para definir a transformação de uma notação para outra foram

escolhidos os formatos para a gravação dos processos em cada ferramenta.

Para essa definição foram verificados em cada uma das ferramentas utilizadas

as possibilidades de utilização das notações XML.

4.1.2 A notação do TimeNet

O padrão definido pela TimeNet foi o adotado apesar da existência do

padrão PNML, que a ferramenta também suporta. Se escolheu essa notação

devido às dificuldades encontradas em obter os arquivos DTD da definição

XML para PNML. A notação PNML está descrita em (Pnml.org, 2009), apesar

disso a ferramenta utilizada é capaz de exportar para esse formato, logo a

escolha do formato nativo da TimeNet ampliou as possibilidades de uso do

65

protótipo pois um arquivo gerado para a TimeNet pode, posteriormente ser

exportado para PNML.

Dois arquivos DTD foram utilizados para gerar as classes utilizando

JAXB: o arquivo EDSPN.xsd e o arquivo SCPN.xsd, o primeiro define a

estrutura das redes EDSPN e DSPN definidas para o TimeNet e o segundo

para as SCPN, ambos estão na pasta Timenet/etc/schemas (Zimmermann &

Knoke, 2007). Outros arquivos de definição de esquemas estão nessa pasta

mas não foram utilizados para o objetivo desse trabalho (embora suas classes

também tenham sido geradas).

De posse dos dois arquivos foi executado o processo de binding

utilizando-se, para isso o comando xjc conforme o trecho de Código 4.1 a

seguir:

Código 4.1: Comandos para realizar o binding. Fonte: (Java Arquiteture for XML Biding (JAXB), 2009)

C:\ xjc –p br.ufpe.cin.timenet.scpn scpn.xsd –d scpn

C:\ Xjc –p br.ufpe.cin.timenet.edspn edspn.xsd –d edspn

Cada um dos comandos gerou as classes necessárias para a

construção de redes de Petri em Java a partir de cada um dos arquivos XML,

utilizando-se os procedimentos de marshall e unmarshall do JAXB.

Na Figura 4.1 tem-se uma representação simplificada do diagrama de

classes gerados para as classes do tipo EDSPN da TimeNet. Esse diagrama,

assim como outros diagramas de classe deste documento foi gerado

automaticamente através da ferramenta Astah Professional utilizando uma

licença de avaliação.

Como pode ser visto na listagem de Código 4.1 as classes foram

colocadas no pacote br.ufpe.cin.timenet, ficando as redes scpn no pacote

br.ufpe.cin.timenet.scpn e as redes edspn no pacote br.ufpe.cin.timenet.edspn.

Na Figura 4.2 foi representado o diagrama de classes da rede SCPN.

66

Figura 4.1: Diagrama simplificado das classes geradas no processo de binding para as redes eDSPN.

Figura 4.2: Diagrama simplificado das classes geradas no processo de binding para as redes SCPN.

67

Tanto a Figura 4.1 quanto a Figura 4.2 estão simplificadas em relação às

classes efetivamente geradas para seus respectivos pacotes, isso foi feito para

ser possível a legibilidade das mesmas. Os elementos não presentes no

diagrama são elementos de apoio que não fazem parte da semântica das redes

Na Figura 4.3 estão representados pacotes a) br.ufpe.cin.timenet.edspn e b)

br.ufpe.cin.timenet.scpn.

Figura 4.3: Listagem das classes das redes a) EDSPN e b) SCPN

68

4.1.3 A notação do Bonita

No caso da BPMN, cuja ferramenta escolhida foi o Bonita Studio (BOS),

também haviam dois formatos a serem escolhidos. O primeiro a ser

considerado é o formato padrão de salvamento da ferramenta, que é um

formato proprietário (extensão .bos) que encapsula todos os elementos gráficos

e uma notação XML. Este formato é um conjunto de arquivos compactados, o

qual possui entre outros arquivos um XML com um formato próprio. A não

escolha deste se deveu à complexidade do mesmo e do tempo disponível para

a pesquisa. Nada impede, no entanto que no futuro esse formato possa ser

utilizado.

Outra razão é que ao ser usado um padrão aberto os métodos aplicados

aqui podem ser utilizados em qualquer ferramenta que também exporte para o

formato o formato BPMN 2.0 que é um formato definido em (OMG, 2011),.

Na listagem de Código 4.2 tem-se o comando para gerar as classes

BPMN dentro do pacote br.ufpe.cin.bpmn.

Código 4.2: Comando para a geração das classes do BPMN 2.0

C:\ xjc –p br.ufpe.cin.bpmn bpmn.xsd –d bpmn

Na Figura 4.4 está uma parte das classes geradas a partir do comando

xjc listado no Código 4.2. A partir das instâncias dessas classes e utilizando os

métodos de transformação serão gerados objetos das classes da notação de

destino (EDSPN ou CSPN). Na Figura 4.5, da mesma forma que na seção

anterior estão todas as classes geradas a partir do comando xjc.

Como pode ser visto a quantidade de classes é muito maior que a das

duas notações da TimeNet juntas, isso se deve ao fato de que além de serem

geradas classes que definem os elementos ainda há classes que definem

aspectos dos diagramas em si, classes para diagramas de colaboração,

classes que definem dados a serem utilizados pelas outras classes, classes de

coreografia e classes de elementos de dados. Muitos deles não foram

utilizados nesse trabalho.

69

Figura 4.4: Diagrama simplificado das classes geradas no processo de binding para BPMN

70

Figura 4.5: Listagem das classes da BPMN

Uma vez geradas as classes Java de cada uma das notações, a etapa

seguinte foi definir como seriam feitas as conversões de uma notação para a

outra, para isso foram realizados testes a fim de verificar a capacidade de

conversão da base criada. Estes testes não têm relevância para o

entendimento do projeto.

4.2 Conclusões

Nesta seção foi descrito o processo de obtenção das classes que

servem de base para a criação das transformações dos diagramas. Esse

processo foi importante pois constituiu o passo que viabilizou a continuidade do

trabalho.

Após a obtenção dessa base uma série de testes foi efetuada de modo a

avaliar a capacidade de criação dos arquivos XML que iriam conter as redes de

Petri, assim como na leitura de arquivos com os processos em BPMN 2.0.

71

Capítulo 5

Transformação de BPMN para GSPN

Nesta seção será tratada a execução da ideia central deste trabalho.

Serão expostos o desenvolvido do trabalho, quais as ideias e quais decisões

foram tomadas e os motivos para cada uma dessas decisões.

Conforme já mencionado as ferramentas escolhidas foram o Bonita

Open Solution (BOS) e o TimeNet para serem as ferramentas de geração dos

processos originais e testes dos processos gerados pelo protótipo

respectivamente. Para o desenvolvimento foi utilizado o IDE Eclipse com JAXB.

5.1 Criando o módulo de transformação

Às classes geradas em ambas as notações, conforme descrito no

capítulo anterior, foram acrescidas de códigos que facilitassem a conversão

dos elementos. Esses códigos não alteram a estrutura básica das classes,

apenas dão formas alternativas de criação de objetos dessas classes.

Seguindo o mesmo padrão adotado na geração das classes SCPN,

EDSPN e BPMN o pacote que contém as classes de transformação (trans) é

denominado br.ufpe.cin.trans.bpmn, pois as mesmas transformam de BPMN

para um dos modelos de rede de Petri citados. Uma das possíveis extensões

desse trabalho seria fazer o caminho inverso.5

As classes de transformação foram definidas a medida que cada

transformação foi desenvolvida a partir, em sua maioria, do trabalho de

(Oliveira, 2008) e em casos específicos nos trabalhos de (Ramadan, Elmongui,

& Hassan, 2011) e em (Remco M. Dijkman, 2008).

5Sempre que for feita referência a uma classe de transformação a mesma será encontrada neste pacote, assim como quando se citar as outras classes (BPMN e RdP) estarão nos respectivos pacotes.

72

5.2 A estrutura do pacote do módulo de transformação

As classes desse módulo são o centro deste trabalho. São elas que

farão a conversão da notação BPMN para redes de Petri. Para este trabalho

foram gerados artefatos baseados nas GSPN (Generalized Stochastic Petri

Nets), as quais são testadas usando-se o modelo EDSPN do TimeNet, sendo

assim, na prática um módulo que transforma um fluxo BPMN em um fluxo

equivalente EDSPN, sendo, no entanto, possível a extensão dessa

transformação para redes do tipo SCPN da mesma ferramenta, bastando, para

isso que sejam criadas transformações equivalentes para aquele tipo de rede.

O pacote br.ufpe.cin.trans.bpmn, que executa a transformação de BPMN

para uma EDSPN tem sua estrutura de classes desenhada na Figura 5.1. No

caso desse módulo, dada a sua pequena quantidade de classes não foi

necessária uma listagem como nos anteriores.

Figura 5.1: Diagrama simplificado das classes de transformação de BPMN para EDSPN

Há um elemento raiz representado por uma classe abstrata chamada

Elemento que é responsável pela estrutura e responsabilidades básicas de

todos os elementos de transição construídos.

73

Alguns elementos da BPMN foram implementados internamente a essas

classes e, além disso, boa parte destes foi tratado como um único elemento, no

entanto nada impede que estes, no futuro dêem origem a uma hierarquia

semelhante à que se iniciou com o elemento da classe Tarefa.

O código de criação dessas classes assim como todos os códigos

gerados estão no Anexo C.

Além do módulo de transformação foi desenvolvido um módulo de

testes. Todos os modelos de testes foram criados usando a ferramenta Bonita

Open Solution, as classes de transformação foram desenvolvidas em Java

usando a IDE Eclipse e os resultados foram acessados e testados na

ferramenta TimeNet.

Os modelos obtidos foram testados de acordo com a definição em

(Oliveira, 2008) quanto:

A sua Corretude (soundness)

Número mínimo de recursos necessários em cada papel

Número de instâncias de atividade em execução

Número de work intens em cada worklist

Número de recursos disponíveis em cada papel

Tempo de resposta de um case

Sendo essa etapa apenas parte do processo de verificação da

transformação de um tipo de fluxo para outro.

A partir daí foram seguidos os modelos básicos apresentados e,

conforme a necessidade, adaptados ao objetivo do trabalho.

Conforme a necessidade de esclarecimento alguns conceitos de

(Oliveira, 2008) serão apresentados, no entanto, para não se extender muito,

apenas os conceitos diretamente ligados às transformações serão transcritos

neste trabalho.

74

5.3 Definição da transformação de início de processo

Como já visto anteriormente neste trabalho, a BPMN estabelece eventos

como os indicadores de início e fim, embora a especificação (OMG, 2013) não

obrigue a utilização desses eventos.

Para o objetivo deste trabalho será assumido que todo processo BPMN

terá eventos de início e fim. Na Figura 5.2 tem-se a representação de todos os

eventos de início presentes na ferramenta BOS.

Figura 5.2: Eventos de Início presentes no Bonita Open Solution

Para o caso apresentado as diferenças inerentes a cada tipo de evento

de início da Figura são irrelevantes, sendo assim a representação que foi

usada é a do evento simples. A razão pela qual o tipo de evento de início não é

relevante deve-se à natureza estocástica da rede de Petri gerada Um evento

de início é definido como o ponto em que se inicia uma instância de processo

(Oliveira, 2008). Os diferentes tipos de eventos apenas definem que tipo de

gatilho irá disparar o evento. A definição do termo “gatilho” segue as definições

de padrões de workflow definidas por Will van der Aalst e presentes em

(Oliveira, 2008).

Das definições dos modelos básicos definidos por (Oliveira, 2008) serão

destacadas as definições do Quadro 5.1.

Quadro 5.1: Definições utilizadas para Lugar Inicial e Transições de Partida. Fonte: (Oliveira, 2008).

Definição 5.1 (Função Lugar Inicial): Para um sub-processo

𝑈 = (𝑃𝑈 , 𝑇𝑈, Π𝑈 , 𝐼𝑈 , 𝑂𝑈 , 𝐻𝑈 , 𝑀0𝑈 , 𝜔𝑈 ), denotamos por Start(U) o lugar Sp ∈ PU,

que satisfaz às condições para ser o Lugar Incial de U.

Definição 5.2 (Função Transições de Partida): Para um sub-processo

𝑈 = (𝑃𝑈 , 𝑇𝑈, Π𝑈 , 𝐼𝑈 , 𝑂𝑈 , 𝐻𝑈 , 𝑀0𝑈 , 𝜔𝑈 ), denotamos por End(U) o conjunto de

transições Dt TU que satisfazem às condições para serem Transições partida de U.

75

Baseado nas definições do Quadro 5.1 e na definição forma de evento

de início presente em (OMG, 2013), denota-se que a um evento de início (de

qualquer tipo) pode ser transformado em uma transição exponencial, conforme

o trabalho já citado. Uma outra forma é proposta por (Zimmermann & Knoke,

2007). Esta definição contraria o trabalho de (Raedits, Petkovic, Usenko, Werf,

& Jan Friso Groote, 2007), neste caso o trabalho citado sugere que um par

transição/lugar seria adequado, conforme a Figura 5.3.

Figura 5.3: Início do processo segundo a proposta de (Raedits, Petkovic, Usenko, Werf, & Jan Friso Groote, 2007)

No caso citado do par transição/lugar como equivalente a um evento de

início não faz sentido porque o evento de início não age dentro do processo,

ele é apenas um estímulo externo ao processo, sendo assim incorreto após a

transição representada na Figura 5.3a disparar, que um lugar associado ao

início do processo guarde um token (Figura 5.3b), mesmo que por um breve

instante, ou seja, o processo não necessariamente estaria iniciado pois ainda

dependeria que esse token fosse consumido por uma outra transição.

Com isso a transformação de um evento inicial BPMN de qualquer um

dos tipos presentes na Figura 5.2 é a representada na Figura 5.4.

Figura 5.4: Transformação de um evento inicial BPMN em uma transição de Redes de Petri.

Devido à verbosidade da linguagem Java e à quantidade de código

gerado optou-se por não exibir os códigos-fonte pois os mesmos ficaram muito

extensos para um espaço curto como uma página, portanto para evitar

listagens desnecessárias optou-se por indicar apenas em qual método de qual

classe está a transformação citada. A listagem dos módulos do software

produzido está no Anexo C.

76

A taxa de chegada, embora seja estocástica e correponda, no processo

transformado a um processo de Poisson, para efeitos de simulação e testes

deverá ser indicada pelo designer do processo, este valor pode ser estimado

através de uma média, para uma melhor aproximação com o processo real.

Isto foi feito para o estudo de caso.

5.4 Definição da transformação de fim de processo

O fim de um processo (ou subprocesso) em BPMN é definido pelos

eventos finais. Na Figura 5.10 estão exibidos todos os eventos de fim possíveis

de serem desenhados pela ferramenta BoS.

Figura 5.5: Eventos de Fim presentes no Bonita Open Solution

Neste caso os eventos de fim, com exceção do evento simples, além de

representar o final do processo realizam alguma atividade. Para termos

práticos os eventos de envio de mensagem, erro e de sinal podem ser

mapeados da mesma forma que o evento inicial simples, pois a ação que os

mesmos disparam não será uma ação que afete diretamente o fluxo modelado.

No entanto, o último elemento, conhecido como Terminal em português e

definido no conceito original (OMG, 2013) como Terminator (exterminador), um

elemento final que representa não só o fim do fluxo ao qual está ligado, mas de

todos os fluxos paralelos daquela instância do processo, ou seja, ele para

totalmente a instância do processo. Este elemento não faz parte da

transformação definida nesta seção, ficando como trabalho futuro. Este

elemento para a notação GSPN está representado na Figura 5.6.

Figura 5.6: Transformação de um Evento Final para a representação em uma RdP

77

5.5 Mapeamento de Pools e Raias

Conforme visto em capítulos anteriores os diagramas BPMN são

desenhados em contêineres chamados pools, que podem representar o

processo em si (e assim vai ser considerado nesse trabalho) e raias, que são

os responsáveis ou os papéis P que irão realizar as atividades no processo e a

cada conjunto de papéis ou a cada raia é atribuído um número natural positivo

que representa a quantidade de recursos disponível para aquela raia, o qual

será usado na avaliação de desempenho, onde o número de recursos importa.

Neste trabalho cada raia terá uma capacidade, a qual será presumida

como sendo 1, caso não seja especificada. A forma de especificar as

capacidades, uma vez que esse conceito não está bem estabelecido na BPMN,

seria adicionar atores ao processo, associando esses atores às raias e as

tarefas a esses atores. No entanto cada ator representa apenas um papel em

um processo BPMN, forçando o modelador do processo a criar um ator para

cada tarefa em tarefas paralelas. Para ficar claro, o Quadro 5.2 apresenta o

conceito de papel, conforme a definição de (Oliveira, 2008), seguida neste

trabalho.

Quadro 5.2: definição de conjunto de papéis. Fonte: (Oliveira, 2008)

Definição 5.3 (Conjunto de Papéis): O Conjunto de Papéis, denotado por 𝒫, contém

os papéis que existem no Workflow. É definido por um conjunto

𝒫 = (𝑅1, 𝑅2, … , 𝑅𝑁 ), no qual cada Ri é um papel.

Associado a isso existe a questão do teste das instâncias que seria

influenciada pela quantidade de atores disponíveis para a execução simultânea

de várias instâncias de um processo, com isso haviam duas alternativas:

Associar um ator (e consequentemente um ou vários papeis) para cada

raia, o que seria inviável pois impossibilitaria a execução de várias

instâncias e o teste dessas no TimeNet;

Outra opção seria informar quantos papéis cada ator poderia representar

simultaneamente, ou seja, quantas instâncias de um processo um

78

determinado ator (que seria na verdade um conjunto de um determinado

ator) seria capaz de executar. Dessa forma cada atividade poderia ter

associada a si um Ator com capacidade de K papeis simultâneos.

Essa última opção deixaria as raias sem uma função que não fosse a de

agrupar as tarefas e subprocessos, por isso a solução escolhida foi a mais

simples também: associar a uma raia um conjunto k de papéis, que

representam a quantidade de instâncias paralelas possíveis. Neste caso

assume-se que uma raia representa um grupo de papeis capazes de executar

qualquer uma das atividades de qualquer uma das tarefas internas a essa raia.

Na Figura 5.7 estão representadas duas raias BPMN e sua respectiva

transformação para um local de RdP. A marcação inicial é definida pela

quantidade de recursos definida na raia com o código da marcação k definida

na Tabela 5.1, descrita mais à frente neste trabalho.

Figura 5.7: Transformação de duas raias em lugares de RdP

Uma vez decidido onde fica a informação sobre a capacidade de

execução (quantidade de papéis) das tarefas, restou decidir como guardar

essas informações para que as mesmas se tornassem disponíveis no arquivo

BPMN 2.0 exportado.

Após alguns testes se constatou que vários dos artefatos e das

propriedades criadas no BoS não eram exportadas para o BPMN 2.0, entre

elas os dados de atores. Como não era mais possível a mudança de padrão

79

para XPDL pois a ferramenta não suportava totalmente esse padrão na época,

se avaliou a possibilidade de um registro em dados externos conforme fora

executado em (André, 2009).

Uma outra possibilidade seria a inserção de dados no diagrama, uma

solução mais elegante, mas na época da construção do protótipo a ferramenta

BOS não exportava esses dados para o formato BPMN 2.0. Essa é uma das

mais importantes mudanças a serem feitas na ferramenta. Na Figura 5.8 está

representado um dado da quantidade de papeis de uma raia, no caso estão

definidos três papeis para essa raia.

Figura 5.8: Raia Empregado com 3 papéis definidos

Essa solução evita a necessidade de utilização de qualquer tipo de

informação externa pois o código pode ser utilizado e gravado na descrição da

raia e este dado está presente na exportação para BPMN 2.0. Esse código,

assim como outros que foram utilizados mais à frente nesse trabalho estão

descritos na Tabela 5.1. Os valores n presentes em cada um dos códigos

identifica a quantidade associada cada um deles.

Essas considerações foram necessárias para que se pudesse chegar na

transformação de uma atividade BPMN em sua equivalente proposta,

mapeando-se tarefas em uma estrutura de uma rede de Petri.

80

Tabela 5.1: Códigos definidos para dados de execução.

Código Nome - Função

<k=nk>

K -> Número de papéis da lane

O termo <k indica que se inicia a identificação da quantidade de papéis, n indica a quantidade de papéis disponíveis na raia e k> finaliza a notação.

<d=nd>

d ->Tempo médio de execução das atividades

O termo <d indica o tempo necessário para uma atividade ser executada, n indica esse valor em um número relativo d> finaliza a notação.

<w=nw>

w-> Peso de um fluxo

Em gateways ou demais elementos com decisões, serve para determinar as probabilidades de execução de cada um dos fluxos.

5.6 Mapeamento das Tarefas

Com a definição do mapeamento do início e do final de processos e

subprocessos, resta começar a mapear o que acontece entre um evento e

outro. Para começar, o elemento básico da execução de um diagrama BPMN,

a tarefa, será convertida, mais uma vez adaptando-se do conceito de Modelo

de atividade descrito no quadro 5.3.

Conforme já visto uma atividade pode ser de vários tipos, no BOS os

tipos possíveis são os representados na Figura 5.9

Figura 5.9: Tipos de Tarefas do BoS

81

Quadro 5.3: definição formal do Modelo de Atividade. Fonte: (Oliveira, 2008).

Definição 5.4 (Modelo de Atividade): Um Modelo de Atividade é denotado por

Ai(Rk, di), onde:

1. 𝑅𝑘 ∈ 𝒫 é o papel responsável pela execução da atividade;

2. 𝑑𝑖 ∈ ℝ+∗ é o tempo médio necessário para execução da atividade.

e corresponde a uma GSPN, 𝐴𝑖(𝑅𝑘, 𝑑𝑖) = (𝑃𝑖 , 𝑇𝑖 , Π𝑖 , 𝐼𝑖 , 𝑂𝑖 , 𝐻𝑖 , 𝑀0𝑖 , 𝜔𝑖 ),

que é definida da seguinte forma:

1. 𝑃𝑖 = {𝑅𝑘, 𝑊𝑖 , 𝑆𝑖}, onde:

𝑅𝑘 é um lugar representando o papel 𝑅𝑘, responsável pela execução;

𝑊𝑖 é um lugar que conterá os Work Items desta Atividade, chamado

de Worklist Place;

𝑆𝑖 é um lugar que conterá as Instâncias de Atividade, chamado de

Service Place.

2. 𝑇𝑖 = {𝑞𝑘𝑖 , 𝑇𝐴𝐶𝑇𝐼𝑉𝐼𝑇𝑌−𝑖}, onde:

𝑞𝑖 é uma transição imediata, com 𝜔𝑖(𝑞𝑖) = 1 𝑒 Π𝑖(𝑞𝑖) = 1;

𝑇𝐴𝐶𝑇𝐼𝑉𝐼𝑇𝑌−𝑖 é uma transição temporizada com tempo médio igual ao

valor 𝑑𝑖 e semântica de infinitos servidores (infinite server).

3. e 𝐼𝑖 , 𝑂𝑖 , são tais que:

(a) a pré-condição • 𝑞𝑖 = {𝑊𝑖 , 𝑅𝑘} e a pós-condição 𝑞𝑖 • = {𝑆𝑖};

(b) a pré-condição • 𝑇𝐴𝐶𝑇𝐼𝑉𝐼𝑇𝑌−𝑖 = {𝑆𝑖} e a pós-condição 𝑇𝐴𝐶𝑇𝐼𝑉𝐼𝑇𝑌−𝑖 • =

{𝑅𝑘}.

Para o mapeamento deste trabalho, assim como foi feito nos outros dois

casos o tipo de tarefa não será considerado, portanto a representação a ser

usada será a de tarefa abstrata, simbolizando qualquer uma das outras vistas

na Figura 5.10. Uma modificação que poderia ser proposta seria a separação

entre tarefas automáticas e tarefas manuais, sendo essas primeiras não

consumidoras de recursos e a segunda consumidoras de recursos.

A transformação em si está representada na Figura 5.10, considerando-

se que a tarefa está dentro de uma raia R com uma capacidade k e com um

tempo médio di de execução.

82

Figura 5.10: Transformação de uma tarefa

A representação da tarefa em GSPN é baseada no Modelo de

Atividades descrito no Quadro 5.3, nesse modelo o lugar Wi é worklist place, o

lugar que conterá os work items da atividade, qi é a transição imediata que, ao

ser disparada, retirará work itens da worklist place e os colocará no lugar Si,

que representa as instâncias da atividade. A transição exponencial com

duração di, digitada na descrição da tarefa BPMN conforme a tabela 5.1, terá

além desse dado extraído do diagrama BPMN o nome da tarefa (na notação

original esse é chamado T-Activity-i), o índice i é incrementado automaticamente

de acordo com a leitura e o mapeamento do arquivo XML (BPMN 2.0).

O lugar Rk representa o papel Rk, definido na raia e será nomeado com o

nome da raia, seguindo o conceito de equivalência de papéis (Quadro 5.4).

Este lugar conterá k tokens que serão consumidos com o disparo da transição

qi e que habilitam essa transição juntamente com os tokens existentes no lugar

Wi.

Quadro 5.4: Definição formal de Equivalência de Papéis. Fonte: (Oliveira, 2008)

Definição 5.5 (Equivalência de Papéis): Seja 𝑅𝑘 ∈ 𝒫 um papel e A1(Rk, d1), A2(Rk,

d2), duas atividades quaisquer. Se estas Atividades são compostas, formando uma

única GSPN, o lugar 𝑅𝑘 que corresponde ao papel em cada modelo é único na

GSPN resultante.

Um exemplo, com apenas uma tarefa, está representado na Figura 5.11.

Nessa Figura foram destacadas as inserções dos valores na raia, assim como

o valor do delay da tarefa, enquanto isso, no lado gerado da rede de Petri tem-

se os valores recebidos pela transição exponencial da tarefa e de quantidade

de tokens da raia.

83

Figura 5.11: Teste de geração de um processo simples.

Figura 5.12: Transformação de um processo simples

84

Na Figura 5.12 está a representação da transformação de um processo

BPMN com duas tarefas em uma GSPN equivalente, sem entrar em detalhes

sobre a entrada das informações.

No exemplo citado, o lugar que representa a raia contém 3 tokens, o que

indica que a mesma contém 1 papel desempenhado por 3 atores, cada um

capaz de realizar tarefas simultâneas da mesma instância de processo ou de

instâncias diferentes. Outra observação é que o lugar nomeado como Raia

(nome que recebe da raia do processo BPMN) é compartilhado por todas as

tarefas resultantes, habilitando ou não o seu início. Os papéis do lugar Raia

representam os recursos disponíveis para a raia que foi da qual eles derivaram.

A transformação da Figura 5.12 também foi gerada e testada no Token Game

do TimeNet (Zimmermann & Knoke, 2007), conforme se vê na Figura 5.13.

Figura 5.13: O processo gerado sendo executado no TimeNet

5.7 Transformação de eventos intermediários

Em BPMN existem os eventos intermediários, eventos que ocorrem ao

longo de um processo que, diferente das atividades, não representam a

execução de algo dentro de um processo, mas a espera de algo externo ou,

mais precisamente a interação com algo externo cuja execução, geralmente,

não é controlada pelo processo.

85

Estes mapeamentos não derivaram diretamente de (Oliveira, 2008) mas

foram inspirados nas mesmas idéias presentes no trabalho. Algumas das

implementações derivaram do trabalho de (Remco M. Dijkman, 2008).

Como este trabalho trata da transformação da notação BPMN para

redes de Petri usando uma ferramenta específica, na Figura 5.14 estão

representados todos os possíveis eventos intermediários utilizando essa

ferramenta. Se comparados com os eventos intermediários existentes na

notação percebe-se que é um subconjunto deste último.

Figura 5.14: Eventos intermediários do Bonita Soft

Dos eventos intermediários representados, os dois primeiros são figuras

de ligação (link) e não representam eventos no fluxo, servindo apenas para

facilitar a leitura do diagrama. Esses elementos não serão considerados nesse

trabalho.

Os eventos intermediários tanto podem ocorrer no fluxo normal do

BPMN como podem estar acoplados à borda de uma atividade, representando

assim um evento de exceção. Inicialmente serão tratados os eventos do fluxo

normal de execução.

Os elementos de envio de mensagem e envio de sinal foram mapeados

para o conjunto representado na Figura 5.15. Essa transformação pode ser

estendida a qualquer evento intermediário cujo processamento tenha um tempo

de execução irrelevante para o processo. Deve-se ter em mente que a

mensagem ou sinal enviados vão para fora do fluxo e não pertencem nem

afetam o mesmo. A transição imediata do final da notação dessa transformação

indica que a mesma não afeta significativamente a execução do fluxo, não

caracterizando, assim, esse evento como algo semelhante a uma tarefa,

embora efetivamente seja uma ação dentro do fluxo.

86

Figura 5.15: Transformação de eventos de lançamento de mensagem para RdP

Para os demais eventos intermediários que ocorrem no fluxo normal,

representados na Figura 5.16, que fazem com que haja uma espera no fluxo

até que um evento externo ocorra a representação da transformação está na

Figura 5.17.

Figura 5.16: Eventos intermediários do fluxo normal

Figura 5.17: Transformação de um evento intermediário de captura

Neste caso há a ocorrência de um evento que faz com que o fluxo

aguarde, justificando a troca da transição imediata por uma transição

exponencial com características semelhantes às utilizadas na definição do

mapeamento das tarefas. A natureza do evento não é relevante para o fluxo,

por isso se utilizou a notação do evento simples, podendo ser extendida a

qualquer um dos elementos presentes na Figura 5.16.

Há ainda uma outra forma de se utilizar os eventos intermediários que é

como um evento acoplado à borda de uma atividade. Estes elementos estão

apresentados na Figura 5.18.

Figura 5.18: Eventos que podem se acoplar à borda das atividades

87

Esses eventos podem ter dois comportamentos: a sua ocorrência

interrompe a execução da atividade ou a sua ocorrência não interrompe a

atividade, nesse caso, representado pelo primeiro elemento, o único com borda

tracejada. A situação em que a atividade é interrompida está representada na

transformação da Figura 5.21.

Para definir esta transformação foram consideradas duas abordagens, a

primeira, como no restante do trabalho foi a formulada por (Oliveira, 2008) cuja

representação pode ser vista na Figura 5.19. Nesta abordagem o autor

considera que os Work Items presentes no lugar Wi poderão ser,

eventualmente, consumidos pela transição exponencial TCANCEL-i em vez da

transição imediata qi.

Figura 5.19: Modelo de atividade cancelável segundo (Oliveira, 2008).

Independente da viabilidade dessa notação, a sua não utilização deveu-

se, principalmente pelo conceito de cancelamento de atividade da BPMN: A

atividade será cancelada após ter sido iniciada.

A implementação da Figura 5.21 originou-se da idéia apresentada em

(Remco M. Dijkman, 2008) representada na Figura 5.20. Nessa abordagem o

autor afirma que uma vez que a execução da tarefa T é atômica, ela só pode

ser interrompida pela ocorrência da exceção Ex quando T está habilitada e

ainda não foi completada. Em termos de redes de Petri, isto indica que a

ocorrência da exceção Ex, pode “roubar” o token que normalmente seria

consumido pela transição correspondente à tarefa T, ou seja Ex ocorre antes de

T ocorrer.

88

Figura 5.20: Mapeamento de uma tarefa com exceção proposta em (Remco M. Dijkman, 2008)

Figura 5.21: Mapeamento de um evento de borda interrompível.

Baseado nessa idéia foi proposta, então a transformação da Figura 5.21,

nela se pode ver que, na ocorrência de algum token no lugar S1 tanto a

transição Tarefa1 quanto a transição qt3 são habilitadas, sendo que o disparo

da transição qt3 deixa a Tarefa1 com um token a menos ou simplesmente

desabilitada, no caso em que todos os tokens são consumidos. Observe-se,

ainda que a execução de uma instância não afeta a execução das instâncias

seguintes, podendo o fluxo de exceção ocorrer em paralelo a outros fluxos.

Com isso tem-se que a possibilidade de interrupção de uma atividade pode

gerar um novo fluxo (um fluxo de exceção), que será mapeado de acordo com

as regras já vistas em transformações anteriores.

89

5.8 Definição de notação de subprocessos

Antes de continuar faz-se necessária uma definição que será usada nos

próximos exemplos de transformação de fluxo: a representação de um sub-

processo. Aqui será utilizada a mesma definição utilizada para subprocesso em

(Oliveira, 2008), e para os exemplos deste trabalho essa definição,

originalmente definida para GSPN será extendida para BPMN apenas para

simplificar os diagramas, indicando, na sua ocorrência que naquele ponto

poderá haver qualquer sequência válida de passos. Portanto, nos exemplos

quando a Figura 5.22 surgir em um diagrama de qualquer um dos tipos aqui

utilizado ela estará representando qualquer processo, ou seja, qualquer

sequência de passos válidos dentro do intervalo em que ela ocorrer.

Figura 5.22: Um processo Un

5.9 Transformação de gateways

Os gateways são os elementos de decisão da BPMN. O BOS possibilita

o uso de 3 tipos de gateways ou desvios: os desvios paralelos, desvios

exclusivos e desvios inclusivos, respectivamente na Figura 5.23. No caso do

desvio exclusivo (Xor) será utilizado apenas a figura utilizada pela ferramenta.

Figura 5.23: Gateways (desvios) presentes no BoS

As transformações dos dois primeiros foram criadas a partir das

especificações de (Oliveira, 2008), enquanto que a terceira transformação foi

criada tendo como base o trabalho de (Ramadan, Elmongui, & Hassan, 2011),

conforme será explicitado no momento da explanação de cada caso.

90

5.9.1 Transformação de gateways exclusivos

Os gateways exclusivos ocorrem em um fluxo para criar caminhos

alternativos exclusivos e são citados em (Oliveira, 2008) como caminhos

alternativos (Xor) e sua definição pode ser vista no quadro 5.5.

Quadro 5.5: Definição de Operador Caminho Alternativo (Xor). Fonte: (Oliveira, 2008)

Definição 5.6 (Operador Caminho Alternativo - Xor): Sejam U1, U2, ..., UN sub-

processos e Pr uma função de distribuição de probabilidade

𝑋𝑂𝑅: 𝑆𝑃𝑟𝑜𝑐 × . .× 𝑆𝑃𝑟𝑜𝑐 × (𝑆𝑃𝑟𝑜𝑐 → ℝ[0; 1]) → 𝑆𝑃𝑟𝑜𝑐

𝑋𝑂𝑅(𝑈1, 𝑈2, … , 𝑈𝑁, 𝑃𝑟) = 𝑈𝑅, 𝑜𝑛𝑑𝑒:

1. Seja GXOR uma GSPN contendo um lugar PXOR e transições imediatas

qx1, ..., qxN, com PXOR•={qxi}, i = 1, ..., N;

2. 𝜔(𝑞𝑥𝑖) = Pr(𝑈𝑖) , 𝑖 = 1, … , 𝑁;

3. 𝑈𝑅 = 𝑈1 ∪. . .∪ 𝑈𝑁 ∪ 𝐺𝑋𝑂𝑅, acrescida de arcos, de tal forma que:

(a) 𝑆𝑡𝑎𝑟𝑡(𝑈𝑅) = 𝑃𝑋𝑂𝑅;

(b) 𝐸𝑛𝑑(𝑈𝑅) = 𝐸𝑛𝑑(𝑈1) … 𝐸𝑛𝑑(𝑈𝑁);

(c) 𝑆𝑡𝑎𝑟𝑡(𝑈𝑖) = {𝑞𝑥𝑖}, 𝑖 = 1, … , 𝑁.

Este gateway cria caminhos que são executados como alternativas

exclusivas de execução. A Figura 5.24 mostra a representação original deste

elemento de acordo com a Definição 5.6, presente no Quadro 5.5.

Figura 5.24: Composição de caminhos alternativos (XOR). Fonte: (Oliveira, 2008).

91

As probabilidades de execução que podem ser digitadas em cada fluxo

de saída no diagrama BPMN original, são transferidas, por meio dos métodos

desenvolvidos no protótipo para os elementos que irão compor o seu

equivalente na GSPN.

Figura 5.25: Transformação de um fluxo contendo caminhos alternativos exclusivos.

Os caminhos exclusivos não têm necessidade de sincronização, ou seja,

não é obrigatório em BPMN que haja uma junção dos caminhos gerados. No

entanto, como eles podem ocorrer, então esta possibilidade também foi

mapeada, extendendo-se o conceito definido no operador caminho alternativo.

Embora possa estar claro cabe evidenciar que o fluxo GSPN resultante

garante as propriedades de unicidade definidas no elemento BPMN apenas

com as regras de disparo de transições das RdP. O evidente conflito na

prioridade de disparo das transições pode ser resolvido com as probabilidades

de disparo dos mesmos que devem ser introduzidas nas propriedades dos

fluxos do processo BPMN original, da mesma forma como foram introduzidos

os delas das tarefas e as quantidades de papeis das raias.

Os rótulos de cada uma das transições que saem do lugar Desvio1 da

Figura 5.25 são gerados com o nome padrão qx seguido de um incremento que

servirá para todos os elementos qx de um mesmo diagrama. Se no fluxo BPMN

correspondente estiver explicitada o texto da condição para a execução de

cada caminho, essa descrição também fará parte do rótulo dessas transições

qx (conforme pode ser visto na Figura 5.25).

92

Figura 5.26: junção com gateway exclusivo

Na Figura 5.26 está representada uma junção com esse tipo de

gateway. Este ponto serve apenas como convergência não obrigatório e é

mapeado apenas como um par lugar-transição sem influência no peso do

caminho seguido. O número da transição qx segue a regra de numeração

incremental já descrita anteriormente.

Figura 5.27: Transformação de um bloco com dois gateways exclusivos.

93

Para dar um quadro geral da transformação a Figura 5.27 representa o

mapeamento de uma parte de um fluxo contendo um desvio e uma junção

usando o gateway exclusivo e sua equivalente em uma GSPN.

Para melhor exemplificar um processo simples contendo essa

transformação foi desenhado em BPMN e transformado usando o protótipo. O

resultado está exibido na Figura 5.28, na qual se tem o diagrama desenhado

na ferramenta Bonita e o mesmo diagrama transformado para uma GSPN de

acordo com as regras vistas até o momento.

Figura 5.28: Exemplo de transformação XOR usando o protótipo

5.9.2 Transformação de gateways paralelos

Os gateways paralelos quando surgem como um elemento de divisão

em um fluxo, fazem com que todos os fluxos que se originam deles sejam

executados obrigatoriamente em paralelo.

94

Esta situação é descrita em (Oliveira, 2008) como um caminho

alternativo ou Paralelo And, que é semelhante à definição do gateway paralelo

da BPMN, as definições necessárias, como nas transformações anteriores

estão no Quadro 5.6.

Diferentemente da definição XOR anterior este operador precisa ser

sincronizado com um operador de junção também do tipo AND. É possível que

não haja o sincronismo, no entanto a semântica é diferente, sendo obtidos

resultados diferentes se não houver tal sincronismo.

Quadro 5.6: Definição do Operador Paralelismo – AND. Fonte: (Oliveira, 2008)

Definição 5.7 (Operador Paralelismo - AND):

𝐴𝑁𝐷: 𝑆𝑃𝑟𝑜𝑐 × . .× 𝑆𝑃𝑟𝑜𝑐 × → 𝑆𝑃𝑟𝑜𝑐

𝐴𝑁𝐷(𝑈1, 𝑈2, … , 𝑈𝑁, 𝑃𝑟) = 𝑈𝑅, 𝑜𝑛𝑑𝑒:

1. Seja GAND uma GSPN contendo um lugar PAND, uma transição imediata qsplit,

com PAND• = {qsplit}, um conjunto de lugares {Z1, ..., ZN} e uma transição

imediata qz, tal que •qz={Z1, ..., ZN};

2. 𝑈𝑅 = 𝑈1 ∪. . .∪ 𝑈𝑁 ∪ 𝐺𝐴𝑁𝐷, acrescida de arcos, de tal forma que:

(a) 𝑆𝑡𝑎𝑟𝑡(𝑈𝑅) = 𝑃𝐴𝑁𝐷;

(b) 𝐸𝑛𝑑(𝑈𝑅) = {𝑞𝑧};

(c) • 𝑆𝑡𝑎𝑟𝑡(𝑈𝑖) = 𝑞𝑠𝑝𝑙𝑖𝑡, 𝑖 = 1, … , 𝑁;

(d) • 𝑍𝑖 = 𝐸𝑛𝑑(𝑈𝑖), 𝑖 = 1, … , 𝑁.

Figura 5.29: Composição em Paralelo (AND). Fonte: (Oliveira, 2008).

A representação correspondente à Definição 5.7 está apresentada na

Figura 5.29.

95

A definição citada e sua representação foram a inspiração para a

transformação do gateway paralelo apresentado na Figura 5.30.

Figura 5.30: A transformação de um par de gateways paralelos

Como este elemento, em boa parte das construções deve existir em

pares, com um elemento de desvio, após o qual o fluxo se divide em atividades

paralelas e no final da execução de cada caminho há um ponto de

convergência e consequente sincronização dos fluxos paralelos. A Figura 5.31

representa os dois usos do gateway paralelo: como elemento de divergência,

com uma entrada e várias saídas; e como elemento de convergência e

sincronismo com várias entradas e uma saída.

Assim como foi feito para o gateway exclusivo (XOR) também está

apresentada na Figura 5.32 um exemplo de uma transformação para o gateway

paralelo (AND) utilizando as mesmas ferramentas e o protótipo.

96

Figura 5.31: Gateway paralelo nas duas situações separadas.

Figura 5.32: Um exemplo de transformação de gateway paralelo

97

5.9.3 Transformação de gateways inclusivos

O terceiro e último dos tipos de gateways gerados pela ferramenta BOS

também é o mais complexo deles. O gateway inclusivo funciona como uma

mistura entre o gateway paralelo e o gateway exclusivo, podendo o resultado

da sua divisão (quando é um desvio) ser desde o mesmo de um gateway

exclusivo, ou seja, apenas um dos caminhos é executado ou ser o mesmo de

um gateway paralelo, no qual todos os caminhos são executados, podendo,

ainda ser qualquer uma das combinações entre essas duas possibilidades.

No conceito do gateway paralelo definido em (OMG, 2013) há duas

condições obrigatórias que o tornam particularmente complexo:

1. Pelo menos um dos caminhos deve ser seguido

2. Todos os caminhos que forem executados devem ser sincronizados

por um gateway inclusivo de junção.

A primeira restrição trouxe uma complexidade consigo: como garantir

que pelo menos um dos caminhos seja seguido em um cenário no qual as

opções não dependem umas das outras como é o caso do gateway exclusivo?

A própria notação BPMN sugere que um dos caminhos seja considerado

um caminho padrão que seria executado caso nenhum dos outros o fosse,

garantindo, dessa forma que pelo menos um caminho seria seguido.

A segunda restrição cria a necessidade de um gateway inclusivo de

junção para cada gateway inclusivo de desvio que for criado, pois cria a

obrigatoriedade de não apenas um sincronismo como o existente no gateway

paralelo, mas um sincronismo que tenha memória sobre quais subprocessos

foram executados para que somente esses sejam sincronizados.

Para resolver esse mapeamento (Oliveira, 2008) apresenta uma solução

correta (Figura 5.33), mas cuja complexidade aumenta exponencialmente

quando a quantidade de caminhos paralelos aumenta. Essa solução garante

que as duas condições sejam atendidas mas o custo de produzi-la fez com que

a mesma fosse descartada para este trabalho.

98

Figura 5.33: Composição de múltiplos caminhos com sincronização (OR) proposto por

No exemplo da Figura 5.33 o lugar Por é o ponto de entrada, estando

ligado a três transições com probabilidades de disparos distinta (𝛼, 𝜋, 𝛽) que

totalizam 100%. As transições q1 e q2 representam a possibilidade de que

apenas os subprocesso U1 ou U2 sejam executados exclusivamente e a

transição qs indica a execução dos dois processos em paralelo. Os lugares C1 e

C2 recebem o fluxo da execução dos processos U1 e U2 respectivamente. Os

lugares H1 e H2 funcionam como sincronismo para quando os processos

estiverem sendo executados em paralelo. Independente da possibilidade de

que essa estrutura funcione ou não para N fluxos, ela é inviável na prática pois

é sabido, através da análise combinatória que um conjunto de n elementos terá

2n possíveis conjuntos de combinações, incluindo o elemento vazio e as

execuções únicas de cada processo, como neste caso não se considera a

possibilidade de nenhum processo ser executado, o número de combinações

consideradas passa a ser 2n-1, e como os fluxos únicos já são parte do

modelo, para se obter a quantidade de combinações com mais de um fluxo (ou

o número de transições qs) basta excluir as execuções únicas, ou seja, o total

de transições qs para n fluxos paralelos seria de 2n-(n-1). Além disso a solução

proposta só considera a combinação dos caminhos em pares, no caso de três

fluxos, por exemplo, há a possibilidade de execução dos 3 simultaneamente.

Essa possibilidade o modelo não prevê. Por isso que esta solução foi

descartada como possível de ser executada no presente trabalho.

Uma opção menos precisa mas que satisfaz as restrições da forma

como são desenhadas na BPMN, foi criada baseada no trabalho de (Ramadan,

99

Elmongui, & Hassan, 2011). Esta solução não garante tacitamente a execução

de, pelo menos, um caminho nem mesmo garante que os caminhos seguidos

sejam encerrados, de fato. A proposta está representada na Figura 5.36. É

uma proposta teórica sem o mesmo formalismo matemático da proposta

anterior.

Figura 5.34: mapeamento de gateway inclusivo proposto por (Ramadan, Elmongui, & Hassan, 2011)

Essa proposta considera cada caminho a ser seguido como um par de

decisões independentes entre si, sendo que no caso representado na Figura o

autor considera um caminho padrão, tornando os caminhos dependentes entre

si. O modelo citado foi desenvolvido para redes de Petri coloridas, que não são

o foco desse trabalho e teve mais um papel de inspiração do que base real

para o modelo proposto aqui, pois ele sugere a geração de caminhos

independentes e que esses caminhos teriam probabilidades de execução ou

não

A solução adotada para esse gateway foi uma rede gerada tendo como

inspiração a ideia da Figura 5.34, levando em consideração as probabilidades

de cada caminho.

100

Figura 5.35: Tranformação de gateway inclusivo

Na Figura 5.35 está representado essa transformação. Analisando as

situações de divisão e de junção separadamente pode-se ver que na divisão a

entrada do Desvio1 é o lugar Por-1, lembrando que esse número representa

101

um sequencial de todos os desvios desse tipo, esse lugar está ligado a uma

transição que recebe como rótulo o nome do gateway desvio1. Quando essa

divisão é disparada a mesma coloca tokens em todos os lugares Px1 (esses

lugares recebem o mesmo número do lugar Por-1). Os lugares Px1 recebem

um índice sequencial também. As transições qSx1 e qNx1 representam,

respectivamente a execução ou não execução do subprocesso Un, lembrando

que os números completos de cada um dos elementos são Px1-n, qSx1-n e

qNx1-n, para o primeiro desvio inclusivo encontrado, sendo o número 1 que

aparece em cada elemento incrementado juntamente com a quantidade de

gateways inclusivos transformados.

A definição de qual transição (qSx ou qNx) irá disparar dependerá das

condições serem satisfeitas ou não, podendo ser simuladas com as

probabilidades de execução dessas transições. Essa construção permite,

teoricamente, a criação de um caminho com custo zero, mas essa

possibilidade pode ser evitada, na prática ou com a modificação para a criação

de um caminho padrão a ser executado quando todas as outras possibilidades

não forem executadas. No entanto tal solução necessitaria de um modelo mais

complexo e deixaria os caminhos dependentes de, pelo menos um dos

caminhos (o caminho padrão). Esta possibilidade é descrita na documentação

do BPMN da OMG (OMG, 2013), no entanto não foi criada uma opção para

esse tipo de construção, ficando isso para um trabalho futuro.

A junção do gateway inclusivo tem uma característica importante, já

citada que é a necessidade de que cada um dos caminhos executados seja

finalizado para que o processo continue. Os lugares Z2 do exemplo (cujo índice

2 se refere ao segundo gateway desse tipo encontrado no documento)

garantem que isso aconteça pois precedem a transição que recebe o nome da

junção e que será disparada apenas quando todos os lugares Z2 tiverem pelo

menos um token.

Assim como nas transformações de gateways anteriores, foi criado um

exemplo na ferramenta BOS e esse exemplo foi exportado para o formato

BPMN 2.0, este arquivo foi lido e transformado pelo protótipo e o resultado foi

102

exibido e testado na ferramenta TimeNet. Os resultados desses testes podem

ser observados na Figura 5.36.

Figura 5.36: Um exemplo de uma transformação de um gateway inclusivo

5.10 Transformação de Iterações

Uma das estruturas de controle de fluxo apresentados na Seção 3.1.1 é

a iteração, que se compõe de elementos que permitam que um caminho seja

repetido por um determinado número de vezes.

Em BPMN isso pode ser conseguido de duas formas: com uma atividade

com o modificador de loop ou utilizando-se um gateway exclusivo, conforme

pode ser visto na Figura 5.37a.

103

A representação de uma tarefa em loop está presente na ferramenta

utilizada, no entanto o mesmo não é exportado6 para o formato BPMN 2.0

utilizado no protótipo. Este mesmo loop pode ser representado utilizando-se um

gateway exclusivo (Figura 5.37b) cuja representação em redes de Petri foi

definida na Seção 5.10.1.

Figura 5.37: Representação de um loop em BPMN

Outros tipos de modificações de atividades e tarefas não foram incluídos

neste trabalho pela mesma limitação imposta pelo formato BPMN 2.0, algo que

poderá ser corrigido em um trabalho futuro se for adotado o formato XPDL ou o

próprio formato nativo da ferramenta Bonita.

Essas limitações vêm sendo corrigidas pela equipe de desenvolvimento

da ferramenta BOS. Itens que não eram exportados para BPMN 2.0 na época

da construção do protótipo (poucos meses antes da conclusão desse

documento) atualmente são exportados.

5.11 Considerações Finais

Neste capítulo foi apresentado o desenvolvimento do trabalho, com as

definições essenciais do protótipo e com a exposição dos motivos que levaram

a se utilizar uma ou outra ferramenta ou alternativa para o seu

desenvolvimento.

Conforme foi descrito, nem todas as possibilidades foram exploradas,

ficando aberta uma ampla gama de possibilidades de continuação do trabalho

atual.

6 Na época da criação do protótipo. Atualmente a ferramenta permite tal exportação e várias outras que foram incorporadas ao formato BPMN 2.0

104

Capítulo 6

Estudo de Caso

Neste capítulo será ilustrado um estudo de caso aplicado a um dos

processos que estão sendo mapeados na Secretaria da Fazenda do Estado do

Piauí (Sefaz-PI).

Os objetivos buscados nesse estudo de caso foram:

1. Provar a utilidade da ferramenta no uso de um caso prático;

2. Utilizar os testes existentes para redes de Petri em um fluxo

originalmente desenhado em BPMN;

3. Verificar a viabilidade de uso das técnicas de avaliação de redes de

Petri em processos de negócios desenhados em BPMN.

Para atingir esses objetivos foi escolhido o processo de lançamento de

IPVA (Imposto de propriedade sobre Veículos Automotores) para veículos

novos, utilizado na Sefaz-PI juntamente com o Detran-PI.

Esse processo foi modelado em BPMN no Bonita juntamente com a

equipe de desenvolvimento da Unidade de Tecnologia da Sefaz-PI,

responsável pelo desenvolvimento desse e de outros sistemas daquela

Secretaria.

Para o referido processo foram estabelecidas as seguintes metas a

serem atingidas após as análises e mudanças no processo: Reduzir em, pelo

menos, 50% o tempo de liberação para o emplacamento de veículo novo.

Atualmente esse tempo está acima de 4 dias, o objetivo é que fique abaixo ou

igual a 2 dias. Para tal é necessário melhorar o tempo de atendimento,

melhorando o tempo de resposta como um todo.

105

O processo aqui mapeado faz parte da documentação do sistema de

emplacamento de veículos do Governo do Estado do Piauí.

6.1 Descrição do Processo de Lançamento de IPVA

O processo se inicia com a venda de um veículo 0 km, efetuado em uma

das concessionárias do estado do Piauí. Após a venda uma nota fiscal

eletrônica é gerada e distribuída pelo sistema do Serviço Federal de

Processamento de Dados (Serpro).

Figura 6.1: Processo de lançamento de IPVA – Veículo Novo em BPMN

Uma vez que essa nota esteja disponível um webservice da Sefaz-PI

consome o serviço oferecido pelo Serpro e obtém esta nota fiscal, inserindo-a

no banco de dados da Secretaria com a devida validação. Enquanto isso, o

veículo é encaminhado para a vistoria no Departamento de Trânsito do Piauí

(Detran-PI). Neste momento o veículo já estará pré-cadastrado aguardando

que seja informado pelo Detran-PI que a vistoria foi executada, momento no

qual o fluxo, que ocorria em paralelo entre Detran-PI e Sefaz-PI é sincronizado

106

e o passo seguinte que é a atualização do cadastro realizado na Sefaz-PI. A

Figura 6.1 representa este processo desenhado em BPMN.

Após o cadastro ser atualizado via script pela Sefaz-PI o IPVA é lançado

pela Sefaz-PI, permitindo que o Detran-PI lance suas taxas, juntamente com

outros pagamentos em boletos. Esses boletos podem ser acessados e pagos

por um despachante (geralmente na própria concessionária) ou pelo

proprietário, nesse caso, por simplicidade foi admitido como executor dessa

tarefa a própria concessionária (o que de fato, geralmente ocorre em boa parte

dos casos, uma vez que esse serviço é ofertado aos clientes).

Uma vez recebidos por um agente recebedor a informação de

pagamento é enviada para a Sefaz-PI que realizará o procedimento de baixa.

Este envio tem um detalhe importante que não foi mapeado no modelo: a sua

variação. Dependendo de qual agente recebe o pagamento, o mesmo pode

levar de 15 minutos a 24 horas para ser informado, pois o Detran possui um

acordo com o Banco do Brasil para o envio da informação de pagamento em,

no máximo, 15 minutos enquanto que outros agentes informam no prazo

bancário normal de 24 horas. Como os pagadores já sabem dessa diferença a

grande maioria dos pagamentos acabam sendo feitos no Banco do Brasil ou

nos seus agentes, por isso foi considerado esse tempo para efeito de

simulação.

O procedimento de baixa segue uma lógica estabelecida na Sefaz-PI a

qual utiliza o conceito de conta corrente. Se o contribuinte pagar um valor que

seja suficiente para quitar todo o IPVA, o mesmo será considerado totalmente

quitado, a baixa será realizada e essa informação repassada ao Detran-PI que

poderá prosseguir com o processo de emissão da documentação. Caso o valor

seja suficiente para quitar, pelo menos uma parcela, mas não todo o valor

devido, o mesmo procedimento será feito em relação ao sincronismo com o

Detran-PI, ou seja, o mesmo prosseguirá com o seu processo de emissão de

documentos, neste caso, no entanto, o IPVA continuará constando em aberto.

O terceiro caso, quando o pagamento não é suficiente para quitar sequer uma

parcela do IPVA devido, o valor pago ficará na conta corrente do contribuinte,

aguardando complementação e o processo se encerrará sem a continuação do

107

processo junto ao Detran. A continuação do processo de sincronização, neste

último caso se dará em outro processo de complementação de pagamento, que

também utiliza o processo de baixa, uma vez que esse processo é um

subprocesso representado aqui como parte do processo interno de lançamento

de IPVA apenas como forma de simplificar o estudo de caso.

A probabilidade de execução de cada caminho foi informada nos fluxos

BPMN, usando a notação semelhante à utilizada para o delay da tarefa e para

a capacidade. No caso foram especificadas as probabilidades de 5% para o

caminho não quitado, 15% para quitado parcialmente e 80% para quitado,

estatísticas obtidas na Sefaz-PI.

O processo descrito foi apresentado como o primeiro processo de

negócio mapeado em BPMN na Sefaz-PI. Atualmente outras equipes

participam no mapeamento, análise e redesenho de outros processos. Uma

parte utilizando o Bonita Open Solution e outra usando o Bizagi. Há uma

possibilidade (embora remota) que se utilize uma terceira ferramenta: o Oracle

BPM Suite.

6.1.1 Exportação e transformação do processo

Conforme já descrito em capítulos anteriores o processo criado no

Bonita pode ser exportado para o formato BPMN 2.0 para que possa ser

transformado pelo protótipo em uma rede de Petri, no caso específico em uma

rede EDSPN que possa ser lida, testada e executada pela ferramenta TimeNet.

O resultado em XML da exportação para o BPMN 2.0 está no Anexo B,

código B.1. Este é o arquivo base para a transformação cujo resultado, após

executado o protótipo está listado no Código B.2. Essa rede de Petri resultante

está representada na Figura 6.2

Os tokens presentes nos lugares que representam as raias da notação

BPMN original foram obtidos da forma como descrito na Seção 5.6 sobre

mapeamento de pools e raias.

108

Figura 6.2: Estudo de caso transformado para a notação de Rdes de Petri

A primeira vantagem do uso do protótipo é a eliminação da necessidade

de redesenhar o processo, o que já é um ganho razoável pois quase todos os

elementos não só precisam ser redesenhados mas utilizam-se de mais de um

elemento GSPN. Deve-se levar em conta que o desenho original geralmente

precisa ser organizado manualmente devido às diferenças de tamanho e

formato das duas notações. No caso, os dois fluxos foram ajustados também

para melhor visualização no trabalho.

Uma vez que o processo BPMN foi transformado é possível aplicar os

testes necessários para validar a rede gerada.

6.1.2 Simulação do processo no Bonita

Foram levantados os tempos aproximados de execução das tarefas

existentes no caso. Esses tempos estão descritos na Tabela 6.1.

109

Conforme explicado no Amexo A, o Bonita tem a funcionalidade de

simulação do processo que visa permitir verificar o seu uso durante um período

e gerar gráficos de performance com os dados coletados.

Tabela 6.1: Histórico do Lançamento de IPVA

Taxa de chegada 0,004 casos/hora

Venda de Veículo 1 hora

Gerar NF-e 15 minutos

Validar NF-e 15 minutos

Encaminhar para Vistoria 1 hora

Realizar a Vistoria 1 hora

Realizar pré-cadastro 15 minutos

Atualizar Cadastro 30 minutos

Lançar IPVA 1 hora

Lançar Taxas e Serviços 15 minutos

Pagar IPVA 30 minutos

Informar Pagamento 15 minutos

Verificar Situação de Pagamento 15 minutos

Alterar Status Tota 15 minutos

Alterar Status Parcial 15 minutos

Alterar Status Não Quitado 15 minutos

Sincronismo Detran 15 minutos

Totalmente Quitado? 80%

Quitado parcialmente? 15%

Não quitado 5%

Para a execução da simulação foram inseridos os recursos que podem

ser exportados para o formato do TimeNet, no caso os atores e papéis

específicos de Concessionária, Arrecadador, Serpro, Detran e Sefaz, conforme

a Figura 6.3.

110

Figura 6.3 Resultado das simulações do processo Lançamento de IPVA no BOS.

Aos recursos foram atribuídos custos aproximados em cada utilização no

processo, sendo que o recurso concessionária foi considerado de custo zero,

embora esse não seja um dos itens diretos de interesse na melhoria do

processo.

Um perfil de carregamento foi definido para um período de um mês com

repartição constante e 300 instâncias e a simulação foi executada para simular

um intervalo de amostragem de 1 dia. Esses valores se devem à média de

veículos novos vendidos no estado do Piauí diariamente que é de 300 veículos.

Figura 6.4: Tempo de execução de instâncias por dia gerados pelo BOS.

Ao ser executada a simulação o Bonita gerou a série de gráficos de

performance das iterações. A Figura 6.4 tem a representação do gráfico de

tempo médio de execução das instâncias. Conforme pode ser visto esse tempo

variou no período da simulação (dias no eixo X) entre um valor mínimo de 30

horas e um máximo de 90 horas, tendo um limite (linha tracejada horizontal do

111

gráfico) em 77 horas. Conforme será visto mais adiante esse dado está de

acordo com a simulação do processo no TimeNet.

Nem todas as atividades tiveram um gráfico relevante. Por exemplo a

atividade amortizar conta corrente não chegou a ser executada, pois foi

estabelecido para ela uma probabilidade de 5%, algo razoável pois a execução

dessa atividade implica na não continuidade do processo de compra do veículo

e ela raramente ocorre de fato.

Da mesma forma muitas das atividades existentes são automatizadas e

tem um tempo de execução muito pequeno, se tornando quase irrelevantes

para a simulação.

Ainda analisando os gráficos de execução por tempo tem-se o gráfico da

tarefa encaminhar para vistoria na Figura 6.5. Nele se percebe a grande

variação desta atividade, podendo ir de alguns minutos a quase 40 horas.

Figura 6.5: Tempo de execução da atividade Encaminhar para Vistoria.

Outro gráfico a ser destacado é o de tempo de espera da tarefa Pagar

Taxas e Impostos, apresentado na Figura 6.6. Também há uma grande

variação nesse gráfico. O que é razoável uma vez que ele aguarda que a

vistoria seja feita para que as taxas possam ser pagas.

112

Figura 6.6: Tempo de espera da atividade Pagar Taxas e impostos.

E finalmente os tempos de execução das instâncias da tarefa Realizar

Vistoria (Figura 6.7). Que pode levar, em média, até 7 horas e meia, podendo

chegar ao limite de 15 horas.

Figura 6.7: Tempo de execução das instâncias de Realizar Vistoria.

Figura 6.8: Custo de arrecadador por dia

Outros dados gerados nos gráficos de simulação têm relação com o

custo dos recursos. Neste quesito um dos custos mais visíveis é o do

arrecadador. Cada recebimento de pagamento gera um custo de R$ 3,00. Na

simulação executada o gráfico de custos por arrecadador mostra que, em

alguns dias o valor chega a mais de R$ 7.000,00 (são os pontos em que vários

113

processos chegam à tarefa de pagamento, esse gráfico pode ser visto na

Figura 6.8.

Outros gráficos de custos são gerados, mas seus valores são muito

pequenos se comparados aos custos de recebimento.

Para ter uma ideia mais precisa do processo, vários perfis de

carregamento precisam ser definidos, mas pelos gráficos aqui apresentados

pode-se ver que o processo apresenta o comportamento esperado, levando em

torno de 70 horas para ser concluído, o que está de acordo com o processo

atual.

A conclusão do que foi estabelecido para a melhoria desse processo

será apresentada no final deste capítulo, após a análise feita no processo

gerado pela ferramenta.

6.2 Avaliação do processo exportado

Verificações foram feitas também no processo transformado, desde a

verificação de sua validade com os testes existentes na TimeNet, tais como

Estimate Statespace e Estimate Structure (alguns deles exibidos na Figura 6.9)

até a coleta das métricas baseadas nos valores existentes na Tabela 6.1.

Foram inseridas no modelo GSPN as métricas a serem coletadas

através de simulações estacionárias (essas métricas serão geradas

automaticamente numa futura melhoria da ferramenta). Nesse ponto se

encontrou um problema na ferramenta TimeNet o qual foi relatado à equipe de

desenvolvimento da ferramenta, de onde se obteve a resposta de que tais

problemas já são conhecidos e que seriam solucionados em uma versão que

deverá ser lançada em breve. A principal restrição foi em relação à quantidade

de papéis inseridos, valores acima de 10 papéis inviabilizam a simulação. Para

contornar esse problema foram feitas simulações com quantidade menor de

papéis e, logicamente, de recursos.

114

Figura 6.9: Validando a GSPN gerada

As simulações foram executadas com confiabilidade de 95% e erro de

10% (dados inseridos na ferramenta Timenet). As taxas de chegada internas

de cada uma das tarefas foram tabuladas e a relação percentual entre elas

está representada no gráfico da Figura 6.10.

Como esperado a tarefa Realizar Vistoria é a que tem maior taxa de

chegada. O tempo total de execução do processo foi de 79 horas ou pouco

mais de 3 dias. Para o processo é algo razoável, dadas as informações

disponíveis.

115

Figura 6.10: taxas de chegadas internas por tarefa

Para os dados inseridos na simulação do TimeNet observou-se que o

arrecadador e o Detran são os papéis com desempenho crítico. Uma

alternativa seria deslocar alguma tarefa do papel Detran para outro papel do

processo.

Por questões práticas a solução encontrada foi transferir a tarefa de

vistoria, responsável por boa parte dos atrasos no processo para a

concessionária, conforme está explicado na conclusão deste capítulo.

6.3 Conclusões sobre o estudo de caso

Conforme foi a proposta deste trabalho um processo real desenhado em

BPMN foi exportado para uma GSPN, avaliada quanto à sua corretude e

eficiência em ambos os formatos.

Com isso se pode utilizar das qualidades inerentes a cada uma das

notações. E sobre isso pode-se afirmar que as simulações de ambas as

ferramentas são equivalentes e complementares. Enquanto na Bonita se tem

116

uma simulação gráfica, essa simulação é falha ao não disponibilizar dados

brutos para estudos próprios de quem está analisando a simulação.

Por outro lado a ferramenta TimeNet tem uma forte conotação

matemática e técnica, como deveria ser, mas faltam recursos gráficos, ficando

a cargo de quem analisa a rede não só dominar totalmente a teoria matemática

que sustenta a análise, mas também a criação dos gráficos eventualmente

necessários para uma apresentação a uma equipe heterogênea de gerentes

comerciais e diretores, por exemplo.

Este processo foi apresentado em Janeiro de 2013 na sede da Sefaz-PI

com equipes técnicas do Detran-PI e da Sefaz-PI, além de diretores e gerentes

dos dois órgãos.

Durante o encontro se estabeleceu o uso do Bonita para mapeamento

de todos os processos de negócios da Sefaz-PI e do possível uso das

avaliações feitas na TimeNet para auxiliar na avaliação dos processos. Os

trabalhos de mapeamento continuam, sendo o mais recentemente implantado o

processo de implantação da nota fiscal avulsa na web.

Quanto aos resultados da avaliação se concluiu que a etapa de todo o

processo que gerava mais atrasos (que se propagavam por todo o restante do

processo) era a única tarefa manual e com recursos limitados: a vistoria. Desde

2013 a vistoria de veículos novos é realizada dentro da própria concessionária

e, atualmente o próprio emplacamento é feito na concessionária. O processo,

tal como existe hoje, leva um tempo máximo de 2 dias. Até onde foi pesquisado

é o único estado da federação cujo Detran está integrado à Secretaria da

Fazenda graças à informática.

O estudo de caso apresentado serviu para demonstrar a eficácia do

protótipo, provar sua aplicação prática na transformação de um modelo para o

outro, assim como demonstrar que as notações BPMN e GSPN podem ser

usadas em conjunto para a verificação automática da eficácia de um processo

de negócio.

117

Atualmente a Sefaz-PI aguarda a conclusão deste trabalho para aplicar

seus resultados em diversos processos já mapeados. O autor do trabalho está

atuando como consultor interno na implantação de BPMN e a mesma já foi

inserida em outros órgãos como secretaria da educação (em fase de

implantação) e na secretaria do planejamento, que já contava com uma equipe

e solicitou a atuação da Sefaz-Pi nesse processo.

118

Capítulo 7

Conclusões

Neste capítulo são apresentadas as conclusões, contribuições e

limitações de implementação deste trabalho. Em seguida são relacionados

trabalhos futuros concernentes aos tópicos abordados.

7.1 Conclusões

Conforme pode se constatar pelo desenvolvimento do presente trabalho,

as representações em BPMN são mapeáveis para redes de Petri, mais

especificamente para o modelo apresentado por (Oliveira, 2008), com os

devidos ajustes.

Embora não tenha sido provado, é possível que a notação de redes de

Petri, seguindo os modelos aqui apresentados, seja transformada de volta em

BPMN, pois as classes de transformação criadas em Java foram desenvolvidas

de forma a associar cada elemento da BPMN ao seu conjunto equivalente em

GSPN. Pode-se desenvolver um trabalho futuro para verificar essa

possibilidade.

A aplicação de métodos já definidos em trabalhos anteriores, aqui

corroborados e, em alguns casos, modificados se mostrou eficiente

demonstrando o potencial para uma ferramenta que una as duas notações,

podendo obter, dessa forma, as vantagens das duas formas de se desenhar

processos.

O trabalho ora apresentado representa, possivelmente, o início do

desenvolvimento de uma ferramenta que seja eficiente na união dessas duas

vertentes de abordagem de processos, unindo o mapeamento de processos a

119

uma teoria matemática forte, além de representar a concretização de uma

ferramenta já definida teoricamente em trabalhos anteriores.

A construção do protótipo foi o ponto central deste trabalho e o mesmo

deverá ficar à disposição para melhorias e trabalhos futuros.

Este trabalho também serviu de base para a implantação das

metodologias de processos de negócios na Sefaz-PI, onde foram realizados os

testes e onde foram apresentados alguns dos conceitos e resultados aqui

apresentados, muitos desses conceitos estão fazendo parte, atualmente do

modo de trabalhar de vários setores daquela secretaria, na qual a ferramenta

Bonita Open Solution foi adotada juntamente com outras soluções como Bizagi

e, em estudo o Oracle BPM Suite.

Por fim, o trabalho aqui apresentado serviu aos propósitos que se dispôs

a servir:

Implementou a transformação da notação BPMN para Redes de

Petri (GSPN, mais especificamente);

Incentivou na comunidade local onde foi inserido o uso de

processos de negócios para o conhecimento, melhoria e

automação dos processos;

Iniciou a construção de um software que poderá vir a ser uma

ferramenta importante na análise e melhoria de processos de

negócios;

Construiu uma ponte entre duas notações distintas que atendem

a públicos distintos e tem qualidades e dificuldades distintas,

possibilitando, assim a soma das qualidades e a diminuição dos

defeitos de ambas;

Possibilitou a análise de desempenho das redes exportadas

utilizando-se técnicas existentes nas GSPN;

Permitiu a validação de uma simulação da BPMN com uma

simulação GSPN;

120

Pode-se destacar como principal contribuição a construção de

uma ponte entre os processos de negócio em BPMN e as GSPN

e todas as implicações práticas resultantes.

7.2 Trabalhos Futuros

O trabalho apresentado é um começo de uma ferramenta que poderá e

deverá ser melhorada. O seu uso pode ser útil para o estudo e melhoria dos

processos de negócios.

Algumas construções de BPMN não foram mapeadas por conta de

limitações de tempo e recursos das ferramentas utilizadas. Uma possível

continuação para esse trabalho seria o mapeamento desses elementos.

Mais estudos comparativos entre os dois formatos em relação à medição

dos processos podem e devem ser desenvolvidos.

A transformação de BPMN para SCPN não foi totalmente testada (e

mesmo o que foi testado não está relatado nesse trabalho), um trabalho nesse

sentido pode ser mais um dos trabalhos a serem feitos.

A transformação de uma rede de Petri de volta ao formato BPMN

(seguindo a notação sugerida) pode ser outra sugestão de trabalho futuro.

Além disso o protótipo ou suas melhorias poderão ser úteis no desenho

de redes de Petri que se utilizem da notação aqui sugerida, podendo ser

utilizada como suporte a pesquisas que utilizem esta notação.

121

ANEXO A

Ferramentas utilizadas

A escolha das ferramentas utilizadas no trabalho foi baseada em alguns

fatores: independência de plataforma, disponibilidade, preço, relevância junto à

comunidade acadêmica e disponibilidade. A escolha recaiu sobre os softwares

Bonita Open Solution (BOS) (BonitaSoft , 2011) e TimeNet (Zimmermann &

Knoke, 2007) uma vez que ambos (dentro de certos limites) se enquadram nos

critérios de escolha adotados.

O BOS é um produto relativamente novo que trouxe uma novidade (na

época do seu lançamento) ao gerenciamento de processos e em particular ao

BPMN: uma ferramenta totalmente livre, gratuita e open-source.

A TimeNet é uma ferramenta desenvolvida na Technische Universität

Berlin por pesquisadores do Real Time-Sistems and Robotics Group, Ele é um

conjunto de ferramentas gráficas e interativas para a modelagem de Redes de

Petri Estocasticas (SPN) (Cardoso & Valette, 1997) e para redes de Petri

estocásticas e coloridas (SCPN – Stochastic Colored Petri Nets) (Cardoso &

Valette, 1997).

Ambas as ferramentas são descritas a seguir.

A.1 Introdução à Ferramenta Bonita Open Solution

O Bonita Studio, também conhecido por Bonita Open Solution ou BOS

foi criado em 2009 pelos fundadores do Bonita Project. Segundo white papers

encontrados no site da ferramenta (www.bonitasoft.com), a mesma já foi

baixada mais de 300 mil vezes.

O diferencial dessa ferramenta é ser aberta, multiplataforma e ter uma

versão gratuita totalmente funcional.

122

Ela foi construída com base na IDE Eclipse, é open source e suporta a

adição de funcionalidades pelos seus usuários, possibilitando que a

comunidade possa contribuir com componentes adicionais que venham a ser

integrados à ferramenta. Uma das possibilidades de desenvolvimento do

protótipo desenvolvido nesse trabalho é se tornar um add-on para o Bonita.

Uma das principais restrições do Bonita é que ele não tem todos os

elementos existentes na BPMN, além de não trabalhar com coreografias. Na

Figura A.1 estão exibidos todos os elementos da paleta do Bonita.

Se for feita uma comparação com os elementos apresentados na seção

sobre BPMN ficam evidentes a falta de vários elementos. Este trabalho se

concentrará nos elementos existentes na paleta da ferramenta.

Figura A.1: Paleta do Bonita Open Solution

123

Tem-se na Figura A.2 uma captura de tela do Bonita com um processo

novo criado. Não será explicado nesse documento detalhes de uso da

ferramenta, apenas serão inseridas informações necessárias para o

entendimento do uso da mesma para os propósitos do presente trabalho.

Figura A.2: Visão geral do Bonita Open Solution

Para a execução desse trabalho foi escolhido um dos formatos de

exportação da ferramenta, o formato BPMN 2.0 (OMG, 2011). A razão dessa

escolha e suas consequências para o projeto são destacados mais à frente no

capítulo sobre o desenvolvimento do mesmo. Nesta seção apenas se quer

mostrar como esse formato é gerado na ferramenta. Ação essa representada

na Figura A.3.

O BOS é uma ferramenta BPMN que possui uma boa parte dos

elementos vistos na Seção 3.5.2. Aqui será mostrada a parte básica do uso da

ferramenta. As informações foram obtidas no site www.bonitasoft.com e essa

pode ser a fonte de informações adicionais do uso da ferramenta. Não se

pretende abranger todos os aspectos do uso da ferramenta nem ser um

manual de uso.

124

Figura A.3: O menu de exportação dos diagramas no formato BPMN 2.0

Como pode ser visto na Figura A.2 a ferramenta é dividida em áreas:

uma área com menus e botões de atalho, uma paleta de componentes, uma

área de desenho dos processos e uma área de edição de propriedades dos

elementos. Na área de propriedades é possível a definição de propriedades de

cada um dos elementos usados em um processo, tais como nomes, valores

lógicos e descrições.

Figura A.4: Edição de propriedades dos elementos no BoS.

Na edição das propriedades existem várias abas horizontais e seções

verticais em cada aba (Figura A.4). As propriedades inseridas no nome e na

descrição terão importância na transformação descrita no desenvolvimento do

protótipo.

125

Dentro dessa paleta se pode criar variáveis, atores, conectores com

bancos de dados e outros tipos de conectores, além de ter abas para se criar

páginas web baseadas em tarefas definidas nos fluxos, definir dados para

simulação e uma paleta para a avaliação do processo desenhado nele. Além

da aplicação das regras específicas de cada um dos elementos desenhados.

Algumas regras são aplicadas aos processos, tais como: não ser

permitido dois elementos com o mesmo nome, um gateway exclusivo (and) tem

que ter, pelo menos um fluxo default saindo dele e cada fluxo que não seja o

default deve ter uma função lógica associada ao mesmo.

Um conceito importante para o desenvolvimento do trabalho é o de

atores. Um ator pode estar associado a uma lane, e uma tarefa humana deve

ter um ator associado a ela mas não obrigatoriamente essa tarefa usará o ator

definido na lane. Um ator é o executor da tarefa humana.

Um processo pode ter várias pools, no entanto neste trabalho não foi

considerada essa possibilidade, sendo cada processo representado em um

único arquivo que irá gerar a partir de uma única pool o seu correspondente em

uma GSPN.

Uma descrição abrangente da ferramenta BOS não é o objetivo desta

seção e explicações adicionais podem ser acrescentadas durante a descrição

do desenvolvimento da ferramenta.

A.1.1 Validação do processo no Bonita Open Solution

Uma das funcionalidades existentes na ferramenta BOS é a validação de

um processo BPMN, conforme pode ser visualizado na Figura A.5. Ela ocorre

de duas formas: com avisos visuais no diagrama (uma figura na borda do

elemento com erro) e na forma de uma lista de erros na aba Status da

validação. Essa lista pode ser atualizada utilizando-se o botão atualizar,

conforme pode ser visto na Figura A.5

126

Figura A.5: Erro de validação no BOS

Uma vez corrigido o erro basta que se escolha o botão atualizar para

verificar novamente se o diagrama é válido.

A.1.2 Simulação do processo no Bonita Open Solution

Uma outra funcionalidade do BOS é a possibilidade de simular a

execução do processo, para isso existe o menu Simulação, no qual é possível

se definir os parâmetros da simulação e executá-la sob condições diferentes de

disponibilidade de recursos e em diferentes perfis de carregamento (esses

dados são inseridos pelo usuário da ferramenta). Os resultados acumulados de

todas as iterações são exibidos em um relatório (BonitaSoft , 2011).

Para usar a função de simulação é necessário definir os parâmetros de

cada passo individual do processo e definir os recursos e perfis de

carregamento.

A.1.2.1 Definindo parâmetros de simulação

Os parâmetros de simulação são utilizados para determinar que

condições serão aplicada em cada iteração da execução da simulação.

Um dos parâmetros que podem ser definidos são os dados (data) de

simulação.

127

Figura A.6: Inserção de parâmetros de dados no BOS

Dados podem ser de três tipos: lógicos, literais ou numéricos e seus

valores podem ser definidos por uma expressão ou uma probabilidade.

Figura A.7: Inserindo um parâmetro de dado no BOS

Os dados não são obrigatórios para a criação de uma simulação, uma

vez que esses dados em si podem ser simulados.

Outro tipo de informação para a simulação são os parâmetros de

simulação aplicados diretamente aos elementos representantes de tarefas,

desvios, transições e eventos de início, intermediários e finais. Elementos de

borda não suportam parâmetros de simulação.

Para definir parâmetros de simulação deve-se escolher um dos

elementos do processo que aceite parâmetros de simulação e selecionar na

aba horizontal simulação e na vertical General, conforme a Figura A.8.

128

Figura A.8: Parâmetros de simulação do BOS

No exemplo da Figura A.8, os parâmetros de simulação de uma tarefa

chamada Realizar Vistoria estão sendo preenchidos. Os parâmetros são:

Transições saintes são exclusivas7: Deve ser marcado quando

apenas uma das transições que saem desse elemento pode ser

selecionada. No caso de várias transições serem produzidas essa

opção marcada garante que elas não serão capturadas em

paralelo.

Tarefa Contígua: Deve ser marcada se a tarefa8 for não

interrompível. Deve ser deixada desmarcada se a tarefa puder

ficar em pausa, aguardando algum recurso temporariamente não

disponível.

Tempo de execução: Tempo de execução do passo.

7 Na versão em inglês da ferramenta esse parâmetro se chama “Outgoing transitions are exclusive”cuja tradução deveria ser Transição de saída são exclusivas. 8 Tarefa no sentido de algo a ser executado, podendo ser uma tarefa, um desvio ou evento.

129

Tempo estimado: Uma estimativa da variação (percentual a

mais) de tempo para a execução da tarefa. Se o valor for zero

então o tempo estimado será o mesmo tempo de execução.

Tempo máximo: Uma percentagem do tempo limite de execução.

Se for zero, então será igual ao tempo de execução.

Como pode ser visto na Figura A.8 existe uma aba Data que pode ser

utilizada para se definir que dados serão utilizados ou alterados pela tarefa, a

ferramenta aceita a inclusão de vários tipos de dados em uma única tarefa.

A terceira aba vertical é a de associação de recursos ao elemento

selecionado. A sua seleção para o mesmo elemento pode ser vista na Figura

A.9.

Figura A.9: Inserção de recursos em um elemento

Para adicionar um recurso previamente cadastrado basta selecionar o

botão adicionar, pode-se também editar um recurso (ele será modificado para

todos os elementos que o utilizarem) ou se pode remover um recurso (apenas

do elemento atual).

Para adicionar pode-se usar a opção do menu Simulação >> Gerenciar

recursos ou se pode adicionar recursos enquanto eles são adicionados aos

elementos através do botão criar visto na Figura A.10, na qual se pode ver que

existem as opções de quantidade de recurso utilizado no elemento, assim

130

como se pode definir se o mesmo será usado apenas enquanto o elemento

estiver executando ou durante uma duração personalizada.

Figura A.10: Adicionando recursos a um elemento

Recursos cadastrados pertencem ao escopo da ferramenta e não a um

único processo em particular.

Na Figura A.11 que é a tela de gerenciamento de recursos, nela se pode

ver a listagem de todos os recursos existentes no BonitaSoft (e não só os do

processo atual), assim como seus dados. Pode-se ainda adicionar, remover ou

editar um recurso em particular.

Os recursos quando cadastrados tem os seguintes atributos:

Quantidade: A quantidade disponível do recurso;

Quantidade alvo: Uma quantidade de recursos a qual se deseja

alcançar. Deve ser menor ou igual à quantidade. Se deixada

zerada indica que é igual à quantidade de recursos.

Custo unitário9: É a unidade monetária a ser exibida no relatório

(se for em reais deve ser preenchida com R$);

9 Aqui há um erro de tradução na ferramenta. O termo em ingles é Cost Unit ou unidade de custo.

131

Custo por utilização: Um valor a ser adicionado a cada utilização

do recurso.

Custo por tempo: Um custo por unidade de tempo a ser

escolhida.

Figura A.11: Tela de gerenciamento de recursos

Figura A.12: tela de inserção/edição de recursos do BOS

Na tela de inclusão/edição de recursos apresentada na Figura A.12 há

um botão “seguinte >”. Ao escolher esse botão se tem mais algumas

132

propriedades do recurso. Na tela que se apresenta (Figura A.13) é possível se

determinar períodos de tempo em que esse recurso estará disponível.

Figura A.13: Tela de edição de disponibilidade de recursos.

A.1.2.2 Definindo perfil de carregamento

Um perfil de carregamento diz respeito às características da execução

das iterações de uma simulação de um processo. Nessa tela (Figura A.14) se

define um ou mais períodos de injeção (execução das iterações), o número de

instâncias a serem executadas e o tipo de repartição, que pode ser de dois

tipos:

Constant: As iterações serão carregadas em intervalos regulares

ao longo do período de injeção;

Direct: Todas as iterações serão carregadas ao mesmo tempo no

início do período de injeção.

Na tela seguinte (Figura A.15) pode-se indicar os dias da semana e os

horários em que as iterações serão simuladas.

133

Figura A.14: Primeira tela de edição do perfil de carregamento.

Figura A.15: Segunda tela do perfil de carregamento

A.1.2.3 Executando a simulação

Após cadastrar todos os dados da simulação resta executá-la. Para isso

escolhe-se a opção Executar Simulação e em seguida os seus parâmetros

(Figura A.16).

134

Figura A.16: Parâmetros de execução de uma simulação

Após a execução da simulação uma série de gráficos são exibidos em

uma página HTML gerada localmente com a opção de salvar os mesmo em um

arquivo PDF (Figura A.17).

Figura A.17: Exemplo de gráfico de simulação do BOS. Fonte: (BonitaSoft , 2011)

135

Nesse resultado estão os seguintes gráficos para as instâncias:

Load Profile: Total de iterações executadas.

Instances Execution Time: Tempo de execução em horas X

datas;

Time by Instance: tempos de execução mínimos, máximos,

médios calculados entre as iterações.

Instance waiting time: Tempo inativo (de espera) por data;

Waiting Time by Instance: Tempos de espera máximos,

mínimos e médios por instância;

Instances Cumulated Time: Tempo de espera + tempo de

execução de cada instância;

Seguidos a esses vem os mesmos gráficos para cada um dos elementos

e uma série de relatórios para cada recurso usado no processo:

Time Consumption: número/quantidade de recurso consumidos

ou usados por data

Consumption by Instance: Consumo ou uso mínimo, médio e

máximo de recursos calculados sobre todas as iterações.

Total resource consumption: consumo total de recursos.

Time Cost: Custo total dos recursos consumidos ou usados por

data.

Cost by Instance: Custo mínimo, médio e máximo dos recursos

Total Resource Cost: Custo total de recursos.

Time Utilization: Utilização/consumo de recursos por tempo

(percentual comparado com o total disponível).

Total Utilization: Total consumido ou usado de um recurso em

comparação com o disponível.

136

A.2 Introdução À Ferramenta TimeNet

Segundo (Zimmermann & Knoke, 2007) a ferramenta TimeNet foi

desenvolvida no Real-Time Systems and Robotics group of Technische

Universit em Berlim, Alemanha (http://pdv.cs.tu-berlin.de/), motivado pela

necessidade de um software para a avaliação eficiente de redes de Petri

temporizadas com atraso de disparo. Informações sobre a ferramenta podem

ser obtidas na sua página (http://pdv.cs.tu-berlin.de/~timenet/).

Neste trabalho, o TimeNet foi utilizado para análise e avaliação de

desempenho das redes geradas para o estudo de caso.

A ferramenta suporta dois tipos de redes: as EDSPN (Extended

Deterministic Stochastic Petri Nets) e as SCPN (Stochastic Colored Petri Nets),

ambas foram geradas nos testes a partir dos modelos criados em BPMN, no

entanto os testes gerados foram todos para as redes EDSPN pois elas

comportam as redes GSPN, que são a base para os fluxos gerados.

Figura A.18: Visão geral do TimeNet

A TimeNet tem uma interface gráfica e a possibilidade de exportar os

gráficos exibidos nela para o formato svg, os quais foram posteriormente

convertidos para png para a exibição de algumas das figuras presentes neste

137

trabalho. Na Figura A.18 está sendo exibida uma rede de exemplo extraída de

(Zimmermann & Knoke, 2007).

A ferramenta foi totalmente reescrita em Java, é multiplataforma, sendo

executada em Windows e Linux e durante os testes foi observado que a versão

Linux executa parcialmente em Mac. Este fato foi relatado à equipe o que

motivou uma observação no site (Figura A.19).

Figura A.19: Site da ferramenta TimeNet

Na versão da época da execução dos testes (versão 4.0) o formato de

gravação das redes geradas utiliza-se de XML. É para esse formato específico

que o trabalho gera os fluxos oriundos da BPMN.

Conforme já citado a ferramenta trabalha com dois tipos de redes: as

EDSPN e as SCPN. Como o trabalho concentra-se nas GSPN que podem ser

representadas pelas EDSPN, a descrição das funcionalidades será restrita a

esse tipo de rede. Além disso, esta seção não pretende ser um manual da

ferramenta, ficando a sugestão de consulta do manual da TimeNet

(Zimmermann & Knoke, 2007) para quem desejar conhecer mais.

A interface gráfica da ferramenta é composta por menus e botões

genéricos além de elementos específicos das redes geradas. Parte dessas

funcionalidades serão descritas a seguir.

138

A.2.1 O suporte da TimeNet para as redes EDSPN

Segundo (Zimmermann & Knoke, 2007), as redes chamadas de EDSPN

na TimeNet não devem ser tomadas como uma definição matemática das

redes de Petri extendidas determinísiticas e estocásticas, mas como um

modelo contendo a capacidade de representar subclasses de redes como

GSPN, DSPN e EDSPN.

A.2.2 Elementos de desenho das EDSPN

A interface gráfica da TimeNet permite ao usuário várias ações como

salvar arquivos, abrir arquivos e outras ações comuns a outras interfaces.

Para o caso específico das EDSPN existe um conjunto de botões que

correspondem aos elementos desse tipo de rede. Esses botões podem ser

vistos na Figura A.20.

Figura A.20: Botões dos objetos para as redes EDSPN.

Na Tabela A.1 tem-se uma breve descrição da função de cada um dos

botões da Figura A.20. A forma de uso desses botões é simples mas não faz

parte do escopo desse trabalho, para isso pode-se consultar o manual da

interface gráfica da ferramenta.

Cada um dos botões serve para desenhar elementos das EDSPN que

possuem propriedades. Essas propriedades são específicas de cada um dos

elementos.

Um lugar possui as propriedades text e Initialmarking. A propriedade text

é seu nome e o identifica unicamente no diagrama. A propriedade initialMarking

é um inteiro cujo valor padrão é 0 e representa a marcação inicial (quantidade

de tokens) do lugar. Na Figura A.21 há uma montagem com o botão de lugar e

suas propriedades.

139

Tabela A.1: Elementos gráficos das EDSPN na TimeNet


Lugar Desenha um lugar com o nome Pi, sendo i um número inteiro sequencial de lugares. Os nomes de lugares devem ser. A propriedade initialMarking indica a marcação inicial (quantidade de tokens) do lugar selecionado.

Transição Exponencial Representam uma transição exponencial denominada automaticamente por Ti, sendo o i uma numeração sequencial para todas as transições. As demais propriedades são descritas no texto logo a seguir.

Transição Imediata Desenha uma transição imediata Ti. Com todos os valores ajustados para 1.

Transição determinística Desenha uma transição determinística. Essas transições não serão utilizadas no presente trabalho.

Transição Geral Desenha uma transição geral.

Arco Desenha um arco. A única propriedade de um arco é text, que representa o seu peso.

Arco Inibidor Desenha um arco inibidor. A única propriedade de um arco inibidor é text, que representa o seu peso. Esse tipo de arco sempre sai de um lugar para uma transição.

Medida de Performance Res As medidas de performance definem o que será computado durante a análise.

Definição de Constante Def Podem ser usadas para marcação e parâmetros de atraso. Uma vez definida constante a mesma pode ser usada em qualquer lugar ou transição que seu valor seja aceito.

140

Figura A.21: O botão de lugar e suas propriedades.

Para os fluxos gerados e usados neste trabalho apenas as transições do

tipo exponencial e imediata. O mesmo tipo de montagem feito na Figura A.21

está presente na Figura A.22.

A propriedade text está em todas as transições e representa o mesmo

da propriedade text dos lugares. A diferença é que o valor padrão começa com

a letra T e a numeração é sequencial independente do tipo de transição. Não

podem existir dois elementos no mesmo diagrama com o mesmo nome.

Figura A.22: Propriedades das Transições Imediatas

Na Figura A.22 tem-se as propriedades de uma transição imediata.

Text: O nome dado à transição. Deve ser um nome único.

Priority: um número natural que define a precedência de

transições imediatas habilitadas ao mesmo tempo. Números

maiores indicam prioridades maiores.

Weight: Um número real que define a probabilidade de disparo

da transição em relação a transições que estejam em conflito.

enablingFunction: Também conhecida como guarda, é uma

expressão dependente de uma marcação que deve ser avaliada

como verdadeira para que a transição seja habilitada. Um

exemplo de expressão é #P1=1, a qual será avaliada verdadeira

141

se a quantidade de tokens no lugar P1 for igual a 1. Se não

houver nenhum valor isso indica que a transição estará habilitada

para ser disparada.

Figura A.23: Propriedades das Transições Exponenciais

As propriedades da transição exponencial (Figura A.23) são:

Text: O nome dado à transição. Deve ser um nome único.

Delay: Valor padrão 1.0, representa a expectativa do tempo de

atraso de disparo da transição, que é exponencialmente

distribuído. Por questão de consistência da ferramenta os tempos

de transições são definidos por essa propriedade para todas as

transições.

serverType: o valor padrão é single server, sendo aceitos os

valores infinite server ou exclusive server. A semântica dos tipos

de servidores foi explicitada na seção sobre GSPN e será

importante na execução do trabalho.

preemptionPolicy: Indica o comportamento da transição quando

volta a ser habilitada após ter sido desabilitada, ou seja, define a

política de memória adotada pela transição. Os valores possíveis

são PRD (preemptive repeat diferente) ou PRS (preemptive

resume).

DTSPNPriority: Possui significado apenas para algoritmos de

análise que possuem escala de tempo discreta.

As transições determinísticas, possuem um delay fixo, com valor padrão

igual a 1. Também possuem os atributos priority e preemption policy, e ambos

142

apresentam as mesmas restrições impostas às transições exponenciais. As

Transições gerais, apresentam o seu tempo de disparo descrito por uma

função de probabilidade (probability mass function). Estas transições não foram

utilizadas neste trabalho, para conhece-las pode-se ler o manual da ferramenta

TimeNet (Zimmermann & Knoke, 2007), da qual essa seção obteve as

informações aqui apresentadas.

As medidas de performance devem ser usadas para que se insira no

modelo dados do tipo “nome=expressão”, o qual corresponde a um nome de

uma medida e a expressão para obtê-la ou, no caso da expressão já ter sido

avaliada o par pode ser “nome=valor”.

Um exemplo de medida pode ser o número médio de tokens em um

lugar, que dependendo do modelo tem significados distintos.

Para a definição das medidas uma gramática especial é descrita em

(Zimmermann & Knoke, 2007).

No contexto das classes de rede EDSPN uma medida de performance é

uma expressão que pode conter números, marcações e parâmetros de atraso,

operadores algébricos e as seguintes medidas básicas:

P{<condição_lógica>}; – probabilidade da <condição_lógica

ocorrer;

P{<cond_logica1> IF <cond_logica2>}; - probabilidade da

<cond_logica1> ocorrer se a <cond_logica2> ocorrer antes.

E{<func_marc>}; - refere-se ao valor esperado da expressão

<func_marc>;

E{<func_marc> IF <cond_logica>}; - corresponde ao valor

esperado de uma expressão marcação-dependente <func_marc>,

sendo marcada apenas se <cond_logica> for verdadeira.

O último botão “Def”, representa uma constante que pode ser usada em

marcações ou parâmetros de atraso. São mostrada como uma string “nome :=

expressão”. As propriedades desses componentes são:

143

defType: Define o tipo de dados que pode ser “real” ou “int”;

name: o nome da definição;

expression: define o valor da expressão de definição.

A.2.3 Validação de workflow

Com a TimeNet é possível avaliar as redes construídas para ele. Esta

funcionalidade foi utilizada no projeto para a verificação dos fluxos gerados a

partir da BPMN.

Os seguintes métodos estão disponíveis através do menu validate:

Estimate Statespace: Calcula uma estimativa do número de

estados alcançáveis que existem no modelo, baseado na

estrutura do mesmo.

Traps: Calcula o conjunto de traps (armadilhas), ou seja, lugares

que nunca serão desmarcados uma vez que tenham sido

marcados.

Siphons: Calcula o conjunto de siphons (sifões) mínimos, ou

seja, lugares que nunca serão marcados de novo uma vez que

tenham sido desmarcados.

Check Structure: Obtêm os lugares invariantes mínimos do

modelo e o conjunto estendido de conflitos de transições

imediatas, mostrando-os em duas janelas.

Tokengame: Inicia o tokengame, uma simulação interativa do

comportamento do modelo.

Estes testes foram utilizados durante a criação do protótipo para verificar

os fluxos gerados. Através dos resultados de alguns desses testes as

transformações foram validadas e, algumas vezes corrigidas.

144

A.2.4 Avaliação do workflow

A ferramenta permite uma variedade de métodos de avalição de

performance, todos esses métodos estão acessíveis através do menu

evaluation: Os tipos de avaliação possíveis são:

Transient Analisa o comportamento do modelo da marcação

inicial até um determinado momento, podendo ser utilizada para

responder perguntas do tipo: Qual a probabilidade de que, após

um mês de operação o sistema continue funcionando?

Stationary (Steady State): Calcula a média de todas as medidas

de performance e pode ser usada para responder a questões do

tipo: Qual será a largura de banda máxima de um canal de

comunicação?

Para que algumas avaliações sejam feitas é necessária a definição de

medidas de performance. Algumas análises necessitam que se defina opções

para sua execução.

Esta seção não pretende ser um manual da ferramenta TimeNet, mas

apenas mostrar a sua utilidade na execução do trabalho.

A.3 Considerações Finais

Neste anexo foram apresentadas brevemente as ferramentas principais

utilizadas para os testes criados durante a execução do estudo descrito neste

trabalho.

Mais explicações não se fazem necessárias por não serem relevantes

para o entendimento do estudo ora apresentado, quaisquer outras explicações

serão melhor entendidas durante a descrição dos passos utilizados durante a

elaboração dos testes.

145

ANEXO B

Arquivos XML gerados no Estudo de Caso

da Sefaz-PI

Código B.1: Arquivo do estudo de caso exportado para BPMN 2.0

001

002

003

004

005

006

007

008

009

010

011

012

013

014

015

016

017

018

019

020

021

022

023

024

025

026

027

028

029

030

031

032

033

034

035

036

037

038

039

040

041

042

043

044

045

046

047

048


<model:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:bonitaConnector="http://www.bonitasoft.org/studio/connector/defini

tion/6.0" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"

xmlns:di="http://www.omg.org/spec/BPMN/20100524/DI"

xmlns:di_1="http://www.omg.org/spec/DD/20100524/DI"

xmlns:java="http://jcp.org/en/jsr/detail?id=270"

xmlns:model="http://www.omg.org/spec/BPMN/20100524/MODEL"

xsi:schemaLocation="schemaLocation

http://www.omg.org/spec/BPMN/20100524/MODEL schemas/BPMN20.xsd"

exporter="BonitaSoft" exporterVersion="6.2.3"

expressionLanguage="http://groovy.codehaus.org/"

targetNamespace="http://bonitasoft.com/_lWAN4KYOEeOPa_FxNu5jAg">

<model:collaboration id="_lWAN4KYOEeOPa_FxNu5jAg">

<model:participant id="_L0acgapMEeOF6Y75kSJIFA" name="Lançamento de IPVA

- Carro Novo" processRef="_lWAN4aYOEeOPa_FxNu5jAg"/>

<model:participant id="_lWA1b6YOEeOPa_FxNu5jAg" name="Vistoriador">

<model:documentation>Vistoriador do Detran</model:documentation>

</model:participant>

<model:participant id="_lWA1cKYOEeOPa_FxNu5jAg" name="Funcionario

Detran"/>

<model:participant id="_lWA1caYOEeOPa_FxNu5jAg" name="Funcionario

Sefaz"/>

<model:participant id="_mB6YAKYWEeOPa_FxNu5jAg" name="Concessionária"/>

</model:collaboration>

<model:process id="_lWAN4aYOEeOPa_FxNu5jAg" name="Lançamento de IPVA -

Carro Novo">

<model:ioSpecification id="_L0lboKpMEeOF6Y75kSJIFA">

<model:inputSet id="_L0mpwKpMEeOF6Y75kSJIFA"/>

<model:outputSet id="_L0nQ0KpMEeOF6Y75kSJIFA"/>

</model:ioSpecification>

<model:laneSet id="Lan??amento de IPVA - Carro Novo_laneSet">

<model:lane id="_lWAN4qYOEeOPa_FxNu5jAg" name="Sefaz">

<model:flowNodeRef>_lWAN46YOEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_lWAN7aYOEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_lWA08qYOEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_lWA1B6YOEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_0qQJIKYQEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyL98KhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyOaMKhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyPBQKhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyPoUKhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyQPYKhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyQ2cKhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyRdgKhIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DyRdiahIEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_DySEk6hIEeOPa_FxNu5jAg</model:flowNodeRef>

</model:lane>

146

049

050

051

052

053

054

055

056

057

058

059

060

061

062

063

064

065

066

067

068

069

070

071

072

073

074

075

076

077

078

079

080

081

082

083

084

085

086

087

088

089

090

091

092

093

094

095

096

097

098

099

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

<model:lane id="_4iROcKYOEeOPa_FxNu5jAg" name="Serpro">

<model:flowNodeRef>_86GKUKYOEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_o5_AEKYQEeOPa_FxNu5jAg</model:flowNodeRef>

</model:lane>

<model:lane id="_GkP7cKYPEeOPa_FxNu5jAg" name="Conssession??ria">

<model:flowNodeRef>_lWlnQKYPEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_alf_EKYWEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_brn5oKYWEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_jAhDkKYWEeOPa_FxNu5jAg</model:flowNodeRef>

</model:lane>

<model:lane id="_3fP1wKYPEeOPa_FxNu5jAg" name="Detran">

<model:flowNodeRef>_5UN94KYQEeOPa_FxNu5jAg</model:flowNodeRef>

<model:flowNodeRef>_cVlcoKYWEeOPa_FxNu5jAg</model:flowNodeRef>

</model:lane>

<model:lane id="_IeAngKYREeOPa_FxNu5jAg" name="Arrecadador">

<model:flowNodeRef>_QM2igKYREeOPa_FxNu5jAg</model:flowNodeRef>

</model:lane>

</model:laneSet>

<model:scriptTask id="_lWAN46YOEeOPa_FxNu5jAg" name="RealizaPr??-

Cadastro"/>

<model:scriptTask id="_lWAN7aYOEeOPa_FxNu5jAg"

name="AtualizarCadastro"/>

<model:scriptTask id="_lWA08qYOEeOPa_FxNu5jAg" name="Valida????o da NF-

e">

<model:documentation>Nestaetapa o Bancoverificase a nota fiscal ??

deve??culo e se a mesmadevelan??ar IPVA</model:documentation>

</model:scriptTask>

<model:scriptTask id="_lWA1B6YOEeOPa_FxNu5jAg" name="Lan??ar IPVA"/>

<model:parallelGateway id="_0qQJIKYQEeOPa_FxNu5jAg" name="Desvios2"/>

<model:serviceTask id="_DyL98KhIEeOPa_FxNu5jAg"

name="Verificarsitua????o do pagamento">

<model:documentation>A situa????o ?? verificadalevandoemconta o conta-

corrente</model:documentation>

</model:serviceTask>

<model:exclusiveGateway id="_DyOaMKhIEeOPa_FxNu5jAg" name="Qual a

situa????o do pagamento?" default="_DyT5wKhIEeOPa_FxNu5jAg"/>

<model:serviceTask id="_DyPBQKhIEeOPa_FxNu5jAg" name="Alterarpara Status

Parcial ">

<model:documentation>Status dasparcelas = 10

Status geral = 15</model:documentation>


<model:serviceTask id="_DyPoUKhIEeOPa_FxNu5jAg" name="Alterar Status

Total">

<model:documentation>Status dasparcelas = 10

Status geral = 10</model:documentation>


<model:serviceTask id="_DyQPYKhIEeOPa_FxNu5jAg" name="AmortizarConta-

Corrente"/>

<model:endEvent id="_DyQ2cKhIEeOPa_FxNu5jAg" name="Fim2"/>

<model:exclusiveGateway id="_DyRdgKhIEeOPa_FxNu5jAg" name="Desvios2"/>

<model:serviceTask id="_DyRdiahIEeOPa_FxNu5jAg"

name="SincronismoDetran">

<model:documentation>At?? 500 registros a cada 5

minutos</model:documentation>


<model:endEvent id="_DySEk6hIEeOPa_FxNu5jAg" name="Fim1"/>

<model:serviceTask id="_86GKUKYOEeOPa_FxNu5jAg" name="Gera NF-e"/>

<model:parallelGateway id="_o5_AEKYQEeOPa_FxNu5jAg" name="Desvios1"/>

<model:startEvent id="_lWlnQKYPEeOPa_FxNu5jAg" name="In??cio"/>

<model:userTask id="_alf_EKYWEeOPa_FxNu5jAg" name="Vende um ve??culo

novo"/>

<model:userTask id="_brn5oKYWEeOPa_FxNu5jAg" name="Encaminha para

vistoria"/>

<model:userTask id="_jAhDkKYWEeOPa_FxNu5jAg" name="Paga taxas e

impostos"/>

<model:serviceTask id="_5UN94KYQEeOPa_FxNu5jAg" name="Lan??a taxas e

servi??os"/>

147

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

<model:userTask id="_cVlcoKYWEeOPa_FxNu5jAg" name="Realiza a vistoria"/>

<model:serviceTask id="_QM2igKYREeOPa_FxNu5jAg" name="Informa

pagamento"/>

<model:sequenceFlow id="_lWA1SqYOEeOPa_FxNu5jAg" name=""

sourceRef="_lWAN7aYOEeOPa_FxNu5jAg" targetRef="_lWA1B6YOEeOPa_FxNu5jAg">

<model:conditionExpression xsi:type="model:tFormalExpression"

id="_L2C0MKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"

language="http://www.w3.org/1999/XPath"></model:conditionExpression>

</model:sequenceFlow>

<model:sequenceFlow id="_lWA1UKYOEeOPa_FxNu5jAg" name=""

sourceRef="_lWA08qYOEeOPa_FxNu5jAg" targetRef="_lWAN46YOEeOPa_FxNu5jAg">


id="_L2HssKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_qiedUKYPEeOPa_FxNu5jAg" name=""

sourceRef="_lWlnQKYPEeOPa_FxNu5jAg" targetRef="_alf_EKYWEeOPa_FxNu5jAg">


id="_L2HssapMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_XIX_oKYQEeOPa_FxNu5jAg" name=""

sourceRef="_alf_EKYWEeOPa_FxNu5jAg" targetRef="_86GKUKYOEeOPa_FxNu5jAg">


id="_L2HssqpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_iC1iEKYQEeOPa_FxNu5jAg" name=""

sourceRef="_brn5oKYWEeOPa_FxNu5jAg" targetRef="_cVlcoKYWEeOPa_FxNu5jAg">


id="_L2ITwKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_o6GU0KYQEeOPa_FxNu5jAg" name=""

sourceRef="_86GKUKYOEeOPa_FxNu5jAg"

targetRef="_o5_AEKYQEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_pRfhIKYQEeOPa_FxNu5jAg" name=""

sourceRef="_o5_AEKYQEeOPa_FxNu5jAg"

targetRef="_brn5oKYWEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_qF-5IKYQEeOPa_FxNu5jAg" name=""

sourceRef="_o5_AEKYQEeOPa_FxNu5jAg"

targetRef="_lWA08qYOEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_0qW20KYQEeOPa_FxNu5jAg" name=""

sourceRef="_cVlcoKYWEeOPa_FxNu5jAg"

targetRef="_0qQJIKYQEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_1GtboKYQEeOPa_FxNu5jAg" name=""

sourceRef="_lWAN46YOEeOPa_FxNu5jAg"

targetRef="_0qQJIKYQEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_1yuNEKYQEeOPa_FxNu5jAg" name=""

sourceRef="_0qQJIKYQEeOPa_FxNu5jAg"

targetRef="_lWAN7aYOEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_5USPUKYQEeOPa_FxNu5jAg" name=""

sourceRef="_lWA1B6YOEeOPa_FxNu5jAg"

targetRef="_5UN94KYQEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_BJaYgKYREeOPa_FxNu5jAg" name=""

sourceRef="_5UN94KYQEeOPa_FxNu5jAg"

targetRef="_jAhDkKYWEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_QM_FYKYREeOPa_FxNu5jAg" name=""

sourceRef="_jAhDkKYWEeOPa_FxNu5jAg" targetRef="_QM2igKYREeOPa_FxNu5jAg">


id="_L2KI8KpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_DySrpKhIEeOPa_FxNu5jAg" name=""

sourceRef="_DyL98KhIEeOPa_FxNu5jAg"

targetRef="_DyOaMKhIEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_DyT5wKhIEeOPa_FxNu5jAg" name="Quitado

148

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

parcialmente" sourceRef="_DyOaMKhIEeOPa_FxNu5jAg"

targetRef="_DyPBQKhIEeOPa_FxNu5jAg">


id="_L2LXEKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_DyUg0KhIEeOPa_FxNu5jAg" name="N??o quitado"

sourceRef="_DyOaMKhIEeOPa_FxNu5jAg" targetRef="_DyQPYKhIEeOPa_FxNu5jAg">


id="_L2LXEapMEeOF6Y75kSJIFA"

evaluatesToTypeRef="java:java.lang.Boolean">valor_pago <

valor_parcela</model:conditionExpression>


<model:sequenceFlow id="_DyVH4KhIEeOPa_FxNu5jAg" name="Quitado"

sourceRef="_DyOaMKhIEeOPa_FxNu5jAg" targetRef="_DyPoUKhIEeOPa_FxNu5jAg">

<model:conditionExpression xsi:type="model:tFormalExpression" id="_L2L-

IKpMEeOF6Y75kSJIFA"

evaluatesToTypeRef="java:java.lang.Boolean">valor_pago >=

valor_devido</model:conditionExpression>


<model:sequenceFlow id="_DyVu8KhIEeOPa_FxNu5jAg" name=""

sourceRef="_DyPBQKhIEeOPa_FxNu5jAg" targetRef="_DyRdgKhIEeOPa_FxNu5jAg">

<model:conditionExpression xsi:type="model:tFormalExpression" id="_L2L-

IapMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



<model:sequenceFlow id="_DyWWAKhIEeOPa_FxNu5jAg" name=""

sourceRef="_DyPoUKhIEeOPa_FxNu5jAg"

targetRef="_DyRdgKhIEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_DyW9EKhIEeOPa_FxNu5jAg" name=""

sourceRef="_DyQPYKhIEeOPa_FxNu5jAg"

targetRef="_DyQ2cKhIEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_DyXkIKhIEeOPa_FxNu5jAg" name=""

sourceRef="_DyRdgKhIEeOPa_FxNu5jAg"

targetRef="_DyRdiahIEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_DyYLMKhIEeOPa_FxNu5jAg" name=""

sourceRef="_DyRdiahIEeOPa_FxNu5jAg"

targetRef="_DySEk6hIEeOPa_FxNu5jAg"/>

<model:sequenceFlow id="_ipXtgKhIEeOPa_FxNu5jAg" name=""

sourceRef="_QM2igKYREeOPa_FxNu5jAg" targetRef="_DyL98KhIEeOPa_FxNu5jAg">


id="_L2NMQKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"



</model:process>

<di:BPMNDiagram name="Lan??amento de IPVA - Carro Novo">

<di:BPMNPlane id="plane__lWAN4KYOEeOPa_FxNu5jAg"

bpmnElement="_lWAN4KYOEeOPa_FxNu5jAg">

<di:BPMNShape id="_lWCDfKYOEeOPa_FxNu5jAg"

bpmnElement="_lWAN4aYOEeOPa_FxNu5jAg" isHorizontal="true">

<dc:Bounds height="398.0" width="1247.0" x="15.0" y="15.0"/>

<di:BPMNLabel id="_L0hKMapMEeOF6Y75kSJIFA"

labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>

</di:BPMNShape>

<di:BPMNShape id="_lWCDf6YOEeOPa_FxNu5jAg"

bpmnElement="_lWAN4qYOEeOPa_FxNu5jAg" isHorizontal="true">


<di:BPMNLabel id="_L0riQKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_lWCDgqYOEeOPa_FxNu5jAg"

bpmnElement="_lWAN46YOEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L09PEKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_lWCDhaYOEeOPa_FxNu5jAg"

149

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

bpmnElement="_lWAN7aYOEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L092IKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_lWCDjKYOEeOPa_FxNu5jAg"

bpmnElement="_lWA08qYOEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L092IapMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_lWCDm6YOEeOPa_FxNu5jAg"

bpmnElement="_lWA1B6YOEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L092IqpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_0qRXQKYQEeOPa_FxNu5jAg"

bpmnElement="_0qQJIKYQEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L1CuoKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyNzIKhIEeOPa_FxNu5jAg"

bpmnElement="_DyL98KhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L1y8kKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyOaNahIEeOPa_FxNu5jAg"

bpmnElement="_DyOaMKhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L10xwKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyPBSqhIEeOPa_FxNu5jAg"

bpmnElement="_DyPBQKhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L12m8KpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyPoWqhIEeOPa_FxNu5jAg"

bpmnElement="_DyPoUKhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L12m8apMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyQPaqhIEeOPa_FxNu5jAg"

bpmnElement="_DyQPYKhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L12m8qpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyQ2dahIEeOPa_FxNu5jAg"

bpmnElement="_DyQ2cKhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L15DMKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DyRdhahIEeOPa_FxNu5jAg"

bpmnElement="_DyRdgKhIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L15DMapMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DySEkKhIEeOPa_FxNu5jAg"

bpmnElement="_DyRdiahIEeOPa_FxNu5jAg">

150

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383


<di:BPMNLabel id="_L15DMqpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_DySroKhIEeOPa_FxNu5jAg"

bpmnElement="_DySEk6hIEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L15DM6pMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_4iSckKYOEeOPa_FxNu5jAg"

bpmnElement="_4iROcKYOEeOPa_FxNu5jAg" isHorizontal="true">


<di:BPMNLabel id="_L15DNKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_86GKWqYOEeOPa_FxNu5jAg"

bpmnElement="_86GKUKYOEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L15qQKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_o6A1QKYQEeOPa_FxNu5jAg"

bpmnElement="_o5_AEKYQEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L15qQapMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_GkRJkKYPEeOPa_FxNu5jAg"

bpmnElement="_GkP7cKYPEeOPa_FxNu5jAg" isHorizontal="true">


<di:BPMNLabel id="_L15qQqpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_lWnccKYPEeOPa_FxNu5jAg"

bpmnElement="_lWlnQKYPEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L164YKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_alhNMKYWEeOPa_FxNu5jAg"

bpmnElement="_alf_EKYWEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L17fcKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_broguaYWEeOPa_FxNu5jAg"

bpmnElement="_brn5oKYWEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L18GgKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_jAhqqKYWEeOPa_FxNu5jAg"

bpmnElement="_jAhDkKYWEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L18GgapMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_3fRD4KYPEeOPa_FxNu5jAg"

bpmnElement="_3fP1wKYPEeOPa_FxNu5jAg" isHorizontal="true">


<di:BPMNLabel id="_L18GgqpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_5UPMAKYQEeOPa_FxNu5jAg"

bpmnElement="_5UN94KYQEeOPa_FxNu5jAg">


151

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

<di:BPMNLabel id="_L18Gg6pMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_cVmDtaYWEeOPa_FxNu5jAg"

bpmnElement="_cVlcoKYWEeOPa_FxNu5jAg">


<di:BPMNLabel id="_L18GhKpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_IeB1oKYREeOPa_FxNu5jAg"

bpmnElement="_IeAngKYREeOPa_FxNu5jAg" isHorizontal="true">


<di:BPMNLabel id="_L18GhapMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNShape id="_QM4-wKYREeOPa_FxNu5jAg"

bpmnElement="_QM2igKYREeOPa_FxNu5jAg">


<di:BPMNLabel id="_L18GhqpMEeOF6Y75kSJIFA"


</di:BPMNShape>

<di:BPMNEdge id="_lWCD8KYOEeOPa_FxNu5jAg"

bpmnElement="_lWA1SqYOEeOPa_FxNu5jAg">

<di_1:waypoint x="962.0" y="674.0"/>

<di_1:waypoint x="1016.0" y="674.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_lWCD_KYOEeOPa_FxNu5jAg"

bpmnElement="_lWA1UKYOEeOPa_FxNu5jAg">

<di_1:waypoint x="566.0" y="678.0"/>

<di_1:waypoint x="615.0" y="678.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_qifrcKYPEeOPa_FxNu5jAg"

bpmnElement="_qiedUKYPEeOPa_FxNu5jAg">

<di_1:waypoint x="149.0" y="202.0"/>

<di_1:waypoint x="198.0" y="202.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_XIZ00KYQEeOPa_FxNu5jAg"

bpmnElement="_XIX_oKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="254.0" y="236.0"/>

<di_1:waypoint x="254.0" y="302.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_iC2JIKYQEeOPa_FxNu5jAg"

bpmnElement="_iC1iEKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="659.0" y="205.0"/>

<di_1:waypoint x="786.0" y="205.0"/>

<di_1:waypoint x="786.0" y="413.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_o6Hi8KYQEeOPa_FxNu5jAg"

bpmnElement="_o6GU0KYQEeOPa_FxNu5jAg">

<di_1:waypoint x="308.0" y="328.0"/>

<di_1:waypoint x="384.0" y="328.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_pRgvQKYQEeOPa_FxNu5jAg"

bpmnElement="_pRfhIKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="403.0" y="309.0"/>

<di_1:waypoint x="403.0" y="201.0"/>

<di_1:waypoint x="539.0" y="201.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_qGAHQKYQEeOPa_FxNu5jAg" bpmnElement="_qF-

5IKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="403.0" y="352.0"/>

<di_1:waypoint x="403.0" y="672.0"/>

<di_1:waypoint x="466.0" y="672.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_0qYE8KYQEeOPa_FxNu5jAg"

bpmnElement="_0qW20KYQEeOPa_FxNu5jAg">

<di_1:waypoint x="805.0" y="463.0"/>

152

451

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

<di_1:waypoint x="805.0" y="652.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_1GupwKYQEeOPa_FxNu5jAg"

bpmnElement="_1GtboKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="735.0" y="671.0"/>

<di_1:waypoint x="785.0" y="671.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_1yvbMKYQEeOPa_FxNu5jAg"

bpmnElement="_1yuNEKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="825.0" y="675.0"/>

<di_1:waypoint x="862.0" y="675.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_5US2YKYQEeOPa_FxNu5jAg"

bpmnElement="_5USPUKYQEeOPa_FxNu5jAg">

<di_1:waypoint x="1061.0" y="645.0"/>

<di_1:waypoint x="1061.0" y="468.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_BJbmoKYREeOPa_FxNu5jAg"

bpmnElement="_BJaYgKYREeOPa_FxNu5jAg">

<di_1:waypoint x="1055.0" y="408.0"/>

<di_1:waypoint x="1055.0" y="246.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_QNATgKYREeOPa_FxNu5jAg"

bpmnElement="_QM_FYKYREeOPa_FxNu5jAg">

<di_1:waypoint x="1055.0" y="186.0"/>

<di_1:waypoint x="1055.0" y="125.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyTSsKhIEeOPa_FxNu5jAg"

bpmnElement="_DySrpKhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1284.0" y="668.0"/>

<di_1:waypoint x="1397.0" y="668.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyT5xKhIEeOPa_FxNu5jAg"

bpmnElement="_DyT5wKhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1416.0" y="649.0"/>

<di_1:waypoint x="1416.0" y="568.0"/>

<di_1:waypoint x="1528.0" y="568.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyUg2KhIEeOPa_FxNu5jAg"

bpmnElement="_DyUg0KhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1416.0" y="692.0"/>

<di_1:waypoint x="1416.0" y="769.0"/>

<di_1:waypoint x="1528.0" y="769.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyVH6KhIEeOPa_FxNu5jAg"

bpmnElement="_DyVH4KhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1434.0" y="667.0"/>

<di_1:waypoint x="1528.0" y="667.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyVu86hIEeOPa_FxNu5jAg"

bpmnElement="_DyVu8KhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1648.0" y="558.0"/>

<di_1:waypoint x="1777.0" y="558.0"/>

<di_1:waypoint x="1777.0" y="645.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyWWA6hIEeOPa_FxNu5jAg"

bpmnElement="_DyWWAKhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1648.0" y="666.0"/>

<di_1:waypoint x="1756.0" y="666.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyW9E6hIEeOPa_FxNu5jAg"

bpmnElement="_DyW9EKhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1648.0" y="770.0"/>

<di_1:waypoint x="1728.0" y="770.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyXkI6hIEeOPa_FxNu5jAg"

bpmnElement="_DyXkIKhIEeOPa_FxNu5jAg">

153

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

<di_1:waypoint x="1797.0" y="668.0"/>

<di_1:waypoint x="1870.0" y="668.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_DyYLM6hIEeOPa_FxNu5jAg"

bpmnElement="_DyYLMKhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1989.0" y="669.0"/>

<di_1:waypoint x="2060.0" y="669.0"/>

</di:BPMNEdge>

<di:BPMNEdge id="_ipY7oKhIEeOPa_FxNu5jAg"

bpmnElement="_ipXtgKhIEeOPa_FxNu5jAg">

<di_1:waypoint x="1113.0" y="116.0"/>

<di_1:waypoint x="1222.0" y="116.0"/>

<di_1:waypoint x="1222.0" y="638.0"/>

</di:BPMNEdge>

</di:BPMNPlane>

<di:BPMNLabelStyle id="_L0hKMKpMEeOF6Y75kSJIFA">

<dc:Font isBold="false" isItalic="false" isStrikeThrough="false"

isUnderline="false" name="Segoe UI" size="9.0"/>

</di:BPMNLabelStyle>

</di:BPMNDiagram>

</model:definitions>

154

Código B.2: Estudo de caso depois de transformado para a notação XML nativa da ferramenta TimeNet

001

002

003

004

005

006

007

008

009

010

011

012

013

014

015

016

017

018

019

020

021

022

023

024

025

026

027

028

029

030

031

032

033

034

035

036

037

038

039

040

041

042

043

044

045

046

047

048

049

050

051

052

053

054

055

056

057

058

059

060

061

062


<net id="Lançamento de IPVA - Carro Novo" netclass="eDSPN"

xmlns="http://pdv.cs.tu-berlin.de/TimeNET/schema/eDSPN"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://pdv.cs.tu-berlin.de/TimeNET/schema/eDSPN

etc/schemas/eDSPN.xsd">

<place id="_lWAN4qYOEeOPa_FxNu5jAg" initialMarking="1" type="node">

<graphics orientation="0" x="1180" y="1200"/>

<label id="_lWAN4qYOEeOPa_FxNu5jAg.0" text="Sefaz" type="text">

<graphics orientation="0" x="-20" y="30"/>

</label>

</place>

<place id="_4iROcKYOEeOPa_FxNu5jAg" initialMarking="1" type="node">


<label id="_4iROcKYOEeOPa_FxNu5jAg.0" text="Serpro" type="text">

<graphics orientation="0" x="-10" y="-40"/>

</label>

</place>

<place id="_GkP7cKYPEeOPa_FxNu5jAg" initialMarking="1" type="node">


<label id="_GkP7cKYPEeOPa_FxNu5jAg.0" text="Conssessionária"

type="text">


</label>

</place>

<place id="_3fP1wKYPEeOPa_FxNu5jAg" initialMarking="1" type="node">


<label id="_3fP1wKYPEeOPa_FxNu5jAg.0" text="Detran" type="text">


</label>

</place>

<place id="_IeAngKYREeOPa_FxNu5jAg" initialMarking="1" type="node">


<label id="_IeAngKYREeOPa_FxNu5jAg.0" text="Arrecadador" type="text">


</label>

</place>

<place id="_lWAN7aYOEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_lWAN7aYOEeOPa_FxNu5jAg.0.0" text="W2" type="text">


</label>

</place>

<place id="S2" initialMarking="0" type="node">


<label id="S2.0.0" text="S2" type="text">


</label>

</place>

<place id="_lWA1B6YOEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_lWA1B6YOEeOPa_FxNu5jAg.0.0" text="W4" type="text">


</label>

</place>





</label>

</place>

<place id="_lWA08qYOEeOPa_FxNu5jAg" initialMarking="0" type="node">

155

063

064

065

066

067

068

069

070

071

072

073

074

075

076

077

078

079

080

081

082

083

084

085

086

087

088

089

090

091

092

093

094

095

096

097

098

099

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129


<label id="_lWA08qYOEeOPa_FxNu5jAg.0.0" text="W3" type="text">


</label>

</place>





</label>

</place>

<place id="_lWAN46YOEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_lWAN46YOEeOPa_FxNu5jAg.0.0" text="W1" type="text">


</label>

</place>





</label>

</place>

<place id="_alf_EKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_alf_EKYWEeOPa_FxNu5jAg.0.0" text="W11" type="text">


</label>

</place>





</label>

</place>

<place id="_86GKUKYOEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_86GKUKYOEeOPa_FxNu5jAg.0.0" text="W10" type="text">


</label>

</place>





</label>

</place>

<place id="_brn5oKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_brn5oKYWEeOPa_FxNu5jAg.0.0" text="W12" type="text">


</label>

</place>





</label>

</place>

<place id="_cVlcoKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_cVlcoKYWEeOPa_FxNu5jAg.0.0" text="W15" type="text">


</label>

</place>



156

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196



</label>

</place>

<place id="_o5_AEKYQEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_o5_AEKYQEeOPa_FxNu5jAg.0.0" text="PAnd-2" type="text">


</label>

</place>

<place id="Z1-1" initialMarking="0" type="node">


<label id="Z1-1.0.0" text="Z1-1" type="text">


</label>

</place>

<place id="Z1-2" initialMarking="0" type="node">


<label id="Z1-2.0.0" text="Z1-2" type="text">


</label>

</place>

<place id="_5UN94KYQEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_5UN94KYQEeOPa_FxNu5jAg.0.0" text="W14" type="text">


</label>

</place>





</label>

</place>

<place id="_jAhDkKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_jAhDkKYWEeOPa_FxNu5jAg.0.0" text="W13" type="text">


</label>

</place>





</label>

</place>

<place id="_QM2igKYREeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_QM2igKYREeOPa_FxNu5jAg.0.0" text="W16" type="text">


</label>

</place>





</label>

</place>

<place id="_DyL98KhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyL98KhIEeOPa_FxNu5jAg.0.0" text="W5" type="text">


</label>

</place>




157

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263


</label>

</place>

<place id="_DyOaMKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyOaMKhIEeOPa_FxNu5jAg.0.0"

text="Qual_a_situação_do_pagamento?" type="text">


</label>

</place>

<place id="_DyPBQKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyPBQKhIEeOPa_FxNu5jAg.0.0" text="W6" type="text">


</label>

</place>





</label>

</place>

<place id="_DyQPYKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyQPYKhIEeOPa_FxNu5jAg.0.0" text="W8" type="text">


</label>

</place>





</label>

</place>

<place id="_DyPoUKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyPoUKhIEeOPa_FxNu5jAg.0.0" text="W7" type="text">


</label>

</place>





</label>

</place>

<place id="_DyRdgKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyRdgKhIEeOPa_FxNu5jAg.0.0" text="Desvios2" type="text">


</label>

</place>

<place id="_DyQ2cKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyQ2cKhIEeOPa_FxNu5jAg.0.0" text="Pd1" type="text">


</label>

</place>

<place id="_DyRdiahIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DyRdiahIEeOPa_FxNu5jAg.0.0" text="W9" type="text">


</label>

</place>




158

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330


</label>

</place>

<place id="_DySEk6hIEeOPa_FxNu5jAg" initialMarking="0" type="node">


<label id="_DySEk6hIEeOPa_FxNu5jAg.0.0" text="Pd2" type="text">


</label>

</place>

<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-2"

preemptionPolicy="PRD" serverType="InfiniteServer" type="node">


<label id="Tacticity-2.0.0" text="Atualizar_Cadastro" type="text">


</label>

</exponentialTransition>




<label id="Tacticity-4.0.0" text="Lançar_IPVA" type="text">


</label>





<label id="Tacticity-3.0.0" text="Validação_da_NF-e" type="text">


</label>





<label id="Tacticity-1.0.0" text="Realiza_Pré-Cadastro" type="text">


</label>


<exponentialTransition DTSPNpriority="1" delay="1"

id="_lWlnQKYPEeOPa_FxNu5jAg" preemptionPolicy="PRD"

serverType="ExclusiveServer" type="node">


<label id="_lWlnQKYPEeOPa_FxNu5jAg.0.0" text="Início" type="text">


</label>





<label id="Tacticity-11.0.0" text="Vende_um_veículo_novo" type="text">


</label>





<label id="Tacticity-10.0.0" text="Gera_NF-e" type="text">


</label>





<label id="Tacticity-12.0.0" text="Encaminha_para_vistoria" type="text">


</label>



159

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397



<label id="Tacticity-15.0.0" text="Realiza_a_vistoria" type="text">


</label>





<label id="Tacticity-14.0.0" text="Lança_taxas_e_serviços" type="text">


</label>





<label id="Tacticity-13.0.0" text="Paga_taxas_e_impostos" type="text">


</label>





<label id="Tacticity-16.0.0" text="Informa_pagamento" type="text">


</label>





<label id="Tacticity-5.0.0" text="Verificar_situação_do_pagamento"

type="text">


</label>





<label id="Tacticity-6.0.0" text="Alterar_para_Status_Parcial_"

type="text">


</label>





<label id="Tacticity-8.0.0" text="Amortizar_Conta-Corrente" type="text">


</label>





<label id="Tacticity-7.0.0" text="Alterar_Status_Total" type="text">


</label>





<label id="Tacticity-9.0.0" text="Sincronismo_Detran" type="text">


</label>


<immediateTransition enablingFunction="" id="q2" priority="1"

type="node" weight="1">


160

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

<label id="q2.0.0" text="q2" type="text">


</label>

</immediateTransition>






</label>







</label>







</label>







</label>







</label>







</label>







</label>


<immediateTransition enablingFunction="" id="qsplit2" priority="1"



<label id="qsplit2.0.0" text="Desvios1" type="text">


</label>


<immediateTransition enablingFunction="" id="_0qQJIKYQEeOPa_FxNu5jAg"

priority="1" type="node" weight="1">


<label id="_0qQJIKYQEeOPa_FxNu5jAg.0.0" text="Desvios2" type="text">


</label>


161

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531






</label>







</label>







</label>







</label>


<immediateTransition enablingFunction=""

id="_DyOaMKhIEeOPa_FxNu5jAgqx1" priority="1" type="node" weight="1">


<label id="_DyOaMKhIEeOPa_FxNu5jAgqx1.0.0"

text="Quitado_parcialmente-qx1" type="text">


</label>







</label>





<label id="_DyOaMKhIEeOPa_FxNu5jAgqx2.0.0" text="Não_quitado-qx2"

type="text">


</label>







</label>





<label id="_DyOaMKhIEeOPa_FxNu5jAgqx3.0.0" text="quitado-qx3"

type="text">


</label>



162

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598





</label>


<immediateTransition enablingFunction="" id="qd1" priority="1"



<label id="qd1.0.0" text="Fim2" type="text">


</label>



id="_DyRdgKhIEeOPa_FxNu5jAgqx4" priority="1" type="node" weight="1">


<label id="_DyRdgKhIEeOPa_FxNu5jAgqx4.0.0" text="qx4" type="text">


</label>







</label>


<immediateTransition enablingFunction="" id="qd2" priority="1"



<label id="qd2.0.0" text="Fim1" type="text">


</label>


<arc fromNode="Tacticity-2" id="_lWA1SqYOEeOPa_FxNu5jAg"

toNode="_lWA1B6YOEeOPa_FxNu5jAg" type="connector">

<inscription id="_lWA1SqYOEeOPa_FxNu5jAg.0" text="1"

type="inscriptionText">


</inscription>

</arc>

<arc fromNode="_lWAN7aYOEeOPa_FxNu5jAg" id="wq2" toNode="q2"

type="connector">

<inscription id="wq2.0" text="1" type="inscriptionText">


</inscription>

</arc>

<arc fromNode="q2" id="qs2" toNode="S2" type="connector">

<inscription id="qs2.0" text="1" type="inscriptionText">


</inscription>

</arc>

<arc fromNode="S2" id="st2" toNode="Tacticity-2" type="connector">

<inscription id="st2.0" text="1" type="inscriptionText">


</inscription>

</arc>

<arc fromNode="Tacticity-2" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"

type="connector">

<inscription id=".0" text="1" type="inscriptionText">


</inscription>

</arc>

<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q2"

type="connector">



163

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

</inscription>

</arc>

<arc fromNode="_lWA1B6YOEeOPa_FxNu5jAg" id="wq4" toNode="q4"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

</arc>

<arc fromNode="Tacticity-3" id="_lWA1UKYOEeOPa_FxNu5jAg"

toNode="_lWAN46YOEeOPa_FxNu5jAg" type="connector">

<inscription id="_lWA1UKYOEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="_lWA08qYOEeOPa_FxNu5jAg" id="wq3" toNode="q3"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

</arc>


type="connector">



</inscription>

164

666

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

801

802

803

804

805

806

807

808

809

810

811

812

813

814

815

816

817

818

819

820

821

822

823

824

825

826

827

828

829

830

831

832

</arc>

<arc fromNode="_lWAN46YOEeOPa_FxNu5jAg" id="wq1" toNode="q1"

type="connector">


<graphics orientation="0" x="0" y="-5"/>

</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

</arc>


type="connector">



</inscription>

</arc>

<arc fromNode="_lWlnQKYPEeOPa_FxNu5jAg" id="_qiedUKYPEeOPa_FxNu5jAg"

toNode="_alf_EKYWEeOPa_FxNu5jAg" type="connector">

<inscription id="_qiedUKYPEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="_alf_EKYWEeOPa_FxNu5jAg" id="wq11" toNode="q11"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>

<arc fromNode="Tacticity-11" id="" toNode="_GkP7cKYPEeOPa_FxNu5jAg"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="_GkP7cKYPEeOPa_FxNu5jAg" id="" toNode="q11"

type="connector">



</inscription>

<handle id=".1">

165

833

834

835

836

837

838

839

840

841

842

843

844

845

846

847

848

849

850

851

852

853

854

855

856

857

858

859

860

861

862

863

864

865

866

867

868

869

870

871

872

873

874

875

876

877

878

879

880

881

882

883

884

885

886

887

888

889

890

891

892

893

894

895

896

897

898

899


</handle>

</arc>

<arc fromNode="Tacticity-11" id="_XIX_oKYQEeOPa_FxNu5jAg"

toNode="_86GKUKYOEeOPa_FxNu5jAg" type="connector">

<inscription id="_XIX_oKYQEeOPa_FxNu5jAg.0" text="1"



</inscription>

<handle id="_XIX_oKYQEeOPa_FxNu5jAg.2">


</handle>

<handle id="_XIX_oKYQEeOPa_FxNu5jAg.1">


</handle>

</arc>

<arc fromNode="_86GKUKYOEeOPa_FxNu5jAg" id="wq10" toNode="q10"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>

<arc fromNode="Tacticity-10" id="" toNode="_4iROcKYOEeOPa_FxNu5jAg"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="_4iROcKYOEeOPa_FxNu5jAg" id="" toNode="q10"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="Tacticity-12" id="_iC1iEKYQEeOPa_FxNu5jAg"

toNode="_cVlcoKYWEeOPa_FxNu5jAg" type="connector">

<inscription id="_iC1iEKYQEeOPa_FxNu5jAg.0" text="1"



</inscription>

<handle id="_iC1iEKYQEeOPa_FxNu5jAg.1">


</handle>

</arc>

<arc fromNode="_brn5oKYWEeOPa_FxNu5jAg" id="wq12" toNode="q12"

type="connector">



</inscription>

</arc>


166

900

901

902

903

904

905

906

907

908

909

910

911

912

913

914

915

916

917

918

919

920

921

922

923

924

925

926

927

928

929

930

931

932

933

934

935

936

937

938

939

940

941

942

943

944

945

946

947

948

949

950

951

952

953

954

955

956

957

958

959

960

961

962

963

964

965

966



</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

</arc>

<arc fromNode="_cVlcoKYWEeOPa_FxNu5jAg" id="wq15" toNode="q15"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>

<arc fromNode="Tacticity-15" id="" toNode="_3fP1wKYPEeOPa_FxNu5jAg"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="_3fP1wKYPEeOPa_FxNu5jAg" id="" toNode="q15"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="Tacticity-10" id="_o6GU0KYQEeOPa_FxNu5jAg"

toNode="_o5_AEKYQEeOPa_FxNu5jAg" type="connector">

<inscription id="_o6GU0KYQEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="_o5_AEKYQEeOPa_FxNu5jAg" id="" toNode="qsplit2"

type="connector">

167

967

968

969

970

971

972

973

974

975

976

977

978

979

980

981

982

983

984

985

986

987

988

989

990

991

992

993

994

995

996

997

998

999

1000

1001

1002

1003

1004

1005

1006

1007

1008

1009

1010

1011

1012

1013

1014

1015

1016

1017

1018

1019

1020

1021

1022

1023

1024

1025

1026

1027

1028

1029

1030

1031

1032

1033



</inscription>

</arc>

<arc fromNode="qsplit2" id="_pRfhIKYQEeOPa_FxNu5jAg"

toNode="_brn5oKYWEeOPa_FxNu5jAg" type="connector">

<inscription id="_pRfhIKYQEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="qsplit2" id="_qF-5IKYQEeOPa_FxNu5jAg"

toNode="_lWA08qYOEeOPa_FxNu5jAg" type="connector">

<inscription id="_qF-5IKYQEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="Tacticity-15" id="" toNode="Z1-1" type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="Z1-1" id="" toNode="_0qQJIKYQEeOPa_FxNu5jAg"

type="connector">



</inscription>

</arc>

<arc fromNode="Tacticity-1" id="" toNode="Z1-2" type="connector">



</inscription>

</arc>

<arc fromNode="Z1-2" id="" toNode="_0qQJIKYQEeOPa_FxNu5jAg"

type="connector">



</inscription>

</arc>

<arc fromNode="_0qQJIKYQEeOPa_FxNu5jAg" id=""

toNode="_lWAN7aYOEeOPa_FxNu5jAg" type="connector">



</inscription>

</arc>

<arc fromNode="Tacticity-4" id="_5USPUKYQEeOPa_FxNu5jAg"

toNode="_5UN94KYQEeOPa_FxNu5jAg" type="connector">

<inscription id="_5USPUKYQEeOPa_FxNu5jAg.0" text="1"



</inscription>

<handle id="_5USPUKYQEeOPa_FxNu5jAg.1">


</handle>

</arc>

<arc fromNode="_5UN94KYQEeOPa_FxNu5jAg" id="wq14" toNode="q14"

type="connector">



</inscription>

</arc>



168

1034

1035

1036

1037

1038

1039

1040

1041

1042

1043

1044

1045

1046

1047

1048

1049

1050

1051

1052

1053

1054

1055

1056

1057

1058

1059

1060

1061

1062

1063

1064

1065

1066

1067

1068

1069

1070

1071

1072

1073

1074

1075

1076

1077

1078

1079

1080

1081

1082

1083

1084

1085

1086

1087

1088

1089

1090

1091

1092

1093

1094

1095

1096

1097

1098

1099

1100


</inscription>

</arc>



<graphics orientation="0" x="0" y="-5"/>

</inscription>

</arc>

<arc fromNode="Tacticity-14" id="" toNode="_3fP1wKYPEeOPa_FxNu5jAg"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="_3fP1wKYPEeOPa_FxNu5jAg" id="" toNode="q14"

type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="Tacticity-14" id="_BJaYgKYREeOPa_FxNu5jAg"

toNode="_jAhDkKYWEeOPa_FxNu5jAg" type="connector">

<inscription id="_BJaYgKYREeOPa_FxNu5jAg.0" text="1"



</inscription>

<handle id="_BJaYgKYREeOPa_FxNu5jAg.1">


</handle>

</arc>

<arc fromNode="_jAhDkKYWEeOPa_FxNu5jAg" id="wq13" toNode="q13"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

<handle id=".1">

169

1101

1102

1103

1104

1105

1106

1107

1108

1109

1110

1111

1112

1113

1114

1115

1116

1117

1118

1119

1120

1121

1122

1123

1124

1125

1126

1127

1128

1129

1130

1131

1132

1133

1134

1135

1136

1137

1138

1139

1140

1141

1142

1143

1144

1145

1146

1147

1148

1149

1150

1151

1152

1153

1154

1155

1156

1157

1158

1159

1160

1161

1162

1163

1164

1165

1166

1167


</handle>

</arc>

<arc fromNode="Tacticity-13" id="_QM_FYKYREeOPa_FxNu5jAg"

toNode="_QM2igKYREeOPa_FxNu5jAg" type="connector">

<inscription id="_QM_FYKYREeOPa_FxNu5jAg.0" text="1"



</inscription>

<handle id="_QM_FYKYREeOPa_FxNu5jAg.1">


</handle>

</arc>

<arc fromNode="_QM2igKYREeOPa_FxNu5jAg" id="wq16" toNode="q16"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>

<arc fromNode="Tacticity-16" id="" toNode="_IeAngKYREeOPa_FxNu5jAg"

type="connector">



</inscription>

</arc>

<arc fromNode="_IeAngKYREeOPa_FxNu5jAg" id="" toNode="q16"

type="connector">



</inscription>

</arc>

<arc fromNode="Tacticity-5" id="_DySrpKhIEeOPa_FxNu5jAg"

toNode="_DyOaMKhIEeOPa_FxNu5jAg" type="connector">

<inscription id="_DySrpKhIEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="_DyL98KhIEeOPa_FxNu5jAg" id="wq5" toNode="q5"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">


170

1168

1169

1170

1171

1172

1173

1174

1175

1176

1177

1178

1179

1180

1181

1182

1183

1184

1185

1186

1187

1188

1189

1190

1191

1192

1193

1194

1195

1196

1197

1198

1199

1200

1201

1202

1203

1204

1205

1206

1207

1208

1209

1210

1211

1212

1213

1214

1215

1216

1217

1218

1219

1220

1221

1222

1223

1224

1225

1226

1227

1228

1229

1230

1231

1232

1233

1234


</inscription>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>

<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAg"

id="_DyOaMKhIEeOPa_FxNu5jAgrqx1" toNode="_DyOaMKhIEeOPa_FxNu5jAgqx1"

type="connector">

<inscription id="_DyOaMKhIEeOPa_FxNu5jAgrqx1.0" text="1"



</inscription>

<handle id="_DyOaMKhIEeOPa_FxNu5jAgrqx1.1">


</handle>

</arc>

<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAgqx1"

id="_DyOaMKhIEeOPa_FxNu5jAgoutqx1" toNode="_DyPBQKhIEeOPa_FxNu5jAg"

type="connector">

<inscription id="_DyOaMKhIEeOPa_FxNu5jAgoutqx1.0" text="1"



</inscription>

</arc>

<arc fromNode="_DyPBQKhIEeOPa_FxNu5jAg" id="wq6" toNode="q6"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".2">


</handle>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

171

1235

1236

1237

1238

1239

1240

1241

1242

1243

1244

1245

1246

1247

1248

1249

1250

1251

1252

1253

1254

1255

1256

1257

1258

1259

1260

1261

1262

1263

1264

1265

1266

1267

1268

1269

1270

1271

1272

1273

1274

1275

1276

1277

1278

1279

1280

1281

1282

1283

1284

1285

1286

1287

1288

1289

1290

1291

1292

1293

1294

1295

1296

1297

1298

1299

1300

1301

<handle id=".1">


</handle>

<handle id=".2">


</handle>

<handle id=".3">


</handle>

</arc>



type="connector">




</inscription>

<handle id="_DyOaMKhIEeOPa_FxNu5jAgrqx2.1">


</handle>

</arc>


id="_DyOaMKhIEeOPa_FxNu5jAgoutqx2" toNode="_DyQPYKhIEeOPa_FxNu5jAg"

type="connector">




</inscription>

</arc>

<arc fromNode="_DyQPYKhIEeOPa_FxNu5jAg" id="wq8" toNode="q8"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>



type="connector">


172

1302

1303

1304

1305

1306

1307

1308

1309

1310

1311

1312

1313

1314

1315

1316

1317

1318

1319

1320

1321

1322

1323

1324

1325

1326

1327

1328

1329

1330

1331

1332

1333

1334

1335

1336

1337

1338

1339

1340

1341

1342

1343

1344

1345

1346

1347

1348

1349

1350

1351

1352

1353

1354

1355

1356

1357

1358

1359

1360

1361

1362

1363

1364

1365

1366

1367

1368



</inscription>

</arc>


id="_DyOaMKhIEeOPa_FxNu5jAgoutqx3" toNode="_DyPoUKhIEeOPa_FxNu5jAg"

type="connector">




</inscription>

</arc>

<arc fromNode="_DyPoUKhIEeOPa_FxNu5jAg" id="wq7" toNode="q7"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".3">


</handle>

<handle id=".2">


</handle>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

<handle id=".2">


</handle>

<handle id=".3">


</handle>

</arc>

<arc fromNode="Tacticity-6" id="_DyVu8KhIEeOPa_FxNu5jAg"

toNode="_DyRdgKhIEeOPa_FxNu5jAg" type="connector">

<inscription id="_DyVu8KhIEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="Tacticity-7" id="_DyWWAKhIEeOPa_FxNu5jAg"

toNode="_DyRdgKhIEeOPa_FxNu5jAg" type="connector">

173

1369

1370

1371

1372

1373

1374

1375

1376

1377

1378

1379

1380

1381

1382

1383

1384

1385

1386

1387

1388

1389

1390

1391

1392

1393

1394

1395

1396

1397

1398

1399

1400

1401

1402

1403

1404

1405

1406

1407

1408

1409

1410

1411

1412

1413

1414

1415

1416

1417

1418

1419

1420

1421

1422

1423

1424

1425

1426

1427

1428

1429

1430

1431

1432

1433

1434

1435

<inscription id="_DyWWAKhIEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="Tacticity-8" id="_DyW9EKhIEeOPa_FxNu5jAg"

toNode="_DyQ2cKhIEeOPa_FxNu5jAg" type="connector">

<inscription id="_DyW9EKhIEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="_DyQ2cKhIEeOPa_FxNu5jAg" id="" toNode="qd1"

type="connector">



</inscription>

</arc>

<arc fromNode="_DyRdgKhIEeOPa_FxNu5jAg"

id="_DyRdgKhIEeOPa_FxNu5jAgrqx4" toNode="_DyRdgKhIEeOPa_FxNu5jAgqx4"

type="connector">

<inscription id="_DyRdgKhIEeOPa_FxNu5jAgrqx4.0" text="1"



</inscription>

</arc>

<arc fromNode="_DyRdgKhIEeOPa_FxNu5jAgqx4"

id="_DyRdgKhIEeOPa_FxNu5jAgoutqx4" toNode="_DyRdiahIEeOPa_FxNu5jAg"

type="connector">

<inscription id="_DyRdgKhIEeOPa_FxNu5jAgoutqx4.0" text="1"



</inscription>

</arc>

<arc fromNode="_DyRdiahIEeOPa_FxNu5jAg" id="wq9" toNode="q9"

type="connector">



</inscription>

</arc>




</inscription>

</arc>




</inscription>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

</arc>


type="connector">



</inscription>

<handle id=".1">


</handle>

174

1436

1437

1438

1439

1440

1441

1442

1443

1444

1445

1446

1447

1448

1449

1450

1451

1452

1453

1454

1455

1456

1457

1458

1459

1460

1461

1462

1463

</arc>

<arc fromNode="Tacticity-9" id="_DyYLMKhIEeOPa_FxNu5jAg"

toNode="_DySEk6hIEeOPa_FxNu5jAg" type="connector">

<inscription id="_DyYLMKhIEeOPa_FxNu5jAg.0" text="1"



</inscription>

</arc>

<arc fromNode="_DySEk6hIEeOPa_FxNu5jAg" id="" toNode="qd2"

type="connector">



</inscription>

</arc>

<arc fromNode="Tacticity-16" id="_ipXtgKhIEeOPa_FxNu5jAg"

toNode="_DyL98KhIEeOPa_FxNu5jAg" type="connector">

<inscription id="_ipXtgKhIEeOPa_FxNu5jAg.0" text="1"



</inscription>

<handle id="_ipXtgKhIEeOPa_FxNu5jAg.2">


</handle>

<handle id="_ipXtgKhIEeOPa_FxNu5jAg.1">


</handle>

</arc>

</net>

175

ANEXO C

Código Fonte das Classes de

Transformação do Protótipo

Desvio Exclusivo package br.ufpe.cin.trans.bpmn;

import java.util.ArrayList;

import br.ufpe.cin.bpmn.TExclusiveGateway;

import br.ufpe.cin.timenet.edspn.ArcType;

import br.ufpe.cin.timenet.edspn.GraphicsType;

import br.ufpe.cin.timenet.edspn.ImmediateTransitionType;

import br.ufpe.cin.timenet.edspn.InscriptionType;

import br.ufpe.cin.timenet.edspn.PlaceType;

public class DesvioExclusivo extends Elemento {

static int indice=0;

int i;

public DesvioExclusivo(TExclusiveGateway tExclusiveGateway) {

super(tExclusiveGateway,null);

}

public void geraDesvioExclusivo(Fluxo f, ArrayList<ArcType> arco,

ArrayList<PlaceType> p,

ArrayList<ImmediateTransitionType> t){

int posicao;

if (!this.isMapeado()) {

// Pxor

p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),

0), this.getId(), this.getRotulo()));

this.setMapeado(true);

}

// caso se esteja mapeando um arco de saída

if (f.getOrigem().getId()==this.getId()){

// Apagndo o arco original.

posicao=-1;

for(int i=0; i < arco.size(); i++){

if (arco.get(i).getId().equals(f.getId())){

posicao = i; }

}

if (posicao >= 0)

arco.remove(posicao);

this.i=++indice;

// qxi

if (f.getRotulo().isEmpty())

t.add(new ImmediateTransitionType(new GraphicsType(this.getX()+50,

this.getY(), 0), this.getId()+"qx"+this.i,

"qx"+this.i,f.getPrioridade()));

else


this.getY(), 0), this.getId()+"qx"+this.i, f.getRotulo()+

"-qx"+this.i,f.getPrioridade()));

// Pxor -> qxi

arco.add(new ArcType(this.getId(), this.getId()+"qx"+this.i,

this.getId()+"rqx"+this.i, new InscriptionType()));

// qxi -> next

arco.add(new ArcType( this.getId()+"qx"+this.i,

f.getDestino().getId(), this.getId()+"outqx"+this.i, new

InscriptionType()));}}}

176

Desvio Inclusivo package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TInclusiveGateway;






public class DesvioInclusivo extends Elemento {


private int i=++indice;

private int iEntrada=0;

private int iSaida=0;

private int Zi=0;

private int xi=0;

public DesvioInclusivo(TInclusiveGateway tInclusiveGateway) {

super(tInclusiveGateway,null);

this.setSaida( "qx"+this.i);

}

public void geraDesvioouJuncao(ArrayList<Fluxo> f, Fluxo fl, ArrayList<ArcType>

arco, ArrayList<PlaceType> p,


if (this.iSaida==0) {

for (Fluxo l : f){

if (l.getOrigem().getId().equals(this.getId()))

this.iSaida++;

else

if (l.getDestino().getId().equals(this.getId()))

this.iEntrada++;

}

}

if (this.iEntrada > 1 && this.iEntrada > this.iSaida){

this.geraJuncaoInclusiva(fl, arco, p, t);

}else

this.geraDesvioInclusivo(fl, arco, p, t);

}

public void geraDesvioInclusivo(Fluxo f, ArrayList<ArcType> arco,



arco.get(arco.size() - 1).setFromNode(f.getOrigem().getSaida());


// Por


0), this.getId(), "Por-"+this.i));

// qx


this.getY(), 0), "qx"+this.i, this.getRotulo()));

// arco Por -> qx

arco.add(new ArcType(this.getId(), "qx"+this.i, "", new

InscriptionType()));


}

if (f.getOrigem().getId().equals(this.getId())){

this.xi++;

//Definindo a saída

this.setSaida("qSx"+this.i+"-"+this.xi);


// arco Por -> qx

arco.add(new ArcType("qx"+this.i, "Px"+this.i+"-"+this.xi, "",

new InscriptionType()));

// Pxi


0), "Px"+this.i+"-"+this.xi, "Px"+this.i+"-"+this.xi));

// qSxi

177

t.add(new ImmediateTransitionType(new

GraphicsType(this.getX()+50, this.getY(), 0),

"qSx"+this.i+"-"+this.xi, "qSx"+this.i+"-"+this.xi));

// arco Pxi -> qSxi

arco.add(new ArcType("Px"+this.i+"-"+this.xi, "qSx"+this.i+"-

"+this.xi, "", new InscriptionType()));

// qNxi


GraphicsType(this.getX()+50, this.getY(), 0),

"qNx"+this.i+"-"+this.xi, "qNx"+this.i+"-"+this.xi));

// arco Pxi -> qNxi

arco.add(new ArcType("Px"+this.i+"-"+this.xi, "qNx"+this.i+"-

"+this.xi, "", new InscriptionType()));

//arco qNxi -> Zi+1 -- martelinho

arco.add(new ArcType("qNx"+this.i+"-"+this.xi, "Z"+(this.i+1)+"-

"+(this.xi), "", new InscriptionType()));

}

}

public void geraJuncaoInclusiva(Fluxo f, ArrayList<ArcType> arco,





// qz


GraphicsType(this.getX()+50, this.getY(),

0), this.getId(), this.getRotulo()));

// arco qz -> fora (arco de saída)


arco.remove(arco.size()-1);

arco.add(new ArcType(this.getId(),

f.getDestino().getId(), "", new



}

}

if (f.getDestino().getId().equals(this.getId())){


arco.remove(arco.size()-1);

this.Zi++;

// Zi

p.add(new PlaceType(new GraphicsType(this.getX(),

this.getY(), 0), "Z"+(this.i)+"-"+(this.Zi),

"Z"+(this.i)+"-"+(this.Zi)));

// entrada -> Zi

arco.add(new ArcType(f.getOrigem().getSaida(),

"Z"+(this.i)+"-"+(this.Zi), "", new


// Zi -> qz

arco.add(new ArcType("Z"+(this.i)+"-"+(this.Zi),

this.getId(), "", new InscriptionType()));

}

}

}

178

Desvio Paralelo package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TParallelGateway;






public class DesvioParalelo extends Elemento {



private int iEntrada=0;

private int iSaida=0;

private int Zi=0;

public DesvioParalelo(TParallelGateway tParallelGateway) {

super(tParallelGateway,null);

this.setSaida( "qsplit"+this.i);

}

public void geraDesvioouJuncao(ArrayList<Fluxo> f, Fluxo fl, ArrayList<ArcType>

arco,



if (this.iSaida==0) {

for (Fluxo l : f){

if (l.getOrigem().getId().equals(this.getId()))

this.iSaida++;

else if (l.getDestino().getId().equals(this.getId()))

this.iEntrada++;

}

}

if (this.iEntrada > 1 && this.iEntrada > this.iSaida){

this.geraJuncaoParalela(fl, arco, p, t);

}else

this.geraDesvioParalelo(fl, arco, p, t);

}

public void geraDesvioParalelo(Fluxo f, ArrayList<ArcType> arco,





// Pd


0), this.getId(), "PAnd-"+this.i));

// qd


GraphicsType(this.getX()+50, this.getY(), 0), "qsplit"+this.i, this.getRotulo()));

// arco Pd -> qd

arco.add(new ArcType(this.getId(), "qsplit"+this.i, "", new



}

}

public void geraJuncaoParalela(Fluxo f, ArrayList<ArcType> arco,



int posicao;



// qz


GraphicsType(this.getX()+50, this.getY(), 0), this.getId(), this.getRotulo()));

179

// arco qz -> fora (arco de saída)


posicao=-1;



posicao = i;

}

}

if (posicao >= 0)


// arco.remove(arco.size()-1);

arco.add(new ArcType(this.getId(),

f.getDestino().getId(), "", new InscriptionType()));


}

}

if (f.getDestino().getId().equals(this.getId())){

// Apagando o arco original.

posicao=-1;



posicao = i;

}

}

if (posicao >= 0)


this.Zi++;

// Zi

p.add(new PlaceType(new GraphicsType(this.getX(),

this.getY(), 0), "Z"+(this.i)+"-"+(this.Zi), "Z"+(this.i)+"-"+(this.Zi)));

// entrada -> Zi

arco.add(new ArcType(f.getOrigem().getSaida(),

"Z"+(this.i)+"-"+(this.Zi), "", new InscriptionType()));

// Zi -> qz

arco.add(new ArcType("Z"+(this.i)+"-"+(this.Zi),

this.getId(), "", new InscriptionType()));

}

}

}

180

Elemento package br.ufpe.cin.trans.bpmn;

import br.ufpe.cin.bpmn.TFlowElement;

public abstract class Elemento {

private int x;

private int y;

private int w;

private int h;

private String id;

private String rotulo;

private boolean mapeado=false;

private String delay="1";

private String prioridade="1";

private String saida;

private String recursoID;

private String capacidade="0"; //k

public Elemento(TFlowElement flowElement, String recursoID) {

super();

this.id = flowElement.getId();

this.rotulo = flowElement.getName();

this.recursoID = recursoID;

if (flowElement.getDocumentation().size()>0){

String d =

flowElement.getDocumentation().get(0).getContent().get(0).toString();

if (d.indexOf("d=") > 0)

this.setDelay(d.substring(d.indexOf("d=")+2,

d.indexOf("d>")));

if (d.indexOf("k=") > 0)

this.setCapacidade(d.substring(d.indexOf("k=")+2,

d.indexOf("k>")));

if (d.indexOf("p=") > 0)

this.setPrioridade(d.substring(d.indexOf("p=")+2,

d.indexOf("p>")));

}

this.saida = id;}

181

Evento Final package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TEndEvent;






public class EventoFinal extends Elemento {


int i=++indice;

public EventoFinal(TEndEvent flowElement) {

super(flowElement,null);

// TODO Auto-generated constructor stub

}

public void geraFim(ArrayList<ArcType> arco,

ArrayList<PlaceType> p, ArrayList<ImmediateTransitionType> t){


// Pd


0), this.getId(), "Pd"+this.i));

// qd


GraphicsType(this.getX()+50, this.getY(), 0), "qd"+this.i, this.getRotulo()));

// arco Pd -> qd

arco.add(new ArcType(this.getId(), "qd"+this.i, "", new



}

}

public void geraTransicaoImediata(ArrayList<ImmediateTransitionType> e){

e.add(new ImmediateTransitionType(new

GraphicsType(this.getX()+20, this.getY()+10, 0), this.getId()+"Fim",

this.getRotulo()));


}

public void geraLugar(ArrayList<PlaceType> e){

e.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),

0), this.getId(), "PD"));


}

}

182

Evento Inicial package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TStartEvent;

import br.ufpe.cin.timenet.edspn.ExponentialTransitionType;



import br.ufpe.cin.timenet.edspn.ServerTypeType;

/**

*

* @author Jesse James Ma

*

*/

public class EventoInicial extends Elemento {

public EventoInicial(TStartEvent flowElement) {


}

/**

*

* @param e: Um arraylist para transições iniciais

*/

public void geraInicio(ArrayList<ExponentialTransitionType> e){


this.geraTransicaoExponencial(e);


}

}

public void geraTransicaoImediata(ArrayList<ImmediateTransitionType> e){


e.add(new ImmediateTransitionType(new GraphicsType(this.getX(),

this.getY(), 0), this.getId(), this.getRotulo()));

}

}

/**

*

* @param e: um arraylist de transições exponenciais

*/

public void geraTransicaoExponencial(ArrayList<ExponentialTransitionType> e){


e.add(new ExponentialTransitionType(new GraphicsType(this.getX(),

this.getY(), 0), this.getId(),

this.getRotulo(),this.getDelay(),"1",ServerTypeType.EXCLUSIVE_SERVER));

}

}

}

183

Evento Intermediário de Envio package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TIntermediateThrowEvent;






public class EventoIntermediarioEnvio extends Elemento {


int i=++indice;

public EventoIntermediarioEnvio(TIntermediateThrowEvent flowElement) {


this.setSaida("qi"+this.i);

}

public void geraEnvio(ArrayList<ArcType> arco,



// Pd


0), this.getId(), "Pi"+this.i));

// qd


GraphicsType(this.getX()+50, this.getY(), 0), "qi"+this.i, this.getRotulo()));

// arco Pd -> qd

arco.add(new ArcType(this.getId(), "qi"+this.i, "", new



}

}

}

184

Evento Intermediário de Recepção package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TIntermediateThrowEvent;






public class EventoIntermediarioRecepcao extends Elemento {


int i=++indice;

public EventoIntermediarioEnvio(TIntermediateThrowEvent flowElement) {


this.setSaida("qi"+this.i);}

public void geraEnvio(ArrayList<ArcType> arco,



// Pd


0), this.getId(), "Pi"+this.i));

// qd


GraphicsType(this.getX()+50, this.getY(), 0), "qi"+this.i, this.getRotulo()));

// arco Pd -> qd

arco.add(new ArcType(this.getId(), "qi"+this.i, "", new


this.setMapeado(true);}}}

185

Fluxo package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TFlowElement;

import br.ufpe.cin.bpmn.TSequenceFlow;







public class Fluxo extends Elemento {

private Elemento origem;

private Elemento destino;

public Fluxo(TSequenceFlow flowElement, ArrayList<Elemento> elemento) {


TFlowElement origem = (TFlowElement) flowElement.getSourceRef();

TFlowElement destino = (TFlowElement) flowElement.getTargetRef();

for (Elemento b : elemento) {

if (origem.getId().equals(b.getId())) {

this.origem = b;

}

if (destino.getId().equals(b.getId())) {

this.destino = b;

}

}

}

public void geraArco(ArrayList<Fluxo> f, ArrayList<ArcType> arco,

ArrayList<PlaceType> p, ArrayList<ExponentialTransitionType> x,

ArrayList<ImmediateTransitionType> t) {

arco.add(new ArcType(this.getOrigem().getId(), this.getDestino()

.getId(), this.getId(), new InscriptionType()));


if (this.getOrigem() instanceof EventoInicial) {

EventoInicial e = (EventoInicial) this.getOrigem();

e.geraInicio(x);

} else

if (this.getOrigem() instanceof Tarefa) {

Tarefa o = (Tarefa) this.getOrigem();

o.geraTarefa(this,arco,p,t,x);

} else

if (this.getOrigem() instanceof DesvioParalelo) {

DesvioParalelo e = (DesvioParalelo) this.getOrigem();

e.geraDesvioouJuncao(f,this,arco, p, t);

} else

if (this.getOrigem() instanceof DesvioExclusivo) {

DesvioExclusivo e = (DesvioExclusivo) this.getOrigem();

e.geraDesvioExclusivo(this,arco, p, t);

} else

if (this.getOrigem() instanceof DesvioInclusivo) {

DesvioInclusivo e = (DesvioInclusivo) this.getOrigem();


} else

if (this.getOrigem() instanceof EventoIntermediarioEnvio) {

EventoIntermediarioEnvio e = (EventoIntermediarioEnvio)

this.getOrigem();

e.geraEnvio(arco,p,t);

}

186

if (this.getDestino() instanceof Tarefa) {

Tarefa o = (Tarefa) this.getDestino();

o.geraTarefa(this, arco,p,t,x);

}else if (this.getDestino() instanceof EventoFinal) {

EventoFinal o = (EventoFinal) this.getDestino();

o.geraFim(arco,p,t);

} else if (this.getDestino() instanceof DesvioParalelo) {

DesvioParalelo e = (DesvioParalelo) this.getDestino();


} else if (this.getDestino() instanceof DesvioExclusivo) {

DesvioExclusivo e = (DesvioExclusivo) this.getDestino();

e.geraDesvioExclusivo(this,arco, p, t);

} else if (this.getDestino() instanceof DesvioInclusivo) {

DesvioInclusivo e = (DesvioInclusivo) this.getDestino();


} else if (this.getDestino() instanceof EventoIntermediarioEnvio) {

EventoIntermediarioEnvio e = (EventoIntermediarioEnvio)

this.getDestino();

e.geraEnvio(arco,p,t);

}

}

public void geraFim(ArrayList<ArcType> arco,

ArrayList<PlaceType> p, ArrayList<ImmediateTransitionType> t) {

arco.add(new ArcType(this.getOrigem().getId(), this.getDestino()

.getId(), this.getId(), new InscriptionType()));

EventoFinal e = (EventoFinal) this.getDestino();

e.geraFim(arco, p, t);


}

public void geraDesvioExclusivo(ArrayList<ArcType> arco, ArrayList<PlaceType> p,

ArrayList<ImmediateTransitionType> t) {

}

@Override

public String toString() {

return "Fluxo [origem=" + origem + ", destino=" + destino + "]";}

public Elemento getOrigem() {return origem;}

public void setOrigem(Elemento origem) {this.origem = origem;}

public Elemento getDestino() {return destino;}

public void setDestino(Elemento destino) {this.destino = destino;}

}

187

Raia package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TLane;



public class Raia{

private int x;

private int y;

private int w;

private int h;

private String id;

private String rotulo;

private boolean mapeado=false;

private String capacidade="1"; //k

private String saida;



public Raia(TLane lane) {

super();

this.id = lane.getId();

this.rotulo = lane.getName();

if (lane.getDocumentation().size()>0){

String d =

lane.getDocumentation().get(0).getContent().get(0).toString();

if (d.indexOf("k=") > 0)

this.setCapacidade(d.substring(d.indexOf("k=")+2,

d.indexOf("k>")));

}

}

public void geraRecurso(ArrayList<PlaceType> p) {


// Wi

p.add(new PlaceType(new GraphicsType(this.getX()+500,

this.getY()+(250*this.i), 0), this.getId(),

this.getRotulo(), capacidade));

}


}

public int getX() {return x; }

public void setX(int x) {this.x = x; }

public int getY() { return y;}

public void setY(int y) {this.y = y;}

public int getW() {return w;}

public void setW(int w) {this.w = w;}

public int getH() {return h;}

public void setH(int h) {this.h = h;}

public String getId() {return id;}

public void setId(String id) {this.id = id;}

public String getRotulo() {return rotulo.replace(" ","_");}

public void setRotulo(String rotulo) {this.rotulo = rotulo;}

public boolean isMapeado() { return mapeado;}

public void setMapeado(boolean mapeado) {this.mapeado = mapeado;}

public String getSaida() {return saida;}

public void setSaida(String saida) { this.saida = saida;}

public String getCapacidade() {return capacidade;}

public void setCapacidade(String capacidade) {this.capacidade = capacidade;}

}

188

Tarefa package br.ufpe.cin.trans.bpmn;


import br.ufpe.cin.bpmn.TTask;







public class Tarefa extends Elemento {


int i=++indice;

public Tarefa(TTask flowElement,String recursoID) {

super(flowElement,recursoID);

this.setSaida("Tacticity-"+this.i);

}

public void geraTarefa(Fluxo f, ArrayList<ArcType> arco,


ArrayList<ImmediateTransitionType> t,

ArrayList<ExponentialTransitionType> x) {

if (f.getOrigem().getId()==this.getId())



int px = this.getX();

// Wi

p.add(new PlaceType(new GraphicsType(px, this.getY(), 0),

this.getId(), "W"+this.i));

// qi

t.add(new ImmediateTransitionType(new GraphicsType(px+=50,

this.getY(), 0), "q"+this.i, "q"+this.i));

// Si

p.add(new PlaceType(new GraphicsType(px+=50, this.getY(), 0),

"S"+this.i, "S"+this.i));

// Tactiviti

x.add(new ExponentialTransitionType(new GraphicsType(px+=50,

this.getY(), 0), "Tacticity-"+this.i, this.getRotulo(),this.getDelay(),"1"));

// arco Wi -> qi

arco.add(new ArcType(this.getId(), "q"+this.i, "wq"+this.i, new


// arco qi -> Si

arco.add(new ArcType("q"+this.i, "S"+this.i, "qs"+this.i, new


// arco qi -> Tactivity-i

arco.add(new ArcType( "S"+this.i, "Tacticity-"+this.i,

"st"+this.i, new InscriptionType()));

if (this.getRecursoID() != null){

//arco de TActivity-i para o Rk

arco.add(new ArcType("Tacticity-"+this.i,

this.getRecursoID(), "", new InscriptionType()));

//arco do Rk para o qi

arco.add(new ArcType(this.getRecursoID(),"q"+this.i, "",

new InscriptionType()));

}

}


} }


this.getY(), 0), this.getId()+"qx"+this.i, f.getRotulo()+

"-qx"+this.i,f.getPrioridade()));

// Pxor -> qxi

arco.add(new ArcType(this.getId(), this.getId()+"qx"+this.i,

this.getId()+"rqx"+this.i, new InscriptionType()));

// qxi -> next

arco.add(new ArcType( this.getId()+"qx"+this.i,

f.getDestino().getId(), this.getId()+"outqx"+this.i, new


}}}

189

Referências

Aalst, W. V., & Hee, K. V. (2002). Workflow Management: Models, methods and Systems. Massachussets: MIT Press.

Aalst, W. V., & Stahl, C. (2011). Modeling Business Processess: A Petri net oriented approach. Massachussets: MIT Press.

André, T. M. (2009). Compilador BPEL-GSPN Para Avaliação de Desempenho de Workflow. Poli.

Ballem, M. (2011). XML - Trabalhando com JAXB. Acesso em 13 de Jul de 2013, disponível em MBAllem - Trabalhnado com Java: http://www.mballem.com/post/xml--trabalhando-com-jaxb

BonitaSoft . (01 de 05 de 2011). BonitaSoft. Acesso em 01 de 01 de 2014, disponível em BonitaSoft.org: www.bonitasoft.org

BPM Offensive. (2013). BPMN Poster. Fonte: BPM Offensive: http://www.bpmb.de/index.php/BPMNPoster

Campos, A. L. (2013). Modelagem de Processos com BPMN. São Paulo: Brasport.

Cardoso, J., & Valette, R. (1997). Redes de Petri. Florianópolis.

Gonçalves, J. E. (Jan/MAr de 2000). As Empresas São Grandes Coleções de Processos. Revista de Administração de Empresas, pp. 6-19.

Horstmann, C. S., & Cornell, G. (2012). Core Java, Volume I - Fundamentals, 9th Edition. New Jersey: Prentice Hall.

iProcess. (01 de 01 de 2011). Blog da iProcess. Acesso em 30 de 07 de 2013, disponível em iprocess: http://blog.iprocess.com.br

Java Arquiteture for XML Biding (JAXB). (01 de Mar de 2009). Acesso em 14 de jun de 2013, disponível em Oracle.com: http://www.oracle.com/technetwork/articles/javase/index-140168.html

JAXB user Guide. (2010). Acesso em 18 de jun de 2013, disponível em JAXB.java.Net: https://jaxb.java.net/guide/

Jeston, J., & Nelis, J. (2008). Business Process Management. Burlington: Elsevier.

Marchal, B. (2000). XML by Example. Indianapolis: Que.

190

Marshan, M. A., Balbo, G., Conte, G., Donatelli, S., & Franceschinis, G. (1998). Modeling With Generalized Stochastic Petri Nets. ACM SIGMETRICS Performance Evaluation Review - Special issue on Stochastic Petri Nets.

McLaughlin, B. d., & Edelson, J. (2007). Java and XML, 3r Edition. Sebastopol: O'Reilly.

Murata, T. (1989). Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE, 541-577.

Oliveira, C. A. (2008). Uma Abordagem para Melhoria de Workflow Baseada em Redes de Petri Estocásticas Generalizadas. Recife: Universidade federal de Pernambuco.

OMG. (01 de 03 de 2011). Documents Associated With BPMN Version 2.0. Acesso em 01 de 07 de 2013, disponível em omg.org: http://www.omg.org/spec/BPMN/2.0/

OMG. (09 de 2013). Business Process Model and Notation. Fonte: OMG.org: http://www.omg.org/

Ouyang, C., Dumas, M., Hofstede, A. H., & Aalst, W. M. (2006). From BPMN Process Models to BPEL Web Services. ICWS 2006 International Conference of Web Services (pp. 285-292). Chicago: IEEE.

Panagacos, T. (2012). The Ultimate Guide to Business Process Management . Harvard: Harvard Business Review.

Pnml.org. (2009). PNML.Org. Acesso em 13 de 08 de 2013, disponível em http://www.pnml.org/: http://www.pnml.org/

Raedits, I., Petkovic, M., Usenko, Y. S., Werf, J. M., & Jan Friso Groote, L. S. (2007). Transformation of BPMN models for Behaviour Analysis. Proc. MSVVEIS.

Ramadan, M., Elmongui, H. G., & Hassan, R. (2011). BPMN Formalisation using Coloured Petri Nets. Proceedings of the 2nd GSTF Annual International Conference on Software Engineering & Applications.

Ray, E. T. (2001). Learning XML. Sebastopol: O'Reilly.

Recker, J., & Mendling, J. (2006). On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages. The 18th International Conference on Advanced Information Systems Engineering (pp. 521-532). namur University Press.

Reis, G. d. (2008). Modelagem de Processos de Negócios com BPMN - Curso Completo. São Paulo: PotalBPM Ltda.

Reisig, W. (2013). Understanding Petri Nets. Berlin: Springer.

Remco M. Dijkman, M. D. (2008). Semantics and analysis of business process models in BPMN. Information and Software Technology, 1281-1294.

191

Resfnes Data. (01 de jan de 1999). Xml Tutorial. Acesso em 13 de jun de 2013, disponível em W3Schools: http://www.w3schools.com/xml/default.asp

Sarang, P., Juric, M., & Mathew, B. (2006). Business Process Execution Language for Web Services BPEL and BPEL4WS 2nd Edition. Olton Birmingham: Packt Publishing.

Silver, B. (2012). BPMN Method & Style Second Edition. Aptos, CA, USA: Cody-Cassidy Press.

Takemura, T. (2008). Formal Semantics and Verification of BPMN Transaction and Compensation. IEEE Asia-Pacific Services Computing Conference (pp. 284-290). Tokio: IEEE.

Vasconcelos, L. M. (2012). Petri-SW: Uma Metodologia Baseada em Redes de Petri Para a Avaliação do desempenho de Processo de Software. Recife, PE, Brasil.

W3C. (01 de 01 de 2010). W3C XML Pattern. Acesso em 18 de jul de 2013, disponível em w3c.org: http://www.w3.org/standards/xml/core

White, S. A. (03 de 2005). Using BPMN to Modela a BPEL Process. Business, pp. 1-18.

Zimmermann, A., & Knoke, M. (2007). User Manual for TimeNet 4.0. Berlin, Alemanha. Acesso em 07 de 07 de 2013, disponível em Technische Univerität Ilmenau: http://www.tu-ilmenau.de/sse/timenet/information-for-users/documentation/

Pós-Graduação em Ciência da Computação...Figura 3.12: Exemplo do uso do gateway inclusivo....

Documents

Transcript of Pós-Graduação em Ciência da Computação...Figura 3.12: Exemplo do uso do gateway inclusivo....