Your SlideShare is downloading. ×
Http  _www.portalbpm.com.br_servlet_leartigo_qual=_web-inf_artigos_livrobpmn_livro_bpmn
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Http _www.portalbpm.com.br_servlet_leartigo_qual=_web-inf_artigos_livrobpmn_livro_bpmn

861
views

Published on

Apostila sobre BPMN

Apostila sobre BPMN


0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
861
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
110
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Copyright @ 2008 by Editora PortalBPM ltda. Direitos desta edição reservados a Editora PortalBPM ltda Av. Sta Catarina, 1396 – sala 4 CEP : 04367-050 Impresso no Brasil por HR GráficaProibida a reprodução, total ou parcial, por qualquer meio ou processso,Seja fotográfico, gráfico ou microfilmagem etc.Estas proibições aplicam-se também nas características gráficas e/oueditoriais.A violação dos direitos editoriais é punível como crime (Código penal,art 184, Lei 6.895/80), com busca, apreensão e indenizações diversas(Lei 9610/98 – Lei dos direitos autorais – arts. 122, 123, 124 e 126)Reis, Glauco dos SantosModelagem de processos de negócios com BPMN – Curso completo /Glauco S. Reis;Revisão técnica – equipe PortalBPMSão Paulo; Editora PortalBPM ltda; 20081. Modelagem de processos de negócios 2.BPMN 3.BPMS
  • 2. PrefácioEstamos vivenciando um período de mudanças profundas, emáreas de conhecimento distintas como processos para desen-volvimento de sistemas e gestão empresarial.Toda uma nova gama de conceitos e ferramentas estão sen-do apresentadas e definidas, e que provavelmente deverãonortear o futuro da TI nos próximos anos.Um destes conceitos, e provavelmente o que gera a maiorconcordância entre os especialistas é a notação BPMN.A sigla BPMN é o acrônimo de “Business Process ModelingNotation”, ou notação para modelagem de processos denegócios.Embora quase não exista discordância quanto à efetividadedo padrão, as documentações são limitadas e a especificaçãooficial é densa e intrincada.A proposta deste livro é explorar a notação BPMN, comodescrita na especificação oficial, sem as particularidadesintroduzidas por cada fabricante.Toda a simbologia será explorada, e estaremos fornecendointerpretação para cada símbolo, erros comuns no desenho,além de discutirmos um pouco sobre mapeamento de proces-sos e design patterns aplicados à notação.Espero que você aproveite a leitura, e que muitas dasdúvidas possam ser sanadas ao longo do livro. Glauco Reis glauco@portalbpm.com.br
  • 3. Sumário 1 - Prefácio 2 - Ferramentas BPMS - 06 2.1- Workflows - 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 negócios - 11 2.7 - Business Process Management Systems - 11 2.8 - Pure players - 15 2.9 - BPMN e Futuro - 153 - Processos - 16 3.1 - UML e BPMN - 164 - Tipos de diagramas BPMN - 185 - Pools e Lanes - 205.1 - Instâncias de processos - 216 - Eventos - 227 - Eventos de timer - 238 - Eventos de mensagem - 269 - Eventos de dados - 2910 - Controles de exceção e compensação - 3111 - Conexão entre diagramas - 3512 -Terminadores do processo - 3513 - Resumo dos tipos de eventos da BPMN - 3714 - Gateways - 3815 - Eventos do tipo XOR (OU exclusivo) - 3816 - Token - 3917 - Eventos AND (E) - 4118 - Eventos OR (OU) - 4119 - Tratamento de eventos - 4120 - Eventos multiplos - 4221 - Eventos Complexos - 4322 - Gateways diretamente em fluxos - 4423 - Atividades e tarefas - 4624 - Loop - 4625 - Múltipla instância - 48
  • 4. 26 - Compensação - 4927 - Ad Hoc - 5028 - Pools e Lanes - 5229 - Artefatos - 5630 - Dados - 5631 - Grupos - 58 Parte IIERROS COMUNS NO DESENHO BPMN - 5901 - Gateways de tipos diferentes na junção e bifurcação- 6002 - Gateways baseados em eventos - 6203 - Utilização de elementos de fluxos com fluxos condicionais- 6304 - Eventos - 6505 - Fluxos, pools e lanes - 6806 - Fluxos, pools e lanes - 6907 - Levantamento dos processos de negócios - 7008 - Processos e Macro-processos - 7109 - Os fluxos de processos - 7410 - “As is” e “To be” - 7511 - Use Cases e processos - 7612 - StoryBoards - 7813 - BPEL e BPMN - 7914 - O Mapeamento BPMN para o BPEL - 8215 - Editor BPMN da revista PortalBPM - 8516 - Outras ferramentas de mercado - 9317 - BPMN design patterns - 94
  • 5. 2 - Ferramentas BPMSAntes de iniciarmos nossa jornada pela notação BPMN, va-mos apresentar como a TI evoluiu até chegamos ao momentoatual, com as chamadas soluções BPMS.As disciplinas de modelagem de processos tiveram grandefoco ao final da década de 80 e início da década de 90, comestudos de cientistas como Michael Porter. Nesta época osestudos mantinham foco em administração de empresas, cen-trando esforços em como as empresas poderiam ser melhora-das em termos de estrutura organizacional. O que se percebiaé que o processo de construção das empresas normalmentese fazia de forma desestruturada, com novos departamentose processos sendo criados sob demanda. Em um mundo nãoglobalizado, isto até que não afetava muito a saúde da em-presa. Mas com a internet e globalização, empresas grandescomeçavam a competir com empresas pequenas de igual paraigual, e a necessidade por uma redução de custos e melho-ria de processos junto ao cliente se tornou necessária comoforma de garantir sobrevivência em um ambiente competitivo.Nesta época, o foco dos estudos era como melhorar osprocessos, e embora houvessem vários esforços isolados porparte da TI para solução destes problemas, estes esforçosainda não estavam integrados para formar o conceito quehoje conhecemos como soluções BPMS. 2.1 - WorkflowsEram muito conhecidas na década de 80 como “ferramentasde colaboração”. Uma implementação de destaque foram assoluções da Lotus, que acabaram sendo incorporadas posteri-ormente aos produtos da gigante IBM.A necessidade por organizar de alguma forma a comunicaçãoentre as pessoas, transferindo responsabilidades ao longo doprocesso era e até hoje é fundamental em qualquer tipo deempresa. O nome das ferramentas de colaboração se tornouchamativo, e o conceito de workflow se firmou e se mantématé hoje. 6
  • 6. Na verdade, inúmeras empresas vendem soluções de work-flow como se fossem soluções BPMS hoje no mercado, mas hádiferenças que até hoje os especialistas tentam explicar. Deuma forma geral, um workflow é uma das peças que compõeuma solução BPMS.Em uma ferramenta de workflow existem dois conceitos prin-cipais : o motor de execução e a ferramenta de definição deprocesso ou fluxo.Estas ferramentas de definição inicialmente foram criadas deforma textual, indicando os participantes e em que ordem elesexecutariam atividades. Com o tempo, conforme as própriasnotações para processos evoluíram, todo um conjunto de no-tações gráficas, como IDEF, BPMN, UML, grafos, entre outrosforam utilizadas como forma de representar visualmente estesprocessos em execução em um Workflow.O consorcio WfMC foi notadamente um destaque, propondouma especificação utilizada até hoje por muitos provedores desolução BPMS. 2.2 - BPMNEntre os padrões comentados, a notação de destaque naatualidade é o BPMN (Business Process Modeling Notation),que estaremos explorando nos próximos capítulos destelivro. Além de mais moderna que notações como IDEF e UML,também possui um rico set de elementos gráficos para rep-resentação de uma série de situações que acontecem nosfluxos dos processos. O padrão está em evolução e longeda perfeição, mas de todas as notações da indústria é o quemantém a maior concordância da indústria.Infelizmente, o padrão BPMN é uma notação gráfica paradesenho de processos, e não está associado a nenhum for-mato de armazenamento específico. 7
  • 7. Houve uma tentativa de utilizar a força da organização queestava com credibilidade muito forte pela criação do padrãono sentido de firmar outro padrão, o BPML (Business ProcessModeling Language), que seria um formato binário para arma-zenamento e execução dos processos criados em BPMN.Esta tentativa foi frustrada por outro padrão já em estágiomais avançado de adoção, chamado BPEL. 2.3 - BPELA linguagem BPEL (Business Process Execution Language) éhoje uma forte candidata a ocupar o padrão como notaçãopara execução de processos. Infelizmente, da mesma formaque um motor de fórmula 1 não pode ser colocado seminúmeras adaptações em um veículo comum de mercado, omesmo pode-se dizer em relação ao BPMN mapeado paraBPEL (com o BPMN como o motor neste exemplo).A notação BPMN é muito completa e sua evolução se deuem torno das necessidades que aparecem no dia a dia dosdesenhos dos processos, enquanto que o BPEL foi criado comoum padrão para permitir que um motor pudesse orquestrarfluxos baseados em Serviços Web (Web Services).Em outras palavras, os caminhos seguiram em paralelo e comfocos diferentes em mente. Há todo um esforço no sentidode tornar o BPEL ideal como formato de armazenamento dosdesenhos BPMN, mas hoje os fabricantes adotam duas formu-las para o mapeamento :1)Reduzir o número de elementos gráficos disponíveis, paramanter a conversão para o BPEL viável. Isto ajuda se tiver-mos em mente apenas a execução do processo, mas limita oanalista de negócios, se a ferramenta de desenho for a mes-ma ferramenta que irá operacionalizar os fluxos.2)Incorporar novos elementos ao BPEL, permitindo que todae qualquer representação BPMN possa ser desenhada semproblemas. Isto traz um inconveniente ao BPEL, pois o mesmofoi criado para ser totalmente interoperável, e no momentoem que cada um dos fabricantes incorpora novidades, os mo-tores para execução tendem a se tornar incompatíveis. 8
  • 8. O que se espera nos próximos anos é que uma evolução nosdois padrões venha a surgir, ou que outro formato de arma-zenamento se firme como padrão para desenho. Ainda háuma perspectiva futura que é a criação da notação BPDM, umformato intermediário entre o BPEL e o BPMN. 2.4 - SOA e Web ServicesAnteriormente comentamos que o BPEL foi criado como umpadrão para orquestração de serviços WEB. Esta foi outragrande inovação introduzida a partir das limitações encontra-das nos paradigmas atuais da orientação para objetos. Pormais que tentemos reaproveitar os códigos criados a partir daOO, o grau de acoplamento entre eles ainda é muito forte, etorna difícil o reaproveitamento de códigos de forma corpora-tiva.A arquitetura WEB Java, com seus módulos EAR, WAR, JAR,SAR, RAR, etc. também não facilitam o reaproveitamento decódigos.A idéia dos Web Services, que posteriormente foi promovidaa arquitetura SOA, propõe que os componentes sejam cria-dos e “soltos” dentro de servidores de aplicação, de formaque diversos programas se beneficiem de sua utilização, semque necessitem ser incorporados fisicamente a um programaespecífico.Se esta promessa de componentização se concretizar, teremosum novo patamar de reutilização na indústria. Não há garan-tias de que este terá sucesso, mas os indicadores atuais sãomuito promissores.Bom, imaginando um cenário ideal teremos os desenhos dosfluxos sendo criados em BPMN e salvos ou mapeados paraBPEL, que por sua vez fará com que serviços web sejamorquestrados. Então já temos tudo o que é necessário parauma solução BPMS ? Bom, nem tudo ainda. 9
  • 9. 2.5 - DashBoardsO sonho de consumo de qualquer empresário é poder con-trolar de forma ativa sua empresa, identificando como osprocessos estão durante a execução, tempos de execução decada atividade, e outras informações. Se todas estas infor-mações puderem ser apresentadas em gráficos de fácil com-preensão, melhor ainda.É um conceito semelhante ao de BI (Business Inteligence),onde dados são analisados nas empresas e medidas são to-madas para melhoria dos processos.A idéia de BI ou mineração de dados trabalha com dados apóso fato estar consumado, ou seja, após o gasto já ter concreti-zado. Este controle a que nos referimos é pró-ativo, ou seja,devemos coletar dados ao longo da execução de um fluxo deprocesso, e estudarmos os dados antes mesmo do término daexecução do processo.Este estudo precisa ser feito de forma facilitada, pois temospouco tempo para tomada de decisão. Por isso deve ser visualem formato de gráfico.Nas soluções BPMS, colocamos termômetros dentro do fluxo,e medimos estes termômetros apresentando gráficos quesumarizam a evolução do processo.Isto é chamado de Dashboard, e é uma peça fundamentaldas soluções BPMS. Precisamos corrigir eventuais distorçõesno fluxo bem antes do final, para que possamos garantir aeconomia e redução nas perdas. Sem este termômetro, épraticamente inviável descobrirmos se há algo errado ou mes-mo onde devemos corrigir no processo durante sua execução.Será necessário a execução do processo para que possamosdepois da execução encontrar as falhas.Esta melhora precisa acontecer a todo momento, e um termomuito utilizado para descrever esta melhoria contínua é“realinhamento dos processos de negócios”. 10
  • 10. 2.6 - Realinhamento dos processos de negóciosCom todas estas ferramentas dentro da empresa, com osdesenhos criados com BPMN, sendo orquestrados por umworkflow, executando Web Services com BPEL, e que vãosendo analisados momento a momento para encontrarmospossíveis problemas e pontos de melhoria, através dosDashboards, precisamos de um mecanismo para podermosrealinhar rapidamente, ou seja, resolver rapidamente estesproblemas para que o fluxo continue fluindo da forma espe-rada.Para isto, não é tolerável aguardar meses por alterações naTI, para que um código funcione como esperado.O que se espera das melhores soluções BPMS é que sejamuito fácil introduzir modificações, com poucas alterações efacilidade nas alterações dos códigos. Isto não é um conceitosimples de implementar, e parece que quanto mais visuais asferramentas se tornarem, mais rapidamente conseguiremoseste realinhamento desejado. 2.7 - BPMS Business Process Management SystemsPois bem, uma solução BPMS reune as inovações e tecnolo-gias anteriormente citadas. Uma definição para o BPMS pode-ria ser :“Uma solução BPMS permite a geração e controle dosprocessos de negócios da empresa, proporcionandorápida tomada de decisão e realinhamento dos proces-sos de negócios de forma agilizada.”Um pouco subjetivo não é? Mas é o que o homem de negóciodeseja. Em um mundo globalizado e competitivo, os prazosdefinidos pelas metodologias OO e outras não estão mais semostrando satisfatórios. Mas podemos ler nas entrelinhas dadefinição, e deduzir algumas coisas : 11
  • 11. 1) Uma ferramenta BPMS deve permitir o desenho dosprocessos de forma visual, sendo que as melhores ferramen-tas suportam o BPMN. As boas ferramentas têm programaspróprios de desenho incorporado. Ser visual é importantepois traz agilidade ao gerenciamento do processo. Imaginea quantidade de erros que apareceriam se manipulássemosdezenas ou centenas de arquivos XML de forma manual.2) O suporte ao padrão BPEL4WS não é obrigatório, mas asferramentas que o suportam fornecem algumas vantagens.Em primeiro lugar, você pode utilizar qualquer editor que gereo formato. Segundo, os processos ficam armazenados emformato XML, o que é mais adequado e proporciona maior in-teroperabilidade. As desvantagens estão do fato de o BPEL serorientado para Web Services. Ou seja, não se pode orquestraruma chamada a um EJB através desta tecnologia, a menosque o EJB seja publicado como serviço.3) É um concenso que as ferramentas devem suportar servi-dores de aplicações. Algumas criaram os próprios servidorespara execução. O ideal seriam ferramentas que suportassemservidores .NET ou J2EE, pois são os mais consagrados.Naturalmente, a tecnologia J2EE permite multiplataforma, eisto por sí só já é vantagem. Criar um servidor específico enão utilizar a base J2EE é um erro, pois o grau de maturidadedos servidores J2EE é muito alto. Além disto os servidoresincorporam uma série de recursos, como escalabilidade esegurança, e estes recursos podem ser reaproveitados pelosBPMS.4) Toda ferramenta deve permitir o controle do processo. Estecontrole pode acontecer antes de o processo ser executado(através de simulações) e também durante a execução, paradetecção de falhas no processo em operação (Dashboards).Ou seja, antes de publicar o processo devemos poder simulá-lo, para verificar se está como previsto, e durante a execuçãodevemos o ser capazes de extrair métricas para correção comfacilidade. 12
  • 12. Deve ser possível não só publicar novas versões do processo,como também permitir que as versões antigas continuem en-quanto houverem atividades ainda sendo processadas. Isto énecessário, caso contrário será difícil realinhar os processsosde negócios rapidamente. Não podemos esperar o término daexecução dos processos (o que pode levar dias ou meses),para colocar uma nova alteração em execução. Processosantigos devem continuar executando como previstos, e novosprocessos devem já ser executados de acordo com o novodesenho.5) Um recurso muito apreciado pelas áreas gerenciais são osDashboards, que são gráficos gerenciais, tomados dos proces-sos em execução, e que permitem verificar visualmente quan-do algo não vai bem. Isto ajuda na tomada de decisão. Umacaracterística dos Dashboards é que eles tendem a ser muitodinâmicos, e portanto deve ser fácil criá-los e alterá-los semdemandar grandes esforços da TI.6) Quando dizemos rápido realinhamento nos processos denegócios queremos dizer que o alterações devem se efetivarcom custo mínimo de tempo. Uma das vantagens divulga-das pelas ferramentas BPMS é poder gerar resultados maisrápidos do que os conseguidos até então com as metodolo-gias tradicionais. Se para alterar um processo de negócio fornecessário acionar uma equipe de desenvolvimento gigantes-ca, que terão que criar códigos novos para cada Web Serviceinserido, não estaremos resolvendo um dos problemas que atecnologia se propõe a resolver, que é gerar uma rápida res-posta aos problemas do negócio.Neste sentido, atualmente existem dois paradigmas sendoadotados pelos grandes fabricantes.O primeiro é o de ferramentas onde apenas o processo égerenciado visualmente. 13
  • 13. Os componentes de negócios, sejam eles Web Services,CORBA, EJB são criados manualmente, através de ferramen-tas como Eclipse, NetBeans, WSAD, Sun Studio ou outros, quepodem até estar integrados à ferramenta geradora de fluxos.O segundo tipo de ferramenta, embora não tenha toda a flexi-bilidade de manipulação de códigos da primeira alternativa,adota um paradigma totalmente visual de construção, ondeaté mesmo os objetos de negócios são construidos visual-mente.A vantagem deste segundo tipo é a velocidade no realinha-mento, com poucos códigos gerenciáveis.É bem verdade que este tipo de paradigma deve evoluir paraalgo mais flexível do que os mecanismos atuais. E ferramen-tas geradoras de código devem evoluir para alternativas ondeo processo de construção seja mais ágil.7)Ferramentas que permitem criar telas visualmente trazemagilidade ao processo de mudança, principalmente quando aatividade exige interação humana.Um workflow não pode mais ter telas simples, com campostextuais sem formatação. A identidade visual da empresaprecisa ser mantida durante a execução do processo. Ou seja,as ferramentas devem permitir a criação de telas complexas,de preferência de forma visual.8) Ferramentas que suportam apenas componentes WebServices são limitadas atualmente, embora esta seja umapromessa futura. O ideal são ferramentas que agreguem al-gum tipo de EAI, que permita integrar vários tipos de compo-nentes do legado. Perceba que isto se contrapõe à adoção deBPEL4WS, já que o padrão apenas suporta WS.9) Um elemento importante, que se esquece com frequência,é 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 definir organo-gramas de forma visual, integrando estes organogramas commecanismos computacionais trazem vantagens. 14
  • 14. Infelizmente, a maioria das ferramentas ainda têm limitesneste quesito. Manter as informações de usuários disponíveislivremente, em qualquer ponto da corporação, também é umavantagem.Quase todas as soluções BPMS mantém os usuários e senhasem estruturas dentro da própria ferramenta, ao invés de bus-car em uma base relacional externa ou servidor LDAP.Também a maioria não permite edição visual do organogramada empresa. 2.8 - Pure playersAlguns institutos de pesquisa (Gartner Group, por exemplo)se utilizam do termo “pure player”, para ferramentas que sãoBPMS puros, sendo que os demais são ferramentas que vêmde algum nicho de mercado pré existente. Algumas ferra-mentas são Workflows ou EAIs que estão em evolução parao paradigma BPMS. Algumas empresas têm ferramental dedesenho (BPMN) e estão evoluindo para se enquadrarem nacategoria BPMS. Este termo foi criado para tentar reduzir apanacéia em relação aos diversos fornecedores que desejamter sua ferramenta seja considerada BPMS “pure player”. Umaferramenta do tipo “pure player” tende a ser melhor, já quefoi criada com o espírito destas idéias desde o início. 2.9 - Futuro e BPMNVale a pena gastar esforços no padrão BPMN agora? Bem, sevocê for um analista de negócios este provavelmente será opadrão dominante para desenho nos próximos anos. Se vocêé da área de TI, é muito provável que a operacionalizaçãodos fluxos seja feita através de uma evolução do BPMN, commais elementos programáticos incorporados. Mesmo que opadrão dominante continue sendo a UML, há uma perspectivade evolução da notação para que incorpore o BPMN como umaevolução dos diagramas de atividade. 15
  • 15. 3 - Processos 3.1 - UML e BPMNPara que necessitamos de mais uma notação para desenho deprocessos? Será que as notações existentes, como os diagra-mas de atividade da UML, já não contemplam também estetipo de representação ?Eles representam muito bem etapas na execução de um “UseCase”, ou mesmo um trecho mais complicado de uma rotina.Os fluxos de processos de negócios têm se mostrado muitomais complexos a cada dia, e a notação UML embora sejamuito formal, deixa a desejar em termos de diversidade grá-fica, além de utilizar as mesmas simbologias para o tratamen-to do negócio e para tratamentos de erros, que normalmentenão fazem parte do negócio em si. Em diagramas maiores atendência é confundir e dificultar a visualização e manutençãodos fluxos.Para tornar isto mais claro (e visual), vamos utilizar o exem-plo de apontamento de viagem, explorado na documentaçãooficial BPMN. Veja o mesmo exemplo modelado de duas for-mas : 16
  • 16. BPMNO que se pode observar em primeiro lugar é que, no casoda UML, como não existem mecanismos de compensação egeração de erros, somos obrigados a utilizar elementos dedecisão para indicar o fluxo em caso de erro.Neste caso fica mais difícil identificar qual elemento estásendo utilizado como parte do tratamento do negócio, e qualdecisão foi inserida como desvio para tratamento de erros,dificultando a manutenção.O mesmo irá acontecer quando outros elementos, como timers emensagens são adicionados ao diagrama. Eles isolam el-ementos de interação dos processos de tratamentos da lógicade negócios, de forma mais clara. Além disto, o próprio fatode a imagem já ser representativa, torna mais claro o entend-imento pelo cérebro do que aquele desvio ou evento faz.Em resumo, um diagrama BPMN torna mais claro o entendimen-to e adiciona elementos gráficos que facilitam a compreensãodo que está acontecendo no diagrama. 17
  • 17. 4 - Tipos de diagramas BPMNCada um dos tipos de diagrama é chamado de BPD(“Business Process Diagram”), mas têm nomes mais espe-cíficos, de acordo com seu detalhamento.Algumas vezes desejamos entender em profundidade comoum fluxo opera, e outras vezes desejamos apenas transmitirao leitor do diagrama como dois fluxos distintos operam. Parapermitir esta divisão em categorias temos três tipos de dia-gramas :Os “Private Business Process” ou Diagramas de processosprivados, que utilizamos quando não é relevante representar-mos como diferentes fluxos interagem. Estamos preocupadosapenas com o teor deste fluxo em si.Existem os “Abstract process” ou Processos abstratos. Emum processo abstrato, não estamos preocupados com o con-teúdo do fluxo em si, mas sim como ele colabora com outrosfluxos dentro de um sistema. 18
  • 18. Já nos “Colaboration Process” ou Processos colaborativosdesejamos obter um grau maior de detalhamento, apre-sentando como dois ou mais fluxos se comunicam.Podemos imaginar estes três tipos de diagramas como sendoum só, onde características podem ser apresentadas ou não,dependendo do que desejamos visualizar. Imagine um progra-ma de CAD com uma imagem de um veículo, onde podemosvisualizar sua aparência externa (equivalente ao diagramaabstract) ou as peças que o compõe (equivalente ao diagramaprivate). A especificação não dita regras de como cada imple-mentação de ferramenta deve operar, mas parece que a for-ma mais intuitiva seria a de que cada diagrama pudesse serchaveado para apresentar seus elementos internos ou não.Um aspecto ainda a explorar é como estes tipos de diagramasafetam o mapeamento para um fluxo de processos.Um processo BPEL é representado por um processo privado,por exemplo. Para que tenhamos a colaboração entre proces-sos em BPEL, necessitamos de mais de um arquivo BPEL,cada um mapeado para um processo privado. Em resumo, umdiagrama BPMN pode ser mapeado para mais de um arquivoBPEL. Normalmente um arquivo BPEL é mapeado para apenasum diagrama BPMN. 19
  • 19. 5- Pools e LanesConforme um fluxo vai sendo executado, ele passa por váriasatividades.Em um mundo real e colaborativo, as atividades sãoatribuídas a pessoas ou perfis diferentes, ao longo de suaexecução. Documentos necessitam ser aprovados porgerentes ou coordenadores, e vendedores necessitam inserirpedidos no sistema.Cada um destes “perfis” são identificados dentro do BPMN emelementos chamados pools ou lanes. A pool seria a piscinaonde os competidores nadam. As lanes são as raias, ondecada nadador irá se apresentar. O resultado do processamen-to, neste caso, será o conjunto de processamentos das váriaslanes (o nadador que chegar em primeiro lugar do outrolado).O conceito de pools e lanes está muito preso aos mecanismosde segurança das soluções BPMS. Um vendedor pode inserirum pedido, mas apenas um coordenador pode aprovar umacompra através de cartão de crédito. Quando o fluxo é modeladojá se considerando os pools e lanes, fica mais fácil no futuroorganizarmos os vários perfis que irão executar cada uma dasatividades.Mas, qual a diferença entre um pool e uma lane ?Bem, o pool define um fluxo de processo, onde em seu inte-rior o processamento ocorre independentemente do queacontece ao seu redor. Um pool é como se fosse um móduloou programa independente de um sistema. Imaginando oexemplo de uma piscina, se ela estiver dentro de um estádio,várias outras atividades esportivas podem estar acontecendosimultaneamente, mas a competição dentro da piscina in-depende destas outras atividades que acontecem simulta-neamente no estádio. Já uma lane define o perfil que estáexecutando a atividade em dado momento. Via de regra, umapool define um processo, enquanto que a lane define osparticipantes que irão concretizar este processo. 20
  • 20. 5.1 - Instâncias de processosImaginando que temos um desenho de processo pronto,surge a dúvida do que seria uma instância de processo. Umainstância é uma execução isolada de um processo.Um programa instalado em um computador é como se fosseum processo. Já as várias instâncias em execução seriam osprogramas executando em dado momento em um computa-dor.Cada vendedor dentro de uma loja, atuando em seu processode vendas é uma instância de processo isolada. Todos seguemos mesmos passos, mas cada um de forma independente.A longevidade de uma instância de processo é muito variada,podendo ir de minutos a décadas para processamento.Ou seja, uma vez iniciado um processo, ele se mantém (oudeveria se manter) em execução até que seu término fosseatingido.Se estivermos imaginando um processo executando em umcomputador, é importante que esta característica seja preser-vada, ou seja, se o computador for desligado, quando forreiniciado deve retornar ao mesmo ponto em que estavaanteriormente.De forma similar, diversas instâncias de um mesmo processopodem estar ativas ao mesmo tempo. Uma loja de varejo,onde existam vários vendedores, cada um deles pode estarconduzindo uma instância de processo de vendas, de formatotalmente independente.Algo deve “acontecer” para que o processo inicie uma instân-cia, e o mesmo para que ele seja finalizado.Processos são iniciados e terminados através de eventos. Umavez iniciado, deve acontecer um evento que o finalize. 21
  • 21. 6 - EventosDe acordo com a especificação BPMN, os eventos aparecemdurante a execução de um fluxo ou são gerados durante suaexecução. Somente os eventos têm a capacidade de iniciar outerminar um processo, mas os eventos não executam tarefasno processo. Eles podem forçar a execução ou mesmo desviarpara uma determinada atividade.A representação gráfica dos eventos é feita por círculos, quepodem ser de três tipos: 1) iniciais 2) intermediários 3) finaisOs eventos de início forçam a criação de uma nova instânciade execução para o fluxo. Antes dele, não existia esta instân-cia de processo em execução. Algum fato gerador externo irácausar a geração do evento. O início do processo por si só éum evento.Os eventos intermediários acontecem ou são gerados ao longoda realização de um fluxo já em execução. Podem ser geradospelo fluxo em execução ou podem ser receptores de um even-to gerado por outra intância.Quando são criados dentro do próprio fluxo (geradores)provavelmente irão gerar alguma notificação a alguma outrainstância de fluxo em execução. Quando são gerados exter-namente ao fluxo de processo em execução (receptores), irãoinfluenciar de alguma forma a execução de outro fluxo.Existem os eventos finais, que terminam a instância doprocesso. Após um evento final, nenhuma outra atividadepode ser executada, embora o próprio evento possa gerarinformações que afetem outros fluxos em execução. 22
  • 22. Devemos ter em mente que os fluxos funcionam como or-ganismos vivos, podendo existir vários deles em execuçãosimultânea, e cada um se comunicando com outros por meiode eventos. A única forma de uma instância de fluxo comu-nicar-se com outra é mediante o envio e recepção de eventos.Para podermos diferenciar os eventos de início, intermediárioe final, de forma visual, existem representações gráficasdistintas para cada um deles. Um evento de início é um cír-culo com uma linha simples em sua borda, um evento inter-mediário é representado por um círculo delineado por linhasduplas, e um evento final é delineado por um círculo comlinha de espessura dupla. Veja os tipos de eventos existentes.O set completo BPMN define, além desses três tipos, o fatogerador do evento, ou seja, o causador da execução do evento.Estudaremos os vários fatos geradores, iniciando-se com oseventos de timer. 7- Eventos de timerOs timers permitem controlar o tempo ou definir datas paraexecução de atividades.Um evento de início de timer indica o início da execução deum fluxo em períodos predeterminados de tempo. Um iníciode timer pode demarcar uma data específica, como todo úl-timo dia do mês (para processamento de uma folha de paga-mento); pode indicar uma hora específica, como às dez horas(para iniciar um backup, por exemplo); pode indicar uma datae hora, como dia 23 de janeiro de 2008 (lançamento do livro“Modelagem de Processos de negócios com BPMN”); comotambém pode ser um evento relativo à data atual (cinco horascontando a partir deste momento). 23
  • 23. A Figura anterior indica um evento de início. Uma soluçãoBPMS de mercado fica validando, normalmente, cada eventode início, verificando se ele coincide com o momento atual.Quando se encontra uma situação de início, inicia-se umainstância do processo.Um evento intermediário de timer pode operar de duas for-mas. Se ele estiver no meio da execução do fluxo, interli-gando duas atividades, como na figura a seguir, significa umatraso inserido entre a execução das duas atividades.Isso indica que após a atividade “Aguarda cadastro” o fluxoficará “congelado” pelo tempo definido pelo relógio antes decontinuar a próxima execução, que é “Continua processa-mento”.Mas um timer intermediário pode igualmente estar ligado àborda de uma atividade e irá indicar, nesse caso, um “códigode proteção”. Se acontecer a condição antes do término daexecução da atividade, o processamento será desviado para aatividade que estiver conectada ao fluxo. 24
  • 24. No exemplo anterior, uma atividade solicita o recadastramento,mas pode levar um tempo até que seja executada pelousuário, assim como pode ficar para sempre no aguardo, jáque o usuário pode nunca se cadastrar. Nesse caso, o eventode timer significa dizer que, se o usuário não realizar a ativi-dade em até cinco dias, a atividade “Remove usuário” seráexecutada. Caso ela seja realizada dentro desse prazo, “Re-move usuário” nunca será executada e o processamentocontinua por “Cadastra dados no sistema”. Em qualquerdos dois casos, o processamento continua por “Próximasatividades”.Outra modalidade, nessa representação, seria a de não ter acontinuação do fluxo, e forçar sempre a saída pelo mecanismode exceção.Nesse caso, mesmo após a execução de “Solicita recadas-tramento”, o fluxo fica no aguardo do final dos cinco diaspara continuar por “Remove usuário”. Funciona como se oevento estivesse conectado entre as duas atividades.Basicamente, executa-se um evento timer “atachado” à bordade uma atividade quando se atingiu o período limite ou a dataconfigurada antes do final da execução da atividade. Percebaque pode ser também um sub-processo, com diversas ativi-dades em seu interior, como na figura a seguir. 25
  • 25. No exemplo da figura anterior, pouco importa o número deatividades existentes dentro de “Cadastro e validação”.Quando se atingir o tempo final de cadastramento, cessa osub-processo “Cadastro e validação”, e continua o proces-samento, por meio de “Distribui as atividades”. Forçamosa execução da exceção sempre, pois é a única saída para ofluxo neste caso.Deve-se tomar cuidado com este tipo de abordagem, poisse o desvio acontecer pelo timer, o sub-processo pode ficar“truncado”, e a especificação não dita regras para o que acon-tece com os códigos já processados dentro da atividade.Não está definido nem faz sentido um evento de timer comofinalizador. 8 - Eventos de mensagemUma mensagem é um mecanismo de envio de informaçõesentre instâncias de processos. A notação BPMN não define oque se utilizará como tecnologia para envio, como SMTP, JMSou qualquer outro mecanismo, como também não define oformato das informações a serem enviadas. Uma imple-mentação específica de solução BPMS fará o tratamento maisadequado ao processamento de mensagens.Os eventos de início de mensagem criam uma nova instânciade processo, baseado no recebimento de uma mensagem. 26
  • 26. Na Figura anterior, temos dois fluxos de processos. Quandoo fluxo superior se inicia e quando a Atividade1 é executada,para um evento intermediário que significa envio de men-sagem. Um evento de mensagem entre duas atividades podeser fonte geradora, como no caso anterior, onde será enviadaa mensagem e o fluxo 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á forçar acriação do fluxo inferior.Neste caso, se inicia uma nova instância. Mas após o envio damensagem no fluxo superior, o mesmo continua a execuçãoda atividade2, e os dois fluxos executam em paralelo e deforma completamente independente. O único momento emque houve comunicação foi no momento do envio de mensa-gens, que causou a criação de uma nova instância de fluxo. 27
  • 27. No exemplo da figura anterior, acontece uma série de even-tos-mensagem. Primeiro, a partir de uma atividade envia-seuma mensagem que inicia outra instância de processo. Isso éfeito em “Solicita débito ao banco”. A notação dita que umevento de mensagem na borda deve ser receptor. Uma men-sagem saindo diretamente de uma atividade indica que existeum evento de mensagem sendo gerado por esta atividade.Na seqüência do fluxo, a atividade “autoriza retirada naloja” envia uma mensagem para o fluxo abaixo, que deveriaestar no aguardo para continuar o processamento. Uma vezrecebida a mensagem, a atividade “retirada do produto naloja” é executada, e os fluxos finalizam.Embora não esteja claro, os fluxos anteriores são inde-pendentes, ou seja, estão posicionados em pools diferentes.Isto pode ser afirmado porque a comunicação entre eles estásendo feita por mensagens, e não seria possível enviar men-sagens se as atividades estivessem dentro de um mesmopool.Pode-se dizer que são dois fluxos colaborativos.Quando a atividade está posicionada na borda, como noexemplo a seguir, existe uma outra interpretação possível. 28
  • 28. No exemplo anterior, o evento de mensagem na borda daatividade “Retirada de produto na loja” está posicionadona borda. Esta representação indica um fluxo de exceção demensagem. Após a “operação de débito”, existe um OR,o qual indica que se tomará um dos dois caminhos. Caso setome o caminho de erro no processamento (aquele que geraa mensagem), quando a mensagem chega até “Retirada doproduto na loja”, gera-se um desvio, com base no recebi-mento dessa mensagem. Nesse caso, a operação é cancelada,visto que o fluxo de exceção foi acionado.Em resumo, existem dois comportamentos para atividades demensagem conectadas à borda. Quando o fluxo sai do evento,indica exceção e somente pode ser utilizado posicionada naborda de uma atividade. Quando a mensagem chega até umaatividade, indica que esta atividade estava no aguardo do re-cebimento para continuar o processamento.Cabe salientar que esse é o comportamento padrão definidopela especificação, que até deixa alguma dupla interpretaçãopara este tópico. 9 - Eventos de dadosPodem-se utilizar eventos de dados como início e intermediário.Quando utilizados no início de um processo, indicam que secriará uma instância do processo, quando um valor atingir de-terminado patamar. O modo como os dados são conectados àsolução BPMS e o número de vezes que essa solução verificapelos valores ficam sob completa responsabilidade da imple-mentação BPMS. Lembre-se de que o BPMN é uma notaçãográfica, sem pretensões de como será executado. 29
  • 29. Um processo automatizado de compra de materiais poderiainiciar um subprocesso de compra de papel para impres-sora quando fosse detectado, no estoque, a existência deum número baixo de pacotes de folhas. Quando colocado naborda de uma atividade, sempre indica um fluxo de exceção.Ou seja, quando estiver dentro da atividade, se o patamar foratingido, o fluxo seguirá pelo caminho de exceção. Veja umexemplo na figura a seguir.Nesse caso, o sub-processo “Cadastro de alunos” fica emexecução coletando novos alunos para um novo curso. Ele so-mente sai desse loop quando uma de duas coisas acontecer.Ou o tempo para inscrição se encerrou, o que se denota comum timer, ou o número máximo de alunos por sala foiatingido, o que se indica pelo evento de dados. Como nãoexiste continuação do fluxo depois de “Cadastramento dealunos”, será necessário que uma das duas exceçõesaconteça, para que o fluxo continue por meio de “Finalizaprocesso de cadastramento”.Este tipo de evento pode também ser utilizado como iníciopara um processo ou sub-processo. Por exemplo, quando olimite do estoque está baixo, automaticamente o processo decompras se inicia, como no exemplo a seguir. 30
  • 30. Não é permitido que um finalizador gere um evento de dados,ao menos na especificação atual do BPMN. 10 - Controles de exceção e compensaçãoNa maioria das situações, o BPMN será utilizado paraorquestrar Web Services. Nesse cenário, surge um problema,pois os Web Services são atômicos e síncronos. Isso querdizer que, uma vez chamado, um serviço será executado seestiver disponível, e o resultado do processamento persistiráimediatamente. Em resumo, não há rollback de Web Services.Imagine uma seqüência de chamadas a serviços que precisamoperar em forma de bloco, de forma a efetivar todos ao mes-mo tempo ou a cancelar todos como uma unidade. Como umserviço é atômico, foi necessário criar mecanismos que permi-tissem que grupos de serviços pudessem ser “desfeitos”, casoalgum deles apresentasse algum problema.Como parte da especificação BPMN, existe um controle deexceções e compensações criado sob a forma de eventosgerados. Basta conectarmos a borda de uma atividade com-posta por várias atividades que devem ser atômicas, a umevento especial que atuará como captura de erros que acon-tecem. Quando se efetuar o desvio para essa outra atividade,os processamentos efetuados poderão ser desfeitos, de modoque se retorne o processamento ao estado inicial. 31
  • 31. Vale salientar que, nas implementações de bancos de dadosatuais, esse mecanismo não funciona como nos rollbacksBPMN, que nem sequer chegam a alterar as informações. Emresumo, as tecnologias de EAI estão mais modernas do queo mecanismo de compensação proposto pela especificaçãoBPMN.Em vez disso, na implementação de compensação do BPMN osdados são alterados e depois retornam aos valores originais,através de uma atividade especial de compensação, o quepode acarretar efeitos colaterais quando utilizamos serviços apartir de código legado. A figura a seguir ilustra a represen-tação desse mecanismo.Nesse caso, coletam-se os dados do cliente e efetua-se acompra de passagem. Duas atividades precisam ser executa-das: efetuar a reserva no vôo e a cobrança do valor. Casofalhe algum desses serviços, acontecerá um desvio para acompensação, que irá garantir que o valor nunca será cobradoou que o avião não decolará com o assento reservado, porémvazio. Se por outro lado, os dois serviços forem executadoscom sucesso, o processamento continuará em “Avisa clienteda operação”. 32
  • 32. Eis uma pergunta de cunho maldoso: e se ocorrer uma falhaao estornar o valor ao cliente? Podemos capturar esse erroe direcioná-lo a uma atividade que irá efetuar o tratamento.Nesse caso, o erro é mais grave e o chamamos de exceção,que precisa de atenção especial. Pode-se representar umaparte do desenho acima da seguinte maneira:Nesse caso, houve um erro na compensação, e solicitou-seintervenção manual da operadora, a fim de evitar resultadosmais graves. Podemos unir a compensação e a exceção emapenas uma atividade, como ilustra a figura a seguir. 33
  • 33. Nesse caso, a sub-atividade “compra de passagem” pode-se formar por “pela cobrança da passagem” e pela alo-cação. Caso ocorra algum erro no processamento de umserviço, este se desviará para a compensação, que por suavez tentará desfazer o processo. Se ainda dentro de “comprade passagem” ocorrer um erro grave, será gerada a exceçãoque enviará uma mensagem ao operador do sistema, o qualfará uma intervenção manual.As compensações são erros não tão graves, onde se tentacorrigir o problema, retornado a um estado possível deexecução. Já os erros são mais graves, e exigem um trata-mento especial.A forma como as soluções BPMS tratam esses erros e com-pensações é definida por sua implementação. Entretanto, anotação permite uma representação visual mais simples erepresenta erros de forma visual; erros que, de outra forma,teriam que ser representados como parte do fluxo, mas nadatem a ver com as regras de negócios. Se não tivéssemos acompensação e as exceções, teríamos um trecho como o dafigura a seguir.Nesse caso, prevemos o tratamento de um erro por meio deelementos condicionais; o que é ruim, pois os condicionaisdeveriam representar apenas decisões relativas à lógica denegócios. Quando se utilizam condicionais para representartanto a lógica quanto os tratamentos de erros, tornam-secomplexos os diagramas e, com freqüência, de difícil com-preensão. Quando se utilizam compensações e exceções,usam-se elementos diferentes para cada representação nodiagrama. 34
  • 34. 11 - Conexão entre diagramasAlgumas vezes o diagrama se torna tão extenso que não con-seguimos conectar certas partes, sem que as linhas fiquemcruzadas. Existe um mecanismo simples de link, que permiteconectar elementos dentro de um diagrama, ou mesmoelementos entre dois diagramas distintos. Informamos quedois links estão conectados através de seu nome. O nomefunciona como se fosse uma chave para os dois links. Um linkpode ser representado como : 12 - Terminadores do processoExistem atualmente três formas de finalizarmos um processo.As três representações possíveis são : 35
  • 35. O primeiro tipo, com um circulo preenchido no interior, indicatérmino incondicional. Isto significa que o processo deve serterminado neste momento, sem compensação, tratamento deerros ou quaisquer outros tratamentos.Se for um sub-processo, encerra imediatamente e retorna aofluxo pai.O término com um X no interior indica cancelamento datransação. Os mecanismos de compensação e erros trabalhamem conjunto com o cancelamento. Normalmente o cancela-mento é iniciado programaticamente, enquanto que a com-pensação e exceção são geradas por erros no processamento. 36
  • 36. Supondo um sub-processo escolha, sendo que desdobradose torna um fluxo como o da parte superior da figura. Caso aescolha do usuário for inválida, será gerado o cancel, que écapturado pelo evento cancel conectado à borda da atividade.Neste caso, se redireciona para um outro tratamento, onde aseleção não escolhida será tratada como se fosse uma ex-ceção. 13 - Resumo dos tipos de eventos da BPMN 37
  • 37. 14 - GatewaysGateways são os mecanismos padronizados do BPMN paraefetuarmos desvios. Os vários tipos de desvios, como AND(E), OR (OU) e XOR (OU exclusivo) são tratados com simbo-logias distintas pela notação. Assim como os eventos sãorepresentados por círculos, os gateways são representadospor losangos. 15 - Eventos do tipo XOR (OU exclusivo)Os eventos do tipo XOR (OU exclusivo) podem ser represen-tados de duas formasEste tipo de gateway é o mais simples de se entender, pois elerepresenta o OU, onde o acesso a um dos caminhos é exclu-sivo. Ou seja, apenas um dos caminhos será seguido, nãoimportando quantos caminhos existam para escolha.Um exemplo deste tipo de representação poderia ser a es-colha do tipo de pagamento de um produto : 38
  • 38. Neste caso, o pagamento será feito via transferência bancáriaou por cartão de crédito.Qualquer dos caminhos tomados, haverá uma junção nafrente, fazendo com que o fluxo continue após um dos caminhos.Este caso é de fácil compreensão, pois apenas um doscaminhos é seguido. Existem situações onde mais de umcaminho pode ser seguido (OR) ou mesmo todos os caminhosserão sempre seguidos (AND). Neste caso, para poder explic-ar melhor o conceito do que acontece nestes casos, a especifi-cação utiliza o termo TOKEN.Precisamos entender este conceito para compreender os outrostipos de gateway. 16 - TokenImagine que uma instância de fluxo de processos foi criada.Neste caso, a execução segue pelo caminho natural deexecução, mas como existem gateways que permitem maisdo que um caminho em paralelo, podemos ter dois caminhossendo executados ao mesmo tempo, dentro de uma instânciade processo. Veja este exemplo : 39
  • 39. O processamento se inicia normalmente, com a criação dainstância. Podemos chamar neste caso T1 a instância emexecução. O problema é que quando passamos pelo AND (ogateway com sinal de mais dentro) dois caminhos são segui-dos em paralelo, representados neste caso por T1A e T1B. Seestivéssemos nos referenciando a linguagens de programação,teríamos o processo em execução (T1) e duas “threads” exe-cutando em paralelo. É exatamente este o conceito de Token.Mas, se é equivalente à uma thread, porque não chamá-ladiretamente por este nome ?Bem, em primeiro lugar o termo thread diz respeito a umalinguagem de programação, e neste conceito os dois braçosde execução (T1A e T1B) não precisam estar realmenteexecutando ao mesmo tempo. A notação BPMN não força aque uma implementação de solução BPMS tenha todo o con-ceito de multi-thread embutido dentro dela.Mas a notação diz simplesmente o seguinte :“Uma vez criados mais de um token a partir de umabifurcação, o processamento somente continua apóstodos os tokens chegarem até a junção”.Esta frase abre margem para mais de uma interpretação, eem nenhum momento estamos dizendo que a execução estáacontecendo em paralelo. Dissemos que os dois braços deexecução precisam chegar ao ponto de encontro, para que oprocessamento continue após a junção do gateway.Desta forma, uma solução multi-threaded pode executar“seleção de produtos” e “consulta serasa” realmente emparalelo, o que seria interessante, mas também pode execu-tar primeiro a atividade “seleção de produtos”, depois aatividade “seleção de forma de pagamento” e depois aatividade “consulta serasa”, para somente então continuarapós a junção do gateway. Perceba que para qualquer dasduas implementações, não há diferença aparente em termosde processamento, a não ser pela menor velocidade das ativi-dades sendo executadas de forma seriada. 40
  • 40. Paralelo ou não, necessitamos de um conceito para indicaresta independência criada pelo conceito de bifurcação e nova-mente dependência criada pela junção.Com este conceito de Token em mente, podemos explorar osoutros tipos de gateway existentes. 17 -Eventos AND (E)Este caso é exatamente o exemplo anterior. Quando se chegaaté a bifurcação do tipo AND, se seguem os dois caminhos,através de dois tokens criados. Não há processo de decisão,e todos os caminhos são seguidos. O objetivo de utilizaçãodo AND pode ser tentar otimizar o tempo de processamento,permitindo interações em paralelo pelos vários perfis deexecução. 18 - Eventos OR (OU)Os eventos do tipo OU permitem que se navegue por um oumais caminhos durante o fluxo de execução. Ao contráriodo OU exclusivo, pode-se seguir um ou mais dos caminhos. Énecessário que ao menos um dos caminhos seja válido paranavegação. 19 - Tratamento de eventosOutra necessidade decorrente da especificação BPEL são oseventos múltiplos. Imagine uma situação em que um processa-mento deve aguardar o acontecimento de um evento.Na verdade, pode acontecer uma de várias possibilidades deevento. Esse evento pode ser o recebimento de uma men-sagem ou um timer expirando depois de dois dias. Nessecaso, há duas possibilidades de eventos.A primeira que acontecer continuará o processamento, e asoutras opções são canceladas. Veja um exemplo na figura aseguir. 41
  • 41. 20 - Eventos multiplosNesse caso, o médico solicita um exame e duas são aspossibilidades: o cliente pode fazer o exame solicitado e retor-nar ao médico, ou o cliente pode ignorar a solicitação e diri-gir-se a outro médico. Caso o cliente faça o exame, o médicoemitirá uma receita com base nos resultados. Caso não hajaretorno, a ficha do cliente será arquivada. Nos dois casos, oprocessamento continua pela notificação do plano de assistên-cia médica.Vale salientar que, após adotar uma possibilidade, ignora-se aoutra. Caso o resultado dos exames seja enviado ao médico,nunca ocorrerá o arquivamento da ficha do cliente.Esse tipo de estrutura é chamada de decisão complexa base-ada em eventos e corresponde ao elemento “pick” da BPEL.Claramente a documentação indica que a implementação desteelemento foi no sentido de facilitar a migração de desenhoscriados em BPEL. 42
  • 42. 21 - Eventos ComplexosAlgumas vezes nenhum dos três tipos de gateways (OR, ANDe XOR) é suficiente para representar uma situação. Os gate-ways testam uma única condição, mas algumas vezes neces-sitamos testar mais de um dado para tomada da decisão.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 saídas pode efetuar testesdistintos, e decisões podem ser tomadas de forma mais com-pleta. Outra utilização para este tipo de elemento existe quan-do precisamos saber se uma determinada saída foi escolhida,em função de outras escolhas. 43
  • 43. Neste caso, podemos ter compras à vista, em dinheiro ou àprazo. Caso a compra seja à vista ou em dinheiro, o caminhoseleção de brinde também é executado. Caso a compra sejaa prazo, seleção de brinde não é executado. Desta forma,uma saída pode tomar decisões em função de outras saídas.Os outros tipos de gateway não permitem este tipo de com-portamento. 22 - Gateways diretamente em fluxosEmbora obscuro, podemos representar gateways diretamentena saída das setas que saem das atividadades. O diagramase torna de mais difícil leitura, mas reduz a quantidade degateways.Quando a saída de um fluxo contém um losango, significa queuma decisão deve ser aplicada. Quando a seta contém umcorte diagonal, significa que é a saída default. Se a seta nãocontiver nenhum destes dois elementos, significa que o caminhodeve ser seguido. Se houver mais de um caminho, todos elesdevem ser seguidos. Portanto, as duas representações aseguir são idênticas, em termos de BPMN. 44
  • 44. No primeiro caso, a saída da atividade segue por doiscaminhos, o que significa que há uma bifurcação. No segundo,está representado através do gateway uma bifurcação. Parajunções, o processo é o mesmo, ou seja, duas setas chegandoa uma atividade representam a junção de um AND.Para elementos do tipo XOR, seria algo como :No primeiro caso, o losango indica uma condição, que se nãofor respeitada, fará com que o fluxo siga pelo caminho de-fault, para evento 3. Esta representação é similar ao desenhoda direita, mas utilizando o gateway para XOR. 45
  • 45. 23 - Atividades e tarefasUma atividade é uma unidade de trabalho em um processo.Pode significar uma interação com o usuário, ou algum proces-samento independente do perfil. Quando a atividade é tãoisolada que não faz mais sentido subdivisões, ela é chamadade tarefa. Uma tarefa, portanto, é uma particularização doconceito de atividade. Da mesma forma, um sub-processo éum tipo de atividade onde sabidamente existe pelo menos umgrau de detalhamento em seu interior. Se fôssemos dividir emtemos de hierarquia, poderíamos pensar no processo comosendo a atividade de mais alto nível (algumas vezes chamadode macro-atividade). O processo é dividido em atividadesmenores, chamados sub-processos. Estes sub-processos vãosendo cada vez mais detalhados, até que chegamos em umnível onde não há mais detalhamento, este chamado de tarefa(task). De forma geral, qualquer tipo de atividade é represen-tado por um quadrado com as bordas arredondadas. 24 - LoopAlgumas vezes necessitamos executar repetidas vezes umaatividade, como por exemplo calcular o imposto para cada umdos produtos de uma lista de compra. Poderíamos utilizar umtrecho de código para indicar este cálculo, algo como : 46
  • 46. Basta colocar um condicional, normalmente um XOR, e umacondição para que o fluxo tenha uma saída. Para este caso,poderíamos representar através de uma atividade do tipoloop, de forma mais sintética.Em muitas situações o loop irá executar uma seqüência detarefas, portanto podemos utilizar um loop associado aoelemento de sub-rotina, que é representado por um sinal desoma na representação. 47
  • 47. O padrão BPMN recomenda que uma sub-rotina tenha o si-nal de soma na parte inferior, e caso seja “clicado” deveriase expandir, apresentando uma miniatura do diagrama quenormalmente estaria em seu interior. Este comportamentonão é obrigatório, mas parece ser a forma mais intuitiva detratamento deste tipo de elemento. 25 - Múltipla instânciaOutra forma de representação para o loop é a execução demúltiplas instâncias. Neste caso, a representação é de duasbarras verticais dentro da atividade. 48
  • 48. A diferença básica entre as duas representações é a formacomo cada um dos elementos é tratado. No loop, os elemen-tos são tratados um a um, mantendo sempre um único tokenativo. No caso do processamento paralelo, para cada um doselementos a ser tratado é gerado um novo token, fazendocom que cada um dos elementos tenha um tratamento inde-pendente, causando o processamento em paralelo nas imple-mentações que suportem multi-thread. Na verdade, a escolhapor um ou outro tipo de simbologia pode trazer impactos naimplementação. Se necessitarmos sumarizar um valor, comono exemplo anterior de calculo de imposto, o loop é reco-mendado. Caso os elementos possam ser tratados de formatotalmente independente (lembre-se de que cada token podeser tratado como uma thread por uma linguagem de pro-gramação) podemos utilizar o paralelo. 26 - CompensaçãoA compensação é um tipo de atividade focada na execuçãode um roolback, ou retornar o estado de um processo a umestado anterior, para que o processo possa ser executado.Ele normalmente é utilizado em conjunto com o evento decompensação, que redireciona para esta atividade quandonecessário. 49
  • 49. Repare os dois triângulos dentro do evento de compensação,neste caso “Libera assento alocado” e “Estorna valorcobrado”. Eles indicam este tipo de atividade como umacompensação. 27 - Ad HocHá uma grande discussão na internet sobre o BPMN sercapaz de representar situações de uso corriqueiro em termosde processos. O contra exemplo mais utilizado é aquele de umescritório de advocacia, lidando com um processo de cliente.Embora existam várias atividades a serem executadas, comocópias autenticadas de documentos, obtenção de assinatu-ras, agendamento de audiências, entre outros, muitas vezesnão temos como garantir em que ordem estas atividades irãoacontecer. O importante é que todas elas estejam finaliza-das para que possamos passar para uma etapa seguinte. Omesmo pode ser aplicado à tarefa de escrever um livro. Nãonecessariamente há uma ordem para sua escrita, desde quetodos os capítulos estejam prontos para sua publicação. Umaatividade do tipo Ad Hoc é identificada por um “til” dentro,mas as atividades em seu interior são soltas, ou seja, nãoestão conectadas. Considera-se o final da atividade Ad hocquando todas as atividades em seu interior tiverem termi-nado.A simbologia para este tipo de atividade é a seguinte : 50
  • 50. Veja um exemplo de atividade do tipo Ad Hoc 51
  • 51. 28 - Pools e LanesPools são “compartimentos” onde os elementos do fluxo sãoacomodados, de forma a indicar que participante do processoou um perfil está executando cada atividade. De forma geral,a pool ou lane não interfere nem define o que será feito, massim quem o fará. Está associado a mecanismos de segurançanormalmente.A especificação não define o tipo de elemento, que pode serum departamento, perfil ou pessoa.A representação recomendada é de uma caixa, com uma linhavertical separando os elementos de um título para o pool oulane.Uma pool é o elemento mais externo, ou seja, não se podeinserir pools dentro de pools. As lanes são elementos quesão posicionados dentro de pools, para indicar mais de umperfil que colaboram para a execução de um processo. 52
  • 52. Se os elementos internos de uma pool ou lane são represen-tados, ele pode ser um diagrama privado ou de colaboração(leia o capítulo processos). Se por outro lado os elementosnão estiverem visíveis, mas apenas como dois pools colabo-ram, chamamos de diagrama de colaboração.Cada pool é considerado um fluxo isolado, e a única formade elementos entre dois pools se comunicarem é através demensagens. Ou seja, não é permitido fluxos entre doiselementos do tipo pool.Podemos visualizar duas pools como duas instâncias deprocessos distintas, onde a única forma possível de interaçãoé o envio de mensagens, onde esta mensagem enviada podeinterferir no outro fluxo, caso este fluxo tenha sido preparadopara o tratamento desta mansagem. No conceito de Tokens,existe ao menos um Token para cada pool, e estes Tokensnunca se encontram, ou seja, cada um permanece em suainstância de processo até o término de algum deles. Não háformas de se encerrar vários pools ao mesmo tempo. 53
  • 53. O máximo que podemos modelar é enviar uma mensagem deum pool para outro, e modelar o segundo fluxo de forma queo processo também seja encerrado.Em resumo, dois pools são como que dois programas to-talmente distintos, onde a única forma de comunicação éatravés do envio de mensagens.De forma similar, os mecanismos de mensagens foram criadospara envio de informações entre dois processos distintos. Nãofaz sentido, e a especificação julga ilegal enviar mensagensdentro de uma mesma pool.Esta restrição parece a mais fácil de compreender, se pensar-mos em termos de tokens. No momento em que estamos naatividade1, existe apenas um token. O fluxo de processo irácontinuar pela execução de atividade 2 e atividade 3 mantendoum único token. Mas, em atividade 1 estamos enviando umamensagem para atividade 3, que somente será executada lána frente.Qual o sentido de enviar uma mensagem para uma atividadeque não têm a capacidade de executa-la no momento ? Lem-bre-se de que o envio de mensagens não desvia o fluxo, e aatividade receptora somente pode trata-la se estiver proces-sando ou aguardando por ela. Portanto não faz sentido enviarmensagens dentro de uma mesma pool. 54
  • 54. Se estamos trabalhando com pools abstratos (aqueles quenão mostram os elementos internos) pode ser interessantemostrar os pontos de conexão entre duas pools, portanto épermitido enviar mensagens entre atividades de dois pools oumesmo mensagens de um pool diretamente ao outro.Neste exemplo, deve ficar claro que não é “financial insti-tution” quem está enviando mensagens para o outro fluxoabaixo, mas sim uma de suas atividades internas. Como nãoestão visíveis quais são estas atividades internas, se moveu arepresentação da mensagem para a borda da pool. 55
  • 55. 29 - ArtefatosArtefatos são elementos extras que podem aparecer dentrodo diagrama, mas que não alteram o fluxo nem executamtarefas. Eles servem como representações que irão aumentara clareza do diagrama ou expor certos pontos importantes. Anotação define um set reduzido, mas outros elementos pode-riam ser acrescentados pelas implementações de ferramentas. 30 - DadosEmbora não seja preocupação do BPMN, algumas vezes dese-jamos tornar claro por quanto tempo e até onde um elementode dados está sendo propagado. Este dado pode ser umainformação isolada ou mesmo um bloco de informações.No exemplo a seguir, desejamos deixar claro que os valoresestão sendo sumarizados, e poderão ser utilizados em umponto a seguir no desenho dos processos. 56
  • 56. A linha conectando o artefato de dados à atividade e ao con-dicional pode indicar que o elemento é válido durante aqueleperíodo de tempo, representando a longevidade da infor-mação.Também pode informar que um dado passou de um estadopara outro, como no exemplo a seguir :Na verdade, os elementos de dados podem funcionar comocoringas que representam a informação, onde quer que elaesteja. 57
  • 57. 31 - GruposGrupos não afetam o fluxo de processos nem adicionam re-strições. Da mesma forma que os elementos de dados, elesagrupam atividades e outros elementos de forma a tornarvisíveis blocos importantes de operação. São meramente posi-cionais, e portanto é permitido que um grupo atravesse duaspools, como no exemplo a seguir. 58
  • 58. Parte IIERROS COMUNSNO DESENHOBPMN 59
  • 59. 1 - Gateways de tipos diferentes na junção e bifurcaçãoNormalmente utilizamos um mesmo tipo de bifurcação ejunção, como no exemplo a seguir :Isto garante que os tokens gerados serão sincronizados nasaída. No exemplo anterior, foi criado um AND, que fez comque as atividades seguissem em paralelo. Na junção do fluxoserá aguardado o término dos dois tokens, para que o proces-samento continue. Isto funciona desta forma porque a bifur-cação de AND gera tantos tokens quantas forem as saídas, ea junção aguarda por todos os tokens gerados para continuarapós o processamento.Temos alguma flexibilidade nesta utilização, mas devemosutilizar com cuidado.Uma possibilidade é a de adotarmos gateways de tiposdiferentes, para junção e bifurcação. Ligeiramente diferente, oexemplo anterior ficaria : 60
  • 60. Neste caso, dois tokens serão gerados para “paralela 1” e“paralela 2”. Mas o token de junção é um OR, o que significaque a primeira das atividades que chegar ao fluxo fará comque o mesmo continue. Quando o segundo token chegar atéa junção, será descartado, já que o fluxo já continuou assimque o primeiro Token foi detectado. Neste caso, pode não sertão grave, a menos que as atividades após o gateway neces-sitem de informações ou dados gerados por alguma das duasatividades. Neste caso, como não sabemos qual irá terminarprimeiro, corremos o risco de seguir adiante sem termos osdados consolidados para utilização.Mas, nesta mesma linha podemos cometer um erro grave,que poderá causar impacto muito sério na execução do fluxocriado.Neste caso, apenas um token será gerado com absolutacerteza, já que a bifurcação é um XOR. Entretanto, coloca-mos um AND na junção, que irá aguardar pela chegada dosdois tokens, embora apenas um tenha sido criado. Acabamosde gerar um dead lock, que fará com que qualquer fluxo quepasse por este trecho permaneça travado pela infinidade. Estetermo (dead lock) é utilizado para um trecho em execuçãoque causa um travamento, impossibilitando a continuidade daexecução.Outra modalidade de erro pode causar inconsistências noprocessamento, podendo ser até mais grave do que um deadlock. 61
  • 61. Neste caso, foi gerado um token, mas este não passou pelajunção, chegando a um ponto mais distante do código. Não édifícil se criar fluxos com alguns níveis de gateways, tornandototalmente imprevisível o resultado de processamento dosmesmos.Portanto, algumas regras podem salvar erros em um fluxo :1) Utilize bifurcações e junções do mesmo tipo2) Garanta que uma atividade que passou por umabifurcação continuou o fluxo passando por uma junção 2 - Gateways baseados em eventos 62
  • 62. Os gateways baseados em eventos foram criados com o obje-tivo de permitir que um fluxo fique no aguardo de um evento,para continuar. Uma atividade não é um evento, e portantoesta representação não é permitida.Outra particularidade sobre esta representação é que o gate-way fica no aguardo de um dos eventos acontecer, e continuaapós a recepção do primeiro dos eventos. Todos os outroseventos são descartados após a execução deste caminho. Estetipo de condicional baseado em eventos é um XOR (OU exclu-sivo) pois somente um caminho é seguido.Ao contrário dos outros gateways, este não necessita de umajunção para sincronizar os tokens. Veja um trecho de fluxoaparentemente inválido, mas correto sob ponto de vista danotação.No caso anterior, caso o caminho seja o braço mais inferior, oprocessamento termina com o envio de uma mensagem. Sequalquer dos outros caminhos for seguido, o fluxo segue até ofinal do processamento.3 - Utilização de elementos de fluxos com fluxos condicionais 63
  • 63. Não faz sentido utilizar as notações de condicional e defaultconectados à saída de um gateway, como no exemplo ante-rior. Ou utilizamos o gateway, ou utilizamos os fluxos direta-mente na saída da atividade, utilizando desta forma a notaçãoalternativa.Fluxos não podem sair de gateways, como no exemplo anteri-or, nem mesmo chegar a ele. De uma forma geral, mensagensnão podem ficar contidas dentro de pools. Todas as mensa-gens devem cruzar uma pool e atingir outro fluxo externo.Embora pareça evidente, não podemos ter gateways com ape-nas uma saída. Eles são pontos de decisão, e devem forneceralternativas ao caminho do fluxo. 64
  • 64. 4 - Erros comuns no desenho BPMN – EventosA notação dita que os eventos de início apontam para ocomeço do fluxo, e eventos de finalização terminam um fluxo.Não é obrigatório que existam eventos de início e final, masse existirem, devem aparecer aos pares. O seguinte exemploportanto não é permitido :Por outro lado, podemos ter vários inícios para um fluxo, e seconveniente, podemos representar mais de um final.Quando um fluxo é iniciado, caso não existam os eventos deinício todas as atividades que não tiverem uma seta chegandoaté ela são considerados pontos de início para o fluxo.Quando uma instância de fluxo é criada, são criados tantostokens quantos forem os pontos de início do fluxo.Outro erro comum relacionado aos eventos é que apenasmensagens ou atividades são geradores e consumidores demensagens. 65
  • 65. Neste caso, um timer não pode ser o gerador de uma men-sagem.Mensagens são geradas por atividades e podem chegar aoutras atividades ou a elementos de evento de mensagens.Mensagens intermediárias não podem gerar mensagens. Oexemplo a seguir está errado, portanto.Em resumo, é correto enviar mensagens a partir de ativi-dades, mas não podemos gerar mensagens a partir de eventosintermediários, estejam eles atachados à borda de uma ativi-dade ou não. Como receptores, entretanto, esta restrição nãoexiste.Um evento de timer não pode ser um finalizador de processo,afinal isto estaria significando que o processo estaria termi-nando “após um certo tempo”. Embora fosse bastante con-veniente e útil, um evento de modificação de dados tambémnão pode ser um finalizador. 66
  • 66. Da mesma forma, os eventos de tratamento de erro, comoexception, error e compensação não podem ser utilizadoscomo eventos de inicialização.Por fim, os tratamentos de exceção são representados porsetas de fluxo, e não de mensagens. Apenas lembrando quetratamentos de exceção são aqueles que saem das bordas deuma atividade, como no exemplo a seguir. 67
  • 67. 5-Fluxos, pools e lanesUm fluxo deve se iniciar e continuar até o final do processa-mento. Não podem haver interrupções em sua representação.No caso anterior, não podemos “transferir” o controle paraoutro processo, e receber novamente o controle em outroponto do fluxo, através de mensagens.Vale repetir que entre pools a comunicação é feita entre men-sagens. Dentro de um mesmo pool, a comunicação é feita at-ravés de fluxos de processo, que devem se iniciar e conduzir aseqüência através das atividades até o final do processamento.Dentro de uma pool, existe um único fluxo de processos.Quando um fluxo de processos é instanciado, todos os pontosde início recebem o processamento, criando-se tantos tokensquantos forem os pontos de entrada. 68
  • 68. 6 - Fluxos, pools e lanesUma exceção do tipo compensação deve desviar para umaatividade do tipo compensação, e apenas uma. As seguintesrepresentações portanto não são válidas.No primeiro caso, o desvio acontece para uma atividade co-mum, e não uma compensação. Uma exceção do tipo com-pensação deve apontar para uma atividade do tipo compen-sação.No segundo caso, o desvio acontece para uma atividade queestá ligada a outra compensação. Isto também não é permiti-do, e todo o tratamento da compensação deve ser feito emsomente uma atividade (ou sub-atividade) do tipo compen-sação. 69
  • 69. 7 - Levantamento dos processos de negóciosAs técnicas para levantamento de processos de negócios nãosão muito diferentes da modelagem tradicional de sistemasorientados para objetos.Normalmente a modelagem de processos aparece como umaetapa anterior ao desenvolvimento de um sistema, como for-ma de compreender os mecanismos do negócio em questão.Muitas vezes eles nem mesmo se desdobram em sistemas,servindo apenas como desenhos para otimização dos processosda corporação.Na maior parte do tempo, o levantamento de processos éfeito através de entrevistas com usuários do sistema e nor-malmente geram artefatos que irão amadurecer para gerardocumentos oficiais do sistema. O BPMN, neste caso, será umdos artefatos gerados para representação das informações.Perceba que a notação BPMN nem de longe é completa e umasérie de outros diagramas e documentos são normalmenteutilizados para entendimento do problema. Qualquer ferra-menta de mercado, como Provision, MSVisio ou EnterpriseArchictect, Intalio e outros fornecem uma série de outros dia-gramas auxiliares para o desenho dos processos de negócios.Qualquer empresa fornecedora de uma ferramenta consultadairá apresentar sua “fórmula” para desenho de processos,quase sempre focada nas características de sua própriaferramenta.Por isto iremos expor ao invés de uma metodologia, práticasque podem ser utilizadas de forma a ajudar no levantamento.Vamos propor uma série de idéias, e você pode manter emseu poder, como um canivete suíço, utilizando-as durante umlevantamento, quando julgar mais conveniente. 70
  • 70. 8 - Processos e Macro-processosOs desenhos de processos iniciam em uma camada superiorde desenho, e vão sendo evoluídos (o correto seria detal-hados) em níveis menores.O nível mais alto que encontraremos são os macro-processosde uma empresa. O nível mais baixo que encontraremos seriauma atividade, que não pode ser subdividida.Imaginando que tenhamos iniciado neste momento nossasatividades, e não temos sequer os macro-processos da em-presa. Especialistas costumam salientar que os macro-processos de uma empresa tendem a ser poucos, de umnúmero que varia entre 7 a 15, mais ou menos. Não souadepto de números mágicos, mas se uma empresa propõea existência de 200 macro-processos, é provável que tenhaocorrido o que chamamos de decomposição funcional, ouseja, um macro processo foi detalhado em sub-processos.Uma técnica que ajuda a descobrir os macro-processos deuma empresa é a criação de um diagrama de posicionamento.Ele posiciona a empresa, os clientes e parceiros dentro deáreas na tela, indicando o relacionamento entre cada umadestas áreas. Desta forma, cada uma das setas encontradasdentro deste tipo de diagrama tende a se tornar um macro-processo. Um exemplo deste tipo de diagrama pode ser ob-servado a seguir : 71
  • 71. Através deste tipo de diagrama, que pode ser feito emconjunto com os responsáveis pela companhia consegue-seidentificar pontos de conexão importantes que irão gerar osmacro-processos.Ele pode ser desdobrado em outro que ao invés de mostrar osrelacionamentos entre os blocos na empresa, apresenta comoos departamentos estão hierarquizados. 72
  • 72. Perceba que os dois tipos de diagramas anteriores são relacio-nados, e uma boa ferramenta de desenho garante que alteraçõesem um sejam refletidos no outro.Não devemos nos esquecer de que os processos são feitos eutilizados por pessoas. É sempre conveniente criarmos umaestrutura organizacional da empresa, que irá identificar osvários departamentos e perfis associados. Podemos partir dodiagrama anterior, focado na hierarquia departamental, e irevoluindo até que os vários perfis departamentais estejamvisíveis. Há uma correlação direta entre estes perfis e com aspools e lanes que irão aparecer nos diagramas BPMN, quandojá estivermos em uma fase mais adiantada. 73
  • 73. 9 - Os fluxos de processosQuando estamos em uma sessão de entrevistas para levan-tamento de processos, muitas vezes não temos como forçaruma disciplina de forma a coletar as atividades de forma or-ganizada.Algumas vezes um entrevistado também efetua as mesmasatividades de forma diferente de outro no mesmo processo,e pode-se levar grande tempo discutindo o certo ou erradoantes de avançarmos.O mais simples nestes casos, é efetuar um “brain storm”levantando todas as atividades que devem ser efetuadas emum determinado processo.Ao invés de conduzirmos uma discução em termos já estru-turados, as reuniões ficam mais leves se primeiro levantamostodas as atividades a serem executadas, e em um segundomomento as colocamos em um diagrama com a ordem deexecução. Desta forma aliviamos a pressão imposta pela im-portância de um levantamento de fluxo, e a tendência a errosé minimizada. É importante que não exista a pressão paraque as informações sejam fornecidas de forma organizada,mas sim manter o foco nas atividades componentes. Umalista poderia ser algo como : • Seleciona o produto • Coleta dados do cliente • Sugere produtos relacionados • Efetua cobrança no cartão • Seleciona forma de retirada • Preenche dados do cliente • Assina protocolo de retiradaCriar listas deste tipo são mais efetivas ao usuário do que jádesenhar efetivamente o fluxo. Desenhar as várias atividadesem papeis soltos e depois ir colando em uma folha em brancotorna as reuniões mais efetivas e menos monótonas. 74
  • 74. 10 - “As is” e “To be”Costumamos dividir os desenhos de fluxos em duas fases.Em primeiro lugar se desenha o fluxo do processo como eleé, sem nenhuma alteração na forma com as atividades sãoprocessadas, por mais obvia que seja a alteração.Costumamos chamar esta fase de “as is”. Em um segundomomento, com o fluxo completamente desenhado, se atua emsua melhoria, tornando-o mais eficiente.Desta forma teremos o processo desenhado antes e depoisdas melhorias. Com estes dois desenhos em mãos, podemosnos utilizar de ferramentas de simulação que irão indicar oganho de qualidade obtido com o redesenho.Principalmente os especialistas focados em análise e le-vantamento, quanto maior o conhecimento do negócio,mais rapidamente vislumbram pontos de processamentodesnecessários ou duplicados. Isto se deve à vivência noramo.É muito importante durante o levantamento de processosque foquemos em como o processo está atualmente ( as is),deixando o “to be” para um momento posterior. Muitas vezeso usuário do fluxo percebe o erro que está cometendo no mo-mento deste desenho, e já tenta guiar o desenho de forma acontemplar esta melhora.É importante que isto não aconteça, senão qualquer infor-mação relativa à melhoria irá se perder e análises futurasnunca conseguirão ter sucesso no diagnóstico.Isso é importante pois irá gerar relatórios de melhorias deprocesso, indicando a economia ou aumento de lucro obtido.O objetivo deste redesenho é a melhoria, e o usuário nãodeve se sentir culpado por não ter percebido isto antes, poisafinal ele estava tão focado na execução de seu fluxo diárioque dificilmente teria como abstrair e imaginar melhores for-mas de realizar a tarefa. 75
  • 75. 11- Use Cases e processosPrincipalmente no momento em que a área de negócios seencontra com a TI, para a tranferência de informações que irápermitir a implementação de um sistema baseado no fluxosde processos, surge uma dúvida muito pouco discutida que é :Como uma atividade BPMN está relacionada com elementosde análise tradicional, como um Use Case, por exemplo ?Neste caso, estamos nos referenciando aos Use Cases damodelagem orientada para objetos.Na orientação para objetos nosso foco primário é manter den-tro dos limites de um sistema, normalmente departamental.Quaisquer interfaces externas costumam ser ignoradas, ecolocadas como caixinhas a serem implementadas no futuro.Com um exemplo prático, quando iniciamos a modelagem dosistema de vendas, raramente nos preocupamos com o sis-tema de estoque.Isto é o oposto do que normalmente acontece quando umaempresa se organiza em termos de processos. Para umamodelagem em torno de processos, pouco importa a qualdepartamento uma atividade está relacionada. O que importaé a continuidade do fluxo, passando por vários departamentosda empresa até seu término.Um fluxo de processos pode se iniciar como um processo devendas na loja e passar pelo controle de estoque em algummomento, efetivando o pdedido e a reserva do produto.Por isto se costuma dizer que os sistemas atuais são verticali-zados (ou seja, giram em torno de um departamento), en-quanto que os processos permeiam a empresa na horizontal(ultrapassam vários departamentos).Frequentemente se verifica este tipo de desenho : 76
  • 76. Os mesmos blocos de mais alto nível dos que compõe ossistemas orientados para objetos, chamados de use cases,podem ser as atividades de mais alto nível que compõe osprocessos. Quando se decompõe uma atividade, ela se tornaum sub-processo que na modelagem por processos irá se tor-nar um diagrama BPMN. Na orientação para objetos, um usecase quando “decomposto” pode se tornar um diagrama deatividades, que é muito similar ao diagrama BPMN. Veja doisexemplos na introdução deste livro.Em resumo, um use case é uma atividade de mais alto nível.Podemos utilizar as atividades de um fluxo de processos comoinsumo para detalhamento dos use cases, gerando os arte-fatos necessários para a UML tradicional, como diagramas declasses e de sequências.E se um Use Case é essencialmente uma Atividade de maisalto nível, podemos utilizar os templates de detalhamento deuse cases que já utilizávamos na UML para descrever comocada atividade se comporta. Embora um diagrama BPMN sejamuito mais detalhado do que um diagrama de atividades,ainda não chegamos a um ponto onde possamos omitir o de-talhamento da atividade.Utilizando um template para definição de Use Case já namodelagem de processos de negócios utilizamos um mesmoartefato padronizado até os níveis mais baixos, facilitando nomomento posterior da implementação do sistema. 77
  • 77. 12 - ConclusõesOs objetivos primários da modelagem de processos de negó-cios é obter entendimentos de como a empresa funcionainternamente.Os artefatos discutidos, como organogramas, diagramas deposicionamento, fluxos de processos são formas visuais decompreender o que as pessoas fazem no dia a dia de suasatividades, e servem como ponto de partida para outros es-tudos, como melhorias nos processos e estimativa de custospor atividades, entre outros.Durante este entendimento é importante formentar discussão,“levantando a poeira do tapete”, pois somente desta formapoderemos de forma correta compreender os processos cor-porativos.É errado efetuarmos este levantamento apenas com o gerenteda área, por exemplo, mas se for necessário, por falta detempo dos outros envolvidos, devemos ao menos garantirque todos estão coniventes com esta visão.Muitas vezes os funcionários fazem suas atividades de formadiferente do que a gerência imagina, e vice versa.A modelagem de processos de negócios é importante poisnos faz compreender a empresa e os mecanismos que foramutilizados para que funcione. É fundamental não apenas comoetapa pré desenvolvimento de um sistema, como tambémpara adequação de uma solução de mercado, como um ERP,CRM, etc. 78
  • 78. 13 - BPEL e BPMNSe hoje em dia temos um consenso em termos de notaçãopara desenhos de processos, que é o BPMN, o mais próximoque temos atualmente de uma notação padronizada paraexecução 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-questração de serviços Web (Web Services). Como umalinguagem para execução de serviços, ela é formal e nãopermite ambigüidades.Uma das idéias no mercado é que BPEL seja utilizada na ex-ecução de fluxos de atividades. Nem todos os fabricantes aadotam em sua plenitude, e alguns incorporaram modificaçõespara torná-la compatível com os recursos de seus produtos.Mas sua força é inegável, já que até mesmo a especificaçãoBPMN na release 1.0 apresentava como fazer mapeamen-tos para o BPML, outro padrão também mantido pela mesmaorganização, e já na versão final do documento o capítulo foisubstituído pelo mapeamento em BPEL.Em essência, o BPEL é um arquivo XML. Dentro dele váriostrechos XML vão indicando o que fazer durante o proces-samento de um fluxo, definindo e armazenando variáveis. OBPEL por si só não é capaz de executar muita coisa, delegan-do a responsabilidade para web services.Se estivéssemos comparando o BPEL com um programa tradi-cional, poderíamos dizer que cada subrotina no programaseria um serviço, e o programa principal, que chama emseqüência cada rotina seria o BPEL. A desvantagem de utilizarBPEL é obvia, já que interpretar um arquivo XML é mais lentodo que executar um programa. Mas porque o mercado falatanto sobre ele ? 79
  • 79. Para uma solução BPMS, o BPEL traz vantagens. É muito co-mum ouvirmos sobre “realinhamento dos processos de negó-cios”, que significa reajustar um processo ou otimiza-lo paramelhor execução.Na maioria das situações, este reajuste é feito apenas na or-dem em que os serviços são chamados. Se a execução destefluxo está em um código, quando é necessário reajuste temosque alterar o código que executa o fluxo.Se utilizamos um arquivo XML (BPEL), as alterações na ordemde execução são mais simples, já que não precisamos recom-pilar códigos, e ainda podemos manter duas versões no sis-tema, uma antiga, com os fluxos com a execução já iniciada,e um novo, com a nova forma de execução para os novosprocessos iniciados.Desta forma, testes com o sistema em execução podem serfeitos com prejuízo mínimo aos usuários, pois os que haviaminiciado no fluxo antigo continuam até o final do processa-mento. Isto reduz o impacto nas alterações, pois não afeta oque já está em execução. Se utilizássemos códigos para fazero mesmo processamento, seria muito complicado mantermosduas versões do código em execução na máquina. Delegandopara o XML, o próprio engine BPEL pode fazer a distinção en-tre novo e velho.Para permitir a execução e até mesmo passagem de parâmetrosentre as chamadas, o BPEL possui um conjunto de elementospara lidar com situações comuns de programação, como de-claração de variáveis, atribuição e cópia de valores e chama-das a serviços.<invoke> - Efetua uma chamada a um serviço<receive> - Fica no aguardo de um serviço chamado<assign> - atribui uma variável<reply> - Responde com uma chamada<throw> - tratamento de exceções<wait> - Fica no aguardo 80
  • 80. Mas também temos elementos que controlam o fluxo, comoifs, elses e outros tipos de elementos comuns a linguagens deprogramação tradicional.<sequence> - Executa em sequência<switch> - Escolhe um caminho para execução<pick> - Fica no aguardo de um evento<flow> - Executa processamentos em paralelo<while> - Executa um loop<scope> - Define um escopo para atribuição ou leitura deuma variávelUm arquivo BPEL normalmente tem uma estrutura do tipo :<flow> <links> <link name=”XtoY”/> <link name=”CtoD”/> </links> <sequence name=”X”> <sourcelinkName=”XtoY”/> <invoke name=”A” .../> <invoke name=”B” .../> </sequence> <sequence name”Y”> <targetlinkName=”XtoY”/> <receive name=”C”/> <sourcelinkName=”CtoD”/> </receive> <invoke name=”E” .../> </sequence> <invoke partnerLink=”D”> <target linkName=”CtoD”/> </invoke></flow> 81
  • 81. 14 - O Mapeamento BPMN para o BPELÉ necessária uma certa criatividade para mapear elementosdo BPMN para o BPEL. Podemos apresentar um trecho decódigo e indicar os impactos no mapeamento :Este trecho poderia ser mapeado como :<variable name=”contador” messageType=”loopCounterMessage” /><variable name=”limite” messageType=”forEachCounterMessage” /><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,loopCounter) <= bpws:getVariableData(limite,forEachCount)”> <sequence> <invoke name=”atividade1” ... > <assign name=”incremento”> 82
  • 82. <copy> <from expression=”bpws:getVariableData(contador,loopCount)+1”/> <to variable=”contador” part=”loopCounter” /> </copy> </assign> <invoke name=”atividade2” ... > </sequence> </while></sequence>Em primeiro lugar, vale salientar que foi criada uma atividadechamada incremento, com o objetivo de manter o valor du-rante a execução do processo. Os dois invokes, que farão aschamadas aos serviços estão envolvendo um assign, que faz oincremento. Tudo isto está dentro de um while, que garante aexecução em looping.Foi inserida dentro do BPEL uma linguagem de expressão,o que permite a comparação 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 umanalista de processos provavelmente não foi colocada. Elaapareceu no momento do mapeamento para BPEL, permitindoa geração da “rotina” de incremento.Isto faz com que um fluxo desenhado pelo analista ra-ramente consiga ser mapeado diretamente para o BPEL,sendo necessários reajustes, neste caso exemplificadocom a inserção de uma atividade para permitir a conta-gem.Outra particularidade oculta, mas a ser considerada é que oBPEL não têm o conceito de pools e lanes. Portanto não háperfis e se assume que um fluxo será executado para umperfil específico. Isto pode ser um problema para um desenhomais complexo, e talvez cada lane tenha que ser mapeada 83
  • 83. Como os fabricantes estão lidando com estas deficiências ?Como dissemos anteriormente, muitos estão acrescentandoelementos ao padrão, de forma a contornar estas incon-veniências. Isto deve gerar nossa preocupação, pois podemsurgir 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 quefazem o levantamento dos processos não se preocupam muitocom a notação (alguns nem mesmo utilizam o BPMN).No momento em que o fluxo for implementado em umasolução BPMS, será redesenhado para a ferramenta adotada,seja BPEL ou outra qualquer.Isto não é bom, pois pode causar distorções na transcrição,além de dificultar o processo de implantação e praticamenteinviabilizar o realinhamento rápido do negócio.Também vale salientar que o invoke no BPEL faz uma cha-mada à um Web Service. Mas e se tivermos interações com osusuários ?Talvez a mais notada proposta no mercado seja o BPEL4PEO-PLE, proposta pela IBM e SAP, como alteração no BPEL deforma a permitir interações entre pessoas. O documento épúblico, e alguns fabricantes estão suportando o padrão. Énecessário deixar claro que nem todos os engines BPEL supor-tam BPEL4PEOPLE, o que faz com que um processo modeladoem BPEL nem sempre possa ser executado em qualquer en-gine.Acho que vale salientar que os elementos do BPEL4PEOPLEsão muito diferentes dos elementos BPEL tradicional, e ajustesprofundos nos engines de execução são necessários 84
  • 84. 15 - Editor BPMN da revista PortalBPMVocê pode localizar este editor BPMN no site da revistaPortalBPM (www.portalbpm.com.br), na seção de downloads.Para que mais uma ferramenta de desenho ?Bem, esta ferramenta é distribuida gratuitamente e contémtodos os símbolos da notação BPMN, o que nem todas as fer-ramentas têm, é gratuita para utilização, e mais simples que amédia das ferramentas.A ferramenta necessita de uma instalação Java para operarnormalmente. Ela foi testada e homologada na versão de Java5. Pode-se baixar um JRE, que é menor requer menor esforçona instalação através do link http://java.sun.com/javase/downloads/index_jdk5.jsp.Ela não foi testada com versões posteriores de Java, e não iráfuncionar com versões anteriores. Uma vez baixado o ex-ecutável, pode-se instalar como qualquer aplicativo Windowsnormal. Uma instalação típica pode ser selecionada, e seráapresentada uma tela como : 85
  • 85. Após a instalação, você terá uma máquina virtual Java queserá utilizada pelo programa.A segunda etapa é baixar o programa de edição BPMN. Ele éfornecido como um ZIP, que pode ser aberto para qualquerdiretório do computador. Deve-se criar um diretório na má-quina, por exemplo c:EditorBPMN.Copia-se o arquivo ZIP para dentro desta pasta, e se extrai oconteúdo para dentro deste diretório. Após este processo, odiretório deve parecer como :O arquivo editorbpmn.zip pode ser removido sem problemasagora. A instalação está completa. O executável EditorBPMN.exeirá iniciar o programa. Ele pode ser arrastado para o desktoppara que seja criado um atalho, facilitando execuções futuras.Quando se executa o programa, será solicitado um diretóriode trabalho, onde todos os arquivos criados serão armazena-dos : 86
  • 86. Após definido um espaço de trabalho, o programa entra emsua tela principal. A ferramenta foi construída com base noeclipse, e é formada por várias telas que interagem com aaplicação.Para que tenhamos um ambiente customizado para utilização,podemos chavear para a perspectiva de edição BPMN. Istopode ser feito selecionando os menus Window->Open per-spective->Other, e seleciona-se “Perspectiva edição BPMN”,como a seguir : 87
  • 87. Após este chaveamento, a aparência ficará como :A ferramenta está pronta para uso. Nas entradas seguintes, aperspectiva não precisará mais ser chaveada. Se por algumarazão alguma janela for fechada ou a perspectiva perdida,pode-se novamente abrir a perspectiva com o procedimentoacima.Todos os desenhos BPMN ficam dentro de um projeto. Pre-cisamos criar ao menos um projeto, mas por outro lado po-demos ter vários projetos em um workspace. A ferramentapode também ter vários workspaces, bastando na entrada seselecionar diretórios diferentes para cada execução. A criaçãode um projeto é feita clicando-se com o botão da direita najanela Navigator, que está no canto superior direito da tela : 88
  • 88. Será solicitado um nome para o projeto, e após criado iráapresentar uma aba em navegador, semelhante a uma estru-tura de diretórios do Windows Explorer.Dentro deste projeto podem ser criados vários desenhosBPMN. Selecionando-se o projeto com o botão direito domouse será apresentado : 89
  • 89. Será apresentado um nome padrão, com a extensão BPMN,que pode ser alterado a vontade. A extensão do arquivo de-verá ser sempre BPMN, e não podem existir dois arquivos comum mesmo nome dentro de um projeto. Após criado o arquivoele será aberto na área de edição, que fica na lateral direitada janela.Neste momento, se inicia o processo de edição propriamentedito.O processo de edição consiste em selecionar um elementovisual na paleta decomponentes, através de um clique. Depois pode-se movero mouse até a área do editor, e clica-se novamente para queo elemento seja depositado na área de edição. O editor depropriedades indica algum atributo de cada um dos elementosque 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 ficará selecionado na áreade edição e suas propriedades serão apresentadas. 90
  • 90. Vamos editar um exemplo simples de BPMN. A partir do editoraberto, selecionamos uma lane, que está na palete em outros.Quando se clica em um sub-elemento da palete, ele é abertoe fechado a cada interação. Leva-se a lane para a área deedição, e coloca-se na tela a tela ficará como :Pode-se selecionar o valor de perfil e colocar um valorsignificativo para a Lane, como Atentende. Imediatamenteo desenho na edição superior reflete este valor, bem como ajanela de Outline.O próximo passo é fazer o mesmo com os eventos de início efinal, que devem ser arrastados sobre a Lane. Deve-se fazero mesmo com uma atividade simples, que terá seu atributotexto alterado para “Atende cliente”. Após estes passos, a teladeverá estar como : 91
  • 91. A paleta pode ser aberta ou fechada, bastando-se clicar nela,ou posicinando-se o mouse por algum tempo sobre ela. Elatambém se fecha automaticamente quando não está sendoutilizada.Elementos BPMN podem ser arrastados para uma Lane, nestecaso fazendo parte dela, ou seja, quando a Lane é arrastadatodos os elementos internos são arrastados em conjunto.Pode-se também arrastar os elementos para uma área forade uma lane, neste caso não pertencendo a nenhuma laneespecífica, funcionando como um processo privado, como ex-plicado na primeira edição 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 visualização de elementos na tela.A ferramenta permite exportar em formato imagem. Selecion-ando-se o mouse com o botão direito sobre o editor, em umaárea não populada (branca), será apresentada uma opção“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 documentostextuais, como de requisitos.Arquivos BPMN podem ser exportados da ferramenta, ou im-portados para ela.Clicando-se com o botão da direita sobre um arquivo ou pro-jeto, serão apresentados menus para exportação e importação.Isto permite compartilhar desenhos BPMN entre usuários.Perceba que a cada alteração no diagrama, um asteriscoaparece 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
  • 92. 16 - Outras ferramentas de mercadoTemos várias alternativas de mercado para desenho BPMN.Elas se dividem em ferramentas de desenho BPMN com BPMSintegrado, e soluções puras de desenho.Ferramentas de desenho com suporte ao BPMN • Toguether – Borland • BEA – Aqualogic • Intalio • System Architect • MetaStorm – Provisio • Visual Paradigm • WBI Modeler • Visio • ArisAtualmente temos cadastradas 44 ferramentas com suporteao BPMN, e o número cresce a cada dia.Não podemos deixar de citar o movimento Eclipse, que estáconstruindo uma ferramenta de desenho BPMN sobre o GMF eGEF. 93
  • 93. 17 - BPMN design patternsDa mesma forma que na orientação para objetos, os fluxosde processos desenhados em BPMN demandam padrões dedesenvolvimento (design patterns).Um design pattern, segundo a definição, é um trecho queaparece repetidas vezes durante os ciclos de desenvolvi-mento. Para facilitar a compreensão e garantir uma mesmalinguagem durante as reuniões de levantamento, é importanteutilizarmos os mesmos termos, evitando desta forma am-bigüidades. Seqüência de fluxo (Sequence)Este tipo de design pattern indica uma seqüência de fluxo. Omais óbvio é a seqüência, onde atividades são executadas emuma ordem, uma após a outra. A representação deste tipo defluxo é algo como a seguir :Neste caso, deve estar implícito que existe um token que vaisendo propagado conforme as atividades vão sendo executa-das, sejam elas por um mesmo perfil ou por vários perfis(lanes) dentro da execução. 94
  • 94. Processamento paralelo (Parallel Split)Quando seguimos por mais de um caminho ao longo da ex-ecução do fluxo, ou se temos atividades com tokens distin-tos (notação BPMN), chamamos de processamento paralelo(parallel split).Isto indica que os dois caminhos são processados de formaindependente. Em BPMN, temos mais de uma forma de repre-sentação para processamentos paralelos.No exemplo a seguir, em todos os casos as atividades A e Birão gerar tokens distintos.No exemplo à esquerda, temos um fluxo paralelo não contro-lado. Quando duas setas saem de uma atividade, isto indicaprocessamento paralelo. No exemplo da direita, colocamosexplicitamente o gateway de AND. 95
  • 95. Sincronização (Synchronization)Utilizamos uma sincronização quando desejamos aguardarpela chegada de mais de um token gerado durante o proces-samento. Ele é a contrapartida do processamento paralelo.Suas representações podem ser :A notação BPMN chama este tipo de padrão de Merge. Quan-do colocamos uma sincronização desejamos aguardar por umconjunto de processamentos antes de continuarmos.Escolha exclusiva (Exclusive Choice) e União simples (Simplemerge)Quando temos uma única escolha para um dos caminhos deum fluxo, através de um gateway XOR, definimos este padrãocomo Exclusive Choice. Sua contrapartida é o simple merge,que irá aguardar pela chegada do único token, e assim continuaro processamento. Este tipo de pattern indica que apenas umtoken foi gerado durante o processo. 96
  • 96. Múltipla escolha (Multiple choice) e Múltipla junção (Multiplemerge)Quando temos um mais caminhos sendo processados em umfluxo, indicamos através do pattern Multiple choice e Multiplemerge. 97
  • 97. Sobre junções e bifurcaçõesOs mecanismos de junção e bifurcação são completamentedistintos, e não necessitam ser utilizados aos pares. Vamoscompreender estes mecanismos através de alguns exemplos.Quando o diagrama contém um gateway para bifurcação oujunção, dizemos que este ambiente é controlado. Quandoexiste mais de um fluxo saindo ou chegando a uma atividade,dizemos que este ambiente é não controlado. Se mais de umaseta de fluxo sai de uma atividade, todos os caminhos sãoseguidos, como se fosse um AND.No exemplo anterior as duas representações são idênticasem termos de processamento. Dois tokens foram criados,seguindo para as atividades B e C. Já em termos de junção,um ambiente descontrolado gera resultados distintos, em ter-mos de processamento.Neste exemplo, tanto a implementação 1 como a 2 irão pas-sar por A, gerar dois tokens que seguirão por B e C.A diferençaé que no primeiro exemplo, cada um dos tokens que chegarema D irão forçar a excução 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, Dserá executado apenas uma vez, pois o gateway de junção iráaguardar a chegada dos dois tokens. 98
  • 98. Mas desejamos às vezes que qualquer um dos tokens quechegue até a junção faça com que o fluxo continue.Este pattern é comumente chamado de Discriminação (dis-criminator).Neste caso, embora dois tokens tenham sido gerados, como ajunção é um XOR, o primeiro dos tokens que chegar ao gate-way fará com que o fluxo continue. O outro token, quandochegar ao gateway será descartado em termos de processa-mento.Desta forma, é perfeitamente possível que a seqüência exe-cutada para o exemplo anterior seja A, B, D e C, isto mesmo,com a atividade D terminando antes mesmo da C. Junção N de M (N out of M join)Mas, se a sincronização aguarda por todos os tokens, e a dis-criminação pelo primeiro que chegar, como podemos desenharum fluxo de forma que alguns cheguem até o gateway paracontinuar ? Seria o “meio termo” entre a sincronização e dis-criminação. 99
  • 99. Neste caso, desejamos que o fluxo continue quando as ativi-dades B e C terminarem, e para isto utilizamos o gatewaycomplex como junção. Na bifurcação ele funciona como formade gerarmos várias saídas, e na junção como forma de es-colha para quais elementos devem ser recebidos para que ofluxo continue. Ciclo arbitrário (Arbitrary cicle)Quando desejamos executar um fluxo um certo número devezes, mas não temos como precisar quantas vezes ele seráexecutado, utilizamos um ciclo arbitrário. Ele funciona comouma atividade em paralelo, mas sem que definamos quantasvezes ele será executado.É importante termos consciência destes patterns, mas acimade tudo conhecer os mecanismos de execução, para que nãodesenhemos um fluxo que no momento da execução funcionede uma forma diferente da esperada, apenas porque seleciona-mos um gateway de forma errônea. 100