Copyright @ 2008 by Editora PortalBPM ltda.

Direitos desta edio reservados a

Editora PortalBPM ltda
Av. Sta Catarina, 1396 sala 4
CEP : 04367-050
Impresso no Brasil por HR Grfica

Proibida a reproduo, total ou parcial, por qualquer meio ou processso,
Seja fotogrfico, grfico ou microfilmagem etc.
Estas proibies aplicam-se tambm nas caractersticas grficas e/ou
editoriais.
A violao dos direitos editoriais punvel como crime (Cdigo penal,
art 184, Lei 6.895/80), com busca, apreenso e indenizaes diversas
(Lei 9610/98 Lei dos direitos autorais arts. 122, 123, 124 e 126)
Reis, Glauco dos Santos
Modelagem de processos de negcios com BPMN Curso completo /
Glauco S. Reis;
Reviso tcnica equipe PortalBPM
So Paulo; Editora PortalBPM ltda; 2008
1. Modelagem de processos de negcios 2.BPMN 3.BPMS
Prefcio
Estamos vivenciando um perodo de mudanas profundas, em
reas de conhecimento distintas como processos para desen-
volvimento de sistemas e gesto empresarial.
Toda uma nova gama de conceitos e ferramentas esto sen-
do apresentadas e defnidas, e que provavelmente devero
nortear o futuro da TI nos prximos anos.
Um destes conceitos, e provavelmente o que gera a maior
concordncia entre os especialistas a notao BPMN.
A sigla BPMN o acrnimo de Business Process Modeling
Notation, ou notao para modelagem de processos de
negcios.
Embora quase no exista discordncia quanto efetividade
do padro, as documentaes so limitadas e a especifcao
ofcial densa e intrincada.
A proposta deste livro explorar a notao BPMN, como
descrita na especifcao ofcial, sem as particularidades
introduzidas por cada fabricante.
Toda a simbologia ser explorada, e estaremos fornecendo
interpretao para cada smbolo, erros comuns no desenho,
alm de discutirmos um pouco sobre mapeamento de proces-
sos e design patterns aplicados notao.
Espero que voc aproveite a leitura, e que muitas das
dvidas possam ser sanadas ao longo do livro.
Glauco Reis
glauco@portalbpm.com.br
Sumrio
1 - Prefcio
2 - Ferramentas BPMS - 06
2.1- Workfows - 06
2.2 - BPMN - 07
2.3 - BPEL - 08
2.4 - SOA e Web Services - 09
2.5 - Dashboards - 10
2.6 - Realinhamento dos processos de negcios - 11
2.7 - Business Process Management Systems - 11
2.8 - Pure players - 15
2.9 - BPMN e Futuro - 15
3 - Processos - 16
3.1 - UML e BPMN - 16
4 - Tipos de diagramas BPMN - 18
5 - Pools e Lanes - 20
5.1 - Instncias de processos - 21
6 - Eventos - 22
7 - Eventos de timer - 23
8 - Eventos de mensagem - 26
9 - Eventos de dados - 29
10 - Controles de exceo e compensao - 31
11 - Conexo entre diagramas - 35
12 -Terminadores do processo - 35
13 - Resumo dos tipos de eventos da BPMN - 37
14 - Gateways - 38
15 - Eventos do tipo XOR (OU exclusivo) - 38
16 - Token - 39
17 - Eventos AND (E) - 41
18 - Eventos OR (OU) - 41
19 - Tratamento de eventos - 41
20 - Eventos multiplos - 42
21 - Eventos Complexos - 43
22 - Gateways diretamente em fuxos - 44
23 - Atividades e tarefas - 46
24 - Loop - 46
25 - Mltipla instncia - 48

26 - Compensao - 49
27 - Ad Hoc - 50
28 - Pools e Lanes - 52
29 - Artefatos - 56
30 - Dados - 56
31 - Grupos - 58
Parte II
ERROS COMUNS NO DESENHO BPMN - 59
01 - Gateways de tipos diferentes na juno e bifurcao- 60
02 - Gateways baseados em eventos - 62
03 - Utilizao de elementos de fuxos com fuxos condicionais- 63
04 - Eventos - 65
05 - Fluxos, pools e lanes - 68
06 - Fluxos, pools e lanes - 69
07 - Levantamento dos processos de negcios - 70
08 - Processos e Macro-processos - 71
09 - Os fuxos de processos - 74
10 - As is e To be - 75
11 - Use Cases e processos - 76
12 - StoryBoards - 78
13 - BPEL e BPMN - 79
14 - O Mapeamento BPMN para o BPEL - 82
15 - Editor BPMN da revista PortalBPM - 85
16 - Outras ferramentas de mercado - 93
17 - BPMN design patterns - 94
2 - Ferramentas BPMS
Antes de iniciarmos nossa jornada pela notao BPMN, va-
mos apresentar como a TI evoluiu at chegamos ao momento
atual, com as chamadas solues BPMS.
As disciplinas de modelagem de processos tiveram grande
foco ao fnal da dcada de 80 e incio da dcada de 90, com
estudos de cientistas como Michael Porter. Nesta poca os
estudos mantinham foco em administrao de empresas, cen-
trando esforos em como as empresas poderiam ser melhora-
das em termos de estrutura organizacional. O que se percebia
que o processo de construo das empresas normalmente
se fazia de forma desestruturada, com novos departamentos
e processos sendo criados sob demanda. Em um mundo no
globalizado, isto at que no afetava muito a sade da em-
presa. Mas com a internet e globalizao, empresas grandes
comeavam a competir com empresas pequenas de igual para
igual, e a necessidade por uma reduo de custos e melho-
ria de processos junto ao cliente se tornou necessria como
forma de garantir sobrevivncia em um ambiente competitivo.
Nesta poca, o foco dos estudos era como melhorar os
processos, e embora houvessem vrios esforos isolados por
parte da TI para soluo destes problemas, estes esforos
ainda no estavam integrados para formar o conceito que
hoje conhecemos como solues BPMS.
2.1 - Workfows
Eram muito conhecidas na dcada de 80 como ferramentas
de colaborao. Uma implementao de destaque foram as
solues da Lotus, que acabaram sendo incorporadas posteri-
ormente aos produtos da gigante IBM.
A necessidade por organizar de alguma forma a comunicao
entre as pessoas, transferindo responsabilidades ao longo do
processo era e at hoje fundamental em qualquer tipo de
empresa. O nome das ferramentas de colaborao se tornou
chamativo, e o conceito de workfow se frmou e se mantm
at hoje.
6
Na verdade, inmeras empresas vendem solues de work-
fow como se fossem solues BPMS hoje no mercado, mas h
diferenas que at hoje os especialistas tentam explicar. De
uma forma geral, um workfow uma das peas que compe
uma soluo BPMS.
Em uma ferramenta de workfow existem dois conceitos prin-
cipais : o motor de execuo e a ferramenta de defnio de
processo ou fuxo.
Estas ferramentas de defnio inicialmente foram criadas de
forma textual, indicando os participantes e em que ordem eles
executariam atividades. Com o tempo, conforme as prprias
notaes para processos evoluram, todo um conjunto de no-
taes grfcas, como IDEF, BPMN, UML, grafos, entre outros
foram utilizadas como forma de representar visualmente estes
processos em execuo em um Workfow.

O consorcio WfMC foi notadamente um destaque, propondo
uma especifcao utilizada at hoje por muitos provedores de
soluo BPMS.
2.2 - BPMN
Entre os padres comentados, a notao de destaque na
atualidade o BPMN (Business Process Modeling Notation),
que estaremos explorando nos prximos captulos deste
livro. Alm de mais moderna que notaes como IDEF e UML,
tambm possui um rico set de elementos grfcos para rep-
resentao de uma srie de situaes que acontecem nos
fuxos dos processos. O padro est em evoluo e longe
da perfeio, mas de todas as notaes da indstria o que
mantm a maior concordncia da indstria.
Infelizmente, o padro BPMN uma notao grfca para
desenho de processos, e no est associado a nenhum for-
mato de armazenamento especfco.
7
Houve uma tentativa de utilizar a fora da organizao que
estava com credibilidade muito forte pela criao do padro
no sentido de frmar outro padro, o BPML (Business Process
Modeling Language), que seria um formato binrio para arma-
zenamento e execuo dos processos criados em BPMN.
Esta tentativa foi frustrada por outro padro j em estgio
mais avanado de adoo, chamado BPEL.
2.3 - BPEL
A linguagem BPEL (Business Process Execution Language)
hoje uma forte candidata a ocupar o padro como notao
para execuo de processos. Infelizmente, da mesma forma
que um motor de frmula 1 no pode ser colocado sem
inmeras adaptaes em um veculo comum de mercado, o
mesmo pode-se dizer em relao ao BPMN mapeado para
BPEL (com o BPMN como o motor neste exemplo).
A notao BPMN muito completa e sua evoluo se deu
em torno das necessidades que aparecem no dia a dia dos
desenhos dos processos, enquanto que o BPEL foi criado como
um padro para permitir que um motor pudesse orquestrar
fuxos baseados em Servios Web (Web Services).
Em outras palavras, os caminhos seguiram em paralelo e com
focos diferentes em mente. H todo um esforo no sentido
de tornar o BPEL ideal como formato de armazenamento dos
desenhos BPMN, mas hoje os fabricantes adotam duas formu-
las para o mapeamento :
1)Reduzir o nmero de elementos grfcos disponveis, para
manter a converso para o BPEL vivel. Isto ajuda se tiver-
mos em mente apenas a execuo do processo, mas limita o
analista de negcios, se a ferramenta de desenho for a mes-
ma ferramenta que ir operacionalizar os fuxos.
2)Incorporar novos elementos ao BPEL, permitindo que toda
e qualquer representao BPMN possa ser desenhada sem
problemas. Isto traz um inconveniente ao BPEL, pois o mesmo
foi criado para ser totalmente interopervel, e no momento
em que cada um dos fabricantes incorpora novidades, os mo-
tores para execuo tendem a se tornar incompatveis.
8
O que se espera nos prximos anos que uma evoluo nos
dois padres venha a surgir, ou que outro formato de arma-
zenamento se frme como padro para desenho. Ainda h
uma perspectiva futura que a criao da notao BPDM, um
formato intermedirio entre o BPEL e o BPMN.
2.4 - SOA e Web Services
Anteriormente comentamos que o BPEL foi criado como um
padro para orquestrao de servios WEB. Esta foi outra
grande inovao introduzida a partir das limitaes encontra-
das nos paradigmas atuais da orientao para objetos. Por
mais que tentemos reaproveitar os cdigos criados a partir da
OO, o grau de acoplamento entre eles ainda muito forte, e
torna difcil o reaproveitamento de cdigos de forma corpora-
tiva.
A arquitetura WEB Java, com seus mdulos EAR, WAR, JAR,
SAR, RAR, etc. tambm no facilitam o reaproveitamento de
cdigos.
A idia dos Web Services, que posteriormente foi promovida
a arquitetura SOA, prope que os componentes sejam cria-
dos e soltos dentro de servidores de aplicao, de forma
que diversos programas se benefciem de sua utilizao, sem
que necessitem ser incorporados fsicamente a um programa
especfco.
Se esta promessa de componentizao se concretizar, teremos
um novo patamar de reutilizao na indstria. No h garan-
tias de que este ter sucesso, mas os indicadores atuais so
muito promissores.
Bom, imaginando um cenrio ideal teremos os desenhos dos
fuxos sendo criados em BPMN e salvos ou mapeados para
BPEL, que por sua vez far com que servios web sejam
orquestrados. Ento j temos tudo o que necessrio para
uma soluo BPMS ? Bom, nem tudo ainda.
9
2.5 - DashBoards
O sonho de consumo de qualquer empresrio poder con-
trolar de forma ativa sua empresa, identifcando como os
processos esto durante a execuo, tempos de execuo de
cada atividade, e outras informaes. Se todas estas infor-
maes puderem ser apresentadas em grfcos de fcil com-
preenso, melhor ainda.
um conceito semelhante ao de BI (Business Inteligence),
onde dados so analisados nas empresas e medidas so to-
madas para melhoria dos processos.
A idia de BI ou minerao de dados trabalha com dados aps
o fato estar consumado, ou seja, aps o gasto j ter concreti-
zado. Este controle a que nos referimos pr-ativo, ou seja,
devemos coletar dados ao longo da execuo de um fuxo de
processo, e estudarmos os dados antes mesmo do trmino da
execuo do processo.
Este estudo precisa ser feito de forma facilitada, pois temos
pouco tempo para tomada de deciso. Por isso deve ser visual
em formato de grfco.
Nas solues BPMS, colocamos termmetros dentro do fuxo,
e medimos estes termmetros apresentando grfcos que
sumarizam a evoluo do processo.
Isto chamado de Dashboard, e uma pea fundamental
das solues BPMS. Precisamos corrigir eventuais distores
no fuxo bem antes do fnal, para que possamos garantir a
economia e reduo nas perdas. Sem este termmetro,
praticamente invivel descobrirmos se h algo errado ou mes-
mo onde devemos corrigir no processo durante sua execuo.
Ser necessrio a execuo do processo para que possamos
depois da execuo encontrar as falhas.
Esta melhora precisa acontecer a todo momento, e um termo
muito utilizado para descrever esta melhoria contnua
realinhamento dos processos de negcios.
10
2.6 - Realinhamento dos processos de negcios
Com todas estas ferramentas dentro da empresa, com os
desenhos criados com BPMN, sendo orquestrados por um
workfow, executando Web Services com BPEL, e que vo
sendo analisados momento a momento para encontrarmos
possveis problemas e pontos de melhoria, atravs dos
Dashboards, precisamos de um mecanismo para podermos
realinhar rapidamente, ou seja, resolver rapidamente estes
problemas para que o fuxo continue fuindo da forma espe-
rada.
Para isto, no tolervel aguardar meses por alteraes na
TI, para que um cdigo funcione como esperado.
O que se espera das melhores solues BPMS que seja
muito fcil introduzir modifcaes, com poucas alteraes e
facilidade nas alteraes dos cdigos. Isto no um conceito
simples de implementar, e parece que quanto mais visuais as
ferramentas se tornarem, mais rapidamente conseguiremos
este realinhamento desejado.
2.7 - BPMS
Business Process Management Systems
Pois bem, uma soluo BPMS reune as inovaes e tecnolo-
gias anteriormente citadas. Uma defnio para o BPMS pode-
ria ser :
Uma soluo BPMS permite a gerao e controle dos
processos de negcios da empresa, proporcionando
rpida tomada de deciso e realinhamento dos proces-
sos de negcios de forma agilizada.
Um pouco subjetivo no ? Mas o que o homem de negcio
deseja. Em um mundo globalizado e competitivo, os prazos
defnidos pelas metodologias OO e outras no esto mais se
mostrando satisfatrios. Mas podemos ler nas entrelinhas da
defnio, e deduzir algumas coisas :
11
1) Uma ferramenta BPMS deve permitir o desenho dos
processos de forma visual, sendo que as melhores ferramen-
tas suportam o BPMN. As boas ferramentas tm programas
prprios de desenho incorporado. Ser visual importante
pois traz agilidade ao gerenciamento do processo. Imagine
a quantidade de erros que apareceriam se manipulssemos
dezenas ou centenas de arquivos XML de forma manual.
2) O suporte ao padro BPEL4WS no obrigatrio, mas as
ferramentas que o suportam fornecem algumas vantagens.
Em primeiro lugar, voc pode utilizar qualquer editor que gere
o formato. Segundo, os processos fcam armazenados em
formato XML, o que mais adequado e proporciona maior in-
teroperabilidade. As desvantagens esto do fato de o BPEL ser
orientado para Web Services. Ou seja, no se pode orquestrar
uma chamada a um EJB atravs desta tecnologia, a menos
que o EJB seja publicado como servio.
3) um concenso que as ferramentas devem suportar servi-
dores de aplicaes. Algumas criaram os prprios servidores
para execuo. O ideal seriam ferramentas que suportassem
servidores .NET ou J2EE, pois so os mais consagrados.
Naturalmente, a tecnologia J2EE permite multiplataforma, e
isto por s s j vantagem. Criar um servidor especfco e
no utilizar a base J2EE um erro, pois o grau de maturidade
dos servidores J2EE muito alto. Alm disto os servidores
incorporam uma srie de recursos, como escalabilidade e
segurana, e estes recursos podem ser reaproveitados pelos
BPMS.
4) Toda ferramenta deve permitir o controle do processo. Este
controle pode acontecer antes de o processo ser executado
(atravs de simulaes) e tambm durante a execuo, para
deteco de falhas no processo em operao (Dashboards).
Ou seja, antes de publicar o processo devemos poder simul-
lo, para verifcar se est como previsto, e durante a execuo
devemos o ser capazes de extrair mtricas para correo com
facilidade.
12
Deve ser possvel no s publicar novas verses do processo,
como tambm permitir que as verses antigas continuem en-
quanto houverem atividades ainda sendo processadas. Isto
necessrio, caso contrrio ser difcil realinhar os processsos
de negcios rapidamente. No podemos esperar o trmino da
execuo dos processos (o que pode levar dias ou meses),
para colocar uma nova alterao em execuo. Processos
antigos devem continuar executando como previstos, e novos
processos devem j ser executados de acordo com o novo
desenho.
5) Um recurso muito apreciado pelas reas gerenciais so os
Dashboards, que so grfcos gerenciais, tomados dos proces-
sos em execuo, e que permitem verifcar visualmente quan-
do algo no vai bem. Isto ajuda na tomada de deciso. Uma
caracterstica dos Dashboards que eles tendem a ser muito
dinmicos, e portanto deve ser fcil cri-los e alter-los sem
demandar grandes esforos da TI.
6) Quando dizemos rpido realinhamento nos processos de
negcios queremos dizer que o alteraes devem se efetivar
com custo mnimo de tempo. Uma das vantagens divulga-
das pelas ferramentas BPMS poder gerar resultados mais
rpidos do que os conseguidos at ento com as metodolo-
gias tradicionais. Se para alterar um processo de negcio for
necessrio acionar uma equipe de desenvolvimento gigantes-
ca, que tero que criar cdigos novos para cada Web Service
inserido, no estaremos resolvendo um dos problemas que a
tecnologia se prope a resolver, que gerar uma rpida res-
posta aos problemas do negcio.
Neste sentido, atualmente existem dois paradigmas sendo
adotados pelos grandes fabricantes.
O primeiro o de ferramentas onde apenas o processo
gerenciado visualmente.
13
Os componentes de negcios, sejam eles Web Services,
CORBA, EJB so criados manualmente, atravs de ferramen-
tas como Eclipse, NetBeans, WSAD, Sun Studio ou outros, que
podem at estar integrados ferramenta geradora de fuxos.
O segundo tipo de ferramenta, embora no tenha toda a fexi-
bilidade de manipulao de cdigos da primeira alternativa,
adota um paradigma totalmente visual de construo, onde
at mesmo os objetos de negcios so construidos visual-
mente.
A vantagem deste segundo tipo a velocidade no realinha-
mento, com poucos cdigos gerenciveis.
bem verdade que este tipo de paradigma deve evoluir para
algo mais fexvel do que os mecanismos atuais. E ferramen-
tas geradoras de cdigo devem evoluir para alternativas onde
o processo de construo seja mais gil.
7)Ferramentas que permitem criar telas visualmente trazem
agilidade ao processo de mudana, principalmente quando a
atividade exige interao humana.
Um workfow no pode mais ter telas simples, com campos
textuais sem formatao. A identidade visual da empresa
precisa ser mantida durante a execuo do processo. Ou seja,
as ferramentas devem permitir a criao de telas complexas,
de preferncia de forma visual.
8) Ferramentas que suportam apenas componentes Web
Services so limitadas atualmente, embora esta seja uma
promessa futura. O ideal so ferramentas que agreguem al-
gum tipo de EAI, que permita integrar vrios tipos de compo-
nentes do legado. Perceba que isto se contrape adoo de
BPEL4WS, j que o padro apenas suporta WS.
9) Um elemento importante, que se esquece com frequncia,
a estrutura organizacional da empresa. Antes mesmo de ini-
ciar o entendimento dos processos, se constroe o organogra-
mas da empresa. Uma ferramenta que permita defnir organo-
gramas de forma visual, integrando estes organogramas com
mecanismos computacionais trazem vantagens.
14
Infelizmente, a maioria das ferramentas ainda tm limites
neste quesito. Manter as informaes de usurios disponveis
livremente, em qualquer ponto da corporao, tambm uma
vantagem.
Quase todas as solues BPMS mantm os usurios e senhas
em estruturas dentro da prpria ferramenta, ao invs de bus-
car em uma base relacional externa ou servidor LDAP.
Tambm a maioria no permite edio visual do organograma
da empresa.
2.8 - Pure players
Alguns institutos de pesquisa (Gartner Group, por exemplo)
se utilizam do termo pure player, para ferramentas que so
BPMS puros, sendo que os demais so ferramentas que vm
de algum nicho de mercado pr existente. Algumas ferra-
mentas so Workfows ou EAIs que esto em evoluo para
o paradigma BPMS. Algumas empresas tm ferramental de
desenho (BPMN) e esto evoluindo para se enquadrarem na
categoria BPMS. Este termo foi criado para tentar reduzir a
panacia em relao aos diversos fornecedores que desejam
ter sua ferramenta seja considerada BPMS pure player. Uma
ferramenta do tipo pure player tende a ser melhor, j que
foi criada com o esprito destas idias desde o incio.
2.9 - Futuro e BPMN
Vale a pena gastar esforos no padro BPMN agora? Bem, se
voc for um analista de negcios este provavelmente ser o
padro dominante para desenho nos prximos anos. Se voc
da rea de TI, muito provvel que a operacionalizao
dos fuxos seja feita atravs de uma evoluo do BPMN, com
mais elementos programticos incorporados. Mesmo que o
padro dominante continue sendo a UML, h uma perspectiva
de evoluo da notao para que incorpore o BPMN como uma
evoluo dos diagramas de atividade.
15

3 - Processos
3.1 - UML e BPMN
Para que necessitamos de mais uma notao para desenho de
processos? Ser que as notaes existentes, como os diagra-
mas de atividade da UML, j no contemplam tambm este
tipo de representao ?
Eles representam muito bem etapas na execuo de um Use
Case, ou mesmo um trecho mais complicado de uma rotina.
Os fuxos de processos de negcios tm se mostrado muito
mais complexos a cada dia, e a notao UML embora seja
muito formal, deixa a desejar em termos de diversidade gr-
fca, alm de utilizar as mesmas simbologias para o tratamen-
to do negcio e para tratamentos de erros, que normalmente
no fazem parte do negcio em si. Em diagramas maiores a
tendncia confundir e difcultar a visualizao e manuteno
dos fuxos.
Para tornar isto mais claro (e visual), vamos utilizar o exem-
plo de apontamento de viagem, explorado na documentao
ofcial BPMN. Veja o mesmo exemplo modelado de duas for-
mas :
16
O que se pode observar em primeiro lugar que, no caso
da UML, como no existem mecanismos de compensao e
gerao de erros, somos obrigados a utilizar elementos de
deciso para indicar o fuxo em caso de erro.
Neste caso fca mais difcil identifcar qual elemento est
sendo utilizado como parte do tratamento do negcio, e qual
deciso foi inserida como desvio para tratamento de erros,
difcultando a manuteno.
O mesmo ir acontecer quando outros elementos, como timers e
mensagens so adicionados ao diagrama. Eles isolam el-
ementos de interao dos processos de tratamentos da lgica
de negcios, de forma mais clara. Alm disto, o prprio fato
de a imagem j ser representativa, torna mais claro o entend-
imento pelo crebro do que aquele desvio ou evento faz.
Em resumo, um diagrama BPMN torna mais claro o entendimen-
to e adiciona elementos grfcos que facilitam a compreenso
do que est acontecendo no diagrama.
BPMN
17
4 - Tipos de diagramas BPMN
Cada um dos tipos de diagrama chamado de BPD
(Business Process Diagram), mas tm nomes mais espe-
cfcos, de acordo com seu detalhamento.
Algumas vezes desejamos entender em profundidade como
um fuxo opera, e outras vezes desejamos apenas transmitir
ao leitor do diagrama como dois fuxos distintos operam. Para
permitir esta diviso em categorias temos trs tipos de dia-
gramas :
Os Private Business Process ou Diagramas de processos
privados, que utilizamos quando no relevante representar-
mos como diferentes fuxos interagem. Estamos preocupados
apenas com o teor deste fuxo em si.
Existem os Abstract process ou Processos abstratos. Em
um processo abstrato, no estamos preocupados com o con-
tedo do fuxo em si, mas sim como ele colabora com outros
fuxos dentro de um sistema.
18
J nos Colaboration Process ou Processos colaborativos
desejamos obter um grau maior de detalhamento, apre-
sentando como dois ou mais fuxos se comunicam.
Podemos imaginar estes trs tipos de diagramas como sendo
um s, onde caractersticas podem ser apresentadas ou no,
dependendo do que desejamos visualizar. Imagine um progra-
ma de CAD com uma imagem de um veculo, onde podemos
visualizar sua aparncia externa (equivalente ao diagrama
abstract) ou as peas que o compe (equivalente ao diagrama
private). A especifcao no dita regras de como cada imple-
mentao de ferramenta deve operar, mas parece que a for-
ma mais intuitiva seria a de que cada diagrama pudesse ser
chaveado para apresentar seus elementos internos ou no.
Um aspecto ainda a explorar como estes tipos de diagramas
afetam o mapeamento para um fuxo de processos.
Um processo BPEL representado por um processo privado,
por exemplo. Para que tenhamos a colaborao entre proces-
sos em BPEL, necessitamos de mais de um arquivo BPEL,
cada um mapeado para um processo privado. Em resumo, um
diagrama BPMN pode ser mapeado para mais de um arquivo
BPEL. Normalmente um arquivo BPEL mapeado para apenas
um diagrama BPMN.
18 19
5- Pools e Lanes
Conforme um fuxo vai sendo executado, ele passa por vrias
atividades.
Em um mundo real e colaborativo, as atividades so
atribudas a pessoas ou perfs diferentes, ao longo de sua
execuo. Documentos necessitam ser aprovados por
gerentes ou coordenadores, e vendedores necessitam inserir
pedidos no sistema.
Cada um destes perfs so identifcados dentro do BPMN em
elementos chamados pools ou lanes. A pool seria a piscina
onde os competidores nadam. As lanes so as raias, onde
cada nadador ir se apresentar. O resultado do processamen-
to, neste caso, ser o conjunto de processamentos das vrias
lanes (o nadador que chegar em primeiro lugar do outro
lado).
O conceito de pools e lanes est muito preso aos mecanismos
de segurana das solues BPMS. Um vendedor pode inserir
um pedido, mas apenas um coordenador pode aprovar uma
compra atravs de carto de crdito. Quando o fuxo modelado
j se considerando os pools e lanes, fca mais fcil no futuro
organizarmos os vrios perfs que iro executar cada uma das
atividades.
Mas, qual a diferena entre um pool e uma lane ?
Bem, o pool defne um fuxo de processo, onde em seu inte-
rior o processamento ocorre independentemente do que
acontece ao seu redor. Um pool como se fosse um mdulo
ou programa independente de um sistema. Imaginando o
exemplo de uma piscina, se ela estiver dentro de um estdio,
vrias outras atividades esportivas podem estar acontecendo
simultaneamente, mas a competio dentro da piscina in-
depende destas outras atividades que acontecem simulta-
neamente no estdio. J uma lane defne o perfl que est
executando a atividade em dado momento. Via de regra, uma
pool defne um processo, enquanto que a lane defne os
participantes que iro concretizar este processo.
20
5.1 - Instncias de processos

Imaginando que temos um desenho de processo pronto,
surge a dvida do que seria uma instncia de processo. Uma
instncia uma execuo isolada de um processo.
Um programa instalado em um computador como se fosse
um processo. J as vrias instncias em execuo seriam os
programas executando em dado momento em um computa-
dor.
Cada vendedor dentro de uma loja, atuando em seu processo
de vendas uma instncia de processo isolada. Todos seguem
os mesmos passos, mas cada um de forma independente.
A longevidade de uma instncia de processo muito variada,
podendo ir de minutos a dcadas para processamento.
Ou seja, uma vez iniciado um processo, ele se mantm (ou
deveria se manter) em execuo at que seu trmino fosse
atingido.
Se estivermos imaginando um processo executando em um
computador, importante que esta caracterstica seja preser-
vada, ou seja, se o computador for desligado, quando for
reiniciado deve retornar ao mesmo ponto em que estava
anteriormente.

De forma similar, diversas instncias de um mesmo processo
podem estar ativas ao mesmo tempo. Uma loja de varejo,
onde existam vrios vendedores, cada um deles pode estar
conduzindo uma instncia de processo de vendas, de forma
totalmente independente.
Algo deve acontecer para que o processo inicie uma instn-
cia, e o mesmo para que ele seja fnalizado.
Processos so iniciados e terminados atravs de eventos. Uma
vez iniciado, deve acontecer um evento que o fnalize.

21
6 - Eventos
De acordo com a especifcao BPMN, os eventos aparecem
durante a execuo de um fuxo ou so gerados durante sua
execuo. Somente os eventos tm a capacidade de iniciar ou
terminar um processo, mas os eventos no executam tarefas
no processo. Eles podem forar a execuo ou mesmo desviar
para uma determinada atividade.
A representao grfca dos eventos feita por crculos, que
podem ser de trs tipos:
1) iniciais
2) intermedirios
3) fnais
Os eventos de incio foram a criao de uma nova instncia
de execuo para o fuxo. Antes dele, no existia esta instn-
cia de processo em execuo. Algum fato gerador externo ir
causar a gerao do evento. O incio do processo por si s
um evento.
Os eventos intermedirios acontecem ou so gerados ao longo
da realizao de um fuxo j em execuo. Podem ser gerados
pelo fuxo em execuo ou podem ser receptores de um even-
to gerado por outra intncia.
Quando so criados dentro do prprio fuxo (geradores)
provavelmente iro gerar alguma notifcao a alguma outra
instncia de fuxo em execuo. Quando so gerados exter-
namente ao fuxo de processo em execuo (receptores), iro
infuenciar de alguma forma a execuo de outro fuxo.
Existem os eventos fnais, que terminam a instncia do
processo. Aps um evento fnal, nenhuma outra atividade
pode ser executada, embora o prprio evento possa gerar
informaes que afetem outros fuxos em execuo.
22
Devemos ter em mente que os fuxos funcionam como or-
ganismos vivos, podendo existir vrios deles em execuo
simultnea, e cada um se comunicando com outros por meio
de eventos. A nica forma de uma instncia de fuxo comu-
nicar-se com outra mediante o envio e recepo de eventos.
Para podermos diferenciar os eventos de incio, intermedirio
e fnal, de forma visual, existem representaes grfcas
distintas para cada um deles. Um evento de incio um cr-
culo com uma linha simples em sua borda, um evento inter-
medirio representado por um crculo delineado por linhas
duplas, e um evento fnal delineado por um crculo com
linha de espessura dupla. Veja os tipos de eventos existentes.
23
O set completo BPMN defne, alm desses trs tipos, o fato
gerador do evento, ou seja, o causador da execuo do evento.
Estudaremos os vrios fatos geradores, iniciando-se com os
eventos de timer.
7 - Eventos de timer
Os timers permitem controlar o tempo ou defnir datas para
execuo de atividades.
Um evento de incio de timer indica o incio da execuo de
um fuxo em perodos predeterminados de tempo. Um incio
de timer pode demarcar uma data especfca, como todo l-
timo dia do ms (para processamento de uma folha de paga-
mento); pode indicar uma hora especfca, como s dez horas
(para iniciar um backup, por exemplo); pode indicar uma data
e hora, como dia 23 de janeiro de 2008 (lanamento do livro
Modelagem de Processos de negcios com BPMN); como
tambm pode ser um evento relativo data atual (cinco horas
contando a partir deste momento).
A Figura anterior indica um evento de incio. Uma soluo
BPMS de mercado fca validando, normalmente, cada evento
de incio, verifcando se ele coincide com o momento atual.
Quando se encontra uma situao de incio, inicia-se uma
instncia do processo.
Um evento intermedirio de timer pode operar de duas for-
mas. Se ele estiver no meio da execuo do fuxo, interli-
gando duas atividades, como na fgura a seguir, signifca um
atraso inserido entre a execuo das duas atividades.
Isso indica que aps a atividade Aguarda cadastro o fuxo
fcar congelado pelo tempo defnido pelo relgio antes de
continuar a prxima execuo, que Continua processa-
mento.
Mas um timer intermedirio pode igualmente estar ligado
borda de uma atividade e ir indicar, nesse caso, um cdigo
de proteo. Se acontecer a condio antes do trmino da
execuo da atividade, o processamento ser desviado para a
atividade que estiver conectada ao fuxo.
24
No exemplo anterior, uma atividade solicita o recadastramento,
mas pode levar um tempo at que seja executada pelo
usurio, assim como pode fcar para sempre no aguardo, j
que o usurio pode nunca se cadastrar. Nesse caso, o evento
de timer signifca dizer que, se o usurio no realizar a ativi-
dade em at cinco dias, a atividade Remove usurio ser
executada. Caso ela seja realizada dentro desse prazo, Re-
move usurio nunca ser executada e o processamento
continua por Cadastra dados no sistema. Em qualquer
dos dois casos, o processamento continua por Prximas
atividades.
Outra modalidade, nessa representao, seria a de no ter a
continuao do fuxo, e forar sempre a sada pelo mecanismo
de exceo.
Nesse caso, mesmo aps a execuo de Solicita recadas-
tramento, o fuxo fca no aguardo do fnal dos cinco dias
para continuar por Remove usurio. Funciona como se o
evento estivesse conectado entre as duas atividades.
Basicamente, executa-se um evento timer atachado borda
de uma atividade quando se atingiu o perodo limite ou a data
confgurada antes do fnal da execuo da atividade. Perceba
que pode ser tambm um sub-processo, com diversas ativi-
dades em seu interior, como na fgura a seguir.
25
Deve-se tomar cuidado com este tipo de abordagem, pois
se o desvio acontecer pelo timer, o sub-processo pode fcar
truncado, e a especifcao no dita regras para o que acon-
tece com os cdigos j processados dentro da atividade.
No est defnido nem faz sentido um evento de timer como
fnalizador.
8 - Eventos de mensagem
Uma mensagem um mecanismo de envio de informaes
entre instncias de processos. A notao BPMN no defne o
que se utilizar como tecnologia para envio, como SMTP, JMS
ou qualquer outro mecanismo, como tambm no defne o
formato das informaes a serem enviadas. Uma imple-
mentao especfca de soluo BPMS far o tratamento mais
adequado ao processamento de mensagens.
Os eventos de incio de mensagem criam uma nova instncia
de processo, baseado no recebimento de uma mensagem.
No exemplo da fgura anterior, pouco importa o nmero de
atividades existentes dentro de Cadastro e validao.
Quando se atingir o tempo fnal de cadastramento, cessa o
sub-processo Cadastro e validao, e continua o proces-
samento, por meio de Distribui as atividades. Foramos
a execuo da exceo sempre, pois a nica sada para o
fuxo neste caso.
26
Na Figura anterior, temos dois fuxos de processos. Quando
o fuxo superior se inicia e quando a Atividade1 executada,
para um evento intermedirio que signifca envio de men-
sagem. Um evento de mensagem entre duas atividades pode
ser fonte geradora, como no caso anterior, onde ser enviada
a mensagem e o fuxo ir continuar, ou pode ser fonte recep-
tora, se uma seta chegar at a mensagem. Neste caso, quan-
do o evento inicial de mensagem for gerado, ele ir forar a
criao do fuxo inferior.
Neste caso, se inicia uma nova instncia. Mas aps o envio da
mensagem no fuxo superior, o mesmo continua a execuo
da atividade2, e os dois fuxos executam em paralelo e de
forma completamente independente. O nico momento em
que houve comunicao foi no momento do envio de mensa-
gens, que causou a criao de uma nova instncia de fuxo.
27
No exemplo da fgura anterior, acontece uma srie de even-
tos-mensagem. Primeiro, a partir de uma atividade envia-se
uma mensagem que inicia outra instncia de processo. Isso
feito em Solicita dbito ao banco. A notao dita que um
evento de mensagem na borda deve ser receptor. Uma men-
sagem saindo diretamente de uma atividade indica que existe
um evento de mensagem sendo gerado por esta atividade.
Na seqncia do fuxo, a atividade autoriza retirada na
loja envia uma mensagem para o fuxo abaixo, que deveria
estar no aguardo para continuar o processamento. Uma vez
recebida a mensagem, a atividade retirada do produto na
loja executada, e os fuxos fnalizam.
Embora no esteja claro, os fuxos anteriores so inde-
pendentes, ou seja, esto posicionados em pools diferentes.
Isto pode ser afrmado porque a comunicao entre eles est
sendo feita por mensagens, e no seria possvel enviar men-
sagens se as atividades estivessem dentro de um mesmo
pool.
Pode-se dizer que so dois fuxos colaborativos.
Quando a atividade est posicionada na borda, como no
exemplo a seguir, existe uma outra interpretao possvel.
28
No exemplo anterior, o evento de mensagem na borda da
atividade Retirada de produto na loja est posicionado
na borda. Esta representao indica um fuxo de exceo de
mensagem. Aps a operao de dbito, existe um OR,
o qual indica que se tomar um dos dois caminhos. Caso se
tome o caminho de erro no processamento (aquele que gera
a mensagem), quando a mensagem chega at Retirada do
produto na loja, gera-se um desvio, com base no recebi-
mento dessa mensagem. Nesse caso, a operao cancelada,
visto que o fuxo de exceo foi acionado.
Em resumo, existem dois comportamentos para atividades de
mensagem conectadas borda. Quando o fuxo sai do evento,
indica exceo e somente pode ser utilizado posicionada na
borda de uma atividade. Quando a mensagem chega at uma
atividade, indica que esta atividade estava no aguardo do re-
cebimento para continuar o processamento.
Cabe salientar que esse o comportamento padro defnido
pela especifcao, que at deixa alguma dupla interpretao
para este tpico.

9 - Eventos de dados
Podem-se utilizar eventos de dados como incio e intermedirio.
Quando utilizados no incio de um processo, indicam que se
criar uma instncia do processo, quando um valor atingir de-
terminado patamar. O modo como os dados so conectados
soluo BPMS e o nmero de vezes que essa soluo verifca
pelos valores fcam sob completa responsabilidade da imple-
mentao BPMS. Lembre-se de que o BPMN uma notao
grfca, sem pretenses de como ser executado.
29
Nesse caso, o sub-processo Cadastro de alunos fca em
execuo coletando novos alunos para um novo curso. Ele so-
mente sai desse loop quando uma de duas coisas acontecer.
Ou o tempo para inscrio se encerrou, o que se denota com
um timer, ou o nmero mximo de alunos por sala foi
atingido, o que se indica pelo evento de dados. Como no
existe continuao do fuxo depois de Cadastramento de
alunos, ser necessrio que uma das duas excees
acontea, para que o fuxo continue por meio de Finaliza
processo de cadastramento.
Este tipo de evento pode tambm ser utilizado como incio
para um processo ou sub-processo. Por exemplo, quando o
limite do estoque est baixo, automaticamente o processo de
compras se inicia, como no exemplo a seguir.
Um processo automatizado de compra de materiais poderia
iniciar um subprocesso de compra de papel para impres-
sora quando fosse detectado, no estoque, a existncia de
um nmero baixo de pacotes de folhas. Quando colocado na
borda de uma atividade, sempre indica um fuxo de exceo.
Ou seja, quando estiver dentro da atividade, se o patamar for
atingido, o fuxo seguir pelo caminho de exceo. Veja um
exemplo na fgura a seguir.
30
No permitido que um fnalizador gere um evento de dados,
ao menos na especifcao atual do BPMN.
10 - Controles de exceo e compensao
Na maioria das situaes, o BPMN ser utilizado para
orquestrar Web Services. Nesse cenrio, surge um problema,
pois os Web Services so atmicos e sncronos. Isso quer
dizer que, uma vez chamado, um servio ser executado se
estiver disponvel, e o resultado do processamento persistir
imediatamente. Em resumo, no h rollback de Web Services.
Imagine uma seqncia de chamadas a servios que precisam
operar em forma de bloco, de forma a efetivar todos ao mes-
mo tempo ou a cancelar todos como uma unidade. Como um
servio atmico, foi necessrio criar mecanismos que permi-
tissem que grupos de servios pudessem ser desfeitos, caso
algum deles apresentasse algum problema.
Como parte da especifcao BPMN, existe um controle de
excees e compensaes criado sob a forma de eventos
gerados. Basta conectarmos a borda de uma atividade com-
posta por vrias atividades que devem ser atmicas, a um
evento especial que atuar como captura de erros que acon-
tecem. Quando se efetuar o desvio para essa outra atividade,
os processamentos efetuados podero ser desfeitos, de modo
que se retorne o processamento ao estado inicial.
31
Vale salientar que, nas implementaes de bancos de dados
atuais, esse mecanismo no funciona como nos rollbacks
BPMN, que nem sequer chegam a alterar as informaes. Em
resumo, as tecnologias de EAI esto mais modernas do que
o mecanismo de compensao proposto pela especifcao
BPMN.
Em vez disso, na implementao de compensao do BPMN os
dados so alterados e depois retornam aos valores originais,
atravs de uma atividade especial de compensao, o que
pode acarretar efeitos colaterais quando utilizamos servios a
partir de cdigo legado. A fgura a seguir ilustra a represen-
tao desse mecanismo.
Nesse caso, coletam-se os dados do cliente e efetua-se a
compra de passagem. Duas atividades precisam ser executa-
das: efetuar a reserva no vo e a cobrana do valor. Caso
falhe algum desses servios, acontecer um desvio para a
compensao, que ir garantir que o valor nunca ser cobrado
ou que o avio no decolar com o assento reservado, porm
vazio. Se por outro lado, os dois servios forem executados
com sucesso, o processamento continuar em Avisa cliente
da operao.
32
33
Eis uma pergunta de cunho maldoso: e se ocorrer uma falha
ao estornar o valor ao cliente? Podemos capturar esse erro
e direcion-lo a uma atividade que ir efetuar o tratamento.
Nesse caso, o erro mais grave e o chamamos de exceo,
que precisa de ateno especial. Pode-se representar uma
parte do desenho acima da seguinte maneira:
Nesse caso, houve um erro na compensao, e solicitou-se
interveno manual da operadora, a fm de evitar resultados
mais graves. Podemos unir a compensao e a exceo em
apenas uma atividade, como ilustra a fgura a seguir.
Nesse caso, a sub-atividade compra de passagem pode-
se formar por pela cobrana da passagem e pela alo-
cao. Caso ocorra algum erro no processamento de um
servio, este se desviar para a compensao, que por sua
vez tentar desfazer o processo. Se ainda dentro de compra
de passagem ocorrer um erro grave, ser gerada a exceo
que enviar uma mensagem ao operador do sistema, o qual
far uma interveno manual.
As compensaes so erros no to graves, onde se tenta
corrigir o problema, retornado a um estado possvel de
execuo. J os erros so mais graves, e exigem um trata-
mento especial.
A forma como as solues BPMS tratam esses erros e com-
pensaes defnida por sua implementao. Entretanto, a
notao permite uma representao visual mais simples e
representa erros de forma visual; erros que, de outra forma,
teriam que ser representados como parte do fuxo, mas nada
tem a ver com as regras de negcios. Se no tivssemos a
compensao e as excees, teramos um trecho como o da
fgura a seguir.
34
Nesse caso, prevemos o tratamento de um erro por meio de
elementos condicionais; o que ruim, pois os condicionais
deveriam representar apenas decises relativas lgica de
negcios. Quando se utilizam condicionais para representar
tanto a lgica quanto os tratamentos de erros, tornam-se
complexos os diagramas e, com freqncia, de difcil com-
preenso. Quando se utilizam compensaes e excees,
usam-se elementos diferentes para cada representao no
diagrama.
34
11 - Conexo entre diagramas
Algumas vezes o diagrama se torna to extenso que no con-
seguimos conectar certas partes, sem que as linhas fquem
cruzadas. Existe um mecanismo simples de link, que permite
conectar elementos dentro de um diagrama, ou mesmo
elementos entre dois diagramas distintos. Informamos que
dois links esto conectados atravs de seu nome. O nome
funciona como se fosse uma chave para os dois links. Um link
pode ser representado como :
12 - Terminadores do processo
Existem atualmente trs formas de fnalizarmos um processo.
As trs representaes possveis so :
35
O primeiro tipo, com um circulo preenchido no interior, indica
trmino incondicional. Isto signifca que o processo deve ser
terminado neste momento, sem compensao, tratamento de
erros ou quaisquer outros tratamentos.
Se for um sub-processo, encerra imediatamente e retorna ao
fuxo pai.
O trmino com um X no interior indica cancelamento da
transao. Os mecanismos de compensao e erros trabalham
em conjunto com o cancelamento. Normalmente o cancela-
mento iniciado programaticamente, enquanto que a com-
pensao e exceo so geradas por erros no processamento.
36
Supondo um sub-processo escolha, sendo que desdobrado
se torna um fuxo como o da parte superior da fgura. Caso a
escolha do usurio for invlida, ser gerado o cancel, que
capturado pelo evento cancel conectado borda da atividade.
Neste caso, se redireciona para um outro tratamento, onde a
seleo no escolhida ser tratada como se fosse uma ex-
ceo.
13 - Resumo dos tipos de eventos da BPMN
37
14 - Gateways
Gateways so os mecanismos padronizados do BPMN para
efetuarmos desvios. Os vrios tipos de desvios, como AND
(E), OR (OU) e XOR (OU exclusivo) so tratados com simbo-
logias distintas pela notao. Assim como os eventos so
representados por crculos, os gateways so representados
por losangos.
15 - Eventos do tipo XOR (OU exclusivo)
Os eventos do tipo XOR (OU exclusivo) podem ser represen-
tados de duas formas
Este tipo de gateway o mais simples de se entender, pois ele
representa o OU, onde o acesso a um dos caminhos exclu-
sivo. Ou seja, apenas um dos caminhos ser seguido, no
importando quantos caminhos existam para escolha.
Um exemplo deste tipo de representao poderia ser a es-
colha do tipo de pagamento de um produto :
38
Neste caso, o pagamento ser feito via transferncia bancria
ou por carto de crdito.
Qualquer dos caminhos tomados, haver uma juno na
frente, fazendo com que o fuxo continue aps um dos caminhos.
Este caso de fcil compreenso, pois apenas um dos
caminhos seguido. Existem situaes onde mais de um
caminho pode ser seguido (OR) ou mesmo todos os caminhos
sero sempre seguidos (AND). Neste caso, para poder explic-
ar melhor o conceito do que acontece nestes casos, a especif-
cao utiliza o termo TOKEN.
Precisamos entender este conceito para compreender os outros
tipos de gateway.
39
16 - Token
Imagine que uma instncia de fuxo de processos foi criada.
Neste caso, a execuo segue pelo caminho natural de
execuo, mas como existem gateways que permitem mais
do que um caminho em paralelo, podemos ter dois caminhos
sendo executados ao mesmo tempo, dentro de uma instncia
de processo. Veja este exemplo :
O processamento se inicia normalmente, com a criao da
instncia. Podemos chamar neste caso T1 a instncia em
execuo. O problema que quando passamos pelo AND (o
gateway com sinal de mais dentro) dois caminhos so segui-
dos em paralelo, representados neste caso por T1A e T1B. Se
estivssemos nos referenciando a linguagens de programao,
teramos o processo em execuo (T1) e duas threads exe-
cutando em paralelo. exatamente este o conceito de Token.
Mas, se equivalente uma thread, porque no cham-la
diretamente por este nome ?
Bem, em primeiro lugar o termo thread diz respeito a uma
linguagem de programao, e neste conceito os dois braos
de execuo (T1A e T1B) no precisam estar realmente
executando ao mesmo tempo. A notao BPMN no fora a
que uma implementao de soluo BPMS tenha todo o con-
ceito de multi-thread embutido dentro dela.
Mas a notao diz simplesmente o seguinte :

Uma vez criados mais de um token a partir de uma
bifurcao, o processamento somente continua aps
todos os tokens chegarem at a juno.
Esta frase abre margem para mais de uma interpretao, e
em nenhum momento estamos dizendo que a execuo est
acontecendo em paralelo. Dissemos que os dois braos de
execuo precisam chegar ao ponto de encontro, para que o
processamento continue aps a juno do gateway.
Desta forma, uma soluo multi-threaded pode executar
seleo de produtos e consulta serasa realmente em
paralelo, o que seria interessante, mas tambm pode execu-
tar primeiro a atividade seleo de produtos, depois a
atividade seleo de forma de pagamento e depois a
atividade consulta serasa, para somente ento continuar
aps a juno do gateway. Perceba que para qualquer das
duas implementaes, no h diferena aparente em termos
de processamento, a no ser pela menor velocidade das ativi-
dades sendo executadas de forma seriada.
40
Paralelo ou no, necessitamos de um conceito para indicar
esta independncia criada pelo conceito de bifurcao e nova-
mente dependncia criada pela juno.
Com este conceito de Token em mente, podemos explorar os
outros tipos de gateway existentes.
17 -Eventos AND (E)
Este caso exatamente o exemplo anterior. Quando se chega
at a bifurcao do tipo AND, se seguem os dois caminhos,
atravs de dois tokens criados. No h processo de deciso,
e todos os caminhos so seguidos. O objetivo de utilizao
do AND pode ser tentar otimizar o tempo de processamento,
permitindo interaes em paralelo pelos vrios perfs de
execuo.
18 - Eventos OR (OU)
Os eventos do tipo OU permitem que se navegue por um ou
mais caminhos durante o fuxo de execuo. Ao contrrio
do OU exclusivo, pode-se seguir um ou mais dos caminhos.
necessrio que ao menos um dos caminhos seja vlido para
navegao.
19 - Tratamento de eventos
Outra necessidade decorrente da especifcao BPEL so os
eventos mltiplos. Imagine uma situao em que um processa-
mento deve aguardar o acontecimento de um evento.
Na verdade, pode acontecer uma de vrias possibilidades de
evento. Esse evento pode ser o recebimento de uma men-
sagem ou um timer expirando depois de dois dias. Nesse
caso, h duas possibilidades de eventos.
A primeira que acontecer continuar o processamento, e as
outras opes so canceladas. Veja um exemplo na fgura a
seguir.
41
20 - Eventos multiplos
Nesse caso, o mdico solicita um exame e duas so as
possibilidades: o cliente pode fazer o exame solicitado e retor-
nar ao mdico, ou o cliente pode ignorar a solicitao e diri-
gir-se a outro mdico. Caso o cliente faa o exame, o mdico
emitir uma receita com base nos resultados. Caso no haja
retorno, a fcha do cliente ser arquivada. Nos dois casos, o
processamento continua pela notifcao do plano de assistn-
cia mdica.
Vale salientar que, aps adotar uma possibilidade, ignora-se a
outra. Caso o resultado dos exames seja enviado ao mdico,
nunca ocorrer o arquivamento da fcha do cliente.
Esse tipo de estrutura chamada de deciso complexa base-
ada em eventos e corresponde ao elemento pick da BPEL.
Claramente a documentao indica que a implementao deste
elemento foi no sentido de facilitar a migrao de desenhos
criados em BPEL.

42
43
21 - Eventos Complexos
Algumas vezes nenhum dos trs tipos de gateways (OR, AND
e XOR) sufciente para representar uma situao. Os gate-
ways testam uma nica condio, mas algumas vezes neces-
sitamos testar mais de um dado para tomada da deciso.
Outra necessidade a mistura de um comparador comum
(AND, OR ou XOR) com um comparador baseado em even-
tos. Neste caso, foi criado um coringa chamado evento com-
plexo, onde cada uma de suas sadas pode efetuar testes
distintos, e decises podem ser tomadas de forma mais com-
pleta. Outra utilizao para este tipo de elemento existe quan-
do precisamos saber se uma determinada sada foi escolhida,
em funo de outras escolhas.
Neste caso, podemos ter compras vista, em dinheiro ou
prazo. Caso a compra seja vista ou em dinheiro, o caminho
seleo de brinde tambm executado. Caso a compra seja
a prazo, seleo de brinde no executado. Desta forma,
uma sada pode tomar decises em funo de outras sadas.
Os outros tipos de gateway no permitem este tipo de com-
portamento.
22 - Gateways diretamente em fuxos
Embora obscuro, podemos representar gateways diretamente
na sada das setas que saem das atividadades. O diagrama
se torna de mais difcil leitura, mas reduz a quantidade de
gateways.
Quando a sada de um fuxo contm um losango, signifca que
uma deciso deve ser aplicada. Quando a seta contm um
corte diagonal, signifca que a sada default. Se a seta no
contiver nenhum destes dois elementos, signifca que o caminho
deve ser seguido. Se houver mais de um caminho, todos eles
devem ser seguidos. Portanto, as duas representaes a
seguir so idnticas, em termos de BPMN.
44
No primeiro caso, a sada da atividade segue por dois
caminhos, o que signifca que h uma bifurcao. No segundo,
est representado atravs do gateway uma bifurcao. Para
junes, o processo o mesmo, ou seja, duas setas chegando
a uma atividade representam a juno de um AND.
Para elementos do tipo XOR, seria algo como :
No primeiro caso, o losango indica uma condio, que se no
for respeitada, far com que o fuxo siga pelo caminho de-
fault, para evento 3. Esta representao similar ao desenho
da direita, mas utilizando o gateway para XOR.
45
24 - Loop
Algumas vezes necessitamos executar repetidas vezes uma
atividade, como por exemplo calcular o imposto para cada um
dos produtos de uma lista de compra. Poderamos utilizar um
trecho de cdigo para indicar este clculo, algo como :
23 - Atividades e tarefas
Uma atividade uma unidade de trabalho em um processo.
Pode signifcar uma interao com o usurio, ou algum proces-
samento independente do perfl. Quando a atividade to
isolada que no faz mais sentido subdivises, ela chamada
de tarefa. Uma tarefa, portanto, uma particularizao do
conceito de atividade. Da mesma forma, um sub-processo
um tipo de atividade onde sabidamente existe pelo menos um
grau de detalhamento em seu interior. Se fssemos dividir em
temos de hierarquia, poderamos pensar no processo como
sendo a atividade de mais alto nvel (algumas vezes chamado
de macro-atividade). O processo dividido em atividades
menores, chamados sub-processos. Estes sub-processos vo
sendo cada vez mais detalhados, at que chegamos em um
nvel onde no h mais detalhamento, este chamado de tarefa
(task). De forma geral, qualquer tipo de atividade represen-
tado por um quadrado com as bordas arredondadas.
46
47
Basta colocar um condicional, normalmente um XOR, e uma
condio para que o fuxo tenha uma sada. Para este caso,
poderamos representar atravs de uma atividade do tipo
loop, de forma mais sinttica.
Em muitas situaes o loop ir executar uma seqncia de
tarefas, portanto podemos utilizar um loop associado ao
elemento de sub-rotina, que representado por um sinal de
soma na representao.
O padro BPMN recomenda que uma sub-rotina tenha o si-
nal de soma na parte inferior, e caso seja clicado deveria
se expandir, apresentando uma miniatura do diagrama que
normalmente estaria em seu interior. Este comportamento
no obrigatrio, mas parece ser a forma mais intuitiva de
tratamento deste tipo de elemento.
25 - Mltipla instncia
Outra forma de representao para o loop a execuo de
mltiplas instncias. Neste caso, a representao de duas
barras verticais dentro da atividade.
48
49
A diferena bsica entre as duas representaes a forma
como cada um dos elementos tratado. No loop, os elemen-
tos so tratados um a um, mantendo sempre um nico token
ativo. No caso do processamento paralelo, para cada um dos
elementos a ser tratado gerado um novo token, fazendo
com que cada um dos elementos tenha um tratamento inde-
pendente, causando o processamento em paralelo nas imple-
mentaes que suportem multi-thread. Na verdade, a escolha
por um ou outro tipo de simbologia pode trazer impactos na
implementao. Se necessitarmos sumarizar um valor, como
no exemplo anterior de calculo de imposto, o loop reco-
mendado. Caso os elementos possam ser tratados de forma
totalmente independente (lembre-se de que cada token pode
ser tratado como uma thread por uma linguagem de pro-
gramao) podemos utilizar o paralelo.
26 - Compensao
A compensao um tipo de atividade focada na execuo
de um roolback, ou retornar o estado de um processo a um
estado anterior, para que o processo possa ser executado.
Ele normalmente utilizado em conjunto com o evento de
compensao, que redireciona para esta atividade quando
necessrio.
Repare os dois tringulos dentro do evento de compensao,
neste caso Libera assento alocado e Estorna valor
cobrado. Eles indicam este tipo de atividade como uma
compensao.
27 - Ad Hoc
H uma grande discusso na internet sobre o BPMN ser
capaz de representar situaes de uso corriqueiro em termos
de processos. O contra exemplo mais utilizado aquele de um
escritrio de advocacia, lidando com um processo de cliente.
Embora existam vrias atividades a serem executadas, como
cpias autenticadas de documentos, obteno de assinatu-
ras, agendamento de audincias, entre outros, muitas vezes
no temos como garantir em que ordem estas atividades iro
acontecer. O importante que todas elas estejam fnaliza-
das para que possamos passar para uma etapa seguinte. O
mesmo pode ser aplicado tarefa de escrever um livro. No
necessariamente h uma ordem para sua escrita, desde que
todos os captulos estejam prontos para sua publicao. Uma
atividade do tipo Ad Hoc identifcada por um til dentro,
mas as atividades em seu interior so soltas, ou seja, no
esto conectadas. Considera-se o fnal da atividade Ad hoc
quando todas as atividades em seu interior tiverem termi-
nado.
A simbologia para este tipo de atividade a seguinte :
50
51
Veja um exemplo de atividade do tipo Ad Hoc
28 - Pools e Lanes
Pools so compartimentos onde os elementos do fuxo so
acomodados, de forma a indicar que participante do processo
ou um perfl est executando cada atividade. De forma geral,
a pool ou lane no interfere nem defne o que ser feito, mas
sim quem o far. Est associado a mecanismos de segurana
normalmente.
A especifcao no defne o tipo de elemento, que pode ser
um departamento, perfl ou pessoa.
A representao recomendada de uma caixa, com uma linha
vertical separando os elementos de um ttulo para o pool ou
lane.
Uma pool o elemento mais externo, ou seja, no se pode
inserir pools dentro de pools. As lanes so elementos que
so posicionados dentro de pools, para indicar mais de um
perfl que colaboram para a execuo de um processo.
52
52 53
Se os elementos internos de uma pool ou lane so represen-
tados, ele pode ser um diagrama privado ou de colaborao
(leia o captulo processos). Se por outro lado os elementos
no estiverem visveis, mas apenas como dois pools colabo-
ram, chamamos de diagrama de colaborao.
Cada pool considerado um fuxo isolado, e a nica forma
de elementos entre dois pools se comunicarem atravs de
mensagens. Ou seja, no permitido fuxos entre dois
elementos do tipo pool.
Podemos visualizar duas pools como duas instncias de
processos distintas, onde a nica forma possvel de interao
o envio de mensagens, onde esta mensagem enviada pode
interferir no outro fuxo, caso este fuxo tenha sido preparado
para o tratamento desta mansagem. No conceito de Tokens,
existe ao menos um Token para cada pool, e estes Tokens
nunca se encontram, ou seja, cada um permanece em sua
instncia de processo at o trmino de algum deles. No h
formas de se encerrar vrios pools ao mesmo tempo.
O mximo que podemos modelar enviar uma mensagem de
um pool para outro, e modelar o segundo fuxo de forma que
o processo tambm seja encerrado.
Em resumo, dois pools so como que dois programas to-
talmente distintos, onde a nica forma de comunicao
atravs do envio de mensagens.
De forma similar, os mecanismos de mensagens foram criados
para envio de informaes entre dois processos distintos. No
faz sentido, e a especifcao julga ilegal enviar mensagens
dentro de uma mesma pool.
Esta restrio parece a mais fcil de compreender, se pensar-
mos em termos de tokens. No momento em que estamos na
atividade1, existe apenas um token. O fuxo de processo ir
continuar pela execuo de atividade 2 e atividade 3 mantendo
um nico token. Mas, em atividade 1 estamos enviando uma
mensagem para atividade 3, que somente ser executada l
na frente.
Qual o sentido de enviar uma mensagem para uma atividade
que no tm a capacidade de executa-la no momento ? Lem-
bre-se de que o envio de mensagens no desvia o fuxo, e a
atividade receptora somente pode trata-la se estiver proces-
sando ou aguardando por ela. Portanto no faz sentido enviar
mensagens dentro de uma mesma pool.
54
55
Se estamos trabalhando com pools abstratos (aqueles que
no mostram os elementos internos) pode ser interessante
mostrar os pontos de conexo entre duas pools, portanto
permitido enviar mensagens entre atividades de dois pools ou
mesmo mensagens de um pool diretamente ao outro.
Neste exemplo, deve fcar claro que no fnancial insti-
tution quem est enviando mensagens para o outro fuxo
abaixo, mas sim uma de suas atividades internas. Como no
esto visveis quais so estas atividades internas, se moveu a
representao da mensagem para a borda da pool.
29 - Artefatos
Artefatos so elementos extras que podem aparecer dentro
do diagrama, mas que no alteram o fuxo nem executam
tarefas. Eles servem como representaes que iro aumentar
a clareza do diagrama ou expor certos pontos importantes. A
notao defne um set reduzido, mas outros elementos pode-
riam ser acrescentados pelas implementaes de ferramentas.
30 - Dados
Embora no seja preocupao do BPMN, algumas vezes dese-
jamos tornar claro por quanto tempo e at onde um elemento
de dados est sendo propagado. Este dado pode ser uma
informao isolada ou mesmo um bloco de informaes.
No exemplo a seguir, desejamos deixar claro que os valores
esto sendo sumarizados, e podero ser utilizados em um
ponto a seguir no desenho dos processos.
56
56 57
A linha conectando o artefato de dados atividade e ao con-
dicional pode indicar que o elemento vlido durante aquele
perodo de tempo, representando a longevidade da infor-
mao.
Tambm pode informar que um dado passou de um estado
para outro, como no exemplo a seguir :

Na verdade, os elementos de dados podem funcionar como
coringas que representam a informao, onde quer que ela
esteja.
31 - Grupos
Grupos no afetam o fuxo de processos nem adicionam re-
stries. Da mesma forma que os elementos de dados, eles
agrupam atividades e outros elementos de forma a tornar
visveis blocos importantes de operao. So meramente posi-
cionais, e portanto permitido que um grupo atravesse duas
pools, como no exemplo a seguir.
58
59
Parte II
ERROS COMUNS
NO DESENHO
BPMN
1 - Gateways de tipos diferentes na juno e bifurcao
Normalmente utilizamos um mesmo tipo de bifurcao e
juno, como no exemplo a seguir :
Isto garante que os tokens gerados sero sincronizados na
sada. No exemplo anterior, foi criado um AND, que fez com
que as atividades seguissem em paralelo. Na juno do fuxo
ser aguardado o trmino dos dois tokens, para que o proces-
samento continue. Isto funciona desta forma porque a bifur-
cao de AND gera tantos tokens quantas forem as sadas, e
a juno aguarda por todos os tokens gerados para continuar
aps o processamento.
Temos alguma fexibilidade nesta utilizao, mas devemos
utilizar com cuidado.
Uma possibilidade a de adotarmos gateways de tipos
diferentes, para juno e bifurcao. Ligeiramente diferente, o
exemplo anterior fcaria :
60
61
Neste caso, dois tokens sero gerados para paralela 1 e
paralela 2. Mas o token de juno um OR, o que signifca
que a primeira das atividades que chegar ao fuxo far com
que o mesmo continue. Quando o segundo token chegar at
a juno, ser descartado, j que o fuxo j continuou assim
que o primeiro Token foi detectado. Neste caso, pode no ser
to grave, a menos que as atividades aps o gateway neces-
sitem de informaes ou dados gerados por alguma das duas
atividades. Neste caso, como no sabemos qual ir terminar
primeiro, corremos o risco de seguir adiante sem termos os
dados consolidados para utilizao.
Mas, nesta mesma linha podemos cometer um erro grave,
que poder causar impacto muito srio na execuo do fuxo
criado.
Neste caso, apenas um token ser gerado com absoluta
certeza, j que a bifurcao um XOR. Entretanto, coloca-
mos um AND na juno, que ir aguardar pela chegada dos
dois tokens, embora apenas um tenha sido criado. Acabamos
de gerar um dead lock, que far com que qualquer fuxo que
passe por este trecho permanea travado pela infnidade. Este
termo (dead lock) utilizado para um trecho em execuo
que causa um travamento, impossibilitando a continuidade da
execuo.
Outra modalidade de erro pode causar inconsistncias no
processamento, podendo ser at mais grave do que um dead
lock.
Neste caso, foi gerado um token, mas este no passou pela
juno, chegando a um ponto mais distante do cdigo. No
difcil se criar fuxos com alguns nveis de gateways, tornando
totalmente imprevisvel o resultado de processamento dos
mesmos.
Portanto, algumas regras podem salvar erros em um fuxo :
1) Utilize bifurcaes e junes do mesmo tipo
2) Garanta que uma atividade que passou por uma
bifurcao continuou o fuxo passando por uma juno
2 - Gateways baseados em eventos
62
63
Os gateways baseados em eventos foram criados com o obje-
tivo de permitir que um fuxo fque no aguardo de um evento,
para continuar. Uma atividade no um evento, e portanto
esta representao no permitida.
Outra particularidade sobre esta representao que o gate-
way fca no aguardo de um dos eventos acontecer, e continua
aps a recepo do primeiro dos eventos. Todos os outros
eventos so descartados aps a execuo deste caminho. Este
tipo de condicional baseado em eventos um XOR (OU exclu-
sivo) pois somente um caminho seguido.
Ao contrrio dos outros gateways, este no necessita de uma
juno para sincronizar os tokens. Veja um trecho de fuxo
aparentemente invlido, mas correto sob ponto de vista da
notao.
No caso anterior, caso o caminho seja o brao mais inferior, o
processamento termina com o envio de uma mensagem. Se
qualquer dos outros caminhos for seguido, o fuxo segue at o
fnal do processamento.
3 - Utilizao de elementos de fuxos com fuxos condicionais
No faz sentido utilizar as notaes de condicional e default
conectados sada de um gateway, como no exemplo ante-
rior. Ou utilizamos o gateway, ou utilizamos os fuxos direta-
mente na sada da atividade, utilizando desta forma a notao
alternativa.
Fluxos no podem sair de gateways, como no exemplo anteri-
or, nem mesmo chegar a ele. De uma forma geral, mensagens
no podem fcar contidas dentro de pools. Todas as mensa-
gens devem cruzar uma pool e atingir outro fuxo externo.
Embora parea evidente, no podemos ter gateways com ape-
nas uma sada. Eles so pontos de deciso, e devem fornecer
alternativas ao caminho do fuxo.
64
65
4 - Erros comuns no desenho BPMN Eventos
A notao dita que os eventos de incio apontam para o
comeo do fuxo, e eventos de fnalizao terminam um fuxo.
No obrigatrio que existam eventos de incio e fnal, mas
se existirem, devem aparecer aos pares. O seguinte exemplo
portanto no permitido :
Por outro lado, podemos ter vrios incios para um fuxo, e se
conveniente, podemos representar mais de um fnal.
Quando um fuxo iniciado, caso no existam os eventos de
incio todas as atividades que no tiverem uma seta chegando
at ela so considerados pontos de incio para o fuxo.
Quando uma instncia de fuxo criada, so criados tantos
tokens quantos forem os pontos de incio do fuxo.
Outro erro comum relacionado aos eventos que apenas
mensagens ou atividades so geradores e consumidores de
mensagens.
Neste caso, um timer no pode ser o gerador de uma men-
sagem.
Mensagens so geradas por atividades e podem chegar a
outras atividades ou a elementos de evento de mensagens.
Mensagens intermedirias no podem gerar mensagens. O
exemplo a seguir est errado, portanto.
Em resumo, correto enviar mensagens a partir de ativi-
dades, mas no podemos gerar mensagens a partir de eventos
intermedirios, estejam eles atachados borda de uma ativi-
dade ou no. Como receptores, entretanto, esta restrio no
existe.
Um evento de timer no pode ser um fnalizador de processo,
afnal isto estaria signifcando que o processo estaria termi-
nando aps um certo tempo. Embora fosse bastante con-
veniente e til, um evento de modifcao de dados tambm
no pode ser um fnalizador.
66
67
Da mesma forma, os eventos de tratamento de erro, como
exception, error e compensao no podem ser utilizados
como eventos de inicializao.
Por fm, os tratamentos de exceo so representados por
setas de fuxo, e no de mensagens. Apenas lembrando que
tratamentos de exceo so aqueles que saem das bordas de
uma atividade, como no exemplo a seguir.
5-Fluxos, pools e lanes
Um fuxo deve se iniciar e continuar at o fnal do processa-
mento. No podem haver interrupes em sua representao.
No caso anterior, no podemos transferir o controle para
outro processo, e receber novamente o controle em outro
ponto do fuxo, atravs de mensagens.
Vale repetir que entre pools a comunicao feita entre men-
sagens. Dentro de um mesmo pool, a comunicao feita at-
ravs de fuxos de processo, que devem se iniciar e conduzir a
seqncia atravs das atividades at o fnal do processamento.
Dentro de uma pool, existe um nico fuxo de processos.
Quando um fuxo de processos instanciado, todos os pontos
de incio recebem o processamento, criando-se tantos tokens
quantos forem os pontos de entrada.
68
69
6 - Fluxos, pools e lanes
Uma exceo do tipo compensao deve desviar para uma
atividade do tipo compensao, e apenas uma. As seguintes
representaes portanto no so vlidas.
No primeiro caso, o desvio acontece para uma atividade co-
mum, e no uma compensao. Uma exceo do tipo com-
pensao deve apontar para uma atividade do tipo compen-
sao.
No segundo caso, o desvio acontece para uma atividade que
est ligada a outra compensao. Isto tambm no permiti-
do, e todo o tratamento da compensao deve ser feito em
somente uma atividade (ou sub-atividade) do tipo compen-
sao.
7 - Levantamento dos processos de negcios
As tcnicas para levantamento de processos de negcios no
so muito diferentes da modelagem tradicional de sistemas
orientados para objetos.
Normalmente a modelagem de processos aparece como uma
etapa anterior ao desenvolvimento de um sistema, como for-
ma de compreender os mecanismos do negcio em questo.
Muitas vezes eles nem mesmo se desdobram em sistemas,
servindo apenas como desenhos para otimizao dos processos
da corporao.
Na maior parte do tempo, o levantamento de processos
feito atravs de entrevistas com usurios do sistema e nor-
malmente geram artefatos que iro amadurecer para gerar
documentos ofciais do sistema. O BPMN, neste caso, ser um
dos artefatos gerados para representao das informaes.
Perceba que a notao BPMN nem de longe completa e uma
srie de outros diagramas e documentos so normalmente
utilizados para entendimento do problema. Qualquer ferra-
menta de mercado, como Provision, MSVisio ou Enterprise
Archictect, Intalio e outros fornecem uma srie de outros dia-
gramas auxiliares para o desenho dos processos de negcios.
Qualquer empresa fornecedora de uma ferramenta consultada
ir apresentar sua frmula para desenho de processos,
quase sempre focada nas caractersticas de sua prpria
ferramenta.
Por isto iremos expor ao invs de uma metodologia, prticas
que podem ser utilizadas de forma a ajudar no levantamento.
Vamos propor uma srie de idias, e voc pode manter em
seu poder, como um canivete suo, utilizando-as durante um
levantamento, quando julgar mais conveniente.
70
71
8 - Processos e Macro-processos
Os desenhos de processos iniciam em uma camada superior
de desenho, e vo sendo evoludos (o correto seria detal-
hados) em nveis menores.
O nvel mais alto que encontraremos so os macro-processos
de uma empresa. O nvel mais baixo que encontraremos seria
uma atividade, que no pode ser subdividida.
Imaginando que tenhamos iniciado neste momento nossas
atividades, e no temos sequer os macro-processos da em-
presa. Especialistas costumam salientar que os macro-
processos de uma empresa tendem a ser poucos, de um
nmero que varia entre 7 a 15, mais ou menos. No sou
adepto de nmeros mgicos, mas se uma empresa prope
a existncia de 200 macro-processos, provvel que tenha
ocorrido o que chamamos de decomposio funcional, ou
seja, um macro processo foi detalhado em sub-processos.
Uma tcnica que ajuda a descobrir os macro-processos de
uma empresa a criao de um diagrama de posicionamento.
Ele posiciona a empresa, os clientes e parceiros dentro de
reas na tela, indicando o relacionamento entre cada uma
destas reas. Desta forma, cada uma das setas encontradas
dentro deste tipo de diagrama tende a se tornar um macro-
processo. Um exemplo deste tipo de diagrama pode ser ob-
servado a seguir :
Atravs deste tipo de diagrama, que pode ser feito em
conjunto com os responsveis pela companhia consegue-se
identifcar pontos de conexo importantes que iro gerar os
macro-processos.
Ele pode ser desdobrado em outro que ao invs de mostrar os
relacionamentos entre os blocos na empresa, apresenta como
os departamentos esto hierarquizados.
72
Perceba que os dois tipos de diagramas anteriores so relacio-
nados, e uma boa ferramenta de desenho garante que alteraes
em um sejam refetidos no outro.
No devemos nos esquecer de que os processos so feitos e
utilizados por pessoas. sempre conveniente criarmos uma
estrutura organizacional da empresa, que ir identifcar os
vrios departamentos e perfs associados. Podemos partir do
diagrama anterior, focado na hierarquia departamental, e ir
evoluindo at que os vrios perfs departamentais estejam
visveis. H uma correlao direta entre estes perfs e com as
pools e lanes que iro aparecer nos diagramas BPMN, quando
j estivermos em uma fase mais adiantada.
73
9 - Os fuxos de processos
Quando estamos em uma sesso de entrevistas para levan-
tamento de processos, muitas vezes no temos como forar
uma disciplina de forma a coletar as atividades de forma or-
ganizada.
Algumas vezes um entrevistado tambm efetua as mesmas
atividades de forma diferente de outro no mesmo processo,
e pode-se levar grande tempo discutindo o certo ou errado
antes de avanarmos.
O mais simples nestes casos, efetuar um brain storm
levantando todas as atividades que devem ser efetuadas em
um determinado processo.
Ao invs de conduzirmos uma discuo em termos j estru-
turados, as reunies fcam mais leves se primeiro levantamos
todas as atividades a serem executadas, e em um segundo
momento as colocamos em um diagrama com a ordem de
execuo. Desta forma aliviamos a presso imposta pela im-
portncia de um levantamento de fuxo, e a tendncia a erros
minimizada. importante que no exista a presso para
que as informaes sejam fornecidas de forma organizada,
mas sim manter o foco nas atividades componentes. Uma
lista poderia ser algo como :
Seleciona o produto
Coleta dados do cliente
Sugere produtos relacionados
Efetua cobrana no carto
Seleciona forma de retirada
Preenche dados do cliente
Assina protocolo de retirada
Criar listas deste tipo so mais efetivas ao usurio do que j
desenhar efetivamente o fuxo. Desenhar as vrias atividades
em papeis soltos e depois ir colando em uma folha em branco
torna as reunies mais efetivas e menos montonas.
74
10 - As is e To be
Costumamos dividir os desenhos de fuxos em duas fases.
Em primeiro lugar se desenha o fuxo do processo como ele
, sem nenhuma alterao na forma com as atividades so
processadas, por mais obvia que seja a alterao.
Costumamos chamar esta fase de as is. Em um segundo
momento, com o fuxo completamente desenhado, se atua em
sua melhoria, tornando-o mais efciente.
Desta forma teremos o processo desenhado antes e depois
das melhorias. Com estes dois desenhos em mos, podemos
nos utilizar de ferramentas de simulao que iro indicar o
ganho de qualidade obtido com o redesenho.
Principalmente os especialistas focados em anlise e le-
vantamento, quanto maior o conhecimento do negcio,
mais rapidamente vislumbram pontos de processamento
desnecessrios ou duplicados. Isto se deve vivncia no
ramo.
muito importante durante o levantamento de processos
que foquemos em como o processo est atualmente ( as is),
deixando o to be para um momento posterior. Muitas vezes
o usurio do fuxo percebe o erro que est cometendo no mo-
mento deste desenho, e j tenta guiar o desenho de forma a
contemplar esta melhora.
importante que isto no acontea, seno qualquer infor-
mao relativa melhoria ir se perder e anlises futuras
nunca conseguiro ter sucesso no diagnstico.
Isso importante pois ir gerar relatrios de melhorias de
processo, indicando a economia ou aumento de lucro obtido.
O objetivo deste redesenho a melhoria, e o usurio no
deve se sentir culpado por no ter percebido isto antes, pois
afnal ele estava to focado na execuo de seu fuxo dirio
que difcilmente teria como abstrair e imaginar melhores for-
mas de realizar a tarefa.
75
11- Use Cases e processos
Principalmente no momento em que a rea de negcios se
encontra com a TI, para a tranferncia de informaes que ir
permitir a implementao de um sistema baseado no fuxos
de processos, surge uma dvida muito pouco discutida que :
Como uma atividade BPMN est relacionada com elementos
de anlise tradicional, como um Use Case, por exemplo ?
Neste caso, estamos nos referenciando aos Use Cases da
modelagem orientada para objetos.
Na orientao para objetos nosso foco primrio manter den-
tro dos limites de um sistema, normalmente departamental.
Quaisquer interfaces externas costumam ser ignoradas, e
colocadas como caixinhas a serem implementadas no futuro.
Com um exemplo prtico, quando iniciamos a modelagem do
sistema de vendas, raramente nos preocupamos com o sis-
tema de estoque.
Isto o oposto do que normalmente acontece quando uma
empresa se organiza em termos de processos. Para uma
modelagem em torno de processos, pouco importa a qual
departamento uma atividade est relacionada. O que importa
a continuidade do fuxo, passando por vrios departamentos
da empresa at seu trmino.
Um fuxo de processos pode se iniciar como um processo de
vendas na loja e passar pelo controle de estoque em algum
momento, efetivando o pdedido e a reserva do produto.
Por isto se costuma dizer que os sistemas atuais so verticali-
zados (ou seja, giram em torno de um departamento), en-
quanto que os processos permeiam a empresa na horizontal
(ultrapassam vrios departamentos).
Frequentemente se verifca este tipo de desenho :
76
Os mesmos blocos de mais alto nvel dos que compe os
sistemas orientados para objetos, chamados de use cases,
podem ser as atividades de mais alto nvel que compe os
processos. Quando se decompe uma atividade, ela se torna
um sub-processo que na modelagem por processos ir se tor-
nar um diagrama BPMN. Na orientao para objetos, um use
case quando decomposto pode se tornar um diagrama de
atividades, que muito similar ao diagrama BPMN. Veja dois
exemplos na introduo deste livro.
Em resumo, um use case uma atividade de mais alto nvel.
Podemos utilizar as atividades de um fuxo de processos como
insumo para detalhamento dos use cases, gerando os arte-
fatos necessrios para a UML tradicional, como diagramas de
classes e de sequncias.
E se um Use Case essencialmente uma Atividade de mais
alto nvel, podemos utilizar os templates de detalhamento de
use cases que j utilizvamos na UML para descrever como
cada atividade se comporta. Embora um diagrama BPMN seja
muito mais detalhado do que um diagrama de atividades,
ainda no chegamos a um ponto onde possamos omitir o de-
talhamento da atividade.
Utilizando um template para defnio de Use Case j na
modelagem de processos de negcios utilizamos um mesmo
artefato padronizado at os nveis mais baixos, facilitando no
momento posterior da implementao do sistema.
77
78
12 - Concluses
Os objetivos primrios da modelagem de processos de neg-
cios obter entendimentos de como a empresa funciona
internamente.
Os artefatos discutidos, como organogramas, diagramas de
posicionamento, fuxos de processos so formas visuais de
compreender o que as pessoas fazem no dia a dia de suas
atividades, e servem como ponto de partida para outros es-
tudos, como melhorias nos processos e estimativa de custos
por atividades, entre outros.
Durante este entendimento importante formentar discusso,
levantando a poeira do tapete, pois somente desta forma
poderemos de forma correta compreender os processos cor-
porativos.
errado efetuarmos este levantamento apenas com o gerente
da rea, por exemplo, mas se for necessrio, por falta de
tempo dos outros envolvidos, devemos ao menos garantir
que todos esto coniventes com esta viso.

Muitas vezes os funcionrios fazem suas atividades de forma
diferente do que a gerncia imagina, e vice versa.
A modelagem de processos de negcios importante pois
nos faz compreender a empresa e os mecanismos que foram
utilizados para que funcione. fundamental no apenas como
etapa pr desenvolvimento de um sistema, como tambm
para adequao de uma soluo de mercado, como um ERP,
CRM, etc.
79
13 - BPEL e BPMN
Se hoje em dia temos um consenso em termos de notao
para desenhos de processos, que o BPMN, o mais prximo
que temos atualmente de uma notao padronizada para
execuo deste processo o BPEL (ou BPEL4WS).
A sigla o anagrama de Business Process Execution Lan-
guage, e foi criada como uma forma de permitir a or-
questrao de servios Web (Web Services). Como uma
linguagem para execuo de servios, ela formal e no
permite ambigidades.
Uma das idias no mercado que BPEL seja utilizada na ex-
ecuo de fuxos de atividades. Nem todos os fabricantes a
adotam em sua plenitude, e alguns incorporaram modifcaes
para torn-la compatvel com os recursos de seus produtos.
Mas sua fora inegvel, j que at mesmo a especifcao
BPMN na release 1.0 apresentava como fazer mapeamen-
tos para o BPML, outro padro tambm mantido pela mesma
organizao, e j na verso fnal do documento o captulo foi
substitudo pelo mapeamento em BPEL.
Em essncia, o BPEL um arquivo XML. Dentro dele vrios
trechos XML vo indicando o que fazer durante o proces-
samento de um fuxo, defnindo e armazenando variveis. O
BPEL por si s no capaz de executar muita coisa, delegan-
do a responsabilidade para web services.
Se estivssemos comparando o BPEL com um programa tradi-
cional, poderamos dizer que cada subrotina no programa
seria um servio, e o programa principal, que chama em
seqncia cada rotina seria o BPEL. A desvantagem de utilizar
BPEL obvia, j que interpretar um arquivo XML mais lento
do que executar um programa. Mas porque o mercado fala
tanto sobre ele ?
Para uma soluo BPMS, o BPEL traz vantagens. muito co-
mum ouvirmos sobre realinhamento dos processos de neg-
cios, que signifca reajustar um processo ou otimiza-lo para
melhor execuo.
Na maioria das situaes, este reajuste feito apenas na or-
dem em que os servios so chamados. Se a execuo deste
fuxo est em um cdigo, quando necessrio reajuste temos
que alterar o cdigo que executa o fuxo.
Se utilizamos um arquivo XML (BPEL), as alteraes na ordem
de execuo so mais simples, j que no precisamos recom-
pilar cdigos, e ainda podemos manter duas verses no sis-
tema, uma antiga, com os fuxos com a execuo j iniciada,
e um novo, com a nova forma de execuo para os novos
processos iniciados.
Desta forma, testes com o sistema em execuo podem ser
feitos com prejuzo mnimo aos usurios, pois os que haviam
iniciado no fuxo antigo continuam at o fnal do processa-
mento. Isto reduz o impacto nas alteraes, pois no afeta o
que j est em execuo. Se utilizssemos cdigos para fazer
o mesmo processamento, seria muito complicado mantermos
duas verses do cdigo em execuo na mquina. Delegando
para o XML, o prprio engine BPEL pode fazer a distino en-
tre novo e velho.
Para permitir a execuo e at mesmo passagem de parmetros
entre as chamadas, o BPEL possui um conjunto de elementos
para lidar com situaes comuns de programao, como de-
clarao de variveis, atribuio e cpia de valores e chama-
das a servios.
<invoke> - Efetua uma chamada a um servio
<receive> - Fica no aguardo de um servio chamado
<assign> - atribui uma varivel
<reply> - Responde com uma chamada
<throw> - tratamento de excees
<wait> - Fica no aguardo
80
Mas tambm temos elementos que controlam o fuxo, como
ifs, elses e outros tipos de elementos comuns a linguagens de
programao tradicional.
<sequence> - Executa em sequncia
<switch> - Escolhe um caminho para execuo
<pick> - Fica no aguardo de um evento
<fow> - Executa processamentos em paralelo
<while> - Executa um loop
<scope> - Defne um escopo para atribuio ou leitura de
uma varivel
Um arquivo BPEL normalmente tem uma estrutura do tipo :
<fow>
<links>
<link name=XtoY/>
<link name=CtoD/>
</links>
<sequence name=X>
<source
linkName=XtoY/>
<invoke name=A .../>
<invoke name=B .../>
</sequence>
<sequence nameY>
<target
linkName=XtoY/>
<receive name=C/>
<source
linkName=CtoD/>
</receive>
<invoke name=E .../>
</sequence>
<invoke partnerLink=D>
<target linkName=CtoD/>
</invoke>
</fow>
81
14 - O Mapeamento BPMN para o BPEL
necessria uma certa criatividade para mapear elementos
do BPMN para o BPEL. Podemos apresentar um trecho de
cdigo e indicar os impactos no mapeamento :
Este trecho poderia ser mapeado como :
<variable name=contador messageType=loopCounterMes
sage />
<variable name=limite messageType=forEachCounterMes
sage />
<sequence>
<assign name=init_contador>
<copy>
<from expression=0/>
<to variable=contador part=loopCounter />
</copy>
</assign>
<assign name=init_limite>
<copy>
<from expression=10/>
<to variable=limite part=forEachCount />
</copy>
</assign>
<while condition= bpws:getVariableData(contador,loopC
ounter) <= bpws:getVariableData(limite,forEachCount)>
<sequence>
<invoke name=atividade1 ... >
<assign name=incremento>
82
<copy>
<from expression=bpws:getVariableData(contador,l
oopCount)+1/>
<to variable=contador part=loopCounter />
</copy>
</assign>
<invoke name=atividade2 ... >
</sequence>
</while>
</sequence>
Em primeiro lugar, vale salientar que foi criada uma atividade
chamada incremento, com o objetivo de manter o valor du-
rante a execuo do processo. Os dois invokes, que faro as
chamadas aos servios esto envolvendo um assign, que faz o
incremento. Tudo isto est dentro de um while, que garante a
execuo em looping.
Foi inserida dentro do BPEL uma linguagem de expresso,
o que permite a comparao de valores, como em bpws:
getVariableData(contador,loopCounter).
Bem parece que temos tudo o que precisamos, certo ? Bem,
nem tanto assim.
Primeiro a atividade incremento, quando foi mapeada por um
analista de processos provavelmente no foi colocada. Ela
apareceu no momento do mapeamento para BPEL, permitindo
a gerao da rotina de incremento.
Isto faz com que um fuxo desenhado pelo analista ra-
ramente consiga ser mapeado diretamente para o BPEL,
sendo necessrios reajustes, neste caso exemplifcado
com a insero de uma atividade para permitir a conta-
gem.
Outra particularidade oculta, mas a ser considerada que o
BPEL no tm o conceito de pools e lanes. Portanto no h
perfs e se assume que um fuxo ser executado para um
perfl especfco. Isto pode ser um problema para um desenho
mais complexo, e talvez cada lane tenha que ser mapeada
83
Como os fabricantes esto lidando com estas defcincias ?
Como dissemos anteriormente, muitos esto acrescentando
elementos ao padro, de forma a contornar estas incon-
venincias. Isto deve gerar nossa preocupao, pois podem
surgir BPELs e BPELs, cada um com suas particularidades.
Como as empresas lidam com isto em termos de equipe ?
Atualmente a abordagem comum que os analistas que
fazem o levantamento dos processos no se preocupam muito
com a notao (alguns nem mesmo utilizam o BPMN).
No momento em que o fuxo for implementado em uma
soluo BPMS, ser redesenhado para a ferramenta adotada,
seja BPEL ou outra qualquer.
Isto no bom, pois pode causar distores na transcrio,
alm de difcultar o processo de implantao e praticamente
inviabilizar o realinhamento rpido do negcio.
Tambm vale salientar que o invoke no BPEL faz uma cha-
mada um Web Service. Mas e se tivermos interaes com os
usurios ?
Talvez a mais notada proposta no mercado seja o BPEL4PEO-
PLE, proposta pela IBM e SAP, como alterao no BPEL de
forma a permitir interaes entre pessoas. O documento
pblico, e alguns fabricantes esto suportando o padro.
necessrio deixar claro que nem todos os engines BPEL supor-
tam BPEL4PEOPLE, o que faz com que um processo modelado
em BPEL nem sempre possa ser executado em qualquer en-
gine.
Acho que vale salientar que os elementos do BPEL4PEOPLE
so muito diferentes dos elementos BPEL tradicional, e ajustes
profundos nos engines de execuo so necessrios
84
15 - Editor BPMN da revista PortalBPM
Voc pode localizar este editor BPMN no site da revista
PortalBPM (www.portalbpm.com.br), na seo de downloads.
Para que mais uma ferramenta de desenho ?
Bem, esta ferramenta distribuida gratuitamente e contm
todos os smbolos da notao BPMN, o que nem todas as fer-
ramentas tm, gratuita para utilizao, e mais simples que a
mdia das ferramentas.
A ferramenta necessita de uma instalao Java para operar
normalmente. Ela foi testada e homologada na verso de Java
5. Pode-se baixar um JRE, que menor requer menor esforo
na instalao atravs do link http://java.sun.com/javase/
downloads/index_jdk5.jsp.
Ela no foi testada com verses posteriores de Java, e no ir
funcionar com verses anteriores. Uma vez baixado o ex-
ecutvel, pode-se instalar como qualquer aplicativo Windows
normal. Uma instalao tpica pode ser selecionada, e ser
apresentada uma tela como :
85
Aps a instalao, voc ter uma mquina virtual Java que
ser utilizada pelo programa.
A segunda etapa baixar o programa de edio BPMN. Ele
fornecido como um ZIP, que pode ser aberto para qualquer
diretrio do computador. Deve-se criar um diretrio na m-
quina, por exemplo c:\EditorBPMN.
Copia-se o arquivo ZIP para dentro desta pasta, e se extrai o
contedo para dentro deste diretrio. Aps este processo, o
diretrio deve parecer como :
O arquivo editorbpmn.zip pode ser removido sem problemas
agora. A instalao est completa. O executvel EditorBPMN.exe
ir iniciar o programa. Ele pode ser arrastado para o desktop
para que seja criado um atalho, facilitando execues futuras.
Quando se executa o programa, ser solicitado um diretrio
de trabalho, onde todos os arquivos criados sero armazena-
dos :
86
Aps defnido um espao de trabalho, o programa entra em
sua tela principal. A ferramenta foi construda com base no
eclipse, e formada por vrias telas que interagem com a
aplicao.
Para que tenhamos um ambiente customizado para utilizao,
podemos chavear para a perspectiva de edio BPMN. Isto
pode ser feito selecionando os menus Window->Open per-
spective->Other, e seleciona-se Perspectiva edio BPMN,
como a seguir :
87
Aps este chaveamento, a aparncia fcar como :
A ferramenta est pronta para uso. Nas entradas seguintes, a
perspectiva no precisar mais ser chaveada. Se por alguma
razo alguma janela for fechada ou a perspectiva perdida,
pode-se novamente abrir a perspectiva com o procedimento
acima.
Todos os desenhos BPMN fcam dentro de um projeto. Pre-
cisamos criar ao menos um projeto, mas por outro lado po-
demos ter vrios projetos em um workspace. A ferramenta
pode tambm ter vrios workspaces, bastando na entrada se
selecionar diretrios diferentes para cada execuo. A criao
de um projeto feita clicando-se com o boto da direita na
janela Navigator, que est no canto superior direito da tela :
88
Ser solicitado um nome para o projeto, e aps criado ir
apresentar uma aba em navegador, semelhante a uma estru-
tura de diretrios do Windows Explorer.
Dentro deste projeto podem ser criados vrios desenhos
BPMN. Selecionando-se o projeto com o boto direito do
mouse ser apresentado :
89
Ser apresentado um nome padro, com a extenso BPMN,
que pode ser alterado a vontade. A extenso do arquivo de-
ver ser sempre BPMN, e no podem existir dois arquivos com
um mesmo nome dentro de um projeto. Aps criado o arquivo
ele ser aberto na rea de edio, que fca na lateral direita
da janela.
Neste momento, se inicia o processo de edio propriamente
dito.
O processo de edio consiste em selecionar um elemento
visual na paleta de
componentes, atravs de um clique. Depois pode-se mover
o mouse at a rea do editor, e clica-se novamente para que
o elemento seja depositado na rea de edio. O editor de
propriedades indica algum atributo de cada um dos elementos
que pode ser editado.
Uma vez editado, a rea visual alterada imediatamente.
A janela outline permite que vejamos os elementos na tela,
mesmo que estejam fora da rea visual. Quando seleciona-
mos um elemento em outline, ele fcar selecionado na rea
de edio e suas propriedades sero apresentadas.
90
Vamos editar um exemplo simples de BPMN. A partir do editor
aberto, selecionamos uma lane, que est na palete em outros.
Quando se clica em um sub-elemento da palete, ele aberto
e fechado a cada interao. Leva-se a lane para a rea de
edio, e coloca-se na tela a tela fcar como :
Pode-se selecionar o valor de perfl e colocar um valor
signifcativo para a Lane, como Atentende. Imediatamente
o desenho na edio superior refete este valor, bem como a
janela de Outline.
O prximo passo fazer o mesmo com os eventos de incio e
fnal, que devem ser arrastados sobre a Lane. Deve-se fazer
o mesmo com uma atividade simples, que ter seu atributo
texto alterado para Atende cliente. Aps estes passos, a tela
dever estar como :
91
A paleta pode ser aberta ou fechada, bastando-se clicar nela,
ou posicinando-se o mouse por algum tempo sobre ela. Ela
tambm se fecha automaticamente quando no est sendo
utilizada.
Elementos BPMN podem ser arrastados para uma Lane, neste
caso fazendo parte dela, ou seja, quando a Lane arrastada
todos os elementos internos so arrastados em conjunto.
Pode-se tambm arrastar os elementos para uma rea fora
de uma lane, neste caso no pertencendo a nenhuma lane
especfca, funcionando como um processo privado, como ex-
plicado na primeira edio da revista PortalBPM.
Na parte superior da janela pode ser encontrado um selecio-
nador de ZOOM, permitindo aumentar ou diminuir a imagem,
facilitando a tarefa de visualizao de elementos na tela.
A ferramenta permite exportar em formato imagem. Selecion-
ando-se o mouse com o boto direito sobre o editor, em uma
rea no populada (branca), ser apresentada uma opo
exporta diagrama como imagem.
Pode-se apontar o nome do arquivo e ser gerada uma ima-
gem em JPG, que pode ser anexada a outros documentos
textuais, como de requisitos.
Arquivos BPMN podem ser exportados da ferramenta, ou im-
portados para ela.
Clicando-se com o boto da direita sobre um arquivo ou pro-
jeto, sero apresentados menus para exportao e importao.
Isto permite compartilhar desenhos BPMN entre usurios.
Perceba que a cada alterao no diagrama, um asterisco
aparece na lateral do nome do arquivo. Isto indica que o mes-
mo est alterado, e para salva-lo se clica em salvar no menu
(o disquete na toolbar) ou o conjunto de teclas CONTROL+S.
Neste momento o arquivo est salvo.
92
93
16 - Outras ferramentas de mercado
Temos vrias alternativas de mercado para desenho BPMN.
Elas se dividem em ferramentas de desenho BPMN com BPMS
integrado, e solues puras de desenho.
Ferramentas de desenho com suporte ao BPMN
Toguether Borland
BEA Aqualogic
Intalio
System Architect
MetaStorm Provisio
Visual Paradigm
WBI Modeler
Visio
Aris

Atualmente temos cadastradas 44 ferramentas com suporte
ao BPMN, e o nmero cresce a cada dia.
No podemos deixar de citar o movimento Eclipse, que est
construindo uma ferramenta de desenho BPMN sobre o GMF e
GEF.
17 - BPMN design patterns
Da mesma forma que na orientao para objetos, os fuxos
de processos desenhados em BPMN demandam padres de
desenvolvimento (design patterns).
Um design pattern, segundo a defnio, um trecho que
aparece repetidas vezes durante os ciclos de desenvolvi-
mento. Para facilitar a compreenso e garantir uma mesma
linguagem durante as reunies de levantamento, importante
utilizarmos os mesmos termos, evitando desta forma am-
bigidades.
Seqncia de fuxo (Sequence)
Este tipo de design pattern indica uma seqncia de fuxo. O
mais bvio a seqncia, onde atividades so executadas em
uma ordem, uma aps a outra. A representao deste tipo de
fuxo algo como a seguir :
Neste caso, deve estar implcito que existe um token que vai
sendo propagado conforme as atividades vo sendo executa-
das, sejam elas por um mesmo perfl ou por vrios perfs
(lanes) dentro da execuo.
94
No exemplo esquerda, temos um fuxo paralelo no contro-
lado. Quando duas setas saem de uma atividade, isto indica
processamento paralelo. No exemplo da direita, colocamos
explicitamente o gateway de AND.
95
Processamento paralelo (Parallel Split)
Quando seguimos por mais de um caminho ao longo da ex-
ecuo do fuxo, ou se temos atividades com tokens distin-
tos (notao BPMN), chamamos de processamento paralelo
(parallel split).
Isto indica que os dois caminhos so processados de forma
independente. Em BPMN, temos mais de uma forma de repre-
sentao para processamentos paralelos.
No exemplo a seguir, em todos os casos as atividades A e B
iro gerar tokens distintos.
Sincronizao (Synchronization)
Utilizamos uma sincronizao quando desejamos aguardar
pela chegada de mais de um token gerado durante o proces-
samento. Ele a contrapartida do processamento paralelo.
Suas representaes podem ser :
A notao BPMN chama este tipo de padro de Merge. Quan-
do colocamos uma sincronizao desejamos aguardar por um
conjunto de processamentos antes de continuarmos.
Escolha exclusiva (Exclusive Choice) e Unio simples (Simple
merge)
Quando temos uma nica escolha para um dos caminhos de
um fuxo, atravs de um gateway XOR, defnimos este padro
como Exclusive Choice. Sua contrapartida o simple merge,
que ir aguardar pela chegada do nico token, e assim continuar
o processamento. Este tipo de pattern indica que apenas um
token foi gerado durante o processo.
96
Mltipla escolha (Multiple choice) e Mltipla juno (Multiple
merge)
Quando temos um mais caminhos sendo processados em um
fuxo, indicamos atravs do pattern Multiple choice e Multiple
merge.
97
Sobre junes e bifurcaes
Os mecanismos de juno e bifurcao so completamente
distintos, e no necessitam ser utilizados aos pares. Vamos
compreender estes mecanismos atravs de alguns exemplos.
Quando o diagrama contm um gateway para bifurcao ou
juno, dizemos que este ambiente controlado. Quando
existe mais de um fuxo saindo ou chegando a uma atividade,
dizemos que este ambiente no controlado. Se mais de uma
seta de fuxo sai de uma atividade, todos os caminhos so
seguidos, como se fosse um AND.
No exemplo anterior as duas representaes so idnticas
em termos de processamento. Dois tokens foram criados,
seguindo para as atividades B e C. J em termos de juno,
um ambiente descontrolado gera resultados distintos, em ter-
mos de processamento.
Neste exemplo, tanto a implementao 1 como a 2 iro pas-
sar por A, gerar dois tokens que seguiro por B e C.A diferena
que no primeiro exemplo, cada um dos tokens que chegarem
a D iro forar a excuo desta atividade. Portanto, no ex-
emplo 1 D SER EXECUTADO DUAS VEZES. J no exemplo 2,
como foi colocado o gateway para controle do ambiente, D
ser executado apenas uma vez, pois o gateway de juno ir
aguardar a chegada dos dois tokens.
98 99
Mas desejamos s vezes que qualquer um dos tokens que
chegue at a juno faa com que o fuxo continue.
Este pattern comumente chamado de Discriminao (dis-
criminator).
Neste caso, embora dois tokens tenham sido gerados, como a
juno um XOR, o primeiro dos tokens que chegar ao gate-
way far com que o fuxo continue. O outro token, quando
chegar ao gateway ser descartado em termos de processa-
mento.
Desta forma, perfeitamente possvel que a seqncia exe-
cutada para o exemplo anterior seja A, B, D e C, isto mesmo,
com a atividade D terminando antes mesmo da C.
Juno N de M (N out of M join)
Mas, se a sincronizao aguarda por todos os tokens, e a dis-
criminao pelo primeiro que chegar, como podemos desenhar
um fuxo de forma que alguns cheguem at o gateway para
continuar ? Seria o meio termo entre a sincronizao e dis-
criminao.
99
Neste caso, desejamos que o fuxo continue quando as ativi-
dades B e C terminarem, e para isto utilizamos o gateway
complex como juno. Na bifurcao ele funciona como forma
de gerarmos vrias sadas, e na juno como forma de es-
colha para quais elementos devem ser recebidos para que o
fuxo continue.
Ciclo arbitrrio (Arbitrary cicle)
Quando desejamos executar um fuxo um certo nmero de
vezes, mas no temos como precisar quantas vezes ele ser
executado, utilizamos um ciclo arbitrrio. Ele funciona como
uma atividade em paralelo, mas sem que defnamos quantas
vezes ele ser executado.
importante termos conscincia destes patterns, mas acima
de tudo conhecer os mecanismos de execuo, para que no
desenhemos um fuxo que no momento da execuo funcione
de uma forma diferente da esperada, apenas porque seleciona-
mos um gateway de forma errnea.
100