Conversão da Notação CEO para a linguagem BPEL4WS

Transcrição

1 Conversão da Notação CEO para a linguagem BPEL4WS Departamento de Engenharia Informática 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)

2 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 i

3 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 ii

4 Índice 1 Introdução Framework CEO Definição de um Processo de Negócio Especificação da Estrutura do Processo Especificação Funcional do Processo BPEL4WS Relação com o WSDL Definição de um Processo de Negócio Especificação do Serviço Associado ao Processo Especificação Funcional do Processo Conversão entre FCEO e BPEL4WS Extensão ao Perfil UML da FCEO Delineação do Processo de Conversão UML BPEL Organização do Espaço Nomes Notação Geração dos Ficheiros XSD, WSDL e BPEL Conversão dos Tipos de Dados e Mensagens Geração dos Ficheiros XSD e WSDL Conversão das Propriedades e Conjuntos de Correlação Notação Geração dos Ficheiros WSDL e BPEL Conversão dos Protocolos de Negócio Notação Geração do Ficheiro WSDL Conversão de Processos Notação Geração do Ficheiro BPEL Manipulação do Estado do Processo Linguagem XPath Expressões de Acesso aos Dados Francisco Santos iii

5 4.8.3 Expressões de Atribuição Geração das Actividades BPEL Conversão do Diagrama de Actividades Implementação Conclusão Apêndice A Ficheiro WSDL Protocolo Encomendar Apêndice B Ficheiro BPEL ProcessoReceberEcomenda Apêndice C Conversão de Tipos Básicos da UML para o Formato XSD Apêndice D Conversão para o Perfil versão UML Referências Francisco Santos iv

6 Lista Figuras Figura 2.1 Diagrama de Classes para a Estrutura dos Recursos Figura 2.2 Diagrama de Actividades para o ProcessoReceberEncomenda Figura 2.3 Diagrama de Actividades para o Processo de Desenvolvimento Software Figura 2.4 Diagrama de Actividades com actividades aninhadas Figura 2.5 Nós de decisão e de fusão Figura 2.6 Utilização explícita de nós de difusão e de junção Figura 2.7 Diagrama de Actividades com fluxo de objectos Figura 2.8 Diagrama de Actividades com fluxo de objectos e pistas Figura 3.1 Processo de Recepção de Encomendas Figura 4.1 Diagrama de Actividades para o Processo Receber Encomenda Figura 4.2 Tipos de Dados e Mensagens Figura 4.3 Protocolos de Negócio, Papéis e Interfaces Figura 4.4 Processo Recepção de Encomendas Figura 4.5 Diagrama de Actividades detalhado para o Processo Receber Encomenda Figura 4.6 Esquema dos Documentos XML gerados pelo Processo de Conversão Figura 4.7 Exemplo de Dependência entre Pacotes Figura 4.8 Notação para o pacote e para a dependência entre pacotes Figura 4.9 Cenário Conversão para uma Encomenda Figura 4.10 Ficheiro XSD correspondente aos Tipos de Dados Base da Encomenda Figura 4.11 Ficheiro WSDL correspondente à Encomenda Figura 4.12 Notação para as Propriedades Figura 4.13 Exemplo da inclusão de um Conjunto de Correlação num Processo Figura 4.14 Exemplo de uma Actividade que usa Correlação Figura 4.15 Definição Propriedades em WSDL Figura 4.16 Definição de Conjuntos de Correlação em BPEL Figura 4.17 Definição de Actividades Correlacionadas em BPEL Figura 4.18 Exemplo da Notação dos Protocolos de Negócio e Papéis Figura 4.19 Exemplo da Notação das Interfaces Figura 4.20 Ficheiro WSDL com a definição das Ligações a Parceiros e Papéis Figura 4.21 Exemplo de uma Actividade de Atribuição Francisco Santos v

7 Figura 4.22 Exemplo da conversão de uma Actividade de Atribuição para BPEL Figura 4.23 Exemplo de uma Actividade de Espera Figura 4.24 Exemplo da conversão de uma Actividade de Atribuição para BPEL Figura 4.25 Exemplo da Invocação de Operações Síncronas e Assíncronas 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 Figura 4.28 Exemplo da Conversão de Actividades de Recepção e Resposta Figura 4.29 Exemplo da utilização de Actividades de Decisão Figura 4.30 Exemplo da Conversão de uma Actividade de Decisão para BPEL Figura 4.31 Exemplo Diagrama Actividades UML Figura 4.32 Grafo de Actividades BPEL Figura 4.33 Ordenação Topológica Figura 4.34 Árvore BPEL Figura 4.35 Árvore BPEL Optimizada Figura 5.1 Interface Gráfica do Conversor Figura 5.2 Visualizador de Eventos da Plataforma Eclipse Francisco Santos vi

8 Lista Tabelas Tabela 2.1 Um plano de execução para o diagrama de actividades da Figura Tabela 3.1 Principais actividades de um processo BPEL4WS Tabela 4.1 Conversão das Expressões de Multiplicidade Tabela 4.2 Conversão Modelo UML para Formato XSD Tabela 4.3 Atributos para a Definição de um Processo BPEL Tabela 4.4 Exemplos de Expressões de Acesso aos Dados Tabela 4.5 Regras para a Geração da Árvore BPEL Tabela 4.6 Heurísticas de Optimização do Código BPEL Francisco Santos vii

9 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

10 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

11 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 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

12 <<resource>> Produto 1..n <<resource>> Cliente 0..1 <<resource>> Encomenda 1 n 1 1 <<resource>> Factura 1 1 <<resource>> Pagamento 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 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

13 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

14 encomendar Encomendar enviar Enviar facturar Facturar fabricar Fabricar receberencomenda inicializarpedidoentrega calcularpreco pedirescalonamentoproducao pedirentrega enviarprecoentrega receberprazoentrega receberfactura env iarprazoentrega env iarfactura Figura 2.2 Diagrama de Actividades para o ProcessoReceberEncomenda 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

15 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 Figura 2.3 Diagrama de Actividades para o Processo de Desenvolvimento Software 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

16 Actividade 1 Actividade 2 Activitdade 3 Actividade 1 Actividade 3 Actividade 4 Actividade 2 Actividade 5 Actividade 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

17 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 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

18 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 [ tipo de envio = 'urgente' ] [ otherwise ] Enviar Modo Expresso Enviar Modo Normal Fechar Encomenda 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

19 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

20 Receber Proposta Comprador Receber Preço Vendedor [ preço venda <= oferta compra ] [ otherwise ] Enviar Artigo ao Comprador Devolver Artigo ao Vendedor 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 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

21 : Encomenda Receber Encomenda : Encomenda [processada] Produzir Produto : Produto Verificar Produto : Produto [verificado] Emitir Factura : Factura Figura 2.7 Diagrama de Actividades com fluxo de objectos 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

22 Cliente e Dep. p. Comercial l Dep. Produção Efectuar Encomenda : Encomenda Processar Encomenda : Encomenda [processada] : Factura Enviar Factura Produzir Produto Efectuar Pagamento : Pagamento Receber Pagamento : Produto : Produto [enviado] Enviar Produto Receber Produto Figura 2.8 Diagrama de Actividades com fluxo de objectos e pistas Francisco Santos 21

23 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

24 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 Fluxo1 Sequencia1 Gerar Pedido Entrega Requisitar Entrega Sequencia2 Calcular Preço Encomenda Processar Preço Entrega Sequencia3 Pedir Escalonamento Producao Finalizar Escalonamento Producao Receber Prazo Entrega Gerar Factura Enviar Factura Ligação de controlo Figura 3.1 Processo de Recepção de Encomendas Francisco Santos 23

25 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

26 (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) 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

27 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

28 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

29 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

30 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

31 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

32 encomendar enviar facturar fabricar Encomendar Enviar Facturar Fabricar <<receiv e>> receberencomenda <<assign>> inicializarpedidoentrega <<inv oke>> calcularpreco <<inv oke>> pedirescalonamentoproducao <<inv oke>> pedirentrega <<inv oke>> env iarprecoentrega <<receiv e>> receberprazoentrega <<receiv e>> receberfactura <<inv oke>> env iarprazoentrega <<reply >> env iarfactura 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

33 <<messagecontent>> PedidoEntrega <<messagecontent>> Encomenda eid : String +cliente <<data>> Cliente nome : String morada : String +cliente +linhaencomenda <<data>> LinhaEncomenda 1..n <<data>> Linha nomeproduto : String quantidade : Integer precounitario : Float <<messagecontent>> Factura eid : String input : String <<messagecontent>> InformacaoEntrega eid : String input : String <<messagecontent>> PrazoEntrega eid : String input : String <<messagecontent>> EncomendaFault descricaoproblema : String 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

34 <<protocol>> Encomendar <<protocol>> Facturar <<role>> ServicoEncomenda IServicoEncomenda enviarpedidoencomenda() <<role>> ClienteEncomenda <<role>> ServicoFacturacao IServicoFacturacao iniciarcalculopreco() enviarprecoentrega() <<role>> ClienteFacturacao ICallbackFacturacao <<protocol>> Enviar enviarfactura() <<role>> ServicoDistribuicao ICallbackDistribuicao enviarprazoentrega() <<role>> ClienteDistribuicao <<protocol>> Fabricar <<role>> ServicoProducao <<role>> ClienteProducao IServicoDistribuicao IServicoProducao pedirentrega() pedirescalonamentoproducao() enviarprazoentrega() 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

35 <<role>> ServicoEncomenda (from Encomendar) +encomendar 1 <<partnerlink>> <<process>> ProcessoReceberEncomenda encomenda : Encomenda factura : Factura encomendafault : EncomendaFault prazoentrega : PrazoEntrega informacaoentrega : InformacaoEntrega pedidoentrega : PedidoEntrega +facturar 1 <<role>> ClienteFacturacao (from Facturar) <<partnerlink>> <<partnerlink>> <<partnerlink>> 1 +fabricar <<role>> ClienteProducao (from Fabricar) 1 +enviar <<role>> ClienteDistribuicao (from Enviar) 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

36 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. encomendar enviar facturar fabricar Encomendar Enviar Facturar Fabricar <<receiv e>> receberencomenda entry / env iarpedidoencomenda(encomenda) <<assign>> inicializarpedidoentrega entry / pedidoentrega/inf Cliente := encomenda/inf Cliente <<inv oke>> calcularpreco entry / iniciarcalculopreco(encomenda) <<inv oke>> pedirescalonamentoproducao entry / pedirescalonamentoproducao(encomenda) <<inv oke>> pedirentrega entry / inf ormacaoentrega := pedirentrega(pedidoentrega) <<inv oke>> env iarprecoentrega entry / env iarprecoentrega(inf ormacaoen... <<receiv e>> receberprazoentrega entry / env iarprazoentrega(prazoent... <<receiv e>> receberfactura entry / env iarfactura(f actura) <<inv oke>> env iarprazoentrega entry / enviarprazoentrega(prazoent... <<reply >> env iarfactura entry / enviarpedidoencomenda() := f actura 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

37 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

38 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

39 WSDL Protocolo de negócio WSDL Mensagens XSD Tipos de dados WSDL Protocolo de negócio BPEL Processo de negócio importação Figura 4.6 Esquema dos Documentos XML gerados pelo Processo de Conversão Francisco Santos 38

40 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 <<import>> <<import>> <<import>> <<import>> <<protocol>> Facturar <<protocol>> Encomendar <<protocol>> Fabricar <<protocol>> Enviar <<import>> <<import>> <<import>> <<import>> ReceberEncomenda Figura 4.7 Exemplo de Dependência entre Pacotes 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

41 Pacote1 <<import>> Pacote2 Figura 4.8 Notação para o pacote e para a dependência entre pacotes 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

42 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: o nome qualificado corresponde a: Analogamente, o nome qualificado correspondente ao documento TiposDados, contido no pacote DefinicoesEncomenda é dado por: 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

43 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 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

44 Expressão UML minoccurs maxoccurs 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 <<data>> ClasseA attriba : String attribb : Boolean attribc : Integer <<data>> ClasseA n <<data>> ClasseB 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> <!-- geracao tipo ClasseAType --> <xsd:complextype name= ClasseAType > <xsd:sequence> <xsd:element name= classeb type= tns:classebtype minoccurs= 1 maxoccurs= unbounded /> </xsd:sequence> </xsd:complextype> <!-- geracao tipo ClasseBType --> <xsd:complextype name= ClasseBType > <xsd:sequence> <xsd:element name= classea type= tns:classeatype minoccurs= 0 maxoccurs= 1 /> </xsd:sequence> </xsd:complextype> Francisco Santos 43

45 Modelo UML <<data>> ClasseA n <<data>> ClasseA attriba : String <<data>> ClasseB attribb : String <<data>> ClasseB Conversão para XSD <!-- geracao tipo ClasseAType --> <xsd:complextype name= ClasseAType > <xsd:sequence> <xsd:element name= classeb type= tns:classebtype minoccurs= 1 maxoccurs= unbounded /> </xsd:sequence> </xsd:complextype> <!-- geracao tipo ClasseBType --> <xsd:complextype name= ClasseBType /> <!-- geracao tipo ClasseAType --> <xsd:complextype name="classeatype"> <xsd:sequence> <xsd:element name="attriba" type="string"/> </xsd:sequence> </xsd:complextype> <!-- geracao tipo ClasseBType --> <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

46 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. <<messagecontent>> Encomenda eid : String +cliente +linhaencomenda <<data>> Cliente nome : String morada : String <<data>> LinhaEncomenda 1..n <<data>> Linha nomeproduto : String quantidade : Integer precounitario : Float 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

47 <types> <schema xmlns:xsd=" xmlns=" 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

48 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 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

49 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. <<properties>> ConjuntoPropriedades propriedade1 : String propriedade2 : Integer propriedade1(msg1 : TipoMensagem1) : String propriedade1(msg2 : TipoMensagem2) : String propriedade2(msg2 : TipoMensagem2) : Integer propriedade2(msg3 : TipoMensagem3) : Integer 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 Francisco Santos 48

50 <<process>> Processo1 <<correlation>> correlacao1 : ConjuntoCorrelacao1 <<correlation>> ConjuntoCorrelacao1 propriedade1 : String propriedade2 : Integer 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 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. <<receive>> Actividade1 entry/ operacao1(msg1) entry/ <expressão de correlação> 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

51 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: correlacao 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

52 convertermos o exemplo da Figura 4.12 obtemos o código WSDL apresentado na Figura 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. <!-- propriedades --> <bpws:property name= propriedade1 type= xsd:string /> <bpws:property name= propriedade2 type= xsd:int /> <!-- metodos de acesso --> <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 <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

53 <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 uniou 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 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

54 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. <<protocol>> Protocolo1 <<role>> Papel1 Interface1 operacao1() <<role>> Papel2 Interface2 operacao2() 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 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

55 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 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

56 representado através de seis atributos: encomenda, factura, encomendafault, prazoentrega, informacaoentrega e pedidoentrega 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

57 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 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

58 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

59 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 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

60 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 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

61 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 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 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: <<assign>> Atribuicao1 entry/ encomenda/aprovada := 'true' entry/ factura/cliente := encomenda/cliente entry/ 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

62 <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 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

63 <<wait>> esperarpelaproducao 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 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

64 ligacaoparceiro1 ligacaoparceiro2 <<invoke>> invocar1 entry/ operacao1( atrib1 ) <<invoke>> invocar2 entry/ atrib3 := operacao2( atrib2 ) Figura 4.25 Exemplo da Invocação de Operações Síncronas e Assíncronas BPEL: A conversão das actividades de invocação anteriores resulta no seguinte código <!-- actividade de invocação assíncrona, operação: operação1 --> <invoke name="invocar1" partnerlink="ligacaoparceiro1" porttype="ligacaoparceiro1:iservicoxxx" operation="operacao1" inputvariable="atrib1" /> <!-- actividade de invocação síncrona, operação: operação2 --> <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 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

65 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: ligacaoparceiro1 ligacaoparceiro2 <<receive>> receber1 entry/ operacao1( atrib1 ) <<invoke>> invocar2 entry/ operacao2( atrib1 ) <<receive>> receber3 <<reply>> responder1 entry/ operacao3( atrib2 ) entry/ operacao1() := atrib2 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

66 <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 actividade 1. 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 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

67 Actividade 1 Actividade 2 [ cond1 ] [ cond2 ] Actividade 4 [ otherwise ] Actividade 3 Actividade 5 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: <!-- actividade1 --> <switch> <!-- cond1 --> <case condition= > <!-- actividade2 --> <!-- actividade3 --> </case> <!-- 'cond2 --> <case condition= > <!-- actividade4 --> </case> <otherwise> <empty/> </otherwise> </switch> <!-- actividade5 --> 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

68 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 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

69 são adicionados ao grafo de actividades BPEL. Considere-se, como exemplo, o seguinte diagrama de actividades UML: <<receive>> Actividade1 [ cond1 ] [ cond2 ] <<assign>> Actividade2 <<invoke>> Actividade3 <<invoke>> Actividade4 <<wait>> Actividade5 <<reply>> Actividade6 Figura 4.31 Exemplo Diagrama Actividades UML Após todas as actividades da Figura 4.31 terem sido convertidas obtém-se o seguinte grafo BPEL: BPELReceive nome: Actividade1 cond: cond1 BPELSwitch nome: Decisao1 cond: cond2 BPELInvoke nome: Actividade4 BPELAssign nome: Actividade2 BPELInvoke nome: Actividade3 BPELWait nome: Actividade5 BPELMerge nome: Fusao1 BPELReply nome: Actividade6 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

70 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

71 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. A B C D E F G Ordenação topológica possível: A,B,C,D,F,E,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

72 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) (u, v) é arco de árvore (u, v) é arco para a frente ou de cruzamento, onde v não é um BPELMerge Actividade u BPELSwitch BPELMerge 2 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. Pesquisar a partir de v e adicionar todas as actividades encontradas a seguir ao BPELSwitch correspondente. 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. Criar uma ligação de controlo entre o BPELSwitch correspondente e v. 2 Pressupõe a existência de um BPELSwitch prévio Francisco Santos 71

73 Arco (u, v) Actividade u Grau saída de u superior a um Grau de saída de u igual a um (u, v) é arco de árvore 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. Todas as actividades encontradas a partir de v são adicionadas à BPELSequence actual. (u, v) é arco para a frente ou de cruzamento, onde v não é um BPELMerge Criar uma ligação de controlo entre u e v para cada arco (u, v) deste tipo. Criar uma ligação de controlo entre u e v. Tabela 4.5 Regras para a Geração da Árvore BPEL Aplicando as regras da Tabela 4.5 ao grafo da Figura 4.32 obtém-se a árvore BPEL ilustrada em baixo. Francisco Santos 72

74 Fluxo1 Sequencia1 Actividade1 Fluxo2 Sequencia2 Seq4 cond1 Actividade2 Decisao1 cond2 Seq5 Actividade3 Sequencia3 Actividade4 Actividade5 Actividade6 Ligação de controlo 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

75 Actividades BPEL BPELEmpty Heurísticas de Optimização H1 Caso não possua ligações de controlo (entrada ou saída): remover a actividade. BPELWait H2 Se a expressão temporal for vazia: aplicar H1. BPELAssign H3 Se a lista de atribuições for nula: aplicar H1. BPELSequence H4 Para cada actividade da BPELSequence aplicar H1 até H3. H5 Se após a aplicação de H4 a BPELSequence ficar vazia: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo da BPELSequence à actividade BPELEmpty e substituir a BPELSequence pela actividade BPELEmpty. H6 Se após a aplicação de H4 a BPELSequence contiver uma só actividade: adicionar as ligações de controlo da BPELSequence à actividade e substituir a BPELSequence pela actividade constituinte. BPELFlow H7 Para cada actividade concorrente aplicar H1 até H3. H8 Se após a aplicação de H7 não restarem fluxos concorrentes: aplicar H1; se existirem ligações de controlo: criar uma actividade BPELEmpty, adicionar as ligações de controlo do BPELFlow à actividade BPELEmpty e substituir o BPELFlow pela actividade BPELEmpty. H9 Se após a aplicação de H7 existir apenas um fluxo de execução e o BPELFlow não armazenar informação sobre as ligações de controlo entre actividades 3 : 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

76 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

77 Sequencia1 Actividade1 Fluxo2 cond1 Actividade2 Decisao1 cond2 Actividade3 Sequencia3 Actividade4 Actividade5 Actividade6 Ligação de controlo Figura 4.35 Árvore BPEL Optimizada Francisco Santos 76

78 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 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

79 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 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, e Francisco Santos 78

80 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

81 Figura 5.1 Interface Gráfica do Conversor Figura 5.2 Visualizador de Eventos da Plataforma Eclipse Francisco Santos 80

82 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

83 Apêndice A Ficheiro WSDL Protocolo Encomendar <?xml version="1.0"?> <definitions name="encomendar targetnamespace=" xmlns:tns=" xmlns:plnk=" xmlns:def=" Encomenda" xmlns:bpws=" xmlns=" > <import namespace=" Encomenda" location="definicoesencomenda.wsdl"/> <!-- ================================================================= --> <!-- Definição dos tipos de portos: agrupam um conjunto de operações --> <!-- numa unidade lógica. --> <!-- ================================================================= --> <porttype name="iservicoencomenda"> <operation name="enviarpedidoencomenda"> <input message="def:encomenda" /> <output message="def:factura"/> <fault name="impossivelfinalizarencomenda" message="def:encomendafault"/> </operation> </porttype> <!-- ================================================================= --> <!-- Definição das ligações aos parceiros de negócio e dos papéis --> <!-- ================================================================= --> <plnk:partnerlinktype name="encomendar"> <plnk:role name="servicoencomenda"> <plnk:porttype name="tns:iservicoencomenda"/> </plnk:role> </plnk:partnerlinktype> </definitions> Francisco Santos 82

84 Apêndice B Ficheiro BPEL ProcessoReceberEcomenda <process name="processoreceberencomenda" suppressjoinfailure="yes" targetnamespace=" ProcessoReceberEncomenda" xmlns=" xmlns:tns=" soreceberencomenda" xmlns:fabricar=" xmlns:bpws=" xmlns:enviar=" xmlns:encomendar=" xmlns:def=" xmlns:xsd=" xmlns:bpelx=" xmlns:ora=" xmlns:facturar=" <!-- ================================================================= --> <!-- PARTNERLINKS --> <!-- Lista de parceiros de negócio associados ao processo --> <!-- ================================================================= --> <partnerlinks> <!-- The 'client' role represents the requester of this service. --> <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 --> <!-- Lista das mensagens e documentos XML usados pelo processo --> <!-- ================================================================= --> <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

85 <!-- CORRELATION SETS --> <!-- Lista dos conjuntos de correlação --> <!-- ================================================================= --> <correlationsets> <correlationset name="encomenda" properties="def:encomendaid"/> <correlationset name="prazoentrega" properties="def:encomendaid"/> </correlationsets> <!-- ================================================================= --> <!-- ORCHESTRATION LOGIC --> <!-- Conjunto de actividades que coordenam o fluxo das mensagens entre --> <!-- o processo e os parceiros de negócio --> <!-- ================================================================= --> <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

86 <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

87 Apêndice C Conversão de Tipos Básicos da UML para o Formato XSD Tipo Elementar UML Boolean Byte Currency Date Double Float Integer Long Single String Tipo Simples XSD boolean byte decimal datetime double float int long float string Francisco Santos 86

88 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 <<receive>> receber entry/ correlation: initialize correlacao1 entry/ operacao1( atrib1 ) <<invoke>> invocar entry/ correlation: initialize correlacao2 entry/ atrib2 := operacao2( atrib1 ) <<reply>> responder entry/ correlation: correlacao1 entry/ operacao1() := atrib2 <<assign>> atribuicao entry/ msg2/secb := msg1/seca 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. 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. 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. Na UML 2, as expressões de atribuição da acção <<assign>> são modeladas através de restrições. Francisco Santos 87

89 Perfil versão UML 1.5 Perfil versão UML 2.0 Descrição <<wait>> esperar24h entry/ for 'P1DT' Na UML 2, as expressões temporais da acção <<wait>> são modeladas através de restrições. [ cond1 ] [ cond2 ] <<receive>> Actividade1 Na UML 2, o fluxo entre actividades deve ser modelado através do fluxo de controlo e não do fluxo de objectos. <<assign>> Actividade2 <<invoke>> Actividade3 <<invoke>> Actividade4 <<wait>> Actividade5 <<reply>> Actividade6 Francisco Santos 88