Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Uma Abordagem Dirigida por Modelos para Gerência
de Variabilidades e Execução de Processos de
Software
Wanderson Câmara dos Santos
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Uma Abordagem Dirigida por Modelos para Gerência
de Variabilidades e Execução de Processos de
Software
Dissertação submetida ao Programa de Pós-Graduação em Sistemas e Computação do De-partamento de Informática e Matemática Apli-cada da Universidade Federal do Rio Grande do Norte como parte dos requisitos para a obtenção do grau de Mestre em Sistemas e Computação.
Autor: Wanderson Câmara dos Santos
Orientador: Prof. Dr. Uirá Kulesza
Wanderson.
• Gostaria de agradecer a deus, por tudo, porque quem tem Deus como império no
mundo não está sozinho.
• Ao meu orientador Prof. Dr. Uirá Kulesza, pela sua dedicação e paciência.
• Aos meus avós Itamar Câmara e Terezinha Freitas Câmara, por me ensinar a sonhar
e por simplesmente acreditarem que poderia transformar meus sonhos em realidade;
• Aos meus pais Edivaldo José dos Santos e Irismar Freitas Câmara dos Santos, que
estão me ajudando a realizar estes sonhos;
• Aos meus irmãos Walderson e Iza, por serem simplesmente tão especiais;
• Aos amigos Silvano Maia, Hamilton Rangel, Guto de Castro e Peter Keussen pelos
ensinamentos e amizade;
• A todas as pessoas que me apoiaram e estiveram presente durante todos os
momen-tos.
Este trabalho apresenta uma abordagem dirigida por modelos para gerência de vari-abilidades em processos desoftware, assim como sua implantação em sistemas de work-flow. A abordagem é fundamentada nos princípios e técnicas de linhas de produto de software e engenharia dirigida por modelos. Engenharia dirigida por modelos fornece
suporte para a especificação de processos de software e sua transformação em especifi-cações de fluxo de trabalho. Técnicas de linhas de produto de software permitem a gerên-cia automática de variabilidades de elementos do processo e fragmentos. Além disso, em nossa abordagem, tecnologias de workflows permitem a execução do processo em mo-tores de workflow. Para avaliar a viabilidade abordagem, a implementamos utilizando tecnologias existentes de engenharia dirigida por modelos. Os processos de software são especificados usando Eclipse Processo Framework (EPF). O gerenciamento automático das variabilidades de processos de software foi implementado como uma extensão de uma ferramenta de derivação produtos já existente. Finalmente, as linguagens de trans-formação ATL e Acceleo são adotadas para transformar o processo EPF para a linguagem de especificações de fluxo de trabalho jPDL, a fim de permitir a implantação e execução de processos de software no motor de workflow JBoss BPM. A abordagem é avaliada através da modelagem e modularização da disciplina de gerenciamento de projetos do processo aberto Unificado (OpenUP).
Palavras-chave: Processo de software, Execução de processos, Reuso de Processo de Software, Desenvolvimento Dirigido por Modelos
This dissertation presents a model-driven and integrated approach to variability man-agement, customization and execution of software processes. Our approach is founded on the principles and techniques of software product lines and model-driven engineering. Model-driven engineering provides support to the specification of software processes and their transformation to workflow specifications. Software product lines techniques allows the automatic variability management of process elements and fragments. Additionally, in our approach, workflow technologies enable the process execution in workflow en-gines. In order to evaluate the approach feasibility, we have implemented it using exist-ing model-driven engineerexist-ing technologies. The software processes are specified usexist-ing Eclipse Process Framework (EPF). The automatic variability management of software processes has been implemented as an extension of an existing product derivation tool. Finally, ATL and Acceleo transformation languages are adopted to transform EPF process to jPDL workflow language specifications in order to enable the deployment and execu-tion of software processes in the JBoss BPM workflow engine. The approach is evaluated through the modeling and modularization of the project management discipline of the Open Unified Process (OpenUP).
Key words: Software process, Process execution, Software process reuse, Model driven development
Sumário
Lista de Figuras p. xi
1 Introdução p. 1
1.1 Problema . . . p. 2
1.2 Limitações das Abordagens Atuais . . . p. 3
1.3 Trabalho Proposto . . . p. 3
1.4 Objetivos . . . p. 4
1.5 Organização do trabalho . . . p. 5
2 Fundamentação Teórica p. 6
2.1 Engenharia de Processos . . . p. 6
2.2 Reuso em Processos deSoftware . . . p. 8
2.2.1 Eclipse Process Framework . . . p. 9
2.3 Linhas de Produto deSoftware . . . p. 10
2.3.1 Ferramentas de Derivação . . . p. 11
2.4 Engenharia Dirigida por Modelos . . . p. 14
2.4.1 Model-Driven Architecture . . . p. 14
2.4.2 Acceleo . . . p. 15
2.4.3 QVTO . . . p. 16
2.5 Sistemas deWorkflow . . . p. 17
3.1 Visão Geral da Abordagem . . . p. 20
3.2 Modelagem e Definição da Linha de Processo . . . p. 24
3.3 Gerência Automatizada de Variabilidades . . . p. 28
3.3.1 Anotando Modelos de Processo com Variabilidades . . . p. 29
3.3.2 Criação de Modelos de Derivação . . . p. 31
3.3.3 Modelagem de Variabilidades em Diferentes Granularidades . . p. 33
3.4 Derivação e Customização Automática de Processos . . . p. 37
3.5 Transformação de Modelo de Processo para Modelo de Workflow . . . p. 39
3.6 Transformação de Modelo de Workflow para Projeto de Workflow . . . p. 43
3.7 Implantando e Executando Processos de Software em umWorkflow
En-gine . . . p. 46
4 Suporte Ferramental da Abordagem p. 51
4.1 Ferramenta para Gerência de Variabilidade em Processos deSoftware . p. 51
4.2 Ferramenta para Transformação e Implantação de Processos em
Sis-temas de Workflow . . . p. 52
5 Estudo de Caso p. 57
5.1 Visão Geral dos Projetos Analisados . . . p. 57
5.2 Modelagem e Definição da Linha de Processo . . . p. 58
5.3 Gerência Automatizada de Variabilidades . . . p. 61
5.4 Derivação e Customização Automática de Processos . . . p. 62
5.5 Transformação de Modelo de Processo para Workflow . . . p. 65
5.6 Transformação de Modelo de Workflow para Texto . . . p. 68
5.8 Lições Aprendidas e Novas Perspectivas . . . p. 72
5.8.1 Mapeamento de especificações de processo emWorkflow . . . . p. 72
5.8.2 Integração do código do Workflowcom ferramentas de
engen-haria desoftware . . . p. 73
5.8.3 Independência de plataforma na aplicação da abordagem . . . . p. 75
5.8.4 Gerência de variabilidades de processos . . . p. 75
5.8.5 Especificação Multi-Nível do Modelo de Característica . . . p. 76
5.8.6 Gerência de Variações em Métricas de Processo . . . p. 76
6 Trabalhos Relacionados p. 78
6.1 Abordagens para Gerência de Variabilidades e Componentização em
Processos deSoftware . . . p. 78
6.2 Abordagens para Execução de Processos deSoftware . . . p. 80
7 Conclusão e Trabalhos Futuros p. 82
7.1 Contribuições . . . p. 82
7.2 Trabalhos em Andamento e Futuros . . . p. 83
Referências Bibliográficas p. 85
Lista de Figuras
2.1 Divisão de tópicos da área de conhecimento de Engenharia de Processo p. 7
2.2 Arquitetura da Ferramenta Genarch [CIRILO, 2008] . . . p. 13
2.3 Exemplo de identificação de variabilidades no código utilizando
ano-tação Java . . . p. 14
2.4 Abordagem de Desenvolvimento Utilizando o Acceleo . . . p. 16
3.1 Uma Visão da Abordagem para Gerência e customização de
variabili-dades e Derivação de Processo . . . p. 22
3.2 Uma Visão da Abordagem para Execução de Processos de Software . . p. 23
3.3 Criação doMethod Pluginna Ferramenta EPF Composer . . . p. 25
3.4 Elementos Presentes no Processo . . . p. 26
3.5 Visualização do processo na forma de umwork breakdown structurena
ferramenta EPF . . . p. 27
3.6 Matriz de Variabilidade . . . p. 30
3.7 Arquivo XMI com um comentário representando umafeature . . . p. 31
3.8 Modelo defeaturesgerado pelo GenArch . . . p. 32
3.9 Modelo de Arquitetura do Processo Gerado pelo GenArch . . . p. 33
3.10 Modelo de configuração gerado pelo GenArch . . . p. 34
3.11 Arquivo xmi representando elemento do processo com multipla
ano-tações de variabilidade . . . p. 35
3.12 Visualização dos arquivos gerados pela ferramenta EPF na geração do
Processo . . . p. 36
3.13 Modelo de Arquitetura do Processo gerado pelo GenArch com a adição
3.15 Arquivo XMI após ser transformado em um template segundo a
lin-guagem XPand . . . p. 39
3.16 Extração de código para fragmento . . . p. 40
3.17 Processo de seleção de variabilidades no modelo de característica
den-tro da ferramenta GenArch . . . p. 41
3.18 Processo derivado sem a presença da tarefaCriar os Casos de Teste . p. 42
3.19 Imagem comWork breakdown structuredo processo derivado . . . p. 43
3.20 Mapeamento elementos UMA e JPDL . . . p. 44
3.21 Fragmento de Código da transformação em QVTO . . . p. 45
3.22 Modelo JPDL, resultado da transformação modelo-para-modelo . . . . p. 46
3.23 Visualização doworkflowatravés doPlug InGPD no eclipse . . . p. 46
3.24 Resultados da Transformação Modelo para Texto . . . p. 47
3.25 Arquivo resultado da transformação modelo-para-texto, que relaciona
formulários JSF a tarefas . . . p. 47
3.26 Template Acceleo para Derivação de Código Java(JSF) . . . p. 48
3.27 Plugin jBPM para a execução do Processo . . . p. 49
3.28 Processo em execução visualizado através do jBPM-Console . . . p. 50
4.1 Arquitetura da ferramenta GenArch adaptada para o trabalho com
pro-cessos desoftware . . . p. 53
4.2 Código para o parsingdos arquivos XMLs a procura de anotações de
variabilidades . . . p. 54
4.3 Fragmento de Código QVT0, destacando como parâmetros para exe-cução doscripta declaração dos metamodelos envolvidos e as
instân-cias dos modelos de entrada e saída . . . p. 55
4.4 Arquitetura da ferramenta de transformação para-modelo e modelo-para-texto . . . p. 56
5.1 Trecho do resultado do estudo de variabiliades e similaridades do OpenUP p. 60
5.2 Work Break down Structureresumido da linha de processo . . . p. 61
5.3 Modelo de Característica gerado pela ferramenta Genarch . . . p. 62
5.4 Modelo de Arquitetura do Processo gerado pela ferramenta Genarch . . p. 63
5.5 Modelo de Configuração gerado pela ferramenta Genarch . . . p. 64
5.6 Fragmento do modelo de características gerado pela ferramenta Genarch,
resultante da seleção de variabilidades nos processos analisados . . . . p. 65
5.7 Visualização WBS do processo resultado da customização e derivação . p. 66
5.8 Visualização do processo em forma de páginaweb. . . p. 67
5.9 Modelo de processo seguindo a especificação do metamodelo UMA . . p. 68
5.10 Modelo seguindo a especificação do metamodelo JPDL . . . p. 69
5.11 Visualização do arquivoforms.xmlresponsável pela ligação das tarefas
com seus formulários . . . p. 70
5.12 Arquivos gerados na Transformação de modelo-para-texto . . . p. 71
5.13 Efetuando odeploydoworkflow . . . p. 72
5.14 página deupload, disponível no jBPMConsole, para a implantação de
processos . . . p. 72
5.15 Visualização do Processo no jBPM Console . . . p. 73
5.16 Visualização do processo na forma gráfica em execução pelo
jbpm-console . . . p. 74
1
Introdução
Atualmente, empresas que tem suas atividades ligadas à engenharia de software
de-mandam a definição e melhoramento contínuo de seus processos de software a fim de
promover o desenvolvimento produtivo desoftwaresde qualidade. Há uma necessidade
crescente por parte da indústria de desenvolvimento de sistemas na rápida e efetiva cus-tomização de processos desoftwarepara endereçar a variedade de cenários, tecnologias,
culturas e escalas existentes[THRÄNERT; WERNER, 2006] [ROMBACH, 2005] [ARM-BRUST et al., 2009]. A rápida e eficaz customização de processos envolve a adaptação de modelos de processo desoftwarepara a realidade dos projetos das organizações. Assim
como o reuso de experiências passadas na definição e desenvolvimento de processos de
software para os novos projetos com o objetivo de aumentar a produtividade durante a
realização de tal atividade.
Ao longo dos últimos anos, diversas ferramentas e tecnologias que oferecem suporte a definição, empacotamento, customização, distribuição e execução de processos de soft-wareforam propostas [IBM, 2010]1. O apoio de ferramentas auxiliam na automatização
das atividades do engenheiro de processos permitindo a manipulação de artefatos rela-cionados à especificação e definição de processos desoftwaree, embora tais ferramentas
já sejam úteis para apoiar atividades de customização, reuso e execução de processos, ainda existe uma forte demanda por funcionalidades que permitam: (i) o gerenciamento dos componentes e variabilidades de tais processos; e (ii) a composição e derivação destes elementos para gerar um processo customizado para um projeto. A definição de um pro-cesso desoftwareé uma atividade complexa que requer muita experiência e conhecimento
de muitas áreas e disciplinas da engenharia desoftware[BARRETO et al., 2010]. Dessa
forma, um dos desafios atuais está relacionado a maneira como uma organização de soft-ware pode facilmente reusar vários elementos dos processos de software existentes de
maneira rápida e automática permitindo sua fácil customização para novos projetos.
1.1
Problema
Atualmente, empresas de desenvolvimento de softwarebuscam a melhoria contínua
da qualidade e produtividade de seus processos de desenvolvimento. O desenvolvimento desoftwareenvolve várias tarefas complexas e envolve diferentes profissionais de diversas
áreas. Projetos de desenvolvimento desoftwarede naturezas distintas também demandam
a adoção de novos processos, técnicas e ferramentas a serem utilizadas.
Um dos caminhos para lidar com tal complexidade, é promover o reuso de processos legados adotados com sucesso em outros projetos, e permitir a customização de partes es-pecíficas de acordo com as peculiaridades dosoftwarea ser desenvolvido, assim como da
natureza e escala do projeto. Embora, já seja possível reusar conhecimento e boas práti-cas de processos existentes, o suporte ferramental disponível para especificação e edição de processos desoftwarenão permite que a customização de variabilidades do processo
seja realizada de forma rápida e confiável, garantindo assim uma boa qualidade para o resultado final. Algumas ferramentas atuais auxiliam no trabalho de especificar e editar especificações de processos desoftware [IBM, 2010] 2, porém não de forma intuitiva e
tratando explicitamente o conceito de variabilidades. Elas permitem apenas a manipu-lação manual e trabalhosa de elementos presentes nas definições de processos, sendo esta uma forma manual e trabalhosa de reusar definições de processos. Estas ferramentas per-mitem também a visualização do processo na forma de um conjunto de páginas HTML, porém esta visualização é feita de maneira que não há interação do processo com a equipe envolvida nele.
Um outro problema existente diz respeito ao acompanhamento e monitoramento da execução de tais processos desoftware, quando instanciando os mesmos para serem
ex-ecutados em determinados projetos. Trabalhos recentes propõem a criação de lingua-gens para especificação e execução de processos [BENDRAOU; JEZéQUéL; FLEUREY, 2009] [BENDRAOU et al., 2007] [MACIEL et al., 2009], mas ainda existe uma grande carência no que se refere a transformação de processos especificados seguindo metamod-elos voltados exclusivamente para especificação de processos desoftware(UMA3, SPEM
4) para ambientes específicos de execução de processos.
2PROJECT, E. Eclipse Process Framework Project (EPF). 2009. Disponível em: http://www-01.ibm.com/software/awdtools/rmc. Acesso em: 10 Nov. 2009.
3PROJECT, E. E. Introduction to UMA. 2008. Disponível em:
http://epf.eclipse.org/wikis/openupsp/baseconcepts/guidances/concepts/introduction.html. Acesso em: 24 Ago. 2009.
1.2
Limitações das Abordagens Atuais
Apesar de oferecer funcionalidades para a manipulação de elementos presentes na especificação do processo, ferramentas como o EPF Composer e o Rational Method Composer [IBM, 2010], não oferecem funcionalidades e mecanismos que permitam a
gerência de suas variabilidades e a derivação automática de versões customizadas do pro-cesso. Dado que metodologias de processos, tais como o RUP [JACOBSON; BOOCH; RUMBAUGH, 1999] e OpenUP5, possuem inúmeras possibilidades de customização e configuração dependendo da natureza do projeto a ser usado, a manipulação e customiza-ção manual dos diferentes elementos do processo pode se tornar inviável, custosa e sujeita a erros. Alguns dosframeworksde processo citados até explicitam elementos do processo
(atividades, tarefas, passos, artefatos) que são opcionais, mas a maioria deles se refere a decisões tomadas durante a execução do processo em um projeto específico, e não du-rante as atividades de customização do projeto por um engenheiro de processo. Uma vez definido um processo no EPF Composer, a ferramenta permite reaproveitar parte da con-figuração definida para um novo processo. Porém, este reaproveitamento ocorre através da manipulação direta de seus elementos. Este processo por ser manual, é pouco produ-tivo e confiável, e não explicita as variabilidades existentes em tal processo, dificultando também sua evolução como uma família de processos relacionados. No que diz respeito a execução de processos, existem linguagens de definição de fluxos de processos eengines
para essesworkflows. Por se tratar de uma linguagem específica para a execução de
pro-cessos, nosso processo teria que ser modelado novamente em uma dessas linguagens para que fosse possível oengineexecutar nosso fluxo principal de processo.
De forma geral, podemos dizer que as abordagens, técnicas e ferramentas disponíveis atualmente, são bastante carentes no que se refere: (i) a gerência de variabilidades em processos; (ii) a derivação automática de versões específicas de tais processos; e (iii) a transformação de especificações de processos em instâncias concretas de tais processos, de forma a permitir a sua instalação, execução e monitoramento, em um ambiente definido para tal finalidade.
1.3
Trabalho Proposto
Esta dissertação de mestrado propõe uma abordagem baseada em modelos para a gerência de variabilidades e execução de processos desoftware. Seus principais objetivos
são: (i) promover o reuso de variabilidades que ocorrem dentro de uma família (ou linha) de processos; e (ii) permitir a sua execução em sistemas de workflow. A abordagem é
definida baseada nos fundamentos de engenharia de linhas de produtos [CLEMENTS; NORTHROP, 2001] [POHL; BOCKLE; LINDEN, 2005], sobretudo em estratégias e téc-nicas usadas atualmente para gerência de variabilidades e derivação de produtos. É re-alizada a adaptação de uma ferramenta de derivação de produto existente, denominada GenArch [CIRILO, 2008], para promover a gerência explícita das variabilidades de uma linha de processo [ARMBRUST et al., 2009]. Uma linha de processos pode ser vista como um conjunto de processos que compartinha similaridades e possuem variabilidades decorrentes das especificidades de cada um dos processos que fazem parte da linha. Os modelos de processo de software utilizados neste trabalho são especificações do
meta-modeloUnified Method architecture (UMA) 6 que é uma variante do Software Process Engineering Metamodel(SPEM) 7 e para a criação destes modelos de processo foi
uti-lizada a ferramenta Eclipse Process Framework (EPF)8. A abordagem também permite que cada especificação de processo EPF derivado automaticamente, possa ser automati-camente transformado para uma especificação deworkflow, que pode ser instalado e
exe-cutado noenginedeworkflowjBPM.
1.4
Objetivos
O objetivo central da abordagem é promover o reuso sistemático de processos de soft-ware, através da proposição de mecanismos para gerência de variabilidades e derivação
automática de processos, assim como permitir sua execução e monitoramento. Cada família de processos relacionados é organizado como uma linha de processos. Os seguintes objetivos específicos são definidos para este trabalho de mestrado:
• Proposição de mecanismos para gerência de variabilidades e derivação automática
de processos de software com foco na disciplina de gerência de projetos, assim
como transformação de especificações de processo EPF em especificações concre-tas deworkflowque podem ser instaladas em sistemas de gerenciamento de work-flows.
• Implementação dos mecanismos mencionados acima como forma de avaliação da
abordagem proposta.
6http://epf.eclipse.org/wikis/openupsp/baseconcepts/guidances/concepts/introduction.html 7http://www.omg.org/technology/documents/formal/spem.htm
• Modelagem de estudo de caso de linha de processo desoftwarepara avaliar a
abor-dagem e mecanismos propostos.
• Análise e comparação da abordagem proposta com outros trabalhos relacionados.
1.5
Organização do trabalho
O restante deste documento está organizado da seguinte forma: O capítulo 2 apre-senta a fundamentação teórica para realização deste trabalho. O capítulo 3 apreapre-senta a abordagem proposta nesta dissertação de mestrado, detalhando sua aplicação com um pe-queno exemplo. O capítulo 4 apresenta a adaptação da ferramenta de derivação de linha de produto desoftwarepara trabalhar com especificações de processo desoftware. O
2
Fundamentação Teórica
Este capítulo apresenta a fundamentação teórica para esta dissertação de mestrado. O desenvolvimento da abordagem proposta neste trabalho envolveu diversos conceitos, tecnologias e ferramentas para a sua implementação. Entre os principais conceitos estão : (i) Engenharia de processos; (ii) Reuso em processos; (iii) Linhas de produto desoftware;
(iv) Ferramentas de derivação; (v) Engenharia dirigida por modelos; e (vi) Sistemas de
workflow.
2.1
Engenharia de Processos
Metodologias de desenvolvimento de software são utilizadas regularmente pela
in-dústria desoftware para diferentes tipos de projetos. A engenharia de processos de soft-ware consiste na criação, modelagem, adaptação e representação desses processos. De
acordo com oSoftware Engineering Body of Knowledge(SWEBOK)1, a área de conhe-cimento da "Engenharia de Processo deSoftware"pode ser estruturada em dois níveis: (i)
o primeiro nível engloba os aspectos técnicos e as atividades de gestão no âmbito do ciclo de vida do processo; e (ii) o segundo nível engloba a definição, implementação, avaliação, medição, gerenciamento de mudanças e a melhoria do processo. A área de conhecimento da engenharia de processo pode ser dividida em diversas sub-áreas. A Figura 2.1 ilustra tal divisão segundo o SWEBOK.
Implementação e gerência de mudanças do processo. A sub-área de implemen-tação e mudança é focada nas mudanças organizacionais e descreve atividades, modelos e infraestrutura para o processo de implementação e gerência de mudanças. Para esta sub-área temos a divisão dos tópicos que ajudam na atividade de implementação e mu-dança, são eles: (i) infraestrutura do processo - esse tópico envolve toda a infraestrutura aplicada no processo, garantindo que todos os recursos necessários estejam disponíveis;
Figura 2.1: Divisão de tópicos da área de conhecimento de Engenharia de Processo
(ii) ciclo de gerenciamento do processo de software - este tópico tem como objetivo o
gerenciamento do processo, e para melhor obter esse gerenciamento contam com ativi-dades como “estabelecer a infraestrutura do processo”e “planejamento”; e (iii) modelos para implementação e gerência de mudanças dos processos - provê a implementação de modelos para apoiar a execução desta sub-área.
Definição do processo. Esta sub-área da engenharia de processos exige um grande esforço por parte do engenheiro de processo, uma vez que para a definição do processo é levado em consideração diversos aspectos como a qualidade crescente do produto e apoio a melhoria do processo. Para esta sub-área temos a seguinte divisão de tópicos: (i) modelos de ciclo de vida de processos - estes modelos servem como uma definição das fases que auxiliam no desenvolvimento. Exemplos desses modelos são: modelo em cascata e o modelo espiral; (ii) processo de ciclo de vida dosoftware- esse tópico tende
a ser mais detalhado do que os modelos de ciclo de vida dosoftware; (iii) notações para a
definição dos processos - há uma série de notações sendo utilizadas para definir processos [CONSORTIUM, 1992], as principais diferenças entre essas notações são os tipos de informações utilizadas. (iv) adaptação do processo - os processos de software que são
auxilia na automação da engenharia de processos.
Avaliação do processo. Esta sub-área consiste em avaliar o processo de software
apoiado por métodos e modelos de avaliação. Os modelos e métodos de avaliação são a divisão dos tópicos desta sub-área: (i) modelo de avaliação do processo - captura o que é reconhecido como boas práticas e (ii) metodos de avaliação - com o intuito de realizar uma avaliação, um método de avaliação específico deve ser seguido para produzir dados que caracterize o processo, como por exemplo, sua capacidade ou nível de maturidade.
Medição de processos e produtos. A medição pode ser realizada para dar suporte a iniciação da implementação e gerência de mudanças do processo ou avaliar as suas con-sequências, os tópicos desta sub-área são: (i) medição de processo - este tópico tem como informações de entrada, dados relativos a quantitativos coletados, analisados e interpreta-dos do processo, que são usainterpreta-dos para identificar os pontos fortes e fracos interpreta-dos processos, e também avaliar esses processos depois de terem sido implementados e/ou alterados; (ii) medição de produtos desoftware- inclui, particularmente, a medição do tamanho do
pro-duto, a sua estrutura e a qualidade deste produto. (iii) qualidade nos resultados de medição - a qualidade dos resultados obtidos nas medições é importante para proporcionar resul-tados efetivos e delimiresul-tados dos processos; (iv) modelos de informação de software - a
maneira como a informação é coletada e utilizada para fins de medição, torna possível a construção de modelos utilizando a experiência e dados obtidos. Estes modelos existem para fins de análise, classificação e previsão; e (v) técnicas de medição do processo - téc-nicas de medição podem ser aplicadas na análise de processos desoftware e identificar
pontos fortes e pontos fracos desses processos.
Este trabalho de dissertação tem relação mais direta com a sub-área de Definição do Processo, a qual envolve notações para a definição do processo, adaptação de processos e automação da engenharia de processos. Em particular, o trabalho busca promover o reuso de elementos de processo através da modelagem de uma linha ou família de processos.
2.2
Reuso em Processos de
Software
Trabalhos recentes [ROMBACH, 2005] [BARRETO; MURTA; ROCHA, 2009] [RU-ZHI et al., 2005] [ARMBRUST et al., 2009] têm reforçado a importância de promover a reutilização de processos como forma de promover o uso de boas práticas de projetos anteriores na definição dos novos processos. Uma das principais vertentes de trabalho atual diz respeito ao uso e adaptação de técnicas de linhas de produto de software, na
pode ser vista como uma família de processos que compartilham elementos de processo comuns e variáveis. Baseado em tal definição,frameworksde processos existentes podem
ser também caracterizados como linhas de processo.
Reusar especificações parciais de processos desoftwareexistentes de maneira rápida
e automática, permitindo sua fácil customização para novos projetos é ainda um desafio para empresas de desenvolvimento de software de média e larga escala. Ao longo dos
últimos anos, alguns esforços e iniciativas têm sido propostos com o intuito de promover e ampliar a reutilização de especificações de processos desoftware, tais como, o Ratio-nal Unified Process (RUP)[KRUCHTEN, 2003]. Em paralelo, ferramentas têm também
sido propostas para viabilizar a automação durante tal processo de reutilização. O EPF Composer [HAUMER, 2007]2 e o Rational Method Composer 3 são exemplos de
tec-nologias que permitem a manipulação e customização dos diferentes elementos presentes na especificação de processos.
2.2.1
Eclipse Process Framework
Projetos diferentes têm necessidades diferentes e gerenciar a customização desses processos para diferentes projetos é uma tarefa difícil de ser implementada na prática, com essa visão algumas ferramentas têm surgido para contribuir no melhor gerenciamento dessa complexidade. Um exemplo dessas ferramentas é o Eclipse Process Framework
(EPF), que é uma ferramenta de apoio aos engenheiros de processo, líderes de projeto e gerentes de projeto que são responsáveis pela criação, customização e publicação de pro-cessos para organizações de desenvolvimento ou projetos individuais. O EPF é também um projeto de tecnologia aberta da fundação Eclipse.
O EPF visa produzir um processo de desenvolvimento de software personalizável,
com conteúdos e ferramentas, suportando uma ampla variedade de tipos de projetos e esti-los de desenvolvimento. O projeto EPF visa dois objetivos principais que são: (i) fornecer uma estrutura extensível e ferramentas para a engenharia de processo desoftware como
gestão da biblioteca de componentes, configuração e publicação de um processo; (ii) como também fornecer conteúdo de processo extensível para uma escala de desenvolvi-mento desoftwaree gerenciamento de processos de suporte de desenvolvimento iterativo,
ágil e incremental, e aplicável a um amplo conjunto de plataformas de desenvolvimento e aplicações, além de promover a automatização de vários aspectos de criação de processos.
2FOUNDATION, E. Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview. 2010. Disponível em: <http://www.eclipse.org/epf/>. Acesso em: 10 Jan. 2010.
2.3
Linhas de Produto de
Software
O conceito de linha de produtos desoftware, consiste em um conjunto de sistemas de softwareque compartilham um conjunto comum de featuresgerenciadas, que satisfazem
necessidades específicas de um segmento particular do mercado, e que são desenvolvi-dos a partir de um conjunto comum de artefatos de forma pré-estabelecida(core assets)
[CLEMENTS; NORTHROP, 2001]4. Chastek [CHASTEK et al., 2001] define LPS como uma família de produtos de software em um domínio que compartilham características (features). Uma linha de produto de software pode ser vista como um conjunto de
po-tenciais produtos desoftwarecom características suficientemente similares para permitir
a definição de uma infra-estrutura genérica de estruturação de artefatos que compõem os produtos e a parametrização de suas diferenças. [GIMENES; TRAVASSOS, 2002]
Vários aspectos levam uma organização a adotar uma abordagem de linha de pro-dutos para obter melhores resultados, como custos de desenvolvimento e qualidade do produto [LINDEN; SCHMID; ROMMES, 2007] entre as outras vantagens de se utilizar a abordagem de linha de produtos desoftwarepodemos citar: (i) redução no tempo de
en-trega, com a adoção da técnica de linhas de produto o tempo de produção de um produto consegue ser bastante reduzido. A princípio a confecção dos artefatos podem deman-dar um tempo maior de desenvolvimento, porém levando em consideração a reutilização deste artefato, o tempo de produção é drasticamente reduzido; (ii) redução no esforço de manutenção, uma vez efetuada a manutenção numa linha de produto essa correção se aplica a todas os produtos, agora, derivados desta linha; (iii) evoluções gerenciáveis, da mesma maneira que ocorre com a manutenção na linha de produto, podem ocorrer evoluções de implementação que serão repassadas para os produtos também derivados desta LPS; (iv) complexidade gerenciável, um dos maiores benefícios é o gerenciamento da complexidade onde na linha de produtos as maiores operações são realizadas no nú-cleo, proporcionando a diminuição dos números de artefatos a serem gerenciados; (v) no quisito qualidade temos que, uma vez testados todos os nossos artefatos na linha de produtos, esses artefatos se propagam nos produtos e uma vez detectados as falhas, es-tas mesmas podem ser tratadas diretamente na linha corrigindo qualquer erro que possa provocar falhas nos produtos desta linha; e (vi) e com certeza o benefício mais esperado é com relação ao custo de produção dos produtos, que levando em consideração todos os aspectos anteriores implicam em uma redução brusca de custos de uma corporação para a manutenção e evolução dos seus produtos desoftware.
Para a implementação da abordagem de linhas de produto de software podem ser
utilizadas três estratégias: (i) pró-ativa - na abordagem pró-ativa a linha de produto é analisada, projetada e implementada por completo, de forma que atenda, inicialmente, o maior número possível de produtos; (ii) reativa - esta técnica é realizada de maneira in-cremental, de forma que, a linha de produto cresça de acordo com a demanda por novos produtos ou novas características em produtos que já existam; e (iii) extrativa - a con-strução da linha de produto é realizada a partir da extração de características comuns e variáveis de um conjunto de softwares bases, previamente desenvolvidos e geralmente
que estejam em produção.
A utilização destas técnicas não é mutuamente exclusivo, por exemplo, no início do desenvolvimento da LPS podemos ter como base um conjunto de produtos já existentes e incrementalmente evoluir a arquitetura com acréscimos de novos produtos. Essa visão corresponde a adotar inicialmente a abordagem extrativa e, posteriormente, passar para uma abordagem reativa. O processo de gerenciamento de um núcleo de artefatossoftware
é composto por dois estágios: engenharia de domínio e engenharia de aplicação.
Segundo [LOBO; RUBIRA, 2009] [PRIETO-DIAZ; ARANGO, 1991] engenharia de domínio é a atividade de coletar, organizar e armazenar experiências anteriores na con-strução de aplicações em um domínio específico na forma de artefatos reutilizáveis, e a utilização sistemática destes artefatos na construção de novas aplicações. A engenharia de domínio engloba, basicamente, três atividades: (i) análise de domínio - atividade rela-cionada a definição do escopo para uma determinada família de sistemas e na identificação de características comuns e variáveis presentes neste domínio; (ii) projeto de domínio -atividade que se concentra na especificação de uma arquitetura comum e de componentes para a linha de produto; e (iii) implementação do domínio - atividade responsável pela implementação da arquitetura comum e dos componentes previamente definidos na ativi-dade de projeto do domínio. A engenharia de aplicação consiste no desenvolvimento de sistemas a partir dos artefatos produzidos na engenharia de domínio [CZARNECKI; EISENECKER, 2000].
2.3.1
Ferramentas de Derivação
derivação de produtos desoftware baseadas em modelo defeature, podemos citar, entre
outras, o Gears5, pure::variants 6 e GenArch [CIRILO; LUCENA, 2009]. As ferra-mentas citadas visam oferecer um apoio para a automatização do processo de utilização da abordagem de linha de produtos desoftwareno que se refere a derivação dos produtos
da linha.
Gears é uma ferramenta de engenharia de linha de produtos e um framework que
aborda os desafios específicos para a geração de uma variedade de produtos da linha, du-rante todo o ciclo de desenvolvimento7. A ferramentaGearspermite a adoção/construção de LPS seguindo a abordagem incremental. Dessa forma, é possível iniciar a construção de produtos a partir de um ou dois subsistemas, módulos ou artefatos, e então transferir facilmente, através de incrementos gerenciáveis, para uma engenharia de LPS.Pure::variants
é uma ferramenta especialmente construída para o gerenciamento de variações [GRO-HER; SCHWANNINGER; VOELTER, 2008], a ferramenta gerencia as linhas de pro-dutos e auxilia na produção de variantes de cada produto. A ferramenta escolhida para apoiar nossa abordagem é a ferramenta de derivaçãoGenarch [CIRILO, 2008], por ser
uma ferramenta de derivação de linha de produtos desoftwarebaseada em modelos e ser
desenvolvida em uma arquitetura deplugin do Eclipse conforme pode ser visto Figura
2.2.
Um fator determinante para a escolha desta ferramenta como ferramenta de apoio para a abordagem proposta neste trabalho, é que o GenArch foi desenvolvido usando tec-nologias compatíveis com a especificação de processos do framework EPF, tais como, o Eclipse Modeling Framework (EMF) e o openArchitectureWare (oAW), consequente-mente oferece facilidades de extensão que facilitam a adaptação da ferramenta para ma-nipular os artefatos de especificação de processos oferecidos pelo EPF [CIRILO et al., 2008]. Além disso o GenArch foi desenvolvido no laboratório de Engenharia deSoftware
da Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO)8, onde há uma maior integração e colaboração com a equipe de estudos desta instituição.
A ferramenta utiliza os recursos doEclipse Modeling Framework(EMF) para a
ma-nipulação de metamodelos e modelos, e a API EclipseJDT Java Development Toolpara
ter acesso a anotações feitas na classes indicando as variações existentes no código. A indicação explícita de variabilidades é realizada através de anotações Java como
demon-5GEARS, G. S. Software Product Lines - Pragmatic Innovation from BigLever Software. 2009. Disponível em: http://www.biglever.com. Acesso em: 3 Nov. 2009.
6Disponível em: http://www.pure-systems.com Acesso em: 3 Nov. 2009
7GEARS. Software Product Lines - Pragmatic Innovation from BigLever Software. 2009. Disponível em: http://www.biglever.com Acesso em: 3 Nov. 2009.
Figura 2.2: Arquitetura da Ferramenta Genarch [CIRILO, 2008]
strado na Figura 2.3. A automação do processo de derivação é realizada através da mod-elagem e especificação de três modelos: (i) modelo de característica(features)- que
in-dicam as características comuns (similaridades) e variáveis (variabilidades) existentes na linha de processo/produto, além de permitir a definição de restrições (constraints)
en-tre os mesmos; (ii) modelo de arquitetura do processo - que representa visualmente os artefatos de implementação usados na estruturação da linha de processo/produto; e (iii) modelo de configuração - que especifica o mapeamento entre variabilidades presentes no modelo de característica e artefatos de implementação presentes no modelo de arquite-tura do processo. Tais modelos representam a realização do modelo generativo proposto por Czarnecki [CZARNECKI; EISENECKER, 2000] e adotado por outras ferramentas de derivação existentes. A ferramenta GenArch foi escolhida no nosso trabalho, por facilitar a manipulação de modelos que representam variabilidades explicitamente, e por permitir a sua extensão e adaptação para modelos de processo EPF especificados usando o Ecore, que é um metamodelo utilizado pelo EMF para definir outros modelos9.
Figura 2.3: Exemplo de identificação de variabilidades no código utilizando anotação Java
2.4
Engenharia Dirigida por Modelos
Desde o começo da programação de sistemas de software a engenharia desoftware
tem buscado elevar o nível de abstração para especificar, modelar e implementar sistemas desoftware. Uma das recentes e fortes iniciativas para alavancar o nível de abstração é
engenharia dirigida por modelos(Model Driven Engeeniring - MDE). Modelos não são
apenas usados para auxiliar no processo de desenvolvimento, mas são considerados os artefatos principais dentro deste contexto. Esta seção apresenta uma visão geral dos im-portantes conceitos de MDE. Estes conceitos são explicados e fornecem uma base teórica para a Engenharia dirigida por modelos.
2.4.1
Model-Driven Architecture
A OMG(Object Management Group)trabalhou o termo MDA(Model-Driven Archi-tecture)como uma abordagem MDE baseada em padrões da indústria e com a visão de
sua plataforma. MDA é baseado nos seguintes padrões UML10, XMI11, QVT12, OCL13
e MOF14. Em MDA temos três tipos de modelos, o modelo CIM(Computacional
Inde-pendent Model), o modelo PIM(Platform Independent Model)e o modelo PSM(Platform Specific Model).
O Modelo CIM é o modelo que descreve o domínio da aplicação sem nenhuma refer-ência a uma tecnologia em particular e não mostra como o sistema é implementado. O modelo CIM mostra o sistema em seu ambiente e ajuda a demonstrar o que o sistema de-verá realizar, ou seja um modelo conceitual é derivado de uma realidade com a finalidade de adquirir um entendimento melhor desta realidade. O modelo PIM é uma parte impor-tante do MDA esse modelo descreve o sistema sem referência à plataforma e permite uma representação independente de plataforma para o sistema, este modelo é o primeiro passo para a criação do sistema. O modelo PSM, ou modelo específico de plataforma, é um modelo de mais alto nível da especificação do sistema e dependente de plataforma, este modelo é obtido do modelo PIM através de transformação entre modelos.
2.4.2
Acceleo
Acceleo é uma linguagemopen sourcepadronizada pela OMG baseada em uma
abor-dagem MDE para a transformação de modelos, com o Acceleo podemos transformar nossas especificações de modelos para texto, desde que os nossos modelos obedeçam um metamodelo e que este metamodelo esteja de acordo com o EMF.
Acceleo foi desenvolvido para melhorar a produtividade no desenvolvimento de soft-ware 15 e a abordagem de desenvolvimento com Acceleo envolve muitos conceitos em
conjunto com MDA (Model Driven Architecture). O Acceleo oferece extensões para
a geração de código para diferentes linguagens de programação como C#, Java e PHP. As ferramentas disponíveis no Acceleo são totalmente integradas com a IDE Eclipse provendo para o desenvolvedor um ambiente homogêneo de desenvolvimento. Esta trans-formação acontece a partir da criação detemplatesno Acceleo, uma vez definido os
tem-10OMG. Unified Modeling Language (UML). 2010. http://www.omg.org/spec/UML/. Acesso em: Set. 2010.
11OMG. XML Metadata Interchange (XMI). 2010. http://www.omg.org/spec/XMI/. Acesso em: Set. 2010.
12OMG. Query/View/Transformation (QVT). 2010. http://www.omg.org/spec/QVT/. Acesso em: Set. 2010.
13OMG. Documents associated with Object Constraint Language, Version 2.0. 2010. Disponível em: http://www.omg.org/spec/OCL/2.0/. Acesso em: Set. 2010.
14OMG. Documents associated with MOF Version 2.0. 2010. Disponível em: http://www.omg.org/spec/MOF/2.0/. Acesso em: Set. 2010.
platesno Acceleo usamos os modelos EMF para a geração dos nossos artefatos desejados
como demonstrado na figura 2.4.
Figura 2.4: Abordagem de Desenvolvimento Utilizando o Acceleo
Para a criação de um template é preciso a criação de um modelo, e para a criação
de um novo modelo pode-se utilizar uma grande variedade desoftwares, isto é possível
porque o Acceleo oferece uma grande compatibilidade com diversas ferramentas de mod-elagem UML.
2.4.3
QVTO
Um conceito importante quando se trabalha com a abordagem dirigida por modelos é a possibilidade de transformação desses modelos. A transformação de modelos é uma estratégia importante quando se deseja separar os níveis de abstração do sistema, ou seja, a partir de um modelo mais abstrato ir construindo modelos mais específicos, no caso de sistemas desoftwarepodemos trabalhar em um modelo independente de plataforma,
um modelo PIM, e a partir de requisitos funcionais do nosso sistema transformar este modelo para um modelo específico de Plataforma, ou seja em um modelo PSM. Para que esta transformação ocorra podemos fazer uso de linguagens de transformação de modelos QVT Operational (QVTO), que é uma linguagem que segue a especificação QVT(Query / Views / Transformations)16. O QVT é uma especificação padrão da OMG para expressar
consultas, exibições e transformações em modelos que sigam o metamodelo UMA 17 e
esse por fim obedeça ao padrão MOF(Meta-Object Facility).
• View: “Uma Visão é um modelo que é completamente derivado de outro modelo ”; • Query: “Uma consulta é uma expressão que é avaliada por outro modelo ”;
• Transformation: “A transformação gera um modelo como resultado a partir de um
modelo de entrada ”;
QVT não é uma linguagem simples, ela implementa OCL como linguagem de con-sulta e possui duas linguagems de transformação. A duas linguagens são QVTRelationse
QVTOperational Mappings. Uma terceira linguagem compõe a parte principal das duas
últimas, essa linguagem que compõe o núcleo do mapeamento operacional e relacional é o QVTcore. QVTO é uma linguagem imperativa que estende ambas linguagens QVT
Relation e QVT Core. Em geral, QVT pode somente ser utilizada na transformação de modelo para modelo, transformação de Modelo para Texto não está incluída na especifi-cação.
2.5
Sistemas de
Workflow
Workflow pode ser entendido como uma visualização de uma sequência lógica de
um processo de negócio ou uma tarefa realizada por uma pessoa, grupo, empresa ou até mesmo mecanismos complexos, para se obter um produto ou prover um serviço, podendo ser entendido também como uma abstração de um trabalho real. Com o grande cresci-mento da complexidade e mudanças nas condições de tarefas e procedicresci-mentos para se obter um produto ou serviço, houve também uma necessidade cada vez maior de ferra-mentas que auxiliassem no trabalho de definição e gerenciamento desses fluxos de tra-balho. Para essa finalidade, nos ultimos anos diversas ferramentas para auxiliar o desen-volvimento e acompanhamento dos fluxos de trabalho foram propostas 18. Essas ferra-mentas são caracterizadas como sistemas deworkflowpodendo ser vistos também dentro
17PROJECT, E. E. Introduction to UMA. 2008. Disponível em:
http://epf.eclipse.org/wikis/openupsp/baseconcepts/guidances/concepts/introduction.html. Acesso em: 24 Ago. 2009.
18jBPM (http://www.jboss.org/jbossjbpm/), WfMOpen (http://wfmopen.sourceforge.net/), Apache
Or-chestration Director Engine (ODE) (http://ode.apache.org/), Imixs Workflow (http://www.imixs.org/),
do conceito de sistemas de gerenciamento de processos de negócio 19, sendo definido
como um sistema que permitem a definição e gerência de procedimentos para se obter um produto ou serviço.
A maioria dessa ferramentas nos oferece uma interface gráfica para a definição do fluxo de trabalho, isso é uma forma de tornar mais interativa a escrita do nossoworkflowe
com a crescente complexidade dos processos discutida no início da seção surgiu também a necessidade a criação de padrões de definição de processos20, [JURIC, 2006], [PENG;
ZHOU, 2008].
Sistemas deworkflowajudam a gerenciar a complexidade de tarefas de uma
organi-zação como um todo. Em organizações onde processos para realizações dos mais dife-rentes serviços demandam um fluxo complexo, seria praticamente impossível o acompan-hamento e gerênciamento de um fluxo sem o apoio de um sistema de gerenciamento de
workflow.
2.5.1
JBoss BPM
O jBPM é um frameworkda jBOSS que permite a criação de soluções empresariais
baseados em processos de negócio usando notações gráficas, como também programação orientada a grafos e umenginedeworkflows. Esta ferramenta tem a característica de fazer
uma ponte entre os analistas de negócio e os desenvolvedores, enquanto outros engines
de BPM tem um foco que é limitado a pessoas que não são técnicas21. O jBOSS BPM
funciona da seguinte maneira, como entrada podemos ter uma especificação de processo. Um processo por sua vez é composto de atividades que são compostos por transições e representam um fluxo de execução. Oengine jBPM oferece também uma visualização
em forma gráfica do processo servindo como base de comunicação entre pessoas técnicas e não técnicas envolvidas no desenvolvimento.
Cada execução de uma definição de processo é chamado de uma instância do pro-cesso, onde essas instâncias de processos são gerenciadas pelo jBPM. A ferramenta ainda possui uma interface gráfica para a exibição das execuções dos processos onde os usuários envolvidos no processo podem acompanhar o andamento do fluxo de execução da instân-cia que estão executando, podem também interagir com o processo comentando execução de tarefas e dar andamento nas tarefas que estão executando.
19do inglêsBusiness Process Management System (BPMS)
20XML Process Definition Language (XPDL)). 2010. Disponível em: http://www.xpdl.org. Acesso em: Ago. 2010.
jBPM é baseado em uma máquina virtual de processo que é a base para suportar mul-tiplas linguagens de especificação de processo. Atualmente linguagens como BPMN22
e JPDL 23 estão ganhando mais espaço nesta ferramenta. A especificação de processos
na linguagem JPDL podem ser realizadas na IDE Eclipse com o plugin jBPM Graphi-cal Proces Designer24. Nesta ferramenta os componentes que compõe o processo são
especificados visualmente, através da edição do código JPDL que será executado pelo engine JBPM, oplugincria um arquivo chamadoprocessdefinition.xml, que é uma es-pecificação de processo seguindo um metamodelo JPDL. O plugin também oferece um canaldeploymentdo processo, e todo processo que é executado pelo engine deworkflow
é armazenado em um banco de dados, uma vez que o jBPMengineé compatível e pode
ser configurado para os mais diversos bancos de dados relacionais existentes.
22OMG. Business Process Management Initiative. http://www.bpmn.org/. Acesso em: Ago. 2010. 23JBOSS. jBPM Process Definition Language (JPDL). 2008. Disponível em: http://docs.jboss.org/jbpm/v3/userguide/jpdl.html. Acesso em: 14 Dez. 2009.
3
Uma Abordagem Dirigida por
Modelos para Gerência de
Variabilidades e Execução de
Processos de Software
Este capítulo apresenta uma abordagem para o gerenciamento de variabilidades em processos desoftware, assim como mecanismos para promover a execução de processos
desoftware em umengine de workflow. O capítulo descreve uma visão geral da
abor-dagem, assim como detalha as atividades, técnicas e ferramentas usadas em cada estágio da abordagem.
3.1
Visão Geral da Abordagem
A abordagem proposta nesta trabalho visa a especificação de uma linha de processo desoftware, o gerenciamento de variabilidades durante a customização de processos de softwareespecíficos e sua execução e monitoramento através de um motor deworkflow. O
trabalho utiliza uma abordagem dirigida por modelos para a especificação, gerenciamento e execução de processos desoftware. A Figura 3.1 apresenta uma visão geral da primeira
etapa da nossa abordagem que engloba a especificação da linha de processo, gerencia-mento de características dos processos derivados da linha e a derivação do produto, no caso deste estudo o processo desoftware. Na Figura 3.2 temos a visão da segunda etapa
da nossa abordagem, onde temos as transformações modelo e modelo-para-texto, que permitem a implantação, execução e gerenciamento do processo em umengine
deworkflow.
A abordagem parte da modelagem e definição de uma linha de processo desoftware
ofer-ecem recursos e funcionalidades para a definição/modelagem de processos, através da utilização de linguagens de modelagem de processos. A linha de processo foi construida utilizando a ferramenta EPF(Eclipse Process Framework)(índice 3 da Figura 3.1). Cada
conteúdo de trabalho de um processo EPF é definido através da linguagem de modelagem de processoUnified Method Architecture(UMA)1, que é um subconjunto de uma outra
linguagem aSoftware Process Engineering Meta-Model (SPEM)2, e que serviu de base
para o desenvolvimento de uma nova versão desta última, a SPEM 2.0 [TERäVä, 2007]. Como artefatos de entrada para esta atividade, podemos ter processos legados que servirão de base para a montagem da linha de processo. E como artefatos de saída, temos a especi-ficação dos modelos de processo e a definição de uma matriz de variabilidades (índice 4 da Figura 3.1) . Em seguida, a abordagem se concentra na gerência de variabilidades dos elementos da linha de processo (índice 5 da Figura 3.1). Para promover tal gerência é utilizado como artefato de entrada os modelos de processo UMA (índice 7 da Figura 3.1 ), resultados da definição da linha de processo. Como resultado dessa atividade temos como artefatos de saída os modelos de derivação (índice 8 da Figura 3.1 ). Esses artefatos foram produzidos com o apoio da ferramenta de derivaçãoGenArch(índice 6 da Figura 3.1 ). Na atividade seguinte, também com o auxílio da ferramenta de derivaçãoGenArch, acontece a derivação automatizada de processo (índice 9 da Figura 3.1 ), que utiliza os artefatos produzidos no passo anterior para seleção dasfeaturesrelevantes para um
pro-cesso, possibilitando a geração de processos de software customizados, que lidem com
cenários e necessidades específicas de um dado projeto (índice 10 da Figura 3.1 ). O pa-pel responsável pa-pela execução das atividades previstas nesta primeira etapa da abordagem é o engenheiro de processo (índice 2 da Figura 3.1 ), por requerer um conhecimento amplo na área de definição de processo desoftware.
Na segunda etapa da nossa abordagem, temos a implantação, execução e gerenci-amento de processos de software em um motor de workflow. Após derivado um
pro-cesso desoftwarea partir da linha de processos (índice 10 da Figura 3.2 ), o modelo que
representa a especificação do processo sofre uma transformação para o modelo de pro-cesso correspondente na linguagem de especificação do workflow (índice 11 da Figura
3.2 ). Esta atividade é automatizada através de uma transformação modelo para modelo
(model-to-model - M2M), que utiliza como modelo de entrada os processos derivados a
partir da linha e que gera como saída um modelo deworkflowseguindo a especificação do
1PROJECT, E. E. Introduction to UMA. 2008. Disponível em:
http://epf.eclipse.org/wikis/openupsp/baseconcepts/guidances/concepts/introduction.html Acesso em: 24 Ago. 2009
meta-modelo deworkflowJPDL3 (índice 13 da Figura 3.2 ). Para implementar a
trans-formação modelo-para-modelo proposta por esta atividade foi utilizada a linguagem de transformação QVT4(índice 12 da Figura 3.2 ). Após a geração do modelo deworkflow,
a abordagem promove uma transformação modelo-para-texto (índice 14 da Figura 3.2 ), com o auxílio da ferramenta Acceleo (índice 15 da Figura 3.2 ), tal atividade utiliza o modelo deworkflowJPDL como artefato de entrada para a transformação (índice 13 da
Figura 3.2 ) e temos como resultado deste passo os artefatos de saída (índice 17 da Figura 3.2 ), que são os arquivos de configuração para a implantação e execução do workflow
(índice 18 da Figura 3.2 ) no motor de workflowjBPM 5 (índice 20 da Figura 3.2 ). E
temos que o papel responsável pelo gerenciamento doworkflow(índice 21 da Figura 3.2
) é o gerente de projetos (índice 22 da Figura 3.2 )
Nesta seção apresentamos uma visão geral da abordagem para a definição, gerência de variabilidades e execução de processos desoftware. A abordagem foi dividida em
eta-pas, onde foram definidos os papéis responsáveis pela execução das tarefas, os artefatos de entrada e saída, e as ferramentas e tecnologias que serviram de apoio para a automação de cada etapa da abordagem. As transformações modelo para modelo (M2M) foram codificadas emQVT Operationalpara possibilitar a transformação automática de
especi-ficações UMA em elementos do modelo jPDL(JBoss Process Definition Language). A
especifição jPDL é então processada através de uma transformação modelo para texto im-plementada usando a linguagem Acceleo, com o objetivo de gerar formulárioswebque
representam a especificação de umworkflowjPDL, codificados de acordo com a
tecnolo-giaJava Server Faces(JSF). Por fim, estes formulárioswebsão implantados e executados
no motor de workflow JBoss Business Process Management (jBPM) e permitindo,
fi-nalmente, o gerenciamento do workflow de processo de software. As seções seguintes
detalham cada uma das atividades do processo.
3.2
Modelagem e Definição da Linha de Processo
De forma similar ao desenvolvimento de linhas de produto de software, a primeira
atividade para a definição de uma linha de processos desoftwareé o estudo das
similari-dades e variabilisimilari-dades entre os processos que fazem parte de uma mesma família. A abor-dagem proposta utiliza a forma de representação de processos de desenvolvimento de
soft-3JBOSS. jBPM Process Definition Language (JPDL). 2008. Disponível em: http://docs.jboss.org/jbpm/v3/userguide/jpdl.html>. Acesso em: 14 Dez. 2009.
4OMG. QVTO Specification. 2008. Disponível http://www.omg.org/spec/QVT/1.0/. Acesso em: 07 Out. 2009.
wareproposta pelo EPF. Para exemplificação desta etapa de identificação e modelagem
de similaridades, precisamos montar nossa linha de processos. Para isso precisamos criar um Method PlugIn, que pode ser considerado, conceitualmente, uma representação de
uma unidade para a configuração, modularização, extensão e distribuição de conteúdos de processos. Uma vez criado oMethod PlugInpodemos a partir desse ponto criar todos
os elementos presentes em um processo desoftwareatravés do EPF Composer. A Figura
3.3 ilustra a criação de umMethod PlugIn.
Figura 3.3: Criação doMethod Pluginna Ferramenta EPF Composer
O EPF Composer utiliza uma abordagem baseada em formulários para a definição e relação dos elementos de processo, tais como: papéis, tarefas e artefatos. A Figura 3.4 apresenta os elementos na definição do processo que utilizaremos como exemplo. Com o EPF Composer, um engenheiro de processo pode definir um novo processo, reusando elementos de outros processos previamente definidos na ferramenta, dessa forma o EPF funciona como um repositório de artefatos de processo.
Na definição de um processo na ferramente EPF Composer, podemos definir parte dos nossos elementos de processo como sendo elementos que podem ser reutilizados em diversas etapas do processo.
Ao finalizar a edição de um processo de software, é possível gerar uma publicação
do mesmo, na forma de um site Web. A definição de um processo com o EPF, é
Figura 3.4: Elementos Presentes no Processo
metamodelo UMA. Embora o EPF já forneça algum apoio para especificar e definir pro-cessos desoftware, ele não permite a representação de suas variabilidades e nem a sua
personalização automática de processos desoftwareexistentes. Ferramentas de derivação
de produto podem então ser usadas para permitir a seleção das características relevantes de um processo de software existente, permitindo assim a derivação de especificações
personalizadas do processo desoftware, abordando cenários e projetos específicos.
Uma vez definido o processo, o EPF composer permite a sua visualização na forma de umwork breakdown structure. Podemos definir o que pode ser comum e variável dentro
da linha de processo através de um estudo dos processos de desenvolvimento desoftware
adotados em uma empresa. Analisando o processo temos definidas as seguintes tarefas : (i) Encontrar e Descrever os Requisitos, (ii) Detalhar os Requisitos e (iii) Criar os Casos de Teste. Os seguintes papeis foram também definidos: (i) analista, (ii) desenvolvedor e (iii) testador. Esses papeis combinados com as terafas podem definir, seguindo suas especializaçãos, os seguintes artefatos: (i) Caso de Uso, (ii) Visão e (iii) Caso de Teste. A Figura 3.5 apresenta tal estrutura para o exemplo.
Figura 3.5: Visualização do processo na forma de umwork breakdown structurena
ferra-menta EPF
linha , tenham: (i) a tarefa Encontrar e Descrever os RequisitoseDetalhar os Requisi-toscomo mandatórias, ou seja, esteja presente em todos os processos que serão derivados desta linha; e (ii) como uma característica opcional poder escolher a tarefaCriar os Ca-sos de Teste. Além destasfeaturespodemos definir que a tarefaDetalhar os Requisitos seja associada obrigatoriamente ao papel de analista e, opcionalmente, aos demais papéis como demostrado a seguir:
• Tarefa : Encontrar e Descrever os Requisitos.
– Papéis mandatórios
∗ Analista
– Papéis opcionais
∗ Desenvolvedor ∗ Testador
artefatos de entrada que serão obrigatórios temosDocumento de Visãoe como artefatos de saída temos como mandatórioCaso de Uso, podemos visualizar a estrutura a seguir:
• Tarefa : Encontrar e Descrever os Requisitos.
– Artefatos de entrada
∗ Mandatórios
· Documento de Visão
– Artefatos de Saída
∗ Mandatórios · Caso de Uso
Esta tarefa de análise e definição de elementos comuns e variáveis presente na nossa abordagem, é importante para termos o conhecimento de quais artefatos do processo po-dem ser levados em consideração quando for gerado um novo processo desoftware. Essa
tarefa envolve conhecimento em engenharia de processo e também um grande conheci-mento da aplicação destes processos em projetos específicos e esta tarefa é geralmente atribuída ao engenheiro desoftware. Para contemplar tal objetivo, esta atividade produz
como artefato de saída, uma matriz contendo todos os elementos do processos que podem ser considerados comuns e variáveis. Este artefato é chamado de matriz de variabilidade. Uma matriz de variabilidade pode ser considerada uma relação das variabilidades exis-tentes no processo, encontradas durante a análise da linha de processos, e a especificação dessa variabilidade, em diferentes granularidades, no projeto dessa linha. A Figura 3.6 ilustra a matriz de variabilidades do nosso exemplo.
Tendo definido as variabilidades e similaridades no processo podemos agora seguir para a próxima atividade relacionada a gerência das variabilidades. Vale lembrar que o foco principal da abordagem proposta nesta dissertação de mestrado, não está em oferecer heurísticas ou diretrizes para a modelagem de variabilidades de linhas de processo, mas sim no suporte automático para gerenciá-las.
3.3
Gerência Automatizada de Variabilidades
da especificação de modelos que podem ser manipulados por uma ferramenta de derivação. Esse é um passo fundamental que habilita os engenheiros de processo a poderem geren-ciar as variabilidades do processo. Esta seção detalha o processo de uso e adaptação da ferramenta GenArch com tal propósito.
3.3.1
Anotando Modelos de Processo com Variabilidades
Para permitir a gerência das variabilidades de uma linha de processo, foi necessário selecionar uma ferramenta de derivação que apoiasse a realização de tal atividade. A ferramenta GenArch foi escolhida nessa etapa, por duas razões principais: (i) ela foi de-senvolvida usando tecnologias compatíveis com a especificação de processos do frame-work EPF, tais como, o Eclipse Modeling Frameframe-work (EMF) e o openArchitectureWare (oAW); e (ii) ela oferece facilidades de extensão que facilitam a adaptação da ferramenta para manipular os artefatos de especificação de processos oferecidos pela ferramenta EPF [CIRILO et al., 2008].
O GenArch foi inicialmente desenvolvido para trabalhar com linhas de produto im-plementadas usando a linguagem Java e AspectJ6. Mais recentemente, a ferramenta foi
também adaptada para trabalhar com outras linguagens e frameworks [CIRILO et al., 2008][CIRILO et al., 2008]. O GenArch oferece suporte para a derivação automática de produtos durante a engenharia de aplicação, a partir dos artefatos de implementação produzidos na engenharia de domínio para arquiteturas de LPSs. A ferramenta permite a criação automática de três modelos (arquitetura, característica e configuração) que aux-iliam nesse processo de derivação, a partir da análise sintática de anotações Java. Tais anotações são inseridas dentro de artefatos que implementam a arquitetura da LPS, e in-dicam que variabilidades cada um deles implementa. Para permitir o uso da ferramenta GenArch na gerência de variabilidades de uma linha de processo, foi necessário adaptá-la com a criação de novas funcionalidades que permitissem a manipulação de artefatos de uma especificação de processo geradas no EPF Composer. Como uma especificação de processo gerada no EPF é definida através de um conjunto de arquivos XMI, onde cada um deles representa uma parte bem definida (atividade, tarefa, artefato) do processo, foi necessário estender a ferramenta para permitir a leitura e manipulação de arquivos XMI. No lugar de anotações Java, foram usados comentários XML com o mesmo formato das anotações dos arquivos Java anotados. Tais anotações/comentários XML podem então ser lidas e processadas para automaticamente produzir os modelos usados na derivação
automática. Os detalhes de implementação desta adaptação podem ser vistos no capítulo 4.
Assim, após a adaptação da ferramenta GenArch para permitir a gerência de vari-abilidades em linhas de processo especificadas no EPF, a sua utilização em tal contexto, passou a obedecer os seguintes passos: (i) exportação do processo que se deseja gerenciar variabilidades, a partir da ferramenta EPF Composer - dado que estamos interessados em gerenciar variabilidades em um processo EPF, esse passo é importante para permitir a exportação dos artefatos que representam o processo de forma a promover a gerência de variabilidades sobre o mesmo. A ferramenta permite essa exportação na forma deMethod Plug-in, que é um container de conteúdos de métodos e do processo, especificados como
uma série de arquivos XMI; (ii) inclusão dos comentários/anotações XML dentro dos el-ementos de processos (arquivos XMI) para indicar explicitamente a que variabilidades cada um deles está relacionado - este passo é realizado com o auxílio de uma matriz de variabilidades (Figura 3.6), gerada a partir da análise das customizações necessárias ao processo em questão, para atender às necessidades dos diferentes tipos de projetos; e (iii) importação dos artefatos que especificam a linha de processo na forma de um Method Plug Inno Eclipse EPF - este passo consistiu na importação dos arquivos XMI anotados
que representam o processo na forma de um projeto EPF dentro do Eclipse.
Figura 3.6: Matriz de Variabilidade
O procedimento de adicionar comentários-anotações XML nos arquivos XMI para indicar cada variabilidade é relativamente trabalhoso, por se tratar ainda de uma tarefa manual, e complexo, pois exige um conhecimento razoável da estrutura física de ar-mazenamento dos arquivos relativos a especificação de processo no UMA. Por fim, os diferentes arquivos XMI relativos a diferentes elementos do processo foram devidamente marcados com comentários XML. A Figura 3.7 demonstra as anotações das variabili-dades, na forma de comentário XML, presentes nos arquivos XMI que formam a linha de processo. Analisando a anotação presente no fragmento de código XML, temos que a anotação @Feature caracteriza a presença de uma variabilidade referente ao arquivo
que pertence, o atributo name atribui um nome que servirá de identificação desta
Figura 3.7: Arquivo XMI com um comentário representando umafeature
vinculada. O atributotypedefine que tipo de variabilidade afeaturerepresenta, que pode
seroptional, mandatoryoualternative. Uma característica alternativa pode ser
exempli-ficada como sendo uma opção de seleção dentre várias outras opções, sendo esta seleção mutuamente exclusiva. Um exemplo seria: templatesde um documento associado como
artefato de entrada ou saida de uma determinada tarefa, onde poderiamos escolher um
templatedentre diversas opções.
3.3.2
Criação de Modelos de Derivação
A ferramenta GenArch promove a automação do processo de derivação através da modelagem e especificação de três modelos: (i) modelo de característica(features)- que
indicam as características comuns (similaridades) e variáveis (variabilidades) existentes na linha de processo/produto, além de permitir a definição de restrições(constraints)
en-tre os mesmos; (ii) modelo de arquitetura do processo - que representa visualmente os artefatos de implementação usados na estruturação da linha de processo/produto; e (iii) modelo de configuração - que especifica o mapeamento entre variabilidades presentes no modelo de característica e artefatos de implementação presentes no modelo de arquitetura do processo. Tais modelos representam a realização do modelo generativo proposto por Czarnecki [CZARNECKI; EISENECKER, 2000] e adotado por algumas ferramentas de derivação existentes.
No caso de linhas de processo definidas usando o framework EPF, a ferramenta
