Conversão do Diagrama de Actividades

Um grafo é definido por um conjunto de vértices ‘V’ e um conjunto de arcos ‘E’, onde os arcos representam ligações entre os vértices. Os grafos podem ser dirigidos ou não dirigidos, consoante exista (ou não) a noção de direcção nos arcos. O diagrama de actividades da UML é um grafo dirigido, onde os vértices representam as actividades e os arcos representam as ligações de controlo. Uma actividade só se executa quando todas as ligações de controlo de entrada estiverem activas. Quando uma actividade finaliza a sua execução, todas as ligações de controlo de saída ficam activas. Desta forma é possível que várias actividades se executem concorrentemente. Na linguagem BPEL, as actividades encontram-se estruturadas em árvores. São usadas duas actividades estruturantes para construir uma árvore BPEL: BPELSequence, que representa uma sequência de actividades BPEL, e BPELFlow, que representa um conjunto de actividades BPEL concorrentes. É possível sincronizar actividades concorrentes recorrendo às ligações de controlo em BPEL.

Uma vez que as duas metodologias de modelação: UML e BPEL, usam representações diferentes para a concorrência entre actividades, torna-se necessário usar um algoritmo para separar as actividades UML concorrentes em sequências e fluxos paralelos de execução, preservando a noção de concorrência descrita inicialmente no diagrama de actividades UML. Os restantes artefactos do diagrama de actividades da UML são facilmente convertíveis, usando as regras de conversão apresentadas anteriormente.

4.8.5.1 Geração da Árvore do Processo BPEL

O algoritmo desenvolvido está dividido em três fases: conversão das actividades UML em BPEL, geração da árvore BPEL e optimização da árvore gerada. Na primeira fase, as actividades UML são convertidas em actividades BPEL equivalentes, através das regras de conversão apresentadas nas Secções anteriores. É usada uma representação em grafo para armazenar o resultado da conversão inicial, onde os vértices do grafo são as actividades BPEL. Todos os arcos constantes no diagrama de actividades UML original

são adicionados ao grafo de actividades BPEL. Considere-se, como exemplo, o seguinte diagrama de actividades UML:

Actividade1 <<receive>> Actividade2 <<assign>> [ cond1 ] Actividade4 <<invoke>> Actividade3 <<invoke>> [ cond2 ] Actividade6 <<reply>> Actividade5 <<wait>>

Figura 4.31 – Exemplo Diagrama Actividades UML

Após todas as actividades da Figura 4.31 terem sido convertidas obtém-se o seguinte grafo BPEL: BPELReceive nome: Actividade1 BPELSwitch nome: Decisao1 BPELAssign nome: Actividade2 BPELInvoke nome: Actividade3 BPELMerge nome: Fusao1 BPELInvoke nome: Actividade4 BPELWait nome: Actividade5 BPELReply nome: Actividade6 cond: ‘cond2’ cond: ‘cond1’ BPELReceive nome: Actividade1 BPELSwitch nome: Decisao1 BPELAssign nome: Actividade2 BPELInvoke nome: Actividade3 BPELMerge nome: Fusao1 BPELInvoke nome: Actividade4 BPELWait nome: Actividade5 BPELReply nome: Actividade6 cond: ‘cond2’ cond: ‘cond1’

Figura 4.32 – Grafo de Actividades BPEL

Na segunda fase, é gerada uma árvore com base no grafo BPEL recorrendo às duas actividades estruturantes: BPELSequence e BPELFlow. Torna-se necessário

separar as actividades BPEL do grafo em sequências e fluxos concorrentes. Existem pelo menos duas técnicas básicas para a travessia de grafos: pesquisa em largura e pesquisa em profundidade. Dado um grafo ‘G=(V,E)’ e um vértice raiz ‘s’, a pesquisa em largura explora, sistematicamente, todos os arcos de ‘G’ para descobrir cada vértice atingível a partir de ‘s’. Para qualquer vértice ‘v’ atingível a partir de ‘s’, o caminho na árvore de pesquisa em profundidade corresponde ao caminho mais curto de ‘s’ a ‘v’, na medida em que contém o menor número de arcos. A razão do nome “pesquisa em profundidade” deve-se ao facto do algoritmo descobrir todos os vértices ‘v’ que se encontram à distância ‘k’ de ‘s’ antes de descobrir os que estão à distância ‘k+1’.

Na pesquisa em profundidade, os arcos são explorados a partir do último vértice descoberto ‘v’ que ainda tenha arcos de saída por explorar. O algoritmo continua até que todos os vértices atingíveis a partir do vértice inicial tenham sido descobertos. Se restarem vértices por descobrir então um deles é seleccionado e a pesquisa continua a partir dele. É possível usar a pesquisa em profundidade para classificar os arcos do grafo em quatro tipos distintos: arcos de árvore, arcos para trás, arcos para a frente, arcos de cruzamento. Um arco ‘(u, v)’ é um arco de árvore se ‘v’ foi descoberto pela primeira vez devido à exploração de ‘(u, v)’. Os arcos para trás ligam um vértice ‘u’ a um vértice ‘v’, antecessor na mesma árvore de pesquisa. Os arcos para a frente ligam um vértice ‘u’ a um vértice ‘v’, descendente na mesma árvore de pesquisa. Os arcos de cruzamento podem ligar vértices dentro da mesma árvore de pesquisa, desde que um vértice não seja antecessor do outro, ou podem ligar vértices entre árvores de pesquisa diferentes. Prova-se que um grafo dirigido é acíclico somente se a pesquisa em profundidade não encontrar arcos para trás [CLRS01].

Através da pesquisa em profundidade é possível obter a ordenação topológica dos vértices de um grafo. A ordenação topológica dos vértices de um grafo dirigido acíclico ‘G=(V,E)’ é uma ordenação linear de todos os seus vértices tal que se ‘G’ contém o arco ‘(u, v)’ então ‘u’ aparece antes de ‘v’ na ordenação. Se o grafo que representa o diagrama de actividades não tiver ciclos, i.e. não tiver arcos para trás, e se interpretarmos a existência de um arco ‘(u, v)’ no grafo como uma ligação de controlo entre as actividades ‘u’ e ‘v’, então, através da ordenação topológica obtém-se

ordenação topológica dos vértices de um grafo dirigido acíclico. Após a execução do conjunto de acções descritas no vértice ‘A’ seguido das do vértice ‘B’, passa a ser possível executar as acções dos vértices: ‘C’, ‘D’ e ‘E’, em paralelo. No entanto, após a ordenação topológica todas as actividades são executadas em série, pelo que a noção de concorrência é perdida, podendo reduzir significativamente a eficiência de execução do processo BPEL resultante da conversão.

Ordenação topológica possível: A,B,C,D,F,E,G

A

B

C D E

F G

Ordenação topológica possível: A,B,C,D,F,E,G

A B C D E F G A B C D E F G

Figura 4.33 – Ordenação Topológica

Dado que as actividades em BPEL estão estruturadas em árvores, as próprias árvores de pesquisa, resultantes da travessia em largura e em profundidade, são uma conversão possível para o grafo de actividades BPEL. Assim, os nós da árvore que tenham um número de descendentes superior a um representam um BPELFlow, com um número de actividades concorrentes igual ao número de descendentes do nó. Os nós com um número de descendentes igual a um são adicionados a uma BPELSequence. Todos os arcos para a frente e de cruzamento correspondem a ligações de controlo em BPEL. Se for encontrado um arco para trás, sabe-se de imediato que existem ciclos no grafo e que o processo UML não pode ser convertido num processo BPEL. Devido ao facto do algoritmo de pesquisa em profundidade classificar os arcos do grafo e identificar a presença de ciclos durante a própria travessia, é possível gerar a árvore a partir do grafo BPEL numa só iteração. Por este motivo prefere-se a utilização da travessia em profundidade à travessia em largura para construir a árvore de actividades BPEL. A implementação do algoritmo com base na travessia em profundidade permite

que o tempo de execução seja linear, proporcional à soma do número de arcos e vértices do grafo BPEL: ‘O(V+E)’. Em [CLRS01] é feita uma demonstração formal do tempo de execução do algoritmo de travessia em profundidade.

As regras a aplicar durante a travessia em profundidade para gerar a árvore BPEL encontram-se descritas na Tabela em baixo. As regras estão seriadas segundo a sua ordem de aplicação.

Arco ‘(u, v)’

Actividade ‘u’

‘(u, v)’ é arco de árvore ‘(u, v)’ é arco para a frente ou de cruzamento, onde ‘v’ não é um BPELMerge

BPELSwitch Criar um novo ramo do nó

decisão, com a condição de transição do arco.

Pesquisar a partir de ‘v’ e adicionar todas as actividades encontradas ao ramo do BPELSwitch.

Criar um novo ramo do nó decisão, com a condição de transição do arco.

Adicionar uma actividade

BPELEmpty ao ramo.

Criar uma ligação de controlo entre a actividade

BPELEmpty e ‘v’.

BPELMerge² Pesquisar a partir de ‘v’ e

adicionar todas as actividades encontradas a seguir ao BPELSwitch correspondente.

Criar uma ligação de controlo entre o

BPELSwitch

correspondente e ‘v’.

Arco ‘(u, v)’

Actividade ‘u’

‘(u, v)’ é arco de árvore ‘(u, v)’ é arco para a frente ou de cruzamento, onde ‘v’ não é um BPELMerge

Grau saída de ‘u’ superior a um

Criar um BPELFlow. Criar uma BPELSequence para cada arco ‘(u, v)’ deste tipo. Todas as actividades encontradas a partir de ‘v’ são adicionadas a esta sequência.

Criar uma ligação de controlo entre ‘u’ e ‘v’ para cada arco ‘(u, v)’ deste tipo.

Grau de saída de ‘u’ igual a um

Todas as actividades encontradas a partir de ‘v’ são adicionadas à

BPELSequence actual.

Criar uma ligação de controlo entre ‘u’ e ‘v’.

Tabela 4.5 – Regras para a Geração da Árvore BPEL

Aplicando as regras da Tabela 4.5 ao grafo da Figura 4.32 obtém-se a árvore BPEL ilustrada em baixo.

Actividade1 Actividade3 Actividade6 Actividade2 Actividade4 Actividade5 Fluxo2 Fluxo1 cond1 cond2 Ligação de controlo Decisao1 S equ en c ia1 S e qu enc ia 2 S e qu enc ia 3 Seq 4 Seq 5 Actividade1 Actividade3 Actividade6 Actividade2 Actividade4 Actividade5 Fluxo2 Fluxo1 cond1 cond2 Ligação de controlo Decisao1 S equ en c ia1 S e qu enc ia 2 S e qu enc ia 3 Seq 4 Seq 5

Figura 4.34 – Árvore BPEL

A árvore gerada com base no algoritmo de pesquisa em profundidade tende a produzir actividades de características: redundantes, i.e. que não têm significado para a execução do processo ou não alteram o seu estado interno, e lentas, i.e. que podem ser substituídas por outras que demoram menos tempo a produzir o mesmo resultado. A fase de optimização tem como objectivo substituir o código BPEL por outro que seja de execução mais rápida, ocupe menos espaço em memória e produza o mesmo resultado. O optimizador recorre a um conjunto de heurísticas simples, de modo a não prejudicar o desempenho global do algoritmo de conversão.

O método genérico de optimização consiste em percorrer a árvore BPEL da raiz em direcção às folhas, substituindo actividades BPEL por outras mais eficientes. No caso das actividades compostas, i.e. actividades que contenham outras actividades BPEL, tais como: o BPELFlow, a BPELSequence e o BPELSwitch, as actividades constituintes são optimizadas primeiro, seguindo-se a optimização da própria actividade

Actividades BPEL Heurísticas de Optimização

BPELEmpty H1 Caso não possua ligações de controlo (entrada ou saída): remover a actividade.

BPELWait H2 Se a expressão temporal for vazia: aplicar H1.

BPELAssign H3 Se a lista de atribuições for nula: aplicar H1.

BPELSequence H4 Para cada actividade da BPELSequence aplicar H1 até H3.

H5 Se após a aplicação de H4 a BPELSequence ficar vazia: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo da BPELSequence à actividade

BPELEmpty e substituir a BPELSequence pela

actividade BPELEmpty.

H6 Se após a aplicação de H4 a BPELSequence contiver uma só actividade: adicionar as ligações de controlo da BPELSequence à actividade e substituir a

BPELSequence pela actividade constituinte.

BPELFlow H7 Para cada actividade concorrente aplicar H1 até H3. H8 Se após a aplicação de H7 não restarem fluxos

concorrentes: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo do BPELFlow à actividade

BPELEmpty e substituir o BPELFlow pela actividade BPELEmpty.

H9 Se após a aplicação de H7 existir apenas um fluxo de execução e o BPELFlow não armazenar informação sobre as ligações de controlo entre actividades³: adicionar as ligações de controlo do BPELFlow à actividade e substituir o BPELFlow pela actividade constituinte.

3

Todas as ligações de controlo entre actividades são armazenadas num BPELFlow hierarquicamente superior; o próprio BPELFlow pode estar ligado a outra actividade BPEL, sendo esta ligação de controlo armazenada num BPELFlow hierarquicamente superior a este.

Actividades BPEL Heurísticas de Optimização

BPELSwitch H10 Para cada ramo aplicar H1 até H3.

H11 Se após a aplicação de H10 não restarem ramos: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo do BPELSwitch à actividade BPELEmpty e substituir o BPELSwitch pela actividade

BPELEmpty.

H12 Se após a aplicação de H10 existir apenas um ramo com a condição ‘otherwise’: adicionar as ligações de controlo do BPELSwitch à actividade associada ao ramo e substituir o BPELSwitch pela actividade do ramo.

Tabela 4.6 – Heurísticas de Optimização do Código BPEL

O resultado da optimização da árvore BPEL da Figura 4.34 encontra-se na Figura em baixo. As actividades: ‘Sequencia4’ e ‘Sequencia5’, contidas nos ramos do

BPELSwitch, foram substituídas pelas actividades constituintes, resultado da aplicação

de H6. O ‘Fluxo1’ apenas contém uma actividade do tipo BPELSequence. Se a ligação de controlo entre ‘Decisao1’ e ‘Actividade6’ estiver armazenada no ‘Fluxo2’, é possível aplicar H9, substituindo ‘Fluxo1’ por ‘Sequencia1’.

Actividade1 Actividade3 Actividade6 Actividade2 Actividade4 Actividade5 Fluxo2 cond1 cond2 Ligação de controlo Decisao1 S e q uencia1 S equen c ia3 Actividade1 Actividade3 Actividade6 Actividade2 Actividade4 Actividade5 Fluxo2 cond1 cond2 Ligação de controlo Decisao1 S e q uencia1 S equen c ia3