Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Uma Abordagem Dirigida por Modelos para Gerência
de Variabilidades e Execução de Processos de Software
Wanderson Câmara dos Santos
Natal/RN
Setembro de 2010
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Uma Abordagem Dirigida por Modelos para Gerência
de Variabilidades e Execução de Processos de Software
Dissertação submetida ao Programa de Pós-Graduação em Sistemas e Computação do De-partamento de Informática e Matemática Apli-cada da Universidade Federal do Rio Grande do Norte como parte dos requisitos para a obtenção do grau de Mestre em Sistemas e Computação.
Autor: Wanderson Câmara dos Santos
Orientador: Prof. Dr. Uirá Kulesza
Natal/RN
Setembro de 2010
"Este trabalho é dedicado aos meus avós Itamar Câmara e Terezinha Freitas Câmara. (in memoriam)."
Wanderson.
Agradecimentos
A Deus, por tudo; Aos meus avós Itamar Câmara e Terezinha Freitas Câmara, por me ensinar a sonhar e por simplesmente acreditarem que poderia transformar meus sonhos em realidade; Aos meus pais Edivaldo José dos Santos e Irismar Freitas Câmara dos Santos, que estão me ajudando a realizar estes sonhos; Aos meus irmãos Walderson e Iza, por serem simplesmente tão especiais; Aos amigos Hamilton Rangel, Silvano Maia, Guto de Castro e Nunes Maia pelos ensinamentos e amizade; Ainda Não Acabou a lista é grande... :P
Resumo
Este trabalho apresenta uma abordagem dirigida por modelos para gerência e cus-tomização de variabilidades em processos de software como sua implantação em sis-temas de workflow. A abordagem é fundamentada nos princípios e técnicas de linhas de produto de software. Ela oferece suporte para a manipulação automática de variações ocorrendo em especificações de processos, e promove a derivação automática de cus-tomizações específicas de tais processos. A abordagem para a execução dos processos em um motor de workflow consiste: (i) a transformação modelo-para-modelo de especi-ficações de processo de software para especiespeci-ficações de workflow; e (ii) a transformação modelo-para-texto de especificações de workflow para código-fonte a ser instalado em motores de workflow. Como benefícios, a bordagem promove o acompanhamento da execução do processo, permitindo o seu monitoramento para fins de validação, verifi-cação ou simulação, bem como em análises e decisões para melhoria dos processos. De forma a validar e demonstrar os benefícios da abordagem, o trabalho apresenta uma imple-mentação da abordagem, Nesta impleimple-mentação, especificações de processos de software no Eclipse Process Framework (EPF) são automaticamente transformadas para especifi-cações de workflow na linguagem jPDL. Tais especifiespecifi-cações jPDL são, posteriormente, transformadas em código-fonte de formulários web Java Server Faces (JSF) que podem ser instalados no motor de workflow jBPM. Tecnologias de engenharia dirigida por mode-los, tais como QVTO e Accelleo, foram usadas no desenvolvimento de tal implementação da abordagem.
Palavras-chave: Processo de software, Execução de processos, Reuso de Software.
Abstract
This work proposes...
Key words: Software Process, Process execution, Software Reuse.
vi
Sumário
Lista de Figuras p. vii
Lista de Tabelas p. viii
1 Fundamentação Teórica p. 1
1.1 Reuso em Processos de Software . . . p. 1
1.2 Linhas de Produto de Software . . . p. 1
1.2.1 Ferramentas de Derivação . . . p. 3
1.3 Engenharia Dirigidida por Modelos . . . p. 4
1.3.1 Model-Driven Architecture . . . p. 4
1.3.2 Eclipse Modeling Framework . . . p. 5
1.3.3 Acceleo . . . p. 6
1.3.4 QVTO . . . p. 7
1.3.5 Sistemas de Workflow . . . p. 8
1.3.6 JBoss BPM . . . p. 8
vii
Lista de Figuras
viii
1
1
Fundamentação Teórica
1.1
Reuso em Processos de Software
Trabalhos recentes [ROMBACH, 2005] [BARRETO; MURTA; ROCHA, 2009] [RU-ZHI et al., 2005] [ARMBRUST et al., 2009] têm reforçado a importância de promover a reutilização de processos como forma de promover o uso de boas práticas de projetos anteriores na definição dos novos processos (Seção V). Uma das principais vertentes de trabalho atual diz respeito ao uso e adaptação de técnicas de linhas de produto de software, na gerência de variabilidades encontradas em linhas de processo. Uma linha de processo pode ser vista como uma família de processos que compartilha elementos de processo comuns e variáveis. Baseado em tal definição, frameworks de processos existentes podem ser também caracterizados como linhas de processo.
Reusar especificações parciais de processos de software existentes de maneira rápida e automática permitindo sua fácil customização para novos projetos é ainda um desafio para empresas de desenvolvimento de software de média e larga escala. Ao longo dos últimos anos, alguns esforços e iniciativas têm sido propostos com o intuito de promover e ampliar a reutilização de especificações de processos de software, tais como, o Ratio-nal Unified Process (RUP) [KRUCHTEN, 2003]. Em paralelo, ferramentas têm também sido propostas para viabilizar a automação durante tal processo de reutilização. O EPF Composer [HAUMER, 2007] [FOUNDATION, 2010] e o Rational Method Composer [IBM, 2010] são exemplos de tecnologias que permitem a manipulação e customização dos diferentes elementos presentes na especificação de processos.
1.2
Linhas de Produto de Software
O conceito de linha de produtos de software, também conhecida como família de produtos, consiste em um conjunto de sistemas de software que compartilham um con-junto comum de features gerenciadas, que satisfazem necessidades específicas de um
seg-1. Fundamentação Teórica 2
mento particular do mercado e que são desenvolvidos a partir de um conjunto comum de artefatos de forma pré-estabelecida (core assets) [CLEMENTS; NORTHROP, 2001] [COHEN, 2003]. Chastek [CHASTEK et al., 2001] define LPS como uma Família de Produtos de Software (FPS) em um domínio que compartilha características (features). Para [O. . . , 2002] Uma linha de produto de software pode ser vista como um conjunto de potenciais produtos de software com características suficientemente similares para permi-tir a definição de uma infra-estrutura genérica de estruturação de artefatos que compõem os produtos e a parametrização de suas diferenças.
Vários aspectos levam uma organização a adotar uma abordagem de linha de produtos para obter melhores resultados, como custos de desenvolvimento e qualidade do produto [LINDEN; SCHMID; ROMMES, 2007] entre as outras vantagens de se utilizar a abor-dagem de linha de produtos de software podemos citar: (i) redução no tempo de entrega, com a adoção da técnica de linhas de produto o tempo de produção de um produto conse ser bastante reduzido, a princípio a confecção dos artefatos podem demandar um tempo maior de desenvolvimento, porém levando em consideração a reutilização deste artefato, o tempo de produção é drasticamente reduzido, (ii) redução no esforço de manutenção, uma vez efetuada a manutenção numa linha de produto essa correção se aplica a todas os produtos, agora, devidados desta linha, (iii) evoluções gerenciáveis, da mesma maneira que ocorre com a manutenção na linha de produto, podem ocorrer evoluções de imple-mentação que serão repassadas para os produtos também devirados desta LPS, (iv) com-plexidade gerenciavel - um dos maiores benefícios é o gerenciamento da comcom-plexidade 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 temo que, uma vez todos os nossos, artefatos testatos na linha de produtos, esses artefatos se propagam nos produtos e uma vez detectados as falhas, estas mesmas podem ser tatadas diretamente na linha corrigindo qualquer erro que possa provocar falhas nos produtos desta linha, (vi) e com certeza o benefício mais esperado é com relação ao custo de pro-dução dos produtos, que levando em consideração todos os quisitos anteriores implicam em uma redução brusca de custos de uma corporação para a a manutenção e evolução dos seus produtos de software.
Para a implementação da abordagem de linhas de produto de software podem ser utilizadas três técnicas:
(i) pró-ativa - na abordagem pró-ativa a linha de produto é analisada, projetada e im-plementada por completo, de forma que atenda, inicialmente, o maior número possível de produtos. (ii) reativa - esta técnica é realizada de maneira incremental, de forma que, a linha de produto cresça de acordo com a demanda por novos produtos ou novas
carac-1. Fundamentação Teórica 3
terísticas em produtos que já existam. (iii) extrativa - a construção da linha de produto é realizada a partir da extração de características comuns e variáveis de um conjunto de softwares bases, previamente desenvolvidos e geralmente que estejam em produção.
A utilização destas técnicas não é mutuamente exclusivo, por exemplo, no início da contrução da Linha de Produto podemos ter como base um conjunto de produtos já exis-tentes e incrementalmente evoluir a arquitetura com acréscimos de novos produtos. Essa visão corresponde a adotar inicialmente a abordagem extrativa e, posteriormente, passar para uma abordagem reativa. O processo de gerenciamento de um núcleo de artefatos de software é composto por dois estágios: engenharia de domínio e engenharia de aplicação.
Segundo [LOBO; RUBIRA, 2009] [PRIETO-DIAZ; ARANGO, 1991] engenharia de domínio é a atividade de coletar, organizar e armazenar experiências anteriores na con-strução de aplicações em um domínio específico na forma de artefatos reutilizáveis, e a utilização sistemática destes artefatos na construção de novas aplicações. A engenharia de domínio engloba, basicamente, três atividades: (i) análise de domínio - atividade na definição do escopo para uma determinada família de sistemas e na identificação de carac-terísticas comuns e variáveis presentes neste domínio; (ii) projeto do domínio - atividade que se concentra na especificação de uma arquitetura comum e de componentes para o domínio; e (iii) implementação do domínio - atividade responsável pela implementação da arquitetura comum e dos componentes previamente definidos na atividade de projeto do domínio. O estágio onde é aplicado a engenharia de aplicação é a fase de construção de sistemas a partir dos resultados obtidos na engenharia de domínio [CZARNECKI; EISENECKER, 2000].
1.2.1
Ferramentas de Derivação
Para o uso da abordagens 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ção e 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, Gears [GEARS, 2009], pure::variants [PURE:VARIANTS, 2009], GenArch [CIRILO; LUCENA, 2009]. as ferramentas citadas visam oferecer um apoio para a automatização do processo de uti-lização da abordagem de linha de produtos de software no que se refere a derivação do produtos da linha.
1. Fundamentação Teórica 4
A ferramenta Gears é uma ferramenta de engenharia de linha de produtos e um frame-workque aborda os desafios específicos para a geração de uma variedade de produtos da linha, durante todo o ciclo de desenvolvimento completo [GEARS, 2009].
A ferramenta Gears permite a adoção/construção de LPS seguindo a abordagem in-cremental [CIRILO, 2008]. Dessa forma, é possível iniciar a construção de productos a partir de um ou dois subsistemas, módulos ou artefatos, e então transferir facilmente, através de incrementos gerenciáveis, para uma engenharia de LPS.
Pure::variants é uma ferramenta especialmente construida para o gerenciamento de variações [GROHER; SCHWANNINGER; VOELTER, 2008], a ferramenta gerencia as linhas de produtos e auxilia na produção de variantes de cada produto. O gerenciamento de variações é tarefa presente em todos os estágios do desenvolvimento da linha de pro-duto, inclusive suportando todas as fases do processo de desenvolvimento de software, desde a análise e projeto, passando pela implementação e teste até o uso e manutenção.[CIRILO, 2008].
1.3
Engenharia Dirigidida por Modelos
Desde o começo da programação de sistemas de software o homen aumenta o nível de abstração. o ultimo passo em alavancar o nível de abstração é provavelmente Engen-haria dirigida a modelos (Model Driven Engeeniring - MDE). em MDE. modelos não são apenas usado par auxiliar no processo de desenvolvimento, ficam além disso, são con-siderados os artefatos principais. Esta seção apresenta uma visão geral dos importantes conceitos de MDE. Estes conceitos são explicados e fornecem uma base teórica para a Engenharia dirigida por modelos.
1.3.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 industrias e com a visão na independência de plataforma [VOS, 2008]. de acordo com o OMG, MDA fornece uma abordagem para a especificação de sistemas e seu comportamento independentemente da sua plataforma. MDA é baseado nos seguintes padrões UML, XMI, QVT, OCL e MOF.
Em MDA temos três tipos de modelos, o modelo CIM (Computacional Independent Model), o modelo PIM
1. Fundamentação Teórica 5
(Platform Independent Model)e o modelo PSM (Platform Specific Model)
O Modelo CIM é o modelo que descreve o domínio da aplicação sem nenhuma refer-ência a uma tecnologia em particular e não mostra como o sistema é implementado. O modelo CIM mostro o sistema em seu ambiente e ajuda a demostrar o que o sistema dev-erá realizar, ou seja um modelo conceitual é derivado de uma realidade com a finalidade de adquirir um entendimento melhor desta realidade.
O Modelo PIM é uma parte importante do MDA esse modelo descreve o sistema sem referência a plataforma e permite uma representação independente de plataforma para o sistema, este modelo é o primeiro passo para a criação do sistema, o modelo PIM pode ser transformado em um modelo PSM utilizando transformação entre modelos.
1.3.2
Eclipse Modeling Framework
Projetos diferentes têm necessidades diferentes e gerenciar a customização desses processos para diferentes projetos é uma tarefa difícil de ser implementada na prática, com essa visão algumas ferramenta tem surgido para contribuir no gerenciamento dessa complexidade, um exemplo dessas ferramentas é o Eclipse Process Framework (EPF), que é uma ferramenta de apoio aos engenheiros de processo, líderes de projeto e gerentes de projeto que são responsáveis por criação, customização e publicação de processos para organizações de desenvolvimento ou projetos individuais, é também um projeto de tec-nologia aberta da fundação eclipse. Eclipse é uma comunidade de código aberto constru-indo uma plataforma de desenvolvimento aberto. [PROJECT, 2009] O Eclipse Process Framework (EPF), visa produzir um processo de de desenvolvimento de software person-alizável, com conteúdos e ferramentas exemplares, suportando uma ampla variedade de tipos de projetos e estilos de desenvolvimento. O projeto EPF visa dois principais obje-tivos que são: fornecer uma estrutura extensível e ferramentas para a engenharia de pro-cesso de software - método e propro-cesso de criação, gestão da biblioteca de componentes, configuração e publicação de um processo como também fornecer conteúdo de processo modelo e extensível para uma escala de desenvolvimento 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 e aplicações, além de promover a automatização de vários aspectos de criação de processos como por exemplo:
1. Fundamentação Teórica 6
1.3.3
Acceleo
Acceleo é uma linguagem OpenSource padronizada pela OMG baseada em uma abor-dagem DDM para a transformação de modelos, com o Acceleo podemos transformar nossas especificações de modelos para texto, desde que os nossos modelos obedeçam um meta-modelo e que este meta-modelo esteja de acordo com o EMF.
Acceleo foi desenvolvido para melhorar a produtividade no desenvolvimento de Soft-ware [??] e a abordagem com o desenvolvimento com acceleo envolve muitos conceitos em conjunto com MDA (Model Driven Architecture). O Acceleo oferece extensões para a geração de código para diferentes linguagens de programação como CShap, Java e PHP. As ferramentas disponíveis no Acceleo são totalmente integradas com o Eclipse provendo para o desenvolvedor um ambiente homogêneo de desenvolvimento.
Esta transformação acontece a partir da criação de templates no acceleo, uma vez definido os templates no acceleo usamos os modelos EMF para a geração dos nossos artefatos desejados como demonstrado na figura 1.1.
Figura 1.1: Abordagem de Desenvolvimento Utilizando o Acceleo
Para a criação de um template é preciso a criação de um modelo, e para a criação de um novo modelo pode-se utilizar uma grande variedade de softwares, isto é possível porque o acceleo oferece uma grande compatibilidade com diversas ferramentas de mdoe-lagem UML.
1. Fundamentação Teórica 7
1.3.4
QVTO
Uma conceito importante quando se trabalha com a abordagem dirigida por modelos é a possibilidade de transoformação desses modelos, a transformação de modelos é uma estratégia importante quando se deseja separa os níveis de abstração do sistema, ou seja, a partir de um modelo mais abstrato ir construindo modelos mais específicos, no caso de sistemas de software podemos trabalhar em um modelo independente de plataforma, um modelo PIM, e a partir de requisitos funcionais do nosso sistema transformar este modelo para um modelo específico de Plataforma, ou seja em um modelo PSM. Para que esta transformação ocorra fazemos uso de linguagens de transformação de modelos QVT Operational, ou QVTO, que é uma linguagem que segue a especificação QVT (Query / Views / Transformations) [OMG, 2008]. O QVT é uma linguagem padrão da OMG para expressar consultas, exibições transformações em modelos que sigam o uma meta-modelo e esse por fim obedeça ao padrão MOF (Meta-Object Facility).
Como o próprio nome sugere esta linguagem possui vários propósitos, a linguagem pode ser utilizada para especificar consultas, visões e transformações A seguir temos a seguinte definição para Query, View e Transformation seguindo a definição dada por [GARDNER et al., 2003]
• View: “Uma Visão é um modelo que é completamente derivado de outro modelo ”; • Query: “Uma consulta é uma expressão que é avaliada por outro modelo ”;
• Transformation: “A transformação gera um modelo como resultado a partir de um modelo de entrada ”;
QVT não é uma linguagem simples, ela implementa OCL como linguagem de con-sulta e possui duas linguagems de transformação. A duas linguagens são QVT Relations e QVT Operational Mappings. Uma terceira linguagem compõem a parte principal das duas ultimas, essa linguagem que compõe o núcleo do mapeamento operacional e relacional é o QVT core.
QVTO é uma linguagem imperativa que extende ambas linguagens QVT Relation e QVT Core. Em geral, QVT pode somente ser utilizada na transformação de modelo para modelo, Transformação de Modelo para Texto não está incluida na especificação.
1. Fundamentação Teórica 8
1.3.5
Sistemas de Workflow
Workflowpode ser entendido como uma visualização de uma sequência lógica de um processo de negócio ou uma tarefa realizada por uma pessoa, grupo, orgazinação ou até mesmo mecanismos complexos, para se obter um produto ou prover um serviço, pode ser entendido também como uma abstração de um trabalho real. Com o grande crescimento da complexidade e mudanças nas condições de tarefas e procedimentos para a se obter um produto ou serviço, houve também uma necessidade cada vez maior de ferramentas que auxiliasse no trabalho de definição e gerenciamento desses fluxos de trabalho. Para essa finalidade, nos ultimos anos diversas ferramentas para auxiliar o desenvolvimento e acompanhamento dos fluxos de trabalho foram propostas [JBOSS, 2008], [DANET, 2010], [APACHE, 2010], [IMIXS, 2010], [BONITASOFT, 2010], [JAWFLOW, 2010] para essas ferramentas damos o nome de sistema de workflow que pode ser enquadrade dentro do conceito de BPMS (Business Process Management System), sendo definido como um sistema wue gerencia e define uma série de tarefas e procedimentos para se obter um produto ou serviço.
A maioria dessa ferramentas nos oferece uma interface gráfica para a definição do fluxo de trabalho, isso é uma forma de tornar mais iterativo a escrita do nosso workflow e com a crescente complexidade dos processos discutida no início da seção surgiu também a necessidade a criação de padrões de definição de processos [XPDL.ORG, 2010], [JURIC, 2006], [PENG; ZHOU, 2008].
1.3.6
JBoss BPM
O jBPM é um framework da JBoss que permite a criação de soluções empresariais baseados em processos de negócio usando notações gráficas, como também programação orientada a grafos e um engine de workflows. Esta ferramenta tem a característica de fazer uma ponte entre os analistas de negócio e os desenvolvedores, enquanto outros engines de BPM tem um foco que é limitado á pessoas que não são técnicas [JBOSS, 2010]
O jBoss BPM funciona da seguinte maneira, como entrada podemos ter uma especi-ficação de processo. Um Processo por sua vez é composto de de aticidades que são compostos pro transições e representam um fluxo de execução. O engine jBPM oferece também uma visualização em forma gráfica do processo servindo como base de comuni-cação entre pessoas técnicas e não técnicas envolvidas no desenvolvimento.
Cada execução de uma definição de processo é chamado de uma instância do pro-cesso, onde essas instâncias de processos são gerenciadas pelo jBPM. A ferramenta ainda
1. Fundamentação Teórica 9
possui uma interface gráfica para a exibição das execuções dos processos onde os usuários envolvidos no processo podem acompanhar o andamento do fluxo de execução da instân-cia que estão executando, podem também interagir com o processo comentando execução de tarefas e dar andamento nas tarefas que estão executando.
jBPM é baseado em uma máquina virtual de processo que é seu base para suportar multiplas linguagens de especificação de processo, atualmente linguagens como BPMN [OMG, 2010] e JPDL [??] estão ganhando mais espaço nesta ferramenta. A especifi-cação de processos na linguagem JPDL podem sem ser trabalhadas na IDE Eclipse com o plugin jBPM Graphical Proces Designer, nesta ferramenta os componentes que compõe o processo são trabalhados visualmente e a ferramenta trabalha o código JPDL que será executado pelo engine JBPM, o plugin cria um arquivo chamado processdefinition.xml que é uma especificação de processo seguindo um meta-modelo JPDL o plugin também oferece um canal 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 pode ser configurado para os mais diversos bancos de dados existentes.
10
Referências Bibliográficas
APACHE. Apache ODE (Orchestration Director Engine). 2010. Disponível em: <http://ode.apache.org/>. Acesso em: Ago. 2010.
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. S.; MURTA, L. G. P.; ROCHA, A. R. C. Componentizando processos legados 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.
BONITASOFT. Bonita Open Solution). 2010. Disponível em: <http://www.bonitasoft.com/>. Acesso em: Ago. 2010.
CHASTEK, G. et al. Product Line Analysis: A Practical Introduction. [S.l.], 2001.
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 Rio de Janeiro, 2008.
CIRILO, U. K. E.; LUCENA, C. J. P. de. Genarch: Uma ferramenta baseada em modelos para 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).
COHEN, 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.
CZARNECKI, K.; EISENECKER, U. Generative Programming: Methods, Tools, and Applications. Boston, MA: Addison-Wesley, 2000. ISBN 978-0-201-30977-5.
DANET. WfMOpen. 2010. Disponível em: <http://wfmopen.sourceforge.net/>. Acesso em: Ago. 2010.
Referências Bibliográficas 11
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.
FOUNDATION, E. Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview. 2010. Disponível em: <http://www.eclipse.org/epf/>. Acesso em: 10 Jan. 2010.
GARDNER, T. et al. A review of OMG MOF 2.0 Query / Views / Transformations Sub-missions and Recommendations towards the final Standard. [S.l.], 2003.
GEARS, G. S. Software Product Lines - Pragmatic Innovation from BigLever Software. 2009. Disponível em: <http://www.biglever.com>. Acesso em: 3 Nov. 2009.
GROHER, I.; SCHWANNINGER, C.; VOELTER, M. An integrated aspect-oriented model-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.
IMIXS. Imixs Workflow Project). 2010. Disponível em: <http://www.imixs.org/>. Acesso em: Ago. 2010.
JAWFLOW. jawFlow - a Java WorkFlow Manager). 2010. Disponível em: <http://jawflow.sourceforge.net/>. Acesso em: Ago. 2010.
JBOSS. jBPM. 2008. Disponível em: <http://www.jboss.org/jbossjbpm/>. Acesso em: 15 Jul. 2009.
JBOSS. jBPM. 2010. Disponível em: <http://jboss.org/jbpm>. Acesso em: 01 Ago. 2010.
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.
Referências Bibliográficas 12
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. ISBN 978-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.
O Enfoque de Linha de Produto para Desenvolvimento de Software. In: . [S.l.: s.n.], 2002. cap. 1.
OMG. QVTO Specification. 2008. Disponível em: <http://www.omg.org/spec/QVT/1.0/>. Acesso em: 07 Out. 2009.
OMG. Business Process Management Initiative. 2010. Disponível em: <http://www.bpmn.org/>. Acesso em: Ago. 2010.
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.
PRIETO-DIAZ, R.; ARANGO, G. Domain Analysis and Software Systems Modeling. Los Alamitos, CA, USA: IEEE Computer Society Press, 1991. ISBN 081868996X.
PROJECT, E. Eclipse Process Framework Project (EPF). 2009. Disponível em: <http://www-01.ibm.com/software/awdtools/rmc>. Acesso em: 10 Nov. 2009.
PURE:VARIANTS. 2009. Disponível em: <http://www.pure-systems.com>. Acesso em: 3 Nov. 2009.
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.
VOS, G. ISSUES OF ITERATIVE MDA-BASED SOFTWARE DEVELOPMENT PRO-CESS. Dissertação (Mestrado) — University Of Twente, 2008.
XPDL.ORG. XML Process Definition Language (XPDL)). 2010. Disponível em: <http://www.xpdl.org/>. Acesso em: Ago. 2010.
