Você está na página 1de 6

www.portalbpm.com.

br

Curso de BPMN - II

Glauco Reis (gsrt@terra.com.br) Consultor em Java e metodologias OO, e especializado em plataforma IBM. Tm o ttulo de SCJP 1.1 e 1.4, SCJWCD 1.4, e IBM CSE e IBM Websphere Application Server Certified. Escreve h mais de 8 anos sobre o tema Java e trabalha na rea de informtica h mais de 21 anos, participando tambm como palestrante COMDEX e FENASOFT. especialista em WebServices e est envolvido com a tecnologia BPMS, como arquiteto principal na criao de uma soluo BPMS nacional.

No mdulo anterior, exploramos os tipos de diagramas existentes na notao BPMN. Foram comentados os tipos de BPD (Business Process Diagram) existentes. Vamos explorar neste mdulo o que encontramos normalmente dentro de um BPD, bem como os elementos bsicos desta notao.

Desenho de processo
Todo desenho de processo (que iremos chamar de fluxo a partir deste momento) tm um incio e um final. A simbologia contm uma representao para incio e trmino de fluxo, que basicamente so crculos. O incio contm um circulo com linha mais fina, e o final do fluxo com linha mais grossa. No somos obrigados a representar graficamente o incio e trmino do fluxo, mas caso exista um incio, obrigatria a representao do final. Caso um fluxo no tenha incio, todas as atividades que no contiverem uma seta chegando at ela sero consideradas pontos de incio. O mesmo valido para o trmino. Atividades sem setas de sada sero consideradas atividades finais. No existe limitao para o nmero de incios, nem para o nmero de trminos.

Incio e trmino de processo Embora no seja obrigatrio, muito recomendvel que todo processo tenha um incio e um final explcitos, pois isto torna mais clara a leitura do fluxo. Veja o exemplo de fluxo a seguir, vlido sob o ponto de vista de notao, mas pouco visvel onde se inicia ou termina :

Incio e trmino de fluxo sem o evento indicativo Cada quadrado com as bordas arredondadas representa uma atividade que acontece dentro de

www.portalbpm.com.br

um fluxo. Cada seta unindo duas atividades representa uma sequncia que ser executada. Os dois elementos (fluxo e atividade) sero explorados mais adiante. O que importa neste momento que este tipo de notao tende a tornar os diagramas menores (pois omite o incio e final), mas dificulta por vezes a compreenso. Neste caso, quando uma instncia iniciada, tanto incio1 quanto incio2 so executados. Uma dvida que surge neste ponto, principalmente observando o exemplo anterior, o significado de executar incio1 e incio2 ao iniciar a instncia de processo. As duas atividades sero executadas em paralelo, como threads ? Para compreendermos isto, precisamos saber o que significa um Token, que o que veremos a seguir.

Token
Existe um conceito que permeia toda a documentao BPMN, que o conceito de TOKEN. Em uma linguagem de programao como o Java, um token seria algo anlogo uma thread. algo criado em algum ponto do processo, e sua execuo fica ativa durante algum tempo, at desaparecer ou se unir com outras unidades funcionais, que esto sendo executadas de forma independente umas das outras. No caso do BPMN, eles so propagados pelas atividades seguintes no fluxo, at que algo o faa desaparecer ou se juntar aos outros tokens. No diagrama acima, por exemplo, quando uma instncia de processo criada, dois tokens so criados. Tanto incio1 quanto incio2 so executados ao mesmo tempo. Mas ao contrrio de uma thread, onde tudo executado em paralelo mesmo, a notao BPMN no obriga a criao de mecanismos multithread. Pode ser executada incio1 primeiro e incio2 depois, ou vice versa. Ou os dois podem ser executados em paralelo, em uma ferramenta workflow que suporte multithread legtimo. O que importa que, neste caso, a atividade intermedirio atua como uma juno de tokens, e intermedirio somente executado quando inicio1 e inicio2 tiverem terminado. Se uma das atividades terminar antes, o token chega at intermedirio e fica aguardando at que o outro token chegue at l, para que o processo prossiga em sua execuo. importante distinguir instncias de processos de tokens. Uma instncia pode ter diversos tokens, mas um token pertence a apenas uma instncia de processo. muito importante a compreenso dos tokens, pois dependendo de como os fluxos forem desenhados haver variao na forma como eles so criados e destruidos, e utilizaremos neste curso os mesmos termos adotados pela documentao oficial. Uma preocupao ao adotar o termo token foi permitir atividades executando em paralelo, sem forar o engine de execuo a adotar prticas de multithread. Para termos a certeza de que compreendemos o conceito, vamos analisar o seguinte exemplo :

Exemplo de tokens Neste caso, dependendo da soluo de workflow, poderemos ter as seguintes possibilidades de execuo: 1) Uma thread iniciada, e a atividade a1 executada, e aps esta a atividade a2. Ao mesmo tempo outra thread iniciada, e a atividade a3 executada e aps a atividade a4.

www.portalbpm.com.br

A atividade a5 espera o trmino das duas threads para iniciar sua execuo. O programa segue executando atravs de a5, com uma nica thread. 2) A atividade a1 executada, e depois a atividade a2. Ou seja, o caminho de cima executado inteiro, depois o caminho de baixo (a3 e a4). Aps a execuo dos dois, o caminho a5 continua a execuo. 3) Outra possibilidade seria a execuo da atividade a1, depois a execuo da a3, a2 e depois a4, continuando na sequncia a execuo de a5. Verificando os exemplos acima, percebemos que pouco importa para o desenhista de processos como a ferramenta de workflow executa o processo. O que importa que as atividades da bifurcao so executadas antes e que a juno a5 sincroniza as duas execues. Desta forma, a notao permite a representao de execues simultneas, mesmo que a ferramenta no suporte o conceito.

Atividade
O conceito de atividade simples, mas por outro lado abrangente. Uma atividade um passo na execuo de um fluxo. Ele representado por um retngulo com as extremidades arredondadas. Uma atividade pode ser manual ou automtica. Uma aprovao de crdito pode ser uma atividade. Um processo inteiro de cobrana pode ser uma atividade. Atividade, portanto, um termo genrico para algo executado dentro de um processo. O desenho do fluxo j uma atividade. No nvel mais baixo, onde ele no pode mais ser subdividido em unidades menores, chamado de uma tarefa (task), que um termo especializado para uma atividade que no tm mais subnveis. Quando uma atividade pode ser aberta em atividades mais especializadas, ela chamada de subprocesso.

Exemplos de tarefas e subprocessos Uma diferena visual entre a tarefa (task) e o subprocesso o sinal de +, que normalmente fica localizado no centro do lado inferior do subprocesso. Quando o sinal de mais (+) visvel, o fluxo que se encontra dentro no apresentado. Quando o + clicado, a atividade expandida para mostrar o desenho em miniatura do fluxo em seu interior. No um comportamento obrigatrio, mas facilita a visualizao de cada nvel inferior. Algumas ferramentas optam por abrir uma outra janela com o desenho do fluxo, quando o + clicado.

Conexo entre elementos


O BPMN determina basicamente dois tipos de conexo : As que acontecem dentro de um processo, indicando a passagem de uma atividade para outra, e as conexes que acontecem entre dois processos, que so feitas pela passagem de mensagens. A conexo entre duas atividades de um mesmo processo representada por uma seta com linha

www.portalbpm.com.br

contnua. Algo como :

Sequncia de fluxo Quando precisamos fazer com que dois fluxos distintos se comuniquem, a nica forma atravs do envio de mensagens. Mensagens fazem com que os fluxos tenham um baixo acoplamento, reduzindo dependncias fsicas. A documentao BPMN no especifica o mecanismo utilizado para mensagens. Pode ser SMTP, JMS ou qualquer outro middleware de mensagens. A sugesto que envios de mensagens aconteam atravs de acessos SOAP.

Pool
Para delinearmos os limites de um fluxo ns utilizamos um pool. A especificao no obriga a representao da pool, mas se um fluxo se iniciar em uma pool, ele deve estar completamente contido dentro dela.

Pool No desenho acima, no correto ter o evento de incio dentro da pool, e o evento de trmino fora dela. O que permitido a comunicao de dois pools (lembrando que representam fluxos) atravs de mensagens.

Mensagens entre fluxos

www.portalbpm.com.br

No exemplo anterior, temos dois tipos de mensagens. Uma enviada de uma atividade especfica para uma atividade em outra pool, e uma conectando as duas pools. Cada mensagem diferenciada atravs de uma linha pontilhada, unindo dois elementos. Quando a mensagem enviada, o fluxo continua normalmente (atravs da linha contnua). Ela funciona como um aviso ao outro fluxo, algo que ser utilizado do outro lado como uma forma de tomar deciso. Veremos mais adiante que podemos controlar o fluxo, fazendo com que uma atividade aguarde pela chegada de uma mensagem. Elas podem ser utilizadas como sincronismo entre fluxos. Embora de utilidade discutvel, pode-se enviar mensagens dentro de uma mesma pool. Cada Pool pode ser dividida em unidades menores, chamadas de Lane.

Uma Lane pode representar cada papel dentro de um processo. Por exemplo, vendedores, gerentes, diretores podem ser papis para execuo de cada atividade. A documentao no coloca amarras em Lanes, significando meramente subdivises. Podem ser departamentos, cargos ou mesmo unidades da empresa em pases diferentes. Nos diagramas de mais baixo nvel (aqueles que iro gerar cdigos) o mais razovel utilizar as Lanes para diferenciar os papeis (cargos), durante a execuo.

Lane

exemplo de Lane Embora bem simplificado, podemos observar algumas coisas interessantes no diagrama acima. Por exemplo, a Pool representa um processo de venda ao cliente. Cada Lane representa um papel que ser executado ao longo do processo. Representar os papeis em lanes, ao invs de coloc-los nas prprias atividades torna o desenho mais claro. Quando outro papel assume o controle do processamento, a seta cruza uma lane para chegar at o perfil que ir executar aquela atividade. Algumas ferramentas permitem lanes na horizontal, como o exemplo acima, ou na vertical. A especificao no obriga este tipo de formatao.

No exemplo acima, aparecem dois losangos. Um logo aps a entrada da forma de pagamento. Se a forma de pagamento e valores estiverem dentro de algo que possa ser aprovado pelo prprio vendedor, este entra os dados para entrega do produto. Se por outro lado, o vendedor no puder aprovar, ele repassa o caso ao gerente, que avalia se a venda pode ser aprovada ou no. Um gateway, portanto, algo que permite tomada de deciso. Esta deciso pode ser manual, como este exemplo, ou programtica, sobre um determinado valor ou clculo. Neste caso, o gateway est funcionando de forma exclusiva sobre um dos caminhos. Se o vendedor tiver autonomia, o gerente nem mesmo acionado durante a execuo do processo. Ou se vai para um caminho, ou para o outro. Nunca os dois (neste caso). Naturalmente o set completo do BPMN tm gateways

Gateway

www.portalbpm.com.br

que vo muito alm de uma comparao simples como esta. Neste momento, podemos explorar um pouco mais o conceito do token. Neste desenho de processo, o token caminha para um dos lados do gateway, mas nunca para os dois. Na verdade, h um pequeno erro neste desenho, mas como nosso objetivo era simplificar o fluxo, apresentaremos o erro em um outro artigo. Com isto, exploramos o set simplificado do BPMN. Voc pode estar decepcionado, e at mesmo dizer que at agora nada foi acrescentado de diferencial, se comparado a um diagrama de atividades da UML. A partir dos prximos artigos estaremos explorando os elementos do set completo, e a sim veremos o poder e diferencial do BPMN. Vocs iro perceber que existe todo um set de simbolos, para representar as situaes mais comuns de desenhos de processos, alguns at mesmo relacionados aos mecanismos de programao. At a prxima e fique sintonizado no PortalBPM !!

Você também pode gostar