Curso de BPMN - II Glauco Reis (gsrt@terra.com.br) é Consultor em Java e metodologias OO, e especializado em plataforma IBM. Têm o título 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 informática há mais de 21 anos, participando também como palestrante COMDEX e FENASOFT. É especialista em WebServices e está envolvido com a tecnologia BPMS, como arquiteto principal na criação de uma solução BPMS nacional. No módulo anterior, exploramos os tipos de diagramas existentes na notação BPMN. Foram comentados os tipos de BPD (Business Process Diagram) existentes. Vamos explorar neste módulo o que encontramos normalmente dentro de um BPD, bem como os elementos básicos desta notação. Desenho de processo Todo desenho de processo (que iremos chamar de fluxo a partir deste momento) têm um início e um final. A simbologia contém uma representação para início e término de fluxo, que basicamente são círculos. O início contém um circulo com linha mais fina, e o final do fluxo com linha mais grossa. Não somos obrigados a representar graficamente o início e término do fluxo, mas caso exista um início, é obrigatória a representação do final. Caso um fluxo não tenha início, todas as atividades que não contiverem uma seta chegando até ela serão consideradas pontos de início. O mesmo é valido para o término. Atividades sem setas de saída serão consideradas atividades finais. Não existe limitação para o número de inícios, nem para o número de términos. Início e término de processo Embora não seja obrigatório, é muito recomendável que todo processo tenha um início e um final explícitos, pois isto torna mais clara a leitura do fluxo. Veja o exemplo de fluxo a seguir, válido sob o ponto de vista de notação, mas pouco visível onde se inicia ou termina : Início e término de fluxo sem o evento indicativo Cada quadrado com as bordas arredondadas representa uma atividade que acontece dentro de
um fluxo. Cada seta unindo duas atividades representa uma sequência que será executada. Os dois elementos (fluxo e atividade) serão explorados mais adiante. O que importa neste momento é que este tipo de notação tende a tornar os diagramas menores (pois omite o início e final), mas dificulta por vezes a compreensão. Neste caso, quando uma instância é iniciada, tanto início1 quanto início2 são executados. Uma dúvida que surge neste ponto, principalmente observando o exemplo anterior, é o significado de executar início1 e início2 ao iniciar a instância de processo. As duas atividades serão 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 documentação BPMN, que é o conceito de TOKEN. Em uma linguagem de programação como o Java, um token seria algo análogo à uma thread. É algo criado em algum ponto do processo, e sua execução fica ativa durante algum tempo, até desaparecer ou se unir com outras unidades funcionais, que estão sendo executadas de forma independente umas das outras. No caso do BPMN, eles são propagados pelas atividades seguintes no fluxo, até que algo o faça desaparecer ou se juntar aos outros tokens. No diagrama acima, por exemplo, quando uma instância de processo é criada, dois tokens são criados. Tanto início1 quanto início2 são executados ao mesmo tempo. Mas ao contrário de uma thread, onde tudo é executado em paralelo mesmo, a notação BPMN não obriga a criação de mecanismos multithread. Pode ser executada início1 primeiro e início2 depois, ou vice versa. Ou os dois podem ser executados em paralelo, em uma ferramenta workflow que suporte multithread legítimo. O que importa é que, neste caso, a atividade intermediário atua como uma junção de tokens, e intermediário somente é executado quando inicio1 e inicio2 tiverem terminado. Se uma das atividades terminar antes, o token chega até intermediário e fica aguardando até que o outro token chegue até lá, para que o processo prossiga em sua execução. É importante distinguir instâncias de processos de tokens. Uma instância pode ter diversos tokens, mas um token pertence a apenas uma instância de processo. É muito importante a compreensão dos tokens, pois dependendo de como os fluxos forem desenhados haverá variação na forma como eles são criados e destruidos, e utilizaremos neste curso os mesmos termos adotados pela documentação oficial. Uma preocupação ao adotar o termo token foi permitir atividades executando em paralelo, sem forçar o engine de execução a adotar práticas de multithread. Para termos a certeza de que compreendemos o conceito, vamos analisar o seguinte exemplo : Exemplo de tokens Neste caso, dependendo da solução de workflow, poderemos ter as seguintes possibilidades de execução: 1) Uma thread é iniciada, e a atividade a1 é executada, e após esta a atividade a2. Ao mesmo tempo outra thread é iniciada, e a atividade a3 é executada e após a atividade a4.
A atividade a5 espera o término das duas threads para iniciar sua execução. O programa segue executando através 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). Após a execução dos dois, o caminho a5 continua a execução. 3) Outra possibilidade seria a execução da atividade a1, depois a execução da a3, a2 e depois a4, continuando na sequência a execução 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 bifurcação são executadas antes e que a junção a5 sincroniza as duas execuções. Desta forma, a notação permite a representação de execuções simultâneas, mesmo que a ferramenta não suporte o conceito. Atividade O conceito de atividade é simples, mas por outro lado abrangente. Uma atividade é um passo na execução de um fluxo. Ele é representado por um retângulo com as extremidades arredondadas. Uma atividade pode ser manual ou automática. Uma aprovação de crédito pode ser uma atividade. Um processo inteiro de cobrança pode ser uma atividade. Atividade, portanto, é um termo genérico para algo executado dentro de um processo. O desenho do fluxo já é uma atividade. No nível mais baixo, onde ele não pode mais ser subdividido em unidades menores, é chamado de uma tarefa (task), que é um termo especializado para uma atividade que não têm mais subníveis. Quando uma atividade pode ser aberta em atividades mais especializadas, ela é chamada de subprocesso. Exemplos de tarefas e subprocessos Uma diferença 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 (+) é visível, o fluxo que se encontra dentro não é apresentado. Quando o + é clicado, a atividade é expandida para mostrar o desenho em miniatura do fluxo em seu interior. Não é um comportamento obrigatório, mas facilita a visualização de cada nível inferior. Algumas ferramentas optam por abrir uma outra janela com o desenho do fluxo, quando o + é clicado. Conexão entre elementos O BPMN determina basicamente dois tipos de conexão : As que acontecem dentro de um processo, indicando a passagem de uma atividade para outra, e as conexões que acontecem entre dois processos, que são feitas pela passagem de mensagens. A conexão entre duas atividades de um mesmo processo é representada por uma seta com linha
contínua. Algo como : Sequência de fluxo Quando precisamos fazer com que dois fluxos distintos se comuniquem, a única forma é através do envio de mensagens. Mensagens fazem com que os fluxos tenham um baixo acoplamento, reduzindo dependências físicas. A documentação BPMN não especifica o mecanismo utilizado para mensagens. Pode ser SMTP, JMS ou qualquer outro middleware de mensagens. A sugestão é que envios de mensagens aconteçam através de acessos SOAP. Pool Para delinearmos os limites de um fluxo nós utilizamos um pool. A especificação não obriga a representação da pool, mas se um fluxo se iniciar em uma pool, ele deve estar completamente contido dentro dela. Pool No desenho acima, não é correto ter o evento de início dentro da pool, e o evento de término fora dela. O que é permitido é a comunicação de dois pools (lembrando que representam fluxos) através de mensagens. Mensagens entre fluxos
No exemplo anterior, temos dois tipos de mensagens. Uma enviada de uma atividade específica para uma atividade em outra pool, e uma conectando as duas pools. Cada mensagem é diferenciada através de uma linha pontilhada, unindo dois elementos. Quando a mensagem é enviada, o fluxo continua normalmente (através da linha contínua). Ela funciona como um aviso ao outro fluxo, algo que será utilizado do outro lado como uma forma de tomar decisão. 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 discutível, pode-se enviar mensagens dentro de uma mesma pool. Cada Pool pode ser dividida em unidades menores, chamadas de Lane. Lane Uma Lane pode representar cada papel dentro de um processo. Por exemplo, vendedores, gerentes, diretores podem ser papéis para execução de cada atividade. A documentação não coloca amarras em Lanes, significando meramente subdivisões. Podem ser departamentos, cargos ou mesmo unidades da empresa em países diferentes. Nos diagramas de mais baixo nível (aqueles que irão gerar códigos) o mais razoável é utilizar as Lanes para diferenciar os papeis (cargos), durante a execução. 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 invés de colocá-los nas próprias 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 especificação não obriga este tipo de formatação. Gateway No exemplo acima, aparecem dois losangos. Um logo após a entrada da forma de pagamento. Se a forma de pagamento e valores estiverem dentro de algo que possa ser aprovado pelo próprio vendedor, este entra os dados para entrega do produto. Se por outro lado, o vendedor não puder aprovar, ele repassa o caso ao gerente, que avalia se a venda pode ser aprovada ou não. Um gateway, portanto, é algo que permite tomada de decisão. Esta decisão pode ser manual, como este exemplo, ou programática, sobre um determinado valor ou cálculo. 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 execução do processo. Ou se vai para um caminho, ou para o outro. Nunca os dois (neste caso). Naturalmente o set completo do BPMN têm gateways
que vão muito além de uma comparação 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 próximos artigos estaremos explorando os elementos do set completo, e aí sim veremos o poder e diferencial do BPMN. Vocês irão perceber que existe todo um set de simbolos, para representar as situações mais comuns de desenhos de processos, alguns até mesmo relacionados aos mecanismos de programação. Até a próxima e fique sintonizado no PortalBPM!!