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.

receberEncomenda <<receiv e>> env iarFactura <<reply >> inicializarPedidoEntrega <<assign>> pedirEntrega <<inv oke>> receberPrazoEntrega <<receiv e>> env iarPrecoEntrega <<inv oke>> receberFactura <<receiv e>> calcularPreco <<inv oke>> pedirEscalonamentoProducao <<inv oke>> env iarPrazoEntrega <<inv oke>> Fabricar Facturar Enviar Encomendar

encomendar enviar facturar fabricar

Figura 4.1 – Diagrama de Actividades para o Processo Receber Encomenda

Os tipos de dados devem ser representados através de classes UML com o estereótipo <<data>>, conforme ilustrado na Figura 4.2. Estes tipos de dados podem ser usados directamente pelas operações das interfaces dos protocolos de negócio ou, alternativamente, como parte de mensagens mais complexas (ex.: ‘PedidoEntrega’ e ‘Encomenda’). Todos os tipos de dados base foram colocados no pacote ‘DefinicoesEncomenda’. As mensagens, que são definidas à custa dos tipos de dados base, também se encontram definidas no mesmo pacote. Por exemplo, a mensagem ‘Encomenda’ é composta por dois tipos de dados base: ‘Cliente’, que contém informação sobre o cliente, e ‘LinhaEncomenda’, que contém informação sobre os vários produtos que foram encomendados.

Cliente nome : String morada : String <<data>> PedidoEntrega <<messageContent>> +cliente EncomendaFault descricaoProblema : String <<messageContent>> Factura eid : String input : String <<messageContent>> InformacaoEntrega eid : String input : String <<messageContent>> PrazoEntrega eid : String input : String <<messageContent>> Encomenda eid : String <<messageContent>> +cliente Linha nomeProduto : String quantidade : Integer precoUnitario : Float <<data>> LinhaEncomenda <<data>> +linhaEncomenda 1..n 1..n

Figura 4.2 – Tipos de Dados e Mensagens

O processo participa num protocolo através das ligações aos parceiros de negócio. Um protocolo liga um par de papéis complementares, associados a cada um dos parceiros, e especifica como é que esses papéis interagem. Cada papel disponibiliza, opcionalmente, um conjunto de interfaces através das quais o papel complementar pode interagir. As interfaces juntamente com os papéis complementares encontram-se definidas em pacotes próprios com o estereótipo <<protocol>>. Na Figura 4.3 são apresentados os protocolos de negócio, os papéis e as interfaces.

Encomendar <<protocol>> ClienteEncomenda <<role>> ServicoEncomenda <<role>> IServicoEncomenda enviarPedidoEncomenda() Enviar <<protocol>> ClienteDistribuicao <<role>> ServicoDistribuicao <<role>> ICallbackDistribuicao enviarPrazoEntrega() IServicoDistribuicao pedirEntrega() Fabricar <<protocol>> ClienteProducao <<role>> ServicoProducao <<role>> IServicoProducao pedirEscalonamentoProducao() enviarPrazoEntrega() Facturar <<protocol>> IServicoFacturacao iniciarCalculoPreco() enviarPrecoEntrega() ICallbackFacturacao enviarFactura() ClienteFacturacao <<role>> ServicoFacturacao <<role>>

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

Nesta fase, todas as definições necessárias ao processo foram fornecidas. Embora estas definições tenham sido introduzidas no contexto do processo recepção de encomendas, podem ser usadas independentemente do processo. Se os parceiros também forem modelados como processos de negócio automatizados, então também podem fazer uso destas definições. Mais genericamente, outros processos que disponibilizem todos ou apenas uma parte dos papéis do processo recepção de encomendas podem fazer uso destas definições.

Na Figura 4.4 é apresentada a classe ‘ProcessoReceberEncomenda’, com o estereótipo <<process>>, que representa o processo recepção de encomendas. O estado do processo é descrito pelos atributos da classe ‘ProcessoReceberEncomenda’, cujos tipos de dados foram introduzidos no pacote ‘Encomenda’ ou importados do pacote ‘DefinicoesEncomenda’. Adicionalmente possui quatro associações a papéis de negócio, correspondentes aos quatros parceiros com os quais interage, definidos nos pacotes <<protocol>> da Figura 4.3.

ServicoEncomenda

(from Encom endar)

<<role>> ClienteFacturacao (from Facturar) <<role>> ClienteProducao (from Fabricar) <<role>> ClienteDistribuicao (from Enviar) <<role>> ProcessoReceberEncomenda encomenda : Encomenda factura : Factura encomendaFault : EncomendaFault prazoEntrega : PrazoEntrega informacaoEntrega : InformacaoEntrega pedidoEntrega : PedidoEntrega <<process>> 1 +encomendar ¹ <<partnerLink>> 1 +facturar 1 <<partnerLink>> 1 +fabricar 1 <<partnerLink>> 1 +enviar 1 <<partnerLink>>

Figura 4.4 – Processo Recepção de Encomendas

Cada ligação a um parceiro de negócio constitui um ponto de ligação para um parceiro do processo. As interfaces, que são disponibilizadas ou solicitadas através de uma ligação, estão definidas pelo papel que o processo desempenha no protocolo. Uma ligação a um parceiro de negócio é representada por uma associação, com o estereótipo <<partnerLink>>, entre o processo e o papel que este desempenha.

O ‘ProcessoReceberEncomenda’ disponibiliza a sua interface ‘IServicoEncomenda’ através da ligação ‘encomendar’, correspondente ao protocolo ‘Encomendar’, e solicita serviços através das restantes ligações: ‘facturar’, ‘fabricar’ e ‘enviar’. A ligação ‘facturar’ suporta comunicação bidireccional: o processo solicita a interface ‘IServicoFacturacao’ e disponibiliza a interface ‘ICallbackFacturacao’, tal como especificado pelo papel ‘ClienteFacturacao’ do protocolo ‘Facturar’. A ligação ‘enviar’ também é bidireccional, neste caso o processo solicita a interface ‘IServicoDistribuicao’ e disponibiliza a interface ‘ICallbackDistribuicao’.

O diagrama de actividades na Figura 4.5 mostra o comportamento do processo recepção de encomendas, fazendo parte da classe ‘ProcessoReceberEcomenda’. É idêntico ao diagrama da Figura 4.1 excepto que exibe um maior nível de detalhe. Cada pista do diagrama corresponde a uma ligação a um parceiro de negócio. Actividades que

representem uma interacção através de um porto, seja de entrada ou de saída, associado a um determinado parceiro de negócio, são colocadas na pista respectiva, com setas de controlo de fluxo a indicar a sua sequência de execução. Cada actividade é identificada por um nome descritivo. As acções de entrada, representadas por um evento do tipo entry, descrevem o trabalho realizado numa dada actividade.

receberEncomenda <<receiv e>>

entry / env iarPedidoEncomenda(encomenda)

env iarFactura <<reply >> entry / env iarPedidoEncomenda() := f actura

inicializarPedidoEntrega <<assign>>

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

pedirEntrega <<inv oke>>

entry / inf ormacaoEntrega := pedirEntrega(pedidoEntrega)

receberPrazoEntrega <<receiv e>>

entry / env iarPrazoEntrega(prazoEnt...

env iarPrecoEntrega <<inv oke>> entry / env iarPrecoEntrega(inf ormacaoEn...

receberFactura <<receiv e>> entry / env iarFactura(f actura)

calcularPreco <<inv oke>> entry / iniciarCalculoPreco(encomenda) pedirEscalonamentoProducao <<inv oke>> entry / pedirEscalonamentoProducao(encomenda) env iarPrazoEntrega <<inv oke>>

entry / env iarPrazoEntrega(prazoEnt...

Fabricar Facturar

Enviar Encomendar

encomendar enviar facturar fabricar

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

A actividade ‘receberEncomenda’ contém o estereótipo <<receive>>, tratando-se, por isso, da recepção de uma mensagem através de uma ligação, neste caso da ligação ‘encomendar’. A expressão:

enviarPedidoEncomenda(encomenda)

indica o nome da operação a invocar, através da ligação ‘encomendar’, e o nome do atributo onde a mensagem recebida é guardada. A actividade ‘enviarFactura’ possui o estereótipo <<reply>> indicando que o resultado deve ser enviado ao invocador da anterior actividade <<receive>>. Ambas as actividades fazem referência à mesma

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.