Na primeira fase do trabalho foi desenvolvida uma biblioteca dedicada à manipulação de grafos, para servir de base à implementação do algoritmo de conversão, descrito na Secção 4.8.5. Os algoritmos para a travessia em largura e em profundidade foram implementados na sua versão iterativa por questões de eficiência: espaço ocupado em memória e tempo de execução. O algoritmo de conversão estende a classe para a travessia em profundidade, definida na biblioteca, e reutiliza o método de classificação de arcos do grafo.
Para o primeiro protótipo da solução foi usado um processador de expressões XPath: designado Java XPath Engine (Jaxen), para ler o modelo UML a partir de um ficheiro XMI 1.1. Nesta implementação adoptou-se a estratégia de seguir a sequência de nós da árvore do documento XML para a conversão do modelo UML. Esta solução revelou-se impraticável visto que é necessário consultar mais do que uma parte do modelo em simultâneo durante a conversão. O primeiro protótipo serviu apenas para testar e desenvolver as principais ideias do algoritmo de conversão baseado em grafos, centrando-se no diagrama de actividades associado ao processo. Para converter a totalidade do modelo tornava-se necessário usar uma representação em memória do modelo UML do utilizador, que permitisse um acesso eficiente a todos os seus elementos constituintes. O projecto UML2 sobre a plataforma Eclipse [Hussey05] veio responder a esta necessidade.
Embora adequado à solução do problema, o projecto UML2 disponibiliza documentação insuficiente sobre a sua utilização, existindo, à data da escrita deste relatório, poucos artigos publicados sobre o assunto: [Hussey05], [Hussey05b] e [Misic05]. O projecto Eclipse UML2 representa uma implementação do meta-modelo UML2 e é baseado no projecto Eclipse Modelling Framework (EMF), através do qual tem capacidade para fazer importação e exportação dos modelos para XMI 2.0. A utilização do meta-modelo UML versão 2 obrigou à conversão do perfil de modelação de negócio, descrito neste documento, que estava inicialmente adaptado à versão 1.5 do meta-modelo. Os diagramas de actividades sofreram várias modificações ao longo das versões da UML. Por este motivo, não é surpreendente que na versão 2 da UML o
diagrama de actividades tenha sido significativamente estendido e alterado [Fowler04]. Na UML2 os diagramas de actividades deixaram de ser uma especialização dos diagramas de estados. Na UML1 existiam regras para o balanceamento dos nós de difusão e de junção, que deixaram de existir na nova versão. Os nós do diagrama de actividades são agora designados por: “acções”, sendo que uma “actividade” se refere a uma sequência de acções e o diagrama de actividades mostra uma actividade, composta por várias acções. Os nós de decisão, designados por “ramos” na UML1, possuem um único fluxo de entrada e vários fluxos de saída. Cada fluxo de saída possui uma “condição de transição”, representada por uma expressão booleana, colocada entre parênteses rectos. A partir de um nó de decisão apenas um fluxo de saída pode ser escolhido, sendo por isso necessário que as condições de transição sejam mutuamente exclusivas. O nó de fusão, ao contrário do nó de decisão, possui múltiplos fluxos de entrada e apenas um de saída. Este nó é usado para assinalar o final de um nó de decisão. Finalmente, na UML1 múltiplos fluxos de entrada significavam uma fusão implícita dos fluxos, sendo apenas necessário que um fluxo estivesse activo para que a acção se executasse. Na nova versão, este comportamento foi modificado de forma a existir uma junção (sincronização) implícita dos fluxos de entrada de uma acção. Este aspecto em particular já tinha sido contemplado no perfil descrito em [AGGI03], pelo que não foi necessário modificar o comportamento descrito na Secção 2.1.2. No Apêndice D – Conversão para o Perfil versão UML 2.0 – encontra-se uma descrição das modificações necessárias ao perfil para poder ser usado na versão 2 da linguagem UML. O algoritmo de conversão encontra-se implementado sobre a forma de um componente para a plataforma Eclipse. A principal vantagem desta plataforma é a possibilidade de desenvolver aplicações num curto espaço de tempo, estendendo e reutilizando outros componentes existentes na plataforma, nomeadamente os componentes: UML2 e EMF. Adicionalmente, devido ao crescente interesse das empresas da área informática nesta plataforma de desenvolvimento, e no componente UML2 em particular, favorece a longevidade da solução proposta. A conversão e optimização das expressões XPath, contidas no próprio modelo UML, ficam a cargo do processador Jaxen, usando as regras de conversão descritas na Secções: 4.8.1, 4.8.2 e 4.8.3.
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.
Figura 5.1 – Interface Gráfica do Conversor