Automating the Variability Management, Customization and ...

Automating the Variability Management, Customization and Deployment of Software Processes: A Model-Driven Approach Fellipe Araújo Aleixo1,2, Marília Aranha Freire1,2, Wanderson Câmara dos Santos1, Uirá Kulesza1 1

2

Federal University of Rio Grande do Norte (UFRN), Natal, Rio Grande do Norte, Brazil {wanderson, uira}@dimap.ufrn.br

Federal Institute of Education, Science and Technology of Rio Grande do Norte (IFRN), Natal, Rio Grande do Norte, Brazil {fellipe.aleixo, marilia.freire}@ifrn.edu.br

Abstract. This paper presents a model-driven and integrated approach to variability management, 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 engines. In order to evaluate the approach feasibility, we have implemented it using existing model-driven 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 execution of software processes in the JBoss BPM workflow engine. Keywords: Software Process, Software Product Lines, Model-Driven Development.

1 Introduction Nowadays, the importance of using software processes is already consolidated and is considered fundamental to the success of software development projects. Large and medium software projects demand the definition and continuous improvement of a software process in order to promote the productive development of high-quality software. Customizing and evolving existing software processes to address the variety of scenarios, technologies, culture and scale is a recurrent challenge required by the software industry. It involves the adaptation of software process models for the reality

of their projects. Besides, it must promote the reuse of past experiences in the definition and development of software processes for the new projects. The adequate management and execution of software processes can bring a better quality and productivity to the produced software systems. In this context, automated tools supporting the definition, customization and deployment are increasingly necessary. Although there are already many existing tools to specify processes [1] [2], there is a strong need to develop tools, technologies and techniques that help: (i) the management of components and variations of such processes; and (ii) the automatic composition and derivation of these elements to generate a customized process for a project. Furthermore, we know that the definition of a software process is a complex activity that requires much experience and knowledge of many areas and disciplines of software engineering. Our main research question is thus related to: how a software organization can reuse existing software processes by rapidly and automatically allowing their customization for new projects? On the other hand, there is recent research work that proposes languages and approaches to address the modeling and execution of software processes. Many of them explore the adoption of model-driven engineering techniques to support the process modeling. There is a strong need to promote not only the processes modeling but also provides mechanisms to support their effective execution. Workflow systems are a well-known approach that allows the effective execution of processes. However, current research work has not addressed the development of approaches that allow the process definition, deployment and execution in an integrated way. In this paper, we propose an approach that supports: (i) the variability management of software processes; (ii) the automatic product derivation of customized specifications of software processes; and (iii) the automatic transformation of these customized software processes to workflow specifications, which can be deployed and executed in existing workflow engines. Our approach is founded on the principles and techniques of software product lines [3] and model-driven engineering [4]. In order to evaluate the approach feasibility, we have implemented it using several model-driven technologies. The software processes are specified using Eclipse Process Framework (EPF). The variability management and product derivation of software processes has been implemented as an extension of an existing product line tool, called GenArch [5]. Finally, ATL and Acceleo [6] transformation languages are adopted to transform EPF process to jPDL workflow language specifications in order to enable the deployment and execution of software processes in the JBoss BPM workflow engine. The remainder of this paper is organized as follows. Section 2 presents existing research work on software processes reuse by identifying several challenges in the variability management of software processes. Section 3 gives an overview of the main elements and functionalities of our approach. Section 4 describes the approach implementation using existing model-driven technologies. Section 5 compares our approach to existing related work. Finally, Section 6 presents the conclusions and points out future work directions.

2 Software Process Reuse Over the last years, several approaches have been proposed that explore the development of software product lines (SPLs) [3]. The main aim of these approaches is to maximize reuse and minimize costs by promoting the identification and management of commonalities and variabilities (common and variable features) of software families. Software product line engineering promotes the effective reuse of software artifacts based on the organization of similar artifacts according to commonalities and variabilities [7]. A common and flexible architecture is designed to address the commonalities and variabilities of the SPL. Finally, a set of reusable assets is implemented following the SPL architecture. After the design and implementation of the SPL architecture and code assets, which is called domain engineering, new applications (products) can be easily derived by reusing and customizing the code assets developed for the SPL architecture. Currently, there are some existing tools, such as Gears [8], pure::variants [9] and GenArch [5], which automate the derivation of new applications/products from existing code assets. They facilitate the streamline selection, composition and configuration of code assets. In the software development process scenario, recent work has been developed to allow the reuse of process assets, in the same way that code assets can be reused. The Eclipse Process Framework [2] is one of these initiatives. It facilitates the definition of software processes using: (i) the Unified Method Architecture (UMA) metamodel; (ii) a supporting tool (EPF Composer [10]); and (iii) content (process asset) that can be used as the basis for a wide range of processes. The EPF Composer allows authoring, configuring and publishing methods. You can add, remove and change process elements according to your team and project needs. In other words, the EPF Composer allows software development processes be extended and customized in a simple way [11]. Rational Method Composer [1] is another existing tool that provides functionalities to the definition and specification of software processes. One important challenge in reuse of software process elements is to do a fast combination of these elements to generate a customized software process. Usually, this customization is necessary to meet specific demands (deadlines, resources, documentation, team experience). The right choices in the software process can guarantee that the team reaches the maximum of efficiency. The software process customization time is included in the overall time for the software development. The lost time at the process customization is lost in the overall software time to market. Although existing process definition tools, such as Eclipse Process Framework and Rational Method Composer, already provide some support to specify, define, and customize software processes, they do not support to the management of process variabilities and automatic customization of existing software processes. The customization of a software process in EPF, for example, is done by editing the process in EPF Composer [2]. In this edition process, the elements of the software process are added, removed and modified, and this is done individually element by element. As a result, this is a tedious and time-consuming process, which strongly influences the time and quality of the process customization. The main disadvantage of existing work is that there is no technique and associated tool that provide support to the automatic customization of software processes allowing the modeling and management of their existing variabilities. Other aspect

that is not explored in existing research work is the explicit support to automatic deployment and execution of software processes. Current efforts for supporting the execution of software processes are disjoint of the efforts for the customization of software development process, even though these efforts are extremely related.

3 A Model-Driven Approach for Process Definition, Customization and Execution In this section, we present an overview of our approach for process definition, customization and execution. It is founded on the principles and techniques of software product lines and model-driven engineering. Figure 1 illustrates the main elements of our approach and their respective relationships. Next we briefly explain the activities of the proposed approach. The first stage of our approach is the software process modeling and definition (steps 1 and 2 in Figure 1). Existing tools such as EPF provides support to address it by using the UMA metamodel. After that, our approach concentrates on the variability management of software process elements. This second stage consists on the creation of a variability model (e.g. feature model) that allows specifying the existing variabilities of a software process (steps 3 and 4). A product derivation tool can then be used to allow the selection of relevant features from an existing software process, thus enabling the automatic derivation of customized specifications of the software process addressing specific scenarios and projects (steps 5 and 6). Finally, our approach supports the automatic transformation of the software process specification to a workflow specification (steps 7 e 8) in order to make possible their deployment and execution in a workflow engine (steps 9 and 10). Through these transformations, the sequence of activities of the process is mapped to a workflow definition. In order to evaluate the feasibility of our approach, we have designed and implemented it using existing and available technologies. Figure 1 also provides an overview of the implementation of our approach. The process specification is supported by EPF composer using the UMA metamodel (step 2 in Figure 1). The variability management of the EPF specifications is addressed by GenArch product derivation tool [12] [13] [14]. This tool was extended to explicitly indicating which variabilities in a feature model are related to different process fragments from an EPF specification (step 4). The tool uses this information to automatically derive customized versions of a software process (step 6). Finally, we have implemented model-to-model transformations (M2M) codified in ATL/QVT [15] to allow the translation of the EPF specification of an automatically customized process to JPDL model elements (step 7). This JPDL specification is then processed by a model-to-text (M2T) transformation implemented using Acceleo language [6] to promote the generation of Java Server Faces (JSF) web forms from a JPDL workflow specification (step 8). These web forms can then be deployed and executed in the JBoss Business Process Management (jBPM) workflow engine. Section 4 describes our approach in action by detailing a customization example of a software process.

Fig. 1. Approach overview

Our approach brings several benefits when compared to other existing research work [16] [7] [17]. First, it promotes the variability management of existing software processes by allowing to explicitly specifying which process fragments (activities, guides, roles, tasks, etc) represent variabilities (optional and alternative) to be chosen and customized when considering specific projects. Second, it allows automatically deriving, deploying and executing software processes in workflow engines by supporting the systematic transformation of process specifications to workflow specifications. Last but not least, the approach is flexible enough to allow the

adoption of process and workflow specifications defined in different languages and notations, as well as to promote the adoption of different tools to process definition, automatic derivation, deployment and execution.

4 Implementing the Model-Driven Approach In this section, we present the approach implementation by exploring the adopted techniques to managing software process variabilities and deploying software processes in workflows engines. 4.1 Managing Variabilities in Software Processes Figure 2 presents a fragment of a case study developed in the context of research and development projects of a technical educational organization [18]. It illustrates three projects of software development, which are: (i) an integrated academic management information system, called SIGA; (ii) a professional and technological education information system, called SIEP; and (iii) an enterprise system development project, called PDSC. Each project used a customized version of the OpenUP process [2]. The detailed analysis of these OpenUP customizations allowed us identifying and modeling the commonalities and variabilities of this process family. Due to restriction space, in this paper we only focus on the project management discipline. SIGA

SIEP

PDSC

Fig. 2. Fragment of study case result

Figure 2 presents the details of the plan project task of the project management discipline. Some steps of this task were performed in every project – the

commonalities, such as: (i) establish a cohesive team; (ii) forecast project velocity and duration; (iii) outline project lifecycle; and (iv) plan deployment. Some steps can be executed or not (optional features), such as: (i) evaluate risks; (ii) estimate project size; and (iii) establish costs and articulated value. Some steps include the use of specific artefacts, which should demand the change of original document template provided by the OpenUP (alternative features). Examples of such alternative templates are: (i) risk list template – that can be top 10 or full list; and (ii) project plan template – that can be specified using the Redmine or MS-Project tools. Figure 3 shows the correspondent feature model for this fragment of the project management discipline. The variability management in a software process is based on the used representation notation. One of most cited notation is the SPEM [19], an initiative of the OMG. In our work, we have adopted an evolution of SPEM, called Unified Method Architecture – UMA [20], which is supported by the Eclipse Process Framework – EPF [20]. EPF was used to specify a software process line that models a family of processes that shares common and variable features. The software process line maintains all the process elements that can be found in any process to be customized from it. It allows systematically reusing common process content elements and fragments of existing software processes.

Fig. 3. Feature model for the case study

The variability management of the software process line is supported by a product derivation tool. This tool enables us to relate variability models (e.g. feature models)

to the process content elements. This is a similar strategy adopted by existing product derivation tools to manage the variabilities of software product lines. In our approach, we have adapted an existing product derivation tool, called GenArch, to support the variability management of software process lines. The original implementation of GenArch provides three models: (i) feature model – that represents the commonalities and variabilities; (ii) architecture model – that represents all the code assets implemented for a software product line; and (iii) configuration model – that defines the mapping between features and code assets in order to enable the automatic product derivation. To enable the usage of GenArch in the software process line context, we replaced our architecture model by the EPF process model. It allows specifying how specific variabilities (optional and alternative features) from a feature model are mapped to existing elements from a process specification. Figure 5(A) shows an example of the variability management of process lines for project management process activities. As we can see, the feature model is used to indicate the optional, alternative and mandatory features of an existing process line. The configuration model defines the mapping of these features to process elements. The complete configuration model is automatically produced from feature variabilities annotations that are inserted in the EPF process specification. Each file of the EPF specification that corresponds to an identified feature is edited, and a XML comment is inserted. This XML comment indicates the name and the type of the associated feature. Figure 4 shows an example of feature annotation inside the Assess_Result activity from an EPF specification. As we can see, each annotation defines the name (Assess_Result), parent (tasks) and type (optional) of the feature that the related artifact represents.

Fig. 4. Feature annotation in an EPF specification

The following process variabilities have been found in the process line case study that we have modeled and specified: (i) optional and alternative activities in process workflows; (ii) optional and alternative steps from process activities; (iii) optional and alternative specification templates for any specific tool or activity; and (iv) optional and alternative technology developer guides that provides principles and guidelines to adopt specific technologies (CASE tools, modelling and programming languages, API libraries, components and frameworks, and so on). Besides, we are currently exploring fine-grained variabilities (parameters, variables, text portions) that can occur as part of the descriptions of process activities and steps.

Fig. 5. Approach implementation

After specifying the mapping between variabilities specified in the feature model to the process elements from an EPF specification, GenArch tool can automatically derive customized versions of a software process line. This stage is similar to what is called product derivation [21] in software product line approaches. During the process derivation, the process engineer chooses the desired variabilities (optional and alternative features) in a feature model editor. Next, the GenArch tool processes the mappings specified in the configuration model to decide which process elements will remain in the final customized process according to the variabilities selection. Resolution of feature constraints and process component dependencies are also computed by the tool during this step of process customization. Finally, after all this processing, the tool is responsible to produce the only EPF specification that represents a customized process to be adopted by a specific project. After the feature selection, the Genarch can be used to generate a new process that makes sense in the features selected in the feature model. Figure 5(B) illustrates two examples of feature selection (configuration1, configuration2) that are processed by GenArch tool to produce two different set of project management activities for specific projects (SIGA, SIEP, and PDSC). The strategy for annotating XMI files representing software processes did not cover all the necessary elements to the complete variability management of the OpenUP process family. This happens because some features presented in the OpenUP delivery process are represented and specified as small pieces of XML specifications inside the EPF specification files. It impairs to mark the complete XMI files as related to a specific process variability using GenArch annotations. To solve this problem, we adopted the fragment mechanism provided by GenArch product derivation tool. A fragment is as a piece of text in a code asset (source code, configuration file, process description file) that is related to specific variabilities. Each fragment is explicitly specified in the XML file, represented in the architecture model, and related to specific features in the configuration file. Each fragment is included in a specific process during the automatic derivation stage, only if it is related to process variabilities explicitly selected. In our work, existing dependencies between software processes elements were specified in EPF. The usage of fragments was required in this context, because the dependencies between process elements in EPF specifications is spread and tangled along different XML files that specify the complete process. Additional details about the implementation of the fragment mechanisms can be found in [22] [18]. 4.2 Deploying and Executing a Software Process in a Workflow Engine Nowadays, organizations are investing in information technology to support their processes. With this increasing need to control and improve processes, we include the concept of Business Process Management (BPM), which in essence is the union of resources in information technology to the analysis of business management focused on improving business processes. Our approach allows automatically deploying and executing a customized software process automatically derived by GenArch in the jBPM workflow engine. jBPM [23] is a framework of JBoss that allows the creation of business solutions based on

business processes using graphical notations and graph-oriented programming. It also provides a workflow engine. We use the jBPM engine to run and monitor software process activities, which were previously defined in EPF process specification and customized by GenArch tool. In our approach, we have implemented transformations that automatically convert the EPF process to the jPDL workflow specification language. This language is used to specify business processes graphically in terms of tasks, wait states, timers, automated actions, and so on. This model-to-model transformation was implemented using the ATLAS Transformation Language (ATL) inside the Eclipse platform. ATL is an implementation of the QVT (Query/Views /Transformations) transformation language [15], which is the OMG's standard language for expressing queries, views and transformations on MOF models. Figure 5(C) shows how an EPF customized specification produced as result of the variability management of the process line can be automatically translated to jPDL workflow specifications. It can be observed that some activities (ex.: “plan project” and “request change”) are present in both textual and graphical jPDL specification. Table 1. Mapping between UMA to jPDL element. UMA

jPDL

Activity Workorder Activities with more than one predecessor Activities with more than one successor Activity without predecessor Activity without successor Task Step

Task-node Transition Join Fork Start-state End-state Task-node Task

Table 1 presents the mapping of the UMA process elements to jPDL workflow elements implemented by our QVT transformation. The generated elements in jPDL model are need to generate the jPDL specification files, which are then installed in the workflow engine to support the workflow execution. The generated jPDL model enables the definition of a jPDL workflow specification and the creation of Java Server Faces forms implementations to monitor the process flow. This monitoring functionality is responsible to store information about the tasks and or decisions taken during the process execution. In order to generate a process definition archive, in jPDL schema, and the related JSF forms for the jPDL workflow specification, we implemented a model-to-text transformation using Acceleo [6]. This is a code generation tool that allows transforming models to code. We also generated the “forms.xml” file, which is a XML file that matches each specific task node to a JSF form. All of these files were generated in a jPDL Eclipse project. Through of simple configurations, this project can be deployed in the jBPM workflow engine. Figure 6 presents a fragment of the jPDL process definition file. It is essential to the workflow deployment and execution in the workflow engine. We can see that each workflow element represents an element of the process specification, and they are organized in the same order specified in the process specification. This process

specification file, the JSF pages and the forms.xml configuration file defines the complete software process to be deployed and execute in the workflow engine. After the deployment of the process workflow in the jBPM engine, the user can request the start of a new instance of the process. Figure 5(D) shows the result of the deployment of the process previously customized and generated by GenArch tool. When starting the execution of a new instance of the process, the user can visualize the actual state of the specific process – that presents details of the activity that have to be done. After the execution of each activity, the user notifies the workflow engine that requests the user to enter some information about the activity in a specific JFS form. All the information is stored in a specific database, related to the process instance. Finally, the workflow engine shows that a new activity is now required. All these steps are repeated for each activity until the end of the process, when the end state of the workflow is reached.

Fig. 6. Fragment of the generated jPDL process definition file

5 Related Work In this section, we present some recent research work that are related to process reuse or propose the adoption of software product line techniques to enable the automatic management, reuse and customization of software processes. Additionally, we also point out existing research work that proposes the deployment and execution of process workflows. We can observe that existing research work do not propose automated and integrated approaches that provides support to the variability management, customization, deployment and execution of software processes.

Rombach [7] presents the first studies to describe the term Software Process Line. His proposal suggests the organization of families of similar processes. It has been applied in small domains and points out the feasibility of applying this approach in more general contexts. However, his work does not define any approach or tools to effectively promote the reuse of software processes. Xu et al [17] present a definition of a standardized representation and retrieval of process components. The focus is on: (i) the specific components organization of a process and its representation; and (ii) the recovery process definition based on the reuse of existing components. The main drawback of their approach is that it requires high expertise for the representation and retrieval of components. Barreto et al [16] propose an approach to the componentization of legacy software processes. Their strategy aims to facilitate the achievement of expected results for maturity models. This work states that make processes reusable is a costly task, because many different situations must be provided and addressed by components and features. The work is restricted to the definition of reusable process fragments, and it does not propose any automation for the effective reuse and variability management. Bendraou et al [24] propose the creation of a model for implementation of processes, called UML4SPM. This model is based on UML and the process implementation is done using a meta-programming language, called Kermeta, that allows its implementation without any compilation. The main drawback of this work is that it does provide an environment for the deployment of processes workflow, thus allowing their execution and monitoring. Bendraou et al [25] presents an approach based on model-driven engineering, which includes the mapping between two languages UML4SPM and WS-BPEL. Each language operates in a different perspective: definition of software processes and process execution, respectively. The rationale for this choice was that both languages have their strengths, both in the modeling as in the proposed implementation. The transformation between process models and workflow was defined by a program written directly in Java language. Our work has a strong relationship with this proposed work because we also propose an approach to process definition and execution. One of the main difference is that our work motivates: (i) the process definition using abstractions from the UMA metamodel; and (ii) the process execution using workflow engine, such as the jBPM. We believe that the existing design of our approach allows evolving the process definition and execution technologies in an independent way. For example, we can migrate our approach to work with other existing workflow engines. Another difference between our work and the presented by Bendraou et al [25] is that we provide transformations that allow the generation of effective source web forms that are installed and running on a workflow system. Maciel et al [26] defines a model-based approach that allows the modeling of software processes. This approach is based on Model-Driven Architecture (MDA) technology and adopts a series of standard technologies (OMG SPEM 2.0, UML 2.0, MDA). The main focus of this work is specifying elements of MDA processes. However, the approach does not address process variability management and does not involve a complete process transformation to execution in workflow systems.

6 Conclusions and Future Work In this paper, we presented a model-driven approach to managing and customizing software processes variabilities. Our approach also provides support to the deployment and execution of the customized process in a workflow engine. The approach has been implemented and validated using existing model-driven and software product line technologies. The main benefits of our approach are: (i) the variability management of software processes that directly contributes to productivity improvement when producing customized software processes to related projects; and (ii) the integration and automation of the process definition, customization, deployment and execution. Additionally, our approach has been designed in a flexible way that allows its easy adaptation to deal with new technologies. For example, new process or workflow specification languages can be adopted to specify process or workflows, respectively. Additionally, our approach can be used to implement different model-driven technologies. During the development and validation of the proposed approach with a initial case study, we have found and observed important technical issues and lessons learned that are important to the refinement of our research work. Next, we present and discuss some of them. Process Mapping in Workflow Specifications. Our approach defines an explicit mapping between process models and workflow specifications through the model-tomodel and model-to-text transformations. Different elements and abstractions of process models EPF were directly mapped to representations in workflow specifications in both level as description and implementation of web forms, which could then be installed to run the process in the workflow engine jBPM. Different relevant information can be generated within web forms, in accordance with the wishes of process engineer. Although already offering support for mapping and implementation of various information (date/time, start and end states of implementation, current status, buttons upload or links to artifacts generated), our approach needs to be further refined to allow during the transforming process the interaction with the process engineer to choose parameters and specific configuration options for implementing their process. Workflow Code Integration with Software Engineering Tools. Our approach allows the currently generation of different forms web JSF that can be installed and executing directly into jBPM. Information concerning the implementation of the process is informed by such forms and are automatically persisted by jBPM. Currently, the approach is being refined to allow integration with other systems external to obtain relevant information to track process execution. One of the integrations we currently exploring obtains information directly from a configuration management system and version control systems about artifacts being submitted directly to the repository. This allows the workflow process to obtain updated information regarding the execution of processes. The jBPM engine offers the possibility of extending the workflows code for realize external calls (via web services) to other external systems. Management of Variabilities in Software Processes. Our model-driven approach for the process variability management based on manual annotation of the process assets (XMI files) has succeeded to modularize the process variabilities and to achieve its intended goals in our case study. The creation of fragments was another

mechanism that helped us to deal with the management of fine-grained variabilities in existing XMI files. Despite the benefits brought by both annotation and fragment mechanisms to the process variability management, we noticed that it is essential to complement them with visual support focused on the use of techniques and composition mechanisms of model-driven engineering. We are currently exploring in a new implementation of the approach, the adoption of different model-driven strategies to support a better management of the dependencies between different process elements (activities, tasks, artifacts, guides). In our case study, we observed that many dependencies between process elements, can bring serious difficult to their specification using the annotation and fragment mechanisms. Those mechanisms provide an adequate low-level persistence support to the variability management and process derivation, but they are not an adequate mechanism to be used by the process engineer. Our proposal is to complement them using more high-level domain-specific modeling languages that contributes to the specification of the process variabilities. We also intend to compare and analyze the complementarities of such different mechanisms. As a future work, we also intend to apply and evaluate our approach to more extensive and complex software process customization scenarios. We are currently refining the approach to apply it in an industrial scenario of a company that defines and reuses its processes using the Rational Unified Processes (RUP) framework. Additional details about the approach and its implementation can be found in [18].

Acknowledgements This work was supported partially by Brazilian Research Council (CNPq) under grants: No. 313064/2009-1, No. 552010/2009-0, and No. 480978/2008-5.

References 1. IBM. (2010) IBM - RUP. [Online]. http://www-01.ibm.com/software/awdtools/rmc 2. EPF Project. (2009) Eclipse Process Framework Project (EPF). [Online]. http://www.eclipse.org/epf/ 3. K Pohl, G Bockle, and F Van der Linden, Software Product Line Engineering: Foundations, Principles and Techniques. New Yourk: Springer Berlin/Heidelberg, 2005. 4. Anneke G. Kleppe, Jos B. Warmer, and Wim Bast, MDA Explained: The Model Driven Architecture: Pratice and Promisse.: Addison-Wesley, 2003. 5. GenArch Plugin. (2009) A model-based Product Line Derivation Tool. [Online]. http://www.teccomm.les.inf.puc-rio.br/genarch/ 6. OBEO. (2009) Acceleo. [Online]. http://www.acceleo.org/pages/home/en 7. Dieter Rombach, "Integrated Software Process and Product Lines," in Unifying the Software Process Spectrum. Berlin / Heidelberg: Springer, 2005, pp. 83-90. 8. Gear/BigLever Software. (2009) Software Product Lines – Pragmatic Innovation from BigLever Software. [Online]. http://www.biglever.com

9. Pure:Variants. (2009) [Online]. http://www.pure-systems.com 10. Eclipse Foundation. (2010) Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview. [Online]. http://www.eclipse.org/epf/composer_architecture/ 11. Peter Haumer. (2007) Eclipse Process Framework Composer:Part 1: Key Concepts. [Online]. http://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf 12. Elder Cirilo, Uira Kulesza, and Carlos Lucena, "A Product Derivation Tool Based on Model-Driven Tecniques an Annotations," Journal of Universal Computer Science, vol. 14, 2008. 13. Elder Cirilo, Uirá Kulesza, Roberta Coelho, Carlos J.P. Lucena, and Arndt von Staa, "Integrating Component and Product Lines," in ICSR, 2008b. 14. Elder Cirilo, Uirá Kulesza, and Carlos J. P. Lucena, "Automatic Derivation of Spring-OSGi based Web Enterprise Applications," in ICEIS, 2009. 15. OMG. (2009) OMG. [Online]. http://www.omg.org/spec/QVT/1.0/ 16. A. S Barreto, L.G.P Murta, and A. R Rocha, Componentizando Processos Legados de Software Visando a Reutilização de Processos, 2009. 17. Ru-Zhi Xu, He Tao, Chu Dong-Sheng, Xue Yun-Jiao, and Quian Le-Qiu, "Reuse-Oriented Process Component Representation and Retrieval," The Fifth International Conference on Computer and Information Technology, no. IEEE, 2005. 18. Fellipe A. Aleixo, Marília A. Freire, Wanderson C. Santos, and Uirá Kulesza. (2010) Software Process Lines. [Online]. http://softwareprocesslines.blogspot.com/ 19. OMG. (2010) Software & Systems Process Engineering Metamodel Specification (SPEM). [Online]. http://www.omg.org/spec/SPEM/2.0/ 20. Eclipse Foundation. (2009) Eclipse. [Online]. http://www.eclipse.org/epf/ 21. Paul Clements, Software Product Lines: Practices and Patterns. Boston: Addison-Wesley, 2002. 22. Fellipe Aleixo, Marília Freire, Wanderson Santos, and Uirá Kulesza, "A Model-Driven Approach to Managing and Customizing Software Process Variabilities," in Proceedings of XXIV Brazilian Symposium on Software Engineering (SBES'2010), Salvador, Brazil, 2010, pp. 50-69. 23. J Hat. (2009) JBPM. [Online]. http://labs.jboss.com/jbossjbpm/ 24. Reda Bendraou, Andrey Sadovykh, Marie-Pierre Gervais, and Xavier Blanc, "Software Process Mode and Execution: The UML4SPM to WS-BPEL Approach," in 33rd EUROMICRO Conference SEAA, 2007. 25. Reda Bendraou, Jean-Marc Jezéquél, and Franck Fleurey, "Combining Aspect and Mode Driven Engineering Approaches for Software Process Modeling and Execution," in International Software Process Workshop, Vancouver - Canada, 2009, pp. 148-160. 26. Rita Suzana P. Maciel, Bruno C. da Silva, Ana Patrícia F. Magalhães, and Nelson S. Rosa, "An Integrated Approach for Model Driven Process Modeling and Enactment," in XXIII Brazilian Symposium on Software Engineering, 2009.