uma abordagem dirigida por modelos para gerência de

Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaPrograma de Pós-Graduação em Sistemas e Computação

Uma Abordagem Dirigida por Modelos para Gerênciade Variabilidades e Execução de Processos de Software

Wanderson Câmara dos Santos

Natal/RNFevereiro de 2011

Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaPrograma de Pós-Graduação em Sistemas e Computação

Uma Abordagem Dirigida por Modelos para Gerênciade 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 doNorte como parte dos requisitos para a obtençãodo grau de Mestre em Sistemas e Computação.

Autor: Wanderson Câmara dos SantosOrientador: Prof. Dr. Uirá Kulesza

Natal/RNFevereiro de 2011

"Este trabalho é dedicado aos meus avós Itamar Câmara e Terezinha Freitas Câmara.(in memoriam)."

Wanderson.

iv

Agradecimentos

• Gostaria de agradecer a deus, por tudo, porque quem tem Deus como império nomundo 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 sonhare por simplesmente acreditarem que poderia transformar meus sonhos em realidade;

• Aos meus pais Edivaldo José dos Santos e Irismar Freitas Câmara dos Santos, queestã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 pelosensinamentos e amizade;

• A todas as pessoas que me apoiaram e estiveram presente durante todos os momen-tos.

v

Resumo

Este trabalho apresenta uma abordagem dirigida por modelos para gerência de vari-

abilidades em processos de software, 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 deSoftware, Desenvolvimento Dirigido por Modelos

vi

Abstract

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 engineering technologies. The software processes are specified using

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 drivendevelopment

vii

viii

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 de Software . . . . . . . . . . . . . . . . . . . . . p. 8

2.2.1 Eclipse Process Framework . . . . . . . . . . . . . . . . . . . p. 9

2.3 Linhas de Produto de Software . . . . . . . . . . . . . . . . . . . . . . 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 de Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

2.5.1 JBoss BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

3 Uma Abordagem Dirigida por Modelos para Gerência de Variabilidades

e Execução de Processos de Software p. 20

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 um Workflow En-

gine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

4 Suporte Ferramental da Abordagem p. 51

4.1 Ferramenta para Gerência de Variabilidade em Processos de Software . 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

ix

5.7 Implantando e Executando Processos de Software em um Workflow En-

gine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70

5.8 Lições Aprendidas e Novas Perspectivas . . . . . . . . . . . . . . . . . p. 72

5.8.1 Mapeamento de especificações de processo em Workflow . . . . p. 72

5.8.2 Integração do código do Workflow com ferramentas de engen-haria de software . . . . . . . . . . . . . . . . . . . . . . . . . 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 emProcessos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78

6.2 Abordagens para Execução de Processos de Software . . . . . . . . . . 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

x

xi

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 do Method Plugin na Ferramenta EPF Composer . . . . . . . . p. 25

3.4 Elementos Presentes no Processo . . . . . . . . . . . . . . . . . . . . . p. 26

3.5 Visualização do processo na forma de um work breakdown structure naferramenta EPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

3.6 Matriz de Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3.7 Arquivo XMI com um comentário representando uma feature . . . . . . p. 31

3.8 Modelo de features gerado 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 doProcesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3.13 Modelo de Arquitetura do Processo gerado pelo GenArch com a adiçãode Fragmentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

3.14 Modelo de Configuração gerado pelo GenArch com a adição de Frag-mentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

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 tarefa Criar os Casos de Teste . p. 42

3.19 Imagem com Work breakdown structure do 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 do workflow através do Plug In GPD 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 relacionaformulá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 de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53

4.2 Código para o parsing dos arquivos XMLs a procura de anotações devariabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

4.3 Fragmento de Código QVT0, destacando como parâmetros para exe-cução do script a 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 modelo-para-modelo e modelo-para-texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56

xii

4.5 Visualização dos metamodelos instanciados pelo Eclipse, através dometamodel explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56

5.1 Trecho do resultado do estudo de variabiliades e similaridades do OpenUP p. 60

5.2 Work Break down Structure resumido 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ágina web . . . . . . . . . . . . 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 arquivo forms.xml responsável pela ligação das tarefascom seus formulários . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70

5.12 Arquivos gerados na Transformação de modelo-para-texto . . . . . . . p. 71

5.13 Efetuando o deploy do workflow . . . . . . . . . . . . . . . . . . . . . p. 72

5.14 página de upload, disponível no jBPM Console, para a implantação deprocessos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

xiii

1

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 depromover o desenvolvimento produtivo de softwares de qualidade. Há uma necessidadecrescente por parte da indústria de desenvolvimento de sistemas na rápida e efetiva cus-tomização de processos de software para 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 demodelos de processo de software para a realidade dos projetos das organizações. Assimcomo o reuso de experiências passadas na definição e desenvolvimento de processos desoftware para os novos projetos com o objetivo de aumentar a produtividade durante arealização de tal atividade.

Ao longo dos últimos anos, diversas ferramentas e tecnologias que oferecem suportea definição, empacotamento, customização, distribuição e execução de processos de soft-

ware foram propostas [IBM, 2010] 1. O apoio de ferramentas auxiliam na automatizaçãodas atividades do engenheiro de processos permitindo a manipulação de artefatos rela-cionados à especificação e definição de processos de software e, embora tais ferramentasjá 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 gerenciamentodos componentes e variabilidades de tais processos; e (ii) a composição e derivação desteselementos para gerar um processo customizado para um projeto. A definição de um pro-cesso de software é uma atividade complexa que requer muita experiência e conhecimentode muitas áreas e disciplinas da engenharia de software [BARRETO et al., 2010]. Dessaforma, 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 demaneira rápida e automática permitindo sua fácil customização para novos projetos.

1PROJECT, E. Eclipse Process Framework Project (EPF). 2009. Disponível em: http://www-01.ibm.com/software/awdtools/rmc. Acesso em: 3 Ago. 2009.

1. Introdução 2

1.1 Problema

Atualmente, empresas de desenvolvimento de software buscam a melhoria contínuada qualidade e produtividade de seus processos de desenvolvimento. O desenvolvimentode software envolve várias tarefas complexas e envolve diferentes profissionais de diversasáreas. Projetos de desenvolvimento de software de naturezas distintas também demandama adoção de novos processos, técnicas e ferramentas a serem utilizadas.

Um dos caminhos para lidar com tal complexidade, é promover o reuso de processoslegados adotados com sucesso em outros projetos, e permitir a customização de partes es-pecíficas de acordo com as peculiaridades do software a ser desenvolvido, assim como danatureza 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çãode processos de software não permite que a customização de variabilidades do processoseja realizada de forma rápida e confiável, garantindo assim uma boa qualidade para oresultado final. Algumas ferramentas atuais auxiliam no trabalho de especificar e editarespecificações de processos de software [IBM, 2010] 2, porém não de forma intuitiva etratando explicitamente o conceito de variabilidades. Elas permitem apenas a manipu-lação manual e trabalhosa de elementos presentes nas definições de processos, sendo estauma 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 equipeenvolvida nele.

Um outro problema existente diz respeito ao acompanhamento e monitoramento daexecução de tais processos de software, 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 grandecarência no que se refere a transformação de processos especificados seguindo metamod-elos voltados exclusivamente para especificação de processos de software (UMA 3, SPEM4) 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.

4GROUP, O. M. OMG. Software Process Engineering Meta-Model, version 2.0. 2008. Disponível em:http://www.omg.org/technology/documents/formal/spem.htm Acesso em: 10 jan. 2010.

1. Introdução 3

1.2 Limitações das Abordagens Atuais

Apesar de oferecer funcionalidades para a manipulação de elementos presentes naespecificação do processo, ferramentas como o EPF Composer e o Rational Method

Composer [IBM, 2010], não oferecem funcionalidades e mecanismos que permitam agerê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 OpenUP 5, possuem inúmeras possibilidades de customização econfiguraçã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 sujeitaa erros. Alguns dos frameworks de processo citados até explicitam elementos do processo(atividades, tarefas, passos, artefatos) que são opcionais, mas a maioria deles se refere adecisõ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 vezdefinido 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ésda 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, dificultandotambém sua evolução como uma família de processos relacionados. No que diz respeito aexecução de processos, existem linguagens de definição de fluxos de processos e engines

para esses workflows. 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 paraque fosse possível o engine executar nosso fluxo principal de processo.

De forma geral, podemos dizer que as abordagens, técnicas e ferramentas disponíveisatualmente, são bastante carentes no que se refere: (i) a gerência de variabilidades emprocessos; (ii) a derivação automática de versões específicas de tais processos; e (iii) atransformaçã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 definidopara tal finalidade.

1.3 Trabalho Proposto

Esta dissertação de mestrado propõe uma abordagem baseada em modelos para agerência de variabilidades e execução de processos de software. Seus principais objetivos

5http://epf.eclipse.org/wikis/openup/

1. Introdução 4

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, denominadaGenArch [CIRILO, 2008], para promover a gerência explícita das variabilidades de umalinha de processo [ARMBRUST et al., 2009]. Uma linha de processos pode ser vistacomo um conjunto de processos que compartinha similaridades e possuem variabilidadesdecorrentes das especificidades de cada um dos processos que fazem parte da linha. Osmodelos de processo de software utilizados neste trabalho são especificações do meta-modelo Unified 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 permiteque cada especificação de processo EPF derivado automaticamente, possa ser automati-camente transformado para uma especificação de workflow, que pode ser instalado e exe-cutado no engine de workflow jBPM.

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çãoautomática de processos, assim como permitir sua execução e monitoramento. Cadafamília de processos relacionados é organizado como uma linha de processos. Os seguintesobjetivos específicos são definidos para este trabalho de mestrado:

• Proposição de mecanismos para gerência de variabilidades e derivação automáticade processos de software com foco na disciplina de gerência de projetos, assimcomo transformação de especificações de processo EPF em especificações concre-tas de workflow que podem ser instaladas em sistemas de gerenciamento de work-

flows.

• Implementação dos mecanismos mencionados acima como forma de avaliação daabordagem proposta.

6http://epf.eclipse.org/wikis/openupsp/baseconcepts/guidances/concepts/introduction.html7http://www.omg.org/technology/documents/formal/spem.htm8PROJECT, E. Eclipse Process Framework Project (EPF). 2009. Disponível em: <http://www-

01.ibm.com/software/awdtools/rmc>. Acesso em: 3 Ago. 2009.

1. Introdução 5

• Modelagem de estudo de caso de linha de processo de software para 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 apresenta aabordagem 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 linhade produto de software para trabalhar com especificações de processo de software. O capí-tulo 5 demonstra a aplicação da abordagem aplicada em um estudo de caso. No capítulo6 apresentamos trabalhos relacionados que motivaram e ajudaram a criar e desenvolver aabordagem proposta neste trabalho. No capítulo 7 apresentamos as considerações finais.

6

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 de software;(iv) Ferramentas de derivação; (v) Engenharia dirigida por modelos; e (vi) Sistemas deworkflow.

2.1 Engenharia de Processos

Metodologias de desenvolvimento de software são utilizadas regularmente pela in-dústria de software para diferentes tipos de projetos. A engenharia de processos de soft-

ware consiste na criação, modelagem, adaptação e representação desses processos. Deacordo com o Software Engineering Body of Knowledge (SWEBOK) 1, a área de conhe-cimento da "Engenharia de Processo de Software"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 ciclode 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 conhecimentoda engenharia de processo pode ser dividida em diversas sub-áreas. A Figura 2.1 ilustratal 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, modelose infraestrutura para o processo de implementação e gerência de mudanças. Para estasub-á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 infraestruturaaplicada no processo, garantindo que todos os recursos necessários estejam disponíveis;

1IEEE Computer Society. Software Engineering Body of Knowledge (SWEBOK). EUA: AngelaBurgess, 2004. Disponível em: http://www.swebok.org/.

2. Fundamentação Teórica 7

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 ogerenciamento do processo, e para melhor obter esse gerenciamento contam com ativi-dades como “estabelecer a infraestrutura do processo”e “planejamento”; e (iii) modelospara implementação e gerência de mudanças dos processos - provê a implementação demodelos para apoiar a execução desta sub-área.

Definição do processo. Esta sub-área da engenharia de processos exige um grandeesforç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 eapoio 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çãodas fases que auxiliam no desenvolvimento. Exemplos desses modelos são: modelo emcascata e o modelo espiral; (ii) processo de ciclo de vida do software - esse tópico tendea ser mais detalhado do que os modelos de ciclo de vida do software; (iii) notações para adefiniçã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 deinformações utilizadas. (iv) adaptação do processo - os processos de software que sãopré-definidos precisam se adaptar a diversos contextos como: tamanho do projeto, práticasindustriais e culturas corporativas e (v) automação - diz respeito ao apoio ferramental que


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 adivisã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 realizaruma avaliação, um método de avaliação específico deve ser seguido para produzir dadosque 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 ainiciaçã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 comoinformações de entrada, dados relativos a quantitativos coletados, analisados e interpreta-dos do processo, que são usados para identificar os pontos fortes e fracos dos processos,e também avaliar esses processos depois de terem sido implementados e/ou alterados; (ii)medição de produtos de software - 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 delimitados dos processos; (iv) modelos de informação de software - amaneira como a informação é coletada e utilizada para fins de medição, torna possível aconstrução de modelos utilizando a experiência e dados obtidos. Estes modelos existempara 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 de software e identificarpontos fortes e pontos fracos desses processos.

Este trabalho de dissertação tem relação mais direta com a sub-área de Definição doProcesso, a qual envolve notações para a definição do processo, adaptação de processos eautomação da engenharia de processos. Em particular, o trabalho busca promover o reusode 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 promovera reutilização de processos como forma de promover o uso de boas práticas de projetosanteriores na definição dos novos processos. Uma das principais vertentes de trabalhoatual diz respeito ao uso e adaptação de técnicas de linhas de produto de software, nagerência de variabilidades encontradas em linhas de processo. Uma linha de processo


pode ser vista como uma família de processos que compartilham elementos de processocomuns e variáveis. Baseado em tal definição, frameworks de processos existentes podemser também caracterizados como linhas de processo.

Reusar especificações parciais de processos de software existentes de maneira rápidae automática, permitindo sua fácil customização para novos projetos é ainda um desafiopara 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 promovere ampliar a reutilização de especificações de processos de software, tais como, o Ratio-

nal Unified Process (RUP) [KRUCHTEN, 2003]. Em paralelo, ferramentas têm tambémsido propostas para viabilizar a automação durante tal processo de reutilização. O EPFComposer [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 presentesna especificação de processos.

2.2.1 Eclipse Process Framework

Projetos diferentes têm necessidades diferentes e gerenciar a customização dessesprocessos 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 gerenciamentodessa complexidade. Um exemplo dessas ferramentas é o Eclipse Process Framework

(EPF), que é uma ferramenta de apoio aos engenheiros de processo, líderes de projeto egerentes 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émum 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) forneceruma estrutura extensível e ferramentas para a engenharia de processo de software comogestã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 de software e gerenciamento de processos de suporte de desenvolvimento iterativo,ágil e incremental, e aplicável a um amplo conjunto de plataformas de desenvolvimento eaplicaçõ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.

3IBM. Rational Method Composer. IBM - RUP. 2010. Disponível em: http://www-01.ibm.com/software/awdtools/rmc. Acesso em: 10 Jan. 2010.


2.3 Linhas de Produto de Software

O conceito de linha de produtos de software, consiste em um conjunto de sistemas desoftware que compartilham um conjunto comum de features gerenciadas, que satisfazemnecessidades 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 comouma 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 de software com características suficientemente similares para permitira definição de uma infra-estrutura genérica de estruturação de artefatos que compõem osprodutos 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 doproduto [LINDEN; SCHMID; ROMMES, 2007] entre as outras vantagens de se utilizar aabordagem de linha de produtos de software podemos 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 produtoconsegue 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çãodeste artefato, o tempo de produção é drasticamente reduzido; (ii) redução no esforçode manutenção, uma vez efetuada a manutenção numa linha de produto essa correçãose 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 ocorrerevoluções de implementação que serão repassadas para os produtos também derivadosdesta LPS; (iv) complexidade gerenciável, um dos maiores benefícios é o gerenciamentoda 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 deprodutos, 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 possaprovocar 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 osaspectos anteriores implicam em uma redução brusca de custos de uma corporação paraa manutenção e evolução dos seus produtos de software.

4COHEN, S. G. Product Line State of the Practice Report. 2003. Disponível em:http://www.sei.cmu.edu/library/abstracts/reports/02tn017.cfm Acesso em: Ago. 2010.


Para a implementação da abordagem de linhas de produto de software podem serutilizadas 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, omaior 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 novosprodutos 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 evariáveis de um conjunto de softwares bases, previamente desenvolvidos e geralmenteque estejam em produção.

A utilização destas técnicas não é mutuamente exclusivo, por exemplo, no início dodesenvolvimento da LPS podemos ter como base um conjunto de produtos já existentese incrementalmente evoluir a arquitetura com acréscimos de novos produtos. Essa visãocorresponde a adotar inicialmente a abordagem extrativa e, posteriormente, passar parauma abordagem reativa. O processo de gerenciamento de um núcleo de artefatos software

é composto por dois estágios: engenharia de domínio e engenharia de aplicação.

Segundo [LOBO; RUBIRA, 2009] [PRIETO-DIAZ; ARANGO, 1991] engenharia dedomí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 autilização sistemática destes artefatos na construção de novas aplicações. A engenhariade 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çãode 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 componentespara a linha de produto; e (iii) implementação do domínio - atividade responsável pelaimplementação da arquitetura comum e dos componentes previamente definidos na ativi-dade de projeto do domínio. A engenharia de aplicação consiste no desenvolvimentode sistemas a partir dos artefatos produzidos na engenharia de domínio [CZARNECKI;EISENECKER, 2000].

2.3.1 Ferramentas de Derivação

Para o uso da abordagem e técnicas de linha de produtos se faz necessário a uti-lização de ferramentas que auxiliem o trabalho de derivação dos produtos [DEELSTRA;SINNEMA; BOSCH, 2005] gerados a partir da linha, auxiliando na seleção, composiçãoe configuração dos artefatos, gerenciando de uma maneira completa as variabilidades pre-sentes na linha, para a perfeita derivação de produtos. Como exemplos de ferramentas de


derivação de produtos de software baseadas em modelo de feature, podemos citar, entreoutras, o Gears 5, pure::variants 6 e GenArch [CIRILO; LUCENA, 2009]. As ferra-mentas citadas visam oferecer um apoio para a automatização do processo de utilizaçãoda abordagem de linha de produtos de software no que se refere a derivação dos produtosda linha.

Gears é uma ferramenta de engenharia de linha de produtos e um framework queaborda os desafios específicos para a geração de uma variedade de produtos da linha, du-rante todo o ciclo de desenvolvimento 7. A ferramenta Gears permite a adoção/construçãode LPS seguindo a abordagem incremental. Dessa forma, é possível iniciar a construçãode produtos a partir de um ou dois subsistemas, módulos ou artefatos, e então transferirfacilmente, 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 paraapoiar nossa abordagem é a ferramenta de derivação Genarch [CIRILO, 2008], por seruma ferramenta de derivação de linha de produtos de software baseada em modelos e serdesenvolvida em uma arquitetura de plugin do Eclipse conforme pode ser visto Figura2.2.

Um fator determinante para a escolha desta ferramenta como ferramenta de apoiopara 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 de Software

da Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO) 8, onde há uma maiorintegração e colaboração com a equipe de estudos desta instituição.

A ferramenta utiliza os recursos do Eclipse Modeling Framework (EMF) para a ma-nipulação de metamodelos e modelos, e a API Eclipse JDT Java Development Tool parater acesso a anotações feitas na classes indicando as variações existentes no código. Aindicaçã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. 20097GEARS. Software Product Lines - Pragmatic Innovation from BigLever Software. 2009. Disponível

em: http://www.biglever.com Acesso em: 3 Nov. 2009.8http://www.les.inf.puc-rio.br/


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 nalinha 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 osartefatos 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 nomodelo 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 propostopor Czarnecki [CZARNECKI; EISENECKER, 2000] e adotado por outras ferramentas dederivação existentes. A ferramenta GenArch foi escolhida no nosso trabalho, por facilitara manipulação de modelos que representam variabilidades explicitamente, e por permitira sua extensão e adaptação para modelos de processo EPF especificados usando o Ecore,que é um metamodelo utilizado pelo EMF para definir outros modelos 9.

9http://www.eclipse.org/modeling/emf/?project=emf


Figura 2.3: Exemplo de identificação de variabilidades no código utilizando anotaçãoJava

2.4 Engenharia Dirigida por Modelos

Desde o começo da programação de sistemas de software a engenharia de software

tem buscado elevar o nível de abstração para especificar, modelar e implementar sistemasde software. 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ãoapenas usados para auxiliar no processo de desenvolvimento, mas são considerados osartefatos 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óricapara 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 deindependência de plataforma [VOS, 2008]. De acordo com o OMG, MDA fornece umaabordagem para a especificação de sistemas e seu comportamento independentemente da


sua plataforma. MDA é baseado nos seguintes padrões UML 10, XMI 11, QVT 12, OCL 13

e MOF 14. 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. Omodelo 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 finalidadede 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 umarepresentação independente de plataforma para o sistema, este modelo é o primeiro passopara a criação do sistema. O modelo PSM, ou modelo específico de plataforma, é ummodelo de mais alto nível da especificação do sistema e dependente de plataforma, estemodelo é obtido do modelo PIM através de transformação entre modelos.

2.4.2 Acceleo

Acceleo é uma linguagem open source padronizada pela OMG baseada em uma abor-dagem MDE para a transformação de modelos, com o Acceleo podemos transformarnossas especificações de modelos para texto, desde que os nossos modelos obedeçam ummetamodelo 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 emconjunto com MDA (Model Driven Architecture). O Acceleo oferece extensões paraa 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 Eclipseprovendo para o desenvolvedor um ambiente homogêneo de desenvolvimento. Esta trans-formação acontece a partir da criação de templates no 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.

15http://wiki.eclipse.org/Acceleo


plates no Acceleo usamos os modelos EMF para a geração dos nossos artefatos desejadoscomo 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çãode um novo modelo pode-se utilizar uma grande variedade de softwares, isto é possívelporque 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 é umaestraté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 casode sistemas de software podemos trabalhar em um modelo independente de plataforma,um modelo PIM, e a partir de requisitos funcionais do nosso sistema transformar estemodelo para um modelo específico de Plataforma, ou seja em um modelo PSM. Para queesta transformação ocorra podemos fazer uso de linguagens de transformação de modelosQVT 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

16OMG. QVTO Specification. 2008. Disponível http://www.omg.org/spec/QVT/1.0/. Acesso em: 07Out. 2009.


consultas, exibições e transformações em modelos que sigam o metamodelo UMA 17 eesse 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 ummodelo 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 QVT Relations eQVT Operational 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 QVT core. QVTO é uma linguagem imperativa que estende ambas linguagens QVTRelation e QVT Core. Em geral, QVT pode somente ser utilizada na transformação demodelo 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 deum 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, podendoser 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 procedimentos para seobter 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 de workflow podendo 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/),Bonita Open Solution (http://www.bonitasoft.com/), JawFlow (http://jawflow.sourceforge.net/)


do conceito de sistemas de gerenciamento de processos de negócio 19, sendo definidocomo um sistema que permitem a definição e gerência de procedimentos para se obter umproduto ou serviço.

A maioria dessa ferramentas nos oferece uma interface gráfica para a definição dofluxo de trabalho, isso é uma forma de tornar mais interativa a escrita do nosso workflow ecom a crescente complexidade dos processos discutida no início da seção surgiu tambéma necessidade a criação de padrões de definição de processos 20, [JURIC, 2006], [PENG;ZHOU, 2008].

Sistemas de workflow ajudam 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 deworkflow.

2.5.1 JBoss BPM

O jBPM é um framework da jBOSS que permite a criação de soluções empresariaisbaseados em processos de negócio usando notações gráficas, como também programaçãoorientada a grafos e um engine de workflows. Esta ferramenta tem a característica de fazeruma 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écnicas 21. O jBOSS BPMfunciona 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 erepresentam um fluxo de execução. O engine jBPM oferece também uma visualizaçãoem forma gráfica do processo servindo como base de comunicação entre pessoas técnicase 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 aindapossui uma interface gráfica para a exibição das execuções dos processos onde os usuáriosenvolvidos 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çãode tarefas e dar andamento nas tarefas que estão executando.

19do inglês Business Process Management System (BPMS)20XML Process Definition Language (XPDL)). 2010. Disponível em: http://www.xpdl.org. Acesso em:

Ago. 2010.21JBOSS. jBPM. 2010. Disponível em: http://jboss.org/jbpm. Acesso em: 01 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 BPMN 22

e JPDL 23 estão ganhando mais espaço nesta ferramenta. A especificação de processosna 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ãoespecificados visualmente, através da edição do código JPDL que será executado peloengine JBPM, o plugin cria um arquivo chamado processdefinition.xml, que é uma es-pecificação de processo seguindo um metamodelo JPDL. O plugin também oferece umcanal deployment do processo, e todo processo que é executado pelo engine de workflow

é armazenado em um banco de dados, uma vez que o jBPM engine é compatível e podeser 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.24http://www.eclipse.org/jbpm

20

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 emprocessos de software, assim como mecanismos para promover a execução de processosde software em um engine 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ágioda abordagem.

3.1 Visão Geral da Abordagem

A abordagem proposta nesta trabalho visa a especificação de uma linha de processode software, o gerenciamento de variabilidades durante a customização de processos desoftware específicos e sua execução e monitoramento através de um motor de workflow. Otrabalho utiliza uma abordagem dirigida por modelos para a especificação, gerenciamentoe execução de processos de software. A Figura 3.1 apresenta uma visão geral da primeiraetapa 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, nocaso deste estudo o processo de software. Na Figura 3.2 temos a visão da segunda etapada nossa abordagem, onde temos as transformações modelo-para-modelo e modelo-para-texto, que permitem a implantação, execução e gerenciamento do processo em um engine

de workflow.

A abordagem parte da modelagem e definição de uma linha de processo de software

(índice 1 da Figura 3.1 ), utilizamos para esta etapa da abordagem, ferramentas que ofer-

3. Uma Abordagem Dirigida por Modelos para Gerência de Variabilidades eExecução de Processos de Software 21

ecem recursos e funcionalidades para a definição/modelagem de processos, através dautilização de linguagens de modelagem de processos. A linha de processo foi construidautilizando a ferramenta EPF (Eclipse Process Framework) (índice 3 da Figura 3.1). Cadaconteúdo de trabalho de um processo EPF é definido através da linguagem de modelagemde processo Unified Method Architecture (UMA) 1, que é um subconjunto de uma outralinguagem a Software Process Engineering Meta-Model (SPEM) 2, e que serviu de basepara 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ãode 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 (índice4 da Figura 3.1) . Em seguida, a abordagem se concentra na gerência de variabilidadesdos 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 Figura3.1 ), resultados da definição da linha de processo. Como resultado dessa atividade temoscomo artefatos de saída os modelos de derivação (índice 8 da Figura 3.1 ). Esses artefatosforam produzidos com o apoio da ferramenta de derivação GenArch (índice 6 da Figura3.1 ). Na atividade seguinte, também com o auxílio da ferramenta de derivação GenArch,acontece a derivação automatizada de processo (índice 9 da Figura 3.1 ), que utiliza osartefatos produzidos no passo anterior para seleção das features relevantes para um pro-cesso, possibilitando a geração de processos de software customizados, que lidem comcenários e necessidades específicas de um dado projeto (índice 10 da Figura 3.1 ). O pa-pel responsável 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 amplona área de definição de processo de software.

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 de software a partir da linha de processos (índice 10 da Figura 3.2 ), o modelo querepresenta 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 Figura3.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 apartir da linha e que gera como saída um modelo de workflow seguindo 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

2GROUP, O. M. OMG. Software Process Engineering Meta-Model, version 2.0. 2008. Disponível em:http://www.omg.org/technology/documents/formal/spem.htm Acesso em: 10 jan. 2010.


Figura 3.1: Uma Visão da Abordagem para Gerência e customização de variabilidades eDerivação de Processo


Figura 3.2: Uma Visão da Abordagem para Execução de Processos de Software


meta-modelo de workflow JPDL 3 (índice 13 da Figura 3.2 ). Para implementar a trans-formação modelo-para-modelo proposta por esta atividade foi utilizada a linguagem detransformação QVT 4 (índice 12 da Figura 3.2 ). Após a geração do modelo de workflow,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 omodelo de workflow JPDL como artefato de entrada para a transformação (índice 13 daFigura 3.2 ) e temos como resultado deste passo os artefatos de saída (índice 17 da Figura3.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 workflow jBPM 5 (índice 20 da Figura 3.2 ). Etemos que o papel responsável pelo gerenciamento do workflow (í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ênciade variabilidades e execução de processos de software. A abordagem foi dividida em eta-pas, onde foram definidos os papéis responsáveis pela execução das tarefas, os artefatosde entrada e saída, e as ferramentas e tecnologias que serviram de apoio para a automaçãode cada etapa da abordagem. As transformações modelo para modelo (M2M) foramcodificadas em QVT Operational para possibilitar a transformação automática de especi-ficações UMA em elementos do modelo jPDL (JBoss Process Definition Language). Aespecifiçã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ários web querepresentam a especificação de um workflow jPDL, codificados de acordo com a tecnolo-gia Java Server Faces (JSF). Por fim, estes formulários web são implantados e executadosno motor de workflow JBoss Business Process Management (jBPM) e permitindo, fi-nalmente, o gerenciamento do workflow de processo de software. As seções seguintesdetalham 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 primeiraatividade para a definição de uma linha de processos de software é o estudo das similari-dades e variabilidades 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: 07Out. 2009.

5http://www.jboss.org/jbossjbpm/


ware proposta pelo EPF. Para exemplificação desta etapa de identificação e modelagemde similaridades, precisamos montar nossa linha de processos. Para isso precisamos criarum Method PlugIn, que pode ser considerado, conceitualmente, uma representação deuma unidade para a configuração, modularização, extensão e distribuição de conteúdosde processos. Uma vez criado o Method PlugIn podemos a partir desse ponto criar todosos elementos presentes em um processo de software através do EPF Composer. A Figura3.3 ilustra a criação de um Method PlugIn.

Figura 3.3: Criação do Method Plugin na Ferramenta EPF Composer

O EPF Composer utiliza uma abordagem baseada em formulários para a definição erelação dos elementos de processo, tais como: papéis, tarefas e artefatos. A Figura 3.4apresenta os elementos na definição do processo que utilizaremos como exemplo. Como EPF Composer, um engenheiro de processo pode definir um novo processo, reusandoelementos de outros processos previamente definidos na ferramenta, dessa forma o EPFfunciona como um repositório de artefatos de processo.

Na definição de um processo na ferramente EPF Composer, podemos definir partedos nossos elementos de processo como sendo elementos que podem ser reutilizados emdiversas etapas do processo.

Ao finalizar a edição de um processo de software, é possível gerar uma publicaçãodo mesmo, na forma de um site Web. A definição de um processo com o EPF, é fisi-camente constituída por uma estrutura de diretórios, contendo arquivos XMI seguindo o


Figura 3.4: Elementos Presentes no Processo

metamodelo UMA. Embora o EPF já forneça algum apoio para especificar e definir pro-cessos de software, ele não permite a representação de suas variabilidades e nem a suapersonalização automática de processos de software existentes. Ferramentas de derivaçãode produto podem então ser usadas para permitir a seleção das características relevantesde um processo de software existente, permitindo assim a derivação de especificaçõespersonalizadas do processo de software, abordando cenários e projetos específicos.

Uma vez definido o processo, o EPF composer permite a sua visualização na forma deum work breakdown structure. Podemos definir o que pode ser comum e variável dentroda linha de processo através de um estudo dos processos de desenvolvimento de software

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 Casosde Teste. Os seguintes papeis foram também definidos: (i) analista, (ii) desenvolvedore (iii) testador. Esses papeis combinados com as terafas podem definir, seguindo suasespecializaçãos, os seguintes artefatos: (i) Caso de Uso, (ii) Visão e (iii) Caso de Teste. AFigura 3.5 apresenta tal estrutura para o exemplo.

Uma vez realizada a análise sobre os elementos definidos no processo, podemosdefinir o que será comum ou variável considerando a família de processos sendo definida.Na análise no processo podemos considerar que todos os processos derivados a partir da


Figura 3.5: Visualização do processo na forma de um work breakdown structure na ferra-menta EPF

linha , tenham: (i) a tarefa Encontrar e Descrever os Requisitos e Detalhar os Requisi-tos como mandatórias, ou seja, esteja presente em todos os processos que serão derivadosdesta linha; e (ii) como uma característica opcional poder escolher a tarefa Criar os Ca-sos de Teste. Além destas features podemos definir que a tarefa Detalhar os Requisitosseja associada obrigatoriamente ao papel de analista e, opcionalmente, aos demais papéiscomo demostrado a seguir:

• Tarefa : Encontrar e Descrever os Requisitos.

– Papéis mandatórios

∗ Analista

– Papéis opcionais

∗ Desenvolvedor

∗ Testador

Ainda na tarefa Encontrar e Descrever os Requisitos podemos definir os artefatosde entrada e saída que serão mandatórios, opcionais ou alternativos para esta tarefa. Como


artefatos de entrada que serão obrigatórios temos Documento de Visão e como artefatosde saída temos como mandatório Caso 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 nossaabordagem, é importante para termos o conhecimento de quais artefatos do processo po-dem ser levados em consideração quando for gerado um novo processo de software. Essatarefa 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 é geralmenteatribuída ao engenheiro de software. Para contemplar tal objetivo, esta atividade produzcomo artefato de saída, uma matriz contendo todos os elementos do processos que podemser 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çãodessa variabilidade, em diferentes granularidades, no projeto dessa linha. A Figura 3.6ilustra a matriz de variabilidades do nosso exemplo.

Tendo definido as variabilidades e similaridades no processo podemos agora seguirpara a próxima atividade relacionada a gerência das variabilidades. Vale lembrar que ofoco principal da abordagem proposta nesta dissertação de mestrado, não está em oferecerheurísticas ou diretrizes para a modelagem de variabilidades de linhas de processo, massim no suporte automático para gerenciá-las.

3.3 Gerência Automatizada de Variabilidades

Após a identificação e modelagem de similaridades e variabilidades da linha de pro-cesso de software, a atividade seguinte foi prover a gerência de suas variabilidades através


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 daferramenta 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árioselecionar uma ferramenta de derivação que apoiasse a realização de tal atividade. Aferramenta 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 Framework (EMF) e o openArchitectureWare(oAW); e (ii) ela oferece facilidades de extensão que facilitam a adaptação da ferramentapara 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 AspectJ 6. Mais recentemente, a ferramenta foitambé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áticade produtos durante a engenharia de aplicação, a partir dos artefatos de implementaçãoproduzidos na engenharia de domínio para arquiteturas de LPSs. A ferramenta permite acriaçã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. Taisanotaçõ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 ferramentaGenArch na gerência de variabilidades de uma linha de processo, foi necessário adaptá-lacom a criação de novas funcionalidades que permitissem a manipulação de artefatos deuma especificação de processo geradas no EPF Composer. Como uma especificação deprocesso gerada no EPF é definida através de um conjunto de arquivos XMI, onde cadaum deles representa uma parte bem definida (atividade, tarefa, artefato) do processo, foinecessá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 dasanotações dos arquivos Java anotados. Tais anotações/comentários XML podem entãoser lidas e processadas para automaticamente produzir os modelos usados na derivação

6http://www.eclipse.org/aspectj/


automática. Os detalhes de implementação desta adaptação podem ser vistos no capítulo4.

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 gerenciarvariabilidades, a partir da ferramenta EPF Composer - dado que estamos interessados emgerenciar variabilidades em um processo EPF, esse passo é importante para permitir aexportação dos artefatos que representam o processo de forma a promover a gerência devariabilidades sobre o mesmo. A ferramenta permite essa exportação na forma de Method

Plug-in, que é um container de conteúdos de métodos e do processo, especificados comouma 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 variabilidadescada um deles está relacionado - este passo é realizado com o auxílio de uma matriz devariabilidades (Figura 3.6), gerada a partir da análise das customizações necessárias aoprocesso 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 In no Eclipse EPF - este passo consistiu na importação dos arquivos XMI anotadosque 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 paraindicar cada variabilidade é relativamente trabalhoso, por se tratar ainda de uma tarefamanual, 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, osdiferentes arquivos XMI relativos a diferentes elementos do processo foram devidamentemarcados 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 linhade processo. Analisando a anotação presente no fragmento de código XML, temos quea anotação @Feature caracteriza a presença de uma variabilidade referente ao arquivoque pertence, o atributo name atribui um nome que servirá de identificação desta vari-abilidade. O atributo parent representa a que feature na hierarquia a variabilidade está


Figura 3.7: Arquivo XMI com um comentário representando uma feature

vinculada. O atributo type define que tipo de variabilidade a feature representa, que podeser optional, mandatory ou alternative. 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çãomutuamente exclusiva. Um exemplo seria: templates de um documento associado comoartefato de entrada ou saida de uma determinada tarefa, onde poderiamos escolher umtemplate dentre 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 damodelagem e especificação de três modelos: (i) modelo de característica (features) - queindicam as características comuns (similaridades) e variáveis (variabilidades) existentesna 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 osartefatos 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 nomodelo de característica e artefatos de implementação presentes no modelo de arquiteturado processo. Tais modelos representam a realização do modelo generativo proposto porCzarnecki [CZARNECKI; EISENECKER, 2000] e adotado por algumas ferramentas dederivação existentes.

No caso de linhas de processo definidas usando o framework EPF, a ferramentaGenArch permite a criação automática dos modelos de derivação a partir do processa-


mento de comentários/anotações nos arquivos XMI, que representam os elementos doprocesso sendo considerados. Esta seção discute e apresenta em mais detalhes, quem sãotais modelos e como são usados para gerenciar as variabilidades no GenArch. As Figuras3.8, 3.9 e 3.10 apresentam uma visão parcial dos modelos de característica, configuraçãoe arquitetura, respectivamente, considerando a linha de processo criada com o propósitode exemplificar a abordagem.

Figura 3.8: Modelo de features gerado pelo GenArch

O modelo de features ilustra todas as features mandatórias, opcionais e alternativasencontradas durante a análise dos arquivos XMI contidos na estrutura de diretórios doprocesso. Para cada comentário/anotação representando uma variabilidade encontradaem um dos arquivos XMI, uma feature correspondente é adicionada ao modelo de carac-terística. A Figura 3.8 ilustra o modelo de features parcial do processo, indicando suassimilaridades e variabilidades. No modelo de arquitetura do processo temos representadotodos os elementos encontrados durante a análise da estrutura de diretórios representandoa linha de processo. A Figura 3.9 ilustra tal modelo contendo a estrutura de arquivos daespecificação EPF do processo que foi processado pelo Genarch.


Figura 3.9: Modelo de Arquitetura do Processo Gerado pelo GenArch

Já o modelo de configuração é usado para relacionar elementos do modelo de ar-quitetura do processo que representa a linha de produto à features específicas presentesno modelo de features. A Figura 3.10 apresenta uma visão parcial do modelo de con-figuração do processo destacando os elementos que tem dependência de alguma feature

opcional ou alternativa. Todos os modelos gerados são posteriormente usados para a cus-tomização de um processo durante o processo de derivação automático.

3.3.3 Modelagem de Variabilidades em Diferentes Granularidades

No caso de gerência de variabilidades em arquivos XMI, as seções anteriores ilustramque o uso de comentários/anotações sobre tais arquivos foram suficientes para permitir acriação automática dos modelos de derivação, assim garantindo que elementos de pro-cesso, tais como, atividades e tarefas pudessem ser tratados como variabilidades da linhade processo. Entretanto, alguns elementos de processo, assim como relacionamentos ex-istentes entre tais elementos e que também podem representar variabilidades, não sãorepresentados usando arquivos XMI individuais. Por exemplo, os passos definidos para


Figura 3.10: Modelo de configuração gerado pelo GenArch

uma tarefa são especificados dentro do próprio arquivo XMI que descreve a tarefa. Ou-tros exemplos de elementos de processo que não são definidos dentro de arquivos XMIexclusivos para isso foram: artefatos de entrada e saída, papéis participantes, conceitosrelacionados e guias. Analisando a arquitetura e os arquivos gerados pelo EPF Composer,observamos que vários arquivos eram gerados em conjuntos com os arquivos relacionadosdiretamento aos artefatos de processo.

A Figura 3.12 mostra uma visualização do processo gerado pela ferramenta EPF.Podemos observar na figura que temos arquivos com os nomes a mesma nomenclaturaatribuída às tarefas, por exemplo, Criar os Casos de Teste.xmi, Detalhar os Requisitos.xmi

e Encontrar e Descrever os Requisitos.xmi. Esses arquivos gerados pela ferramenta re-cebem o nome de method content element, que possui o conteúdo do elemento de pro-cesso, e na sua criação pela ferramenta é nomeado da seguinte maneira: <method content

element>.xmi, recebendo o mesmo nome que é dado ao elemento de processo. Observa-mos também que são criados arquivos que auxiliam na montagem do processo pela fer-ramenta agregando os elementos de processo, por exemplo temos os arquivos model.xmi

dentro de uma camada superior chamada de delivery process, que por sua vez representaum modelo de processo completo e integrado para a realização de um tipo específico deprojeto. Esse arquivo contém a referências para os descritores (tarefa, papel e produ-tos de trabalho), ou seja quando estamos definindo a variabilidade da linha de processotemos que levar em consideração que existe a necessidade de gerênciar variabilidadesem pequenas granularidades. Por exemplo, se preferimos que a tarefa Criar os Casos

de Teste não esteja presente em um processo derivado da linha de processo precisamos,além de retirar o elemento do processo Criar os Casos de Teste.xmi, retirar também asua referência dentro do arquivo model.xmi. Da mesma forma deve ocorrer dentro do ar-


Figura 3.11: Arquivo xmi representando elemento do processo com multipla anotaçõesde variabilidade

quivo plugin.xmi, este arquivo contém a referência para todos os elementos presentes noprocesso bem como os nomes de apresentação, uma breve descrição, e as relações paracada elemento, tais como orientação, entradas ou saídas (tarefas), a atribuição de papeis(tarefas), responsabilidade pelos produtos de trabalho (papel), etc

Para garantir a gerência de variabilidade de tais trechos de menor granularidade den-tro de arquivos XMI, foi utilizada outro recurso da ferramenta GenArch, denominadofragmentos. Um fragmento é caracterizado como um trecho de texto de qualquer tipode artefato (código, arquivo de configuração, texto, etc) que pode ser inserido (ou não)dependendo da escolha de uma dada variabilidade, durante o processo de derivação naengenharia de aplicação. Ferramentas como pure::varians 7 e Gears 8 também oferecemmecanismos parecidos com um propósito similar.

As Figuras 3.13 e 3.14 também ilustram as definições de fragmentos dentro dos mod-elos de arquitetura e configuração da linha de processo. Tais fragmentos representamtrechos com tags XML que representam variabilidades a serem inseridas dentro dos ar-quivos que representam os elementos de processo. Usando a ferramenta GenArch, épossível selecionar um trecho de um arquivo específico e extrair tal trecho automatica-mente para um fragmento, realizando assim uma refatoração nos artefatos da LPS paraexpor tal variação. Tal refatoração transforma o arquivo cujo fragmento foi extraído emum template na linguagem XPand [EFFTINGE S.; KADURA, 2006], além de criar as

7Disponível em: http://www.pure-systems.com Acesso em: 3 Nov. 20098GEARS. Software Product Lines - Pragmatic Innovation from BigLever Software. 2009. Disponível

em: http://www.biglever.com Acesso em: 3 Nov. 2009.


Figura 3.12: Visualização dos arquivos gerados pela ferramenta EPF na geração do Pro-cesso

respectivas entradas no modelo de arquitetura do processo e no modelo de configuraçãopara representar o fragmento.

A Figura 3.15 ilustra como fica parte de um arquivo XMI após a extração de algunstrechos e associação destes à fragmentos específicos. O trecho de arquivo ilustrado rep-resenta a junção das tarefas relacionadas ao nosso processo. Das três tarefas associadasao processo, uma foi identificada como opcional, conforme nossa análise do projeto paraidentificação de similaridades e variabilidades. A Figura 3.16 apresenta a extração departe do código XMI do arquivo plugin.xmi e sua associação a um fragmento gerenciadopela ferramenta GenArch. No template temos que o trecho referente a tarefa Criar os Ca-

sos de Teste foi extraído para um fragmento denominado Criar_os_Casos_de_Teste quefoi associado posteriormente a uma feature de mesmo nome no modelo de configuração.Esta associação possibilita que cada um desses fragmentos seja inserido no arquivo daespecificação final do processo derivado apenas se as features a eles relacionadas foremselecionadas.

A seção seguinte utiliza os resultados obtidos neste estudo de modelagem de vari-abilidades em diferentes granularidades para permitir que a derivação e customização dos


Figura 3.13: Modelo de Arquitetura do Processo gerado pelo GenArch com a adição deFragmentos

processos ocorram de forma a manter a integridade das referências entre os elementospresentes na linha de processo.

3.4 Derivação e Customização Automática de Processos

A etapa apresentada nesta seção consiste na derivação e customização de um pro-cesso, a partir dos modelos de derivação e artefatos que representam a implementaçãoda linha de processo. Assim, após a realização de todas as atividades anteriores, restaao engenheiro de processo selecionar, usando a ferramenta GenArch, o conjunto de car-acterísticas variáveis (variabilidades) que ele deseja para o seu processo, e também uti-lizando esta ferramenta podemos executar a derivação da linha em um novo processo desoftware A atividade de customização do processo consiste basicamente na seleção ex-plícita de quais características opcionais e alternativas se deseja ter no processo que seráderivado da linha de processo. A seleção de features é baseada nas características de umprojeto específico, bem como na experiência dos engenheiros de processo, responsáveispela customização do processo que será usado em tal projeto, uma vez que toda a base de


Figura 3.14: Modelo de Configuração gerado pelo GenArch com a adição de Fragmentos

conhecimento do que seria disponibilizado como característica opcional ou alternativa foibaseado no conhecimento de processos aplicados em diversos projetos desenvolvidos poruma empresa, chamados de processos legados, ou por empresa especializada em prestarconsultoria para definir, implantar ou implementar melhorias em processos de software

[BARRETO et al., 2010].

A Figura 5.6 ilustra o processo de seleção de variabilidades no modelo de caracterís-tica que é realizado dentro da ferramenta GenArch, para a seleção das variabilidades nomodelo de característica é preciso criar um configuration of feature, como pode ser visual-izado nesta figura. Importante lembrar que no modelo de configuração estão definidos osmapeamento das features para os elementos do processo, sejam eles arquivos individuaisou trechos (fragmentos) de arquivos específicos. São esses mapeamentos que são proces-sados pela ferramenta de derivação para decidir quais arquivos e fragmentos devem entrarna especificação de processo sendo gerada. Como exemplo de derivação de um novo pro-cesso partindo na nossa linha de processo de software, partiremos do princípio que parao desenvolvimento de um projeto específico não será necessário a realização da tarefaCriar os Casos de Teste , que está caracterizada como opcional na linha de processo,porém será necessário ter a presença de um Testador para a realização a realização datarefa de Detalhar os Requisitos que tem o Testador como papel opcional. Obedecendoesta customização temos o configuration of feature selecionado como demonstrado naFigura 5.6. Após a operação de derivação teremos um processo baseado na linha que nãocontém a tarefa de Criar os Casos de Teste , que será utilizado para apoiar o desenvolvi-mento de um projeto em específico. A Figura 3.18 demostra o resultado da derivação do


Figura 3.15: Arquivo XMI após ser transformado em um template segundo a linguagemXPand

processo.

Como resultado dessa geração automática, é criada uma estrutura de diretórios semel-hante a definida para a linha de processo, mas com as devidas adaptações realizadaslevando em consideração as features selecionadas. Tal seleção implica na inclusão ounão de determinados arquivos ou trechos de arquivos (fragmentos) na especificação EPFque representa o processo desejado. Após a derivação, a estrutura de diretórios gerada,por ser a mesma estrutura da linha de processo, pode ser importada pelo EPF Composere um site correspondente a esse processo customizado pode ser finalmente gerado, alémde proporcionar toda manipulação de informação oferecida pelo EPF Composer.

3.5 Transformação de Modelo de Processo para Modelode Workflow

Tendo derivado o processo de software, temos agora um processo específico e mode-lado para um dado projeto. De acordo com as diretrizes da abordagem proposta neste tra-balho precisamos realizar uma transformação do modelo de processo de software em ummodelo de workflow, sendo este uma especificação de um metamodelo JPDL. A Figura3.19 ilustra a estrutura do nosso processo, agora uma derivação da nossa linha de pro-cesso, na forma de um WBS (Work Breakdown Structure) através do Eclipse ProcessFramework (EPF).


Figura 3.16: Extração de código para fragmento

Para permitir a implantação e execução da especificação do processo EPF em um mo-tor de workflow, precisamos transformar tal especificação que segue o metamodelo UMA,em um modelo de workflow, que segue a especificação do metamodelo JPDL de formaa permitir sua execução no motor de execução de workflow jBPM. O conjunto de ele-mentos do processo definidos no EPF é atualmente disponibilizada na forma de um mod-elo do Eclipse Modeling Framework (EMF), composta por uma série de arquivos XMLscom extensão .XMI, que na verdade são instâncias do metamodelo UMA. O metamod-elo UMA define uma terminologia e esquema para representar elementos do processo.Cada processo UMA especificado e modularizado no EPF, usando pequenas unidades,são denominadas conteúdo de método (method content) 9.

A transformação de modelo para modelo - especificação de processo UMA para aespecificação de workflow jPDL - é implementada na nossa abordagem utilizando o QVT

Operational, que é uma linguagem que segue a especificação QVT (Query / Views / Trans-

9Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview. 2010. Disponível em:http://www.eclipse.org/epf/ Acesso em: 10 Jan. 2010.


Figura 3.17: Processo de seleção de variabilidades no modelo de característica dentro daferramenta GenArch

formations) [LAARMAN, 2009]. O QVT é uma linguagem padrão da OMG para expres-sar consultas, exibições e transformações em modelos MOF (Meta-Object Facility). Paraa implementação das funções de transformação em QVTO, foram mapeados os diferentestipos de elementos existentes na especificação de processo para um equivalente na especi-ficação do workflow. A Figura 3.20 apresenta uma tabela que ilustra o mapeamento entretais elementos.

A Figura 3.21 apresenta uma visão parcial da implementação QVTO para a trans-formação dos modelos de processo. A criação das regras de transformação envolveu asolução de alguns problemas relacionados ao mapeamento entre as abstrações dos dife-rentes metamodelos. Um destes problemas foi a forma de encadeamento das atividades(activities) no UMA que é diferente da forma de encadeamento de tarefas no jPDL. Nometamodelo UMA temos cada atividade apontando seu predecessor, já na linguagemjPDL cada task-node (elemento que representa a atividade de UMA, ver Figura 3.21)aponta para suas sucessoras. Este problema também dificultou a criação dos nós join efork, pois não existe tais informações nos elementos UMA.

No código apresentado na Figura 3.21, as duas linhas de códigos iniciais servem parainstanciar os metamodelos envolvidos na transformação. As demais linhas de código sãofunções de mapeamentos entre os elementos dos metamodelos. No mapeamento, denom-


Figura 3.18: Processo derivado sem a presença da tarefa Criar os Casos de Teste

inado Activity2TaskNode, podemos verificar, por exemplo, que a criação de um nó join nojPDL se dá através de um mapeamento direto de UMA para JPDL, pois tal elemento nãoestá presente no modelo UMA de forma explícita. Sendo assim, tal transformação é feitaatravés da verificação, em cada elemento Activity, para saber se a mesma possui mais deum predecessor, o que indica a existência de um nó join antes de tal atividade, caso sejaverdade, é criado o nó join e uma transição entre ele e a atividade atual (como pode serobservado no rótulo 1 da Figura 3.21).

A Figura 3.22 ilustra um resultado da transformação de modelo-para-modelo do ma-peamento do processo modelado no estudo de caso. Podemos perceber que cada umade suas tarefas (exemplos: Encontrar e Descrever os Requisitos, Detalhar os Requisitos)foram transformadas em elementos jPDL do tipo task-node. Finalmente, os passos decada tarefa, foram mapeados em task . Como resultado da nossa transformação obtemos


Figura 3.19: Imagem com Work breakdown structure do processo derivado

uma instância do metamodelo jPDL que passa por mais uma transformação, desta vezuma transformação de modelo para texto, conforme descrito na próxima seção, para quedaí então possa ser implantado no motor de workflow.

3.6 Transformação de Modelo de Workflow para Projetode Workflow

A transformação de modelo para texto da nossa abordagem utiliza como entrada omodelo jPDL, resultante da transformação de modelo para modelo, descrito na seção an-terior. A transformação de modelo para texto nos proporciona como resultado os arquivosnecessários para a implantação do workflow de processo, que será implantado e executadono motor de execução de workflow jBPM.

A Figura 3.24 apresenta os arquivos resultantes da transformação Modelo para texto(M2T). Para a exibição de forma gráfica este plugin necessita de basicamente dois ar-quivos, um desses arquivos é gerado como resultado da transformação M2T, são os ar-quivos: (i) o arquivo XML com o conteúdo do nosso fluxo de trabalho, chamado deprocessdefinition.xml, este arquivo é gerado como resultado da transformação modelo-para-texto e (ii) outro arquivo XML chamado de gpd.xml que permite a visualizaçãodo processo de forma gráfica. Este último contém os nós e as posições de cada nó querepresentam os elementos presentes no workflow de maneira que sejá possível a sua vi-


Figura 3.20: Mapeamento elementos UMA e JPDL

sualização. A Figura 3.23 ilustra a notação gráfica para o workflow, sendo visualizadoatravés do plugin editor de workflow do Eclipse Designer (GPD). Este arquivo tambémserá interpretado pelo motor jBPM para a visualização gráfica do fluxo de atividades doprocesso no jBPM-console usando um browser.

Para a transformação de modelo para texto utilizamos o Acceleo, que é uma lin-guagem de geração de texto padrão da OMG, baseada em uma abordagem DDM. Elapermite a geração automática de código a partir de um metamodelo que esteja de acordocom o EMF. Essa transformação se dá a partir da construção de templates do Acceleo.Dessa maneira analisando os arquivos de configuração do jBPM que são necessários paraa implantação e execução do workflow de processo, fomos capazes de construir templates

Acceleo e a partir desses templates recuperar informações do modelo JPDL para quefosse possível a geração dos arquivos necessários a implantação, execução e gerencia-mento do workflow no engine jBPM.

O jBPM permite a criação de formulários web implementados no framework Java

Server Faces (JSF), a partir de uma definição de um modelo de workflow jPDL. Taisformulários podem ser usados para acompanhar o fluxo de execução do processo. Estafuncionalidade de acompanhamento é responsável por armazenar informações sobre astarefas e/ou decisões tomadas durante sua execução. Os formulários JSF gerados sãocustomizados usando uma conjunto de tags específicas do jBPM o que habilita a suaimplantação e reconhecimento automático por parte do seu motor de execução. Paraenriquecer a geração de tais formulários, os templates que os representam na tecnolo-gia Accelleo, foram modificados para incluir um conjunto de componentes gráficos que


Figura 3.21: Fragmento de Código da transformação em QVTO

oferecem diversas informações de interesse que são coletadas do processo. Exemplos decomponentes gerados para cada formulário são: (i) botões de upload para tarefas/passosassociados a produção de artefatos; (ii) campos de data para indicar o período de real-ização da tarefa/passo; (iii) campos extras de texto para descrição e comentários extrasda tarefa/passo; e (iv) caixas de seleção indicando o status (não iniciado, em andamento,finalizado, etc) das tarefas/passos do processo. A Figura 3.26 apresenta um template doAcceleo para a composição das páginas JSF que irão complementar com informações aexecução das tarefas do nosso workflow. Utilizamos taglibs próprias do jBPM para que omotor possa executar o formulário e associá-lo ao processo. Vale observar a configuraçãono template de informações relativas as tarefas (tasks) e transições (transitions) entre asmesmas. Estes trechos de código são automaticamente gerados a partir do processamentodo modelo de workflow. As transformações modelo-para-texto Acceleo são também re-sponsáveis pela geração de um arquivo de configuração (forms.xml) que relaciona cadatarefa do nosso fluxo a um formulário JSF. A Figura 3.25 apresenta o conteúdo deste ar-quivo. A seção seguinte apresenta o processo de implantação e execução do workflow,utilizando os artefatos gerados a partir da transformação modelo-para-texto.


Figura 3.22: Modelo JPDL, resultado da transformação modelo-para-modelo

Figura 3.23: Visualização do workflow através do Plug In GPD no eclipse

3.7 Implantando e Executando Processos de Software emum Workflow Engine

Com a derivação do processo para uma especificação de workflow podemos implantar,executar e monitorar instâncias dos processos em um motor de workflow. A implantaçãodo processo de software no engine de workflow é uma tarefa simples. Usando o plugin

do Graphical Process Design na ferramenta Eclipse podemos visualizar o processo naforma de um Workflow, e temos uma aba de visualização do plugin chamada deployment

nesta aba de visualização temos a opção de realizar a implantação do processo, na mesmatela temos a visualização dos arquivos que serão implantados no engine, com a opção demarcar ou desmarcar os arquivos que serão implantados, índice 1 da Figura 3.27. Temos aopção também de antes de realizar o deploy do workflow de testar a conexão com o servi-dor jBPM como demonstrado no índice 2 da Figura 3.27 e finalmente podemos executar


Figura 3.24: Resultados da Transformação Modelo para Texto

Figura 3.25: Arquivo resultado da transformação modelo-para-texto, que relaciona for-mulários JSF a tarefas

o deploy no nosso processo, índice 3 da Figura 3.27.

A Figura 3.28 apresenta uma visualização do processo sendo executado no navegadoratravés do motor jBPM. Após a implantação do processo de workflow no jBPM, o usuáriopode solicitar a execução de uma nova instância do processo. Ao iniciar a execução deuma nova instância do processo, o usuário pode visualizar o seu estado atual, que apre-senta os detalhes das atividades realizadas e aquelas a serem realizadas. Após a execuçãode cada atividade, o usuário informa na interface de execução do workflow, alguma in-formação relativa (tais como, data/hora de início, data/hora de conclusão, estado atual,artefatos implementados) ao monitoramento da atividade em questão. Todas as infor-mações são armazenadas em um banco de dados, e relacionadas à instância do processo.Todos estes passos são repetidos para cada atividade, até o final do processo, quando oestado final do fluxo de trabalho foi atingido e podendo a partir das informações que serãoalimentadas na execução do fluxo do processo de workflow realizar o gerenciamento dessefluxo.


Figura 3.26: Template Acceleo para Derivação de Código Java(JSF)


Figura 3.27: Plugin jBPM para a execução do Processo


Figura 3.28: Processo em execução visualizado através do jBPM-Console

51

4 Suporte Ferramental da

Abordagem

Este capítulo apresenta o suporte ferramental oferecido pela nossa abordagem. Otrabalho definiu basicamente dois tipos de ferramentas: (i) uma ferramenta para gerênciade variabilidades em linhas de processo que foi desenvolvida como uma adaptação daferramenta de derivação de produtos GenArch; e (ii) uma ferramenta de transformação demodelos de processos; especificados de acordo com o metamodelo UMA, para modelose arquivos de configuração do motor de workflow jBPM.

4.1 Ferramenta para Gerência de Variabilidade em Pro-cessos de Software

De forma a oferecer suporte automatizado para a gerência de variabilidades na nossaabordagem, através do uso de técnicas de linhas de produto e programação generativa, foinecessário realizar a adaptação da ferramenta GenArch [CIRILO, 2008] para trabalharcom arquivos e a arquitetura gerada pelo EPF Composer. Para isto foi necessário enten-der e investigar técnicas e conceitos que envolvem a arquitetura do GenArch. Como vistoanteriormente, no capítulo 4 a ferramenta GenArch propõe a definição de três modelos osquais são usados para representar as variabilidades (modelo de características) e elemen-tos de implementação (modelo de arquitetura) de uma LPS, bem como o mapeamentoentre tais elementos (modelo de configuração).

A principal mudança que temos na proposta de utilizar o GenArch para a geraçãoinicial dos modelos partindo de um projeto definido no EPF Composer é a linguagem aser verificada para a montagem dos modelos. Na proposta original do GenArch, a fer-ramenta analisa anotações Java no código utilizando os plug ins Java development tools

(JDT) [SHAVOR et al., 2003] e AspectJ Development Tools (AJDT) [COLYER et al.,2004]. A API de árvore de sintaxe abstrata disponível nesses plug-ins foi utilizada na

4. Suporte Ferramental da Abordagem 52

manipulação (leitura, escrita e remoção) das anotações Java caracterizando as variabili-dades presentes na linha. Essas informações foram necessárias para a definição do modelode característica utilizando o Feature Modeling Plugin (FMP) [ANTKIEWICZ; CZAR-NECKI, 2004]. Na nossa abordagem, não podemos analisar anotações Java, porque oEPF nos fornece arquivos XML com a extensão XMI, que representam a especificaçãodo processo. Para a anotação de características no código XML utilizamos comentáriosXML, nesse contexto o GenArch foi adaptado para que a ferramenta pudesse interpretaresses comentários para a composição do modelo de características. Utilizamos a bib-lioteca jDOM 1 para verificação da presença dos comentários nos artefatos de processo.(arquivos XMI). Cada comentário XML é equivalente a uma anotação Java que indica onome e o tipo de feature ao qual aquele artefato está associado.

Além de utilizar a biblioteca jDOM para processar os comentários internos aos ar-quivos XMI, tivemos que modificar o método que faz a verificação de arquivos em buscade anotações Java para a composição do feature model. O GenArch implementa o padrãoVisitor para a varredura de código no projeto. Foi realizada a inclusão de busca emarquivos com a extensão XMI no algoritmo de busca para a composição dos modelosde derivação. A Figura 4.1 apresenta a estrutura geral da ferramenta GenArch modi-ficada para a sua aplicação em processos de software. Temos neste momento a ferra-menta fazendo também a verificação de comentários, representando anotação de vari-abilidades em artefatos de processos de software, em arquivos de código XML. Parte daimplementação necessária para o (parsing) desses comentários XML a procura de ano-tações de variabilidades pode ser visualizada na Figura 4.2, a sintaxe para a definiçãode uma variabilidade em arquivos XMLs foi mantida similar a anotação de código Java,porém essa anotação ocorre na forma de um comentário XML. Podemos observar queforam realizadas mudanças localizadas na ferramenta GenArch, envolvendo sobretudo asua adaptação para manipulação de arquivos XMI, tanto com o objetivo de processar asanotações-comentários quanto no momento de incluir os arquivos XMI que representamos elementos do processo derivado.

4.2 Ferramenta para Transformação e Implantação deProcessos em Sistemas de Workflow

Nossa abordagem também contempla a transformação de modelos de processo, bemcomo sua posterior implantação em sistemas de workflow. Esta funcionalidade é com-

1http://www.jdom.org/


Figura 4.1: Arquitetura da ferramenta GenArch adaptada para o trabalho com processosde software

posta por: (i) uma transformação modelo-para-modelo reponsável pela transformação domodelo de processo de software definido pelo metamodelo UMA em modelo de workflow

definido pelo metamodelo jPDL; e (ii) uma transformação modelo-para-texto responsávelpela transformação das informações contidas no modelo de workflow para um projeto deworkflow executável, capaz de ser implantado e executado no engine de workflow jBPM.

Para a definição do processo, utilizamos a ferramenta EPF Composer. A ferramentacria instâncias do metamodelo de processo UMA. Da mesma forma que para definição deprocesso utilizamos o apoio de um metamodelo, podemos utilizar o apoio de metamodelosna definição de modelos de workflows. No nosso caso o metamodelo jPDL, que podeser executado em motores de workflow. A transformação entre modelos no contexto daabordagem é realizada pensando no reuso de conhecimento dos processos de software queforam definidos pela ferramenta EPF Composer, e na utilização de tecnologia existentepara a definição de workflow jPDL e sua execução em motor de workflow.

Para a execução destas etapas de transformações entre modelos da nossa abordagem,foi necessário a instanciação dos metamodelos, presentes nas transformações, sendo estesdefinidos através do metametamodelo Ecore do EMF, e disponibilizados na forma deplug-ins para a sua manipulação pela ferramenta Eclipse. A transformação modelo-para-texto é realizada com o apoio da ferramenta Acceleo, que oferece uma implementaçãopadrão para a transformação modelo-para-texto e para a transformação modelo-para-modelo foi utilizado a linguagem QVTO, que também oferece uma implementação padrãode transformação entre modelos definida pela OMG.


Figura 4.2: Código para o parsing dos arquivos XMLs a procura de anotações de vari-abilidades

A Figura 4.4 demonstra a arquitetura final da ferramenta. Para o primeiro passo destatarefa de disponibilização de plug-ins foi necessário a definição dos metamodelos emformato Ecore. Os seguintes metamodelos são necessários a ferramenta para as transfor-mações: (i) UMA - Unified Method Architecture; 2; (ii) jPDL - Java Process Definition

Language 3; e (iii) XMI - XML Metadata Interchange 4. Para a instanciação do metamod-elo UMA utilizamos o Ecore disponibilizado pelo EPF team, que também é instanciadopela ferramenta EPF Composer. Os metamodelos jPDL e XMI tiveram que ser geradosa partir da definição dos seus XML Schemas utilizando a ferramenta Eclipse 5. Uma vezgerado os metamodelos podemos agora gerar as instâncias dos plug ins que serão insta-lados no Eclipse. A Figura 4.5 apresenta os metamodelos instanciados pela ferramentavisualizada através do metamodel explorer.

Para a transformação entre modelos de processo e workflow utilizamos a tecnologiaQVTO. A Figura 4.3 demonstra um fragmento de código, resultado da implementaçãoQVTO para a transformação entre modelos. Nos índices 1 e 2 da Figura 4.3 temos adefinição dos metamodelos envolvidos na transformação. Nos itens 3 e 4 temos, respec-tivamente, a definição dos modelos de entrada e saída necessários a transformação. Aimplementação QVTO para a transformação entre modelos é definida através de mapea-

2http://www.eclipse.org/epf/composer_architecture/3http://docs.jboss.org/jbpm/v3/userguide/jpdl.html4http://www.omg.org/spec/XMI/index.htm5http://www.eclipse.org/modeling/emf/docs/1.x/tutorials/xlibmod/xlibmod_emf1.1.html


Figura 4.3: Fragmento de Código QVT0, destacando como parâmetros para execução doscript a declaração dos metamodelos envolvidos e as instâncias dos modelos de entrada esaída

mentos entre os elementos presentes nesses modelos, antes de executar a transformaçãofoi necessário definir os mapeamentos entre o metamodelo de processo e o metamodelode workflow. O mapeamento entre estes elementos pode ser visto com mais detalhes nocapítulo 3 destinada a descrição da abordagem.

Para a execução desse workflow precisamos implantá-lo no motor de execução. Nanossa abordagem foi utilizado o jBPM um engine de workflow que é um motor de exe-cução para a linguagem jPDL. Para a implantação do workflow precisamos de mais umatransformação modelo-para-texto, a qual foi implementada usando a tecnologia Acceleo.Para executar estas transformações, o Acceleo utiliza templates para a geração de arquivosde configuração e código-fonte responsáveis pela sua implantação no engine de workflow.Para essa implementação também é necessário a definição do modelo de entrada, no nossocaso o modelo jPDL resultante da transformação modelo-para-texto e como artefatos desaída temos os arquivos que serão implantados no engine de workflow.

Neste capítulo apresentamos o apoio ferramental utilizado pela nossa abordagem comênfase nas adaptações e implementações oferecidas pelas ferramentas. Ambas as ferra-mentas de gerência de variabilidades em modelos de processos e transformação de mod-elos de processo em modelos de workflow, foram implementadas usando como base aplataforma Eclipse e a infra-estrutura de desenvolvimento dirigido por modelos disponívelem tal plataforma.


Figura 4.4: Arquitetura da ferramenta de transformação modelo-para-modelo e modelo-para-texto

Figura 4.5: Visualização dos metamodelos instanciados pelo Eclipse, através do meta-model explorer

57

5 Estudo de Caso

Este capítulo apresenta a aplicação da abordagem proposta neste trabalho em pro-cessos de desenvolvimento de software utilizados no Instituto Federal de Ciência e Tec-nologia do Rio Grande do Norte(IFRN). Esses processos foram utilizados em diversosprojetos no núcleo de desenvolvimento de software (NUDES).

5.1 Visão Geral dos Projetos Analisados

No núcleo de desenvolvimento de software do Instituto Federal do Rio Grande doNorte, vários projetos são desenvolvidos. Dentre estes projetos, foram analisados os pro-cessos aplicados ao desenvolvimento dos projetos SIEP-Gerencial e o SIGA-EPT quesão desenvolvidos para subsidiar os processos de planejamento estratégico e operacional,como também rotinas administrativas, acadêmicas e de gestão da Secretaria de EducaçãoProfissional e Tecnológica do Ministério da Educação - SETEC/MEC. A seguir apresen-tamos um breve resumo sobre cada projeto.

• SIEP-Gerencial: tem como objetivo desenvolver, implantar, dar suporte e manutençãoao módulo gerencial do Sistema de Informações da Educação Profissional - SIEPGerencial com código aberto, utilizando tecnologia livre, para prover a SETEC/MECde instrumentos e ferramentas que possibilitem o exercício de sua função definidorade políticas, supervisora, estimulando um processo contínuo de avaliação, mon-itoramento, modernização e transparência da oferta e da expansão da EducaçãoProfissional e Tecnológica no Brasil. 1

• SIGA-EPT: tem como objetivo desenvolver, implantar e dar suporte ao SistemaIntegrado de Gestão Acadêmica - SIGA-EPT - como módulo do Sistema de Infor-mações da Educação Profissional - SIEP - com código aberto, utilizando tecnolo-gias de software livre, para prover as unidades acadêmicas supervisionadas pela

1http://siep.cefetrn.br/doku.php/siep/home

5. Estudo de Caso 58

SETEC/MEC de instrumentos e ferramentas que possibilitem sua gestão efetiva,tanto acadêmica quanto administrativa e garantir a integração das bases de dadoslocais com a SETEC/MEC. Atualmente o projeto SIGA-EPT é formado por 10núcleos de pesquisa e desenvolvimento, envolvendo CEFETs, Escolas Agrotécni-cas e Universidades Federais. 2

O projeto Eclipse Process Framework (EPF) disponibiliza bibliotecas de processoscomo exemplos de base para sua customização, dentre os processos disponibilizadospelo EPF, Dentre as bibliotecas de processo disponibilizadas pelo EPF, foi selecionadoa biblioteca de processo do OpenUP como sendo a família de processos a ser estudada,dado que o mesmo pode ser customizado de diversas formas para atender as necessidadesespecíficas de projetos reais de desenvolvimento. Além disso, os processos usados noSIEP-Gerencial e no SIGA-EPT foram também baseados no OpenUP. Com a disponi-bilização da biblioteca de elementos de processo do OpenUP disponível na ferramentaEPF Composer, foi possível estender e utilizar esses elementos de processo como es-tudo de caso para a abordagem demonstrada neste trabalho. Por serem processos basea-dos no OpenUP esses processos herdaram informações importantes para a sua aplicaçãoem cenários de desenvolvimento onde foram aplicados. Como, por exemplo, definiçõesde artefatos produzidos em diferentes fases e disciplinas presentes no ciclo de vida doprocesso, definições claras dos campos de atuação dos papéis envolvidos no processo eartefatos produzidos por esses papéis ao longo do ciclo de vida do processo. Esses sãoapenas alguns exemplos de informações importantes que puderam ser herdadas da bib-lioteca do OpenUP. Uma vez definida a linha de processo, podemos prosseguir com aabordagem, identificando e modelando similaridades e variabilidades presentes na ativi-dade descrita na próxima seção.

5.2 Modelagem e Definição da Linha de Processo

Para viabilizar o presente estudo, como mencionado, foram selecionados projetosde pesquisa e desenvolvimento de software, ligados ao Núcleo de Desenvolvimento deSoftware da Diretoria de Educação e Tecnologia da Informação do Instituto Federal deEducação, Ciência e Tecnologia do Rio Grande do Norte - NUDES / DIETINF / CNAT/ IFRN. Tais projetos definem processos que refletem customizações do OpenUP. Alémdisso, foi também considerada a experiência profissional de pesquisadores envolvidos na

2http://siep.cefetrn.br/doku.php/siga/home


condução do estudo de caso, no que se refere a processos e metodologias de desenvolvi-mento de software baseadas no RUP.

A seleção de projetos de pesquisa e desenvolvimento de software reais, que fazemuso de customizações do OpenUP, permitiu a análise de similaridades e variabilidades detal linha de processo. A estrutura de divisão de trabalho do OpenUP (work breakdown

structure) serviu de base para modelagem de tais similaridades e variabilidades. Comoresultado dessa análise foi produzida uma matriz que explicita quais atividades, tarefas,artefatos de entrada e saída, e passos relacionadas às tarefas do OpenUP representam sim-ilaridades e variabilidades da linha de processo que o define. Ao final desta atividade nototal, foram identificadas 586 features: 273 features mandatórias, 239 features opcionaise 74 features alternativas [FREIRE et al., 2010].

O processo OpenUP explicita que algumas atividades ou passos do processo são op-cionais durante a sua execução, entretanto, ele não define quais elementos dos processos(atividades, passos, artefatos, guias, etc.) são variabilidades do ponto de vista da linhade processo, podendo estar ou não presente durante a sua instanciação para um projetoespecífico. Assim para modelar o OpenUP como uma linha de processo, o primeiro passoé definir claramente quais são as suas features similares e variáveis, tomando como basepara essas decisões os processos aplicados no NUDES do IFRN, cruzando informaçõesda base de elementos de processo disponível no OpenUP com a execução dos processosdo NUDES.

A Figura 5.1 apresenta uma visão parcial da matriz de similaridades e variabilidadesobtida como resultado desse processo de análise de domínio da linha de processo. Astarefas que foram executadas em todos os projetos investigados foram classificadas comomandatórias, e aquelas que foram executadas em pelo menos um dos projetos estudados,foram classificadas como opcionais. Pode-se observar, por exemplo, que diversas tarefasrelacionadas a detalhamento dos cenários de casos de uso (Detail Use-Case Scenarios),criação dos casos de teste (Create Test Cases) e esboço da arquitetura (Outline the Ar-

chitecture) foram classificadas como opcionais durante a fase de Concepção. Isso ocorreporque nem sempre tais tarefas fazem parte das atividades a serem realizadas durantetal fase. Vale ressaltar que a definição do OpenUP dentro do EPF não torna explícita apresença de tais similaridades e variabilidades, dificultando assim sua customização paranovos projetos. No estudo, foram também identificados elementos do processo que rep-resentam possíveis características alternativas, como, por exemplo, vários tipos diferentesde templates para um dado artefato.

No que se refere às atividades do OpenUP, a seguinte estratégia foi usada para re-alizar a sua modelagem: (i) as atividades que tiveram pelo menos uma das suas tarefas


Figura 5.1: Trecho do resultado do estudo de variabiliades e similaridades do OpenUP

classificada como mandatória, foram classificadas como mandatórias também; e (ii) nocaso onde todas as tarefas da atividade foram classificadas como opcionais, a atividadefoi também classificada como opcional. A Matriz de Variabilidade exemplifica tal caso,por exemplo, mostrando que a atividade: Identify and Refine Requirements é mandatóriaporque possui pelo menos uma tarefa obrigatória Identify and Outline Requirements. Jáa atividade Agree on Technical Approach foi classificada como opcional já que todas astarefas agregadas são opcionais. [FREIRE et al., 2010]

Durante o estudo, foram também identificados elementos do processo que represen-tam possíveis features alternativas, como, por exemplo, vários tipos diferentes de mode-los para um dado artefato. O nosso estudo [FREIRE et al., 2010] mostra, por exemplo,que templates para a produção de determinados artefatos podem representar elementosde processo alternativos para uma das linhas. Outro exemplo de features alternativas en-contrados foram os próprios guias de técnicas ou tecnologias, os quais são muitas vezesoferecidos pelos processos para apoiar a realização de alguma atividade. A Figura 5.2apresenta uma visão resumida do Work Breakdown Structure do OpenUP utilizado comoprocesso base da nossa linha de processos. Podemos observar na figura a divisão em fases


e a distribuição das atividades entre essas fases do processo.

Figura 5.2: Work Break down Structure resumido da linha de processo

5.3 Gerência Automatizada de Variabilidades

Esta seção apresenta os resultados da atividade de gerência automatizada de vari-abilidades aplicada ao nosso estudo de caso, uma vez que os detalhes do gerenciamentodessas informações são apresentados no capítulo 3, destinado a apresentação detalhadada aplicação da abordagem. O objetivo principal desta atividade é produzir modelos dederivação da ferramenta GenArch para gerenciar as variabilidades da linha de processo.


A Figura 5.3 apresenta o modelo de características como resultado da criação dosmodelos de derivação pela ferramenta GenArch, esse modelo representa as similaridadese variabilidades presentes na linha de processo. A Figura 5.4 apresenta o modelo dearquitetura do processo que representa os artefatos presentes na linha. A Figura 5.5 ap-resenta o modelo de configuração, gerado para nossa abordagem, que especifica o ma-peamento entre variabilidades presentes no modelo de característica e artefatos de imple-mentação presentes no modelo de arquitetura do processo. Estes modelos foram geradosautomaticamente pela ferramenta GenArch, a partir da anotação direta de features comunse variáveis dentro dos arquivos XMIs que especificam o OpenUP no EPF.

Figura 5.3: Modelo de Característica gerado pela ferramenta Genarch

5.4 Derivação e Customização Automática de Processos

Uma vez criado os modelos de derivação que representam e modelam a linha deprocessos, é possível derivar processos específicos usando a ferramenta GenArch. Parailustrar a atividade de derivação e customização automática dos processos analisados pelanossa abordagem, vamos derivar um processo que será aplicado no desenvolvimento deum sub-sistema do projeto SIEP-Gerencial.

A Figura 5.6 ilustra o resultado do processo de seleção de variabilidades no modelo


Figura 5.4: Modelo de Arquitetura do Processo gerado pela ferramenta Genarch

de característica. A ferramenta utiliza informações contidas no modelo de caracterís-tica, aliada aos modelos de arquitetura e configuração para a geração de novos processos.Como resultado da derivação, temos um projeto na mesma estrutura da linha com asmodificações que refletem as escolhas realizadas no modelo de características. Uma vezdefinida a estrutura da linha de processo na ferramenta EPF Composer, sua estrutura éexportada na forma de um projeto EPF e importada pelo Genarch. A tarefa de importaçãodo processo pode ser realizada da seguinte maneira: (i) A criação de um projeto GenArchvazio e a importação do conteúdo de processo para esse projeto; (ii) importação comoqualquer outro tipo de projeto e posteriormente a conversão para um projeto GenArch,opção esta presente na ferramenta, para que os modelos de derivação possam ser vali-dados e posteriormente ser realizada a derivação de um processo de software. Uma vezrealizada a derivação do processo, temos um projeto EPF que poderá ser importado pelaferramenta EPF Composer e, consequentemente, poderá ser manipulado e editado pelaferramenta.

A Figura 5.7 mostra o resultado da derivação e customização do processo abordadoneste estudo de caso. Como podemos verificar o processo foi customizado para que nãoestivesse presente: (i) a atividade Agree on Technical Approach e consequentemente atarefa Outline Requirements; e (ii) na atividade Identify And Refine de Requirements


Figura 5.5: Modelo de Configuração gerado pela ferramenta Genarch

não estivesse presente a tarefa Create Test Cases.

Tendo ocorrido a derivação do processo, temos a opção de importar esse processonovamente no EPF, e a partir daí podemos utilizar todas as funcionalidades oferecida peloEPF Composer. Uma das funcionalidades presentes na ferramenta é a de publicação doprocesso na forma de páginas web. A Figura 5.8 mostra a visualização da publicaçãoweb do processo derivado. A publicação proporciona uma navegabilidade entre as in-formações do processo, com a formação do menu de navegação dividido em diversascategorias como fases, disciplinas e atividades.


Figura 5.6: Fragmento do modelo de características gerado pela ferramenta Genarch,resultante da seleção de variabilidades nos processos analisados

5.5 Transformação de Modelo de Processo para Work-flow

Até este passo a utilização do nosso estudo de caso foi abordada de forma completa,envolvendo toda a linha de processo OpenUP. As atividades seguintes da abordagem pro-posta neste trabalho, foram realizadas apenas sobre a disciplina de gerencia de projeto dafase de concepção do OpenUP, devido a restrições de tempo para conclusão desta disser-tação. De forma a definir o escopo do estudo de caso, inicialmente foram extraídas da es-pecificação da linha de processo implementada a partir da definição do processo OpenUP,os diferentes elementos da disciplina de gerência de projeto considerando a fase de con-cepção. Na definição da linha de processo na ferramenta EPF Composer, conseguimosvisualizar também os passos necessários à realização de cada tarefa.

Uma vez que o EPF instancia o metamodelo UMA para a especificação dos modelosde processo, os artefatos de processo gerados pela ferramenta são especificações dessemetamodelo. A Figura 5.9 apresenta uma visão parcial do modelo UMA gerado parao processo derivado pela ferramenta na etapa anterior da abordagem. Na especificação


Figura 5.7: Visualização WBS do processo resultado da customização e derivação

do modelo de processo podemos observar a navegabilidade entre os elementos definidospara o processo de entrega (Delivery Process), e a distribuição das tarefas (tasks) entre asatividades (Activity) da fase de concepção (Phase). O modelo de processo UMA definia sequência das tarefas pela propriedade Work Order, que representa a tarefa predeces-sora da tarefa que a possui. Já no metamodelo JPDL a definição da sequência lógicadas atividades é definida pela transição entre as tarefas, cada tarefa aponta para a tarefasucessora. Na a transformação modelo-para-modelo foi implementado o mapeamento en-tre a representação da sequencia de tarefas do modelo UMA para o modelo JPDL, comoapresentado no capítulo 3 destinada a apresentação da nossa abordagem.

Submetemos então este modelo que contém os elementos de processo à uma trans-formação para modelo de workflow. A Figura 5.10 exibe o resultado da transformaçãomodelo-para-modelo, um modelo que segue a expecificação do metamodelo JPDL. Paraa transformação modelo-para-modelo utilizando o QVTO é necessário especificar o meta-modelo que define o modelo de saída, este metamodelo deve ser definido no EMF. A tarefa


Figura 5.8: Visualização do processo em forma de página web

de definir um metamodelo JPDL para auxiliar na transformação, no início dos nossos estu-dos, foi definida de forma manual, observando as propriedades que estavam definidas nosarquivos de configuração do workflow que eram implantados no jBPM. Posteriormente,foi necessário incrementar o metamodelo Ecore inicialmente definido no EMF com ab-strações adicionais do metamodelo JPDL. Para esta tarefa foi utilizado o XML-Schemaque define a especificação dos arquivos de configuração do workflow JPDL. O próprioEMF permite a criação de metamodelos Ecore, a partir de um XML schema.

Podemos observar o resultado da transformação modelo-para-modelo através da Figura5.10. No modelo JPDL gerado a partir da transformação podemos observar que infor-mações contidas no modelo de processo UMA foram extraídas e serviram de base para ageração do modelo JPDL. Como demonstrado na Figura 5.10, temos as informações dosnós do workflow definida através da tag taskNode e temos atribuido ao nó a informaçãoda tarefa, definida através da tag task, e a informação da transição da tarefa do work-

flow através da tag transition. Isso é ilustrado na Figura 5.10 através do nó de workflow

Desenvolver Visao Tecnica que possui as informações da tarefa e do próximo nó a serexecutado. No nó Avaliar os Resultados temos a transição para o fim do fluxo, definidoatravés da tag endState. Seguindo as atividades previstas na abordagem, utilizamos napróxima seção, os artefatos produzidos na transformação modelo-modelo para produziros artefatos necessários a implantação, execução e gerenciamento do workflow no jBPM,através da transformação modelo-para-texto.


Figura 5.9: Modelo de processo seguindo a especificação do metamodelo UMA

5.6 Transformação de Modelo de Workflow para Texto

Esta seção apresenta os resultados da atividade de transformação modelo-para-textoaplicada ao nosso estudo de caso. Utilizando como artefato de entrada o resultado datransformação modelo-para-modelo da seção anterior podemos realizar neste momentoa transformação modelo-para-texto. Para a transformação de modelo-para-texto temoscomo resultado os artefatos necessários para a execução do workflow no engine jBPM.Nesta transformação também obtemos os elementos essenciais para o gerenciamentodas operações realizadas no workflow. Para a execução da transformação modelo-para-texto utilizamos a ferramenta Acceleo em conjunto com os metamodelos envolvidos nestaetapa, como demonstrado nos capítulos 3 e 4 destinados, respectivamente, a apresentaçãoda abordagem e do apoio ferramental. Para a execução da transformação modelo-para-texto, o Acceleo utiliza templates, onde esses utilizam como artefato de entrada o modelo


Figura 5.10: Modelo seguindo a especificação do metamodelo JPDL

de workflow, permitindo a navegação entre os atributos e operações previstas neste mod-elo, oferecendo desta forma o acesso a informações que servirão de base para a montagemdos templates e, consequentemente, a geração dos arquivos por eles modelados.

A Figura 5.12 apresenta todos os arquivos gerados nesta etapa da abordagem. Entre osartefatos de saída temos a geração do arquivo forms.xml (Figura 5.11) contendo a ligaçãode cada atividade com o formulário JSF. É através deste arquivo que, quando executadadeterminada tarefa acontece a chamada ao formulário para alimentar com informação arealização da tarefa. Temos a geração também do artefato principal contendo todas asinformações do workflow, o arquivo processdefinition.xml, apresenta toda a sequenciade atividades e informações contidas anteriormente no modelo de processo.

Como também podemos visualizar na Figura 5.12, para cada tarefa do fluxo foi cri-


Figura 5.11: Visualização do arquivo forms.xml responsável pela ligação das tarefas comseus formulários

ado também uma página JSF para gerenciar os detalhes da execução da tarefa. Como ojBPM permite a execução de arquivos JSF para a manipulação de informações do pro-cesso, podemos associar as tarefas do fluxo de trabalho à páginas JSF, que coletam ouapresentam informações relevantes relacionadas ao fluxo de gerência de projeto, para quepossamos alimentar com informações relevantes a execução do fluxo do processo.

5.7 Implantando e Executando Processos de Software emum Workflow Engine

Na etapa de transformação modelo-para-texto conseguimos os artefatos necessáriospara a implantação do modelo e artefatos que representam um workflow no engine jBPM.Uma vez tendo o nosso engine de workflow configurado e funcionando, podemos fazero deploy do nosso fluxo no engine jBPM através do GPD, plugin do eclipse. A Figura5.13, demostra a utilização do plugin GPD para a implantação do workflow jBPM. Aimplantação do nosso fluxo de processo de software pode ser realizada também por umbrowser utilizando o jBPM Console. A Figura 5.14 demonstra a página de upload deprocessos disponível no jBPM Console.


Figura 5.12: Arquivos gerados na Transformação de modelo-para-texto

Uma vez realizada a operação de deploy, podemos verificar o conteúdo do processoefetuando o login no jbpm-console, e abrindo a lista de processos no menu. A Figura5.15 exibe a lista de processos implantados no engine. Podemos a partir deste pontoexecutar instâncias desses processos. Uma vez executada a instância do processo elepoderá ser alimentado com informações referentes a execução de cada projeto. Na Figura5.16 podemos verificar a execução do workflow no jBPM Console. À medida que vamosalimentando nosso workflow de processos, temos o auxílio de formulários que tambémforam gerados durante a transformação de modelo-para-texto. Páginas JSF foram geradasde acordo com informações vindas do modelo de processo definida na ferramenta EPF.Podemos observar a execução de um formulário na Figura 5.16 e a visualização gráficadesse processo no jbpm-console na Figura 5.15. A visualização do processo na sua formagráfica permite a verificação de qual atividade está sendo executado. A tarefa do workflow

do processo que está em execução é exibida de forma destacada.


Figura 5.13: Efetuando o deploy do workflow

Figura 5.14: página de upload, disponível no jBPM Console, para a implantação de pro-cessos

5.8 Lições Aprendidas e Novas Perspectivas

Esta seção apresenta e discute aspectos técnicos e lições aprendidas ao longo do de-senvolvimento das abordagens apresentadas neste trabalho. Tais aspectos estão sendofundamentais no desenvolvimento de novos refinamentos e oferecem novas perspectivaspara a melhoria da nossa abordagem. Sendo, portanto, relevantes para o desenvolvimentode novos estudos de gerência automática de variabilidades em processos de software eimplantação de processos de software em sistemas de workflow.

5.8.1 Mapeamento de especificações de processo em Workflow

Nossa abordagem define um mapeamento explícito entre modelos de processo e deworkflow, através da implementação de transformações modelo-para-modelo e modelo-para-texto. Diferentes elementos e abstrações de modelos de processo, especificações


Figura 5.15: Visualização do Processo no jBPM Console

do metamodelo UMA, definidos na ferramenta EPF foram diretamente mapeadas pararepresentações em especificações de workflow, tanto no nível de descrição quanto de im-plementação de formulários web, que puderam ser então instalados para execução doprocesso no motor de workflow jBPM. Diferentes informações relevantes para a execuçãoe monitoramento do processo podem ser geradas nos formulários, que são páginas JSF ex-ecutadas no JBPM Console, auxiliando e historiando sua execução e consequentementealimentando com informações para o seu melhor monitoramento. Apesar de já oferecersuporte para o mapeamento e implementação de diversas dessas informações (data/horainício e final de execução, estado atual, botões de upload ou links para artefatos gerados),nossa abordagem precisa ainda ser refinada para permitir durante o processo de trans-formação, a interação com o engenheiro de processo de forma a escolher parâmetros eopções específicas de configuração para execução do seu processo.

5.8.2 Integração do código do Workflow com ferramentas de engen-haria de software

Nossa abordagem permite a geração de diferentes formulários web JSF que são in-stalados e executados diretamente no jBPM. Informações relativas a execução do pro-cesso que são providas através de tais formulários são automaticamente persistidas pelojBPM. Atualmente, a abordagem está sendo refinada para permitir a integração com ou-tros sistemas externos de forma a obter informação relevante para rastrear a execução doprocesso. Uma das integrações sendo explorada obtém informações diretamente de umsistema de gerência de configuração e controle de versões, a respeito de artefatos sendosubmetidos diretamente ao repositório. Isso permite que o workflow do processo obtenhainformação atualizada a respeito da execução dos processos. O motor jBPM facilita aimplementação de tais integrações, oferecendo a possibilidade de extensão do código doworkflows para a realização de chamadas externas (via web services) para outros sistemas


Figura 5.16: Visualização do processo na forma gráfica em execução pelo jbpm-console


externos.

5.8.3 Independência de plataforma na aplicação da abordagem

As especificações de processos definidas no EPF Composer são definidas na nossaabordagem usando o metamodelo UMA. Tal metamodelo representa uma unificação deconceitos provenientes do metamodelo SPEM e de outras linguagens de processos exis-tentes. Dessa forma, nós podemos encarar a definição de nossos processos EPF, comosendo um modelo independente de plataforma (PIM) na abordagem MDA. As transfor-mações modelo-para-modelo e modelo-para-texto aplicadas sobre tal especificação UMA,geram como saída a especificação de um workflow de acordo com metamodelo JPDLpara o jBPM, na forma de arquivos de configuração e código-fonte de formulários webJSF. Tais elementos gerados podem ser vistos como modelos específicos de plataforma(PSM) na abordagem MDA. Dessa forma, podemos dizer que nossa abordagem ofereceindependência de plataforma, permitindo a fácil inclusão de novas transformações quepermitam a geração de PSMs para outras plataformas de sistemas de workflow.

5.8.4 Gerência de variabilidades de processos

A abordagem apresentada neste trabalho faz parte de um método sistemático sendodesenvolvido atualmente [ALEIXO et al., 2010a], e que objetiva a gerência de variabil-idades de uma família de processos, promovendo a sua fácil customização, instalação eexecução em sistemas de workflow. Técnicas e mecanismos de engenharia de linhas deproduto são usados em combinação com engenharia dirigida por modelos em tal método,para atingir esse objetivo. Modelo de features e técnicas generativas promovem a gerên-cia de variabilidades existentes em uma família de processos, permitindo a seleção e cus-tomização de partes desse processo usando modelos de mais alto nível. A combinaçãodo suporte automatizado para gerência de variabilidades juntamente com a abordagem detransformação de modelos de processo para especificações de workflows permitem atingiro objetivo mencionado acima.

Um dos problemas atuais de escalabilidade da abordagem é a anotação manual deelementos do processo (arquivos XMI) que representam variabilidades, além da criaçãode fragmentos a partir da identificação visual deles em arquivos XMI. Em uma novaimplementação da abordagem, o grupo vem explorando formas de manipulação diretados modelos EMF oferecidos pelo EPF, com o objetivo de automaticamente importá-lopara ser usado como nosso modelo de arquitetura do processo. Tal estratégia pode reduzir


drasticamente a necessidade do uso de anotações e permitir que os fragmentos sejamcriados visualmente nos modelos de derivação oferecidos pelo GenArch. A direção atualde nossa pesquisa indica que o uso e manipulação do metamodelo do EPF é complementaraos mecanismos de anotação e fragmentos oferecidos pela ferramenta de derivação. Talhipótese está sendo avaliada em novas implementações de refinamento da abordagem.

5.8.5 Especificação Multi-Nível do Modelo de Característica

Uma das possibilidades que estamos atualmente explorando e que pode agregar valorà abordagem proposta é poder expressar as features da linha de processo na forma deperguntas. Estas perguntas seriam respondidas na configuração de um novo processotrazendo facilidades para a tomada de decisão e interação do engenheiro de processos du-rante a etapa de derivação do processo customizado. O foco principal de tais perguntaspode ser em tornar explícito features de alto nível relacionadas às diretrizes do projeto.Um exemplo de pergunta seria, por exemplo: “Qual a linguagem de programação utilizadano projeto?”. Através da resposta fornecida pelo usuário diferentes atividades, tarefas,artefatos e guias do processo seriam automaticamente selecionados e customizados paragarantir o atendimento de tal requisito. No caso de seleção da linguagem Java, por ex-emplo, a tarefa de “realizar testes unitários utilizando JUnit” seria incluída no processo.Nossa proposta nessa linha explora a organização do modelo de características através de2 diferentes níveis: (i) das perguntas de mais alto nível; e (ii) do nível de variabilidadesencontradas diretamente na linha de processo.

5.8.6 Gerência de Variações em Métricas de Processo

A importância da utilização de métricas para a engenharia de software já é um as-sunto consolidado, seja para medir produtos, processos ou recursos. No que diz respeitoà processos, sua aplicação pode ser útil para entender e aperfeiçoar o processo de de-senvolvimento, avaliar sua produtividade, identificar as melhores práticas, entre outros.Dada a grande variedade de métricas existentes, gerenciar quais métricas deve ser apli-cadas em determinado processo de desenvolvimento de software não é uma tarefa trivial,pois de acordo com as necessidades de cada projeto, uma série de métricas alternativas ecomplementares podem ser aplicadas.

Neste cenário, é interessante que as variações nas métricas de um processo possamtambém ser gerenciadas durante a fase de customização/reuso de uma linha de processo


usando uma abordagem de gerência de variabilidades, tal como a apresentada neste tra-balho. Atualmente, diversas métricas de avaliação de produtividade vêm sendo explo-radas pelo grupo para serem tratadas como variabilidades da linha de processo OpenUP, edesta forma habilitar o engenheiro de processo a derivar um processo contendo métricasalinhadas com as fases, atividades, técnicas e tecnologias que ele contém.

78

6 Trabalhos Relacionados

Este capítulo apresenta e discute trabalhos relacionados à área de linha de processosde software e ambientes para a execução e monitoramento de processos. A abordagemproposta nesta dissertação é confrontada sob essas duas diferentes perspectivas com ostrabalhos desenvolvidos pela comunidade.

6.1 Abordagens para Gerência de Variabilidades e Com-ponentização em Processos de Software

Armbrust et al [ARMBRUST et al., 2009] apresenta uma abordagem para desenvolvi-mento de linha de processos de forma similar à uma linha de produtos. A abordagemdetalhada apenas o primeiro passo de criação de uma linha de processos, a determinaçãodo escopo. A abordagem analisa produtos e projetos existentes, planejados e potenci-ais em relação às suas necessidades de processos usando um modelo matemático. Umadas vantagens da abordagem estar em analisar não apenas a situação corrente de umaorganização, mas também em antecipar a análise do desenvolvimento futuro permitindouma melhor seleção de processos do que quando apenas uma análise retrospectiva é real-izada. A abordagem proposta neste trabalho vai desde a definição da linha passando peladerivação de processos até sua execução, através do uso de técnicas e conceitos da área deprodutos de software, destacando também o reuso de artefatos da linha de processo. En-tretanto, nosso foco principal é no suporte ferramental para a gerência de variabilidadesem linhas de processo.

Rombach [ROMBACH, 2005] é pioneiro e define no seu trabalho o termo “engen-haria de linhas de processo de softwares”, propondo a organização de famílias de proces-sos similares. Embora não defina explicitamente como seriam construídas e gerenciadastais linhas de processo de software, ele relata a aplicação da sua abordagem em pequenosdomínios (sem validação), citando, como exemplo, o V-Model XT na Alemanha. Esse

6. Trabalhos Relacionados 79

trabalho aponta também a viabilidade de aplicações de tal abordagem em contextos maisgenéricos.

Barreto et al. [BARRETO; MURTA; ROCHA, 2009] propõem uma abordagem paracomponentização de processos legados de software com o objetivo de facilitar o alcancede vários resultados esperados pelos modelos de maturidade. Esta abordagem usa comobase a premissa que tornar processos reutilizáveis é uma tarefa custosa, pois situaçõesdiferentes precisam ser previstas e explicitadas através de componentes, linhas e carac-terísticas. Nossa abordagem parte do mesmo princípio de que reuso de partes da especifi-cação de processo é uma tarefa custosa, porém a componentização é realizado na própriaferramenta de definição de processo, no nosso caso o EPF Composer. E o reuso pode serhabilitado pelo uso de técnicas de gerência de variabilidades sobre elementos dos modelosda linha de processo.

Pereira et al. [PEREIRA; REIS, 2009] descreve um ambiente que atua como repositóriode ativos de processos de software. Neste ambiente, os artefatos do processo podem serreusados, bem como passar por evoluções visando atingir a maturidade. Essa proposta re-força a importância da constante evolução dos ativos de processos de software em funçãodos modelos de maturidade como o CMMI 1 e MPS.BR [WEBER, 2009].

Barreto et al. [BARRETO et al., 2010] Apresenta uma abordagem para reutilização deartefatos de processo de software utilizados por empresa especializada em prestar consul-toria para definir, implantar ou implementar melhorias em processos de software, SPCO(Software Process Consulting Organizations). O estudo apresentado neste trabalho tam-bém propõe a criação de uma linha de processo de software, amparado por especialistasem engenharia de processos de software. A abordagem apresenta também a criação deuma ferramenta de repositório de componentes para os elementos de processo, que aux-ilia na aplicação desta abordagem. O trabalho apresentado vai desde a criação do artefatode processo reutilizável, seu mapeamento em nível de reutilização e a definição do apoioferramental para o auxílio da abordagem. Apesar da abordagem fazer referência que ar-quiteturas de processos de software são similares a workflows e não há uma proposta paraa execução desses processos.

Em comum, todos os trabalhos relacionados apontam para a importância da reuti-lização de elementos de processos de desenvolvimento de software. Nenhum deles, en-tretanto, focaliza a questão da gerência de variabilidades e derivação automática de pro-cessos, nem tampouco focaliza a concretização de tais etapas. A abordagem proposta

1Disponível em: http://www.sei.cmu.edu/cmmi/. Acesso em: Abr. 2009.


nesse trabalho representa um passo inicial para o desenvolvimento de uma abordagemsistemática para o desenvolvimento de linhas de processo de software.

6.2 Abordagens para Execução de Processos de Software

Bendraou et al [BENDRAOU; JEZéQUéL; FLEUREY, 2009] propõe a criação de ummodelo para a execução de processos, chamado de UML4SPM. Tal modelo é baseado emUML e a execução do processo é definida utilizando uma linguagem de meta-programaçãochamada Kermeta 2. Esta linguagem permite a execução do processo sem nenhuma com-pilação, porém não oferece um ambiente rico e robusto para a execução do workflow

do processo de maneira que possa ser feito o seu monitoramento efetivo. Ela é usadamais com propósito de simulação. O diferencial da nossa abordagem é que utilizamosdefinições de linguagens de modelagem e execução de processo existentes e amplamenteutilizada.

Bendraou et al [BENDRAOU et al., 2007] apresenta uma abordagem baseada emDDM que contempla o mapeamento entre duas linguagens UML4SPM e a WS-BPEL[JURIC, 2006]. Cada linguagem atua em um diferente universo: definição de processos desoftware e execução de processos, respectivamente. A justificativa dessa escolha foi queambas linguagens tem seus pontos fortes, tanto na parte de modelagem quanto na propostade execução. A transformação entre modelos de processo e workflow foi definida atravésde um programa escrito diretamente na linguagem Java. Nosso trabalho tem uma forterelação com o trabalho proposto e a diferença é que na nossa abordagem para a execuçãode processos utilizamos os meta-modelos UMA e JPDL para definição de processos eworkflow, respectivamente. Além disso, nossas transformações permitem a geração decódigo fonte efetivo de formulários web que são instalados e executados em um sistemade workflow.

Maciel et al [MACIEL et al., 2009] também define uma abordagem baseada em mod-elos para a modelagem de processos de software usando a abordagem Model Driven Ar-

chitecture (MDA). Os autores citam no trabalho que a abordagem utilizada é baseadatotalmente em padrões da OMG (SPEM 2.0, UML 2.0, MDA). Porém o principal focodeste trabalho é a especificação de elementos de processos. A abordagem não contemplaa completa transformação do processo para execução em sistemas de workflow.

A abordagem de execução e monitoramento de processos apresentada nesta disser-tação de mestrado se diferencia da maioria dos trabalhos de pesquisa recentes, porque ela

2http://kermeta.org/


define transformações entre tecnologias de definição e execução de processo amplamenteusados na indústria e na academia. Ao contrário dos trabalhos atuais, nossa abordagempromove a geração de arquivos de configuração e código fonte que permitem a efetiva ex-ecução e monitoramento de processos em sistemas de workflow. Conforme mencionadono capítulo 5 (seção 5.7), nossa abordagem também está estruturada de forma a permi-tir a incorporação de novas transformações da especificação do processo para diferentesplataformas de workflow.

82

7 Conclusão e Trabalhos Futuros

Neste capítulo são apresentadas as conclusões do trabalho com uma breve descriçãodas contribuições e uma lista de trabalhos em andamento e futuros.

Este trabalho apresentou uma abordagem para gerência de variabilidades e transfor-mação de especificações de processos de desenvolvimento de software em uma especifi-cação de workflow, o qual pode ser instalado e executado em sistemas de workflow. Aabordagem foi implementada e avaliada utilizando tecnologias e plataformas existentes,através de uma concretização que permite a transformação de especificações de processodo Eclipse Process Framework (EPF) em especificações de workflow que podem ser in-staladas no motor de execução jBPM. Conforme discutido ao longo desta dissertaçãode mestrado, nossa abordagem é suficientemente independente de plataforma para seradaptada para outros sistemas de workflow, bastando para isso a redefinição das transfor-mações que ela define.

7.1 Contribuições

Uma abordagem para a gerência de variabilidades e derivação de processos desoftware. Definição de uma abordagem para a anotação de variabilidades em processos desoftware e a definição de uma linha de processo [ALEIXO et al., 2010c] [ALEIXO et al.,2010b] [ALEIXO et al., 2010a]. Derivação automática de processos baseada em modelosde derivação (processo, configuração e características). A abordagem foi implementadae avaliada utilizando tecnologias e plataformas existentes, e torna explícito o processode gerência de variabilidades em famílias de processos existentes, quando comparadaaos recursos manuais oferecidos por ferramentas existentes. Além disso, ela permite acustomização de processos de software de acordo com as necessidades específicas decada projeto.

Adaptação da ferramenta de derivação para trabalhar com processos de soft-ware. Adaptação da ferramenta GenArch, uma ferramenta de derivação de linhas de

7. Conclusão e Trabalhos Futuros 83

produto de software, para ser aplicada no contexto de linhas de processo de software.

Estudo de caso preliminar. Como forma de avaliar preliminarmente a abordagem,ela foi aplicada no cenário relacionado a projetos que definem e reusam processos basea-dos no OpenUP. Foram aplicados como estudo de caso, processos utilizados para o de-senvolvimento de aplicações no núcleo de desenvolvimento de sistemas do IFRN, e essesprocessos foram caracterizados como integrantes de uma mesma família de processos,permitindo a definição de uma linha de processos.

Uma abordagem para a execução de processos de software. Através de trans-formações modelo-para-modelo, de modelos de processos para modelos de workflow, etransformações modelo-para-texto, de modelos de workflow para projetos executáveis deworkflow, a abordagem proporcionou o reuso de informações presentes no processo paraque fosse possível seu gerenciamento através de um motor de execução de workflows.Como parte da definição da abordagem foi realizado um estudo visando o mapeamentoentre abstrações e conceitos presentes nos metamodelos de especificação de processos eworkflow.

7.2 Trabalhos em Andamento e Futuros

Como trabalhos em andamentos e futuros, diversos refinamentos da abordagem estãosendo realizados.

Desenvolvimento de novos estudos de caso e experimentos. Nesta dissertação foidesenvolvido apenas um estudo preliminar relacionado a linha de processos OpenUP.Como parte da continuidade deste trabalho, finalizar a análise do estudo de caso OpenUP,bem como pretendemos avaliar a abordagem proposta em novos estudos de caso maiscomplexo e amplo de processo de software. Finalmente, pretendemos também realizarnovos experimentos que permitam avaliar o desempenho e usabilidade da abordagem emcomparação com estratégias de manipulação direta de modelos EPF.

Refinamento da abordagem para ser independente do Eclipse Process Frame-work. Por conta das dificuldades e limitações trazidas pelo uso e inserção direta de ano-tações em arquivos XMI, pretendemos fazer uma nova implementação da abordagem queofereça um ambiente para especificação de modelos de processo de forma independentedo Eclipse Process Framework (EPF). Mecanismos de anotação e fragmentos serão usa-dos em conjunto com técnicas de engenharia dirigida por modelos provendo a gerênciade variabilidades de forma independente do EPF.

7. Conclusão e Trabalhos Futuros 84

Exploração do conceito de componentes de processo. Também em um novo refi-namento da abordagem pretendemos explorar o uso do conceito de componentes de pro-cesso, como um mecanismo adicional para prover a gerência de variabilidades de granu-laridade grossa. Apesar da abordagem atual, permitir a gerência de elementos de processo(atividades, tarefas, artefatos), pretendemos avaliar se o uso da abstração de componentesde processo pode trazer benefícios explícitos para este processo.

Especificação Multi-Nível do Modelo de Característica. Uma das possibilidadesque estamos atualmente explorando e que pode agregar valor à abordagem proposta époder expressar as features da linha de processo na forma de perguntas. Estas perguntasseriam respondidas na configuração de um novo processo trazendo facilidades para atomada de decisão e interação do engenheiro de processos durante a etapa de derivaçãodo processo customizado. Nossa proposta nessa linha pretende explorar a organizaçãodo modelo de características através de 2 diferentes níveis: (i) das perguntas de mais altonível; e (ii) do nível de variabilidades encontradas diretamente na linha de processo.

Gerência de Variações em Métricas de Processo. Atualmente, diversas métricas deavaliação de produtividade vêm sendo exploradas pelo grupo para serem tratadas comovariabilidades da linha de processo OpenUP, e desta forma habilitar o engenheiro de pro-cesso a derivar um processo contendo métricas alinhadas com as fases, atividades, técni-cas e tecnologias que o processo contém. Pretendemos, além de permitir a derivação deprocessos contendo as métricas e atividades que serão monitoradas, também possibilitarque a instalação do processo em um sistema de workflow, já permita a coleta automáticaparcial ou completa de tais métricas.

85

Referências Bibliográficas

ALEIXO, F. A. et al. An approach to managing and customizing variabilities in softwareprocesses. Software Engineering, Brazilian Symposium on, IEEE Computer Society, LosAlamitos, CA, USA, v. 0, p. 118–127, 2010.

ALEIXO, F. A. et al. Automating the variability management, customization and deploy-ment of software processes: A model-driven approach. In: ICEIS. [S.l.: s.n.], 2010. p.372–387.

ALEIXO, F. A. et al. A model-driven approach to managing and customizing softwareprocess variabilities. In: ICEIS (3). [S.l.: s.n.], 2010. p. 92–100.

ANTKIEWICZ, M.; CZARNECKI, K. Featureplugin: feature modeling plug-in foreclipse. In: ETX. [S.l.: s.n.], 2004. p. 67–72.

ARMBRUST, O. et al. Scoping software process lines. Softw. Process, John Wiley &Sons, Inc., New York, NY, USA, v. 14, n. 3, p. 181–197, 2009. ISSN 1077-4866.

BARRETO, A. et al. Supporting the definition of software processes at consulting organi-zations via software process lines. Quality of Information and Communications Technol-

ogy, International Conference on the, IEEE Computer Society, Los Alamitos, CA, USA,v. 0, p. 15–24, 2010.

BARRETO, A. S.; MURTA, L. G. P.; ROCHA, A. R. C. Componentizando processoslegados de software visando a reutilização de processos. In: JOUAULT, F. (Ed.). Simpósio

Brasileiro de Qualidade de Software (SBQS), 2009. Ouro Preto: [s.n.], 2009.

BENDRAOU, R.; JEZéQUéL, J.-M.; FLEUREY, F. Combining aspect and model-drivenengineering approaches for software process modeling and execution. In: ICSP ’09:

Proceedings of the International Conference on Software Process. Berlin, Heidelberg:Springer-Verlag, 2009. p. 148–160. ISBN 978-3-642-01679-0.

BENDRAOU, R. et al. Software process modeling and execution: The uml4spm to ws-bpel approach. In: EUROMICRO ’07: Proceedings of the 33rd EUROMICRO Confer-

ence on Software Engineering and Advanced Applications. Washington, DC, USA: IEEEComputer Society, 2007. p. 314–321. ISBN 0-7695-2977-1.

Referências Bibliográficas 86

CHASTEK, G. et al. Product Line Analysis: A Practical Introduction. [S.l.], 2001.

CIRILO, E. et al. Integrating component and product lines technologies. In: ICSR. [S.l.:s.n.], 2008. p. 130–141.

CIRILO, E. J. R. GenArch: Uma Ferramenta Baseada em Modelos para Derivação de

Produtos de Software. Dissertação (Mestrado) — Pontifícia Universidade Católica do Riode Janeiro, 2008.

CIRILO, U. K. E.; LUCENA, C. J. P. de. Genarch: Uma ferramenta baseada em modelospara derivação de produtos de software. In: JOUAULT, F. (Ed.). Anais da Sesso de Ferra-

mentas do Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software

(SBCARS) 2007. Ouro Preto: [s.n.], 2009.

CLEMENTS, P. C.; NORTHROP, L. Software Product Lines: Practices and Patterns.[S.l.]: Addison-Wesley, 2001. (SEI Series in Software Engineering).

COLYER, A. et al. Eclipse aspectj: aspect-oriented programming with aspectj and the

eclipse aspectj development tools. First. [S.l.]: Addison-Wesley Professional, 2004. ISBN0321245873.

CONSORTIUM, S. P. Process Definition and Modeling Guidebook. [S.l.]: Software Pro-ductivity Consortium, 1992. ISBN 0321197704.

CZARNECKI, K.; EISENECKER, U. Generative Programming: Methods, Tools, and

Applications. Boston, MA: Addison-Wesley, 2000. ISBN 978-0-201-30977-5.

DEELSTRA, S.; SINNEMA, M.; BOSCH, J. Product derivation in software product fam-ilies: a case study. J. Syst. Softw., Elsevier Science Inc., New York, NY, USA, v. 74, n. 2,p. 173–194, 2005. ISSN 0164-1212.

EFFTINGE S.; KADURA, C. OpenArchitectureWare 4.1 XpandLanguage Reference.

OpenArchitectureWare. 2006. Acesso em: Abr. 2010.

FREIRE, M. et al. Detalhamento das Pesquisas e Estudo de Caso, Software Process Lines.2010. Disponível em: <http://www.dimap.ufrn.br/ uira/process-lines/>. Acesso em: 3Abr. 2010.

GIMENES, I. M. de S.; TRAVASSOS, G. H. O enfoque de linha de produto para de-senvolvimento de software. In: . [S.l.]: XXI Jornada de Atualização em Informática(JAI), 2002. cap. 1.


GROHER, I.; SCHWANNINGER, C.; VOELTER, M. An integrated aspect-orientedmodel-driven software product line tool suite. In: ICSE Companion ’08: Companion of

the 30th international conference on Software engineering. New York, NY, USA: ACM,2008. p. 939–940. ISBN 978-1-60558-079-1.

HAUMER, P. Eclipse process framework composer:part 1: Key concepts. In: . [S.l.: s.n.],2007.

IBM. Rational Method Composer. IBM - RUP. 2010. Disponível em: <http://www-01.ibm.com/software/awdtools/rmc>. Acesso em: 10 Jan. 2010.

JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development pro-

cess. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999. ISBN0-201-57169-2.

JURIC, M. B. Business Process Execution Language for Web Services BPEL and

BPEL4WS 2nd Edition. [S.l.]: Packt Publishing, 2006. ISBN 1904811817.

KRUCHTEN, P. The Rational Unified Process: An Introduction. Boston, MA, USA:Addison-Wesley Longman Publishing Co., Inc., 2003. ISBN 0321197704.

LAARMAN, A. Achieving qvto and atl interoperability: An experience report onthe realization of a qvto to atl computer. In: JOUAULT, F. (Ed.). 1st International

Workshop on Model Transformation with ATL, MtATL 2009. Aachen: Sun SITECentral Europe, 2009. (CEUR Workshop Proceedings), p. 119–133. Disponível em:<http://doc.utwente.nl/67522/>.

LINDEN, F. J. van der; SCHMID, K.; ROMMES, E. Software Product Lines in Action:

The Best Industrial Practice in Product Line Engineering. Berlin: Springer, 2007. ISBN978-3-540-71436-1.

LOBO, A. E. de C.; RUBIRA, C. M. F. Um Estudo para Implantação de Linha de Produto

de Software Baseado em Componentes. [S.l.], 2009.

MACIEL, R. S. P. et al. An integrated approach for model driven process modeling andenactment. Software Engineering, Brazilian Symposium on, IEEE Computer Society, LosAlamitos, CA, USA, v. 0, p. 104–114, 2009.

PENG, L.; ZHOU, B. Research on workflow patterns based on jbpm and jpdl. In: PACIIA

08: Proceedings of the 2008 IEEE Pacific-Asia Workshop on Computational Intelligence

and Industrial Application. Washington, DC, USA: IEEE Computer Society, 2008. p.838–843. ISBN 978-0-7695-3490-9.


PEREIRA, M. A.; REIS, C. A. L. Software process marketplace: Um ambiente para com-partilhamento e reúso de ativos de processo. In: XXIII Simpósio Brasileiro de Engenharia

Software, 2009. Fortaleza: [s.n.], 2009.

POHL, K.; BOCKLE, G.; LINDEN, F. J. v. d. Software Product Line Engineering: Foun-

dations, Principles and Techniques. Secaucus, NJ, USA: Springer-Verlag New York, Inc.,2005. ISBN 3540243720.

PRIETO-DIAZ, R.; ARANGO, G. Domain Analysis and Software Systems Modeling. LosAlamitos, CA, USA: IEEE Computer Society Press, 1991. ISBN 081868996X.

ROMBACH, H. D. Integrated software process and product lines. In: ISPW. [S.l.: s.n.],2005. p. 83–90.

RU-ZHI, X. et al. Reuse-oriented process component representation and retrieval. In: CIT

’05: Proceedings of the The Fifth International Conference on Computer and Information

Technology. Washington, DC, USA: IEEE Computer Society, 2005. p. 911–915. ISBN 0-7695-2432-X.

SHAVOR, S. et al. The Java Developer’s Guide to Eclipse. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. ISBN 0321159640.

TERäVä, H. Software Process Modeling with Eclipse Process Framework and SPEM 2.0.Dissertação (Mestrado) — UNIVERSITY OF TURKU, 2007.

THRÄNERT, M.; WERNER, A. A process family approach for the reuse of developmentprocesses. In: Proceedings of the International Joint Conferences on Computer, Informa-

tion, and Systems Sciences, and Engineering (CISSE 06). [S.l.: s.n.], 2006.

VOS, G. ISSUES OF ITERATIVE MDA-BASED SOFTWARE DEVELOPMENT PRO-

CESS. Dissertação (Mestrado) — University Of Twente, 2008.

WEBER. Modelo de referência e método de avaliação para melhoria de processo de soft-ware - versão 1.0 (mr-mps e ma-mps)). In: IV Simpósio Brasileiro de Qualidade de Soft-

ware. Porto Alegre: [s.n.], 2009.