Eclipse Process Framework Reuse Mechanisms

Eclipse Process Framework Reuse Mechanisms

By Byron Harris, OCI Principal Software Engineer

January 2012

Introduction

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:

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 [1] 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 [2] 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:

  1. 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.
  2. 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 [3] and provides a foundation for IBM's commercial tool Rational Method Composer [4].

There are numerous process libraries [5] created using EPF Composer to use and adapt to your needs. Community edited versions of these libraries are published on the EPF Wiki [6]. These libraries include Scrum and XP. In addition, a OpenUP library is provided. OpenUP [7] 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 ([8]). 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

Figure 1: Element Containment in EPF

Method Content

For capturing the intellectual capital behind the methods performed by your software development team, EPF models the following concepts:

Figure 2: Method Content Model

Figure 2: Method Content Model

Processes

In addition to managing method content, EPF Composer also allows the management of processes. Some of the key process elements are:

Figure 3: Process Model

Figure 3: Process Model

Reuse Mechanisms

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

Figure 4: Example of Reuse in EPF

In particular, some things to note about the reuse of Element A in this example are:

Below we will identify the mechanisms to achieve these types of reuse.

Element References

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

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.

Method Configuration

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

Figure 6: EPF Configuration Model

Descriptors

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

 
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

Plan Iteration Steps

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

Descriptor Modification

Variability

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

Figure 8: 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.

Contributes Variability

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.

Attributes
  • Non-identifying string values from the contributor are concatenated with the base.
  • Attributes used for identification, such as name, are ignored.
  • Attributes from the contributor that are not strings are ignored.
     
Outgoing associations
  • Contributor's added to the base.
  • If there can be only one association, contributor is ignored.
     
Incoming associations
  • Contributor's added to the base.



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 e

Replaces Variability

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.

Attributes
  • All values, including identifying values and blank values, will be that of the replacer.
Outgoing associations
  • Replacer's associations used instead of the base's associations.
  • If the replacer does not have an association, neither will the resulting element.
Incoming associations
  • Base's associations added to replacer.
Variability Replaces

Extends Variability

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.

Attributes
  • If an attribute for a base element is not defined, then extender's attribute is used.
  • Non-identifying string values in the extender are added to the values in the base.
Outgoing associations
  • Base's added to extender's.
Incoming associations
  • No inheritance.
Variability Extends

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.

Attributes
  • If extends-replaces element defines attributes, then these associations are used.
  • For undefined attributes in the extends-replaces element, then base's associations used.
Outgoing associations
  • If defined for extends-replaces element, then these associations are used.
  • If not defined for extends-replaces element, then base's associations used.
Incoming associations
  • Base's added to extends-replaces element.
Variability Extends and Replaces

References