Geração de código orientado a serviço a partir de modelos de processos de negócio

1. Geração de código orientado a serviço a partir de modelos de processos de negócio Douglas Barbosa Alexandre Orientador: Prof. Dr. André Vital Saúde UFLA – Universidade Federal de Lavras

2. Roteiro • Motivação • Problema • Objetivos • Conceitos Básicos • Metodologia • Redbox • Conclusão • Referências Bibliográficas

3. Motivação • Grande demanda por sistemas que sejam de fácil modelagem, implementação e manutenção. • Crescimento da importância da modelagem de processos. • Inserido no crescimento da Gestão de Processos de Negócio (BPM - Business Process Management). • Maior adoção da arquitetura orientada a serviços (SOA – Service-OrientedArchitecture). • Sendo esta uma inovação advinda de uma nova visão computacional, definindo novas regras para facilitar o desenvolvimento de aplicações.

4. Motivação • Disponibilidade ao longo dos últimos anos de tecnologias que formaram a base necessária para que o uso efetivo de BPM fosse possível, a exemplo temos: • Business ProcessModelingNotation(BPMN) • XMLProcessDefinitionLanguage (XPDL) • Service-OrientedArchitecture(SOA).

5. Motivação • É de interesse que possamos unir estas tecnologias a fim de facilitar e agilizar o desenvolvimento de uma aplicação, utilizando para isto a geração automática de código. • Para isto iremos buscar as informações necessárias nos modelos de processo de negócio já modelados através da notação BPMN.

6. Problema • Entender como identificar serviços válidos em um modelo de processo de negócio. • E a partir da identificação destes serviços, como gerar o código necessário para implementação deste ou como associá-lo a um serviço já disponível.

7. Objetivos • Estudar a arquitetura orientada a serviço (SOA – ServiceOrientedArchitecture); • Estudar a notação BusinessProcessModelingNotation (BPMN); • Estudo das técnicas para identificação de serviços nos modelos de processo de negócio; • Estudo das ferramentas de modelagem BPMN, e como e até que ponto estas ferramentas geram código em Java;

8. Objetivos • Estudo da linguagem XMLProcessDefinitionLanguage (XPDL); • Estudo das técnicas de geração automática de código; • Desenvolver um gerador de código orientado a serviço em Java a partir dos serviços identificados nos modelos de processos de negócio descritos em BPMN.

9. Conceitos Básicos

10. Business Process • É uma seqüência de tarefas e atividades que envolvem pessoas e recursos para que se possa atingir um objetivo previamente traçado. Uma vez que este objetivo foi alcançado, podemos dizer que processo está completo. • Como exemplo podemos citar: • Contratação de um empregado; • Processamento de uma ordem de vendas; • Reembolso de gastos por uma empresa;

11. Business Process Management • BPM é um conceito que une gestão de negócio e tecnologia da informação voltado à melhoria dos processos de negócio das organizações. • Não requer SOA, mas ao se utilizar SOA simplifica muito as implementações BPM.

12. Business ProcessModelingNotation • BPMN é uma notação gráfica que descreve a lógica e as etapas de um processo de negócio. • BPMN é independente de qualquer metodologia para modelagem de processos. • BPMN é um padrão aceitointernacionalmente. • BPMN permite a especificação dos fluxos num nível de detalhamento próximo da complexidade de um ambiente real.

13. Business ProcessModelingNotation

14. XML ProcessLanguageDefinition • XPDL é uma linguagem que estabelece um modelo para intercâmbio de processos de negócio entre as diversas ferramentas de modelagem existentes • XPDL é um padrão aceitointernacionalmente. • Sua especificação é totalmente compatível com o padrão BPMN.

15. XML ProcessLanguageDefinition • Para os criadores do XPDL, o BPMN é o padrão ideal para modelar o processo em nível visual e o XPDL para definir suas regras em nível técnico. • Os elementos da notação BPMN podem ser encontradas na sintaxe do XPDL sendo que para cada elemento existe um código apropriado.

16. XML ProcessLanguageDefinition • A principal diferença conceitual entre o padrão BPMN e o XPDL é referente ao conceito de atividade. • Este conceito no XPDL é utilizado para modelar diversos elementos da notação BPMN entre eles: • Tarefas; • Subprocesso; • Gateway; • Eventos.

17. XML ProcessLanguageDefinition

18. Service-OrientedArchitecture • Conjunto de práticas de organização de sistemas de TI que permitem grande agilidade no atendimento das demandas geradas pelo negócio, reduzindo custos e tornando a área de TI mais dinâmica. • A agilidade é resultado de um processo simplificado para criação de novas funcionalidades, através da: • Integração de sistemas; • Reaproveitamento em larga escala de código; • Possibilidade de intercambiar funcionalidades entre os diversos setores da empresa.

19. Metodologia

20. Identificação de Serviços Válidos em um Modelo de Processo de Negócio: • Utilizou-se como base a etapa de identificação e classificação dos serviços candidatos da técnica proposta por Azevedo etal (2009) com algumas exceções. • Nesta etapa as atividades devem ser analisadas dentro dos seus contextos nos modelos de processos, segundo um conjunto de heurísticas que levam em consideração: • a semântica da atividade (regras de negócio, requisitos de negócio ); • quanto à estrutura do fluxo de atividades (padrões de workflow); • e também a presença de fluxos recorrentes.

21. Identificação de Serviços Válidos em um Modelo de Processo de Negócio: • Exceções aplicadas nesta etapa: • Análise dos padrões referentes aos fluxos recorrentes; • Consolidação dos serviços candidatos.

22. Identificação de Serviços Válidos em um Modelo de Processo de Negócio: • Dentre as nove heurísticas propostas por Azevedo etal (2009): • Quatro foram implementadas diretamente neste trabalho; • Uma no caso, a heurística número um, foi implementada, mas sofreu algumas mudanças na sua implementação; • As outras quatro heurísticas não foram implementadas neste trabalho.

23. Heurística 1 (Exceção) • Um serviço deve ser identificado a partir de uma regra de negócio. • A notação BPMN não possui um elemento que define explicitamente uma regra de negócio. • Regras de negócio são declaradas em gateways que ficam responsáveis por realizar o controle do fluxo do processo.

24. Heurística 1 (Exceção) • Um serviço deve ser identificado a partir de uma regra de negócio. • Nossa solução traz o gateway para dentro do serviço que ficará responsável por representá-lo como um todo. • A regra de negócio deverá ser implementada manualmente no serviço, no corpo do método gerado especificamente para este propósito devido a falta de informações presentes no modelo de processo de negócio.

25. Heurística 2 • Um serviço deve ser identificado a partir de um requisito de negócio.

26. Heurística 3 • Um serviço deve ser identificado a partir de um conjunto de atividades seqüenciais.

27. Heurística 4 • Um serviço deve ser identificado a partir de um gateway paralelo.

28. Heurística 5 • Um serviço deve ser identificado a partir de um gateway exclusivo.

29. Geração Automática de Código • Nosso gerador de código utiliza a técnica de transformações baseadas em modelos. • Vantagem: as entidades geradas podem ser alteradas sem precisar que nenhuma alteração seja realizada na aplicação que executa a transformação.

30. Geração Automática de Código • Este modelo é composto de quatro componentes

31. Redbox

32. Objetivo • Preencher a lacuna existente atualmente no mercado; • Diminuir a carga de trabalho sobre o analista SOA; • Implementar um método automático e de fácil extensão para identificação de serviços baseado nos modelos de processo de negócio que utilizam a notação BPMN em sua modelagem; • Gerar todo o código necessário a partir de transformações baseadas em modelos para implementar estes serviços ou delegar a sua execução a serviços já implementados pela organização seguindo o padrão de arquitetura SOA.

33. Arquitetura

34. Estrutura do Modelo de Dados • Estrutura em árvore onde cada elemento desta árvore representa um serviçoidentificado; • Os elementos desta árvore são do tipo abstrato “ServiceDescriptor” o qual pode referenciar um dos quatro tipos de serviços abaixo que o herdam: • “SimpleServiceDescriptor”; • “BundledServicesDescriptor”; • “ExclusiveServiceDescriptor”; • “ParallelServiceDescriptor”.

35. Estrutura do Modelo de Dados

37. Identificação dos Serviços Válidos • O algoritmo implementado neste trabalho trabalha de maneira recursiva percorrendo todos os processos descritos no XPDL em duas etapas.

38. Identificação dos Serviços Válidos • 1ª Etapa: A partir da atividade inicial enquanto houver mais atividades no processo, crie um novo serviço a partir do tipo da atividade informada associando-o a lista de serviços do processo e retornando para este método a próxima atividade após o serviço criado.

39. Identificação dos Serviços Válidos • 2ª Etapa: Após ser realizada a identificação e o agrupamento da primeira etapa, na lista de serviços para o processo em questão encontram-se apenas serviços simples que devem ser agrupados de forma linear para representar processo como um todo.

40. Identificação dos Serviços Válidos • Se a atividade informada possui o atributo estendido “Service”, quer dizer que o serviço que implementa esta atividade já foi desenvolvido pela organização, e este serviço gerado deverá chamar o serviço existente. • Caso contrários, é gerado um serviço stub a ser completado pelo desenvolvedor.

41. Exemplo createSimpleService(...) createService(...) Atividade Inicial

42. Exemplo createSimpleService(...) createService(...) createParallelService(...) createService(...) Atividade retornada createService(...) createExclusiveService(...)

43. Exemplo Atividade retornada createSimpleService(...) createService(...)

44. Exemplo Atividade retornada

45. Exemplo

46. Exemplo

47. Exemplo Atividade retornada createSimpleService(...) createService(...)

48. Exemplo Atividade retornada

49. Exemplo createSimpleService(...) createService(...)

50. Exemplo Atividade retornada createSimpleService(...) createService(...)