View
3
Download
0
Category
Preview:
Citation preview
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
posgraduacao@cin.ufpe.br
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
Figura 4.2: Diagrama simplificado das classes geradas no processo de binding
para as redes SCPN. ....................................................................................... 66
Figura 4.3: Listagem das classes das redes a) EDSPN e b) SCPN ................. 67
Figura 4.4: Diagrama simplificado das classes geradas no processo de binding
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>
<preco>29,99</preco>
</livro>
<livro categoria="WEB">
<titulolingua = inglês ">
Learning XML
</titulo>
<autor>Erik T. Ray</autor>
<ano>2003</ano>
<preco>39,95</preco>
</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
Figura Nome - Função
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
Figura Nome - Função
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.
Figura Nome - Função
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.
Figura Nome - Função
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
Figura Nome - Função
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)
Figura Nome - Função
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.
Figura Nome - Função
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
Figura Nome - Função
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
<?xml version="1.0" encoding="UTF-8"?>
<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>
<model:serviceTask id="_DyPoUKhIEeOPa_FxNu5jAg" name="Alterar Status
Total">
<model:documentation>Status dasparcelas = 10
Status geral = 10</model:documentation>
</model:serviceTask>
<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:serviceTask>
<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">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2HssKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<model:sequenceFlow id="_qiedUKYPEeOPa_FxNu5jAg" name=""
sourceRef="_lWlnQKYPEeOPa_FxNu5jAg" targetRef="_alf_EKYWEeOPa_FxNu5jAg">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2HssapMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<model:sequenceFlow id="_XIX_oKYQEeOPa_FxNu5jAg" name=""
sourceRef="_alf_EKYWEeOPa_FxNu5jAg" targetRef="_86GKUKYOEeOPa_FxNu5jAg">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2HssqpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<model:sequenceFlow id="_iC1iEKYQEeOPa_FxNu5jAg" name=""
sourceRef="_brn5oKYWEeOPa_FxNu5jAg" targetRef="_cVlcoKYWEeOPa_FxNu5jAg">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2ITwKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<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">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2KI8KpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<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">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2LXEKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<model:sequenceFlow id="_DyUg0KhIEeOPa_FxNu5jAg" name="N??o quitado"
sourceRef="_DyOaMKhIEeOPa_FxNu5jAg" targetRef="_DyQPYKhIEeOPa_FxNu5jAg">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2LXEapMEeOF6Y75kSJIFA"
evaluatesToTypeRef="java:java.lang.Boolean">valor_pago <
valor_parcela</model:conditionExpression>
</model:sequenceFlow>
<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>
<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"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
<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">
<model:conditionExpression xsi:type="model:tFormalExpression"
id="_L2NMQKpMEeOF6Y75kSJIFA" evaluatesToTypeRef="java:java.lang.Boolean"
language="http://www.w3.org/1999/XPath"></model:conditionExpression>
</model:sequenceFlow>
</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">
<dc:Bounds height="162.0" width="1238.0" x="24.0" y="251.0"/>
<di:BPMNLabel id="_L0riQKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_lWCDgqYOEeOPa_FxNu5jAg"
bpmnElement="_lWAN46YOEeOPa_FxNu5jAg">
<dc:Bounds height="31.0" width="61.0" x="307.0" y="324.0"/>
<di:BPMNLabel id="_L09PEKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</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">
<dc:Bounds height="25.0" width="50.0" x="431.0" y="325.0"/>
<di:BPMNLabel id="_L092IKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_lWCDjKYOEeOPa_FxNu5jAg"
bpmnElement="_lWA08qYOEeOPa_FxNu5jAg">
<dc:Bounds height="25.0" width="50.0" x="233.0" y="325.0"/>
<di:BPMNLabel id="_L092IapMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_lWCDm6YOEeOPa_FxNu5jAg"
bpmnElement="_lWA1B6YOEeOPa_FxNu5jAg">
<dc:Bounds height="26.0" width="50.0" x="508.0" y="322.0"/>
<di:BPMNLabel id="_L092IqpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_0qRXQKYQEeOPa_FxNu5jAg"
bpmnElement="_0qQJIKYQEeOPa_FxNu5jAg">
<dc:Bounds height="22.0" width="22.0" x="393.0" y="325.0"/>
<di:BPMNLabel id="_L1CuoKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyNzIKhIEeOPa_FxNu5jAg"
bpmnElement="_DyL98KhIEeOPa_FxNu5jAg">
<dc:Bounds height="29.0" width="57.0" x="585.0" y="319.0"/>
<di:BPMNLabel id="_L1y8kKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyOaNahIEeOPa_FxNu5jAg"
bpmnElement="_DyOaMKhIEeOPa_FxNu5jAg">
<dc:Bounds height="22.0" width="22.0" x="697.0" y="324.0"/>
<di:BPMNLabel id="_L10xwKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyPBSqhIEeOPa_FxNu5jAg"
bpmnElement="_DyPBQKhIEeOPa_FxNu5jAg">
<dc:Bounds height="31.0" width="60.0" x="764.0" y="273.0"/>
<di:BPMNLabel id="_L12m8KpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyPoWqhIEeOPa_FxNu5jAg"
bpmnElement="_DyPoUKhIEeOPa_FxNu5jAg">
<dc:Bounds height="31.0" width="60.0" x="764.0" y="318.0"/>
<di:BPMNLabel id="_L12m8apMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyQPaqhIEeOPa_FxNu5jAg"
bpmnElement="_DyQPYKhIEeOPa_FxNu5jAg">
<dc:Bounds height="30.0" width="60.0" x="764.0" y="370.0"/>
<di:BPMNLabel id="_L12m8qpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyQ2dahIEeOPa_FxNu5jAg"
bpmnElement="_DyQ2cKhIEeOPa_FxNu5jAg">
<dc:Bounds height="16.0" width="15.0" x="864.0" y="377.0"/>
<di:BPMNLabel id="_L15DMKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DyRdhahIEeOPa_FxNu5jAg"
bpmnElement="_DyRdgKhIEeOPa_FxNu5jAg">
<dc:Bounds height="22.0" width="22.0" x="878.0" y="322.0"/>
<di:BPMNLabel id="_L15DMapMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</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
<dc:Bounds height="30.0" width="60.0" x="935.0" y="321.0"/>
<di:BPMNLabel id="_L15DMqpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_DySroKhIEeOPa_FxNu5jAg"
bpmnElement="_DySEk6hIEeOPa_FxNu5jAg">
<dc:Bounds height="15.0" width="15.0" x="1030.0" y="326.0"/>
<di:BPMNLabel id="_L15DM6pMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_4iSckKYOEeOPa_FxNu5jAg"
bpmnElement="_4iROcKYOEeOPa_FxNu5jAg" isHorizontal="true">
<dc:Bounds height="50.0" width="1238.0" x="24.0" y="139.0"/>
<di:BPMNLabel id="_L15DNKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_86GKWqYOEeOPa_FxNu5jAg"
bpmnElement="_86GKUKYOEeOPa_FxNu5jAg">
<dc:Bounds height="25.0" width="50.0" x="104.0" y="151.0"/>
<di:BPMNLabel id="_L15qQKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_o6A1QKYQEeOPa_FxNu5jAg"
bpmnElement="_o5_AEKYQEeOPa_FxNu5jAg">
<dc:Bounds height="22.0" width="22.0" x="191.0" y="154.0"/>
<di:BPMNLabel id="_L15qQapMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_GkRJkKYPEeOPa_FxNu5jAg"
bpmnElement="_GkP7cKYPEeOPa_FxNu5jAg" isHorizontal="true">
<dc:Bounds height="59.0" width="1238.0" x="24.0" y="80.0"/>
<di:BPMNLabel id="_L15qQqpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_lWnccKYPEeOPa_FxNu5jAg"
bpmnElement="_lWlnQKYPEeOPa_FxNu5jAg">
<dc:Bounds height="15.0" width="15.0" x="60.0" y="93.0"/>
<di:BPMNLabel id="_L164YKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_alhNMKYWEeOPa_FxNu5jAg"
bpmnElement="_alf_EKYWEeOPa_FxNu5jAg">
<dc:Bounds height="30.0" width="60.0" x="99.0" y="88.0"/>
<di:BPMNLabel id="_L17fcKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_broguaYWEeOPa_FxNu5jAg"
bpmnElement="_brn5oKYWEeOPa_FxNu5jAg">
<dc:Bounds height="30.0" width="61.0" x="269.0" y="88.0"/>
<di:BPMNLabel id="_L18GgKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_jAhqqKYWEeOPa_FxNu5jAg"
bpmnElement="_jAhDkKYWEeOPa_FxNu5jAg">
<dc:Bounds height="30.0" width="61.0" x="497.0" y="93.0"/>
<di:BPMNLabel id="_L18GgapMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_3fRD4KYPEeOPa_FxNu5jAg"
bpmnElement="_3fP1wKYPEeOPa_FxNu5jAg" isHorizontal="true">
<dc:Bounds height="62.0" width="1238.0" x="24.0" y="189.0"/>
<di:BPMNLabel id="_L18GgqpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_5UPMAKYQEeOPa_FxNu5jAg"
bpmnElement="_5UN94KYQEeOPa_FxNu5jAg">
<dc:Bounds height="30.0" width="60.0" x="498.0" y="204.0"/>
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"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_cVmDtaYWEeOPa_FxNu5jAg"
bpmnElement="_cVlcoKYWEeOPa_FxNu5jAg">
<dc:Bounds height="26.0" width="50.0" x="371.0" y="206.0"/>
<di:BPMNLabel id="_L18GhKpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_IeB1oKYREeOPa_FxNu5jAg"
bpmnElement="_IeAngKYREeOPa_FxNu5jAg" isHorizontal="true">
<dc:Bounds height="66.0" width="1238.0" x="24.0" y="15.0"/>
<di:BPMNLabel id="_L18GhapMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</di:BPMNShape>
<di:BPMNShape id="_QM4-wKYREeOPa_FxNu5jAg"
bpmnElement="_QM2igKYREeOPa_FxNu5jAg">
<dc:Bounds height="29.0" width="58.0" x="499.0" y="34.0"/>
<di:BPMNLabel id="_L18GhqpMEeOF6Y75kSJIFA"
labelStyle="_L0hKMKpMEeOF6Y75kSJIFA"/>
</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
<?xml version="1.0" encoding="UTF-8"?>
<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">
<graphics orientation="0" x="270" y="500"/>
<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">
<graphics orientation="0" x="723" y="96"/>
<label id="_GkP7cKYPEeOPa_FxNu5jAg.0" text="Conssessionária"
type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_3fP1wKYPEeOPa_FxNu5jAg" initialMarking="1" type="node">
<graphics orientation="0" x="1140" y="390"/>
<label id="_3fP1wKYPEeOPa_FxNu5jAg.0" text="Detran" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_IeAngKYREeOPa_FxNu5jAg" initialMarking="1" type="node">
<graphics orientation="0" x="2059" y="116"/>
<label id="_IeAngKYREeOPa_FxNu5jAg.0" text="Arrecadador" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_lWAN7aYOEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="987" y="744"/>
<label id="_lWAN7aYOEeOPa_FxNu5jAg.0.0" text="W2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S2" initialMarking="0" type="node">
<graphics orientation="0" x="1088" y="743"/>
<label id="S2.0.0" text="S2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_lWA1B6YOEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="1250" y="741"/>
<label id="_lWA1B6YOEeOPa_FxNu5jAg.0.0" text="W4" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S4" initialMarking="0" type="node">
<graphics orientation="0" x="1362" y="744"/>
<label id="S4.0.0" text="S4" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</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
<graphics orientation="0" x="200" y="740"/>
<label id="_lWA08qYOEeOPa_FxNu5jAg.0.0" text="W3" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S3" initialMarking="0" type="node">
<graphics orientation="0" x="330" y="740"/>
<label id="S3.0.0" text="S3" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_lWAN46YOEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="540" y="740"/>
<label id="_lWAN46YOEeOPa_FxNu5jAg.0.0" text="W1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S1" initialMarking="0" type="node">
<graphics orientation="0" x="660" y="740"/>
<label id="S1.0.0" text="S1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_alf_EKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="160" y="287"/>
<label id="_alf_EKYWEeOPa_FxNu5jAg.0.0" text="W11" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S11" initialMarking="0" type="node">
<graphics orientation="0" x="275" y="290"/>
<label id="S11.0.0" text="S11" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_86GKUKYOEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="170" y="413"/>
<label id="_86GKUKYOEeOPa_FxNu5jAg.0.0" text="W10" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S10" initialMarking="0" type="node">
<graphics orientation="0" x="270" y="413"/>
<label id="S10.0.0" text="S10" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_brn5oKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="539" y="290"/>
<label id="_brn5oKYWEeOPa_FxNu5jAg.0.0" text="W12" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S12" initialMarking="0" type="node">
<graphics orientation="0" x="639" y="290"/>
<label id="S12.0.0" text="S12" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_cVlcoKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="770" y="540"/>
<label id="_cVlcoKYWEeOPa_FxNu5jAg.0.0" text="W15" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S15" initialMarking="0" type="node">
<graphics orientation="0" x="870" y="540"/>
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 id="S15.0.0" text="S15" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_o5_AEKYQEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="391" y="412"/>
<label id="_o5_AEKYQEeOPa_FxNu5jAg.0.0" text="PAnd-2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="Z1-1" initialMarking="0" type="node">
<graphics orientation="0" x="860" y="740"/>
<label id="Z1-1.0.0" text="Z1-1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="Z1-2" initialMarking="0" type="node">
<graphics orientation="0" x="860" y="740"/>
<label id="Z1-2.0.0" text="Z1-2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_5UN94KYQEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="1320" y="540"/>
<label id="_5UN94KYQEeOPa_FxNu5jAg.0.0" text="W14" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S14" initialMarking="0" type="node">
<graphics orientation="0" x="1470" y="540"/>
<label id="S14.0.0" text="S14" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_jAhDkKYWEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="1650" y="330"/>
<label id="_jAhDkKYWEeOPa_FxNu5jAg.0.0" text="W13" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S13" initialMarking="0" type="node">
<graphics orientation="0" x="1750" y="330"/>
<label id="S13.0.0" text="S13" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_QM2igKYREeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="1952" y="219"/>
<label id="_QM2igKYREeOPa_FxNu5jAg.0.0" text="W16" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S16" initialMarking="0" type="node">
<graphics orientation="0" x="2052" y="219"/>
<label id="S16.0.0" text="S16" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyL98KhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="1634" y="744"/>
<label id="_DyL98KhIEeOPa_FxNu5jAg.0.0" text="W5" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S5" initialMarking="0" type="node">
<graphics orientation="0" x="1734" y="744"/>
<label id="S5.0.0" text="S5" type="text">
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
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyOaMKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="1976" y="742"/>
<label id="_DyOaMKhIEeOPa_FxNu5jAg.0.0"
text="Qual_a_situação_do_pagamento?" type="text">
<graphics orientation="0" x="-26" y="36"/>
</label>
</place>
<place id="_DyPBQKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2238" y="539"/>
<label id="_DyPBQKhIEeOPa_FxNu5jAg.0.0" text="W6" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S6" initialMarking="0" type="node">
<graphics orientation="0" x="2350" y="540"/>
<label id="S6.0.0" text="S6" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyQPYKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2190" y="980"/>
<label id="_DyQPYKhIEeOPa_FxNu5jAg.0.0" text="W8" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S8" initialMarking="0" type="node">
<graphics orientation="0" x="2350" y="980"/>
<label id="S8.0.0" text="S8" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyPoUKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2180" y="740"/>
<label id="_DyPoUKhIEeOPa_FxNu5jAg.0.0" text="W7" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S7" initialMarking="0" type="node">
<graphics orientation="0" x="2320" y="740"/>
<label id="S7.0.0" text="S7" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyRdgKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2490" y="640"/>
<label id="_DyRdgKhIEeOPa_FxNu5jAg.0.0" text="Desvios2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyQ2cKhIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2580" y="980"/>
<label id="_DyQ2cKhIEeOPa_FxNu5jAg.0.0" text="Pd1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DyRdiahIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2645" y="641"/>
<label id="_DyRdiahIEeOPa_FxNu5jAg.0.0" text="W9" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="S9" initialMarking="0" type="node">
<graphics orientation="0" x="2790" y="640"/>
<label id="S9.0.0" text="S9" type="text">
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
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<place id="_DySEk6hIEeOPa_FxNu5jAg" initialMarking="0" type="node">
<graphics orientation="0" x="2990" y="640"/>
<label id="_DySEk6hIEeOPa_FxNu5jAg.0.0" text="Pd2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</place>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-2"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="1138" y="742"/>
<label id="Tacticity-2.0.0" text="Atualizar_Cadastro" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-4"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="1432" y="744"/>
<label id="Tacticity-4.0.0" text="Lançar_IPVA" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-3"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="410" y="740"/>
<label id="Tacticity-3.0.0" text="Validação_da_NF-e" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-1"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="720" y="740"/>
<label id="Tacticity-1.0.0" text="Realiza_Pré-Cadastro" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1"
id="_lWlnQKYPEeOPa_FxNu5jAg" preemptionPolicy="PRD"
serverType="ExclusiveServer" type="node">
<graphics orientation="0" x="86" y="288"/>
<label id="_lWlnQKYPEeOPa_FxNu5jAg.0.0" text="Início" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-11"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="339" y="286"/>
<label id="Tacticity-11.0.0" text="Vende_um_veículo_novo" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-10"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="320" y="413"/>
<label id="Tacticity-10.0.0" text="Gera_NF-e" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-12"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="689" y="290"/>
<label id="Tacticity-12.0.0" text="Encaminha_para_vistoria" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-15"
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
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="920" y="540"/>
<label id="Tacticity-15.0.0" text="Realiza_a_vistoria" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-14"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="1550" y="540"/>
<label id="Tacticity-14.0.0" text="Lança_taxas_e_serviços" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-13"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="1800" y="330"/>
<label id="Tacticity-13.0.0" text="Paga_taxas_e_impostos" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-16"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="2102" y="219"/>
<label id="Tacticity-16.0.0" text="Informa_pagamento" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-5"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="1784" y="744"/>
<label id="Tacticity-5.0.0" text="Verificar_situação_do_pagamento"
type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-6"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="2420" y="540"/>
<label id="Tacticity-6.0.0" text="Alterar_para_Status_Parcial_"
type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-8"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="2420" y="980"/>
<label id="Tacticity-8.0.0" text="Amortizar_Conta-Corrente" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-7"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="2390" y="740"/>
<label id="Tacticity-7.0.0" text="Alterar_Status_Total" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<exponentialTransition DTSPNpriority="1" delay="1" id="Tacticity-9"
preemptionPolicy="PRD" serverType="InfiniteServer" type="node">
<graphics orientation="0" x="2860" y="640"/>
<label id="Tacticity-9.0.0" text="Sincronismo_Detran" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</exponentialTransition>
<immediateTransition enablingFunction="" id="q2" priority="1"
type="node" weight="1">
<graphics orientation="0" x="1033" y="743"/>
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">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q4" priority="1"
type="node" weight="1">
<graphics orientation="0" x="1293" y="745"/>
<label id="q4.0.0" text="q4" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q3" priority="1"
type="node" weight="1">
<graphics orientation="0" x="270" y="740"/>
<label id="q3.0.0" text="q3" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q1" priority="1"
type="node" weight="1">
<graphics orientation="0" x="590" y="740"/>
<label id="q1.0.0" text="q1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q11" priority="1"
type="node" weight="1">
<graphics orientation="0" x="210" y="287"/>
<label id="q11.0.0" text="q11" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q10" priority="1"
type="node" weight="1">
<graphics orientation="0" x="220" y="413"/>
<label id="q10.0.0" text="q10" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q12" priority="1"
type="node" weight="1">
<graphics orientation="0" x="589" y="290"/>
<label id="q12.0.0" text="q12" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q15" priority="1"
type="node" weight="1">
<graphics orientation="0" x="820" y="540"/>
<label id="q15.0.0" text="q15" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="qsplit2" priority="1"
type="node" weight="1">
<graphics orientation="0" x="461" y="418"/>
<label id="qsplit2.0.0" text="Desvios1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="_0qQJIKYQEeOPa_FxNu5jAg"
priority="1" type="node" weight="1">
<graphics orientation="0" x="910" y="740"/>
<label id="_0qQJIKYQEeOPa_FxNu5jAg.0.0" text="Desvios2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
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
<immediateTransition enablingFunction="" id="q14" priority="1"
type="node" weight="1">
<graphics orientation="0" x="1400" y="540"/>
<label id="q14.0.0" text="q14" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q13" priority="1"
type="node" weight="1">
<graphics orientation="0" x="1700" y="330"/>
<label id="q13.0.0" text="q13" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q16" priority="1"
type="node" weight="1">
<graphics orientation="0" x="2002" y="219"/>
<label id="q16.0.0" text="q16" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q5" priority="1"
type="node" weight="1">
<graphics orientation="0" x="1684" y="744"/>
<label id="q5.0.0" text="q5" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction=""
id="_DyOaMKhIEeOPa_FxNu5jAgqx1" priority="1" type="node" weight="1">
<graphics orientation="0" x="2084" y="537"/>
<label id="_DyOaMKhIEeOPa_FxNu5jAgqx1.0.0"
text="Quitado_parcialmente-qx1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q6" priority="1"
type="node" weight="1">
<graphics orientation="0" x="2288" y="539"/>
<label id="q6.0.0" text="q6" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction=""
id="_DyOaMKhIEeOPa_FxNu5jAgqx2" priority="1" type="node" weight="1">
<graphics orientation="0" x="2090" y="980"/>
<label id="_DyOaMKhIEeOPa_FxNu5jAgqx2.0.0" text="Não_quitado-qx2"
type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q8" priority="1"
type="node" weight="1">
<graphics orientation="0" x="2270" y="980"/>
<label id="q8.0.0" text="q8" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction=""
id="_DyOaMKhIEeOPa_FxNu5jAgqx3" priority="1" type="node" weight="1">
<graphics orientation="0" x="2090" y="740"/>
<label id="_DyOaMKhIEeOPa_FxNu5jAgqx3.0.0" text="quitado-qx3"
type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q7" priority="1"
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
type="node" weight="1">
<graphics orientation="0" x="2250" y="740"/>
<label id="q7.0.0" text="q7" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="qd1" priority="1"
type="node" weight="1">
<graphics orientation="0" x="2650" y="980"/>
<label id="qd1.0.0" text="Fim2" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction=""
id="_DyRdgKhIEeOPa_FxNu5jAgqx4" priority="1" type="node" weight="1">
<graphics orientation="0" x="2580" y="640"/>
<label id="_DyRdgKhIEeOPa_FxNu5jAgqx4.0.0" text="qx4" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="q9" priority="1"
type="node" weight="1">
<graphics orientation="0" x="2720" y="642"/>
<label id="q9.0.0" text="q9" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<immediateTransition enablingFunction="" id="qd2" priority="1"
type="node" weight="1">
<graphics orientation="0" x="3050" y="640"/>
<label id="qd2.0.0" text="Fim1" type="text">
<graphics orientation="0" x="-10" y="-40"/>
</label>
</immediateTransition>
<arc fromNode="Tacticity-2" id="_lWA1SqYOEeOPa_FxNu5jAg"
toNode="_lWA1B6YOEeOPa_FxNu5jAg" type="connector">
<inscription id="_lWA1SqYOEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_lWAN7aYOEeOPa_FxNu5jAg" id="wq2" toNode="q2"
type="connector">
<inscription id="wq2.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q2" id="qs2" toNode="S2" type="connector">
<inscription id="qs2.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S2" id="st2" toNode="Tacticity-2" type="connector">
<inscription id="st2.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-2" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q2"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
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 id="wq4.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q4" id="qs4" toNode="S4" type="connector">
<inscription id="qs4.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S4" id="st4" toNode="Tacticity-4" type="connector">
<inscription id="st4.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-4" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="1430" y="850"/>
</handle>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q4"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-3" id="_lWA1UKYOEeOPa_FxNu5jAg"
toNode="_lWAN46YOEeOPa_FxNu5jAg" type="connector">
<inscription id="_lWA1UKYOEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_lWA08qYOEeOPa_FxNu5jAg" id="wq3" toNode="q3"
type="connector">
<inscription id="wq3.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="q3" id="qs3" toNode="S3" type="connector">
<inscription id="qs3.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="S3" id="st3" toNode="Tacticity-3" type="connector">
<inscription id="st3.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-3" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q3"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</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">
<inscription id="wq1.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="-5"/>
</inscription>
</arc>
<arc fromNode="q1" id="qs1" toNode="S1" type="connector">
<inscription id="qs1.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="S1" id="st1" toNode="Tacticity-1" type="connector">
<inscription id="st1.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-1" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q1"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_lWlnQKYPEeOPa_FxNu5jAg" id="_qiedUKYPEeOPa_FxNu5jAg"
toNode="_alf_EKYWEeOPa_FxNu5jAg" type="connector">
<inscription id="_qiedUKYPEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_alf_EKYWEeOPa_FxNu5jAg" id="wq11" toNode="q11"
type="connector">
<inscription id="wq11.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q11" id="qs11" toNode="S11" type="connector">
<inscription id="qs11.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S11" id="st11" toNode="Tacticity-11" type="connector">
<inscription id="st11.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-11" id="" toNode="_GkP7cKYPEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="440" y="290"/>
</handle>
</arc>
<arc fromNode="_GkP7cKYPEeOPa_FxNu5jAg" id="" toNode="q11"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</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
<graphics orientation="0" x="270" y="200"/>
</handle>
</arc>
<arc fromNode="Tacticity-11" id="_XIX_oKYQEeOPa_FxNu5jAg"
toNode="_86GKUKYOEeOPa_FxNu5jAg" type="connector">
<inscription id="_XIX_oKYQEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_XIX_oKYQEeOPa_FxNu5jAg.2">
<graphics orientation="0" x="300" y="330"/>
</handle>
<handle id="_XIX_oKYQEeOPa_FxNu5jAg.1">
<graphics orientation="0" x="100" y="380"/>
</handle>
</arc>
<arc fromNode="_86GKUKYOEeOPa_FxNu5jAg" id="wq10" toNode="q10"
type="connector">
<inscription id="wq10.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q10" id="qs10" toNode="S10" type="connector">
<inscription id="qs10.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S10" id="st10" toNode="Tacticity-10" type="connector">
<inscription id="st10.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-10" id="" toNode="_4iROcKYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="350" y="500"/>
</handle>
</arc>
<arc fromNode="_4iROcKYOEeOPa_FxNu5jAg" id="" toNode="q10"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="200" y="500"/>
</handle>
</arc>
<arc fromNode="Tacticity-12" id="_iC1iEKYQEeOPa_FxNu5jAg"
toNode="_cVlcoKYWEeOPa_FxNu5jAg" type="connector">
<inscription id="_iC1iEKYQEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_iC1iEKYQEeOPa_FxNu5jAg.1">
<graphics orientation="0" x="690" y="540"/>
</handle>
</arc>
<arc fromNode="_brn5oKYWEeOPa_FxNu5jAg" id="wq12" toNode="q12"
type="connector">
<inscription id="wq12.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q12" id="qs12" toNode="S12" type="connector">
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 id="qs12.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S12" id="st12" toNode="Tacticity-12" type="connector">
<inscription id="st12.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-12" id="" toNode="_GkP7cKYPEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="660" y="230"/>
</handle>
</arc>
<arc fromNode="_GkP7cKYPEeOPa_FxNu5jAg" id="" toNode="q12"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_cVlcoKYWEeOPa_FxNu5jAg" id="wq15" toNode="q15"
type="connector">
<inscription id="wq15.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="q15" id="qs15" toNode="S15" type="connector">
<inscription id="qs15.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="S15" id="st15" toNode="Tacticity-15" type="connector">
<inscription id="st15.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-15" id="" toNode="_3fP1wKYPEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="890" y="470"/>
</handle>
</arc>
<arc fromNode="_3fP1wKYPEeOPa_FxNu5jAg" id="" toNode="q15"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="890" y="450"/>
</handle>
</arc>
<arc fromNode="Tacticity-10" id="_o6GU0KYQEeOPa_FxNu5jAg"
toNode="_o5_AEKYQEeOPa_FxNu5jAg" type="connector">
<inscription id="_o6GU0KYQEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</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 id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="qsplit2" id="_pRfhIKYQEeOPa_FxNu5jAg"
toNode="_brn5oKYWEeOPa_FxNu5jAg" type="connector">
<inscription id="_pRfhIKYQEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="qsplit2" id="_qF-5IKYQEeOPa_FxNu5jAg"
toNode="_lWA08qYOEeOPa_FxNu5jAg" type="connector">
<inscription id="_qF-5IKYQEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-15" id="" toNode="Z1-1" type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="830" y="630"/>
</handle>
</arc>
<arc fromNode="Z1-1" id="" toNode="_0qQJIKYQEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-1" id="" toNode="Z1-2" type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="Z1-2" id="" toNode="_0qQJIKYQEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="_0qQJIKYQEeOPa_FxNu5jAg" id=""
toNode="_lWAN7aYOEeOPa_FxNu5jAg" type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-4" id="_5USPUKYQEeOPa_FxNu5jAg"
toNode="_5UN94KYQEeOPa_FxNu5jAg" type="connector">
<inscription id="_5USPUKYQEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_5USPUKYQEeOPa_FxNu5jAg.1">
<graphics orientation="0" x="1240" y="540"/>
</handle>
</arc>
<arc fromNode="_5UN94KYQEeOPa_FxNu5jAg" id="wq14" toNode="q14"
type="connector">
<inscription id="wq14.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q14" id="qs14" toNode="S14" type="connector">
<inscription id="qs14.0" text="1" type="inscriptionText">
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
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="S14" id="st14" toNode="Tacticity-14" type="connector">
<inscription id="st14.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="-5"/>
</inscription>
</arc>
<arc fromNode="Tacticity-14" id="" toNode="_3fP1wKYPEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="1490" y="440"/>
</handle>
</arc>
<arc fromNode="_3fP1wKYPEeOPa_FxNu5jAg" id="" toNode="q14"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="1330" y="460"/>
</handle>
</arc>
<arc fromNode="Tacticity-14" id="_BJaYgKYREeOPa_FxNu5jAg"
toNode="_jAhDkKYWEeOPa_FxNu5jAg" type="connector">
<inscription id="_BJaYgKYREeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_BJaYgKYREeOPa_FxNu5jAg.1">
<graphics orientation="0" x="1490" y="330"/>
</handle>
</arc>
<arc fromNode="_jAhDkKYWEeOPa_FxNu5jAg" id="wq13" toNode="q13"
type="connector">
<inscription id="wq13.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="q13" id="qs13" toNode="S13" type="connector">
<inscription id="qs13.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="S13" id="st13" toNode="Tacticity-13" type="connector">
<inscription id="st13.0" text="1" type="inscriptionText">
<graphics orientation="0" x="-5" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-13" id="" toNode="_GkP7cKYPEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="1730" y="210"/>
</handle>
</arc>
<arc fromNode="_GkP7cKYPEeOPa_FxNu5jAg" id="" toNode="q13"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</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
<graphics orientation="0" x="1660" y="260"/>
</handle>
</arc>
<arc fromNode="Tacticity-13" id="_QM_FYKYREeOPa_FxNu5jAg"
toNode="_QM2igKYREeOPa_FxNu5jAg" type="connector">
<inscription id="_QM_FYKYREeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_QM_FYKYREeOPa_FxNu5jAg.1">
<graphics orientation="0" x="1940" y="330"/>
</handle>
</arc>
<arc fromNode="_QM2igKYREeOPa_FxNu5jAg" id="wq16" toNode="q16"
type="connector">
<inscription id="wq16.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q16" id="qs16" toNode="S16" type="connector">
<inscription id="qs16.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S16" id="st16" toNode="Tacticity-16" type="connector">
<inscription id="st16.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-16" id="" toNode="_IeAngKYREeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_IeAngKYREeOPa_FxNu5jAg" id="" toNode="q16"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-5" id="_DySrpKhIEeOPa_FxNu5jAg"
toNode="_DyOaMKhIEeOPa_FxNu5jAg" type="connector">
<inscription id="_DySrpKhIEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyL98KhIEeOPa_FxNu5jAg" id="wq5" toNode="q5"
type="connector">
<inscription id="wq5.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q5" id="qs5" toNode="S5" type="connector">
<inscription id="qs5.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S5" id="st5" toNode="Tacticity-5" type="connector">
<inscription id="st5.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-5" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
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
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="1780" y="900"/>
</handle>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q5"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="1680" y="890"/>
</handle>
</arc>
<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAg"
id="_DyOaMKhIEeOPa_FxNu5jAgrqx1" toNode="_DyOaMKhIEeOPa_FxNu5jAgqx1"
type="connector">
<inscription id="_DyOaMKhIEeOPa_FxNu5jAgrqx1.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_DyOaMKhIEeOPa_FxNu5jAgrqx1.1">
<graphics orientation="0" x="2014" y="540"/>
</handle>
</arc>
<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAgqx1"
id="_DyOaMKhIEeOPa_FxNu5jAgoutqx1" toNode="_DyPBQKhIEeOPa_FxNu5jAg"
type="connector">
<inscription id="_DyOaMKhIEeOPa_FxNu5jAgoutqx1.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyPBQKhIEeOPa_FxNu5jAg" id="wq6" toNode="q6"
type="connector">
<inscription id="wq6.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q6" id="qs6" toNode="S6" type="connector">
<inscription id="qs6.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S6" id="st6" toNode="Tacticity-6" type="connector">
<inscription id="st6.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-6" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".2">
<graphics orientation="0" x="3130" y="540"/>
</handle>
<handle id=".1">
<graphics orientation="0" x="3127" y="1223"/>
</handle>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q6"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</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">
<graphics orientation="0" x="3142" y="1239"/>
</handle>
<handle id=".2">
<graphics orientation="0" x="3150" y="480"/>
</handle>
<handle id=".3">
<graphics orientation="0" x="2330" y="480"/>
</handle>
</arc>
<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAg"
id="_DyOaMKhIEeOPa_FxNu5jAgrqx2" toNode="_DyOaMKhIEeOPa_FxNu5jAgqx2"
type="connector">
<inscription id="_DyOaMKhIEeOPa_FxNu5jAgrqx2.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_DyOaMKhIEeOPa_FxNu5jAgrqx2.1">
<graphics orientation="0" x="2053" y="980"/>
</handle>
</arc>
<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAgqx2"
id="_DyOaMKhIEeOPa_FxNu5jAgoutqx2" toNode="_DyQPYKhIEeOPa_FxNu5jAg"
type="connector">
<inscription id="_DyOaMKhIEeOPa_FxNu5jAgoutqx2.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyQPYKhIEeOPa_FxNu5jAg" id="wq8" toNode="q8"
type="connector">
<inscription id="wq8.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q8" id="qs8" toNode="S8" type="connector">
<inscription id="qs8.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S8" id="st8" toNode="Tacticity-8" type="connector">
<inscription id="st8.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-8" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="2420" y="1120"/>
</handle>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q8"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="2223" y="1073"/>
</handle>
</arc>
<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAg"
id="_DyOaMKhIEeOPa_FxNu5jAgrqx3" toNode="_DyOaMKhIEeOPa_FxNu5jAgqx3"
type="connector">
<inscription id="_DyOaMKhIEeOPa_FxNu5jAgrqx3.0" text="1"
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
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyOaMKhIEeOPa_FxNu5jAgqx3"
id="_DyOaMKhIEeOPa_FxNu5jAgoutqx3" toNode="_DyPoUKhIEeOPa_FxNu5jAg"
type="connector">
<inscription id="_DyOaMKhIEeOPa_FxNu5jAgoutqx3.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyPoUKhIEeOPa_FxNu5jAg" id="wq7" toNode="q7"
type="connector">
<inscription id="wq7.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q7" id="qs7" toNode="S7" type="connector">
<inscription id="qs7.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S7" id="st7" toNode="Tacticity-7" type="connector">
<inscription id="st7.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-7" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".3">
<graphics orientation="0" x="2389" y="810"/>
</handle>
<handle id=".2">
<graphics orientation="0" x="2776" y="912"/>
</handle>
<handle id=".1">
<graphics orientation="0" x="2914" y="1165"/>
</handle>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q7"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="2883" y="1149"/>
</handle>
<handle id=".2">
<graphics orientation="0" x="2754" y="932"/>
</handle>
<handle id=".3">
<graphics orientation="0" x="2269" y="816"/>
</handle>
</arc>
<arc fromNode="Tacticity-6" id="_DyVu8KhIEeOPa_FxNu5jAg"
toNode="_DyRdgKhIEeOPa_FxNu5jAg" type="connector">
<inscription id="_DyVu8KhIEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</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"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-8" id="_DyW9EKhIEeOPa_FxNu5jAg"
toNode="_DyQ2cKhIEeOPa_FxNu5jAg" type="connector">
<inscription id="_DyW9EKhIEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyQ2cKhIEeOPa_FxNu5jAg" id="" toNode="qd1"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyRdgKhIEeOPa_FxNu5jAg"
id="_DyRdgKhIEeOPa_FxNu5jAgrqx4" toNode="_DyRdgKhIEeOPa_FxNu5jAgqx4"
type="connector">
<inscription id="_DyRdgKhIEeOPa_FxNu5jAgrqx4.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyRdgKhIEeOPa_FxNu5jAgqx4"
id="_DyRdgKhIEeOPa_FxNu5jAgoutqx4" toNode="_DyRdiahIEeOPa_FxNu5jAg"
type="connector">
<inscription id="_DyRdgKhIEeOPa_FxNu5jAgoutqx4.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DyRdiahIEeOPa_FxNu5jAg" id="wq9" toNode="q9"
type="connector">
<inscription id="wq9.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="q9" id="qs9" toNode="S9" type="connector">
<inscription id="qs9.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="S9" id="st9" toNode="Tacticity-9" type="connector">
<inscription id="st9.0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-9" id="" toNode="_lWAN4qYOEeOPa_FxNu5jAg"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="2952" y="1193"/>
</handle>
</arc>
<arc fromNode="_lWAN4qYOEeOPa_FxNu5jAg" id="" toNode="q9"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="413" y="256"/>
</inscription>
<handle id=".1">
<graphics orientation="0" x="2937" y="1180"/>
</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"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="_DySEk6hIEeOPa_FxNu5jAg" id="" toNode="qd2"
type="connector">
<inscription id=".0" text="1" type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
</arc>
<arc fromNode="Tacticity-16" id="_ipXtgKhIEeOPa_FxNu5jAg"
toNode="_DyL98KhIEeOPa_FxNu5jAg" type="connector">
<inscription id="_ipXtgKhIEeOPa_FxNu5jAg.0" text="1"
type="inscriptionText">
<graphics orientation="0" x="0" y="0"/>
</inscription>
<handle id="_ipXtgKhIEeOPa_FxNu5jAg.2">
<graphics orientation="0" x="2100" y="320"/>
</handle>
<handle id="_ipXtgKhIEeOPa_FxNu5jAg.1">
<graphics orientation="0" x="1580" y="680"/>
</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
t.add(new ImmediateTransitionType(new GraphicsType(this.getX()+50,
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 java.util.ArrayList;
import br.ufpe.cin.bpmn.TInclusiveGateway;
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 DesvioInclusivo extends Elemento {
static int indice=0;
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,
ArrayList<ImmediateTransitionType> t){
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,
ArrayList<PlaceType> p,
ArrayList<ImmediateTransitionType> t){
arco.get(arco.size() - 1).setFromNode(f.getOrigem().getSaida());
if (!this.isMapeado()) {
// Por
p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
0), this.getId(), "Por-"+this.i));
// qx
t.add(new ImmediateTransitionType(new GraphicsType(this.getX()+50,
this.getY(), 0), "qx"+this.i, this.getRotulo()));
// arco Por -> qx
arco.add(new ArcType(this.getId(), "qx"+this.i, "", new
InscriptionType()));
this.setMapeado(true);
}
if (f.getOrigem().getId().equals(this.getId())){
this.xi++;
//Definindo a saída
this.setSaida("qSx"+this.i+"-"+this.xi);
arco.get(arco.size() - 1).setFromNode(f.getOrigem().getSaida());
// arco Por -> qx
arco.add(new ArcType("qx"+this.i, "Px"+this.i+"-"+this.xi, "",
new InscriptionType()));
// Pxi
p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
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
t.add(new ImmediateTransitionType(new
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,
ArrayList<PlaceType> p,
ArrayList<ImmediateTransitionType> t){
if (!this.isMapeado()) {
if (f.getOrigem().getId().equals(this.getId())){
// qz
t.add(new ImmediateTransitionType(new
GraphicsType(this.getX()+50, this.getY(),
0), this.getId(), this.getRotulo()));
// arco qz -> fora (arco de saída)
// Apagndo o arco original.
arco.remove(arco.size()-1);
arco.add(new ArcType(this.getId(),
f.getDestino().getId(), "", new
InscriptionType()));
this.setMapeado(true);
}
}
if (f.getDestino().getId().equals(this.getId())){
// Apagndo o arco original.
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
InscriptionType()));
// 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 java.util.ArrayList;
import br.ufpe.cin.bpmn.TParallelGateway;
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 DesvioParalelo extends Elemento {
static int indice=0;
private int i=++indice;
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,
ArrayList<PlaceType> p,
ArrayList<ImmediateTransitionType> t){
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,
ArrayList<PlaceType> p,
ArrayList<ImmediateTransitionType> t){
arco.get(arco.size() - 1).setFromNode(f.getOrigem().getSaida());
if (!this.isMapeado()) {
// Pd
p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
0), this.getId(), "PAnd-"+this.i));
// qd
t.add(new ImmediateTransitionType(new
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
InscriptionType()));
this.setMapeado(true);
}
}
public void geraJuncaoParalela(Fluxo f, ArrayList<ArcType> arco,
ArrayList<PlaceType> p,
ArrayList<ImmediateTransitionType> t){
int posicao;
if (!this.isMapeado()) {
if (f.getOrigem().getId().equals(this.getId())){
// qz
t.add(new ImmediateTransitionType(new
GraphicsType(this.getX()+50, this.getY(), 0), this.getId(), this.getRotulo()));
179
// arco qz -> fora (arco de saída)
// 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);
// arco.remove(arco.size()-1);
arco.add(new ArcType(this.getId(),
f.getDestino().getId(), "", new InscriptionType()));
this.setMapeado(true);
}
}
if (f.getDestino().getId().equals(this.getId())){
// Apagando 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.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 java.util.ArrayList;
import br.ufpe.cin.bpmn.TEndEvent;
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 EventoFinal extends Elemento {
static int indice=0;
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){
if (!this.isMapeado()) {
// Pd
p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
0), this.getId(), "Pd"+this.i));
// qd
t.add(new ImmediateTransitionType(new
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
InscriptionType()));
this.setMapeado(true);
}
}
public void geraTransicaoImediata(ArrayList<ImmediateTransitionType> e){
e.add(new ImmediateTransitionType(new
GraphicsType(this.getX()+20, this.getY()+10, 0), this.getId()+"Fim",
this.getRotulo()));
this.setMapeado(true);
}
public void geraLugar(ArrayList<PlaceType> e){
e.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
0), this.getId(), "PD"));
this.setMapeado(true);
}
}
182
Evento Inicial package br.ufpe.cin.trans.bpmn;
import java.util.ArrayList;
import br.ufpe.cin.bpmn.TStartEvent;
import br.ufpe.cin.timenet.edspn.ExponentialTransitionType;
import br.ufpe.cin.timenet.edspn.GraphicsType;
import br.ufpe.cin.timenet.edspn.ImmediateTransitionType;
import br.ufpe.cin.timenet.edspn.ServerTypeType;
/**
*
* @author Jesse James Ma
*
*/
public class EventoInicial extends Elemento {
public EventoInicial(TStartEvent flowElement) {
super(flowElement,null);
}
/**
*
* @param e: Um arraylist para transições iniciais
*/
public void geraInicio(ArrayList<ExponentialTransitionType> e){
if (!this.isMapeado()) {
this.geraTransicaoExponencial(e);
this.setMapeado(true);
}
}
public void geraTransicaoImediata(ArrayList<ImmediateTransitionType> e){
if (!this.isMapeado()) {
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){
if (!this.isMapeado()) {
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 java.util.ArrayList;
import br.ufpe.cin.bpmn.TIntermediateThrowEvent;
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 EventoIntermediarioEnvio extends Elemento {
static int indice=0;
int i=++indice;
public EventoIntermediarioEnvio(TIntermediateThrowEvent flowElement) {
super(flowElement,null);
this.setSaida("qi"+this.i);
}
public void geraEnvio(ArrayList<ArcType> arco,
ArrayList<PlaceType> p, ArrayList<ImmediateTransitionType> t){
if (!this.isMapeado()) {
// Pd
p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
0), this.getId(), "Pi"+this.i));
// qd
t.add(new ImmediateTransitionType(new
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
InscriptionType()));
this.setMapeado(true);
}
}
}
184
Evento Intermediário de Recepção package br.ufpe.cin.trans.bpmn;
import java.util.ArrayList;
import br.ufpe.cin.bpmn.TIntermediateThrowEvent;
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 EventoIntermediarioRecepcao extends Elemento {
static int indice=0;
int i=++indice;
public EventoIntermediarioEnvio(TIntermediateThrowEvent flowElement) {
super(flowElement,null);
this.setSaida("qi"+this.i);}
public void geraEnvio(ArrayList<ArcType> arco,
ArrayList<PlaceType> p, ArrayList<ImmediateTransitionType> t){
if (!this.isMapeado()) {
// Pd
p.add(new PlaceType(new GraphicsType(this.getX(), this.getY(),
0), this.getId(), "Pi"+this.i));
// qd
t.add(new ImmediateTransitionType(new
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
InscriptionType()));
this.setMapeado(true);}}}
185
Fluxo package br.ufpe.cin.trans.bpmn;
import java.util.ArrayList;
import br.ufpe.cin.bpmn.TFlowElement;
import br.ufpe.cin.bpmn.TSequenceFlow;
import br.ufpe.cin.timenet.edspn.ArcType;
import br.ufpe.cin.timenet.edspn.ExponentialTransitionType;
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 Fluxo extends Elemento {
private Elemento origem;
private Elemento destino;
public Fluxo(TSequenceFlow flowElement, ArrayList<Elemento> elemento) {
super(flowElement,null);
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()));
this.setMapeado(true);
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();
e.geraDesvioouJuncao(f,this,arco, p, t);
} 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();
e.geraDesvioouJuncao(f,this,arco, p, t);
} 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();
e.geraDesvioouJuncao(f,this,arco, p, t);
} 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);
this.setMapeado(true);
}
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 java.util.ArrayList;
import br.ufpe.cin.bpmn.TLane;
import br.ufpe.cin.timenet.edspn.GraphicsType;
import br.ufpe.cin.timenet.edspn.PlaceType;
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;
static int indice=0;
private int i=++indice;
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) {
if (!this.isMapeado()) {
// Wi
p.add(new PlaceType(new GraphicsType(this.getX()+500,
this.getY()+(250*this.i), 0), this.getId(),
this.getRotulo(), capacidade));
}
this.setMapeado(true);
}
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 java.util.ArrayList;
import br.ufpe.cin.bpmn.TTask;
import br.ufpe.cin.timenet.edspn.ArcType;
import br.ufpe.cin.timenet.edspn.ExponentialTransitionType;
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 Tarefa extends Elemento {
static int indice=0;
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<PlaceType> p,
ArrayList<ImmediateTransitionType> t,
ArrayList<ExponentialTransitionType> x) {
if (f.getOrigem().getId()==this.getId())
arco.get(arco.size() - 1).setFromNode(f.getOrigem().getSaida());
if (!this.isMapeado()) {
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
InscriptionType()));
// arco qi -> Si
arco.add(new ArcType("q"+this.i, "S"+this.i, "qs"+this.i, new
InscriptionType()));
// 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.setMapeado(true);
} }
t.add(new ImmediateTransitionType(new GraphicsType(this.getX()+50,
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()));
}}}
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/
Recommended