BPMN - Business Process Modeling Notation

BPMN - Business Process Modeling Notation

1. Escopo

O Business Process Management Initiative (BPMI) desenvolveu um padro chamado Business

Process Modeling Notation (BPMN). O principal objetivo do BPMN prover uma notao que

realmente compreensvel para todos os usurios de negcio, desde o analista de negcio que

cria os rascunhos iniciais do processo , aos desenvolvedores tcnicos responsveis por

implementar a tecnologia que ir executar estes processos,e finalmente, para a pessoa do

negcio que ir gereniar e monitorar estes processos.

Assim, o BPMN cria uma ponte padro para o gap entre o desenho do processo de negcio e a

implementao do processo.

Outra meta, mas no menos importante, assegurar que a linguagem XML concebida para a

execuo de processos de negcio, como o BPEL4WS (Business Process Execution Language for

Web Services), possam ser visualizados com uma notao orientada ao negcio.

Esta especificao define notaes e semnticas de um Business Process Diagram (BPD) e

representa a juno das melhores prticas no seio da comunidade de modelagem de

negcio. A inteno do BPMN padronizar a notao para modelagem de processos de

negcio das diferentes notaes de modelagem e pontos de vista. Ao faz-lo, o BPMNir

proporcionar um meio simples de comunicao de informaes a outros utilizadores de

negcio, implementadores de processo, clientes e fornecedores.

Esta verso da especificao no especifica um mecanismo de troca entre os diagramas BPMN.

Esta verso da especificao no especifica um mecanismo para a troca do modelo semntico

de um processo representado por um diagrama BPMN.

Nota A troca de modelos de semnticas de processos BPMN e diagramas sujeita a outras

atividades padres em curso.

Esta verso da especificao, no especifica um mapeamento normativo de BPMN para

WSBPEL

Nota Esta verso prov um mapeamento no normativo de BPMN para WSBPEL mas a

especificao BPMN por si s conhecida por ser incompleta a respeito da captura de todas as

informaes necessrias para o WSBPEL. Ento o mapeamento insuficiente, em qualquer

caso.

Os membros do BPMI Notation Working Group tem trazido muitos conhecimentos e

experincias das mais diversas notaes e tem procurado consolidar as melhores idias destas

notaes divergentes para uma simples notao padro. Exemplos de notaes ou

metodologias que foram revisadas so: UML Activity Diagram, UML EDOC Business Processes,

IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-

Process Chains (EPCs).

Nota do blog - O escopo serve para nos dizer o que e o que no o BPMN. Se voc novo

na rea, voc deve estar muito confuso neste momento com tantas siglas para explicar outra

sigla...Mas no se preocupe agora com isso, a medida em que formos caminhando com a

traduo irei explicando-as. Atente-se neste momento para os sublinhados e grifados que

sero muito importante para seguirmos.

7. Viso Geral

Houve muitas atividades nos ltimos anos no desenvolvimento de Web services baseados em

uma linguagem de execuo XML para sistemas de Business Process Management (BPM).

Linguagens como o BPEL4WS provem um mecanismo formal para a definio de processos de

negcio. O elemento chave para tais linguagens que elas so otimizadas para a operao e

inter-operao dos sistemas BPM. A otimizao destas linguagens para as operaes de

software torna-os menos adaptados para a utilizao direta por humanos para desenhar,

gerenciar e monitorar processos de negcio. BPEL4WS possui tanto grfico como estruturas de

blocos e utiliza os princpios formais dos modelos matemticos, como o clculo do PI. Esta

tcnica prov uma base para a execuo dos processos de negcio para controlar o natural

complexo tanto das interaes internas como as de B2B e tomar vantagem dos benefcios dos

Web services. Dado a natureza do BPEL4WS, um processo de negcio complexo pode ser

organizado em um formato potencialmente complexo, desarticulado e intuitivo que

controlado muito bem por um sistema de software (ou um programador), mas seria difcil de

entender pelo analista de negcio e gerentes incumbidos de desenvolver, gerenciar e

monitorar os processos. Assim, existe um nvel humano de Inter-Operabilidade ou

Portabilidade que no so abordados por estes Web Services baseados em uma linguagem

de execuo XML.

Empresrios sentem-se bastante confortvel com a visualizao dos processos de negcio em

um formato de fluxograma. Existem milhares de analistas de negcio estudando o modo de

trabalhar e definir processos de negcio com um simples fluxograma. Isto cria um gap tcnico

entre o formato inicial do processo de negcio e o formato das linguagens, como o BPEL4WS,

que iro executar estes processos de negcio. Este gap precisa ser preenchido com um

mecanismo formal que mapeie uma apropriada visualizao dos processos de negcio

(notao) para um apropriado formato de execuo ( uma linguagem de execuo BPM) para

estes processos de negcio.

A inter-operao dos processos de negcio em um nvel humano, e no a nvel de um motor

de software, pode ser resolvido com a padronizao da notao da modelagem dos processos

de negcio (BPMN). BPMN fornece um diagrama de processos de negcio (BPD), no qual um

diagrama desenhado para o uso das pessoas que implementam e gerenciam os processos de

negcio. BPMN prov tambm um mapeamento para uma linguagem de execuo para

sistemas BPM (BPEL4WS). Assim, BPMN proporcionaria um mecanismo de visualizao padro

para processos de negcio definido em uma linguagem de execuo otimizada de processos de

negcio.

BPMN ir prove s empresas uma capacidade de compreender seus procedimentos internos

do negcio em uma notao grfica e ir dar para as organizaes a habilidade de comunicar

estes procedimentos em um padro uniforme. Atualmente, existem pontuaes de

ferramentas de modelagem de processos e metodologias. Dado que os indivduos que iro se

deslocar de uma companhia para outra e que esta companhia ir se fundir e divergir,

provvel que o analista de negcio necessite compreender diversas representaes de

processos de negcio potencialmente diferentes representaes do mesmo processo que se

move atravs do seu ciclo de vida do desenvolvimento, implementao, execuo,

acompanhamento e anlise. Portanto, uma notao grfica padro ir facilitar a compreenso

do desempenho das colaboraes e transaes de negcio dentro e entre as organizaes. Isto

ir assegurar que as empresas participantes iro compreender-se e em seus negcios e

permitir que as organizaes se ajustem as novas circunstncias de negcio internas e B2B

mais rapidamente. Para fazer isto, o BPMN ir seguir a tradicional notao de fluxogramas

para facilitar a leitura, mas ainda fornecer um mapeamento para construes executveis.

BPMI est usando a experincia da notao de processo de negcio que tenham precedido o

BPMN para criar a prxima gerao de notao que combina legibilidade, flexibildade e

expansibilidade.

Nota do blog - Uma das mensagens que o item 7 quer passar que o BPMN est caminhando

para a padronizao de processos na qual todas as empresas iro adotar (at agora est

funcionando muito bem). Com as empresas adotando um padro de modelagem de processo

e este padro forando uma padronizao da linguagem que as executa (BPEL), caso

tivssemos que fazer um B2B, por exemplo, seria menos "difcil" o trabalho.

Lindo!Maravilhoso!Mas pera ai!? Isso no est acontecendo hoje...Ahmn...irei fazer um post

apenas pra explicar o porqu disso. Aguardem!

7.1 - Escopo BPMN

BPMN ir ser constrangido apenas para suportar os conceitos de modelagem que so

aplicveis aos processos de negcio. Isto significa que os outros tipos de modelagem feitos

pelas organizaes para outros propsitos de negcio estaro fora do escopo do BPMN. Por

exemplo, a modelagem a seguir:

Estruturas organizacionais e Recursos

Reparties funcionais

Modelo de dados e informao

Estratgia

Regras de negcio

Dado que estes tipos de modelagem de alto nvel querem direta ou indiretamente afeta os

processos de negcio, as relaes entre o BPMN e as outras modelagens de negcio de alto

nvel iro ser definidas mais formalmente como BPMN e outras especificaes so avanadas.

Alm disso, enquanto o BPMN ir mostrar o fluxo dos dados (mensagens), e a associao dos

artefatos de dados para as atividades, no um diagrama de fluxo de dados.

7.1.1 - Usos do BPMN

A modelagem de processos de negcio usada para comunicar uma ampla variedade de

informaes para uma ampla variedade de audincias. BPMN destina-se a cobrir muitos tipos

de modelagem e permitir a criao de processos de negcio fim-a-fim. Os elementos da

estrutura BPMN iro permitir que quem esteja vendo seja apto a diferenciar facilmente as

sees do diagrama BPMN.

Existem trs tipos bsicos de sub-modelos fim-a-fim BPMN:

Processos de negcio privado (Internos)

Processos abstratos (Pblicos)

Processos de colaborao (Global)

Nota: A terminologia usada para descrever os diferentes tipos de processos ainda no foi

padronizada. Definies destes termos esto em evoluo. H trabalho a ser feito na World

Wide Web Consortium (W3C) e na Organization for the Advancement of Structured

Information Standards (OASIS) que vir consolidar estes termos.

Alguns dos termos da especificao BPMN relativos ao uso das Swimlanes (por exemplo, Pools

e Lanes) so usados nas descries abaixo. Swimlanes (Pools e Lanes) so detalhadas na

seo B.8 da especificao BPMN 1.1.

Processos privados(Internos)

Processos de negcio privado so aqueles internos especficos de uma organizao e so os

tipos de processos que geralmente so chamados de workflow ou processos BPM (ver figura

7.1). Um simples processo de negcio privado deve ser mapeado para um ou mais

documentos BPEL4WS.

Se as swinlanes so usadas, ento os processos de negcio privado estar contido em uma

nica pool. A sequncia do fluxo do processo , por conseguinte, contida na Pool e no

pode atravessar a fronteira da Pool. O fluxo de mensagem pode atravessar a fronteira da

Pool para mostrar as interaes existentes entre os separados processos de negcio

privado.Assim, um nico Diagrama de Processos de Negcio (BPD) deve mostrar diverosos

processos de negcio privado, cada um com um distinto mapeamento para BPEL4WS.

http://1.bp.blogspot.com/_7E5KpEUJ3dI/TVL5hz19ayI/AAAAAAAAABo/5q3B2mM06Bw/s1600/Processo+Privado.jpg

Processos abstrato (Pblicos)

Estes representam a interao entre um processo de negcio privado e outro processo ou

participante (ver figura 7.2). Somente aquelas atividades que so usadas para a comunicao

externa ao processo de negcio privado, mais o mecanismo apropriado de fluxo de controle,

esto includos nos processos abstratos. Todas as outras atividades internas do processo de

negcio privado no so mostradas nos processos abstratos. Assim, os processos abstratos

mostram para o mundo externo a sequncia de mensagens que so requeridas para interagir

com o processo de negcio. Um processo abstrato simples deve ser mapeado para um nico

processo abstrato BPEL4WS (entretanto, este mapeamento no foi finalizado nesta verso

desta especificao).

Processos abstratos esto contidos em uma Pool e podem ser modeladas separadamente ou

em um grande diagrama BPMN para mostrar o fluxo de mensagem entre as atividades do

processo abstrato e outras entidades. Se o processo abstrato est no mesmo diagrama que

seu processo de negcio privado correspondente, ento as atividades que so comuns aos dois

processos podem ser associadas.

Processos de colaborao (Global)

O processo de colaborao retrata as interaes entre duas ou mais entidades. Estas

interaes so definidas como uma seqencia de atividades que representam a troca de

mensagens entre os padres das entidades envolvidas. Um nico processo de colaborao

deve ser mapeado para vrias linguagens de colaborao, como ebXML, BPSS, RosettaNet ou

o resultado da especificao do W3C Choreography Working Group (entretanto, estes

mapeamentos so considerados com direes futuras do BPMN).

O processo de colaborao pode ser visto como dois ou mais processos abstratos

comunicando-se entre eles (ver figura 7.3). Com um processo abstrato, as atividades para os

participantes colaborativos podem ser considerados touch-point entre os participantes. Os

atuais processos (executveis) so suscetveis a terem muito mais atividades e detalhes do que

visto no processo abstrato.

http://4.bp.blogspot.com/_7E5KpEUJ3dI/TVL5sIfn61I/AAAAAAAAABs/PQ6buXKWNf8/s1600/Processo+Abstrato.jpg

Tipos de diagramas BPD

Dentro e entre estes trs sub-modelos BPMN, muitos tipos de digramas podem ser criados. A

seguir esto os tipos de processos de negcio que podem ser modelos com o BPMN (os que

tiverem asterisco no podem ser mapeados para um linguagem de execuo):

Alto-nvel das atividades dos processos privados

Processos de negcio privado detalhados

AS IS ou processos de negcio antigos

TO BE ou processos de negcio novos

Processo de negcios privados detalhados com interaes para um ou mais entidades

externas ( ou processos Black-Box)

Dois ou mais processos privados detalhados se interagindo

Relao detalhada do processo de negcio privado para o Processo abstrato

Relao detalhada do Processo de negcio privado para o Processo colaborativo

Dois ou mais Processos Abstratos

Relao do Processo Abstrato para o Processo Colaborativo

Processo Colaborativo (por exemplo, ebXML, BPSS ou RosettaNet)

Dois ou mais processos de negcio privado detalhados interagindo atravs do seu

Processo Abstrato


Processo Colaborativo


Processo Abstrato e Processo Colaborativo

http://3.bp.blogspot.com/_7E5KpEUJ3dI/TVL55SdFWbI/AAAAAAAAABw/Qar1y6qDKUI/s1600/Processo+de+colabora%25C3%25A7%25C3%25A3o.jpg

O BPMN projetado para atender todos os tipos de diagramas acima. No entanto, bom

alertar que, se muitos tipos de sub-modelos forem combinados, tal com trs ou mais

processos privados com fluxo de mensagem entre eles, ento o diagrama ficar muito difcil

para alguns compreender. Assim, ns recomendamos que o modelador tenha um foco com

propsito para o BPD, tal como o processo privado ou o processo colaborativo.

Mapeamentos BPMN

O BPMN cobre uma ampla viso de uso, ele ir mapear mais do que uma especificao de

linguagem de baixo-nvel:

BPEL4WS so as linguagens primrias que o BPMN ir mapear, mas eles cobrem

apenas um nico processo de negcio privado executvel. Se um diagrama BPMN

retratar mais que um processo de negcio interno, ento haver uma separao de

mapeamento para cada um nos processos de negcio interno.

As sees abstratas de um diagrama BPMN iro ser mapeadas para especificaes de

interfaces de Web services, tal como o processo abstrato do BPEL4WS.

As sees de um modelo colaborativo do BPMN deve ser mapeada para modelos

corporativos como ebXML BPSS, Rosetta-Net, e W3C Choreography Working Group

Specification (Quando tiver finalizada).

Esta especificao ir cobrir apenas o mapeamento para BPEL4WS. Mapeamento para outras

especificaes tero que ter esforos separados, ou talvez seja uma futura direo do BPMN.

7.1.2 - Ponto de vista do diagrama

Desde que o diagrama BPMN retrata os processos de diferentes participantes, cada

participante deve ver o diagrama diferente. Isto , os participantes possuem diferentes pontos

de vista sobre a forma de como os processos so aplicados a eles. Algumas das atividades

sero internas ao participante ( significando realizado por ou sobre controle do participante) e

outras atividades sero externas para o participante. Cada participante ter diferentes

perspectivas quanto o que interno e externo. Na execuo, a diferena entre atividades

internas e externas importante em como o participante pode ver o status das atividades ou

corrigir qualquer problema. No entanto, o diagrama em si permanece o mesmo. A figura 7.3,

mostra um processo de negcio que possui dois pontos de vista. Um ponto de vista o do

paciente, o outro do escritrio do doutor. O diagrama mostra as atividades de ambos os

participantes no processo, mas quando o processo est em andamento, cada participante ter

apenas o controle sobre suas prprias atividades.

Embora o ponto de vista do diagrama seja importante para a pessoa que v o diagrama, para

entender como o comportamento do processo relaciona-se com esta pessoa, o BPMN no ir

especificar em qualquer momento qualquer mecanismo grfico para destacar o ponto de vista.

aberto para o modelador ou vendedor da ferramenta de modelagem para prover qualquer

prova visual para enfatizar esta caracterstica do diagrama.

7.1.3 - Extensibilidade do BPMN e domnios verticais

O BPMN destinado para ser extensvel pelos modeladores e pelas ferramentas de

modelagem. Esta extensibilidade permite o modelador adicionar elementos no padronizados

ou artefatos para satisfazer uma necessidade especfica, por exemplo, os requerimentos

nicos de um domnio vertical. Enquanto extensvel, os digramas BPMN devem ainda ter visual

e sentimentos bsicos para que um diagrama feito por qualquer modelador seja facilmente

compreensvel por qualquer pessoa que veja o diagrama. Assim, o espao de fluxo bsico dos

elementos (Eventos, atividades e Gateways) no deve ser alterado. No devendo adicionar ao

BPD qualquer novo fluxo de elementos, desde que no haja nenhuma especificao de como o

fluxo de seqencia e mensagens sero conectados para qualquer novo fluxo de objeto. Alm

disso, mapeamentos para linguagens de execuo devem ser afetados se um novo fluxo de

elementos forem adicionados. Para satisfazer os conceitos adicionais da modelagem que no

fazem parte do pacote bsico dos fluxos dos elementos, o BPMN prov o conceito de artefatos

que podem ser linkados com fluxo de objetos existentes atravs de associaes. Assim,

artefatos no afetam o fluxo bsico de seqencia e mensagens, nem afetam o mapeamento

para linguagens de execuo.

Os elementos grficos do BPMN so projetados para serem abertos para permitirem

marcadores especializados para transmitir informao especializada. Por exemplo, os trs

tipos de eventos todos possuem centros abertos para os marcadores que padronizam o BPMN,

bem como definidos por usurios marcadores.

8.Diagramas de Processos de Negcio

Este captulo fornece um resumo dos objetos grficos do BPMN e suas relaes. Mais detalhes

sobre seus conceitos sero fornecidas mais adiante.

Um objetivo do desenvolvimento do BPMN que a notao seja simples e adaptativa pelos

analistas de negcio. Alm disso, existe um conflito em potencial de requerimento, que o

BPMN fornece o poder de retratar processos de negcio complexos e mapear para uma

linguagem de execuo BPM. Para ajudar a entender como o BPMN pode gerenciar ambos os

requerimentos, a lista de elementos grficos do BPMN apresentada em dois grupos.

Primeiro, existe a lista dos elementos fundamentais que iro suportar os requisitos de uma

notao simples. Estes so os elementos que definem a viso e sentimento bsicos do BPMN.

A maioria dos processos de negcio ser modelada adequadamente com estes elementos.

Segundo, existe a lista completa dos elementos, incluindo os elementos fundamentais, na qual

iro suportar os requisitos de uma poderosa notao para controlar situaes mais avanadas

de modelagem. E mais, os elementos grficos da notao sero suportados por atributos no

grficos que iro prover as informaes necessrias que faltam para mapear para uma

linguagem de execuo ou outros propsitos de modelagem de negcio.

8.1 Conjunto de elementos bsicos de BPD

Deve-se enfatizar que um dos direcionadores para o desenvolvimento do BPMN criar um

simples mecanismo para criar modelos de processos de negcio, enquanto, em um mesmo

momento seja apto a lidar com a complexidade inerente aos processos de negcio.

A abordagem utilizada para tratar esses dois requisitos conflitantes foi a de organizar os

aspectos grficos da notao em categorias especficas. Isto fornece um pequeno conjunto de

categorias de notaes para que o leitor de um digrama BPMN possa facilmente reconhecer os

tipos bsicos dos elementos e compreender o diagrama.

Dentro da categoria dos elementos bsicos, variaes e informaes adicionais podem ser

adicionadas para suportar os requisitos de complexidade sem mudar drasticamente o visual e

sentimentos bsicos do diagrama.

As quatro categorias bsicas de elementos so:

1. Objetos de Fluxo

2. Objetos de conexo

3. Swimlanes

4. Artefatos

Objetos de fluxo so os principais elementos grficos para definir o comportamento dos

processos de negcio. Existem trs objetos de fluxo:

1. Eventos

2. Atividades

3. Gateways

Existem trs maneiras de conectar o fluxo dos objetos a outro fluxo de objeto ou outra

informao. Existem trs objetos de conexo:

1. Fluxo de sequncia

2. Fluxo de mensagem

3. Associao

Existem duas formas de agrupar os elementos primrios de modelagem atravs das

Swinlanes:

1. Piscinas (Pools)

2. Terrenos (Lanes)

Artefatos so usados para fornecer informao adicional sobre o processo. Existem trs

artefatos padres, mas os modeladores ou as ferramentas de modelagem so livres de

adicionar o quanto de artefatos for necessrio.

Pode haver ainda esforos adicionais de BPMN para padronizar um grande conjunto de

artefatos para um uso geral ou para marcadores verticais. O presente conjunto de artefatos

inclui:

1. Objeto de dado

2. Grupo

3. Anotao

Lista dos principais elementos de modelagem que so retratados pela notao.

8.2 Conjunto completo de elementos BPD

A tabela abaixo apresenta uma lista mais extensa dos conceitos de processos de negcio

retratada atravs da notao de modelagem de processos de negcio.

http://1.bp.blogspot.com/-Tl-_xHGSlgs/TWHCpzY_uhI/AAAAAAAAACc/gIUfTuI-9gc/s1600/principais_elementos.jpg

8.3 Uso do texto, cor, tamanho e linhas no diagrama

Objetos de anotao de textos podem ser usadas pelos modeladores para mostrar informao

adicional sobre o processo ou atributos dos objetos dentro do processo.

Objetos de fluxos DEVEM ter rtulos (exemplo, seu nome e/ou atributos) colocados

dentro da forma, ou sobre ou abaixo da forma, em qualquer direo ou localizao,

dependendo da preferncia do modelador ou da ferramenta de modelagem.

https://lh6.googleusercontent.com/-TAAf4t3UA90/TXlZ1-XJJoI/AAAAAAAAADM/71nul0ja9us/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+IV.jpghttps://lh6.googleusercontent.com/-TAAf4t3UA90/TXlZ1-XJJoI/AAAAAAAAADM/71nul0ja9us/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+IV.jpghttps://lh3.googleusercontent.com/-uOhz0Y9ItEM/TXlZdZ7E-dI/AAAAAAAAADA/tPE-rE51qsE/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+I.jpghttps://lh3.googleusercontent.com/--M7TM_nXQUc/TXlZxZq0pnI/AAAAAAAAADE/UQdyei8alEg/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+II.jpghttps://lh6.googleusercontent.com/-vbg0i8qnyKc/TXlZznLm0DI/AAAAAAAAADI/ZCDWyKbIN2I/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+III.jpghttps://lh6.googleusercontent.com/-TAAf4t3UA90/TXlZ1-XJJoI/AAAAAAAAADM/71nul0ja9us/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+IV.jpghttps://lh6.googleusercontent.com/-Yr4MMO90tgQ/TXlZ7QZfQQI/AAAAAAAAADU/322kZEI7580/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+V.jpghttps://lh6.googleusercontent.com/-Yr4MMO90tgQ/TXlZ7QZfQQI/AAAAAAAAADU/322kZEI7580/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+V.jpghttps://lh3.googleusercontent.com/-u0maihQpygE/TXlZ98vupLI/AAAAAAAAADY/pkwGpsl70Wg/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+VI.jpghttps://lh6.googleusercontent.com/-0yWSkXLnD18/TXlaC09lzkI/AAAAAAAAADc/TaG8M1QxqPY/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+VII.jpghttps://lh4.googleusercontent.com/-uwS6R6VxDJA/TXlaFrL42pI/AAAAAAAAADg/wutuyh0k3Tk/s1600/Conjunto+completo+de+elementos+BPD+-+Parte+VIII.jpg

Os preenchimentos que so usados para os elementos grficos DEVEM ser brancos ou

claros.

A notao PODE SER estendida para usar outros preenchimentos de cores para

algum propsito do modelador ou da ferramenta (por exemplo, realar o valor

de um atributo de um objeto).

Objetos de fluxo e marcadores PODEM SER de qualquer tamanho que se adaptem ao

propsito do modelador ou a ferramenta de modelagem.

As linhas que so usadas para desenhar os elementos grficos DEVEM SER pretas.

A notao PODE SER estendida para usar outras cores de linhas que sejam do

propsito do modelador ou da ferramenta de modelagem.

A notao PODE SER estendida para usar outros estilos de linha para se

adaptar ao propsito do modelador ou ferramenta de modelagem (por

exemplo, realar o valor de um atributo de um objeto) com a condio que o

estilo da linha NO DEVA entrar em conflito com qualquer estilo de linha j

definido no BPMN. Assim, o estilo de linha do fluxo de seqencia, fluxo de

mensagens e associao NO DEVEM ser modificados.

8.4 - Regras de conexo de objetos de fluxo

Uma entrada de sequencia de fluxo pode ser conectada para qualquer lugar em um objeto de

fluxo (esquerda, direita, em cima ou em baixo). Da mesma forma, uma sada de sequncia de

fluxo pode ser conectada de qualquer local em um objeto de fluxo (esquerda, direita, em cima

ou em baixo). O fluxo de mensagens tambm possui esta capacidade. O BPMN permite esta

flexibilidade, entretanto, ns recomendamos que os modeladores usassem um julgamento ou

melhores prticas de como os objetos de fluxo devem ser conectados para que os leitores do

diagrama achem o comportamento claro e fcil de seguir. Isto mais importante, quando o

diagrama contm fluxo de sequncia e fluxo de mensagens. Nestas situaes o melhor pegar

a direo do fluxo de sequencia, quer da esquerda para direita ou de cima para baixo e ento

direcionar o fluxo de mensagem num anglo de 90 do fluxo de sequencia. O diagrama

resultante ser muito mais fcil de compreender.

8.4.1 - Regras do fluxo de sequencia

A tabela abaixo apresenta os objetos de fluxo BPMN e mostra como estes objetos podem

conectar-se uns aos outros atravs do fluxo de sequencia. O smbolo indica que o objeto

listado na linha pode ser conectar com o objeto listado na coluna. A quantidade de conexes

dentro e fora de um objeto sujeito a vrias configuraes de dependncia que no esto

especificadas aqui. Cada objeto ser detalhado individualmente mais adiante com as

informaes apropriadas de regras de conexes. Note que se um sub-processo tenha se

expandido dentro do diagrama, os objetos dentro do sub-processo no podem ser conectados

https://lh4.googleusercontent.com/-8Iqoe47I4Ms/TXlgUEwuz4I/AAAAAAAAADs/4-BY1faxMJc/s1600/Seta.jpg

com objetos fora do sub-processo. O fluxo de seqencia tambm no pode atravessar a

fronteira da Pool.

Nota: Somente os objetos que podem ter entrada e/ou sada do fluxo de sequencia so

mostrados na tabela. Assim, Pool, Lane, Data Object e Text Annotation no esto listados na

tabela.

8.4.2 - Regras do fluxo de mensagens

A tabela abaixo apresenta os objetos de fluxo BPMN e mostra como estes objetos podem

conectar-se uns aos outros atravs do fluxo de sequencia. O smbolo indica que o objeto

listado na linha pode ser conectar com o objeto listado na coluna. A quantidade de conexes

dentro e fora de um objeto sujeito a vrias configuraes de dependncia que no esto

especificadas aqui. Cada objeto ser detalhado individualmente mais adiante com as

informaes apropriadas de regras de conexes. Note que o fluxo de mensagem no pode-se

conectar a objetos que esto dentro da mesma Pool.

Nota: Somente os objetos que podem ter entrada e/ou sada do fluxo de mensagens so

mostrados na tabela. Assim, Lane, Gateway, Data Object e Text Annotation no esto listados

na tabela.

8.5 - Atributos do diagrama de Processos de Negcio

A tabela a seguir mostra o conjunto de atributos de um diagrama de processos de negcio

(BPD):

https://lh6.googleusercontent.com/-fW8_emfQ7aw/TXlfpZj_c3I/AAAAAAAAADk/jweLJ3AO1Yg/s1600/Regras+do+fluxo+de+sequencia.jpghttps://lh5.googleusercontent.com/-Wu_scoJF41E/TXljBzos8TI/AAAAAAAAAD4/paZY1HtMOAw/s1600/seta2.jpghttps://lh4.googleusercontent.com/-S1h9_dLQ5pM/TXlhyWIVi9I/AAAAAAAAADw/IWnRSVTSnWg/s1600/Regras+do+fluxo+de+mensagem.jpg

8.6 - Processos

Um processo uma atividade realizada dentro ou entre as empresas e organizaes. No BPMN

um processo retratado como um grfico de fluxo de objetos, na qual so um conjunto de

outras atividades e os controles que o sequncia. O conceito de processo intrinsecamente

hierrquico. Processos devem ser definidos em qualquer nvel, do processo como todo da

empresa a um processo realizado por uma nica pessoa. Processos de baixo nvel devem ser

agrupados em conjunto para alcanar um objetivo de negcio em comum.

Note que o BPMN define o termo processo bastante especfico e define processo de negcio

mais genrico como um conjunto de atividades que so realizadas por uma organizao ou

entre organizaes. Assim, cada processo de negcio pode ter seus prprios sub-processos e

devem estar contidos em uma Pool. Os processos individuais seriam independentes em

termos de fluxo de sequencia, mas pode ter um fluxo de mensagem os conectando.

8.6.1 - Atributos

A tabela a seguir apresenta o conjunto de atributos de um processo, e que estende o conjunto

comum de atributos dos elementos BPMN:

http://3.bp.blogspot.com/-oAXhksvRPys/TaHwjN4KhiI/AAAAAAAAAEg/wDGaY-Yn0sY/s1600/Atributos+do+diagrama+de+Processos+de+Neg%25C3%25B3cio.jpg

http://3.bp.blogspot.com/--8zj-AeiOLM/TaH0SDHnM_I/AAAAAAAAAEk/ZBOzeaNIgB4/s1600/Atributos+-+Parte+I.pnghttp://2.bp.blogspot.com/-731p1xd5I_0/TaH0SpM3f-I/AAAAAAAAAEo/i7x6LA851HI/s1600/Atributos+-+Parte+II.png

9. Objetos Grficos do diagrama de processos de negcio (BPD)

Esta seo detalha a representao grfica e de semntica do comportamento dos elementos

grficos do diagrama de processos de negcio. Consulte Mapeando para BPEL4WS para mais

informaes sobre como estes elementos so mapeados para linguagens de execuo.

9.2 - Atributos comuns dos objetos de fluxo

A tabela a seguir apresenta um conjunto de atributos comuns para os objetos de fluxo BPMN

(Eventos, Atividades e Gateways) e que se estende ao conjunto comum dos atributos dos

elementos BPMN.

http://4.bp.blogspot.com/-LDsgHngSHCc/TaH0TK90SbI/AAAAAAAAAEs/sqR-qlnnMPs/s1600/Atributos+-+Parte+III.pnghttp://2.bp.blogspot.com/-V9syiPHvYbg/TfoM6blxnCI/AAAAAAAAAE0/l5W61zYvTz8/s1600/Atributos+comuns+dos+Elementos+BPMN.jpg

9.3 - Eventos

Um evento algo que acontece durante o curso de um processo de negcio. Estes eventos

afetam o fluxo do processo e normalmente possuem uma causa ou impacto. O termo Evento

geralmente suficiente para cobrir muitas coisas em um processo de negcio. O comeo de

uma atividade, o fim de uma atividade, a mudana de estado de um documento, uma

mensagem que chega, etc., todos eles poderiam ser considerados eventos.

Entretanto, o BPMN restrito ao uso de eventos para incluir somente aqueles tipos de eventos

que iro afetar a sequencia ou o tempo das atividades do processo. O BPMN ainda categoriza

os eventos em trs tipos principais: Inicial, Intermedirio e Final.

Os eventos Inicial e intermedirios possuem acionadores que definem a causa do evento.

Existe diversas maneira de estes eventos serem acionados, que sero vistos mais adiante. O

evento final deve definir o resultado que a consequncia do final do fluxo de sequncia.

Existem diversos tipos de resultados que podem ser definidos.

Todos os eventos compartilham a mesma forma, um pequeno crculo. Diferentes estilos de

linha distinguem os trs tipos de fluxo de eventos. Todos os eventos tambm possuem um

centro aberto para que o modelador possa adicionar cones dentro de sua forma para ajudar a

identificar o acionador ou resultado do evento.

9.3.1 - Atributos comuns dos eventos

A tabela a seguir apresenta o conjunto de atributos comuns dos trs tipos de eventos, e que se

estende ao conjunto de atributos comuns dos fluxos de objetos.

http://3.bp.blogspot.com/-HPcfqN6iPsI/TfoNDfmkGlI/AAAAAAAAAE4/AasCfRdPrNw/s1600/Atributos+comuns+dos+objetos+de+fluxo.jpghttp://2.bp.blogspot.com/-Hkcn_JzHCOs/TfoPIkMqo1I/AAAAAAAAAFA/tI_9a_oCSGA/s1600/Atributos+comuns+dos+eventos.jpg

9.3.2 - Inicial

Como o nome diz, o evento inicial indica quando um processo em particular ir comear. Em

termos de fluxo de sequncia, o evento inicial inicia o fluxo do processo, e assim, no ter

qualquer fluxo de sequncia chegando- nenhum fluxo de sequncia pode conectar-se a um

evento inicial.

O evento inicial compartilha a mesma forma bsica dos eventos intermedirios e finais, um

crculo com um centro aberto para que marcadores possam ser colocados dentro do crculo

para indicar as variaes dos eventos.

Um evento inicial um crculo que TEM QUE SER desenhado com uma nica linha

fina .

O uso do texto, cor, tamanho e linhas do evento inicial TM QUE seguir as regras

definidas na seo 3.3.

A espessura da linha TEM QUE permanecer fina para que o evento inicial possa ser

distinguido dos eventos intermedirios e finais.

Atravs deste documento, ns iremos discutir como o fluxo de sequncia procede dentro de

um processo. Para facilitar esta discusso, ns iremos empregar um conceito de um Token

que ir atravessar o fluxo de seqencia e passar atravs do fluxo dos objetos no processo. O

comportamento do processo pode ser descrito rastreando-se o(s) caminho(s) do Token atravs

do processo. O Token ir possuir um nico identificador, chamado de TokenId set, que pode

ser usado para distinguir mltiplos Tokens que possam existir por causa das instncias dos

processos concorrentes ou da diviso do Token para o processamento paralelo dentro de uma

instncia nica de processo. A diviso paralela do Token cria um nvel mais baixo do TokenId

set. O conjunto de todos os nveis de TokenId ir identificar o Token.

Um evento inicial gera um Token que tem ser eventualmente consumido no evento final ( que

pode estar implcito, se no mostrado graficamente). O caminho dos Tokens devem ser

rastreveis atravs da rede do fluxo de seqencia, Gateways e atividades dentro do processo.

NO DEVE haver nenhum fluxo implcito durante o percurso normal do fluxo de sequncia (ou

seja, deve haver sempre fluxo de sequncia ou indicadores grficos, tal como um evento

intermedirio para mostrar todos os potenciais caminhos dos Tokens). Um exemplo de um

fluxo implcito quando um Token chega a um gateway, mas nenhum dos Gates so vlidos, o

Token ir ento (implicitamente) passar para o final do processo, que ocorre com algumas

notaes de modelagem. Tokens tambm podem ser direcionados atravs de controles de

exceo de eventos intermedirios, que atua como um final forado para uma atividade.

http://www.blogger.com/blogger.g?blogID=2422148690549936520http://4.bp.blogspot.com/-jwgEqI0BqLQ/TfoO9JVVYiI/AAAAAAAAAE8/1T6dyTaURks/s1600/Evento.jpg

NOTA: Um token no pode atravessar o fluxo de mensagem desde que seja uma mensagem

que passada para baixo destes fluxos (como o nome implica).

As semnticas de um evento inicial incluem:

Um evento inicial OPCIONAL: em nvel de processo um processo de alto-nvel ou

um sub-processo expandido DEVE (no obrigado) ter um evento inicial.

NOTA: Um BPD deve ter mais de um nvel de processos (ou seja, ele pode incluir sub-processos

expandidos). O uso de eventos iniciais e finais independente para cada nvel do diagrama.

Se um processo complexo e/ou as condies iniciais no so bvias, ento

RECOMENDADO que um evento inicial seja usado.

Se existir um evento inicial, ento TEM QUE TER pelo menos um evento final.

Se o evento final usado, ento NO TEM QUE TER outros elementos de fluxo que no

possuem chegadas de fluxo de sequncia todos os outros fluxos de objetos TM QUE

SER um alvo para pelo menos um fluxo de sequncia.

Excees a isto so as atividades que so definidas como serem atividades de

compensao (possuem o marcador de compensao). Atividades de compensao

NO PODEM TER qualquer entrada de fluxo de sequncia, mesmo se existir um evento

inicial no nvel do processo.

Uma exceo para isto o evento intermedirio, que PODE SER sem entrada de fluxo

de sequncia.

Se o evento inicial no usado, ento todos os fluxos de objetos que no possuem

entradas de fluxo de sequncia (ou seja, no so um alvo de um fluxo de sequncia)

DEVEM SER instanciados quando o processo instanciado. Existe um pressuposto que

existe apenas um evento inicial implcito, significando que todos os fluxos de objetos

iniciais iro comear em um mesmo momento.

Excees a isto so as atividades que so definidas como serem atividades de


no so consideradas uma parte do fluxo normal e NO DEVEM SER instanciadas

quando o processo instanciado.

PODE HAVER mltiplos eventos iniciais para um determinado nvel de processo.

Cada evento inicial um evento independente. Isto , uma instncia de processo DEVE

SER gerada quando o evento inicial acionado.

NOTA: O comportamento do processo deve ser complicado de compreender se existirem

diversos eventos iniciais. RECOMENDADO que este recurso seja usado com parcimnia e que

o modelador seja cuidadoso porque os outros leitores do diagrama podero ter dificuldades

em compreender a inteno do diagrama.

Quando o acionador do evento inicial ocorre, Tokens sero gerados para cada sada do fluxo

de sequencia daquele evento. O TokenId set para cada Token ser estabelecido de modo que

possa ser identificado que os Tokens so todos de uma mesma diviso paralela (AND-Split) e o

nmero de Tokens no grupo. Estes Tokens iro comear seus fluxos e no iro esperar por

qualquer outro evento inicial ser disparado.

Se existir uma dependncia para mais de um evento que pode acontecer antes do processo

comear (por exemplo, duas mensagens so necessrias para comear), ento os eventos

iniciais devem seguir para a mesma atividade dentro do processo. Os atributos da atividade

iro especificar quando a atividade poder comear. Se os atributos especificarem que a

atividade deve esperar por todos os insumos, ento todos os eventos iniciais devero ser

acionados antes de o processo comear. Alm disso, um mecanismo de correlao ser

requerido para que diferentes eventos iniciais acionados sejam aplicados para a mesma

instncia do processo. Correlao provavelmente ser tratada atravs dos atributos dos

eventos, mas isto uma questo que ser abordada em outra verso da especificao.

Acionadores dos Eventos Iniciais

Existem muitas maneiras de um processo de negcio ser iniciado (instanciado). O acionador de

um evento inicial projetado para mostrar o mecanismo geral que ir instanciar o processo

em particular. Existem seis tipos de eventos iniciais no BPMN: None, Message, Timer, Rule,

Link e Multiple (Nenhum, Mensagem, Tempo, Regra, Ligao e Mltiplo).

Atributos

A tabela a seguir apresenta o conjunto de atributos do evento inicial, no qual se estende do

conjunto dos atributos em comuns dos eventos:

http://2.bp.blogspot.com/-tAfSM2JSAuk/TfoSc0egokI/AAAAAAAAAFE/vilHHb0jT7E/s1600/Acionadores+dos+eventos+iniciais.jpg

Conexes do Fluxo de sequncia

Refere-se seo 3.4.1 intitulada de Regras do fluxo de sequncia para todo o conjunto de

objetos e como eles podem fontes ou alvos do fluxo de sequncia.

Um evento inicial NO DEVE ser alvo de um fluxo de sequncia; ele NO DEVE TER

entradas de fluxo de sequncia.

Uma exceo a isto quando um evento inicial usado em um sub-processo

expandido e ligado regio limite do sub-processo. Neste caso, um fluxo de

sequncia do mais alto nvel do processo DEVE conectar a este evento inicial em vez

de conectar a regio de limite atual do sub-processo.

Um evento inicial DEVE ser a fonte para o fluxo de sequncia.

http://3.bp.blogspot.com/-Leeu1GlVNhM/TfoUvAvMlYI/AAAAAAAAAFI/jviwCk-94RI/s1600/01+-+Atributos+dos+eventos+iniciais.jpghttp://1.bp.blogspot.com/-Z6Ecq2mXll8/TfoUwkl8mGI/AAAAAAAAAFM/-i0tky8EIq4/s1600/02+-+Atributos+dos+eventos+iniciais.jpg

Mltiplos fluxos de sequncia DEVEM originar-se de um evento inicial. Para cada fluxo

de sequncia que possui um evento inicial como fonte, um novo caminho paralelo

DEVE SER gerado.

O atributo de condio para todas as sadas do fluxo de sequncia TEM QUE SER

definido como None.

Quando um evento inicial no usado, ento todos os objetos de fluxo que no

possuem entradas de fluxo de sequncia DEVEM SER o comeo de um caminho

paralelo separado.

Cada caminho ir possuir um Token nico que ir atravessar o fluxo de sequncia.

Conexes do fluxo de mensagens

Refere-se seo 3.4.2 intitulada Regras do fluxo de mensagem para todo o conjunto de

objetos e como eles podem ser a fonte ou alvo do fluxo de mensagens.

NOTA: Todos os fluxos de mensagem devem conectar duas Pools separadas. Eles podem

conectar a fronteira da Pool ou para os objetos de fluxo dentro da fronteira da Pool. Eles no

podem conectar dois objetos dentro da mesma Pool.

Um evento inicial PODE SER o alvo de um fluxo de mensagem; ele pode ter 0 (zero) ou

mais entradas de fluxo de mensagem. Cada fluxo de mensagem chegando no evento

inicial representa um mecanismo de instanciao (um acionador) para o processo.

Somente um dos acionadores requerido para comear um novo processo.

O atributo Trigger do evento inicial TEM QUE SER definido como Message ou

Multiple se existir alguma entrada de fluxo de mensagem.

O atributo Trigger do evento inicial TEM QUE SER definido como Multiple se existir

mais de um entrada de fluxo de mensagem.

Um evento inicial NO DEVE SER uma fonte de fluxo de mensagem; ele NO PODE ter

sadas de fluxo de mensagem.

9.3.3 - Final

Como o nome implica, o evento final indica onde o processo termina. Em termos de fluxo de

sequencia, o evento final termina o fluxo do processo, e assim, no ir ter qualquer sada de

fluxo de sequencia - nenhum fluxo de sequncia pode ser conectado a partir de um evento

final.

O evento final compartilha a mesma forma bsica do evento inicial e intermedirio, um crculo

com um centro aberto para que marcadores possam ser colocados dentro do crculo indicando

as variaes do evento.

Um evento final um crculo que TEM QUE SER desenhado com uma nica linha

preta fina.

O uso de texto, cor, tamanho e linhas do evento final TM QUE seguir as regras

definidas na seo 3.3.

A espessura da linha TEM QUE permanecer espessa para que o evento final possa

ser distinguido dos eventos intermedirios e iniciais.

Para continuar a discusso de como o fluxo procede atravs do processo, um evento final

consume um Token que foi gerado pelo evento inicial dentro do mesmo nvel do processo. Se

um fluxo de sequncia paralelo tiver como alvo um evento final, ento os Tokens sero

consumidos quando chegarem. Todos os Tokens que foram gerados dentro do processo tm

que ser consumidos pelo evento final antes do processo ter terminado. Em outras

circunstncias, se o processo for um sub-processo, ele pode ser interrompido antes da

concluso normal atravs de eventos intermedirios de exceo (consulte a seo 5.2.2

intitulada como fluxo de exceo). Nesta situao os Tokens sero consumidos por um

evento intermedirio anexado a fronteira do sub-processo.

As semnticas do evento final incluem:

PODE haver mltiplos eventos finais dentro de um nico nvel de processo.

Esta forma OPCIONAL: um determinado nvel de processo um processo de nvel

alto ou um sub-processo expandido PODE (no preciso) ter esta forma:

Se existir um evento inicial, ento TEM que ter pelo menos um evento final.

Se um evento final usado, ento NO PODE haver outros elementos de fluxo que

no possuem sada de fluxo de sequncia todos os outros objetos de fluxo TM que

ser a fonte de pelo menos um fluxo de sequncia.

Excees a isto so as atividades que so definidas como sendo atividades de


NO PODEM ter qualquer sada de fluxo de sequncia, mesmo se existir um evento

final no nvel do processo. Consulte a seo 5.3 intitulada de Associao de

Compensao.

Se o evento final no for usado, ento todos os objetos de fluxo que no possuem

sada de fluxo de sequncia (ou seja, no a fonte do fluxo de sequncia) marcam o

http://3.bp.blogspot.com/-zUhAP2rBx5I/TfoWzDJ0dsI/AAAAAAAAAFQ/PlF9fAdZ6Kc/s1600/Evento+Final.jpg

final do caminho do processo. Portanto, o processo NO PODE terminar enquanto

todos os caminhos paralelos forem completados.

Excees a isto so as atividades que so definidas como atividades de compensao

(possuem o marcador de compensao). Atividades de compensao no so

consideradas uma parte do fluxo normal e NO PODEM marcar o final do processo.

NOTA: Um BPD pode ter mais de um nvel de processo (ou seja, pode incluir sub-processos

expandidos). O uso dos eventos iniciais e finais independente para cada nvel do diagrama.

Para processos que no possuem o evento final, um Token ser consumido quando o

processamento realizado pelos objetos completado (ou seja, quando o caminho tiver

terminado), como se o Token fosse embora quando chegasse ao evento final. Quando todos os

Tokens de uma determinada instncia do processo so consumidos ento o processo ir

chegar a um estado de estar concludo.

Resultados de um evento final

Um modelador BPMN pode definir a consequncia de chegar a um evento final. Este ser

designado como resultado de um evento final. A tabela abaixo apresenta os tipos de

resultados e o marcador grfico que ser usado para cada um:

http://3.bp.blogspot.com/-7LVqH6ETf-E/TfoY4Oo2tNI/AAAAAAAAAFU/pQrcDIkImpg/s1600/01+-+Resultados+dos+eventos+finais.jpg

Atributos

A tabela a seguir apresenta o conjunto de atributos de um evento final, que se estende do

conjunto comum de atributos de eventos:

http://2.bp.blogspot.com/-mg4xmShnVYA/TfoY5FL4tgI/AAAAAAAAAFY/4nuqkdDkHak/s1600/02+-+Resultados+dos+eventos+finais.jpghttp://3.bp.blogspot.com/-YKIpdwhrtDo/TfoZ2Ih-rRI/AAAAAAAAAFc/Rkb2DuDHPe0/s1600/01+-+Atributos+dos+eventos+finais.jpghttp://1.bp.blogspot.com/-bwE0LtvtR3I/TfoZ3ZafRII/AAAAAAAAAFg/tkHn_Owwh0Q/s1600/02+-+Atributos+dos+eventos+finais.jpg

Conexes do fluxo de sequncia

Consulte a seo 3.4.1 intitulada de Regras do fluxo de sequncia para o conjunto completo

de objetos e como eles podem ser fontes ou alvos de um fluxo de sequncia.

Um evento final TEM que ser um alvo de um fluxo de sequncia.

Um evento final PODE ter mltiplas entradas de fluxo sequncia.

O fluxo PODE vir de qualquer caminho alternativo ou paralelo. Para uma questo de

convenincia na modelagem, cada caminho DEVE conectar um objeto de evento final

separado. O evento final usado como o consumidor para todos os Tokens que chegam ao

evento final. Todos os Tokens que so gerados no evento inicial de um processo tm que

eventualmente chegar ao evento final. O processo ficar em um estado correndo enquanto

todos os Tokens no forem consumidos.

Um evento final NO PODE ser a fonte de um fluxo de sequncia; ou seja, NO PODE

haver um fluxo de sequncia de sada do evento final.

Uma exceo a isto quando um evento final usado em um sub-processo expandido

e acoplado fronteira deste sub-processo. Neste caso, o fluxo de sequncia do

processo de nvel mais alto DEVE ser conectado pelo evento final ao invs de ser

conectado pela fronteira atual do sub-processo.


Consulte a seo 3.4.2 intitulada de Regras do fluxo de mensagens para o conjunto completo

de objetos e como eles podem ser fontes ou alvos de um fluxo de mensagem.

NOTA: Todos os fluxos de mensagens tm que conectar duas Pools separadas. Eles podem

conectar a fronteira da Pool ou aos objetos dentro da fronteira da pool. Eles no podem

conectar dois objetos dentro da mesma Pool.

Um evento final NO TEM que ser um alvo de um fluxo de mensagem; Ele pode no

receber nenhum fluxo de mensagem de sada.

Um evento final DEVE ser a fonte de fluxo de mensagem; Ele pode ter um ou mais

sadas de fluxo de mensagens.

9.3.4 - Intermedirio

Eventos intermedirios ocorrem entre o Evento inicial e o evento final. Este um evento que

ocorre depois do processo ser iniciado. Ele ir afetar o fluxo do processo, mas no ir iniciar

(diretamente) ou finalizar o processo. Eventos intermedirios podem ser usados como:

Mostrar onde as mensagens so esperadas ou enviadas dentro do Processo,

Apresentar os atrasos esperados dentro do processo,

Romper o fluxo normal atravs do controle de exceo, ou

Mostrar o trabalho extra requerido para a compensao.

O evento intermedirio compartilha a mesma forma bsica do evento inicial e evento final, um

crculo com um centro aberto para que os marcadores possam ser colocados dentro do crculo

para indicar as variaes do evento.

Um evento intermedirio um crculo que TEM QUE ser desenhado com uma dupla

linha fina preta.

O uso de texto, cor, tamanho e linhas para um evento intermedirio TM que seguir as

regras definidas na seo 3.3 com a exceo de:

A espessura da linha TEM que permanecer dupla para que o evento intermedirio

possa ser distinguido dos eventos iniciais e dos eventos finais.

Um dos usos dos eventos intermedirios representar o controle de exceo ou de

compensao. Isto ser demonstrado colocando o evento intermedirio na fronteira da tarefa

ou do sub-processo (mesmo expandido ou no). A figura abaixo apresenta um exemplo de um

evento intermedirio acoplado tarefa. O evento intermedirio pode ser acoplado em

qualquer lugar da fronteira da atividade e a sada do fluxo de sequncia poder seguir para

qualquer direo. No entanto, em interesse para que o diagrama fique mais claro, ns

recomendamos que o modelador escolhesse uma localizao consistente sobre a fronteira. Por

exemplo, se a orientao do diagrama horizontal, ento o evento intermedirio pode ser

acoplado em baixo da atividade e o fluxo de sequncia direcionado para baixo e ento para

direita. Se a orientao do diagrama for vertical, ento o evento intermedirio pode ser

acoplado no lado esquerdo ou direito da atividade e o fluxo de sequncia direto para esquerda

ou direita e ento para baixo.

http://4.bp.blogspot.com/-CaabNWhvpBk/Tfobut1KWXI/AAAAAAAAAFk/Sx1F3zX5I1A/s1600/Evento+Intermedi%25C3%25A1rio.jpg

Acionadores dos eventos intermedirios

Existem oito tipos de eventos intermedirios no BPMN: Message, Timer, Error, Compensation,

Cancel, Rule, Link e Multiple. Estes tipos de eventos indicam as diferentes maneiras que um

processo pode ser interrompido ou atrasado depois que ele comeou. Cada tipo de evento

intermedirio ir possuir um cone diferente colocado no centro da forma do evento

intermedirio para distinguir-se dos outros.

A tabela abaixo apresenta os tipos de acionadores e os marcadores grficos que sero

utilizados para cada um:

http://4.bp.blogspot.com/-3oSQ6SxM7n0/TfocXUDuYQI/AAAAAAAAAFo/TDCdHTTXV74/s1600/Exemplo+de+controle+de+exce%25C3%25A7%25C3%25A3o.jpghttp://3.bp.blogspot.com/-D2b50DQrIaY/TfoddUbt16I/AAAAAAAAAFw/0B5mXhbKqKg/s1600/01+-+Acionadores+dos+eventos+intermedi%25C3%25A1rios.jpg

Atributos

A tabela a seguir apresenta o conjunto de atributos de um evento intermedirio, na qual se

estende do conjunto comum de atributos dos eventos:

http://3.bp.blogspot.com/-Lgic2yX_Lfc/TfodZBuuvOI/AAAAAAAAAFs/QK5DkmtdpiY/s1600/02+-+Acionadores+dos+eventos+intermedi%25C3%25A1rios.jpghttp://2.bp.blogspot.com/-jpeTTxGuCaU/TfoemumGTcI/AAAAAAAAAF0/0qmF1CfWQZ4/s1600/01+-+Atributos+dos+eventos+intermedi%25C3%25A1rios.jpg

Conexes na fronteira da atividade

Um evento intermedirio pode ser acoplado fronteira de uma atividade, nas seguintes

condies:

(Um ou mais) Eventos intermedirios PODEM ser acoplados diretamente a fronteira de

uma atividade.

Para acoplar a fronteira de uma atividade, um evento intermedirio TEM que ser um

dos seguintes acionadores: Message, Timer, Error, Cancel, Compensation, Rule e

Multiple.

http://4.bp.blogspot.com/-q0neCOekoAo/Tfoenj1BRnI/AAAAAAAAAF4/R9fsQFa2Drw/s1600/02+-+Atributos+dos+eventos+intermedi%25C3%25A1rios.jpghttp://3.bp.blogspot.com/-850Ge32Q6ZQ/TfoepD26wtI/AAAAAAAAAF8/I_kuundnZ3E/s1600/03+-+Atributos+dos+eventos+intermedi%25C3%25A1rios.jpg

Um evento intermedirio com um acionador Cancel PODE ser acoplado a fronteira

do sub-processo somente se o atributo Transaction do sub-processo estiver definido

como verdadeiro.

Conexes do fluxo de sequncia

Consulte a seo 3.4.1 intitulada de Regras do fluxo de sequncia para o conjunto completo

dos objetos e como eles podem ser a fonte ou alvo do fluxo de sequncia.

Os seguintes eventos intermedirios PODEM ser acoplados a fronteira de uma

atividade: Message, Timer, Exception, Cancel (somente sub-processos que so

transaes), Compensation, Rule e Multiple. Assim, os seguintes NO PODEM: None e

Link.

Se o evento intermedirio acoplado a fronteira de uma atividade:

O evento intermedirio NO PODE ser um alvo de um fluxo de sequncia; Ele no

pode ter nenhum fluxo de sequncia de entrada.

O evento intermedirio TEM que ser a fonte do fluxo de sequncia; Ele pode ter um (e

somente um) fluxo de sequncia de sada.

Uma exceo a isto: um evento intermedirio com o acionador Compensation NO

PODE ter sada de fluxo de sequncia ( ele PODE ter uma sada de compensao).

Os seguintes eventos intermedirios PODEM ser usados no fluxo normal: None,

Message, Timer, Exception, Compensation, Rule e Link. Assim, os seguintes NO

PODEM: Cancel e Multiple.

Se o evento intermedirio usado dentro do fluxo normal:

Os eventos intermedirios dos seguintes tipos TEM QUE ser um alvo de um fluxo de

sequncia: None, Error e Compensation. Ele TEM que ter um (e somente um) fluxo de

entrada.

NOTA: Estes tipos de eventos intermedirios iro sempre estar prontos para aceitar o

acionador do evento enquanto o processo no qual eles esto contidos ativado.

Um evento intermedirio TEM que ser a fonte de um fluxo de sequncia; ele TEM que

ter um (e somente um) fluxo de sequncia de sada.

Uma exceo a isto: a fonte de um evento intermedirio do tipo Link (como definido

anteriormente), no obrigado a ter um fluxo de sequncia de sada.

Um evento intermedirio com um acionador Link NO PODE ser um alvo e uma

fonte ao mesmo tempo de um fluxo de sequncia a menos que seja parte de um

gateway exclusivo baseado em evento.

Para definir o uso de um evento intermedirio do tipo Link como um objeto Off-Page

Connector ou Go To:

Um evento intermedirio do tipo Link PODE ser um algo (Target Link) ou a fonte

(Source Link) de um fluxo de sequncia, mas NO PODE ser um alvo e uma fonte ao

mesmo tempo.

Se existe um Source Link, deve haver um Target Link correspondente (eles

possuem o mesmo LinkId). NOTA: Um source link (evento intermedirio) no deve ser

usado para interligar com outro processo dentro da mesma Pool; um evento final deve

ser usado para este propsito.

PODE haver vrios Source Links para um nico Target Link.

NO PODE haver vrios Target Links para um nico Source Link.

Um Target Link PODE ser usado sem um Source Link correspondente. Isto indica

que o Source Link (e o evento final) existe em um outro processo dentro da mesma

Pool.


Consulte a seo intitulada 3.4.2 de Regras do fluxo de mensagens para o conjunto completo

dos objetos e como eles so fontes ou alvos do fluxo de mensagem.

NOTA: Todos os fluxos de mensagens tm que conectar duas pools separadas. Eles podem

conectar-se a fronteira da pool ou nos objetos de fluxo dentro da fronteira da pool. Eles no

podem conectar dois objetos dentro da mesma Pool.

Um evento intermedirio do tipo Message DEVE ser alvo de um fluxo de mensagem;

ele pode ter uma entrada de fluxo de mensagem.

Um evento intermedirio NO PODE ser a fonte de um fluxo de mensagem; ele no

pode ter fluxo de mensagem de sada.

Fonte: http://www.tudosobrebpm.com.br/p/bpmn-business-process-modeling-notation.html

Edio: Elder Menezes [email protected]

http://www.tudosobrebpm.com.br/p/bpmn-business-process-modeling-notation.html

Documents

BPMN - Business Process Modeling Notation