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
Dois ou mais processos de negcio privado detalhados interagindo atravs do seu
Processo Colaborativo
Dois ou mais processos de negcio privado detalhados interagindo atravs do seu
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
compensao (possuem o marcador de compensao). Atividades de compensao
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
compensao (possuem o marcador de compensao). Atividades de compensao
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.
Conexes do fluxo de mensagens
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.
Conexes do fluxo de mensagens
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
Top Related