Eclipse Process Framework Reuse Mechanisms
By Byron Harris, OCI Principal Software Engineer
Suppose you work for a software company that asks you to help identify ways to achieve process improvement throughout the various units in the company. Your first step is to identify what the existing processes are. As you do so you may see that while there is a lot in common among processes for the various units, there are numerous differences too. These process variations may be driven by differences in management style, developer's experiences, customers expectations, regulations to comply with, etc., among the units.
In reflecting on how to document the existing processes and process improvements, you might have questions come to mind like:
- In documenting process B that extends aspects of process A, is it possible to avoid duplicating what is common between process A and B?
- If process B excludes certain aspects from process A, can I avoid copying content from A and then removing the excluded portions?
- As improvements are identified in the processes, how can I avoid manually duplicating the common improvements among the units?
- If process B is based on process A, can process B be published in a self-contained manner without the reader also needing to refer to process A?
You could attempt to manage such process variability textually using documents describing the process for each unit. However, it would quickly become error prone and tedious to update common portions of the documents consistently, and to ensure that certain documents do not get updated if process changes do not apply.
Fortunately, the Eclipse Process Framework  can be used to formally capture and publish the various processes in an efficient manner. With EPF's rich set of reuse mechanisms you can define an element in one process that can automatically be reused (or explicitly not reused) in other processes. In many cases, not only can the element be reused, but it can also appear to be altered when used in different contexts.
To help you fully leverage the power of EPF, this article attempts to provide a summary of these reuse mechanisms that you can refer to while authoring process content.
*Note that although the discussion below is geared towards software development, in theory EPF applies to processes in other system engineering domains.
Overview of EPF Composer
While this article does not attempt to introduce EPF Composer in detail, a brief overview of EPF Composer will be given in this section. See  for introductory material on EPF Composer. In addition, the help content for EPF Composer introduces basic concepts and includes tutorials.
EPF Composer is an open source application that provides two major capabilities:
- It allows the capturing of the methods used by your software development team. This include tasks, definitions of work products consumed and produced during the tasks, and guidance for how to perform these tasks. In addition, roles can be defined to identify the skill set necessary to perform these tasks. Capturing these methods helps to ensure that best practices are consistently and uniformly applied during the development process.
- Process engineers can define the lifecycles, milestones, activities, and deliverables used when going from product inception to product deliverable. In addition, method definitions can be referenced and tailored when defining the process.
The method and process content can be then be exported to as pages of HTML for viewing by those enacting processes, or the content can be exported as XML for consumption by other tools. Processes can be exported as Microsoft Project files.
EPF closely follows the Object Management Group's Software & Systems Process Engineering Metamodel  and provides a foundation for IBM's commercial tool Rational Method Composer .
There are numerous process libraries  created using EPF Composer to use and adapt to your needs. Community edited versions of these libraries are published on the EPF Wiki . These libraries include Scrum and XP. In addition, a OpenUP library is provided. OpenUP  is a derivative of the Rational Unified Process that is iterative, agile and suitable for small development teams. It is architecture-centric and focuses on minimizing risk through continuous stakeholder involvement.
*The process model used by EPF is directly maintained in the EPF code base and Java code automatically generated from this model is called by other code in EPF. This model representation and code generation is done using the Eclipse Modeling Framework (). EMF also has the ability to generate diagrams from the model. This feature was leveraged to supplement the discussion below with model diagrams (for simplicity not all associations are included).
Element Physical Containment
An EPF library is the outer most physical container for method and process elements. It in turn contains multiple plug-ins for further organization of the elements. Plug-ins can reference elements in other plug-ins within the same library. Logical partitioning within plug-ins is then done using UML 2 packages. Method elements and process elements are separated in their own packages as shown in the following figure.
Figure 1: Element Containment in EPF
For capturing the intellectual capital behind the methods performed by your software development team, EPF models the following concepts:
- Role Indicates the skills necessary to perform a task.
- Task Defines the steps necessary to perform a repeatable unit of work. Work product inputs and outputs are indicated. Tasks typically take from a few hours to a few days.
- Work Product An abstract concept that represents anything used, modified, or created during a task. Concrete work products include:
- Artifacts A description and definition of a tangible work product. Can be composed of other artifacts.
- Deliverable Specifies other work products that are delivered internally or to a third party.
- Outcome An intangible that represents a result or state.
- Guidance Provides supplemental information for the method content elements. A rich set of concrete guidance types are available. Examples include guidelines, checklists, and supporting material.
- Content Category For creation of navigation views in the published HTML content, content categories can be used for categorization of method content. Standard categories come pre-defined, such as discipline to categorize tasks that are related to a major area of concern or skill set, and domain, which can be used for work product categorization. Custom categorizes can also be defined.
Figure 2: Method Content Model
In addition to managing method content, EPF Composer also allows the management of processes. Some of the key process elements are:
- Activity Used to define nested breakdown structures for capturing the flow of work.
- Capability Pattern Captures process knowledge for a particular area of interest. They can then be used and reused in building delivery processes.
- Delivery Process Represents a template for the process of completing a project.
Figure 3: Process Model
To get an idea of how an EPF element can be reused, consider the example shown in the following figure. In this case Element A exists in plug-in A. A modified form of Element A exists in plug-in B named Element B.
Figure 4: An example of reuse in EPF
In particular, some things to note about the reuse of Element A in this example are:
- Depending on the type of element Element A is, the modification could involve changed attributes or associations, associations added, or associations removed.
- Both Element A and and its modified version can be used in Publication 2.
- Element A can be used in Publication 1 and Publication 2, but not in Publication 3, thus allowing Element A to be filtered when appropriate.
Below we will identify the mechanisms to achieve these types of reuse.
The most obvious and straightforward type of reuse is an element being referred to by multiple elements. For example, a role can be referred to by numerous tasks.
An element in one plug-in can refer to elements in another plug-in. However, it is first necessary to indicate for a plug-in which other plug-ins it can reference. This can be done in the plug-in editor page as shown below.
Figure 5: Selecting plug-in references in EPF Composer
*Note that elements in one library cannot be directly referenced from another library. However, plug-ins from one library can be exported and then one or more of these plug-ins can be imported into another library. If a plug-in that was exported is later modified, it can be re-imported and any referenced elements in the plug-in will be preserved.
When deciding how to partition plug-ins to facilitate reuse, it is important to keep in mind that through method configuration, method elements from multiple plug-ins can be assembled and filtered for usage in processes and publication.
As shown by the configuration model in the figure below, a configuration includes a selection of plug-ins to use. For each plug-in, the packages available in the plug-in can be individually selected. Further refinement is available by selecting the categories to include in the configuration. In addition, you can select categories to subtract from the configuration. This lets you assign elements to a particular category and then explicitly exclude these elements from the configuration.
This configuration capability means, for example, that every task you write in a content category does not need to be accessible along with other tasks in the content category when selecting tasks from this category during process definition.
However, the filtering capability for method configuration runs deeper than just identifying what method content is available for processes or publication. For example, suppose you have a role in Content Package A and a task in Content Package B that refers to this role. If you are using a configuration that uses Content Package B but not A, then the role will not appear in the list of roles for the task. Therefore the associations for the same task can be different depending on the configuration being used. Therefore, as you are partitioning your plug-ins to maximize reuse, keep in mind that it is not an all-or-nothing proposition.
Figure 6: EPF configuration model
Method content is not directly referenced by process breakdown elements. Instead, descriptors are used, which indirectly connect method content with process elements. A descriptor can then be used to modify attributes and relationships of the method element. This allows, for example, a task to be reused during various phases of the process, with modifications made to the task depending on the context in which it is applied.
Figure 7: EPF descriptor model
An example of a descriptor that is a modification of its content element is taken from the OpenUP library. The steps for the plan_iteration task are shown below:
Figure 8: Original content element as basis for descriptor
Now, in the openup_lifecycle delivery process is activity "Plan and Manage Iteration". It has a task descriptor that links to plan_iteration. The steps are identical to plan_iteration's steps, however, step "Prioritize Work Items List" has been removed:
Figure 9: Descriptor that modifies original content
The most elaborate reuse mechanism in EPF is variability. A variability element allows for variation and extension for certain types of elements. Variability is pervasive enough that individual attributes and associations of a base element can be altered without changing the base element itself.
Figure 10: EPF variability model
The different types of variability are discussed below. For more details on variability see EPF Composer's help content, section Creating reusable method content > Method content variability, and the tutorial under Tutorial > Reuse method content.
The variability figures below are based on example elements with one incoming and one outgoing association. The arrows pointing in and pointing out on the left side of an element are used to indicate incoming and outgoing associations, respectively. For examples of these types of associations, consider a role element: If a task references a role as the task's performer, the reference is an incoming association. If the role references a work product as the work products producer, then that reference is an outgoing association.
A contributor adds attributes and associations to the base element. As an example, you may have checklist B in plug-in B that adds items to checklist A in plug-in A. In this case, when published, checklist A will appear to have additional items although it was directly modified in EPF Composer. Checklist B will not be seen in the published content.
A replacer takes over for its base element during publication, so that any instance of the replacer's base element is completely replaced with the replacer. As an example, one Activity for capturing requirements by extracting functional requirements from use cases could be replaced by a requirements gathering Activity based on user stories.
Extends variability allows an element to inherit the attributes and associations from a base element and define additional attributes and associations. Both the extender and base element are published.
Extends and Replaces Variability
Extends and Replaces is similiar to the Extends variability, except any associations to the base element are replaced by the extends-replaces element. One use of this would be to replace some descriptions in the base element without having to duplicate other base element attributes and the base element associations.
-  Eclipse Process Framework
-  Getting Started with EPF
-  Software & Systems Process Engineering Metamodel
-  Rational Method Composer
-  EPF Practices Library Downloads
-  EPF Wiki
-  Introduction to OpenUP
-  Eclipse Modeling Framework Project