Copyright @ 2008 by Editora PortalBPM ltda. Direitos desta edio reservados a Editora PortalBPM ltda Av.

Sta Catarina, 1396 sala 4 CEP : 04367-050 Impresso no Brasil por HR Grfica Proibida a reproduo, total ou parcial, por qualquer meio ou processso, Seja fotogrfico, grfico ou microfilmagem etc. Estas proibies aplicam-se tambm nas caractersticas grficas e/ou editoriais. A violao dos direitos editoriais punvel como crime (Cdigo penal, art 184, Lei 6.895/80), com busca, apreenso e indenizaes diversas (Lei 9610/98 Lei dos direitos autorais arts. 122, 123, 124 e 126) Reis, Glauco dos Santos Modelagem de processos de negcios com BPMN Curso completo / Glauco S. Reis; Reviso tcnica equipe PortalBPM So Paulo; Editora PortalBPM ltda; 2008 1. Modelagem de processos de negcios 2.BPMN 3.BPMS

Prefcio
Estamos vivenciando um perodo de mudanas profundas, em reas de conhecimento distintas como processos para desenvolvimento de sistemas e gesto empresarial. Toda uma nova gama de conceitos e ferramentas esto sendo apresentadas e definidas, e que provavelmente devero nortear o futuro da TI nos prximos anos. Um destes conceitos, e provavelmente o que gera a maior concordncia entre os especialistas a notao BPMN. A sigla BPMN o acrnimo de Business Process Modeling Notation, ou notao para modelagem de processos de negcios. Embora quase no exista discordncia quanto efetividade do padro, as documentaes so limitadas e a especificao oficial densa e intrincada. A proposta deste livro explorar a notao BPMN, como descrita na especificao oficial, sem as particularidades introduzidas por cada fabricante. Toda a simbologia ser explorada, e estaremos fornecendo interpretao para cada smbolo, erros comuns no desenho, alm de discutirmos um pouco sobre mapeamento de processos e design patterns aplicados notao. Espero que voc aproveite a leitura, e que muitas das dvidas possam ser sanadas ao longo do livro.

Glauco Reis glauco@portalbpm.com.br

Sumrio
1 - Prefcio 2 - Ferramentas BPMS 2.1- Workflows 2.2 - BPMN 2.3 - BPEL 2.4 - SOA e Web Services 2.5 - Dashboards 2.6 - Realinhamento dos processos de negcios 2.7 - Business Process Management Systems 2.8 - Pure players 2.9 - BPMN e Futuro 3 - Processos 3.1 - UML e BPMN 4 - Tipos de diagramas BPMN 5 - Pools e Lanes 5.1 - Instncias de processos 6 - Eventos 7 - Eventos de timer 8 - Eventos de mensagem 9 - Eventos de dados 10 - Controles de exceo e compensao 11 - Conexo entre diagramas 12 -Terminadores do processo 13 - Resumo dos tipos de eventos da BPMN 14 - Gateways 15 - Eventos do tipo XOR (OU exclusivo) 16 - Token 17 - Eventos AND (E) 18 - Eventos OR (OU) 19 - Tratamento de eventos 20 - Eventos multiplos 21 - Eventos Complexos 22 - Gateways diretamente em fluxos 23 - Atividades e tarefas 24 - Loop 25 - Mltipla instncia - 06 - 06 - 07 - 08 - 09 - 10 - 11 - 11 - 15 - 15 - 16 - 16 - 18 - 20 - 21 - 22 - 23 - 26 - 29 - 31 - 35 - 35 - 37 - 38 - 38 - 39 - 41 - 41 - 41 - 42 - 43 - 44 - 46 - 46 - 48

26 27 28 29 30 31

Compensao Ad Hoc Pools e Lanes Artefatos Dados Grupos

49 50 52 56 56 58

Parte II ERROS COMUNS NO DESENHO BPMN - 59

01 - Gateways de tipos diferentes na juno e bifurcao- 60 02 - Gateways baseados em eventos - 62 03 - Utilizao de elementos de fluxos com fluxos condicionais- 63 04 - Eventos - 65 05 - Fluxos, pools e lanes - 68 06 - Fluxos, pools e lanes - 69 07 - Levantamento dos processos de negcios - 70 08 - Processos e Macro-processos - 71 09 - Os fluxos de processos - 74 10 - As is e To be - 75 11 - Use Cases e processos - 76 12 - StoryBoards - 78 13 - BPEL e BPMN - 79 14 - O Mapeamento BPMN para o BPEL - 82 15 - Editor BPMN da revista PortalBPM - 85 16 - Outras ferramentas de mercado - 93 17 - BPMN design patterns - 94

2 - Ferramentas BPMS
Antes de iniciarmos nossa jornada pela notao BPMN, vamos apresentar como a TI evoluiu at chegamos ao momento atual, com as chamadas solues BPMS. As disciplinas de modelagem de processos tiveram grande foco ao final da dcada de 80 e incio da dcada de 90, com estudos de cientistas como Michael Porter. Nesta poca os estudos mantinham foco em administrao de empresas, centrando esforos em como as empresas poderiam ser melhoradas em termos de estrutura organizacional. O que se percebia que o processo de construo das empresas normalmente se fazia de forma desestruturada, com novos departamentos e processos sendo criados sob demanda. Em um mundo no globalizado, isto at que no afetava muito a sade da empresa. Mas com a internet e globalizao, empresas grandes comeavam a competir com empresas pequenas de igual para igual, e a necessidade por uma reduo de custos e melhoria de processos junto ao cliente se tornou necessria como forma de garantir sobrevivncia em um ambiente competitivo. Nesta poca, o foco dos estudos era como melhorar os processos, e embora houvessem vrios esforos isolados por parte da TI para soluo destes problemas, estes esforos ainda no estavam integrados para formar o conceito que hoje conhecemos como solues BPMS.

2.1 - Workflows
Eram muito conhecidas na dcada de 80 como ferramentas de colaborao. Uma implementao de destaque foram as solues da Lotus, que acabaram sendo incorporadas posteriormente aos produtos da gigante IBM. A necessidade por organizar de alguma forma a comunicao entre as pessoas, transferindo responsabilidades ao longo do processo era e at hoje fundamental em qualquer tipo de empresa. O nome das ferramentas de colaborao se tornou chamativo, e o conceito de workflow se firmou e se mantm at hoje.

Na verdade, inmeras empresas vendem solues de workflow como se fossem solues BPMS hoje no mercado, mas h diferenas que at hoje os especialistas tentam explicar. De uma forma geral, um workflow uma das peas que compe uma soluo BPMS. Em uma ferramenta de workflow existem dois conceitos principais : o motor de execuo e a ferramenta de definio de processo ou fluxo. Estas ferramentas de definio inicialmente foram criadas de forma textual, indicando os participantes e em que ordem eles executariam atividades. Com o tempo, conforme as prprias notaes para processos evoluram, todo um conjunto de notaes grficas, como IDEF, BPMN, UML, grafos, entre outros foram utilizadas como forma de representar visualmente estes processos em execuo em um Workflow. O consorcio WfMC foi notadamente um destaque, propondo uma especificao utilizada at hoje por muitos provedores de soluo BPMS.

2.2 - BPMN
Entre os padres comentados, a notao de destaque na atualidade o BPMN (Business Process Modeling Notation), que estaremos explorando nos prximos captulos deste livro. Alm de mais moderna que notaes como IDEF e UML, tambm possui um rico set de elementos grficos para representao de uma srie de situaes que acontecem nos fluxos dos processos. O padro est em evoluo e longe da perfeio, mas de todas as notaes da indstria o que mantm a maior concordncia da indstria. Infelizmente, o padro BPMN uma notao grfica para desenho de processos, e no est associado a nenhum formato de armazenamento especfico.

Houve uma tentativa de utilizar a fora da organizao que estava com credibilidade muito forte pela criao do padro no sentido de firmar outro padro, o BPML (Business Process Modeling Language), que seria um formato binrio para armazenamento e execuo dos processos criados em BPMN. Esta tentativa foi frustrada por outro padro j em estgio mais avanado de adoo, chamado BPEL.

2.3 - BPEL
A linguagem BPEL (Business Process Execution Language) hoje uma forte candidata a ocupar o padro como notao para execuo de processos. Infelizmente, da mesma forma que um motor de frmula 1 no pode ser colocado sem inmeras adaptaes em um veculo comum de mercado, o mesmo pode-se dizer em relao ao BPMN mapeado para BPEL (com o BPMN como o motor neste exemplo). A notao BPMN muito completa e sua evoluo se deu em torno das necessidades que aparecem no dia a dia dos desenhos dos processos, enquanto que o BPEL foi criado como um padro para permitir que um motor pudesse orquestrar fluxos baseados em Servios Web (Web Services). Em outras palavras, os caminhos seguiram em paralelo e com focos diferentes em mente. H todo um esforo no sentido de tornar o BPEL ideal como formato de armazenamento dos desenhos BPMN, mas hoje os fabricantes adotam duas formulas para o mapeamento : 1)Reduzir o nmero de elementos grficos disponveis, para manter a converso para o BPEL vivel. Isto ajuda se tivermos em mente apenas a execuo do processo, mas limita o analista de negcios, se a ferramenta de desenho for a mesma ferramenta que ir operacionalizar os fluxos. 2)Incorporar novos elementos ao BPEL, permitindo que toda e qualquer representao BPMN possa ser desenhada sem problemas. Isto traz um inconveniente ao BPEL, pois o mesmo foi criado para ser totalmente interopervel, e no momento em que cada um dos fabricantes incorpora novidades, os motores para execuo tendem a se tornar incompatveis.

O que se espera nos prximos anos que uma evoluo nos dois padres venha a surgir, ou que outro formato de armazenamento se firme como padro para desenho. Ainda h uma perspectiva futura que a criao da notao BPDM, um formato intermedirio entre o BPEL e o BPMN.

2.4 - SOA e Web Services

Anteriormente comentamos que o BPEL foi criado como um padro para orquestrao de servios WEB. Esta foi outra grande inovao introduzida a partir das limitaes encontradas nos paradigmas atuais da orientao para objetos. Por mais que tentemos reaproveitar os cdigos criados a partir da OO, o grau de acoplamento entre eles ainda muito forte, e torna difcil o reaproveitamento de cdigos de forma corporativa. A arquitetura WEB Java, com seus mdulos EAR, WAR, JAR, SAR, RAR, etc. tambm no facilitam o reaproveitamento de cdigos. A idia dos Web Services, que posteriormente foi promovida a arquitetura SOA, prope que os componentes sejam criados e soltos dentro de servidores de aplicao, de forma que diversos programas se beneficiem de sua utilizao, sem que necessitem ser incorporados fisicamente a um programa especfico. Se esta promessa de componentizao se concretizar, teremos um novo patamar de reutilizao na indstria. No h garantias de que este ter sucesso, mas os indicadores atuais so muito promissores. Bom, imaginando um cenrio ideal teremos os desenhos dos fluxos sendo criados em BPMN e salvos ou mapeados para BPEL, que por sua vez far com que servios web sejam orquestrados. Ento j temos tudo o que necessrio para uma soluo BPMS ? Bom, nem tudo ainda.

2.5 - DashBoards
O sonho de consumo de qualquer empresrio poder controlar de forma ativa sua empresa, identificando como os processos esto durante a execuo, tempos de execuo de cada atividade, e outras informaes. Se todas estas informaes puderem ser apresentadas em grficos de fcil compreenso, melhor ainda. um conceito semelhante ao de BI (Business Inteligence), onde dados so analisados nas empresas e medidas so tomadas para melhoria dos processos. A idia de BI ou minerao de dados trabalha com dados aps o fato estar consumado, ou seja, aps o gasto j ter concretizado. Este controle a que nos referimos pr-ativo, ou seja, devemos coletar dados ao longo da execuo de um fluxo de processo, e estudarmos os dados antes mesmo do trmino da execuo do processo. Este estudo precisa ser feito de forma facilitada, pois temos pouco tempo para tomada de deciso. Por isso deve ser visual em formato de grfico. Nas solues BPMS, colocamos termmetros dentro do fluxo, e medimos estes termmetros apresentando grficos que sumarizam a evoluo do processo. Isto chamado de Dashboard, e uma pea fundamental das solues BPMS. Precisamos corrigir eventuais distores no fluxo bem antes do final, para que possamos garantir a economia e reduo nas perdas. Sem este termmetro, praticamente invivel descobrirmos se h algo errado ou mesmo onde devemos corrigir no processo durante sua execuo. Ser necessrio a execuo do processo para que possamos depois da execuo encontrar as falhas. Esta melhora precisa acontecer a todo momento, e um termo muito utilizado para descrever esta melhoria contnua realinhamento dos processos de negcios.

10

2.6 - Realinhamento dos processos de negcios

Com todas estas ferramentas dentro da empresa, com os desenhos criados com BPMN, sendo orquestrados por um workflow, executando Web Services com BPEL, e que vo sendo analisados momento a momento para encontrarmos possveis problemas e pontos de melhoria, atravs dos Dashboards, precisamos de um mecanismo para podermos realinhar rapidamente, ou seja, resolver rapidamente estes problemas para que o fluxo continue fluindo da forma esperada. Para isto, no tolervel aguardar meses por alteraes na TI, para que um cdigo funcione como esperado. O que se espera das melhores solues BPMS que seja muito fcil introduzir modificaes, com poucas alteraes e facilidade nas alteraes dos cdigos. Isto no um conceito simples de implementar, e parece que quanto mais visuais as ferramentas se tornarem, mais rapidamente conseguiremos este realinhamento desejado.

2.7 - BPMS Business Process Management Systems

Pois bem, uma soluo BPMS reune as inovaes e tecnologias anteriormente citadas. Uma definio para o BPMS poderia ser : Uma soluo BPMS permite a gerao e controle dos processos de negcios da empresa, proporcionando rpida tomada de deciso e realinhamento dos processos de negcios de forma agilizada. Um pouco subjetivo no ? Mas o que o homem de negcio deseja. Em um mundo globalizado e competitivo, os prazos definidos pelas metodologias OO e outras no esto mais se mostrando satisfatrios. Mas podemos ler nas entrelinhas da definio, e deduzir algumas coisas :

11

1) Uma ferramenta BPMS deve permitir o desenho dos processos de forma visual, sendo que as melhores ferramentas suportam o BPMN. As boas ferramentas tm programas prprios de desenho incorporado. Ser visual importante pois traz agilidade ao gerenciamento do processo. Imagine a quantidade de erros que apareceriam se manipulssemos dezenas ou centenas de arquivos XML de forma manual. 2) O suporte ao padro BPEL4WS no obrigatrio, mas as ferramentas que o suportam fornecem algumas vantagens. Em primeiro lugar, voc pode utilizar qualquer editor que gere o formato. Segundo, os processos ficam armazenados em formato XML, o que mais adequado e proporciona maior interoperabilidade. As desvantagens esto do fato de o BPEL ser orientado para Web Services. Ou seja, no se pode orquestrar uma chamada a um EJB atravs desta tecnologia, a menos que o EJB seja publicado como servio. 3) um concenso que as ferramentas devem suportar servidores de aplicaes. Algumas criaram os prprios servidores para execuo. O ideal seriam ferramentas que suportassem servidores .NET ou J2EE, pois so os mais consagrados. Naturalmente, a tecnologia J2EE permite multiplataforma, e isto por s s j vantagem. Criar um servidor especfico e no utilizar a base J2EE um erro, pois o grau de maturidade dos servidores J2EE muito alto. Alm disto os servidores incorporam uma srie de recursos, como escalabilidade e segurana, e estes recursos podem ser reaproveitados pelos BPMS. 4) Toda ferramenta deve permitir o controle do processo. Este controle pode acontecer antes de o processo ser executado (atravs de simulaes) e tambm durante a execuo, para deteco de falhas no processo em operao (Dashboards). Ou seja, antes de publicar o processo devemos poder simullo, para verificar se est como previsto, e durante a execuo devemos o ser capazes de extrair mtricas para correo com facilidade.

12

Deve ser possvel no s publicar novas verses do processo, como tambm permitir que as verses antigas continuem enquanto houverem atividades ainda sendo processadas. Isto necessrio, caso contrrio ser difcil realinhar os processsos de negcios rapidamente. No podemos esperar o trmino da execuo dos processos (o que pode levar dias ou meses), para colocar uma nova alterao em execuo. Processos antigos devem continuar executando como previstos, e novos processos devem j ser executados de acordo com o novo desenho. 5) Um recurso muito apreciado pelas reas gerenciais so os Dashboards, que so grficos gerenciais, tomados dos processos em execuo, e que permitem verificar visualmente quando algo no vai bem. Isto ajuda na tomada de deciso. Uma caracterstica dos Dashboards que eles tendem a ser muito dinmicos, e portanto deve ser fcil cri-los e alter-los sem demandar grandes esforos da TI. 6) Quando dizemos rpido realinhamento nos processos de negcios queremos dizer que o alteraes devem se efetivar com custo mnimo de tempo. Uma das vantagens divulgadas pelas ferramentas BPMS poder gerar resultados mais rpidos do que os conseguidos at ento com as metodologias tradicionais. Se para alterar um processo de negcio for necessrio acionar uma equipe de desenvolvimento gigantesca, que tero que criar cdigos novos para cada Web Service inserido, no estaremos resolvendo um dos problemas que a tecnologia se prope a resolver, que gerar uma rpida resposta aos problemas do negcio. Neste sentido, atualmente existem dois paradigmas sendo adotados pelos grandes fabricantes. O primeiro o de ferramentas onde apenas o processo gerenciado visualmente.

13

Os componentes de negcios, sejam eles Web Services, CORBA, EJB so criados manualmente, atravs de ferramentas como Eclipse, NetBeans, WSAD, Sun Studio ou outros, que podem at estar integrados ferramenta geradora de fluxos. O segundo tipo de ferramenta, embora no tenha toda a flexibilidade de manipulao de cdigos da primeira alternativa, adota um paradigma totalmente visual de construo, onde at mesmo os objetos de negcios so construidos visualmente. A vantagem deste segundo tipo a velocidade no realinhamento, com poucos cdigos gerenciveis. bem verdade que este tipo de paradigma deve evoluir para algo mais flexvel do que os mecanismos atuais. E ferramentas geradoras de cdigo devem evoluir para alternativas onde o processo de construo seja mais gil. 7)Ferramentas que permitem criar telas visualmente trazem agilidade ao processo de mudana, principalmente quando a atividade exige interao humana. Um workflow no pode mais ter telas simples, com campos textuais sem formatao. A identidade visual da empresa precisa ser mantida durante a execuo do processo. Ou seja, as ferramentas devem permitir a criao de telas complexas, de preferncia de forma visual. 8) Ferramentas que suportam apenas componentes Web Services so limitadas atualmente, embora esta seja uma promessa futura. O ideal so ferramentas que agreguem algum tipo de EAI, que permita integrar vrios tipos de componentes do legado. Perceba que isto se contrape adoo de BPEL4WS, j que o padro apenas suporta WS. 9) Um elemento importante, que se esquece com frequncia, a estrutura organizacional da empresa. Antes mesmo de iniciar o entendimento dos processos, se constroe o organogramas da empresa. Uma ferramenta que permita definir organogramas de forma visual, integrando estes organogramas com mecanismos computacionais trazem vantagens.

14

Infelizmente, a maioria das ferramentas ainda tm limites neste quesito. Manter as informaes de usurios disponveis livremente, em qualquer ponto da corporao, tambm uma vantagem. Quase todas as solues BPMS mantm os usurios e senhas em estruturas dentro da prpria ferramenta, ao invs de buscar em uma base relacional externa ou servidor LDAP. Tambm a maioria no permite edio visual do organograma da empresa.

2.8 - Pure players

Alguns institutos de pesquisa (Gartner Group, por exemplo) se utilizam do termo pure player, para ferramentas que so BPMS puros, sendo que os demais so ferramentas que vm de algum nicho de mercado pr existente. Algumas ferramentas so Workflows ou EAIs que esto em evoluo para o paradigma BPMS. Algumas empresas tm ferramental de desenho (BPMN) e esto evoluindo para se enquadrarem na categoria BPMS. Este termo foi criado para tentar reduzir a panacia em relao aos diversos fornecedores que desejam ter sua ferramenta seja considerada BPMS pure player. Uma ferramenta do tipo pure player tende a ser melhor, j que foi criada com o esprito destas idias desde o incio.

2.9 - Futuro e BPMN

Vale a pena gastar esforos no padro BPMN agora? Bem, se voc for um analista de negcios este provavelmente ser o padro dominante para desenho nos prximos anos. Se voc da rea de TI, muito provvel que a operacionalizao dos fluxos seja feita atravs de uma evoluo do BPMN, com mais elementos programticos incorporados. Mesmo que o padro dominante continue sendo a UML, h uma perspectiva de evoluo da notao para que incorpore o BPMN como uma evoluo dos diagramas de atividade.

15

3 - Processos 3.1 - UML e BPMN

Para que necessitamos de mais uma notao para desenho de processos? Ser que as notaes existentes, como os diagramas de atividade da UML, j no contemplam tambm este tipo de representao ? Eles representam muito bem etapas na execuo de um Use Case, ou mesmo um trecho mais complicado de uma rotina. Os fluxos de processos de negcios tm se mostrado muito mais complexos a cada dia, e a notao UML embora seja muito formal, deixa a desejar em termos de diversidade grfica, alm de utilizar as mesmas simbologias para o tratamento do negcio e para tratamentos de erros, que normalmente no fazem parte do negcio em si. Em diagramas maiores a tendncia confundir e dificultar a visualizao e manuteno dos fluxos. Para tornar isto mais claro (e visual), vamos utilizar o exemplo de apontamento de viagem, explorado na documentao oficial BPMN. Veja o mesmo exemplo modelado de duas formas :

16

BPMN
O que se pode observar em primeiro lugar que, no caso da UML, como no existem mecanismos de compensao e gerao de erros, somos obrigados a utilizar elementos de deciso para indicar o fluxo em caso de erro. Neste caso fica mais difcil identificar qual elemento est sendo utilizado como parte do tratamento do negcio, e qual deciso foi inserida como desvio para tratamento de erros, dificultando a manuteno. O mesmo ir acontecer quando outros elementos, como timers e mensagens so adicionados ao diagrama. Eles isolam elementos de interao dos processos de tratamentos da lgica de negcios, de forma mais clara. Alm disto, o prprio fato de a imagem j ser representativa, torna mais claro o entendimento pelo crebro do que aquele desvio ou evento faz. Em resumo, um diagrama BPMN torna mais claro o entendimento e adiciona elementos grficos que facilitam a compreenso do que est acontecendo no diagrama.

17

4 - Tipos de diagramas BPMN

Cada um dos tipos de diagrama chamado de BPD (Business Process Diagram), mas tm nomes mais especficos, de acordo com seu detalhamento. Algumas vezes desejamos entender em profundidade como um fluxo opera, e outras vezes desejamos apenas transmitir ao leitor do diagrama como dois fluxos distintos operam. Para permitir esta diviso em categorias temos trs tipos de diagramas : Os Private Business Process ou Diagramas de processos privados, que utilizamos quando no relevante representarmos como diferentes fluxos interagem. Estamos preocupados apenas com o teor deste fluxo em si.

Existem os Abstract process ou Processos abstratos. Em um processo abstrato, no estamos preocupados com o contedo do fluxo em si, mas sim como ele colabora com outros fluxos dentro de um sistema.

18

J nos Colaboration Process ou Processos colaborativos desejamos obter um grau maior de detalhamento, apresentando como dois ou mais fluxos se comunicam.

Podemos imaginar estes trs tipos de diagramas como sendo um s, onde caractersticas podem ser apresentadas ou no, dependendo do que desejamos visualizar. Imagine um programa de CAD com uma imagem de um veculo, onde podemos visualizar sua aparncia externa (equivalente ao diagrama abstract) ou as peas que o compe (equivalente ao diagrama private). A especificao no dita regras de como cada implementao de ferramenta deve operar, mas parece que a forma mais intuitiva seria a de que cada diagrama pudesse ser chaveado para apresentar seus elementos internos ou no. Um aspecto ainda a explorar como estes tipos de diagramas afetam o mapeamento para um fluxo de processos. Um processo BPEL representado por um processo privado, por exemplo. Para que tenhamos a colaborao entre processos em BPEL, necessitamos de mais de um arquivo BPEL, cada um mapeado para um processo privado. Em resumo, um diagrama BPMN pode ser mapeado para mais de um arquivo BPEL. Normalmente um arquivo BPEL mapeado para apenas um diagrama BPMN.

19

5- Pools e Lanes
Conforme um fluxo vai sendo executado, ele passa por vrias atividades. Em um mundo real e colaborativo, as atividades so atribudas a pessoas ou perfis diferentes, ao longo de sua execuo. Documentos necessitam ser aprovados por gerentes ou coordenadores, e vendedores necessitam inserir pedidos no sistema. Cada um destes perfis so identificados dentro do BPMN em elementos chamados pools ou lanes. A pool seria a piscina onde os competidores nadam. As lanes so as raias, onde cada nadador ir se apresentar. O resultado do processamento, neste caso, ser o conjunto de processamentos das vrias lanes (o nadador que chegar em primeiro lugar do outro lado). O conceito de pools e lanes est muito preso aos mecanismos de segurana das solues BPMS. Um vendedor pode inserir um pedido, mas apenas um coordenador pode aprovar uma compra atravs de carto de crdito. Quando o fluxo modelado j se considerando os pools e lanes, fica mais fcil no futuro organizarmos os vrios perfis que iro executar cada uma das atividades. Mas, qual a diferena entre um pool e uma lane ? Bem, o pool define um fluxo de processo, onde em seu interior o processamento ocorre independentemente do que acontece ao seu redor. Um pool como se fosse um mdulo ou programa independente de um sistema. Imaginando o exemplo de uma piscina, se ela estiver dentro de um estdio, vrias outras atividades esportivas podem estar acontecendo simultaneamente, mas a competio dentro da piscina independe destas outras atividades que acontecem simultaneamente no estdio. J uma lane define o perfil que est executando a atividade em dado momento. Via de regra, uma pool define um processo, enquanto que a lane define os participantes que iro concretizar este processo.

20

5.1 - Instncias de processos

Imaginando que temos um desenho de processo pronto, surge a dvida do que seria uma instncia de processo. Uma instncia uma execuo isolada de um processo. Um programa instalado em um computador como se fosse um processo. J as vrias instncias em execuo seriam os programas executando em dado momento em um computador. Cada vendedor dentro de uma loja, atuando em seu processo de vendas uma instncia de processo isolada. Todos seguem os mesmos passos, mas cada um de forma independente. A longevidade de uma instncia de processo muito variada, podendo ir de minutos a dcadas para processamento. Ou seja, uma vez iniciado um processo, ele se mantm (ou deveria se manter) em execuo at que seu trmino fosse atingido. Se estivermos imaginando um processo executando em um computador, importante que esta caracterstica seja preservada, ou seja, se o computador for desligado, quando for reiniciado deve retornar ao mesmo ponto em que estava anteriormente. De forma similar, diversas instncias de um mesmo processo podem estar ativas ao mesmo tempo. Uma loja de varejo, onde existam vrios vendedores, cada um deles pode estar conduzindo uma instncia de processo de vendas, de forma totalmente independente. Algo deve acontecer para que o processo inicie uma instncia, e o mesmo para que ele seja finalizado. Processos so iniciados e terminados atravs de eventos. Uma vez iniciado, deve acontecer um evento que o finalize.

21

6 - Eventos
De acordo com a especificao BPMN, os eventos aparecem durante a execuo de um fluxo ou so gerados durante sua execuo. Somente os eventos tm a capacidade de iniciar ou terminar um processo, mas os eventos no executam tarefas no processo. Eles podem forar a execuo ou mesmo desviar para uma determinada atividade. A representao grfica dos eventos feita por crculos, que podem ser de trs tipos: 1) iniciais 2) intermedirios 3) finais Os eventos de incio foram a criao de uma nova instncia de execuo para o fluxo. Antes dele, no existia esta instncia de processo em execuo. Algum fato gerador externo ir causar a gerao do evento. O incio do processo por si s um evento. Os eventos intermedirios acontecem ou so gerados ao longo da realizao de um fluxo j em execuo. Podem ser gerados pelo fluxo em execuo ou podem ser receptores de um evento gerado por outra intncia. Quando so criados dentro do prprio fluxo (geradores) provavelmente iro gerar alguma notificao a alguma outra instncia de fluxo em execuo. Quando so gerados externamente ao fluxo de processo em execuo (receptores), iro influenciar de alguma forma a execuo de outro fluxo. Existem os eventos finais, que terminam a instncia do processo. Aps um evento final, nenhuma outra atividade pode ser executada, embora o prprio evento possa gerar informaes que afetem outros fluxos em execuo.

22

Devemos ter em mente que os fluxos funcionam como organismos vivos, podendo existir vrios deles em execuo simultnea, e cada um se comunicando com outros por meio de eventos. A nica forma de uma instncia de fluxo comunicar-se com outra mediante o envio e recepo de eventos. Para podermos diferenciar os eventos de incio, intermedirio e final, de forma visual, existem representaes grficas distintas para cada um deles. Um evento de incio um crculo com uma linha simples em sua borda, um evento intermedirio representado por um crculo delineado por linhas duplas, e um evento final delineado por um crculo com linha de espessura dupla. Veja os tipos de eventos existentes.

O set completo BPMN define, alm desses trs tipos, o fato gerador do evento, ou seja, o causador da execuo do evento. Estudaremos os vrios fatos geradores, iniciando-se com os eventos de timer.

7-

Eventos de timer

Os timers permitem controlar o tempo ou definir datas para execuo de atividades. Um evento de incio de timer indica o incio da execuo de um fluxo em perodos predeterminados de tempo. Um incio de timer pode demarcar uma data especfica, como todo ltimo dia do ms (para processamento de uma folha de pagamento); pode indicar uma hora especfica, como s dez horas (para iniciar um backup, por exemplo); pode indicar uma data e hora, como dia 23 de janeiro de 2008 (lanamento do livro Modelagem de Processos de negcios com BPMN); como tambm pode ser um evento relativo data atual (cinco horas contando a partir deste momento).

23

A Figura anterior indica um evento de incio. Uma soluo BPMS de mercado fica validando, normalmente, cada evento de incio, verificando se ele coincide com o momento atual. Quando se encontra uma situao de incio, inicia-se uma instncia do processo. Um evento intermedirio de timer pode operar de duas formas. Se ele estiver no meio da execuo do fluxo, interligando duas atividades, como na figura a seguir, significa um atraso inserido entre a execuo das duas atividades.

Isso indica que aps a atividade Aguarda cadastro o fluxo ficar congelado pelo tempo definido pelo relgio antes de continuar a prxima execuo, que Continua processamento. Mas um timer intermedirio pode igualmente estar ligado borda de uma atividade e ir indicar, nesse caso, um cdigo de proteo. Se acontecer a condio antes do trmino da execuo da atividade, o processamento ser desviado para a atividade que estiver conectada ao fluxo.

24

No exemplo anterior, uma atividade solicita o recadastramento, mas pode levar um tempo at que seja executada pelo usurio, assim como pode ficar para sempre no aguardo, j que o usurio pode nunca se cadastrar. Nesse caso, o evento de timer significa dizer que, se o usurio no realizar a atividade em at cinco dias, a atividade Remove usurio ser executada. Caso ela seja realizada dentro desse prazo, Remove usurio nunca ser executada e o processamento continua por Cadastra dados no sistema. Em qualquer dos dois casos, o processamento continua por Prximas atividades. Outra modalidade, nessa representao, seria a de no ter a continuao do fluxo, e forar sempre a sada pelo mecanismo de exceo. Nesse caso, mesmo aps a execuo de Solicita recadastramento, o fluxo fica no aguardo do final dos cinco dias para continuar por Remove usurio. Funciona como se o evento estivesse conectado entre as duas atividades. Basicamente, executa-se um evento timer atachado borda de uma atividade quando se atingiu o perodo limite ou a data configurada antes do final da execuo da atividade. Perceba que pode ser tambm um sub-processo, com diversas atividades em seu interior, como na figura a seguir.

25

No exemplo da figura anterior, pouco importa o nmero de atividades existentes dentro de Cadastro e validao. Quando se atingir o tempo final de cadastramento, cessa o sub-processo Cadastro e validao, e continua o processamento, por meio de Distribui as atividades. Foramos a execuo da exceo sempre, pois a nica sada para o fluxo neste caso. Deve-se tomar cuidado com este tipo de abordagem, pois se o desvio acontecer pelo timer, o sub-processo pode ficar truncado, e a especificao no dita regras para o que acontece com os cdigos j processados dentro da atividade. No est definido nem faz sentido um evento de timer como finalizador.

8 - Eventos de mensagem
Uma mensagem um mecanismo de envio de informaes entre instncias de processos. A notao BPMN no define o que se utilizar como tecnologia para envio, como SMTP, JMS ou qualquer outro mecanismo, como tambm no define o formato das informaes a serem enviadas. Uma implementao especfica de soluo BPMS far o tratamento mais adequado ao processamento de mensagens. Os eventos de incio de mensagem criam uma nova instncia de processo, baseado no recebimento de uma mensagem.

26

Na Figura anterior, temos dois fluxos de processos. Quando o fluxo superior se inicia e quando a Atividade1 executada, para um evento intermedirio que significa envio de mensagem. Um evento de mensagem entre duas atividades pode ser fonte geradora, como no caso anterior, onde ser enviada a mensagem e o fluxo ir continuar, ou pode ser fonte receptora, se uma seta chegar at a mensagem. Neste caso, quando o evento inicial de mensagem for gerado, ele ir forar a criao do fluxo inferior. Neste caso, se inicia uma nova instncia. Mas aps o envio da mensagem no fluxo superior, o mesmo continua a execuo da atividade2, e os dois fluxos executam em paralelo e de forma completamente independente. O nico momento em que houve comunicao foi no momento do envio de mensagens, que causou a criao de uma nova instncia de fluxo.

27

No exemplo da figura anterior, acontece uma srie de eventos-mensagem. Primeiro, a partir de uma atividade envia-se uma mensagem que inicia outra instncia de processo. Isso feito em Solicita dbito ao banco. A notao dita que um evento de mensagem na borda deve ser receptor. Uma mensagem saindo diretamente de uma atividade indica que existe um evento de mensagem sendo gerado por esta atividade. Na seqncia do fluxo, a atividade autoriza retirada na loja envia uma mensagem para o fluxo abaixo, que deveria estar no aguardo para continuar o processamento. Uma vez recebida a mensagem, a atividade retirada do produto na loja executada, e os fluxos finalizam. Embora no esteja claro, os fluxos anteriores so independentes, ou seja, esto posicionados em pools diferentes. Isto pode ser afirmado porque a comunicao entre eles est sendo feita por mensagens, e no seria possvel enviar mensagens se as atividades estivessem dentro de um mesmo pool. Pode-se dizer que so dois fluxos colaborativos. Quando a atividade est posicionada na borda, como no exemplo a seguir, existe uma outra interpretao possvel.

28

No exemplo anterior, o evento de mensagem na borda da atividade Retirada de produto na loja est posicionado na borda. Esta representao indica um fluxo de exceo de mensagem. Aps a operao de dbito, existe um OR, o qual indica que se tomar um dos dois caminhos. Caso se tome o caminho de erro no processamento (aquele que gera a mensagem), quando a mensagem chega at Retirada do produto na loja, gera-se um desvio, com base no recebimento dessa mensagem. Nesse caso, a operao cancelada, visto que o fluxo de exceo foi acionado. Em resumo, existem dois comportamentos para atividades de mensagem conectadas borda. Quando o fluxo sai do evento, indica exceo e somente pode ser utilizado posicionada na borda de uma atividade. Quando a mensagem chega at uma atividade, indica que esta atividade estava no aguardo do recebimento para continuar o processamento. Cabe salientar que esse o comportamento padro definido pela especificao, que at deixa alguma dupla interpretao para este tpico.

9 - Eventos de dados
Podem-se utilizar eventos de dados como incio e intermedirio. Quando utilizados no incio de um processo, indicam que se criar uma instncia do processo, quando um valor atingir determinado patamar. O modo como os dados so conectados soluo BPMS e o nmero de vezes que essa soluo verifica pelos valores ficam sob completa responsabilidade da implementao BPMS. Lembre-se de que o BPMN uma notao grfica, sem pretenses de como ser executado.

29

Um processo automatizado de compra de materiais poderia iniciar um subprocesso de compra de papel para impressora quando fosse detectado, no estoque, a existncia de um nmero baixo de pacotes de folhas. Quando colocado na borda de uma atividade, sempre indica um fluxo de exceo. Ou seja, quando estiver dentro da atividade, se o patamar for atingido, o fluxo seguir pelo caminho de exceo. Veja um exemplo na figura a seguir.

Nesse caso, o sub-processo Cadastro de alunos fica em execuo coletando novos alunos para um novo curso. Ele somente sai desse loop quando uma de duas coisas acontecer. Ou o tempo para inscrio se encerrou, o que se denota com um timer, ou o nmero mximo de alunos por sala foi atingido, o que se indica pelo evento de dados. Como no existe continuao do fluxo depois de Cadastramento de alunos, ser necessrio que uma das duas excees acontea, para que o fluxo continue por meio de Finaliza processo de cadastramento. Este tipo de evento pode tambm ser utilizado como incio para um processo ou sub-processo. Por exemplo, quando o limite do estoque est baixo, automaticamente o processo de compras se inicia, como no exemplo a seguir.

30

No permitido que um finalizador gere um evento de dados, ao menos na especificao atual do BPMN.

10 - Controles de exceo e compensao

Na maioria das situaes, o BPMN ser utilizado para orquestrar Web Services. Nesse cenrio, surge um problema, pois os Web Services so atmicos e sncronos. Isso quer dizer que, uma vez chamado, um servio ser executado se estiver disponvel, e o resultado do processamento persistir imediatamente. Em resumo, no h rollback de Web Services. Imagine uma seqncia de chamadas a servios que precisam operar em forma de bloco, de forma a efetivar todos ao mesmo tempo ou a cancelar todos como uma unidade. Como um servio atmico, foi necessrio criar mecanismos que permitissem que grupos de servios pudessem ser desfeitos, caso algum deles apresentasse algum problema. Como parte da especificao BPMN, existe um controle de excees e compensaes criado sob a forma de eventos gerados. Basta conectarmos a borda de uma atividade composta por vrias atividades que devem ser atmicas, a um evento especial que atuar como captura de erros que acontecem. Quando se efetuar o desvio para essa outra atividade, os processamentos efetuados podero ser desfeitos, de modo que se retorne o processamento ao estado inicial.

31

Vale salientar que, nas implementaes de bancos de dados atuais, esse mecanismo no funciona como nos rollbacks BPMN, que nem sequer chegam a alterar as informaes. Em resumo, as tecnologias de EAI esto mais modernas do que o mecanismo de compensao proposto pela especificao BPMN. Em vez disso, na implementao de compensao do BPMN os dados so alterados e depois retornam aos valores originais, atravs de uma atividade especial de compensao, o que pode acarretar efeitos colaterais quando utilizamos servios a partir de cdigo legado. A figura a seguir ilustra a representao desse mecanismo.

Nesse caso, coletam-se os dados do cliente e efetua-se a compra de passagem. Duas atividades precisam ser executadas: efetuar a reserva no vo e a cobrana do valor. Caso falhe algum desses servios, acontecer um desvio para a compensao, que ir garantir que o valor nunca ser cobrado ou que o avio no decolar com o assento reservado, porm vazio. Se por outro lado, os dois servios forem executados com sucesso, o processamento continuar em Avisa cliente da operao.

32

Eis uma pergunta de cunho maldoso: e se ocorrer uma falha ao estornar o valor ao cliente? Podemos capturar esse erro e direcion-lo a uma atividade que ir efetuar o tratamento. Nesse caso, o erro mais grave e o chamamos de exceo, que precisa de ateno especial. Pode-se representar uma parte do desenho acima da seguinte maneira:

Nesse caso, houve um erro na compensao, e solicitou-se interveno manual da operadora, a fim de evitar resultados mais graves. Podemos unir a compensao e a exceo em apenas uma atividade, como ilustra a figura a seguir.

33

Nesse caso, a sub-atividade compra de passagem podese formar por pela cobrana da passagem e pela alocao. Caso ocorra algum erro no processamento de um servio, este se desviar para a compensao, que por sua vez tentar desfazer o processo. Se ainda dentro de compra de passagem ocorrer um erro grave, ser gerada a exceo que enviar uma mensagem ao operador do sistema, o qual far uma interveno manual. As compensaes so erros no to graves, onde se tenta corrigir o problema, retornado a um estado possvel de execuo. J os erros so mais graves, e exigem um tratamento especial. A forma como as solues BPMS tratam esses erros e compensaes definida por sua implementao. Entretanto, a notao permite uma representao visual mais simples e representa erros de forma visual; erros que, de outra forma, teriam que ser representados como parte do fluxo, mas nada tem a ver com as regras de negcios. Se no tivssemos a compensao e as excees, teramos um trecho como o da figura a seguir.

Nesse caso, prevemos o tratamento de um erro por meio de elementos condicionais; o que ruim, pois os condicionais deveriam representar apenas decises relativas lgica de negcios. Quando se utilizam condicionais para representar tanto a lgica quanto os tratamentos de erros, tornam-se complexos os diagramas e, com freqncia, de difcil compreenso. Quando se utilizam compensaes e excees, usam-se elementos diferentes para cada representao no diagrama.

34

11 - Conexo entre diagramas

Algumas vezes o diagrama se torna to extenso que no conseguimos conectar certas partes, sem que as linhas fiquem cruzadas. Existe um mecanismo simples de link, que permite conectar elementos dentro de um diagrama, ou mesmo elementos entre dois diagramas distintos. Informamos que dois links esto conectados atravs de seu nome. O nome funciona como se fosse uma chave para os dois links. Um link pode ser representado como :

12 - Terminadores do processo
Existem atualmente trs formas de finalizarmos um processo. As trs representaes possveis so :

35

O primeiro tipo, com um circulo preenchido no interior, indica trmino incondicional. Isto significa que o processo deve ser terminado neste momento, sem compensao, tratamento de erros ou quaisquer outros tratamentos. Se for um sub-processo, encerra imediatamente e retorna ao fluxo pai. O trmino com um X no interior indica cancelamento da transao. Os mecanismos de compensao e erros trabalham em conjunto com o cancelamento. Normalmente o cancelamento iniciado programaticamente, enquanto que a compensao e exceo so geradas por erros no processamento.

36

Supondo um sub-processo escolha, sendo que desdobrado se torna um fluxo como o da parte superior da figura. Caso a escolha do usurio for invlida, ser gerado o cancel, que capturado pelo evento cancel conectado borda da atividade. Neste caso, se redireciona para um outro tratamento, onde a seleo no escolhida ser tratada como se fosse uma exceo.

13 - Resumo dos tipos de eventos da BPMN

37

14 - Gateways
Gateways so os mecanismos padronizados do BPMN para efetuarmos desvios. Os vrios tipos de desvios, como AND (E), OR (OU) e XOR (OU exclusivo) so tratados com simbologias distintas pela notao. Assim como os eventos so representados por crculos, os gateways so representados por losangos.

15 - Eventos do tipo XOR (OU exclusivo)

Os eventos do tipo XOR (OU exclusivo) podem ser representados de duas formas

Este tipo de gateway o mais simples de se entender, pois ele representa o OU, onde o acesso a um dos caminhos exclusivo. Ou seja, apenas um dos caminhos ser seguido, no importando quantos caminhos existam para escolha. Um exemplo deste tipo de representao poderia ser a escolha do tipo de pagamento de um produto :

38

Neste caso, o pagamento ser feito via transferncia bancria ou por carto de crdito. Qualquer dos caminhos tomados, haver uma juno na frente, fazendo com que o fluxo continue aps um dos caminhos. Este caso de fcil compreenso, pois apenas um dos caminhos seguido. Existem situaes onde mais de um caminho pode ser seguido (OR) ou mesmo todos os caminhos sero sempre seguidos (AND). Neste caso, para poder explicar melhor o conceito do que acontece nestes casos, a especificao utiliza o termo TOKEN. Precisamos entender este conceito para compreender os outros tipos de gateway.

16 - Token
Imagine que uma instncia de fluxo de processos foi criada. Neste caso, a execuo segue pelo caminho natural de execuo, mas como existem gateways que permitem mais do que um caminho em paralelo, podemos ter dois caminhos sendo executados ao mesmo tempo, dentro de uma instncia de processo. Veja este exemplo :

39

O processamento se inicia normalmente, com a criao da instncia. Podemos chamar neste caso T1 a instncia em execuo. O problema que quando passamos pelo AND (o gateway com sinal de mais dentro) dois caminhos so seguidos em paralelo, representados neste caso por T1A e T1B. Se estivssemos nos referenciando a linguagens de programao, teramos o processo em execuo (T1) e duas threads executando em paralelo. exatamente este o conceito de Token. Mas, se equivalente uma thread, porque no cham-la diretamente por este nome ? Bem, em primeiro lugar o termo thread diz respeito a uma linguagem de programao, e neste conceito os dois braos de execuo (T1A e T1B) no precisam estar realmente executando ao mesmo tempo. A notao BPMN no fora a que uma implementao de soluo BPMS tenha todo o conceito de multi-thread embutido dentro dela. Mas a notao diz simplesmente o seguinte : Uma vez criados mais de um token a partir de uma bifurcao, o processamento somente continua aps todos os tokens chegarem at a juno. Esta frase abre margem para mais de uma interpretao, e em nenhum momento estamos dizendo que a execuo est acontecendo em paralelo. Dissemos que os dois braos de execuo precisam chegar ao ponto de encontro, para que o processamento continue aps a juno do gateway. Desta forma, uma soluo multi-threaded pode executar seleo de produtos e consulta serasa realmente em paralelo, o que seria interessante, mas tambm pode executar primeiro a atividade seleo de produtos, depois a atividade seleo de forma de pagamento e depois a atividade consulta serasa, para somente ento continuar aps a juno do gateway. Perceba que para qualquer das duas implementaes, no h diferena aparente em termos de processamento, a no ser pela menor velocidade das atividades sendo executadas de forma seriada.

40

Paralelo ou no, necessitamos de um conceito para indicar esta independncia criada pelo conceito de bifurcao e novamente dependncia criada pela juno. Com este conceito de Token em mente, podemos explorar os outros tipos de gateway existentes.

17 -Eventos AND (E)

Este caso exatamente o exemplo anterior. Quando se chega at a bifurcao do tipo AND, se seguem os dois caminhos, atravs de dois tokens criados. No h processo de deciso, e todos os caminhos so seguidos. O objetivo de utilizao do AND pode ser tentar otimizar o tempo de processamento, permitindo interaes em paralelo pelos vrios perfis de execuo.

18 - Eventos OR (OU)
Os eventos do tipo OU permitem que se navegue por um ou mais caminhos durante o fluxo de execuo. Ao contrrio do OU exclusivo, pode-se seguir um ou mais dos caminhos. necessrio que ao menos um dos caminhos seja vlido para navegao.

19 - Tratamento de eventos
Outra necessidade decorrente da especificao BPEL so os eventos mltiplos. Imagine uma situao em que um processamento deve aguardar o acontecimento de um evento. Na verdade, pode acontecer uma de vrias possibilidades de evento. Esse evento pode ser o recebimento de uma mensagem ou um timer expirando depois de dois dias. Nesse caso, h duas possibilidades de eventos. A primeira que acontecer continuar o processamento, e as outras opes so canceladas. Veja um exemplo na figura a seguir.

41

20 - Eventos multiplos
Nesse caso, o mdico solicita um exame e duas so as possibilidades: o cliente pode fazer o exame solicitado e retornar ao mdico, ou o cliente pode ignorar a solicitao e dirigir-se a outro mdico. Caso o cliente faa o exame, o mdico emitir uma receita com base nos resultados. Caso no haja retorno, a ficha do cliente ser arquivada. Nos dois casos, o processamento continua pela notificao do plano de assistncia mdica. Vale salientar que, aps adotar uma possibilidade, ignora-se a outra. Caso o resultado dos exames seja enviado ao mdico, nunca ocorrer o arquivamento da ficha do cliente. Esse tipo de estrutura chamada de deciso complexa baseada em eventos e corresponde ao elemento pick da BPEL. Claramente a documentao indica que a implementao deste elemento foi no sentido de facilitar a migrao de desenhos criados em BPEL.

42

21 - Eventos Complexos
Algumas vezes nenhum dos trs tipos de gateways (OR, AND e XOR) suficiente para representar uma situao. Os gateways testam uma nica condio, mas algumas vezes necessitamos testar mais de um dado para tomada da deciso. Outra necessidade a mistura de um comparador comum (AND, OR ou XOR) com um comparador baseado em eventos. Neste caso, foi criado um coringa chamado evento complexo, onde cada uma de suas sadas pode efetuar testes distintos, e decises podem ser tomadas de forma mais completa. Outra utilizao para este tipo de elemento existe quando precisamos saber se uma determinada sada foi escolhida, em funo de outras escolhas.

43

Neste caso, podemos ter compras vista, em dinheiro ou prazo. Caso a compra seja vista ou em dinheiro, o caminho seleo de brinde tambm executado. Caso a compra seja a prazo, seleo de brinde no executado. Desta forma, uma sada pode tomar decises em funo de outras sadas. Os outros tipos de gateway no permitem este tipo de comportamento.

22 - Gateways diretamente em fluxos

Embora obscuro, podemos representar gateways diretamente na sada das setas que saem das atividadades. O diagrama se torna de mais difcil leitura, mas reduz a quantidade de gateways.

Quando a sada de um fluxo contm um losango, significa que uma deciso deve ser aplicada. Quando a seta contm um corte diagonal, significa que a sada default. Se a seta no contiver nenhum destes dois elementos, significa que o caminho deve ser seguido. Se houver mais de um caminho, todos eles devem ser seguidos. Portanto, as duas representaes a seguir so idnticas, em termos de BPMN.

44

No primeiro caso, a sada da atividade segue por dois caminhos, o que significa que h uma bifurcao. No segundo, est representado atravs do gateway uma bifurcao. Para junes, o processo o mesmo, ou seja, duas setas chegando a uma atividade representam a juno de um AND. Para elementos do tipo XOR, seria algo como :

No primeiro caso, o losango indica uma condio, que se no for respeitada, far com que o fluxo siga pelo caminho default, para evento 3. Esta representao similar ao desenho da direita, mas utilizando o gateway para XOR.

45

23 - Atividades e tarefas
Uma atividade uma unidade de trabalho em um processo. Pode significar uma interao com o usurio, ou algum processamento independente do perfil. Quando a atividade to isolada que no faz mais sentido subdivises, ela chamada de tarefa. Uma tarefa, portanto, uma particularizao do conceito de atividade. Da mesma forma, um sub-processo um tipo de atividade onde sabidamente existe pelo menos um grau de detalhamento em seu interior. Se fssemos dividir em temos de hierarquia, poderamos pensar no processo como sendo a atividade de mais alto nvel (algumas vezes chamado de macro-atividade). O processo dividido em atividades menores, chamados sub-processos. Estes sub-processos vo sendo cada vez mais detalhados, at que chegamos em um nvel onde no h mais detalhamento, este chamado de tarefa (task). De forma geral, qualquer tipo de atividade representado por um quadrado com as bordas arredondadas.

24 - Loop
Algumas vezes necessitamos executar repetidas vezes uma atividade, como por exemplo calcular o imposto para cada um dos produtos de uma lista de compra. Poderamos utilizar um trecho de cdigo para indicar este clculo, algo como :

46

Basta colocar um condicional, normalmente um XOR, e uma condio para que o fluxo tenha uma sada. Para este caso, poderamos representar atravs de uma atividade do tipo loop, de forma mais sinttica.

Em muitas situaes o loop ir executar uma seqncia de tarefas, portanto podemos utilizar um loop associado ao elemento de sub-rotina, que representado por um sinal de soma na representao.

47

O padro BPMN recomenda que uma sub-rotina tenha o sinal de soma na parte inferior, e caso seja clicado deveria se expandir, apresentando uma miniatura do diagrama que normalmente estaria em seu interior. Este comportamento no obrigatrio, mas parece ser a forma mais intuitiva de tratamento deste tipo de elemento.

25 - Mltipla instncia
Outra forma de representao para o loop a execuo de mltiplas instncias. Neste caso, a representao de duas barras verticais dentro da atividade.

48

A diferena bsica entre as duas representaes a forma como cada um dos elementos tratado. No loop, os elementos so tratados um a um, mantendo sempre um nico token ativo. No caso do processamento paralelo, para cada um dos elementos a ser tratado gerado um novo token, fazendo com que cada um dos elementos tenha um tratamento independente, causando o processamento em paralelo nas implementaes que suportem multi-thread. Na verdade, a escolha por um ou outro tipo de simbologia pode trazer impactos na implementao. Se necessitarmos sumarizar um valor, como no exemplo anterior de calculo de imposto, o loop recomendado. Caso os elementos possam ser tratados de forma totalmente independente (lembre-se de que cada token pode ser tratado como uma thread por uma linguagem de programao) podemos utilizar o paralelo.

26 - Compensao
A compensao um tipo de atividade focada na execuo de um roolback, ou retornar o estado de um processo a um estado anterior, para que o processo possa ser executado. Ele normalmente utilizado em conjunto com o evento de compensao, que redireciona para esta atividade quando necessrio.

49

Repare os dois tringulos dentro do evento de compensao, neste caso Libera assento alocado e Estorna valor cobrado. Eles indicam este tipo de atividade como uma compensao.

27 - Ad Hoc
H uma grande discusso na internet sobre o BPMN ser capaz de representar situaes de uso corriqueiro em termos de processos. O contra exemplo mais utilizado aquele de um escritrio de advocacia, lidando com um processo de cliente. Embora existam vrias atividades a serem executadas, como cpias autenticadas de documentos, obteno de assinaturas, agendamento de audincias, entre outros, muitas vezes no temos como garantir em que ordem estas atividades iro acontecer. O importante que todas elas estejam finalizadas para que possamos passar para uma etapa seguinte. O mesmo pode ser aplicado tarefa de escrever um livro. No necessariamente h uma ordem para sua escrita, desde que todos os captulos estejam prontos para sua publicao. Uma atividade do tipo Ad Hoc identificada por um til dentro, mas as atividades em seu interior so soltas, ou seja, no esto conectadas. Considera-se o final da atividade Ad hoc quando todas as atividades em seu interior tiverem terminado. A simbologia para este tipo de atividade a seguinte :

50

Veja um exemplo de atividade do tipo Ad Hoc

51

28 - Pools e Lanes
Pools so compartimentos onde os elementos do fluxo so acomodados, de forma a indicar que participante do processo ou um perfil est executando cada atividade. De forma geral, a pool ou lane no interfere nem define o que ser feito, mas sim quem o far. Est associado a mecanismos de segurana normalmente. A especificao no define o tipo de elemento, que pode ser um departamento, perfil ou pessoa. A representao recomendada de uma caixa, com uma linha vertical separando os elementos de um ttulo para o pool ou lane.

Uma pool o elemento mais externo, ou seja, no se pode inserir pools dentro de pools. As lanes so elementos que so posicionados dentro de pools, para indicar mais de um perfil que colaboram para a execuo de um processo.

52

Se os elementos internos de uma pool ou lane so representados, ele pode ser um diagrama privado ou de colaborao (leia o captulo processos). Se por outro lado os elementos no estiverem visveis, mas apenas como dois pools colaboram, chamamos de diagrama de colaborao. Cada pool considerado um fluxo isolado, e a nica forma de elementos entre dois pools se comunicarem atravs de mensagens. Ou seja, no permitido fluxos entre dois elementos do tipo pool.

Podemos visualizar duas pools como duas instncias de processos distintas, onde a nica forma possvel de interao o envio de mensagens, onde esta mensagem enviada pode interferir no outro fluxo, caso este fluxo tenha sido preparado para o tratamento desta mansagem. No conceito de Tokens, existe ao menos um Token para cada pool, e estes Tokens nunca se encontram, ou seja, cada um permanece em sua instncia de processo at o trmino de algum deles. No h formas de se encerrar vrios pools ao mesmo tempo.

53

O mximo que podemos modelar enviar uma mensagem de um pool para outro, e modelar o segundo fluxo de forma que o processo tambm seja encerrado. Em resumo, dois pools so como que dois programas totalmente distintos, onde a nica forma de comunicao atravs do envio de mensagens. De forma similar, os mecanismos de mensagens foram criados para envio de informaes entre dois processos distintos. No faz sentido, e a especificao julga ilegal enviar mensagens dentro de uma mesma pool.

Esta restrio parece a mais fcil de compreender, se pensarmos em termos de tokens. No momento em que estamos na atividade1, existe apenas um token. O fluxo de processo ir continuar pela execuo de atividade 2 e atividade 3 mantendo um nico token. Mas, em atividade 1 estamos enviando uma mensagem para atividade 3, que somente ser executada l na frente. Qual o sentido de enviar uma mensagem para uma atividade que no tm a capacidade de executa-la no momento ? Lembre-se de que o envio de mensagens no desvia o fluxo, e a atividade receptora somente pode trata-la se estiver processando ou aguardando por ela. Portanto no faz sentido enviar mensagens dentro de uma mesma pool.

54

Se estamos trabalhando com pools abstratos (aqueles que no mostram os elementos internos) pode ser interessante mostrar os pontos de conexo entre duas pools, portanto permitido enviar mensagens entre atividades de dois pools ou mesmo mensagens de um pool diretamente ao outro.

Neste exemplo, deve ficar claro que no financial institution quem est enviando mensagens para o outro fluxo abaixo, mas sim uma de suas atividades internas. Como no esto visveis quais so estas atividades internas, se moveu a representao da mensagem para a borda da pool.

55

29 - Artefatos
Artefatos so elementos extras que podem aparecer dentro do diagrama, mas que no alteram o fluxo nem executam tarefas. Eles servem como representaes que iro aumentar a clareza do diagrama ou expor certos pontos importantes. A notao define um set reduzido, mas outros elementos poderiam ser acrescentados pelas implementaes de ferramentas.

30 - Dados
Embora no seja preocupao do BPMN, algumas vezes desejamos tornar claro por quanto tempo e at onde um elemento de dados est sendo propagado. Este dado pode ser uma informao isolada ou mesmo um bloco de informaes.

No exemplo a seguir, desejamos deixar claro que os valores esto sendo sumarizados, e podero ser utilizados em um ponto a seguir no desenho dos processos.

56

A linha conectando o artefato de dados atividade e ao condicional pode indicar que o elemento vlido durante aquele perodo de tempo, representando a longevidade da informao. Tambm pode informar que um dado passou de um estado para outro, como no exemplo a seguir :

Na verdade, os elementos de dados podem funcionar como coringas que representam a informao, onde quer que ela esteja.

57

31 - Grupos
Grupos no afetam o fluxo de processos nem adicionam restries. Da mesma forma que os elementos de dados, eles agrupam atividades e outros elementos de forma a tornar visveis blocos importantes de operao. So meramente posicionais, e portanto permitido que um grupo atravesse duas pools, como no exemplo a seguir.

58

Parte II ERROS COMUNS NO DESENHO BPMN

59

1 - Gateways de tipos diferentes na juno e bifurcao

Normalmente utilizamos um mesmo tipo de bifurcao e juno, como no exemplo a seguir :

Isto garante que os tokens gerados sero sincronizados na sada. No exemplo anterior, foi criado um AND, que fez com que as atividades seguissem em paralelo. Na juno do fluxo ser aguardado o trmino dos dois tokens, para que o processamento continue. Isto funciona desta forma porque a bifurcao de AND gera tantos tokens quantas forem as sadas, e a juno aguarda por todos os tokens gerados para continuar aps o processamento. Temos alguma flexibilidade nesta utilizao, mas devemos utilizar com cuidado. Uma possibilidade a de adotarmos gateways de tipos diferentes, para juno e bifurcao. Ligeiramente diferente, o exemplo anterior ficaria :

60

Neste caso, dois tokens sero gerados para paralela 1 e paralela 2. Mas o token de juno um OR, o que significa que a primeira das atividades que chegar ao fluxo far com que o mesmo continue. Quando o segundo token chegar at a juno, ser descartado, j que o fluxo j continuou assim que o primeiro Token foi detectado. Neste caso, pode no ser to grave, a menos que as atividades aps o gateway necessitem de informaes ou dados gerados por alguma das duas atividades. Neste caso, como no sabemos qual ir terminar primeiro, corremos o risco de seguir adiante sem termos os dados consolidados para utilizao. Mas, nesta mesma linha podemos cometer um erro grave, que poder causar impacto muito srio na execuo do fluxo criado.

Neste caso, apenas um token ser gerado com absoluta certeza, j que a bifurcao um XOR. Entretanto, colocamos um AND na juno, que ir aguardar pela chegada dos dois tokens, embora apenas um tenha sido criado. Acabamos de gerar um dead lock, que far com que qualquer fluxo que passe por este trecho permanea travado pela infinidade. Este termo (dead lock) utilizado para um trecho em execuo que causa um travamento, impossibilitando a continuidade da execuo. Outra modalidade de erro pode causar inconsistncias no processamento, podendo ser at mais grave do que um dead lock.

61

Neste caso, foi gerado um token, mas este no passou pela juno, chegando a um ponto mais distante do cdigo. No difcil se criar fluxos com alguns nveis de gateways, tornando totalmente imprevisvel o resultado de processamento dos mesmos. Portanto, algumas regras podem salvar erros em um fluxo : 1) Utilize bifurcaes e junes do mesmo tipo 2) Garanta que uma atividade que passou por uma bifurcao continuou o fluxo passando por uma juno

2 - Gateways baseados em eventos

62

Os gateways baseados em eventos foram criados com o objetivo de permitir que um fluxo fique no aguardo de um evento, para continuar. Uma atividade no um evento, e portanto esta representao no permitida. Outra particularidade sobre esta representao que o gateway fica no aguardo de um dos eventos acontecer, e continua aps a recepo do primeiro dos eventos. Todos os outros eventos so descartados aps a execuo deste caminho. Este tipo de condicional baseado em eventos um XOR (OU exclusivo) pois somente um caminho seguido. Ao contrrio dos outros gateways, este no necessita de uma juno para sincronizar os tokens. Veja um trecho de fluxo aparentemente invlido, mas correto sob ponto de vista da notao.

No caso anterior, caso o caminho seja o brao mais inferior, o processamento termina com o envio de uma mensagem. Se qualquer dos outros caminhos for seguido, o fluxo segue at o final do processamento.

3 - Utilizao de elementos de fluxos com fluxos condicionais

63

No faz sentido utilizar as notaes de condicional e default conectados sada de um gateway, como no exemplo anterior. Ou utilizamos o gateway, ou utilizamos os fluxos diretamente na sada da atividade, utilizando desta forma a notao alternativa.

Fluxos no podem sair de gateways, como no exemplo anterior, nem mesmo chegar a ele. De uma forma geral, mensagens no podem ficar contidas dentro de pools. Todas as mensagens devem cruzar uma pool e atingir outro fluxo externo. Embora parea evidente, no podemos ter gateways com apenas uma sada. Eles so pontos de deciso, e devem fornecer alternativas ao caminho do fluxo.

64

4 - Erros comuns no desenho BPMN Eventos

A notao dita que os eventos de incio apontam para o comeo do fluxo, e eventos de finalizao terminam um fluxo. No obrigatrio que existam eventos de incio e final, mas se existirem, devem aparecer aos pares. O seguinte exemplo portanto no permitido :

Por outro lado, podemos ter vrios incios para um fluxo, e se conveniente, podemos representar mais de um final. Quando um fluxo iniciado, caso no existam os eventos de incio todas as atividades que no tiverem uma seta chegando at ela so considerados pontos de incio para o fluxo. Quando uma instncia de fluxo criada, so criados tantos tokens quantos forem os pontos de incio do fluxo. Outro erro comum relacionado aos eventos que apenas mensagens ou atividades so geradores e consumidores de mensagens.

65

Neste caso, um timer no pode ser o gerador de uma mensagem. Mensagens so geradas por atividades e podem chegar a outras atividades ou a elementos de evento de mensagens. Mensagens intermedirias no podem gerar mensagens. O exemplo a seguir est errado, portanto.

Em resumo, correto enviar mensagens a partir de atividades, mas no podemos gerar mensagens a partir de eventos intermedirios, estejam eles atachados borda de uma atividade ou no. Como receptores, entretanto, esta restrio no existe. Um evento de timer no pode ser um finalizador de processo, afinal isto estaria significando que o processo estaria terminando aps um certo tempo. Embora fosse bastante conveniente e til, um evento de modificao de dados tambm no pode ser um finalizador.

66

Da mesma forma, os eventos de tratamento de erro, como exception, error e compensao no podem ser utilizados como eventos de inicializao.

Por fim, os tratamentos de exceo so representados por setas de fluxo, e no de mensagens. Apenas lembrando que tratamentos de exceo so aqueles que saem das bordas de uma atividade, como no exemplo a seguir.

67

5-Fluxos, pools e lanes

Um fluxo deve se iniciar e continuar at o final do processamento. No podem haver interrupes em sua representao.

No caso anterior, no podemos transferir o controle para outro processo, e receber novamente o controle em outro ponto do fluxo, atravs de mensagens. Vale repetir que entre pools a comunicao feita entre mensagens. Dentro de um mesmo pool, a comunicao feita atravs de fluxos de processo, que devem se iniciar e conduzir a seqncia atravs 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 pontos de incio recebem o processamento, criando-se tantos tokens quantos forem os pontos de entrada.

68

6 - Fluxos, pools e lanes

Uma exceo do tipo compensao deve desviar para uma atividade do tipo compensao, e apenas uma. As seguintes representaes portanto no so vlidas.

No primeiro caso, o desvio acontece para uma atividade comum, e no uma compensao. Uma exceo do tipo compensao deve apontar para uma atividade do tipo compensao. No segundo caso, o desvio acontece para uma atividade que est ligada a outra compensao. Isto tambm no permitido, e todo o tratamento da compensao deve ser feito em somente uma atividade (ou sub-atividade) do tipo compensao.

69

7 - Levantamento dos processos de negcios

As tcnicas para levantamento de processos de negcios no so muito diferentes da modelagem tradicional de sistemas orientados para objetos. Normalmente a modelagem de processos aparece como uma etapa anterior ao desenvolvimento de um sistema, como forma de compreender os mecanismos do negcio em questo. Muitas vezes eles nem mesmo se desdobram em sistemas, servindo apenas como desenhos para otimizao dos processos da corporao. Na maior parte do tempo, o levantamento de processos feito atravs de entrevistas com usurios do sistema e normalmente geram artefatos que iro amadurecer para gerar documentos oficiais do sistema. O BPMN, neste caso, ser um dos artefatos gerados para representao das informaes. Perceba que a notao BPMN nem de longe completa e uma srie de outros diagramas e documentos so normalmente utilizados para entendimento do problema. Qualquer ferramenta de mercado, como Provision, MSVisio ou Enterprise Archictect, Intalio e outros fornecem uma srie de outros diagramas auxiliares para o desenho dos processos de negcios. Qualquer empresa fornecedora de uma ferramenta consultada ir apresentar sua frmula para desenho de processos, quase sempre focada nas caractersticas de sua prpria ferramenta. Por isto iremos expor ao invs de uma metodologia, prticas que podem ser utilizadas de forma a ajudar no levantamento. Vamos propor uma srie de idias, e voc pode manter em seu poder, como um canivete suo, utilizando-as durante um levantamento, quando julgar mais conveniente.

70

8 - Processos e Macro-processos
Os desenhos de processos iniciam em uma camada superior de desenho, e vo sendo evoludos (o correto seria detalhados) em nveis menores. O nvel mais alto que encontraremos so os macro-processos de uma empresa. O nvel mais baixo que encontraremos seria uma atividade, que no pode ser subdividida. Imaginando que tenhamos iniciado neste momento nossas atividades, e no temos sequer os macro-processos da empresa. Especialistas costumam salientar que os macroprocessos de uma empresa tendem a ser poucos, de um nmero que varia entre 7 a 15, mais ou menos. No sou adepto de nmeros mgicos, mas se uma empresa prope a existncia de 200 macro-processos, provvel que tenha ocorrido o que chamamos de decomposio funcional, ou seja, um macro processo foi detalhado em sub-processos. Uma tcnica que ajuda a descobrir os macro-processos de uma empresa a criao de um diagrama de posicionamento. Ele posiciona a empresa, os clientes e parceiros dentro de reas na tela, indicando o relacionamento entre cada uma destas reas. Desta forma, cada uma das setas encontradas dentro deste tipo de diagrama tende a se tornar um macroprocesso. Um exemplo deste tipo de diagrama pode ser observado a seguir :

71

Atravs deste tipo de diagrama, que pode ser feito em conjunto com os responsveis pela companhia consegue-se identificar pontos de conexo importantes que iro gerar os macro-processos. Ele pode ser desdobrado em outro que ao invs de mostrar os relacionamentos entre os blocos na empresa, apresenta como os departamentos esto hierarquizados.

72

Perceba que os dois tipos de diagramas anteriores so relacionados, e uma boa ferramenta de desenho garante que alteraes em um sejam refletidos no outro. No devemos nos esquecer de que os processos so feitos e utilizados por pessoas. sempre conveniente criarmos uma estrutura organizacional da empresa, que ir identificar os vrios departamentos e perfis associados. Podemos partir do diagrama anterior, focado na hierarquia departamental, e ir evoluindo at que os vrios perfis departamentais estejam visveis. H uma correlao direta entre estes perfis e com as pools e lanes que iro aparecer nos diagramas BPMN, quando j estivermos em uma fase mais adiantada.

73

9 - Os fluxos de processos
Quando estamos em uma sesso de entrevistas para levantamento de processos, muitas vezes no temos como forar uma disciplina de forma a coletar as atividades de forma organizada. Algumas vezes um entrevistado tambm efetua as mesmas atividades de forma diferente de outro no mesmo processo, e pode-se levar grande tempo discutindo o certo ou errado antes de avanarmos. O mais simples nestes casos, efetuar um brain storm levantando todas as atividades que devem ser efetuadas em um determinado processo. Ao invs de conduzirmos uma discuo em termos j estruturados, as reunies ficam mais leves se primeiro levantamos todas as atividades a serem executadas, e em um segundo momento as colocamos em um diagrama com a ordem de execuo. Desta forma aliviamos a presso imposta pela importncia de um levantamento de fluxo, e a tendncia a erros minimizada. importante que no exista a presso para que as informaes sejam fornecidas de forma organizada, mas sim manter o foco nas atividades componentes. Uma lista poderia ser algo como : Seleciona o produto Coleta dados do cliente Sugere produtos relacionados Efetua cobrana no carto Seleciona forma de retirada Preenche dados do cliente Assina protocolo de retirada

Criar listas deste tipo so mais efetivas ao usurio do que j desenhar efetivamente o fluxo. Desenhar as vrias atividades em papeis soltos e depois ir colando em uma folha em branco torna as reunies mais efetivas e menos montonas.

74

10 - As is e To be
Costumamos dividir os desenhos de fluxos em duas fases. Em primeiro lugar se desenha o fluxo do processo como ele , sem nenhuma alterao na forma com as atividades so processadas, por mais obvia que seja a alterao. Costumamos chamar esta fase de as is. Em um segundo momento, com o fluxo completamente desenhado, se atua em sua melhoria, tornando-o mais eficiente. Desta forma teremos o processo desenhado antes e depois das melhorias. Com estes dois desenhos em mos, podemos nos utilizar de ferramentas de simulao que iro indicar o ganho de qualidade obtido com o redesenho. Principalmente os especialistas focados em anlise e levantamento, quanto maior o conhecimento do negcio, mais rapidamente vislumbram pontos de processamento desnecessrios ou duplicados. Isto se deve vivncia no ramo. muito importante durante o levantamento de processos que foquemos em como o processo est atualmente ( as is), deixando o to be para um momento posterior. Muitas vezes o usurio do fluxo percebe o erro que est cometendo no momento deste desenho, e j tenta guiar o desenho de forma a contemplar esta melhora. importante que isto no acontea, seno qualquer informao relativa melhoria ir se perder e anlises futuras nunca conseguiro ter sucesso no diagnstico. Isso importante pois ir gerar relatrios de melhorias de processo, indicando a economia ou aumento de lucro obtido. O objetivo deste redesenho a melhoria, e o usurio no deve se sentir culpado por no ter percebido isto antes, pois afinal ele estava to focado na execuo de seu fluxo dirio que dificilmente teria como abstrair e imaginar melhores formas de realizar a tarefa.

75

11- Use Cases e processos

Principalmente no momento em que a rea de negcios se encontra com a TI, para a tranferncia de informaes que ir permitir a implementao de um sistema baseado no fluxos de processos, surge uma dvida muito pouco discutida que : Como uma atividade BPMN est relacionada com elementos de anlise tradicional, como um Use Case, por exemplo ? Neste caso, estamos nos referenciando aos Use Cases da modelagem orientada para objetos. Na orientao para objetos nosso foco primrio manter dentro dos limites de um sistema, normalmente departamental. Quaisquer interfaces externas costumam ser ignoradas, e colocadas como caixinhas a serem implementadas no futuro. Com um exemplo prtico, quando iniciamos a modelagem do sistema de vendas, raramente nos preocupamos com o sistema de estoque. Isto o oposto do que normalmente acontece quando uma empresa se organiza em termos de processos. Para uma modelagem em torno de processos, pouco importa a qual departamento uma atividade est relacionada. O que importa a continuidade do fluxo, passando por vrios departamentos da empresa at seu trmino. Um fluxo de processos pode se iniciar como um processo de vendas na loja e passar pelo controle de estoque em algum momento, efetivando o pdedido e a reserva do produto. Por isto se costuma dizer que os sistemas atuais so verticalizados (ou seja, giram em torno de um departamento), enquanto que os processos permeiam a empresa na horizontal (ultrapassam vrios departamentos). Frequentemente se verifica este tipo de desenho :

76

Os mesmos blocos de mais alto nvel dos que compe os sistemas orientados para objetos, chamados de use cases, podem ser as atividades de mais alto nvel que compe os processos. Quando se decompe uma atividade, ela se torna um sub-processo que na modelagem por processos ir se tornar um diagrama BPMN. Na orientao para objetos, um use case quando decomposto pode se tornar um diagrama de atividades, que muito similar ao diagrama BPMN. Veja dois exemplos na introduo deste livro. Em resumo, um use case uma atividade de mais alto nvel. Podemos utilizar as atividades de um fluxo de processos como insumo para detalhamento dos use cases, gerando os artefatos necessrios para a UML tradicional, como diagramas de classes e de sequncias. E se um Use Case essencialmente uma Atividade de mais alto nvel, podemos utilizar os templates de detalhamento de use cases que j utilizvamos na UML para descrever como cada atividade se comporta. Embora um diagrama BPMN seja muito mais detalhado do que um diagrama de atividades, ainda no chegamos a um ponto onde possamos omitir o detalhamento da atividade. Utilizando um template para definio de Use Case j na modelagem de processos de negcios utilizamos um mesmo artefato padronizado at os nveis mais baixos, facilitando no momento posterior da implementao do sistema.

77

12 - Concluses
Os objetivos primrios da modelagem de processos de negcios obter entendimentos de como a empresa funciona internamente. Os artefatos discutidos, como organogramas, diagramas de posicionamento, fluxos de processos so formas visuais de compreender o que as pessoas fazem no dia a dia de suas atividades, e servem como ponto de partida para outros estudos, como melhorias nos processos e estimativa de custos por atividades, entre outros. Durante este entendimento importante formentar discusso, levantando a poeira do tapete, pois somente desta forma poderemos de forma correta compreender os processos corporativos. errado efetuarmos este levantamento apenas com o gerente da rea, por exemplo, mas se for necessrio, por falta de tempo dos outros envolvidos, devemos ao menos garantir que todos esto coniventes com esta viso. Muitas vezes os funcionrios fazem suas atividades de forma diferente do que a gerncia imagina, e vice versa. A modelagem de processos de negcios importante pois nos faz compreender a empresa e os mecanismos que foram utilizados para que funcione. fundamental no apenas como etapa pr desenvolvimento de um sistema, como tambm para adequao de uma soluo de mercado, como um ERP, CRM, etc.

78

13 - BPEL e BPMN
Se hoje em dia temos um consenso em termos de notao para desenhos de processos, que o BPMN, o mais prximo que temos atualmente de uma notao padronizada para execuo deste processo o BPEL (ou BPEL4WS). A sigla o anagrama de Business Process Execution Language, e foi criada como uma forma de permitir a orquestrao de servios Web (Web Services). Como uma linguagem para execuo de servios, ela formal e no permite ambigidades. Uma das idias no mercado que BPEL seja utilizada na execuo de fluxos de atividades. Nem todos os fabricantes a adotam em sua plenitude, e alguns incorporaram modificaes para torn-la compatvel com os recursos de seus produtos. Mas sua fora inegvel, j que at mesmo a especificao BPMN na release 1.0 apresentava como fazer mapeamentos para o BPML, outro padro tambm mantido pela mesma organizao, e j na verso final do documento o captulo foi substitudo pelo mapeamento em BPEL. Em essncia, o BPEL um arquivo XML. Dentro dele vrios trechos XML vo indicando o que fazer durante o processamento de um fluxo, definindo e armazenando variveis. O BPEL por si s no capaz de executar muita coisa, delegando a responsabilidade para web services. Se estivssemos comparando o BPEL com um programa tradicional, poderamos dizer que cada subrotina no programa seria um servio, e o programa principal, que chama em seqncia cada rotina seria o BPEL. A desvantagem de utilizar BPEL obvia, j que interpretar um arquivo XML mais lento do que executar um programa. Mas porque o mercado fala tanto sobre ele ?

79

Para uma soluo BPMS, o BPEL traz vantagens. muito comum ouvirmos sobre realinhamento dos processos de negcios, que significa reajustar um processo ou otimiza-lo para melhor execuo. Na maioria das situaes, este reajuste feito apenas na ordem em que os servios so chamados. Se a execuo deste fluxo est em um cdigo, quando necessrio reajuste temos que alterar o cdigo que executa o fluxo. Se utilizamos um arquivo XML (BPEL), as alteraes na ordem de execuo so mais simples, j que no precisamos recompilar cdigos, e ainda podemos manter duas verses no sistema, uma antiga, com os fluxos com a execuo j iniciada, e um novo, com a nova forma de execuo para os novos processos iniciados. Desta forma, testes com o sistema em execuo podem ser feitos com prejuzo mnimo aos usurios, pois os que haviam iniciado no fluxo antigo continuam at o final do processamento. Isto reduz o impacto nas alteraes, pois no afeta o que j est em execuo. Se utilizssemos cdigos para fazer o mesmo processamento, seria muito complicado mantermos duas verses do cdigo em execuo na mquina. Delegando para o XML, o prprio engine BPEL pode fazer a distino entre novo e velho. Para permitir a execuo e at mesmo passagem de parmetros entre as chamadas, o BPEL possui um conjunto de elementos para lidar com situaes comuns de programao, como declarao de variveis, atribuio e cpia de valores e chamadas a servios.
<invoke> <receive> <assign> <reply> <throw> <wait> Efetua uma chamada a um servio Fica no aguardo de um servio chamado atribui uma varivel Responde com uma chamada tratamento de excees Fica no aguardo

80

Mas tambm temos elementos que controlam o fluxo, como ifs, elses e outros tipos de elementos comuns a linguagens de programao tradicional.
<sequence> <switch> <pick> <flow> <while> <scope> uma varivel Executa em sequncia Escolhe um caminho para execuo Fica no aguardo de um evento Executa processamentos em paralelo Executa um loop Define um escopo para atribuio ou leitura de

Um arquivo BPEL normalmente tem uma estrutura do tipo :

<flow> <links> <link name=XtoY/> <link name=CtoD/> </links> <sequence name=X> <source linkName=XtoY/> <invoke name=A .../> <invoke name=B .../> </sequence> <sequence nameY> <target linkName=XtoY/> <receive name=C/> <source linkName=CtoD/> </receive> <invoke name=E .../> </sequence> <invoke partnerLink=D> <target linkName=CtoD/> </invoke> </flow>

81

14 - O Mapeamento BPMN para o BPEL

necessria uma certa criatividade para mapear elementos do BPMN para o BPEL. Podemos apresentar um trecho de cdigo e indicar os impactos no mapeamento :

Este trecho poderia ser mapeado como :

<variable name=contador messageType=loopCounterMes sage /> <variable name=limite messageType=forEachCounterMes sage /> <sequence> <assign name=init_contador> <copy> <from expression=0/> <to variable=contador part=loopCounter /> </copy> </assign> <assign name=init_limite> <copy> <from expression=10/> <to variable=limite part=forEachCount /> </copy> </assign> <while condition= bpws:getVariableData(contador,loopC ounter) <= bpws:getVariableData(limite,forEachCount)> <sequence> <invoke name=atividade1 ... > <assign name=incremento>

82

<copy> <from expression=bpws:getVariableData(contador,l oopCount)+1/> <to variable=contador part=loopCounter /> </copy> </assign> <invoke name=atividade2 ... > </sequence> </while> </sequence>

Em primeiro lugar, vale salientar que foi criada uma atividade chamada incremento, com o objetivo de manter o valor durante a execuo do processo. Os dois invokes, que faro as chamadas aos servios esto envolvendo um assign, que faz o incremento. Tudo isto est dentro de um while, que garante a execuo em looping. Foi inserida dentro do BPEL uma linguagem de expresso, o que permite a comparao de valores, como em bpws: getVariableData(contador,loopCounter). Bem parece que temos tudo o que precisamos, certo ? Bem, nem tanto assim. Primeiro a atividade incremento, quando foi mapeada por um analista de processos provavelmente no foi colocada. Ela apareceu no momento do mapeamento para BPEL, permitindo a gerao da rotina de incremento. Isto faz com que um fluxo desenhado pelo analista raramente consiga ser mapeado diretamente para o BPEL, sendo necessrios reajustes, neste caso exemplificado com a insero de uma atividade para permitir a contagem. Outra particularidade oculta, mas a ser considerada que o BPEL no tm o conceito de pools e lanes. Portanto no h perfis e se assume que um fluxo ser executado para um perfil especfico. Isto pode ser um problema para um desenho mais complexo, e talvez cada lane tenha que ser mapeada

83

Como os fabricantes esto lidando com estas deficincias ? Como dissemos anteriormente, muitos esto acrescentando elementos ao padro, de forma a contornar estas inconvenincias. Isto deve gerar nossa preocupao, pois podem surgir BPELs e BPELs, cada um com suas particularidades. Como as empresas lidam com isto em termos de equipe ? Atualmente a abordagem comum que os analistas que fazem o levantamento dos processos no se preocupam muito com a notao (alguns nem mesmo utilizam o BPMN). No momento em que o fluxo for implementado em uma soluo BPMS, ser redesenhado para a ferramenta adotada, seja BPEL ou outra qualquer. Isto no bom, pois pode causar distores na transcrio, alm de dificultar o processo de implantao e praticamente inviabilizar o realinhamento rpido do negcio. Tambm vale salientar que o invoke no BPEL faz uma chamada um Web Service. Mas e se tivermos interaes com os usurios ? Talvez a mais notada proposta no mercado seja o BPEL4PEOPLE, proposta pela IBM e SAP, como alterao no BPEL de forma a permitir interaes entre pessoas. O documento pblico, e alguns fabricantes esto suportando o padro. necessrio deixar claro que nem todos os engines BPEL suportam BPEL4PEOPLE, o que faz com que um processo modelado em BPEL nem sempre possa ser executado em qualquer engine. Acho que vale salientar que os elementos do BPEL4PEOPLE so muito diferentes dos elementos BPEL tradicional, e ajustes profundos nos engines de execuo so necessrios

84

15 - Editor BPMN da revista PortalBPM

Voc pode localizar este editor BPMN no site da revista PortalBPM (www.portalbpm.com.br), na seo de downloads. Para que mais uma ferramenta de desenho ? Bem, esta ferramenta distribuida gratuitamente e contm todos os smbolos da notao BPMN, o que nem todas as ferramentas tm, gratuita para utilizao, e mais simples que a mdia das ferramentas. A ferramenta necessita de uma instalao Java para operar normalmente. Ela foi testada e homologada na verso de Java 5. Pode-se baixar um JRE, que menor requer menor esforo na instalao atravs do link http://java.sun.com/javase/ downloads/index_jdk5.jsp. Ela no foi testada com verses posteriores de Java, e no ir funcionar com verses anteriores. Uma vez baixado o executvel, pode-se instalar como qualquer aplicativo Windows normal. Uma instalao tpica pode ser selecionada, e ser apresentada uma tela como :

85

Aps a instalao, voc ter uma mquina virtual Java que ser utilizada pelo programa. A segunda etapa baixar o programa de edio BPMN. Ele fornecido como um ZIP, que pode ser aberto para qualquer diretrio do computador. Deve-se criar um diretrio na mquina, por exemplo c:\EditorBPMN. Copia-se o arquivo ZIP para dentro desta pasta, e se extrai o contedo para dentro deste diretrio. Aps este processo, o diretrio deve parecer como :

O arquivo editorbpmn.zip pode ser removido sem problemas agora. A instalao est completa. O executvel EditorBPMN.exe ir iniciar o programa. Ele pode ser arrastado para o desktop para que seja criado um atalho, facilitando execues futuras. Quando se executa o programa, ser solicitado um diretrio de trabalho, onde todos os arquivos criados sero armazenados :

86

Aps definido um espao de trabalho, o programa entra em sua tela principal. A ferramenta foi construda com base no eclipse, e formada por vrias telas que interagem com a aplicao.

Para que tenhamos um ambiente customizado para utilizao, podemos chavear para a perspectiva de edio BPMN. Isto pode ser feito selecionando os menus Window->Open perspective->Other, e seleciona-se Perspectiva edio BPMN, como a seguir :

87

Aps este chaveamento, a aparncia ficar como :

A ferramenta est pronta para uso. Nas entradas seguintes, a perspectiva no precisar mais ser chaveada. Se por alguma razo alguma janela for fechada ou a perspectiva perdida, pode-se novamente abrir a perspectiva com o procedimento acima. Todos os desenhos BPMN ficam dentro de um projeto. Precisamos criar ao menos um projeto, mas por outro lado podemos ter vrios projetos em um workspace. A ferramenta pode tambm ter vrios workspaces, bastando na entrada se selecionar diretrios diferentes para cada execuo. A criao de um projeto feita clicando-se com o boto da direita na janela Navigator, que est no canto superior direito da tela :

88

Ser solicitado um nome para o projeto, e aps criado ir apresentar uma aba em navegador, semelhante a uma estrutura de diretrios do Windows Explorer.

Dentro deste projeto podem ser criados vrios desenhos BPMN. Selecionando-se o projeto com o boto direito do mouse ser apresentado :

89

Ser apresentado um nome padro, com a extenso BPMN, que pode ser alterado a vontade. A extenso do arquivo dever ser sempre BPMN, e no podem existir dois arquivos com um mesmo nome dentro de um projeto. Aps criado o arquivo ele ser aberto na rea de edio, que fica na lateral direita da janela. Neste momento, se inicia o processo de edio propriamente dito.

O processo de edio consiste em selecionar um elemento visual na paleta de componentes, atravs de um clique. Depois pode-se mover o mouse at a rea do editor, e clica-se novamente para que o elemento seja depositado na rea de edio. O editor de propriedades indica algum atributo de cada um dos elementos que pode ser editado. Uma vez editado, a rea visual alterada imediatamente. A janela outline permite que vejamos os elementos na tela, mesmo que estejam fora da rea visual. Quando selecionamos um elemento em outline, ele ficar selecionado na rea de edio e suas propriedades sero apresentadas.

90

Vamos editar um exemplo simples de BPMN. A partir do editor aberto, selecionamos uma lane, que est na palete em outros. Quando se clica em um sub-elemento da palete, ele aberto e fechado a cada interao. Leva-se a lane para a rea de edio, e coloca-se na tela a tela ficar como :

Pode-se selecionar o valor de perfil e colocar um valor significativo para a Lane, como Atentende. Imediatamente o desenho na edio superior reflete este valor, bem como a janela de Outline. O prximo passo fazer o mesmo com os eventos de incio e final, que devem ser arrastados sobre a Lane. Deve-se fazer o mesmo com uma atividade simples, que ter seu atributo texto alterado para Atende cliente. Aps estes passos, a tela dever estar como :

91

A paleta pode ser aberta ou fechada, bastando-se clicar nela, ou posicinando-se o mouse por algum tempo sobre ela. Ela tambm se fecha automaticamente quando no est sendo utilizada. Elementos BPMN podem ser arrastados para uma Lane, neste caso fazendo parte dela, ou seja, quando a Lane arrastada todos os elementos internos so arrastados em conjunto. Pode-se tambm arrastar os elementos para uma rea fora de uma lane, neste caso no pertencendo a nenhuma lane especfica, funcionando como um processo privado, como explicado na primeira edio da revista PortalBPM. Na parte superior da janela pode ser encontrado um selecionador de ZOOM, permitindo aumentar ou diminuir a imagem, facilitando a tarefa de visualizao de elementos na tela. A ferramenta permite exportar em formato imagem. Selecionando-se o mouse com o boto direito sobre o editor, em uma rea no populada (branca), ser apresentada uma opo exporta diagrama como imagem. Pode-se apontar o nome do arquivo e ser gerada uma imagem em JPG, que pode ser anexada a outros documentos textuais, como de requisitos. Arquivos BPMN podem ser exportados da ferramenta, ou importados para ela. Clicando-se com o boto da direita sobre um arquivo ou projeto, sero apresentados menus para exportao e importao. Isto permite compartilhar desenhos BPMN entre usurios. Perceba que a cada alterao no diagrama, um asterisco aparece na lateral do nome do arquivo. Isto indica que o mesmo 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

16 - Outras ferramentas de mercado

Temos vrias alternativas de mercado para desenho BPMN. Elas se dividem em ferramentas de desenho BPMN com BPMS integrado, e solues puras de desenho. Ferramentas de desenho com suporte ao BPMN Toguether Borland BEA Aqualogic Intalio System Architect MetaStorm Provisio Visual Paradigm WBI Modeler Visio Aris

Atualmente temos cadastradas 44 ferramentas com suporte ao BPMN, e o nmero cresce a cada dia. No podemos deixar de citar o movimento Eclipse, que est construindo uma ferramenta de desenho BPMN sobre o GMF e GEF.

93

17 - BPMN design patterns

Da mesma forma que na orientao para objetos, os fluxos de processos desenhados em BPMN demandam padres de desenvolvimento (design patterns). Um design pattern, segundo a definio, um trecho que aparece repetidas vezes durante os ciclos de desenvolvimento. Para facilitar a compreenso e garantir uma mesma linguagem durante as reunies de levantamento, importante utilizarmos os mesmos termos, evitando desta forma ambigidades.

Seqncia de fluxo (Sequence)

Este tipo de design pattern indica uma seqncia de fluxo. O mais bvio a seqncia, onde atividades so executadas em uma ordem, uma aps a outra. A representao deste tipo de fluxo algo como a seguir :

Neste caso, deve estar implcito que existe um token que vai sendo propagado conforme as atividades vo sendo executadas, sejam elas por um mesmo perfil ou por vrios perfis (lanes) dentro da execuo.

94

Processamento paralelo (Parallel Split)

Quando seguimos por mais de um caminho ao longo da execuo do fluxo, ou se temos atividades com tokens distintos (notao BPMN), chamamos de processamento paralelo (parallel split). Isto indica que os dois caminhos so processados de forma independente. Em BPMN, temos mais de uma forma de representao para processamentos paralelos. No exemplo a seguir, em todos os casos as atividades A e B iro gerar tokens distintos.

No exemplo esquerda, temos um fluxo paralelo no controlado. Quando duas setas saem de uma atividade, isto indica processamento paralelo. No exemplo da direita, colocamos explicitamente o gateway de AND.

95

Sincronizao (Synchronization)
Utilizamos uma sincronizao quando desejamos aguardar pela chegada de mais de um token gerado durante o processamento. Ele a contrapartida do processamento paralelo. Suas representaes podem ser :

A notao BPMN chama este tipo de padro de Merge. Quando colocamos uma sincronizao desejamos aguardar por um conjunto de processamentos antes de continuarmos. Escolha exclusiva (Exclusive Choice) e Unio simples (Simple merge) Quando temos uma nica escolha para um dos caminhos de um fluxo, atravs de um gateway XOR, definimos este padro como Exclusive Choice. Sua contrapartida o simple merge, que ir aguardar pela chegada do nico token, e assim continuar o processamento. Este tipo de pattern indica que apenas um token foi gerado durante o processo.

96

Mltipla escolha (Multiple choice) e Mltipla juno (Multiple merge) Quando temos um mais caminhos sendo processados em um fluxo, indicamos atravs do pattern Multiple choice e Multiple merge.

97

Sobre junes e bifurcaes

Os mecanismos de juno e bifurcao so completamente distintos, e no necessitam ser utilizados aos pares. Vamos compreender estes mecanismos atravs de alguns exemplos. Quando o diagrama contm um gateway para bifurcao ou juno, dizemos que este ambiente controlado. Quando existe mais de um fluxo saindo ou chegando a uma atividade, dizemos que este ambiente no controlado. Se mais de uma seta de fluxo sai de uma atividade, todos os caminhos so seguidos, como se fosse um AND.

No exemplo anterior as duas representaes so idnticas em termos de processamento. Dois tokens foram criados, seguindo para as atividades B e C. J em termos de juno, um ambiente descontrolado gera resultados distintos, em termos de processamento.

Neste exemplo, tanto a implementao 1 como a 2 iro passar por A, gerar dois tokens que seguiro por B e C.A diferena que no primeiro exemplo, cada um dos tokens que chegarem a D iro forar a excuo desta atividade. Portanto, no exemplo 1 D SER EXECUTADO DUAS VEZES. J no exemplo 2, como foi colocado o gateway para controle do ambiente, D ser executado apenas uma vez, pois o gateway de juno ir aguardar a chegada dos dois tokens.

98

Mas desejamos s vezes que qualquer um dos tokens que chegue at a juno faa com que o fluxo continue. Este pattern comumente chamado de Discriminao (discriminator).

Neste caso, embora dois tokens tenham sido gerados, como a juno um XOR, o primeiro dos tokens que chegar ao gateway far com que o fluxo continue. O outro token, quando chegar ao gateway ser descartado em termos de processamento. Desta forma, perfeitamente possvel que a seqncia executada para o exemplo anterior seja A, B, D e C, isto mesmo, com a atividade D terminando antes mesmo da C.

Juno N de M (N out of M join)

Mas, se a sincronizao aguarda por todos os tokens, e a discriminao pelo primeiro que chegar, como podemos desenhar um fluxo de forma que alguns cheguem at o gateway para continuar ? Seria o meio termo entre a sincronizao e discriminao.

99

Neste caso, desejamos que o fluxo continue quando as atividades B e C terminarem, e para isto utilizamos o gateway complex como juno. Na bifurcao ele funciona como forma de gerarmos vrias sadas, e na juno como forma de escolha para quais elementos devem ser recebidos para que o fluxo continue.

Ciclo arbitrrio (Arbitrary cicle)

Quando desejamos executar um fluxo um certo nmero de vezes, mas no temos como precisar quantas vezes ele ser executado, utilizamos um ciclo arbitrrio. Ele funciona como uma atividade em paralelo, mas sem que definamos quantas vezes ele ser executado.

importante termos conscincia destes patterns, mas acima de tudo conhecer os mecanismos de execuo, para que no desenhemos um fluxo que no momento da execuo funcione de uma forma diferente da esperada, apenas porque selecionamos um gateway de forma errnea.

100