Conversão da Notação CEO para a linguagem BPEL4WSweb.ist.utl.pt/ist150077/doc/uthesis.pdf ·...

Departamento de Engenharia

Informática

Conversão da Notação CEO

para a linguagem BPEL4WS

RELATÓRIO

TRABALHO FINAL DE CURSO

Ano Lectivo: 2004/2005

N.º da Proposta: 39

Título: Conversão da Notação CEO para a linguagem BPEL4WS

Curso: Licenciatura em Engenharia Informática e de Computadores (LEIC)

Professor Orientador:

Prof.ª Dr.ª Carla Ferreira __________(assinatura)__________

Co-Orientador:

__________(assinatura)__________

Alunos:

50077, Francisco Santos __________(assinatura)__________

Relatório de TFC – Conversão da Notação CEO para a linguagem BPEL4WS

Francisco Santos i

Agradecimentos

À minha orientadora, a Sr.ª Prof.ª Dr.ª Carla Ferreira, agradeço todo o apoio prestado durante

a realização do trabalho e os conselhos sobre a melhor forma de concretizar os objectivos

propostos.

Ao grupo CEO agradeço a oportunidade que me deram para expor o meu trabalho e as

sugestões que fizeram sobre como melhorar e expandir as ideias iniciais.

Ao Sr. Eng. João Saraiva agradeço a disponibilidade que demonstrou no esclarecimento de

dúvidas sobre o projecto Eclipse UML2. Ao Sr. Dr. Alexandre Francisco agradeço os

esclarecimentos que prestou relativamente aos algoritmos de travessia em grafos.

Um agradecimento especial à minha família e amigos que me apoiaram durante a realização

do trabalho.

Lisboa, Fevereiro de 2006

Francisco Santos


Francisco Santos ii

Resumo

A Framework CEO (FCEO) suporta a modelação dos processos de negócio de organizações.

Para a representação dos seus modelos a FCEO estende a notação UML com conceitos

específicos ao domínio dos processos de negócio. A Business Process Execution Language

for Web Services (BPEL4WS) é uma linguagem executável para a modelação de negócios, no

entanto, o seu nível conceptual é mais próximo da implementação do que os modelos FCEO.

O objectivo deste trabalho é o de tornar os modelos FCEO executáveis, estendendo o perfil de

modelação do negócio da FCEO e implementando um método automático de conversão para

a linguagem de execução de processos de negócio: BPEL4WS.

Palavras chave: modelo, processo, negócio, modelação, FCEO, UML, BPEL4WS, BPEL,

conversão, algoritmo, executável


Francisco Santos iii

Índice

1 Introdução............................................................................................................................ 8

2 Framework CEO................................................................................................................ 10

2.1 Definição de um Processo de Negócio..................................................................... 10

2.1.1 Especificação da Estrutura do Processo ............................................................... 10

2.1.2 Especificação Funcional do Processo .................................................................. 11

3 BPEL4WS ......................................................................................................................... 22

3.1 Relação com o WSDL.............................................................................................. 22

3.2 Definição de um Processo de Negócio..................................................................... 23

3.2.1 Especificação do Serviço Associado ao Processo................................................ 24

3.2.2 Especificação Funcional do Processo .................................................................. 25

4 Conversão entre FCEO e BPEL4WS ................................................................................ 30

4.1 Extensão ao Perfil UML da FCEO........................................................................... 30

4.2 Delineação do Processo de Conversão UML BPEL ................................................ 37

4.3 Organização do Espaço Nomes................................................................................ 39

4.3.1 Notação................................................................................................................. 39

4.3.2 Geração dos Ficheiros XSD, WSDL e BPEL ...................................................... 40

4.4 Conversão dos Tipos de Dados e Mensagens .......................................................... 41

4.4.1 Geração dos Ficheiros XSD e WSDL.................................................................. 42

4.5 Conversão das Propriedades e Conjuntos de Correlação ......................................... 46

4.5.1 Notação................................................................................................................. 47

4.5.2 Geração dos Ficheiros WSDL e BPEL ................................................................ 50

4.6 Conversão dos Protocolos de Negócio..................................................................... 52

4.6.1 Notação................................................................................................................. 52

4.6.2 Geração do Ficheiro WSDL................................................................................. 53

4.7 Conversão de Processos ........................................................................................... 54

4.7.1 Notação................................................................................................................. 54

4.7.2 Geração do Ficheiro BPEL .................................................................................. 55

4.8 Manipulação do Estado do Processo........................................................................ 56

4.8.1 Linguagem XPath................................................................................................. 56

4.8.2 Expressões de Acesso aos Dados ......................................................................... 58


Francisco Santos iv

4.8.3 Expressões de Atribuição ..................................................................................... 59

4.8.4 Geração das Actividades BPEL ........................................................................... 60

4.8.5 Conversão do Diagrama de Actividades .............................................................. 67

5 Implementação................................................................................................................... 77

6 Conclusão .......................................................................................................................... 81

Apêndice A – Ficheiro WSDL Protocolo Encomendar ........................................................... 82

Apêndice B – Ficheiro BPEL ProcessoReceberEcomenda...................................................... 83

Apêndice C – Conversão de Tipos Básicos da UML para o Formato XSD ............................ 86

Apêndice D – Conversão para o Perfil versão UML 2.0 ......................................................... 87

Referências ............................................................................................................................... 89


Francisco Santos v

Lista Figuras

Figura 2.1 – Diagrama de Classes para a Estrutura dos Recursos ........................................... 11

Figura 2.2 – Diagrama de Actividades para o ProcessoReceberEncomenda........................... 13

Figura 2.3 – Diagrama de Actividades para o Processo de Desenvolvimento Software ......... 14

Figura 2.4 – Diagrama de Actividades com actividades aninhadas......................................... 15

Figura 2.5 – Nós de decisão e de fusão .................................................................................... 17

Figura 2.6 – Utilização explícita de nós de difusão e de junção .............................................. 19

Figura 2.7 – Diagrama de Actividades com fluxo de objectos ................................................ 20

Figura 2.8 – Diagrama de Actividades com fluxo de objectos e pistas ................................... 21

Figura 3.1 – Processo de Recepção de Encomendas................................................................ 23

Figura 4.1 – Diagrama de Actividades para o Processo Receber Encomenda......................... 31

Figura 4.2 – Tipos de Dados e Mensagens............................................................................... 32

Figura 4.3 – Protocolos de Negócio, Papéis e Interfaces ......................................................... 33

Figura 4.4 – Processo Recepção de Encomendas .................................................................... 34

Figura 4.5 – Diagrama de Actividades detalhado para o Processo Receber Encomenda ........ 35

Figura 4.6 – Esquema dos Documentos XML gerados pelo Processo de Conversão.............. 38

Figura 4.7 – Exemplo de Dependência entre Pacotes .............................................................. 39

Figura 4.8 – Notação para o pacote e para a dependência entre pacotes ................................. 40

Figura 4.9 – Cenário Conversão para uma Encomenda ........................................................... 45

Figura 4.10 – Ficheiro XSD correspondente aos Tipos de Dados Base da Encomenda.......... 45

Figura 4.11 – Ficheiro WSDL correspondente à Encomenda.................................................. 46

Figura 4.12 – Notação para as Propriedades ............................................................................ 48

Figura 4.13 – Exemplo da inclusão de um Conjunto de Correlação num Processo ................ 49

Figura 4.14 – Exemplo de uma Actividade que usa Correlação .............................................. 49

Figura 4.15 – Definição Propriedades em WSDL.................................................................... 51

Figura 4.16 – Definição de Conjuntos de Correlação em BPEL ............................................. 51

Figura 4.17 – Definição de Actividades Correlacionadas em BPEL ....................................... 52

Figura 4.18 – Exemplo da Notação dos Protocolos de Negócio e Papéis................................ 53

Figura 4.19 – Exemplo da Notação das Interfaces................................................................... 53

Figura 4.20 – Ficheiro WSDL com a definição das Ligações a Parceiros e Papéis................. 54

Figura 4.21 – Exemplo de uma Actividade de Atribuição....................................................... 60


Francisco Santos vi

Figura 4.22 – Exemplo da conversão de uma Actividade de Atribuição para BPEL .............. 61

Figura 4.23 – Exemplo de uma Actividade de Espera ............................................................. 62

Figura 4.24 – Exemplo da conversão de uma Actividade de Atribuição para BPEL .............. 62

Figura 4.25 – Exemplo da Invocação de Operações Síncronas e Assíncronas ........................ 63

Figura 4.26 – Exemplo da Conversão de Actividades de Invocação Síncronas e Assíncronas63

Figura 4.27 – Exemplo da utilização de Actividades de Recepção e Reposta......................... 64

Figura 4.28 – Exemplo da Conversão de Actividades de Recepção e Resposta...................... 65

Figura 4.29 – Exemplo da utilização de Actividades de Decisão ............................................ 66

Figura 4.30 – Exemplo da Conversão de uma Actividade de Decisão para BPEL.................. 66

Figura 4.31 – Exemplo Diagrama Actividades UML .............................................................. 68

Figura 4.32 – Grafo de Actividades BPEL .............................................................................. 68

Figura 4.33 – Ordenação Topológica....................................................................................... 70

Figura 4.34 – Árvore BPEL ..................................................................................................... 73

Figura 4.35 – Árvore BPEL Optimizada.................................................................................. 76

Figura 5.1 – Interface Gráfica do Conversor............................................................................ 80

Figura 5.2 – Visualizador de Eventos da Plataforma Eclipse .................................................. 80


Lista Tabelas

Tabela 2.1 – Um plano de execução para o diagrama de actividades da Figura 2.4................ 16

Tabela 3.1 – Principais actividades de um processo BPEL4WS ............................................. 27

Tabela 4.1 – Conversão das Expressões de Multiplicidade ..................................................... 43

Tabela 4.2 – Conversão Modelo UML para Formato XSD ..................................................... 44

Tabela 4.3 – Atributos para a Definição de um Processo BPEL.............................................. 55

Tabela 4.4 – Exemplos de Expressões de Acesso aos Dados .................................................. 59

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

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

Francisco Santos vii

1 Introdução A Unified Modeling Language (UML) é uma linguagem para a especificação,

visualização, construção e documentação de artefactos de software. A UML representa

um conjunto das melhores práticas da engenharia, que provaram adequadas na

modelação de sistemas software complexos e de grande escala. Através dos seus

mecanismos de extensão foi possível utilizar a UML noutros domínios de aplicação,

como sendo a modelação do negócio.

Desenvolver um modelo para um sistema de software antes da sua construção ou

renovação é uma tarefa importante para garantir o sucesso de um projecto de

engenharia. Os bons modelos são essenciais para a comunicação entre equipas de

projecto e assegura uma coesão arquitectural do sistema. À medida que a complexidade

dos sistemas aumenta, torna-se particularmente útil recorrer às técnicas de modelação,

tratando-se de uma boa forma de reduzir a complexidade do projecto. A modelação

permite ao engenheiro abstrair-se dos aspectos irrelevantes e focar nos aspectos mais

importantes para uma dada fase do projecto.

A Framework CEO (FCEO) é um perfil UML (extensão do UML base) que

permite definir o modelo de negócio de uma organização. Este modelo,

conceptualmente semelhante ao modelo de software, é uma abstracção de como o

negócio funciona. Cria uma vista simplificada da estrutura do negócio, servindo de base

à comunicação, introdução de melhoramentos ao funcionamento da organização ou na

inovação do negócio. Os modelos FCEO não são à partida executáveis, uma vez que

possuem apenas uma descrição estática da estrutura e dinâmica do processo. Usando

uma descrição normalizada da dinâmica do processo torna-se possível a conversão

automática dos modelos estáticos em modelos executáveis, permitindo simular o

funcionamento real dos processos. Através da simulação torna-se possível enriquecer

ainda mais o modelo de negócio existente e possibilita a sua validação, recorrendo a

cenários de negócio reais.

Foi escolhida a linguagem Business Process Execution Language for Web

Services (BPEL4WS) para definir a versão executável dos processos de negócio. A


BPEL4WS define um modelo e uma gramática para descrever o comportamento de um

processo de negócio baseado nas interacções entre o processo e os parceiros de negócio

envolvidos. Um parceiro pode providenciar serviços, requisitar serviços ou participar

numa conversação bidireccional com o processo. O objectivo deste trabalho é o de

tornar os modelos FCEO executáveis, estendendo o perfil de modelação do negócio da

FCEO e implementando um método automático de conversão para a linguagem de

execução de processos de negócio: BPEL4WS.

O relatório está organizado da seguinte forma: na Secção 2 é feita uma descrição

do perfil UML da FCEO para a definição de processos de negócio, na Secção 3 é

apresentada a linguagem de modelação de processos de negócio executáveis:

BPEL4WS, na Secção 4 é descrito todo o processo de conversão entre as duas

linguagens de modelação, os detalhes da implementação do algoritmo encontram-se

descritos na Secção 5 e as principais conclusões do trabalho encontram-se descritas na

Secção 6.

Francisco Santos 9


2 Framework CEO A Framework CEO (FCEO) [VCSMT04], proposta pelo Centro de Engenharia

Organizacional (CEO), permite modelar os conceitos do negócio. Nesta framework foi

adoptada uma estratégia conjunta de desenho de SI e do negócio, garantindo assim um

melhor alinhamento entre estes dois aspectos da modelação organizacional. Esta

framework contempla, actualmente, os seguintes conceitos do negócio: os objectivos

(<<goal>>), para a modelação da estratégia; os processos (<<process>>), para a

modelação dos processos de negócio; os recursos (<<resource>>), para a modelação

dos recursos do negócio; e os blocos (<<block>>), para a modelação dos sistemas de

informação.

Outra vantagem da FCEO reside no facto de ser suportada por uma linguagem

de modelação estandarte que representa as melhores práticas na indústria da modelação

orientada a objectos: a Unified Modelling Language (UML) [OMG03]. Mais

concretamente, esta framework recorre a um perfil UML para permitir a modelação no

domínio do negócio.

2.1 Definição de um Processo de Negócio

De forma a melhor compreender a metodologia de modelação sugerida pela FCEO e,

numa fase posterior, compreender quais são as transformações necessárias a fazer ao

modelo de forma a torná-lo executável, é apresentado um curto exemplo de um processo

de recepção de encomendas.

2.1.1 Especificação da Estrutura do Processo

No Diagrama de Classes para a Estrutura dos Recursos são descritas as relações que

existem entre os recursos físicos e de informação, lidados pelo processo. Neste caso, o

Cliente (recurso físico) efectua uma Encomenda (recurso de informação) onde constam

vários Produtos (recurso físico) oferecidos pela empresa. Para cada encomenda é

emitida uma Factura (recurso de informação) à qual irá corresponder um Pagamento

(recurso físico).

Francisco Santos 10


Cliente<<resource>>

Produto<<resource>>

Encomenda<<resource>>

1 n

0..1

1..n

Pagamento<<resource>>

Factura<<resource>>

1

1

1 1

1 n

0..1

1..n

1

1

1 1

Figura 2.1 – Diagrama de Classes para a Estrutura dos Recursos

Existem as seguintes relações entre os recursos enunciados: para cada Cliente

existem zero ou mais Encomendas, para cada Encomenda existem um ou mais Produtos

encomendados, para cada Encomenda existe uma Factura e para cada Factura existe um

Pagamento. Seguidamente deve ser criado o Diagrama de Classes para a Estrutura dos

Processos, onde são descritas as relações entre os vários processos e sub-processos da

organização. Neste caso, vai ser modelado apenas um processo: o

‘ProcessoReceberEncomenda’.

2.1.2 Especificação Funcional do Processo

Os diagramas de actividades são usados para explorar e descrever fluxos de execução,

as acções desempenhadas por uma operação de uma classe, semelhante aos tradicionais

diagramas de fluxos de dados. Adicionalmente, os diagramas de actividades são usados

para descrever processos de negócio, i.e. fluxos de execução, ou workflows, no contexto

organizacional. Um fluxo de execução pode envolver uma simples operação, tal como a

introdução de uma encomenda num sistema de processamento de encomendas, ou pode

ser mais complexo, tal como o processo de controlo de produção e desenvolvimento de

produtos. No âmbito deste trabalho não serão considerados diagramas de actividades

que contenham actividades aninhadas (tal como apresentado na Figura 2.4) [OMG03].

Na Figura 2.2, é apresentado o diagrama de actividades para o processo de

recepção de encomendas. Os classificadores: ‘encomendar’, ‘enviar’, ‘facturar’ e

Francisco Santos 11


‘fabricar’ separam o conjunto de actividades desempenhadas pelos vários intervenientes

no processo. Os nomes das actividades foram escolhidos com base na actividade

realizada pelo processo em relação aos outros intervenientes.

No acto da recepção da encomenda do cliente, actividade ‘receberEncomenda’,

são iniciadas três tarefas concorrentes: escolha do distribuidor, actividade

‘inicializarPedidoEntrega’, cálculo do preço dos artigos encomendados, actividade

‘calcularPreco’, e escalonamento da produção, actividade

‘pedirEscalonamentoProducao’. Num diagrama de actividades existe uma transição

automática entre uma actividade e as actividades sucessoras. Não havendo condições de

guarda especificadas para as transições de saída, as próximas actividades podem

executar-se logo que as actividades antecessoras tenham terminado. No caso do

exemplo, existem restrições quanto à forma de execução concorrencial das tarefas: só é

possível finalizar o cálculo do preço da encomenda depois de determinado o preço de

envio, ligação entre ‘pedirEntrega’ e ‘enviarPrecoEntrega’, e só é possível finalizar o

escalonamento da produção depois de se saber a data de envio do distribuidor, ligação

entre ‘receberPrazoEntrega’ e ‘enviarPrazoEntrega’. Assim que as três sequências

concorrentes terminem, o processamento da encomenda pode continuar, sendo enviada

a factura ao cliente: ‘enviarFactura’.

Francisco Santos 12


receberEncomenda

env iarFactura

inicializarPedidoEntrega

pedirEntrega

receberPrazoEntrega

env iarPrecoEntrega

receberFactura

calcularPreco pedirEscalonamentoProducao

env iarPrazoEntrega

FabricarFacturarEnviarEncomendar encomendar enviar facturar fabricar

Figura 2.2 – Diagrama de Actividades para o ProcessoReceberEncomenda

2.1.2.1 Estados Actividade

O diagrama de actividades é um caso particular de um diagrama de estados, no qual

todos ou a maioria dos estados representam actividades a ser executadas, e todas ou a

maioria das transições são despoletadas pelo término das actividades antecedentes, i.e.

quando uma actividade especificada num estado foi executada, a transição para a

próxima actividade ocorre automaticamente. Os estados num diagrama de actividades

são designados estados actividade ou, simplesmente, actividades. Os estados

actividade são estados nos quais alguma actividade é desempenhada.

As actividades podem ser divididas em subactividades. No caso apresentado na

Figura 2.3 a actividade ‘Processo Desenvolvimento Software’ foi subdividida em seis

actividades distintas: ‘Análise Requisitos’, ‘Desenho Sistema’, ‘Implementação’,

‘Teste’, ‘Distribuição’ e ‘Manutenção’. As subactividades que não possam mais ser

subdivididas são designadas acções (actividades atómicas); as actividades atómicas

encontram-se representadas pelo mesmo símbolo das outras actividades: rectângulo de

cantos arredondados. As actividades e acções encontram-se ligadas através de

Francisco Santos 13


transições, sendo que estas compõem o fluxo de execução de um diagrama de

actividades.

Processo Desenvolvimento Software

Análise Requisitos

Desenho Sistema

Implementação

Teste Distribuição Manutenção

Análise Requisitos

Desenho Sistema

Implementação

Teste Distribuição Manutenção

Figura 2.3 – Diagrama de Actividades para o Processo de Desenvolvimento Software

2.1.2.2 Fluxo de Execução Básico

A ordem de execução das actividades é modelada usando ligações de controlo, que são

representadas por uma seta de transição entre duas actividades. Os processos suportam

fluxos de execução concorrentes. Uma actividade é executada quando todas as ligações

de controlo de entrada estão activas. Quando uma actividade finaliza a sua execução,

todas as ligações de controlo de saída ficam activas. Opcionalmente, uma ligação de

controlo pode conter uma guarda. Uma ligação de controlo com guarda só é activada se

a avaliação da guarda (expressão booleana) resultar no valor verdadeiro após a

actividade origem terminar a sua execução.

Uma actividade pode ter uma ou mais ligações de controlo de entrada e de saída.

Uma actividade pode estar aninhada dentro de outra actividade. As ligações de controlo

podem atravessar as fronteiras duma actividade; isto permite que uma actividade

aninhada possa ter uma ligação de controlo de entrada e de saída para uma actividade

exterior à actividade que a contém.

O exemplo da Figura 2.4 ilustra o fluxo de execução para actividades aninhadas.

De forma a facilitar a compreensão do exemplo, designaremos por ‘1’ a actividade

‘Actividade 1’ e por ‘3::1’ a actividade ‘Actividade 3::Actividade 1’.

Francisco Santos 14


Actividade 1

Actividade 2Activitdade 3

Actividade 1

Actividade 2

Actividade 3Actividade 1

Actividade 2

Actividade 3 Actividade 4

Actividade 5Actividade 6

Actividade 7

[ guarda1 ]

Figura 2.4 – Diagrama de Actividades com actividades aninhadas

Na tabela que se segue é demonstrado um plano de execução possível e quais as

actividades que podem ser executadas a um dado momento. Assume-se, neste exemplo,

que as actividades: 1, 2, 3::1, 3::2, 3::3, 4, 5, 6 e 7, são atómicas.

Actividades Executáveis Operação Escolhida Comentário

{1} Executar 1 Inicio da execução.

{2, 3} Executar 3 É possível subdividir a

actividade 3. A actividade 4

depende da actividade 3::3.

{2, 3::1, 3::3} Executar 3::1

{2, 3::3} Executar 2

{3::2, 3::3} Executar 3:2 3::2 só pode ser executada

após 2 e 3::1 terem

terminado.

{3::3} Executar 3::3

Francisco Santos 15


Actividades Executáveis Operação Escolhida Comentário

{4, 5} Executar 5 Tendo sido executada a

última actividade atómica

aninhada na actividade 3,

considera-se que esta

terminou a sua execução.

{4} Executar 4

{6} Executar 6

{} Avaliar guarda1 = true Após término da actividade

6, a condição de guarda é

avaliada; caso seja

verdadeira, torna-se

possível executar a

actividade 7.

{7} 7 Tabela 2.1 – Um plano de execução para o diagrama de actividades da Figura 2.4

2.1.2.3 Nós de Decisão e de Fusão

Os nós de decisão (decision) e de fusão (merge) permitem afinar o comportamento do

fluxo de execução concorrente. As decisões permitem relacionar o fluxo de execução

das actividades ao estado interno do processo. Quando o controlo de execução chega ao

nó de decisão, todas as condições de guarda, pertencentes às ligações de controlo que

partem do nó, são avaliadas. Quando o resultado de avaliar uma condição de guarda for

verdadeiro, a ligação de controlo associada passa a estar activa e mais nenhuma

condição de guarda é avaliada. No máximo uma ligação de controlo pode ter a condição

de guarda ‘otherwise’, indicando que a ligação de controlo é activada caso o resultado

de avaliar todas as outras ligações de controlo tenha sido falso.

Um nó de fusão permite que várias ligações de controlo de entrada causem a

activação de uma ligação de controlo de saída. Este tipo de nó é usado para juntar vários

fluxos de execução alternativos, criados por um nó decisão, indicando que o

Francisco Santos 16


comportamento após a fusão é comum a todos os casos. O exemplo da Figura 2.5 ilustra

um caso de utilização dos nós de decisão e de fusão para diferenciar o tratamento de

encomendas urgentes, sendo que a actividade ‘Fechar Encomenda’ é executada em

qualquer um dos casos.

Preparar

Encomenda

Enviar Modo Expresso

Enviar Modo Normal

Fechar Encomenda

[ tipo de envio = 'urgente' ] [ otherwise ]

Figura 2.5 – Nós de decisão e de fusão

Em termos de notação, tanto o nó de decisão como o de fusão são representados

por um losango (existe um nó de cada tipo no diagrama anterior). Os nós de decisão

representam escolhas, onde a execução de uma dada ligação de controlo de saída é

determinada pela avaliação da sua condição de guarda. A condição de guarda deve ser

colocada entre parênteses rectos numa etiqueta associada à ligação de controlo.

Opcionalmente uma (e só uma) das ligações de controlo pode ser condicionada pela

guarda ‘otherwise’. Os nós de fusão recebem várias ligações de controlo de entrada e

têm apenas uma ligação de controlo de saída.

Em UML, um nó de decisão apenas pode ter uma ligação de controlo de entrada

e um nó de fusão apenas pode ter uma ligação de controlo de saída. Se um losango for

desenhado tendo várias ligações de controlo de entrada e de saída, então é interpretado

como sendo um nó de fusão seguido de um de decisão. Isto significa que, para

representar a sincronização de actividades concorrentes antes de um nó decisão é

Francisco Santos 17


necessário usar um nó de junção, e para representar actividades concorrentes após um

nó de fusão torna-se necessário usar um nó de difusão.

O nó de difusão (fork) permite modelar um fluxo de execução singular que se

separa em dois ou mais fluxos de execução concorrentes. Todavia, o número de nós de

difusão presentes no diagrama deve ser compensado por igual número de nós de junção.

Uma junção (join) consiste em dois ou mais fluxos de execução concorrentes que se

juntam num único fluxo de execução. Todas as actividades que se encontrem entre uma

difusão e uma junção devem completar a sua execução antes dos fluxos de execução se

unirem num só fluxo. O processo de ‘Marketplace’, ilustrado na Figura 2.6, demonstra a

utilização de uma junção antes de uma decisão (barra sólida) e uma difusão (também

representada por uma barra sólida) depois da fusão.

O comportamento de um nó de decisão pode ser alcançado colocando guardas

nas várias transições de saída de uma actividade. Por questões de clareza, é

recomendável introduzir um nó de decisão sempre que seja feita uma escolha

mutuamente exclusiva, Figura 2.6. Quando é usado um nó de decisão, sabe-se que

apenas uma das suas transições de saída pode ser executada. Por este motivo, é

necessário que a escolha a partir do nó decisão seja mutuamente exclusiva. Quando são

usadas transições de saída com guarda, é possível que mais do que uma condição seja

verdadeira, tornando activas todas as transições onde isto se verifique.

Francisco Santos 18


Receber Proposta Comprador

Receber Preço Vendedor

Enviar Artigo ao Comprador

[ preço venda <= oferta compra ]

Devolver Artigo ao Vendedor

[ otherwise ]

Enviar Resultado Negociação ao Comprador

Enviar Resultado Negociação ao Vendedor

Figura 2.6 – Utilização explícita de nós de difusão e de junção

2.1.2.4 Fluxo de Objectos

O fluxo de objectos é uma técnica usada para modelar a forma como os objectos

participam em actividades e a forma como são afectados por elas. Na Figura 2.7 é

ilustrado um exemplo de um diagrama de actividades que contém um fluxo de objectos.

Neste caso um objecto do tipo ‘Encomenda’ é recebido pela actividade ‘Receber

Encomenda’, que é responsável por alterar o seu estado para ‘processada’. A actividade

‘Produzir Produto’ recebe a encomenda processada e produz um objecto do tipo

‘Produto’. O fluxo de execução termina com a emissão do objecto do tipo ‘Factura’.

Os fluxos de objectos são representados por uma seta a tracejado e ligam,

obrigatoriamente, objectos a actividades ou actividades a objectos. Quando a seta parte

do objecto em direcção à actividade, trata-se de um objecto de entrada. Quando a seta

parte da actividade em direcção ao objecto, trata-se de um objecto de saída. No caso de

haver um fluxo de objectos entre duas actividades está implicitamente definida uma

transição (representada por uma seta a cheio) entre essas duas actividades.

Francisco Santos 19


Receber Encomenda

Produzir Produto

Verificar Produto

Emitir Factura

: Encomenda : Encomenda[processada]

: Produto : Produto[verificado]

: Factura

Figura 2.7 – Diagrama de Actividades com fluxo de objectos

2.1.2.5 Pistas

As pistas (swimlanes) agrupam actividades de acordo com a sua responsabilidade.

Podem ser usadas para diferentes propósitos, como sendo mostrar em que objecto são

executadas as actividades, ou que parte da organização é responsável pela sua execução.

As pistas são representadas por rectângulos verticais no diagrama de actividades e as

actividades que fazem parte dessa pista são colocadas dentro do rectângulo. É atribuído

um nome à pista, que é colocado no topo do rectângulo. No âmbito organizacional

interpretam-se fluxos de objectos que partem de uma pista em direcção a outra como

troca de recursos (objectos) entre unidades organizacionais.

No exemplo da Figura 2.8 é ilustrado um processo de recepção de encomendas

com passagem de recursos entre as unidades da empresa e o cliente. O cliente efectua

uma encomenda, logo a origem do objecto do tipo ‘Encomenda’ é o ‘Cliente’. Após o

processamento da encomenda, o envio da factura e o início da produção do produto são

actividades concorrentes. O objecto do tipo ‘Factura’ é produzido pelo ‘Dep.

Comercial’ e é enviado ao ‘Cliente’ através da actividade ‘Enviar Factura’. Após a

recepção do pagamento e da finalização do produto, este é enviado ao cliente através da

actividade ‘Enviar Produto’.

Francisco Santos 20


Efectuar Encomenda

Efectuar Pagamento

Receber Produto

Processar Encomenda

Enviar Produto

Enviar Factura

Receber Pagamento

Produzir Produto

: Factura

: Produto[enviado]

: Encomenda

: Pagamento

: Encomenda[processada]

: Produto

Dep. ProduçãoDe lp. ComerciaCl eient Cliente Dep. Comercial Dep. Produção

Figura 2.8 – Diagrama de Actividades com fluxo de objectos e pistas

Francisco Santos 21


3 BPEL4WS Esta linguagem define um modelo e uma gramática para a descrição do comportamento

de um processo de negócio, baseado nas suas interacções com os parceiros de negócio.

A interacção com cada parceiro de negócio é feita através da interface de Web Services.

A estrutura de cada interacção encontra-se encapsulada por uma ligação a um parceiro

de negócio (partner link).

O processo BPEL4WS define como é que as múltiplas interacções com os

parceiros de negócio são coordenadas de forma a satisfazer um dado objectivo de

negócio, para além de descrever o estado e a lógica necessários a uma dada interacção.

3.1 Relação com o WSDL

O modelo de processos é suportado pelo modelo de serviços definido na especificação

WSDL 1.1. No núcleo do modelo de processos BPEL4WS existe a noção de interacção

ponto-a-ponto entre serviços, descrita em WSDL; tanto o processo como os seus

parceiros encontram-se modelados em WSDL. Um processo de negócio define como

deve ser feita a coordenação entre a instância do processo e os seus parceiros. Neste

sentido, uma definição particular de um processo BPEL4WS fornece e/ou utiliza um ou

mais serviços WSDL. Adicionalmente, descreve o comportamento e as interacções entre

a instância do processo e os parceiros de negócio, através da interface de Web Services.

Por outras palavras, a linguagem BPEL4WS define os protocolos de troca de mensagens

e, seguidamente, define o processo de negócio para um papel específico na interacção

entre parceiros.

Na definição de um processo BPEL4WS as mensagens e os tipos de portos

encontram-se separados da ligação (binding) aos serviços e informação de

endereçamento na rede, tal como é descrito no modelo WSDL. Em particular, o

processo BPEL4WS descreve os parceiros e respectivas interacções através de

interfaces WSDL abstractas (i.e. recorrendo apenas a operações e tipos de portos), não

sendo especificadas as ligações concretas aos serviços usados pela instância do

processo.

Francisco Santos 22


3.2 Definição de um Processo de Negócio

Antes de abordar a estrutura detalhada de um processo, definido na linguagem

BPEL4WS, é usado o exemplo já introduzido na Secção 2.1, que ilustra um processo de

recepção de encomendas de uma empresa. Neste caso, o exemplo será usado para

apresentar as principais estruturas e conceitos da linguagem BPEL4WS. De seguida, é

apresentada uma descrição mais detalhada dos elementos constituintes da linguagem.

Na Figura 3.1 é modelado o processo de recepção de encomendas. Neste

diagrama, recorre-se a conceitos mais próximos da linguagem BPEL4WS: os

rectângulos a tracejado representam sequências; os losangos seguidos de uma barra

horizontal representam conjuntos de actividades de execução concorrente; as setas a

tracejado representam ligações de controlo, usadas para sincronizar actividades

concorrentes. É importante notar que este diagrama não faz parte da especificação da

BPEL4WS, sendo apenas usado, informalmente, para melhor compreender o processo

descrito no exemplo.

Receber Encomenda

Calcular Preço Encomenda

Processar Preço Entrega

Gerar Factura

Gerar Pedido Entrega

Requisitar Entrega

Receber Prazo Entrega

Pedir Escalonamento Producao

Finalizar Escalonamento Producao

Fluxo1

Enviar Factura

Seq

uenc

ia1

Seq

uenc

ia2

Seq

uenc

ia3

Ligação de controlo

Receber Encomenda

Calcular Preço Encomenda

Processar Preço Entrega

Gerar Factura

Gerar Pedido Entrega

Requisitar Entrega

Receber Prazo Entrega

Pedir Escalonamento Producao

Finalizar Escalonamento Producao

Fluxo1

Enviar Factura

Seq

uenc

ia1

Seq

uenc

ia2

Seq

uenc

ia3


Figura 3.1 – Processo de Recepção de Encomendas

Francisco Santos 23


3.2.1 Especificação do Serviço Associado ao Processo

No documento WSDL é feita a descrição do serviço associado ao processo de negócio.

Este documento descreve o formato das mensagens trocadas, os tipos de portos e os

tipos de ligações aos parceiros de negócio.

A definição abstracta do processo é feita apenas com base nos tipos de portos

para os serviços envolvidos no processo, independentemente da sua localização na rede.

Isto permite a utilização das definições do processo para múltiplas disposições dos

serviços na rede, sendo apenas exigida a sua compatibilidade com os tipos de portos

definidos.

O documento WSDL para a especificação do serviço contém as seguintes

definições:

• As mensagens (<message>): que são uma definição abstracta,

tipificada, para os dados usados nas operações do serviço.

• As operações (<operation>): que são uma descrição abstracta das

acções suportadas pelo serviço.

• Os tipos de portos (<portType>): representam colecções abstractas

das operações suportadas por um ou mais pontos terminais.

• Os tipos de ligações aos parceiros de negócio

(<partnerLinkType>): que descrevem as interacções com os

parceiros de negócio.

Os tipos de ligação aos parceiros de negócio (partner link types) podem ser

usados para representar as dependências entre serviços, independentemente de existirem

processos BPEL4WS associados a esses serviços. Cada tipo de ligação define até dois

nomes de papéis, explicitando para cada papel quais os tipos de portos que necessitam

ser suportados pelo serviço para que a interacção se realize com êxito.

Neste exemplo são definidos dois tipos de ligações a parceiros de negócio com

apenas um papel: ‘encomendar’ e ‘fabricar’. A existência de apenas um papel deve-se

ao facto de, nos dois casos, apenas uma das entidades envolvidas na interacção fornecer

as operações a invocar. A ligação ‘encomendar’ representa a interacção entre o serviço

de encomendas e o cliente, onde apenas são executadas operações do primeiro serviço

Francisco Santos 24


(ver Apêndice A – Ficheiro WSDL Protocolo Encomendar). A ligação ‘fabricar’

representa a interacção entre o serviço de encomendas e o serviço de escalonamento da

produção, onde apenas são invocadas operações do último. Os outros dois tipos de

ligações: ‘facturar’ e ‘enviar’, definem dois papéis cada. Tanto o serviço de cálculo do

valor da encomenda como o serviço de envio necessitam disponibilizar operações

callback de forma a permitir o envio de notificações assíncronas (tipos de portos:

‘ICallbackFacturacao’ e ‘ICallbackDistribuicao’ respectivamente).

3.2.2 Especificação Funcional do Processo

A estrutura das actividades do processo é descrita no documento BPEL, que está

separado da definição do serviço. Neste documento, escrito em XML, é descrita a forma

do processo armazenar os dados, a ordem de execução das actividades, a sequência e a

forma como devem ser contactados os parceiros de negócio e o procedimento a seguir

caso ocorra uma falha durante a execução.

Este documento encontra-se estruturado em quatro secções:

• A secção <variables> define as variáveis, que irão conter os dados

usados pelo processo, em termos de: tipos de mensagens WSDL, tipos

simples XML Schema e tipos compostos XML Schema.

• A secção <partnerLinks> define como é que os parceiros de

negócio interagem com o processo. No exemplo os parceiros associados

ao processo são: a entidade que efectua a encomenda, a entidade que

calcula o preço, a entidade responsável pelo envio e a entidade

responsável pelo escalonamento da produção.

• A secção <faultHandlers> descreve o procedimento para o

tratamento das faltas resultantes da execução do processo através de uma

sequência de actividades.

• A restante parte do documento contém a descrição do funcionamento

normal do processo. As actividades que fazem parte da descrição

funcional do processo encontram-se apresentadas a seguir.

Francisco Santos 25


Cada actividade de um processo BPEL4WS contém opcionalmente um nome e

os elementos aninhados: <source> e <target>. Estes dois elementos aninhados são

usados para criar ligações de controlo, que determinam a ordem de execução das

actividades de um processo. Cada ligação de controlo possui um nome e é definida

independentemente das outras. Define-se que uma actividade é origem de uma ou mais

ligações de controlo através da inclusão de um ou mais elementos <source>.

Analogamente, define-se que uma actividade é alvo de uma ou mais ligações de

controlo, através da inclusão de um ou mais elementos <target>. Todos os elementos

<source> associados a uma actividade têm de possuir um nome distinto.

Semelhantemente, todos os elementos <target> associados a uma actividade

precisam de nomes distintos. As principais actividades de um processo encontram-se

descritas na Tabela 3.1.

Actividade Elemento XML Descrição

BPELReceive <receive> Permite ao processo bloquear-se à espera da

recepção de um dado tipo de mensagem.

BPELReply <reply> Permite ao processo responder a uma mensagem

recebida através da actividade <receive>. A

combinação <receive> <reply> forma uma

operação bidireccional (síncrona) para um dado

tipo de porto do processo.

BPELInvoke <invoke> Permite ao processo invocar operações

unidireccionais (assíncronas) e bidireccionais

(síncronas) através de um tipo de porto

disponibilizado por um parceiro de negócio.

BPELAssign <assign> É usada para actualizar os valores das variáveis

com dados novos, podendo conter um número

arbitrário de atribuições elementares.

BPELThrow <throw> Permite gerar uma falta a partir do interior do

processo.

Francisco Santos 26


Actividade Elemento XML Descrição

BPELWait <wait> Permite esperar um determinado período de tempo,

sendo tipicamente usada para executar uma

operação a um dado instante no tempo.

BPELEmpty <empty> Permite inserir uma instrução nula no processo,

sendo útil para sincronizar actividades

concorrentes.

BPELSequence <sequence> Permite definir um conjunto de actividades a ser

executadas sequencialmente.

BPELSwitch <switch> Permite seleccionar exactamente um ramo de

execução a partir de um conjunto de opções.

BPELWhile <while> Permite repetir a execução de uma outra actividade

até que uma dada condição seja verdadeira.

BPELFlow <flow> Permite especificar uma ou mais actividades a ser

executadas concorrentemente. Podem ser usadas

ligações de controlo para determinar a ordem de

execução de um subconjunto das actividades

contidas no fluxo. Tabela 3.1 – Principais actividades de um processo BPEL4WS

No exemplo, a estrutura principal do processo encontra-se caracterizada pelo

elemento <sequence>, que define a ordem de execução das actividades constituintes

como sendo sequencial (ver Apêndice B – Ficheiro BPEL Processo). A encomenda do

cliente é recebida (elemento <receive>), depois é processada (elemento <flow>,

que permite a execução concorrencial das actividades constituintes) e, finalmente, é

enviada a resposta ao cliente (elemento <reply>).

Neste caso, foi utilizado um modelo de comunicação síncrono. Assume-se,

portanto, que o tempo de processamento é suficientemente curto para permitir que o

invocador do serviço espere por uma resposta síncrona ao seu pedido. Alternativamente,

podia ser usado um modelo de comunicação assíncrono. Para implementar este modelo

de comunicação, é necessário modificar a operação ‘enviarPedidoEncomenda’ para que

Francisco Santos 27


seja unidireccional e a resposta ao pedido de encomenda passa a ser enviada através de

uma segunda operação na interface callback do cliente. Para representar a interface

callback do cliente são necessárias duas modificações adicionais. Em primeiro lugar, a

ligação entre o processo e o cliente, ‘encomendar’, necessita de um papel adicional,

‘ClienteEncomenda’, contendo o tipo de porto para a interface callback do cliente.

Finalmente, a actividade <reply> no processo deve ser substituída pela actividade

<invoke>, com o objectivo de invocar a operação de envio de resposta, definida na

interface callback do cliente.

Dentro do elemento <flow> existem três blocos do tipo <sequence>, que se

executam concorrentemente. A sincronização entre as actividades contidas nos três

blocos <sequence> é feita através de ligações de controlo, descritas no início do

bloco <flow>. Na ausência de ligações de controlo as actividades dentro do fluxo são

executadas concorrentemente. No exemplo, a existência de duas ligações de controlo

determina a ordem de execução das actividades contidas em cada sequência. O cálculo

do preço da encomenda pode começar logo após a recepção do pedido por parte do

cliente. No entanto, o preço de envio só pode ser adicionado à encomenda depois do

distribuidor ter sido seleccionado; esta dependência é representada pela ligação

‘pedirEntrega-to-enviarPrecoEntrega’, que liga a invocação da operação ‘pedirEntrega’,

para a escolha do distribuidor, à invocação da operação ‘enviarPrecoEntrega’, que

remete o preço de envio para o serviço de facturação. Analogamente, a informação

sobre o prazo de envio da encomenda só pode ser enviada ao serviço de escalonamento

da produção depois de ter sido recebida do serviço do distribuidor; esta dependência é

representada pela ligação ‘receberPrazoEntrega-to-enviarPrazoEntrega’.

Os dados são passados entre as actividades, de uma forma implícita, através da

partilha de variáveis globais. Neste exemplo, as ligações de controlo de execução das

actividades estão relacionadas com as dependências de dados correspondentes. Existe

uma dependência associada à informação sobre o preço de envio e outra associada à

informação sobre o prazo de entrega da encomenda. A informação é transferida entre a

actividade que a cria para a actividade que consome através de duas varáveis globais:

‘informacaoEntrega’ e ‘prazoEntrega’.

Francisco Santos 28


Certas operações podem retornar faltas, tal como especificado no documento

WSDL. Para simplificar, no exemplo é assumido que as duas operações retornam a

mesma falta: ‘impossivelFinalizarEncomenda’. Quando ocorre uma falta, termina o

processamento normal e o controlo de execução é transferido para o tratador de faltas

correspondente, tal como definido na secção <faultHandlers> do documento

BPEL. Neste exemplo, o tratador de faltas usa um elemento do tipo <reply> para

enviar a falta ao cliente (observe a presença do atributo para o nome da falta,

‘faultName’, neste elemento <reply>).

Finalmente, é importante notar a forma como a actividade de atribuição,

<assign>, é usada para transferir dados entre variáveis distintas. As atribuições

ilustradas neste exemplo servem para transferir a secção de uma mensagem, guardada

numa variável origem, para a secção de uma outra mensagem, guardada numa variável

destino. Para além das atribuições simples do exemplo é possível definir atribuições

mais complexas nesta linguagem.

Francisco Santos 29


4 Conversão entre FCEO e BPEL4WS De forma a tornar possível a conversão dos modelos FCEO em modelos BPEL4WS

executáveis é necessário estender o perfil UML, definido na FCEO. Nesta Secção são

descritas as extensões introduzidas à framework, adequadamente justificadas, bem como

a conversão entre os artefactos dos modelos FCEO e BPEL4WS.

4.1 Extensão ao Perfil UML da FCEO

O perfil UML, definido actualmente na FCEO, não permite uma conversão automática

para a BPEL4WS. Não é possível identificar, de forma clara, quais são os parceiros de

negócio, quais as operações suportadas pelos parceiros e qual o papel que cada parceiro

desempenha na interacção com o processo. Adicionalmente, não é possível distinguir

entre as actividades de espera, atribuição, recepção, resposta e invocação (i.e. wait,

assign, receive, reply e invoke) da BPEL, não é possível especificar qual o formato das

mensagens trocadas entre os parceiros e o processo e não é possível definir a forma de

encaminhar as mensagens entre diferentes instâncias dos processos comunicantes. Para

colmatar os problemas identificados são descritas as alterações necessárias ao actual

perfil UML da FCEO, recorrendo ao perfil proposto em [AGGI03].

O diagrama de actividades apresentado na Figura 4.1 fornece uma vista global

do processo para a recepção de encomendas. Ao contrário do diagrama da Figura 2.2,

este foi concebido para permitir a conversão para a linguagem BPEL4WS. Em resumo,

este diagrama mostra que o processo possui quatro ligações a parceiros de negócio:

‘encomendar’, ‘enviar’, ‘facturar’ e ‘fabricar’, que estão representados pelas pistas. As

actividades que envolvem uma operação de recepção ou envio de mensagens, através de

uma ligação a um determinado parceiro de negócio, aparecem na pista correspondente.

Francisco Santos 30


receberEncomenda<<receiv e>>

env iarFactura<<reply >>

inicializarPedidoEntrega<<assign>>

pedirEntrega<<inv oke>>

receberPrazoEntrega<<receiv e>>

env iarPrecoEntrega<<inv oke>>

receberFactura<<receiv e>>

calcularPreco<<inv oke>>

pedirEscalonamentoProducao<<inv oke>>

env iarPrazoEntrega<<inv oke>>

Fa rbricaFacturarEnviarEncomendar encomendar enviar facturar fabricar

Figura 4.1 – Diagrama de Actividades para o Processo Receber Encomenda

Os tipos de dados devem ser representados através de classes UML com o

estereótipo <<data>>, conforme ilustrado na Figura 4.2. Estes tipos de dados podem

ser usados directamente pelas operações das interfaces dos protocolos de negócio ou,

alternativamente, como parte de mensagens mais complexas (ex.: ‘PedidoEntrega’ e

‘Encomenda’). Todos os tipos de dados base foram colocados no pacote

‘DefinicoesEncomenda’. As mensagens, que são definidas à custa dos tipos de dados

base, também se encontram definidas no mesmo pacote. Por exemplo, a mensagem

‘Encomenda’ é composta por dois tipos de dados base: ‘Cliente’, que contém

informação sobre o cliente, e ‘LinhaEncomenda’, que contém informação sobre os

vários produtos que foram encomendados.

Francisco Santos 31


Clientenome : Stringmorada : String

<<data>>

PedidoEntrega<<messageContent>>

+cliente

EncomendaFaultdescricaoProblema : String

<<messageContent>>Factura

eid : Stringinput : String

<<messageContent>>InformacaoEntregaeid : Stringinput : String

<<messageContent>>PrazoEntrega

eid : Stringinput : String

<<messageContent>>

Encomendaeid : String

<<messageContent>>

+cliente LinhanomeProduto : Stringquantidade : IntegerprecoUnitario : Float

<<data>>

LinhaEncomenda<<data>>

+linhaEncomenda

1..n1..n

Figura 4.2 – Tipos de Dados e Mensagens

O processo participa num protocolo através das ligações aos parceiros de

negócio. Um protocolo liga um par de papéis complementares, associados a cada um

dos parceiros, e especifica como é que esses papéis interagem. Cada papel disponibiliza,

opcionalmente, um conjunto de interfaces através das quais o papel complementar pode

interagir. As interfaces juntamente com os papéis complementares encontram-se

definidas em pacotes próprios com o estereótipo <<protocol>>. Na Figura 4.3 são

apresentados os protocolos de negócio, os papéis e as interfaces.

Francisco Santos 32


Encomendar<<protocol>>

ClienteEncomenda<<role>>

ServicoEncomenda<<role>>

IServicoEncomenda

enviarPedidoEncomenda()

Enviar<<protocol>>

ClienteDistribuicao<<role>>

ServicoDistribuicao<<role>>

ICallbackDistribuicao

enviarPrazoEntrega()

IServicoDistribuicao

pedirEntrega()

Fabricar<<protocol>>

ClienteProducao<<role>>

ServicoProducao<<role>>

IServicoProducao

pedirEscalonamentoProducao()enviarPrazoEntrega()

Facturar<<protocol>>

IServicoFacturacao

iniciarCalculoPreco()enviarPrecoEntrega()

ICallbackFacturacao

enviarFactura()

ClienteFacturacao<<role>>

ServicoFacturacao<<role>>

Figura 4.3 – Protocolos de Negócio, Papéis e Interfaces

Nesta fase, todas as definições necessárias ao processo foram fornecidas.

Embora estas definições tenham sido introduzidas no contexto do processo recepção de

encomendas, podem ser usadas independentemente do processo. Se os parceiros

também forem modelados como processos de negócio automatizados, então também

podem fazer uso destas definições. Mais genericamente, outros processos que

disponibilizem todos ou apenas uma parte dos papéis do processo recepção de

encomendas podem fazer uso destas definições.

Na Figura 4.4 é apresentada a classe ‘ProcessoReceberEncomenda’, com o

estereótipo <<process>>, que representa o processo recepção de encomendas. O

estado do processo é descrito pelos atributos da classe ‘ProcessoReceberEncomenda’,

cujos tipos de dados foram introduzidos no pacote ‘Encomenda’ ou importados do

pacote ‘DefinicoesEncomenda’. Adicionalmente possui quatro associações a papéis de

negócio, correspondentes aos quatros parceiros com os quais interage, definidos nos

pacotes <<protocol>> da Figura 4.3.

Francisco Santos 33


ServicoEncomenda(from Encomendar)

<<role>>

ClienteFacturacao(from Facturar)

<<role>>

ClienteProducao(from Fabricar)

<<role>> ClienteDistribuicao(from Enviar)

<<role>>

ProcessoReceberEncomendaencomenda : Encomendafactura : FacturaencomendaFault : EncomendaFaultprazoEntrega : PrazoEntregainformacaoEntrega : InformacaoEntregapedidoEntrega : PedidoEntrega

<<process>>

1+encomendar 1<<partnerLink>>

1+facturar

1

<<partnerLink>>

1+fabricar

1

<<partnerLink>>

1+enviar

1

<<partnerLink>>

Figura 4.4 – Processo Recepção de Encomendas

Cada ligação a um parceiro de negócio constitui um ponto de ligação para um

parceiro do processo. As interfaces, que são disponibilizadas ou solicitadas através de

uma ligação, estão definidas pelo papel que o processo desempenha no protocolo. Uma

ligação a um parceiro de negócio é representada por uma associação, com o estereótipo

<<partnerLink>>, entre o processo e o papel que este desempenha.

O ‘ProcessoReceberEncomenda’ disponibiliza a sua interface

‘IServicoEncomenda’ através da ligação ‘encomendar’, correspondente ao protocolo

‘Encomendar’, e solicita serviços através das restantes ligações: ‘facturar’, ‘fabricar’ e

‘enviar’. A ligação ‘facturar’ suporta comunicação bidireccional: o processo solicita a

interface ‘IServicoFacturacao’ e disponibiliza a interface ‘ICallbackFacturacao’, tal

como especificado pelo papel ‘ClienteFacturacao’ do protocolo ‘Facturar’. A ligação

‘enviar’ também é bidireccional, neste caso o processo solicita a interface

‘IServicoDistribuicao’ e disponibiliza a interface ‘ICallbackDistribuicao’.

O diagrama de actividades na Figura 4.5 mostra o comportamento do processo

recepção de encomendas, fazendo parte da classe ‘ProcessoReceberEcomenda’. É

idêntico ao diagrama da Figura 4.1 excepto que exibe um maior nível de detalhe. Cada

pista do diagrama corresponde a uma ligação a um parceiro de negócio. Actividades que

Francisco Santos 34


representem uma interacção através de um porto, seja de entrada ou de saída, associado

a um determinado parceiro de negócio, são colocadas na pista respectiva, com setas de

controlo de fluxo a indicar a sua sequência de execução. Cada actividade é identificada

por um nome descritivo. As acções de entrada, representadas por um evento do tipo

entry, descrevem o trabalho realizado numa dada actividade.

receberEncomenda<<receiv e>>

entry / env iarPedidoEncomenda(encomenda)

env iarFactura<<reply >>

entry / env iarPedidoEncomenda() := f actura

inicializarPedidoEntrega<<assign>>

entry / pedidoEntrega/inf Cliente := encomenda/inf Cliente

pedirEntrega<<inv oke>>

entry / inf ormacaoEntrega := pedirEntrega(pedidoEntrega)

receberPrazoEntrega<<receiv e>>

entry / env iarPrazoEntrega(prazoEnt...

env iarPrecoEntrega<<inv oke>>

entry / env iarPrecoEntrega(inf ormacaoEn...

receberFactura<<receiv e>>

entry / env iarFactura(f actura)

calcularPreco<<inv oke>>

entry / iniciarCalculoPreco(encomenda)

pedirEscalonamentoProducao<<inv oke>>

entry / pedirEscalonamentoProducao(encomenda)

env iarPrazoEntrega<<inv oke>>

entry / env iarPrazoEntrega(prazoEnt...

FabricarFacturarEnviarEncomendar encomendar enviar facturar fabricar

Figura 4.5 – Diagrama de Actividades detalhado para o Processo Receber Encomenda

A actividade ‘receberEncomenda’ contém o estereótipo <<receive>>,

tratando-se, por isso, da recepção de uma mensagem através de uma ligação, neste caso

da ligação ‘encomendar’. A expressão:

enviarPedidoEncomenda(encomenda)

indica o nome da operação a invocar, através da ligação ‘encomendar’, e o nome do

atributo onde a mensagem recebida é guardada. A actividade ‘enviarFactura’ possui o

estereótipo <<reply>> indicando que o resultado deve ser enviado ao invocador da

anterior actividade <<receive>>. Ambas as actividades fazem referência à mesma

operação: ‘enviarPedidoEncomenda’, sendo que a actividade de recepção especifica o

Francisco Santos 35


atributo no qual a mensagem recebida deve ser guardada e a actividade de resposta

especifica o atributo a partir do qual a mensagem de resposta deve ser criada. A

expressão:

enviarPedidoEncomenda() := factura

indica que o valor do atributo ‘factura’ deve constituir a resposta à operação

‘enviarPedidoEncomenda’. As actividades ‘pedirEntrega’ e

‘pedirEscalonamentoProducao’ possuem o estereótipo <<invoke>>, indicando que

invocam uma operação através de um porto. A actividade

‘pedirEscalonamentoProducao’ não especifica o atributo de resposta, pelo que se trata

de uma actividade assíncrona (unidireccional). A expressão:

pedirEscalonamentoProducao(encomenda)

indica que a operação ‘pedirEscalonamentoProducao’ é invocada com o valor do

atributo ‘encomenda’. A actividade ‘pedirEntrega’, por sua vez, é síncrona

(bidireccional). A expressão:

informacaoEntrega := pedirEntrega(pedidoEntrega)

indica que a operação ‘pedirEntrega’ deve ser invocada, tendo como parâmetro o valor

do atributo ‘pedidoEntrega’. Na actividade ‘inicializarPedidoEntrega’ não é feita

qualquer interacção com parceiros de negócio, sendo apenas copiado o valor de uma

variável para outra. O operador ‘:=’ é usado na atribuição de valores.

Tal como na linguagem BPEL4WS, a passagem dos dados neste exemplo é feita

recorrendo a variáveis no ambiente do processo, que no modelo UML são representadas

através dos atributos da classe do processo. Por exemplo, a actividade

‘receberEncomenda’ recebe um valor, através da ligação ‘encomendar’, que é guardado

na variável ‘encomenda’, sendo depois lida pela actividade

‘pedirEscalonamentoProducao’ e depois usada como parâmetro de entrada na operação

invocada por essa actividade.

Francisco Santos 36


4.2 Delineação do Processo de Conversão UML BPEL

Pretende-se nesta Secção delinear o processo de conversão UML para BPEL. As classes

com o estereótipo <<data>> contém a definição dos tipos de dados usados no âmbito

do negócio. Por exemplo: a entidade de informação ‘cliente’ tem os seguintes atributos:

‘nome’, representado por uma cadeia de caracteres, e ‘morada’, igualmente

representado por uma cadeia de caracteres. Os tipos de dados são convertidos em

representações equivalentes no formato XML Schema Definition (XSD). As mensagens,

representadas através de classes com o estereótipo <<messageContent>>, fazem

uso dos anteriores tipos de dados, juntamente com os tipos de dados elementares XSD,

para definir o seu conteúdo. Estas mensagens são usadas para trocar informação entre o

processo e os parceiros de negócio. O resultado da conversão destas classes é colocado

num documento WSDL, que é importado por todos os protocolos de negócio. Para cada

protocolo, contido num pacote <<protocol>>, é definida uma ligação a um parceiro

de negócio. A ligação contém dois papéis complementares, sendo que um é

desempenhado pelo processo e o outro pelo parceiro. Os papéis definem a interface das

operações que podem ser executadas por cada entidade comunicante. Cada protocolo é

colocado num ficheiro WSDL separado. Para cada processo de negócio, descritos

através das classes com o estereótipo <<process>>, é gerado um ficheiro BPEL.

Todos os ficheiros WSDL, correspondentes aos protocolos onde o processo participa,

são importados por este ficheiro. Na Figura 4.6 é ilustrado o esquema dos documentos

XML gerados pelo processo de conversão.

Francisco Santos 37


WSDL

Mensagens

XSD

Tipos de dados

WSDL

Protocolo de negócio

WSDL


BPEL

Processo de negócio

…

importação

WSDL

Mensagens

XSD

Tipos de dados

WSDL


WSDL


BPEL

Processo de negócio

…

importação Figura 4.6 – Esquema dos Documentos XML gerados pelo Processo de Conversão

Francisco Santos 38


4.3 Organização do Espaço Nomes

A organização do espaço nomes e a definição de unidades reutilizáveis do modelo é

feita recorrendo ao diagrama de pacotes do UML. As dependências no espaço de nomes

são representadas através das dependências de importação do UML.

DefinicoesEncomenda

Facturar<<protocol>>

Enviar<<protocol>>

Fabricar<<protocol>>

Encomendar<<protocol>>

ReceberEncomenda

<<import>><<import>> <<import>>

<<import>> <<import>> <<import>> <<import>>

<<import>>

Figura 4.7 – Exemplo de Dependência entre Pacotes

4.3.1 Notação

Os pacotes são usados para agrupar elementos e para criar um espaço de nomes. Em

UML, as dependências entre pacotes são designadas permissões. As dependências entre

pacotes são representadas recorrendo à seta de permissão do tipo <<import>>, tal

como ilustrado na Figura 4.8. A utilização da importação permite ao pacote que faz

importação referenciar os elementos, contidos no pacote importado, sem que seja

necessário usar nomes qualificados. Por exemplo, se a ‘classe X’ estiver definida no

‘Pacote1’, então o ‘Pacote2’ pode referenciar a ‘classe X’ directamente, sem ter de usar

o nome qualificado ‘Pacote1::X’.

Francisco Santos 39


Pacote1

Pacote2

<<import>>

Figura 4.8 – Notação para o pacote e para a dependência entre pacotes

4.3.2 Geração dos Ficheiros XSD, WSDL e BPEL

A hierarquia de pacotes de um modelo corresponde a uma hierarquia de espaços de

nome em XML. O nome do modelo em si (pacote de topo) também contribui para o

espaço de nomes. O prefixo para o espaço de nomes, usado nos ficheiros XML gerados,

é especificado durante o processo de conversão. A estrutura dos directórios onde os

ficheiros gerados serão colocados corresponde à hierarquia de espaços de nomes

definida anteriormente. Finalmente, a dependência <<import>> entre pacotes

corresponde à importação de um espaço de nomes em XML.

Os protocolos de negócio encontram-se definidos nos pacotes do tipo

<<protocol>>, dando origem à geração dos ficheiros WSDL correspondentes.

Nestes ficheiros encontram-se definidas as ligações aos parceiros de negócio, os papéis

complementares da interacção e os portos que o processo e o parceiro deverão

implementar para que o protocolo se realize. A cada processo do modelo corresponderá

um ficheiro BPEL, contendo a descrição do processo na linguagem executável. A

participação do processo nos protocolos de negócio pode ser feita com o papel de

cliente ou com o papel de serviço. Todas as operações suportadas pelo papel de serviço

devem ser implementadas pelo processo BPEL. A inclusão de mais de um processo por

pacote não é suportada pelo perfil.

No exemplo apresentado na Figura 4.7 é gerado um ficheiro XML Schema

Definition (XSD) [FW04] contendo os tipos de dados base que resultam da conversão

Francisco Santos 40


das classes <<data>> compreendidas no pacote ‘DefinicoesEncomenda’. As

mensagens que dependem destes tipos de dados e os conjuntos de correlação, usados no

diálogo entre processos assíncronos, são descritos num ficheiro WSDL.

Para cada protocolo é gerado um ficheiro WSDL com os papéis suportados. Para

cada papel é disponibilizado um conjunto de interfaces através das quais o papel

complementar pode interagir. As interfaces, por sua vez, definem um conjunto de

operações suportadas bem como os tipos de mensagens, de entrada e saída, associadas a

cada operação. O pacote ‘ReceberEncomenda’ contém um processo, representado por

uma classe do tipo <<process>>, de nome ‘ProcessoReceberEncomenda’, ver Figura

4.4. Durante a conversão é gerado um ficheiro BPEL com ligações aos protocolos de

negócio onde o processo participa: ‘Facturar’, ‘Encomendar’, ‘Fabricar’ e ‘Enviar’. O

processo implementa o papel de serviço no protocolo ‘Encomendar’, pelo que

implementa a funcionalidade das operações definidas nas interfaces deste papel.

O espaço de nomes é construído com base num prefixo, nome do modelo,

seguido da hierarquia de pacotes usada. Por exemplo, para o caso do

‘ProcessoReceberEncomenda’, contido no pacote ‘ReceberEncomenda’ e para um

prefixo: ‘http://www.example.org’, o nome qualificado corresponde a: http://www.example.org/ProcessamentoEncomendas/ReceberEncomenda/ProcessoReceberEncomenda

Analogamente, o nome qualificado correspondente ao documento ‘TiposDados’,

contido no pacote ‘DefinicoesEncomenda’ é dado por: http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda/TiposDados

A estrutura de directórios espelha a hierarquia do espaço de nomes, definida

anteriormente, tendo como raiz um directório com o nome do modelo:

‘ProcessamentoEncomendas’, e como sub-directórios os vários pacotes definidos.

4.4 Conversão dos Tipos de Dados e Mensagens

É possível converter, automaticamente, os tipos de dados e as mensagens em UML para

o formato XSD/WSDL, recorrendo a um conjunto de regras. No perfil, os tipos de

dados são definidos através de classes com o estereótipo <<data>>. Por sua vez, as

Francisco Santos 41


mensagens são definidas através das classes com o estereótipo

<<messageContent>>. Como resultado da conversão devem ser criados dois

ficheiros. No ficheiro XSD deverão ser colocados os tipos de dados e no ficheiro WSDL

deverão ser colocadas as mensagens. A separação entre os dois documentos permite

aumentar a modularidade da solução, reutilizar os mesmos tipos de dados base em

outros projectos, usar esquemas já existentes e facilitar a manutenção do projecto.

4.4.1 Geração dos Ficheiros XSD e WSDL

Todas as classes com o estereótipo <<data>> são convertidas num tipo composto:

complexType [FW04]. O nome a atribuir é constituído pelo nome da classe seguido de

“Type”. Este sufixo serve para distinguir entre tipos e elementos em XSD. Para cada

tipo XSD deve ser criado o elemento respectivo. Recorre-se à etiqueta element para

definir os elementos em XSD. O nome a atribuir ao elemento é igual ao do tipo que lhe

deu origem, excepto que a primeira letra é minúscula e que o sufixo “Type” é excluído

do nome.

Os atributos de cada classe UML dão origem a uma sequência de elementos

dentro do tipo XSD composto. Estes elementos, por sua vez, podem referenciar um tipo

XSD simples ou complexo. Um elemento referencia um tipo simples sempre que o

atributo do modelo UML seja elementar, por exemplo: ‘String’, ‘Integer’, ‘Double’, etc

(ver Apêndice C – Conversão de Tipos Básicos da UML para o Formato XSD). Neste

caso, o seu nome é igual ao atributo do modelo UML que lhe deu origem. Quando a

classe está associada a outras classes do tipo <<data>>, o elemento passa a referenciar

o tipo XSD correspondente à classe associada [BM04]. Neste caso, o nome do elemento

é constituído pelo nome da classe associada, devendo iniciar-se por uma letra

minúscula. Deve ainda ser considerada a multiplicidade dos elementos que participam

na associação, alterando em conformidade os campos: ‘minOccurs’ e ‘maxOccurs’, do

elemento XSD. Na Tabela em baixo encontra-se exemplificada a conversão das

diferentes expressões de multiplicidade possíveis em UML para XSD.

Francisco Santos 42

Expressão UML minOccurs maxOccurs

0..1 0 1

1 1 1

m..n m n

1..* 1 unbounded Tabela 4.1 – Conversão das Expressões de Multiplicidade

Sempre que exista herança entre duas classes <<data>> deve usar-se o

elemento extension. A extensão é declarada no tipo XSD que solicita a herança,

definindo, como base da extensão, o tipo XSD associado à classe da qual pretende

herdar. Podem ser usados nomes de atributos iguais na super- e na sub-classe. Na

Tabela 4.2 encontra-se exemplificada a conversão de vários exemplos de classes

<<data>> para o formato XSD.

Modelo UML Conversão para XSD

<xsd:complexType name=”ClasseAType”>

<xsd:sequence>

<xsd:element name=”attribA” type=”string”/>

<xsd:element name=”attribB” type=”boolean”/>

<xsd:element name=”attribC” type=”int”/>

</xsd:sequence>

</xsd:complexType>

ClasseAattribA : StringattribB : BooleanattribC : Integer

<<data>>

ClasseA<<data>>

ClasseB<<data>>

1..n0..10..1 1..n




<xsd:sequence>

<xsd:element name=”classeB” type=”tns:ClasseBType” minOccurs=”1” maxOccurs=”unbounded” />

</xsd:sequence>

</xsd:complexType>



<xsd:complexType name=”ClasseBType”>

<xsd:sequence>

<xsd:element name=”classeA” type=”tns:ClasseAType” minOccurs=”0” maxOccurs=”1” />

</xsd:sequence>

</xsd:complexType>

Francisco Santos 43


Modelo UML Conversão para XSD

ClasseA<<data>>

ClasseB<<data>>

1..n0..10..1 1..n



<xsd:sequence>

<xsd:element name=”classeB” type=”tns:ClasseBType” minOccurs=”1” maxOccurs=”unbounded” />

</xsd:sequence>

</xsd:complexType>


<xsd:complexType name=”ClasseBType” />

ClasseAattribA : String

<<data>>

ClasseBattribB : String

<<data>>


<xsd:complexType name="ClasseAType">

<xsd:sequence>

<xsd:element name="attribA" type="string"/>

</xsd:sequence>

</xsd:complexType>


<xsd:complexType name="ClasseBType">

<xsd:complexContent>

<xsd:extension base="tns:ClasseAType">

<xsd:sequence>

<xsd:element name="attribB" type="string"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

Tabela 4.2 – Conversão Modelo UML para Formato XSD

As mensagens e as secções constituintes devem ser colocadas num ficheiro

WSDL, separado do ficheiro XSD que contém o esquema dos tipos de dados base. Cada

classe do tipo <<messageContent>> dá origem a um elemento message no ficheiro

WSDL. Para cada atributo da classe é acrescentada uma etiqueta part ao elemento da

mensagem. Sempre que um atributo seja elementar recorre-se ao método de conversão

usado para os tipos de dados base (ver Apêndice C – Conversão de Tipos Básicos da

UML para o Formato XSD). Os restantes atributos da classe devem referenciar um tipo

XSD composto previamente definido. Nas Figuras em baixo é ilustrado um exemplo de

conversão de uma mensagem para o formato WSDL juntamente com os tipos de dados

Francisco Santos 44


utilizados. Note-se que o esquema importado através do ficheiro WSDL corresponde ao

ficheiro XSD que contém a definição dos tipos de dados base.

Clientenome : Stringmorada : String

<<data>>

Encomendaeid : String

<<messageContent>>

+cliente

LinhanomeProduto : Stringquantidade : IntegerprecoUnitario : Float

<<data>>

LinhaEncomenda<<data>>

+linhaEncomenda

1..n1..n

Figura 4.9 – Cenário Conversão para uma Encomenda

… <xsd:complexType name="ClienteType"> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="morada" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="LinhaEncomendaType"> <xsd:sequence> <xsd:element name="linhas" type="LinhaType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="LinhaType"> <xsd:sequence maxOccurs="unbounded"> <xsd:element name="nomeProduto" type="xsd:string"/> <xsd:element name="quantidade" type="xsd:int"/> <xsd:element name="precoUnitario" type="xsd:float"/> </xsd:sequence> </xsd:complexType> …

Figura 4.10 – Ficheiro XSD correspondente aos Tipos de Dados Base da Encomenda

Francisco Santos 45


…

<types>

<schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://www.w3.org/2001/XMLSchema"

…

elementFormDefault="qualified" >

<import namespace="…" schemaLocation="Ficheiro.xsd"/>

<element name="cliente" type="tns:ClienteType"/>

<element name="linhaEncomenda" type="tns:LinhaEncomendaType"/>

</schema>

</types>

…

<message name="Encomenda">

<part name="eid" type="xsd:string"/>

<part name="cliente" element="tns:cliente"/>

<part name="linhaEncomenda" element="tns:linhaEncomenda"/>

</message>

…

Figura 4.11 – Ficheiro WSDL correspondente à Encomenda

4.5 Conversão das Propriedades e Conjuntos de Correlação

Numa primeira abordagem ao problema da comunicação entre processos pode parecer

viável que para enviar uma mensagem a um processo seja apenas necessário conhecer o

seu porto WSDL. Isto é uma ilusão, pois os processos têm estado e necessitam ser

instanciados no início de cada interacção. Por este motivo, qualquer solução para o

encaminhamento das mensagens entre processos deve ter em conta, não só o porto

WSDL do destinatário, como também a correcta identificação da instância do processo.

A infra-estrutura tecnológica de suporte à comunicação entre processos deve permitir

ainda que o encaminhamento das mensagens seja feito de uma forma genérica, sem

obrigar a que cada implementação de um processo possua o seu próprio mecanismo de

encaminhamento [AGGI03].

No mundo orientado por objectos cada objecto possui uma referência, usada

para a comunicação entre objectos. Este mecanismo funciona razoavelmente bem em

ambientes onde exista um acoplamento forte (tight coupling) das entidades

comunicantes, onde a dependência na implementação do mecanismo de referências é

considerada normal. No mundo dos Web Services, que operam num ambiente onde

Francisco Santos 46


existe um acoplamento fraco das entidades comunicantes, torna-se necessário usar um

mecanismo de encaminhamento que seja independente, tanto quanto possível, da

implementação dos processos. A solução passa por usar os identificadores dos dados

que compõem as mensagens trocadas entre processos. Esta é a única solução que

promete sobreviver à evolução independente das implementações dos processos, uma

vez que depende apenas da estrutura das mensagens descritas no protocolo de negócio.

A esta solução de encaminhamento de mensagens dá-se o nome de: correlação.

O conjunto de valores usados para identificar a instância numa comunicação

com correlação é designado por: conjunto de correlação. Todas as mensagens trocadas

através do mecanismo de correlação devem conter os dados do conjunto de correlação

correspondente. É permitido, no entanto, que estes valores se situem em lugares

diferentes na mensagem. Por exemplo: a mensagem ‘Encomenda’ pode conter o

identificador no atributo ‘encomendaID’, mas a mensagem ‘Factura’ pode conter o

identificador no atributo ‘cabecalho/encID’. Por este motivo os conjuntos de correlação

são definidos através de propriedades. As propriedades permitem abstrair do local na

mensagem onde se situam os identificadores dos dados. Cada propriedade possui um

nome e um tipo XSD. Para cada mensagem que contenha uma dada propriedade deve

ser referido o caminho para aceder aos dados correspondentes na mensagem.

4.5.1 Notação

As definições das propriedades são introduzidas no modelo através de uma classe com o

estereótipo <<properties>>. Cada propriedade é expressa como um atributo da

classe, contendo um nome e o tipo correspondente. Para cada mensagem que

implemente uma dada propriedade é definida uma operação na classe

<<properties>>, com o mesmo nome dessa propriedade. Estas operações têm

como único atributo o tipo da mensagem a partir da qual é extraída a propriedade e têm

um tipo de retorno igual ao da propriedade associada. Associa-se uma expressão XPath

a cada operação de modo a definir a forma como deve ser extraída a propriedade a partir

da mensagem. Genericamente, a XML Path Language (XPath) permite aceder aos nós

dos documentos XML, usando uma sintaxe compacta e independente da linguagem

Francisco Santos 47


XML [CR99]. Neste contexto específico a linguagem é usada para aceder às secções

constituintes da mensagem.

Na Figura 4.12 é ilustrado um exemplo de definição de propriedades no modelo

UML. A classe ‘ConjuntoPropriedades’, do tipo <<properties>>, define duas

propriedades: ‘propriedade1’ e ‘propriedade2’. São definidos dois métodos de extracção

para cada propriedade. As primeiras duas operações definem a forma de extrair a

‘propriedade1’ das mensagens do tipo: ‘TipoMensagem1’ e ‘TipoMensagem2’. As

restantes duas operações definem como se extrai a ‘propriedade2’ das mensagens do

tipo: ‘TipoMensagem2’ e ‘TipoMensagem3’.

ConjuntoPropriedadespropriedade1 : Stringpropriedade2 : Integer

propriedade1(msg1 : TipoMensagem1) : Stringpropriedade1(msg2 : TipoMensagem2) : Stringpropriedade2(msg2 : TipoMensagem2) : Integerpropriedade2(msg3 : TipoMensagem3) : Integer

<<properties>>

Figura 4.12 – Notação para as Propriedades

Um conjunto de correlação é definido por uma classe com o estereótipo

<<correlation>>. Os atributos correspondem às propriedades definidas no mesmo

espaço de nomes da classe, sendo que os nomes e tipos são concordantes. A utilização

de um conjunto de correlação por parte de um processo é descrita através da inclusão de

um atributo com o tipo do conjunto de correlação. O estereótipo <<correlation>>

é também aplicado ao atributo para que seja mais fácil distingui-lo dos restantes

atributos do processo. Na Figura 4.13 é ilustrado um exemplo onde a classe

‘ConjuntoCorrelacao1’ é utilizada pela classe ‘Processo1’. O conjunto de correlação,

definido pela classe ‘ConjuntoCorrelacao1’, faz referência às propriedades definidas

anteriormente no exemplo da Figura 4.12.

Francisco Santos 48


ConjuntoCorrelacao1propriedade1 : Stringpropriedade2 : Integer

<<correlation>>

Processo1<<correlation>> correlacao1 : ConjuntoCorrelacao1

<<process>>

Figura 4.13 – Exemplo da inclusão de um Conjunto de Correlação num Processo

No caso mais simples, todas as mensagens recebidas e enviadas pelo processo

usam o mesmo conjunto de correlação, sendo este inicializado no arranque do processo.

Neste caso é apenas necessário associar o conjunto ao processo, conforme ilustrado na

Figura 4.13. Nos outros casos torna-se necessário associar, individualmente, um

conjunto de correlação às actividades de interacção: invoke, receive e reply. Note-se que

apenas as actividades de interacção podem estar associadas a um conjunto de

correlação. Na Figura 4.14 encontra-se ilustrado um exemplo de uma actividade de

interacção, neste caso do tipo receive, onde se define quais os conjuntos de correlação a

usar no acto da recepção da mensagem: ‘msg1’, através da operação: ‘operacao1’.

Actividade1

entry/ operacao1(msg1)entry/ <expressão de correlação>

<<receive>>

Figura 4.14 – Exemplo de uma Actividade que usa Correlação

É usado o prefixo: correlation:, para indicar o começo de uma expressão

de correlação. As expressões de correlação indicam quais são os conjuntos de

correlação usados pela actividade. Sempre que uma actividade use mais do que um

conjunto, os nomes dos restantes conjuntos de correlação deverão estar separados por

vírgulas.

Francisco Santos 49


Exemplos de expressões de correlação:

• correlation: correlacao1

• correlation: correlacao1, correlacao2

Em BPEL, quando um conjunto de correlação é usado pela primeira vez é

necessário inicializá-lo. Por este motivo, as actividades que usam em primeira-mão um

dado conjunto de correlação devem proceder à sua inicialização. Na linguagem BPEL é

possível que múltiplas actividades concorrentes suportem a inicialização do mesmo

conjunto de correlação. A primeira actividade a usar um determinado conjunto ficará

encarregue de proceder à sua inicialização. Obtém-se este comportamento sempre que

seja colocada a palavra initialize antes do nome do conjunto, na expressão de

correlação da actividade.

Exemplos de expressões de correlação com a palavra initialize:

• correlation: initialize correlacao1

• correlation: correlacao1, initialize correlacao2

Sempre que, através da actividade invoke, se execute uma operação síncrona, é

possível usar conjuntos de correlação diferentes para as mensagens recebidas e

enviadas. Neste caso, são necessárias duas acções de entrada para definir os conjuntos

de correlação a usar em cada sentido. De forma a distinguir entre os dois conjuntos, as

expressões de correlação são precedidas pelas palavras: in, no caso da recepção de

mensagens, e out, no caso do envio.

Exemplos de expressões de correlação para a invocação de operações síncronas:

• in correlation: correlacao1

• out correlation: correlacao2

4.5.2 Geração dos Ficheiros WSDL e BPEL

Cada atributo de uma classe <<properties>> corresponde à definição de uma

propriedade no ficheiro WSDL. As operações da classe correspondem aos métodos de

extracção das propriedades para cada tipo de mensagem em WSDL (propertyAlias). Se

Francisco Santos 50

convertermos o exemplo da Figura 4.12 obtemos o código WSDL apresentado na

Figura 4.15. Note-se que, embora não conste no diagrama UML da classe

‘ConjuntoPropriedades’, cada operação define uma interrogação XPath para aceder às

propriedades nos diferentes tipos de mensagens. Neste exemplo assume-se que na

mensagem do tipo ‘TipoMensagem2’ a informação referente à ‘propriedade1’ está

contida no elemento ‘parte1’ e a informação referente à ‘propriedade2’ está contida no

elemento ‘parte2’.

 <bpws:property name=”propriedade1” type=”xsd:string” /> <bpws:property name=”propriedade2” type=”xsd:int” />  <bpws:propertyAlias propertyName=”tns:propriedade1” messageType=”tns:TipoMensagem1” part=”parte1” query=”/parte1/”/> <bpws:propertyAlias propertyName=”tns:propriedade1” messageType=”tns:TipoMensagem2” part=”parte1” query=”/parte1/”/> <bpws:propertyAlias propertyName=”tns:propriedade2” messageType=”tns:TipoMensagem2” part=”parte2” query=”/parte2/”/> <bpws:propertyAlias propertyName=”tns:propriedade2” messageType=”tns:TipoMensagem3” part=”parte1” query=”/parte1/”/>

Figura 4.15 – Definição Propriedades em WSDL

Cada atributo do tipo <<correlation>>, contido num processo, corresponde

à definição de um conjunto de correlação no ficheiro BPEL para esse processo. A

definição das propriedades desse conjunto provém da classe <<correlation>> que

está associada ao atributo. A conversão para BPEL do exemplo descrito na Figura 4.13

resulta no código BPEL apresentado na Figura 4.16.

<correlationSets> <correlationSet name=”correlacao1” properties=”tns:propriedade1 tns:propriedade2”/> </correlationSets>

Figura 4.16 – Definição de Conjuntos de Correlação em BPEL

As expressões de correlação contidas nas actividades UML são convertidas em

expressões de correlação para as actividades do processo BPEL. A actividade com

correlação, descrita na Figura 4.14, resulta no código BPEL apresentado na Figura em

baixo.

Francisco Santos 51


<receive name="actividade1" partnerLink="…" portType="…" operation="initiate" variable="…" createInstance="…"> <correlations> <correlation set="conjuntoCorrelacao1" initiate="yes"/> </correlations> </receive>

Figura 4.17 – Definição de Actividades Correlacionadas em BPEL

4.6 Conversão dos Protocolos de Negócio

Na relação entre um processo e um parceiro de negócio pode existir comunicação uni-

ou bi-direccional. Um protocolo une dois papéis complementares, por exemplo: o

Comprador e o Vendedor, e define quais são as interfaces oferecidas e requeridas por

cada um. Um processo possui um conjunto de portos, onde cada porto está associado a

um papel no protocolo de negócio. O papel define quais são as interfaces oferecidas e

requeridas por esse porto.

Na Figura 4.3 são ilustrados quatro protocolos de negócio: ‘Encomendar’,

‘Enviar’, ‘Fabricar’, ‘Facturar’. Os protocolos: ‘Encomendar’ e ‘Fabricar’ são

unidireccionais, e os restantes são bidireccionais.

4.6.1 Notação

Um protocolo é modelado como um pacote com o estereótipo <<protocol>>. Cada

protocolo contém um par de classes do tipo <<role>>. O nome do protocolo é igual

ao nome do pacote onde está contido. Cada pacote <<protocol>> deve conter

apenas um protocolo.

Na Figura 4.18 é apresentada a definição do protocolo de negócio: ‘Protocolo1’.

O ‘Papel1’ oferece a ‘Interface1’ e requer a ‘Interface2’, e o ‘Papel2’ oferece a

‘Interface2’ e requer a ‘Interface1’. Se este protocolo fosse unidireccional, seria

definida apenas uma interface, oferecida por um dos papéis e requerida pelo

complementar. Na Figura 4.19 é apresentada a definição detalhada da ‘Interface1’ e da

‘Interface2’. O argumento de entrada da operação tem sempre o nome ‘input’ e pode

estar associado a uma mensagem (classe <<messageContent>>) ou tipo de dados

base (classe <<data>>). Tratando-se de uma operação síncrona, é também necessário

Francisco Santos 52


definir o tipo de retorno. Tal como no caso do argumento de entrada, o tipo de retorno

pode estar associado a uma mensagem ou tipo de dados base.

Protocolo1<<protocol>>

Papel2<<role>>

Interface2

operacao2()

Papel1<<role>> Interface1

operacao1()

Figura 4.18 – Exemplo da Notação dos Protocolos de Negócio e Papéis

Interface1

operacao1(input : TipoEntrada1) : TipoRetorno1

Interface2

operacao2(input : TipoEntrada2) Figura 4.19 – Exemplo da Notação das Interfaces

4.6.2 Geração do Ficheiro WSDL

Para cada pacote do tipo <<protocol>> é criada uma ligação a um parceiro de

negócio. Os papéis do protocolo são convertidos em papéis desta ligação. As interfaces

realizadas pelos papéis correspondem aos tipos de portos, sendo que o nome do tipo de

porto é igual ao nome da interface. Protocolos que apenas suportem a comunicação

unidireccional são convertidos em ligações com apenas um papel. O código WSDL,

Francisco Santos 53


apresentado na Figura 4.20, resulta da conversão do protocolo de negócio, descrito

anteriormente.

<portType name="Interface1"> <operation name="operacao1"> <input message="ns1:TipoEntrada1"/> <output message="ns1:TipoRetorno1"/> </operation> </portType> <portType name="Interface2"> <operation name="operacao2"> <input message="ns1:TipoEntrada2"/> </operation> </portType> <plnk:partnerLinkType name="Protocolo1"> <plnk:role name="Papel1"> <plnk:portType name="tns:Interface1"/> </plnk:role> <plnk:role name="Papel2"> <plnk:portType name="tns:Interface2"/> </plnk:role> </plnk:partnerLinkType>

Figura 4.20 – Ficheiro WSDL com a definição das Ligações a Parceiros e Papéis

4.7 Conversão de Processos

Um processo automatizado descreve os passos de execução de uma tarefa do negócio,

possivelmente envolvendo várias entidades internas ou externas à organização. O

processo possui estado e interage com os parceiros de negócio através de protocolos

bem definidos. Cada ligação a um parceiro de negócio constitui um ponto de ligação

para um parceiro do processo. As interfaces, que são disponibilizadas ou solicitadas

através de uma ligação, estão definidas pelo papel que o processo desempenha no

protocolo.

4.7.1 Notação

Um processo é modelado através de uma classe com o estereótipo <<process>>.

Uma ligação a um parceiro de negócio é representada por uma associação, com o

estereótipo <<partnerLink>>, entre o processo e o papel que este desempenha. O

‘ProcessoReceberEncomenda’, ilustrado na Figura 4.4, possui quatro ligações a

parceiros de negócio: ‘encomendar’, ‘facturar’, ‘enviar’ e ‘fabricar’, e o seu estado é

Francisco Santos 54


representado através de seis atributos: ‘encomenda’, ‘factura’, ‘encomendaFault’,

‘prazoEntrega’, ‘informacaoEntrega’ e ‘pedidoEntrega’.

4.7.2 Geração do Ficheiro BPEL

Cada classe que contenha o estereótipo <<process>> é convertida numa definição de

um processo BPEL, com os seguintes atributos:

Atributo Valor Descrição

abstractProcess no Este perfil suporta apenas a modelação de processos executáveis [ACDG+03].

variableAccessSerializable no Os contextos BPEL serializáveis [ACDG+03] não são suportados por este perfil.

enableInstanceCompensation no Os contextos BPEL de compensação [ACDG+03] não são suportados por este perfil.

suppressJoinFailure yes As falhas de junção [ACDG+03] ocorrem sempre que todas as ligações de entrada de uma actividade BPEL estejam inactivas. Este evento não é considerado um erro neste perfil.

Tabela 4.3 – Atributos para a Definição de um Processo BPEL

O prefixo do espaço de nomes do processo é fornecido no início do processo de

conversão. A restante parte do espaço de nomes é constituída pelo nome do modelo,

estrutura de pacotes e o nome do processo.

Os atributos do processo são convertidos em variáveis BPEL e as associações

com o estereótipo <<partenerLink>>, que ligam o processo aos papéis do

protocolo, são convertidas em ligações a parceiros de negócio. Não é necessário

especificar o papel desempenhado pelo parceiro uma vez que este, automaticamente,

assume o papel complementar, definido no protocolo de negócio. No Apêndice B –

Ficheiro BPEL ProcessoReceberEcomenda – encontra-se descrita a conversão do

‘ProcessoReceberEncomenda’.

Francisco Santos 55


4.8 Manipulação do Estado do Processo

Ao longo da vida útil de um processo de negócio, torna-se necessário actualizar e

manipular o seu estado interno. O perfil recorre à linguagem XPath para manipular os

atributos do processo através de expressões, permitindo uma conversão directa para

BPEL. Isto deve-se ao facto da XPath ser a linguagem usada por omissão na definição

de expressões em BPEL.

4.8.1 Linguagem XPath

O principal objectivo da linguagem XPath é o de aceder ao conteúdo de um documento

XML [CR99]. Para poder processar os dados contidos nos documentos XML, a

linguagem disponibiliza um conjunto de funções adequadas à manipulação de cadeias

de caracteres, números e valores booleanos. Esta linguagem usa uma notação compacta,

diferente da notação XML, para facilitar a sua utilização em Universal Resource

Identifiers (URIs) e nos valores dos atributos XML. A XPath opera na estrutura lógica

abstracta de um documento XML em vez de na sua sintaxe superficial. Um documento

XML é visto como uma árvore de nós. Os nós podem ser de vários tipos diferentes,

incluindo: nós elemento (element), nós atributo (attribute) e nós texto (text), sendo que

para cada um existe uma representação textual definida pela linguagem.

O principal constructo sintáctico na XPath é a expressão. Uma expressão

corresponde à produção ‘Expr’ da gramática XPath. O resultado da avaliação de uma

expressão pode ser de quatro tipos: conjunto de nós (conjunto desordenado de nós sem

duplicados), valor booleano, número (de vírgula flutuante) ou cadeia de caracteres. A

avaliação de expressões é sempre feita com base num contexto. O contexto consiste em:

um nó (designado nó contexto), um par de inteiros positivos, constituído pela posição e

tamanho do contexto, um conjunto de ligações de variáveis, uma biblioteca de funções,

um conjunto de espaços nomes válidos neste contexto. O tamanho do contexto

representa o número de nós filho do nó contexto. A posição representa o identificador

numérico, começado em um, do nó filho que está a ser analisado. Facilmente se

depreende que o valor da posição é sempre inferior ao tamanho do contexto. As ligações

de variáveis representam a correspondência entre o nome de uma variável e o seu valor.

Francisco Santos 56


A biblioteca de funções faz a correspondência entres os nomes das funções e as próprias

funções. Na Secção 4 de [CR99] é descrito o conjunto de funções base que faz parte de

qualquer implementação XPath. No contexto da linguagem BPEL são acrescentadas

algumas funções a esta biblioteca para seleccionar atributos de um processo de negócio

e para obter o seu valor. Por fim, o conjunto de espaços de nomes faz a correspondência

entre os prefixos e os URIs dos espaços de nomes.

Uma expressão com particular interesse é o caminho. O caminho selecciona um

conjunto de nós relativos ao nó contexto. Os caminhos, que correspondem à produção

‘LocationPath’ da gramática XPath, podem conter, recursivamente, outras expressões

que sejam usadas para filtrar o conjunto de nós resultante. Existem dois tipos de

caminhos: relativos e absolutos.

Os caminhos relativos consistem numa sequência de um ou mais passos,

separados por uma barra (‘/’). Os passos são construídos da esquerda para a direita.

Cada passo selecciona um conjunto de nós relativamente a um nó contexto. Após a

avaliação de uma sequência de ‘k’ passos obtemos um determinado conjunto de nós do

documento XML. O passo ‘k+1’ utiliza, como nós contexto, todos os nós pertencentes

ao conjunto anterior. No final da execução do passo ‘k+1’ é feita a união dos nós

encontrados com o conjunto anterior.

Os caminhos absolutos consistem numa barra seguida de um caminho relativo.

A barra, por si só, selecciona a raiz do documento XML. Se esta for sucedida por um

caminho relativo, o resultado é igual à avaliação da expressão do caminho relativo,

tendo como nó contexto a raiz do documento.

Um passo do caminho é composto por três partes: um eixo, um selector de nós e

zero ou mais predicados. O eixo identifica qual a relação que existe entre os nós

seleccionados pelo passo e o nó contexto. Por exemplo: child identifica uma relação

de “pai para filho”, descendant identifica uma relação de descendência, que inclui

todos os filhos e, recursivamente, os filhos dos filhos, e parent identifica uma relação

de “filho para pai”. O selector do nó identifica o tipo de nó a encontrar ou o nome

expandido do nó (composto pelo URI do espaço de nomes e o nome local). Os

predicados são expressões arbitrárias que servem para refinar ainda mais o conjunto de

nós encontrado neste passo. A sintaxe para a definição de um passo é a seguinte: nome

Francisco Santos 57


do eixo, separado por ‘::’, selector do nó, seguido de zero ou mais predicados entre

parênteses rectos (‘[‘ e ‘]’). Por exemplo:

child::paragrafo[position()=1]

child é o nome do eixo, paragrafo é o selector do nó e position()=1 é o

predicado. Este passo do caminho selecciona o primeiro filho, de nome paragrafo, a

partir do contexto.

4.8.2 Expressões de Acesso aos Dados

Cada expressão de acesso aos dados é começada pelo nome de um atributo (ou

variável) do processo. Para aceder a uma secção da mensagem correspondente ao

atributo concatena-se uma barra ao nome do atributo e acrescenta-se o nome da secção.

Por exemplo, a expressão:

encomenda/cliente

permite aceder à secção ‘cliente’ da mensagem ‘encomenda’, que representa um

atributo do processo.

A especificação BPEL acrescenta duas novas funções à especificação XPath. A

função ‘getVariableData’ recebe como argumentos: o nome da variável do processo

(ex.: ‘encomenda’), a secção da mensagem que deve ser acedida (‘cliente’) e,

opcionalmente, uma expressão que representa o caminho para aceder aos dados contidos

na secção anterior (ex.: ‘morada/codigoPostal’). Como resultado da aplicação desta

função obtém-se o nó correspondente à secção da mensagem ou à selecção descrita pelo

terceiro argumento. Se o resultado da aplicação da selecção devolver um conjunto de

nós com cardinalidade diferente de um, a função devolve um erro. A função

‘getVariableProperty’ recebe como argumentos: o nome da variável do processo (ex.:

‘factura’) e o nome de uma propriedade que esteja associada à mensagem anterior (ex.:

‘encomendaID’). Após a aplicação desta função obtém-se o valor associado à

propriedade da mensagem, que resulta da avaliação da expressão XPath associada à

propriedade (ver Secção 4.5). Se o resultado da avaliação da expressão XPath

Francisco Santos 58


correspondente à propriedade devolver um conjunto de nós com cardinalidade diferente

de um, é devolvido um erro.

As expressões de acesso aos dados são convertidas em aplicações de uma das

funções anteriores: ‘getVariableData’ ou ‘getVariableProprety’. O primeiro argumento

de ambas as funções corresponde ao atributo do processo. O segundo argumento pode

representar o nome de uma secção ou o nome de uma propriedade da mensagem

anterior. Se representar o nome de uma secção é aplicada a função ‘getVariableData’,

caso represente uma propriedade é aplicada a função ‘getVariableProperty’. Na tabela

em baixo são apresentados alguns exemplos de conversão de expressões de acesso aos

dados.

Expressão acesso aos dados Conversão BPEL encomenda/cliente

onde ‘encomenda’ é uma variável do tipo ‘Encomenda’ e ‘cliente’ é o nome de uma secção dessa mensagem

getVariableData(‘encomenda’,’cliente’)

encomenda/cliente/morada/codigoPostal

onde ‘encomenda’ é uma variável do tipo ‘Encomenda’ e a restante parte da expressão representa um caminho para aceder aos dados da mensagem

getVariableData(‘encomenda’,’cliente’,’/morada/codigoPostal’)

factura/encomendaID

onde ‘factura’ é uma variável do tipo ‘Factura’ e ‘encomendaID’ representa uma propriedade da mensagem

getPropertyData(‘factura’,’encomendaID’)

Tabela 4.4 – Exemplos de Expressões de Acesso aos Dados

4.8.3 Expressões de Atribuição

As expressões de atribuição, usadas nas actividades <<assign>>, são necessárias

para modificar o valor dos atributos de um processo. Uma vez que não fazem parte da

Francisco Santos 59


linguagem XPath base, torna-se necessário introduzir a sua definição. Estas expressões

são constituídas por um operador atribuição ‘:=’ entre duas expressões XPath normais.

Como resultado da avaliação destas expressões, o valor da expressão direita é copiado

para o elemento seleccionado pela expressão esquerda. Por exemplo:

factura/cliente := encomenda/cliente

copia o valor do atributo ‘cliente’ da mensagem ‘encomenda’ para o atributo ‘cliente’

da mensagem ‘factura’.

4.8.4 Geração das Actividades BPEL

Nesta Secção é descrita a conversão das actividades individuais, que compõem o

diagrama de actividades do processo, em BPEL. O processo de conversão ao nível da

actividade é invocado durante a construção do grafo de actividades BPEL, usado pelo

algoritmo descrito na Secção 4.8.5.1.

4.8.4.1 Actividade de Atribuição

As actividades de atribuição (BPELAssign) são usadas para actualizar os valores dos

atributos de um processo, podendo conter um número arbitrário de atribuições

elementares. Em UML, as atribuições são descritas através das actividades com o

estereótipo <<assign>>, recorrendo às expressões de atribuição (ver Secção 4.8.3). O

processo de conversão das actividades <<assign>> é ilustrado através de um

exemplo:

Atribuicao1<<assign>>

entry/ encomenda/aprovada := 'true'entry/ factura/cliente := encomenda/clienteentry/ factura/data := getDataHora()

Figura 4.21 – Exemplo de uma Actividade de Atribuição

A conversão da actividade anterior resulta no seguinte código BPEL:

Francisco Santos 60


<assign name="Atribuicao1"> <copy> <from expression="‘true’)"/> <to variable="encomenda" part="aprovada"/> </copy> <copy> <from expression="getVariableData(‘encomenda’,’cliente’)"/> <to variable="factura" part="cliente"/> </copy> <copy> <from expression="getDataHora()"/> <to variable="factura" part="data"/> </copy> </assign>

Figura 4.22 – Exemplo da conversão de uma Actividade de Atribuição para BPEL

Note-se que tanto a biblioteca de funções base da linguagem XPath 1.0 [CR99]

como a da linguagem BPEL [ACDG+03] não incluem funções para manipular datas,

pelo que a existência da função ‘getDataHora()’, descrita no exemplo anterior e que

devolve a data e hora actuais, depende da plataforma escolhida para a execução do

processo.

4.8.4.2 Actividade de Espera

A actividade de espera (BPELWait) permite modelar eventos temporais, i.e. períodos

de espera ou prazos, na sequência de actividades de um processo. Em UML,

representam-se as actividades de espera com o estereótipo <<wait>> e recorre-se a

expressões XPath para modelar eventos temporais. Na modelação de períodos de espera

o resultado da avaliação da expressão XPath deve ser do tipo: XSD duration [BM04].

Para a modelação de prazos o tipo de dados resultante da expressão XPath dever ser:

XSD date ou dateTime [BM04]. De forma a distinguir entre os dois tipos de eventos

temporais, coloca-se o prefixo ‘for’, no caso dos períodos de espera, e ‘until’, no

caso dos prazos, antes da expressão XPath temporal. O processo de conversão das

actividades <<wait>> é ilustrado através de um exemplo:

Francisco Santos 61


esperarPelaProducao<<wait>>

entry/ until escalonamentoProducao/finalizacaoEncomenda

enviarEncomenda

Figura 4.23 – Exemplo de uma Actividade de Espera

A conversão da actividade de espera anterior resulta no seguinte código BPEL:

<wait name=”esperarPelaProducao” until=”getVariableData(‘escalonamentoProducao’,’finalizacaoEncomenda’)”/>

Figura 4.24 – Exemplo da conversão de uma Actividade de Atribuição para BPEL

4.8.4.3 Actividade de Invocação

É normal que um processo invoque operações dos parceiros de negócio várias vezes

durante a sua execução. Uma actividade de invocação (BPELInvoke) pode ser do tipo:

síncrono ou assíncrono. Na invocação síncrona é retornado um valor e, em caso de erro,

é devolvida uma excepção. Na invocação assíncrona, a actividade de invocação termina

assim que seja enviado o pedido, não sendo retornado qualquer valor ou excepção. A

resposta assíncrona do parceiro para o processo é modelada através de uma actividade

de invocação adicional. Em UML, as actividade de invocação são representadas pelo

estereótipo <<invoke>>. O processo de conversão das actividades de invocação é

ilustrado através de um exemplo:

Francisco Santos 62

invocar1<<invoke>>

entry/ operacao1( atrib1 )

invocar2<<invoke>>

entry/ atrib3 := operacao2( atrib2 )

ligacaoParceiro2ligacaoParceiro1

Figura 4.25 – Exemplo da Invocação de Operações Síncronas e Assíncronas

A conversão das actividades de invocação anteriores resulta no seguinte código

BPEL:



<invoke name="invocar1" partnerLink="ligacaoParceiro1" portType="ligacaoParceiro1:IServicoXXX" operation="operacao1" inputVariable="atrib1" />



<invoke name="invocar2" partnerLink="ligacaoParceiro2" portType="ligacaoParceiro2:IServicoYYY" operation="operacao2" inputVariable="atrib2" outputVariable="atrib3"/>

Figura 4.26 – Exemplo da Conversão de Actividades de Invocação Síncronas e Assíncronas

4.8.4.4 Actividade de Recepção e de Resposta

Um processo disponibiliza o conjunto de operações a executar pelos seus parceiros

através das actividades de recepção (BPELReceive). As respostas síncronas são

modeladas através de uma actividade de resposta (BPELReply) correspondente,

significando que o parceiro fica bloqueado à espera da resposta ao seu pedido. Em

UML, as actividades de recepção são representadas através do estereótipo

<<receive>>, tendo, como acção de entrada, a operação invocada pelo parceiro, cujo

único atributo é a variável onde é colocada a mensagem recebida. As actividades de

resposta são modeladas através do estereótipo <<reply>>, tendo, como acção de

entrada, uma expressão de atribuição, cujo lado esquerdo contém a operação invocada

Francisco Santos 63


inicialmente pelo parceiro e no lado direito contém a variável a partir da qual deve ser

gerada a resposta. A actividade de resposta é colocada na mesma pista da actividade de

recepção correspondente. O processo de conversão das actividades de recepção e

resposta é ilustrado através de um exemplo:

receber1<<receive>>


responder1<<reply>>

entry/ operacao1() := atrib2

invocar2<<invoke>>


receber3<<receive>>


ligacaoParceiro2ligacaoParceiro1

Figura 4.27 – Exemplo da utilização de Actividades de Recepção e Reposta

Na Figura 4.27 é ilustrado um exemplo de um pedido síncrono, representado

pelas actividades ‘receber1’ e ‘responder1’, que formam um par recepção/resposta

através da ligação ‘ligacaoParceiro1’. A mensagem correspondente à invocação da

‘operacao1’ é guardada na variável do processo ‘atrib1’. O processo invoca a

‘operacao2’ através da ligação ‘ligacaoParceiro2’, enviando a mensagem contida no seu

atributo ‘atrib1’. Na actividade ‘receber3’ é ilustrado um exemplo de um pedido

assíncrono, note-se que não existe uma actividade de resposta correspondente.

Finalmente, é enviada a resposta ao pedido inicial através da actividade ‘resposta1’.

Neste caso, é enviada a mensagem contida no atributo ‘atrib2’. A conversão das

actividades de recepção e resposta do exemplo resultam no seguinte código BPEL:

Francisco Santos 64


<receive name="receber1" variable="atrib1" createInstance="yes" operation="operacao1" partner="ligacaoParceiro1" portType="ligacaoParceiro1:IServicoXXX" suppressJoinFailure="no"/>

…

<receive name="receber3" variable="atrib2" createInstance="no" operation="operacao3" partner="ligacaoParceiro2" portType="ligacaoParceiro2:ICallbackYYY" suppressJoinFailure="no"/>

<reply name="responder1" partnerLink="ligacaoParceiro1" portType=" ligacaoParceiro1:IServicoXXX " operation="operacao1" variable="atrib2"/>

Figura 4.28 – Exemplo da Conversão de Actividades de Recepção e Resposta

As actividades de recepção são também usadas para criar a instância do

processo, pelo que são sempre executadas antes de qualquer outro tipo de actividade1.

Na conversão de uma actividade de recepção inicial para BPEL é colocado o valor ‘yes’

no atributo ‘createInstance’, significando que ao executar-se é criada uma nova

instância do processo. Caso a ordem de chegada dos pedidos iniciais não seja previsível,

é possível haver mais do que uma actividade de recepção responsável pela criação da

instância do processo [ACDG+03]. Todas as actividades de recepção iniciais devem

partilhar os mesmos conjuntos de correlação.

4.8.4.5 Actividade de Decisão

As actividades de decisão (BPELSwitch) dão suporte ao comportamento condicional

dos processos. Esta actividade consiste num conjunto de uma ou mais condições

mutuamente exclusivas, definas por elementos case. Opcionalmente, pode incluir-se

uma condição de excepção através do elemento otherwise, sendo escolhida sempre que

todas as outras condições sejam falsas. A execução desta actividade termina assim que a

actividade correspondente à condição escolhida tenha terminado a sua execução. Em

UML, as actividades de decisão são representadas através dos nós de decisão do

diagrama de actividades, sendo as condições especificadas através de expressões XPath

cuja avaliação resulte num valor booleano. O processo de conversão das actividades de

decisão é ilustrado através do seguinte exemplo:

Francisco Santos 65

Actividade 1

Actividade 2

Actividade 3

Actividade 4

Actividade 5

[ cond1 ][ cond2 ]

[ otherwise ]

Figura 4.29 – Exemplo da utilização de Actividades de Decisão

Na Figura 4.29 é apresentado um diagrama de actividades com um nó de decisão

e de fusão. Do nó de decisão partem três ligações de controlo, cada um com uma

condição de transição mutuamente exclusiva: ‘cond1’, ‘cond2’ e ‘otherwise’, que é

verdadeira sempre que ‘cond1’ e ‘cond2’ sejam falsas. A conversão do diagrama de

actividades do exemplo resulta no seguinte código BPEL:

 <switch>  <case condition=”…”>   </case>  <case condition=”…”>  </case> <otherwise> <empty/> </otherwise> </switch> 

Figura 4.30 – Exemplo da Conversão de uma Actividade de Decisão para BPEL

1 Nota: a actividade BPEL pick [ACDG+03] também pode ser usada no início para criar a instância do processo. Esta actividade não é suportada pelo perfil.

Francisco Santos 66


4.8.5 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

Francisco Santos 67


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>>


[ 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: BPELReceivenome: Actividade1

BPELSwitchnome: Decisao1

BPELAssignnome: Actividade2

BPELInvokenome: Actividade3

BPELMergenome: Fusao1


BPELWaitnome: Actividade5

BPELReplynome: Actividade6

cond: ‘cond2’cond: ‘cond1’

BPELReceivenome: Actividade1

BPELSwitchnome: Decisao1

BPELAssignnome: Actividade2


BPELMergenome: Fusao1


BPELWaitnome: Actividade5

BPELReplynome: 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

Francisco Santos 68


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

sequência de actividades BPEL. Na Figura 4.33 podemos observar o resultado da

Francisco Santos 69


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

Francisco Santos 70


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’.

BPELMerge2 Pesquisar a partir de ‘v’ e

adicionar todas as

actividades encontradas a

seguir ao BPELSwitch

correspondente.


controlo entre o

BPELSwitch

correspondente e ‘v’.

2 Pressupõe a existência de um BPELSwitch prévio

Francisco Santos 71


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.


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.


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.

Francisco Santos 72


Actividade1

Actividade3

Actividade6

Actividade2

Actividade4

Actividade5

Fluxo2

Fluxo1

cond1 cond2


Decisao1

Seq

uenc

ia1

Seq

uenc

ia2

Seq

uenc

ia3

Seq

4

Seq

5

Actividade1

Actividade3

Actividade6

Actividade2

Actividade4

Actividade5

Fluxo2

Fluxo1

cond1 cond2


Decisao1

Seq

uenc

ia1

Seq

uenc

ia2

Seq

uenc

ia3

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

composta. As heurísticas encontram-se descritas na Tabela em baixo.

Francisco Santos 73


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 actividades3: 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.

Francisco Santos 74


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’.

Francisco Santos 75


Actividade1

Actividade3

Actividade6

Actividade2

Actividade4

Actividade5

Fluxo2

cond1 cond2


Decisao1

Seq

uenc

ia1

Seq

uenc

ia3

Actividade1

Actividade3

Actividade6

Actividade2

Actividade4

Actividade5

Fluxo2

cond1 cond2


Decisao1

Seq

uenc

ia1

Seq

uenc

ia3

Figura 4.35 – Árvore BPEL Optimizada

Francisco Santos 76


5 Implementação Na primeira fase do trabalho foi desenvolvida uma biblioteca dedicada à manipulação

de grafos, para servir de base à implementação do algoritmo de conversão, descrito na

Secção 4.8.5. Os algoritmos para a travessia em largura e em profundidade foram

implementados na sua versão iterativa por questões de eficiência: espaço ocupado em

memória e tempo de execução. O algoritmo de conversão estende a classe para a

travessia em profundidade, definida na biblioteca, e reutiliza o método de classificação

de arcos do grafo.

Para o primeiro protótipo da solução foi usado um processador de expressões

XPath: designado Java XPath Engine (Jaxen), para ler o modelo UML a partir de um

ficheiro XMI 1.1. Nesta implementação adoptou-se a estratégia de seguir a sequência de

nós da árvore do documento XML para a conversão do modelo UML. Esta solução

revelou-se impraticável visto que é necessário consultar mais do que uma parte do

modelo em simultâneo durante a conversão. O primeiro protótipo serviu apenas para

testar e desenvolver as principais ideias do algoritmo de conversão baseado em grafos,

centrando-se no diagrama de actividades associado ao processo. Para converter a

totalidade do modelo tornava-se necessário usar uma representação em memória do

modelo UML do utilizador, que permitisse um acesso eficiente a todos os seus

elementos constituintes. O projecto UML2 sobre a plataforma Eclipse [Hussey05] veio

responder a esta necessidade.

Embora adequado à solução do problema, o projecto UML2 disponibiliza

documentação insuficiente sobre a sua utilização, existindo, à data da escrita deste

relatório, poucos artigos publicados sobre o assunto: [Hussey05], [Hussey05b] e

[Misic05]. O projecto Eclipse UML2 representa uma implementação do meta-modelo

UML2 e é baseado no projecto Eclipse Modelling Framework (EMF), através do qual

tem capacidade para fazer importação e exportação dos modelos para XMI 2.0. A

utilização do meta-modelo UML versão 2 obrigou à conversão do perfil de modelação

de negócio, descrito neste documento, que estava inicialmente adaptado à versão 1.5 do

meta-modelo. Os diagramas de actividades sofreram várias modificações ao longo das

versões da UML. Por este motivo, não é surpreendente que na versão 2 da UML o

Francisco Santos 77


diagrama de actividades tenha sido significativamente estendido e alterado [Fowler04].

Na UML2 os diagramas de actividades deixaram de ser uma especialização dos

diagramas de estados. Na UML1 existiam regras para o balanceamento dos nós de

difusão e de junção, que deixaram de existir na nova versão. Os nós do diagrama de

actividades são agora designados por: “acções”, sendo que uma “actividade” se refere a

uma sequência de acções e o diagrama de actividades mostra uma actividade, composta

por várias acções. Os nós de decisão, designados por “ramos” na UML1, possuem um

único fluxo de entrada e vários fluxos de saída. Cada fluxo de saída possui uma

“condição de transição”, representada por uma expressão booleana, colocada entre

parênteses rectos. A partir de um nó de decisão apenas um fluxo de saída pode ser

escolhido, sendo por isso necessário que as condições de transição sejam mutuamente

exclusivas. O nó de fusão, ao contrário do nó de decisão, possui múltiplos fluxos de

entrada e apenas um de saída. Este nó é usado para assinalar o final de um nó de

decisão. Finalmente, na UML1 múltiplos fluxos de entrada significavam uma fusão

implícita dos fluxos, sendo apenas necessário que um fluxo estivesse activo para que a

acção se executasse. Na nova versão, este comportamento foi modificado de forma a

existir uma junção (sincronização) implícita dos fluxos de entrada de uma acção. Este

aspecto em particular já tinha sido contemplado no perfil descrito em [AGGI03], pelo

que não foi necessário modificar o comportamento descrito na Secção 2.1.2. No

Apêndice D – Conversão para o Perfil versão UML 2.0 – encontra-se uma descrição das

modificações necessárias ao perfil para poder ser usado na versão 2 da linguagem UML.

O algoritmo de conversão encontra-se implementado sobre a forma de um

componente para a plataforma Eclipse. A principal vantagem desta plataforma é a

possibilidade de desenvolver aplicações num curto espaço de tempo, estendendo e

reutilizando outros componentes existentes na plataforma, nomeadamente os

componentes: UML2 e EMF. Adicionalmente, devido ao crescente interesse das

empresas da área informática nesta plataforma de desenvolvimento, e no componente

UML2 em particular, favorece a longevidade da solução proposta. A conversão e

optimização das expressões XPath, contidas no próprio modelo UML, ficam a cargo do

processador Jaxen, usando as regras de conversão descritas na Secções: 4.8.1, 4.8.2 e

4.8.3.

Francisco Santos 78


O perfil descrito neste relatório foi definido sob a forma de um ficheiro UML2,

tal como descrito em [Hussey05b] e [Misic05], e estende os elementos do meta-modelo

UML2 da plataforma através de um conjunto de estereótipos. Sempre que se pretenda

construir um modelo de negócio que seja convertível para a linguagem BPEL, torna-se

necessário importar o perfil a partir do modelo UML. Uma vez que o ficheiro do perfil

está contido no componente Eclipse desenvolvido, a importação deve ser feita através

de um Universal Resource Identifier (URI), o que permite abstrair da sua localização

física. Assim, sempre que se queira usar este perfil deve ser usado o seguinte URI a

partir da plataforma Eclipse:

pathmap://UML2BPEL_PROFILES/UML2BPEL.profile.uml2

O componente de conversão é invocado através da interface gráfica da

plataforma, sempre que se carregue com o botão direito do rato sobre um ficheiro

UML2 na área de trabalho do utilizador, conforme ilustrado na Figura 5.1. Os eventuais

erros de conversão são apresentados através do visualizador de eventos da própria

plataforma, conforme ilustrado na Figura 5.2. Os ficheiros resultantes da conversão são

colocados na área de trabalho do utilizador, usando a estrutura de directórios definida na

Secção 4.3. Actualmente, o algoritmo de conversão gera os ficheiros BPEL a partir da

especificação do processo, não sendo ainda gerados os ficheiros WSDL correspondentes

aos protocolos, nem os ficheiros XSD e WSDL correspondentes aos tipos de dados e

mensagens.

Francisco Santos 79


Figura 5.1 – Interface Gráfica do Conversor

Figura 5.2 – Visualizador de Eventos da Plataforma Eclipse

Francisco Santos 80


6 Conclusão A Framework CEO (FCEO) é um perfil UML (extensão do UML base) que permite

definir o modelo de negócio de uma organização. Os modelos FCEO não são à partida

executáveis, uma vez que possuem apenas uma descrição estática da estrutura e

dinâmica do processo. Usando uma descrição normalizada da dinâmica do processo

torna possível a conversão automática dos modelos estáticos em modelos executáveis,

permitindo simular o funcionamento real dos processos. Foi escolhida a linguagem

Business Process Execution Language for Web Services (BPEL4WS) para definir a

versão executável dos processos de negócio. A BPEL4WS define um modelo e uma

gramática para descrever o comportamento de um processo de negócio baseado nas

interacções entre o processo e os parceiros de negócio envolvidos.

Recorre-se a um exemplo simples de um processo de recepção de encomendas

para melhor compreender a metodologia de modelação sugerida pela FCEO, sendo

introduzidos os principais diagramas usados para descrever a estrutura e funcionamento

do processo. Este exemplo é também usado para apresentar as principais estruturas e

conceitos da linguagem BPEL4WS. De forma a tornar possível a conversão dos

modelos FCEO em modelos BPEL4WS executáveis é necessário estender o perfil

UML, definido na FCEO. Neste relatório são descritas as extensões necessárias à

framework de forma a tornar possível a conversão automática dos processos de negócio

descritos em UML. A partir da definição do perfil de modelação do negócio é detalhado

todo o processo de conversão dos modelos UML para a linguagem BPEL4WS, sendo

especificado o algoritmo usado durante a conversão. Actualmente, o algoritmo

implementado permite gerar os ficheiros BPEL a partir da especificação do processo,

não sendo ainda gerados os ficheiros WSDL correspondentes aos protocolos, nem os

ficheiros XSD e WSDL correspondentes aos tipos de dados e mensagens.

Francisco Santos 81

Apêndice A – Ficheiro WSDL Protocolo Encomendar <?xml version="1.0"?>

<definitions name="Encomendar”

targetNamespace="http://www.example.org/ProcessamentoEncomendas/Encomendar"

xmlns:tns="http://www.example.org/ProcessamentoEncomendas/Encomendar"

xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"

xmlns:def="http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda/Definicoes

Encomenda"

xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns="http://schemas.xmlsoap.org/wsdl/"

>

<import

namespace="http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda/Definicoes

Encomenda" location="DefinicoesEncomenda.wsdl"/>









<portType name="IServicoEncomenda">

<operation name="enviarPedidoEncomenda">

<input message="def:Encomenda" />

<output message="def:Factura"/>

<fault name="impossivelFinalizarEncomenda" message="def:EncomendaFault"/>

</operation>

</portType>







<plnk:partnerLinkType name="Encomendar">

<plnk:role name="ServicoEncomenda">

<plnk:portType name="tns:IServicoEncomenda"/>

</plnk:role>

</plnk:partnerLinkType>

</definitions>

Francisco Santos 82

Apêndice B – Ficheiro BPEL ProcessoReceberEcomenda <process name="ProcessoReceberEncomenda" suppressJoinFailure="yes"

targetNamespace="http://www.example.org/ProcessamentoEncomendas/ReceberEncomenda/

ProcessoReceberEncomenda"

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns:tns="http://www.example.org/ProcessamentoEncomendas/ReceberEncomenda/Proces

soReceberEncomenda"

xmlns:fabricar="http://www.example.org/ProcessamentoEncomendas/Fabricar"

xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns:enviar="http://www.example.org/ProcessamentoEncomendas/Enviar"

xmlns:encomendar="http://www.example.org/ProcessamentoEncomendas/Encomendar"

xmlns:def="http://www.example.org/ProcessamentoEncomendas/DefinicoesEncomenda"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:bpelx="http://schemas.oracle.com/bpel/extension"

xmlns:ora="http://schemas.oracle.com/xpath/extension"

xmlns:facturar="http://www.example.org/ProcessamentoEncomendas/Facturar">









<partnerLinks>



<partnerLink name="encomendar" partnerLinkType="encomendar:Encomendar"

myRole="ServicoEncomenda"/>

<partnerLink name="enviar" partnerLinkType="enviar:Enviar"

myRole="ClienteDistribuicao" partnerRole="ServicoDistribuicao"/>

<partnerLink name="facturar" partnerLinkType="facturar:Facturar"

partnerRole="ServicoFacturacao" myRole="ClienteFacturacao"/>

<partnerLink name="fabricar" partnerLinkType="fabricar:Fabricar"

partnerRole="ServicoProducao"/>

</partnerLinks>









<variables>

<variable name="encomenda" messageType="def:Encomenda"/>

<variable name="pedidoEntrega" messageType="def:PedidoEntrega"/>

<variable name="informacaoEntrega" messageType="def:InformacaoEntrega"/>

<variable name="prazoEntrega" messageType="def:PrazoEntrega"/>

<variable name="factura" messageType="def:Factura"/>

</variables>



Francisco Santos 83

<correlationSets>

<correlationSet name="Encomenda" properties="def:encomendaID"/>

<correlationSet name="PrazoEntrega" properties="def:encomendaID"/>

</correlationSets>











<sequence name="main">

<receive createInstance="yes" name="receberEncomenda"

partnerLink="encomendar" portType="encomendar:IServicoEncomenda"

operation="enviarPedidoEncomenda" variable="encomenda"/>

<flow name="flow-1">

<links>

<link name="pedirEntrega-to-enviarPrecoEntrega"/>

<link name="receberPrazoEntrega-to-enviarPrazoEntrega"/>

</links>

<sequence name="flow-sequence-distribuicao">

<assign name="inicializarPedidoEntrega">

<copy>

<from variable="encomenda" part="eid"/>

<to variable="pedidoEntrega" part="eid"/>

</copy>

<copy>

<from variable="encomenda" part="cliente"/>

<to variable="pedidoEntrega" part="cliente"/>

</copy>

</assign>

<invoke name="pedirEntrega" partnerLink="enviar"

portType="enviar:IServicoDistribuicao" operation="pedirEntrega"

inputVariable="pedidoEntrega" outputVariable="informacaoEntrega">

<source linkName="pedirEntrega-to-enviarPrecoEntrega"/>

</invoke>

<receive createInstance="no" name="receberPrazoEntrega"

partnerLink="enviar" portType="enviar:ICallbackDistribuicao"

operation="enviarPrazoEntrega" variable="prazoEntrega">

<source linkName="receberPrazoEntrega-to-enviarPrazoEntrega"/>

</receive>

</sequence>

<sequence name="flow-sequence-facturacao">

<invoke name="calcularPreco" partnerLink="facturar"

portType="facturar:IServicoFacturacao"

operation="iniciarCalculoPreco" inputVariable="encomenda"/>

Francisco Santos 84


<invoke name="enviarPrecoEntrega" partnerLink="facturar"

portType="facturar:IServicoFacturacao"

operation="enviarPrecoEntrega" inputVariable="informacaoEntrega">

<target linkName="pedirEntrega-to-enviarPrecoEntrega"/>

</invoke>

<receive createInstance="no" name="receberFactura"

partnerLink="facturar" portType="facturar:ICallbackFacturacao"

operation="enviarFactura" variable="factura"/>

</sequence>

<sequence name="flow-sequence-producao">

<invoke name="pedirEscalonamentoProducao" partnerLink="fabricar"

portType="fabricar:IServicoProducao"

operation="pedirEscalonamentoProducao" inputVariable="encomenda">

<correlations>

<correlation set="Encomenda" initiate="yes" pattern="out"/>

</correlations>

</invoke>

<invoke name="enviarPrazoEntrega" partnerLink="fabricar"

portType="fabricar:IServicoProducao"

operation="enviarPrazoEntrega" inputVariable="prazoEntrega">

<target linkName="receberPrazoEntrega-to-enviarPrazoEntrega"/>

<correlations>

<correlation set="PrazoEntrega" initiate="yes" pattern="out"/>

</correlations>

</invoke>

</sequence>

</flow>

<reply name="enviarFactura" partnerLink="encomendar"

portType="encomendar:IServicoEncomenda"

operation="enviarPedidoEncomenda" variable="factura"/>

</sequence>

</process>

Francisco Santos 85


Apêndice C – Conversão de Tipos Básicos da UML para o Formato XSD Tipo Elementar UML Tipo Simples XSD

Boolean boolean

Byte byte

Currency decimal

Date dateTime

Double double

Float float

Integer int

Long long

Single float

String string

Francisco Santos 86


Apêndice D – Conversão para o Perfil versão UML 2.0

Perfil versão UML 1.5 Perfil versão UML 2.0 Descrição

receber<<receive>>

entry/ correlation: initialize correlacao1entry/ operacao1( atrib1 )

Na UML 2, a acção <<receive>> é modelada como uma CallOperation action e referencia directamente a operação da interface do protocolo; o nome da acção é sempre igual ao nome da operação; é usado um output pin para modelar a mensagem recebida: ‘atrib1’; os conjuntos de correlação a usar são descritos através de uma restrição associada à acção.

invocar

entry/ correlation: initialize correlacao2entry/ atrib2 := operacao2( atrib1 )

<<invoke>>

Na UML 2, a acção <<invoke>> é modelada como uma CallOperation action e referencia directamente a operação da interface do protocolo; o nome da acção é sempre igual ao nome da operação invocada; todas as invocações incluem um input pin, correspondente ao parâmetro de entrada da operação, e no caso da invocação síncrona é também incluído um output pin, correspondente ao parâmetro de retorno da operação.

responder<<reply>>

entry/ correlation: correlacao1entry/ operacao1() := atrib2

Na UML 2, a acção <<reply>> é modelada como uma CallOperation action e referencia directamente a operação da interface do protocolo; o nome da acção é sempre igual ao nome da operação; todas as actividades de resposta incluem um input pin correspondente ao parâmetro de retorno da operação.

atribuicao<<assign>>

entry/ msg2/secB := msg1/secA

Na UML 2, as expressões de atribuição da acção <<assign>> são modeladas através de restrições.

Francisco Santos 87


Perfil versão UML 1.5 Perfil versão UML 2.0 Descrição

esperar24H

entry/ for 'P1DT'

<<wait>>

Na UML 2, as expressões temporais da acção <<wait>> são modeladas através de restrições.

Actividade1<<receive>>

Actividade2<<assign>>

[ cond1 ]



[ cond2 ]

Actividade6<<reply>>

Actividade5<<wait>>

Na UML 2, o fluxo entre actividades deve ser modelado através do fluxo de controlo e não do fluxo de objectos.

Francisco Santos 88


Referências

[ACDG+03] – T. Andrews, F. Curbera, H. Dholakia, Y. Goland et. al, “Business Process Execution Language for Web Services”, 2003

[AGGI03] – J. Amsden, T. Gardner, C. Griffin, S. Iyengar, “Draft UML 1.4 Profile for Automated Business Processes with a mapping to BPEL 1.0”, 2003

[BEKM05] – F. Beshears, J. Evdemon, R. Kleinman, S. Mohler, “IMS General Web Services UML to WSDL Binding Auto-generation Guidelines”, IMS Global Learning Consortium, Inc., 2005

[CCMW01] – E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Web Services Description Language (WSDL) 1.1”, www.w3.org/TR/wsdl, W3C, 2001

[CLRS01] – T. Cormen, C. Leiserson, R. Rivest, C. Stein, “Introduction to Algorithms”, McGraw-Hill, 2001

[CR99] – J. Clark, S. DeRose, “XML Path Language (XPath)”, www.w3.org/TR/xpath, W3C, 1999

[FW04] – D. Fallside, P. Walmsley, “XML Schema Part 0: Primer Second Edition”, www.w3.org/TR/xmlschema-0/, W3C, 2004

[BM04] – P. Biron, A. Malhotra, “XML Schema Part 2: Datatypes Second Edition”, www.w3.org/TR/xmlschema-2/, W3C, 2004

[EP00] – H. Eriksson, M. Penker, “Business Modeling with UML”, John Wiley & Sons, Inc., 2000

[Fowler04] – Martin Fowler, “UML Distilled Third Edition: A Brief Guide to the Standard Object Modeling Language”, Addison-Wesley, 2004

Francisco Santos 89

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/xpath

http://www.w3.org/TR/xmlschema-0/

http://www.w3.org/TR/xmlschema-2/


[Hussey05] – Kenn Hussey, “Getting Started with UML2”, dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/uml2-home/docs/articles/Getting_Started_with_UML2/article.html, IBM, 2005

[Hussey05b] – Kenn Hussey, “Introduction to UML2 Profiles”, dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/uml2-home/docs/articles/Introduction_to_UML2_Profiles/article.html, IBM, 2005

[Misic05] – Dusko Misic, “Authoring UML profiles using Rational Software Architect and Rational Software Modeler”, www-128.ibm.com/developerworks/rational/library/05/0906_dusko/ , IBM, 2005

[OMG03] – “Unified Modeling Language Specification”, OMG, version 1.5, 2003

[Sinogas02] – Pedro Sinogas, “Modelação de processos de negócio”, 2002

[VCSMT04] – A. Vasconcelos, A. Caetano, P. Sinogas, R. Mendes, J. Tribolet, Arquitectura de Sistemas de Informação: A Ferramenta de Alinhamento Negócio / Sistemas de Informação?, 2004

Francisco Santos 90

http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E/uml2-home/docs/articles/Getting_Started_with_UML2/article.html

http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E/uml2-home/docs/articles/Getting_Started_with_UML2/article.html

http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E/uml2-home/docs/articles/Introduction_to_UML2_Profiles/article.html

http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E/uml2-home/docs/articles/Introduction_to_UML2_Profiles/article.html

http://www-128.ibm.com/developerworks/rational/library/05/0906_dusko/

Conversão da Notação CEO para a linguagem BPEL4WSweb.ist.utl.pt/ist150077/doc/uthesis.pdf ·...

Documents

Transcript of Conversão da Notação CEO para a linguagem BPEL4WSweb.ist.utl.pt/ist150077/doc/uthesis.pdf ·...