Default Profile Change Request: Activity Parameters
Table of Contents
1. Introduction 4
2. References 4
3. Design Requirements 4
4. Design Constraints 4
5. Issues 4
5.1 Specifying parameters for an Activity is very difficult 4
5.1.1 Description 4
6. Considered Approaches 4
6.1 Preferred Approach - Add class ActivityParameter to the metamodel 4
6.1.1 Description 4
6.1.2 Pros 5
6.1.3 Cons 5
6.2 Alternate Approach 1 Include the Parameters in an Activity attribute 5
6.2.1 Description 5
6.2.2 Pros 5
6.2.3 Cons 5
6.3 Alternate Approach 2 Expand the class VariabilityPointBinding 5
6.3.1 Description 5
6.3.2 Pros 6
6.3.3 Cons 6
7. Design Artifacts 6
7.1 Figure 1 6
7.2 Figure 2 7
7.3 Figure 3 7
7.4 Example 1 8
8. Future Considerations 9
9. Draft Reviews Threads 9
1. Introduction
This document describes the issues the RAS Aurora Program development team has experienced while trying to write tooling to effectively exploit the activity element in the RAS default profile. It also contains a proposal to help alleviate these issues.
2. References
· Reusable Asset Specification(04-06-06.pdf)
3. Design Requirements
· Provide a mechanism to easily associate parameters with an activity
· Concretely define the relationship between activities and their parameters at the metamodel level
4. Design Constraints
· Require only minor changes to the current default profile metamodel
5. Issues
5.1 Specifying parameters for an Activity is very difficult
5.1.1 Description
It’s quite common to include asset or artifact activities in a RAS manifest that are interrogated by clients during some part of the asset’s lifecycle. Often the activity requires additional pieces of information that’s used by the client to help execute the activity in one manner or another during processing. For example, IBM’s Eclipse based RAS implementation provides an activity to build a deployable project that’s processed during asset packaging. The RAS manifest author has the option to build that project with or without source and package the binaries in different formats. In today’s default profile metamodel, there doesn’t appear to be a clear, simple way to specify the options. Ideally the metamodel should provide a way to express the parameters for an activity in an unambiguous way. Below are a few approaches we considered including a preferred approach to resolving this issue. We are open to other suggestions as well.
6. Considered Approaches
6.1 Preferred Approach - Add class ActivityParameter to the metamodel
6.1.1 Description
Our preferred approach is to add a new class called ActivityParameter to the metamodel for the default profile that extends the class Descriptor. This new class would contain one attribute named defaultValue that would provide the ability to specify for the parameter exactly what the name implies
a default value. The name and value attributes inherited from the Descriptor class would provide the mechanism for defining the parameters and their values. See Figure 1 and Example 1.
6.1.2 Pros
· Concretely defines the relationship between activities and their parameters in a clear, straight forward manner.
· Client will not have to interrogate the attributes of other elements to try to determine if they are the parameters for activity.
· The parameters will not have to be included in one of the attributes of the activity.
6.1.3 Cons
· New class and relationships must be added to the metamodel
6.2 Alternate Approach 1 Include the Parameters in an Activity attribute
6.2.1 Description
Include the parameters as part of one of the existing activity attributes. Use special characters to denote the parameters and their values so that they can be specified and accessed by clients.
6.2.2 Pros
· Requires no changes to the current default profile metamodel
6.2.3 Cons
· No clear relationship between the activity and the parameters
· Adds confusing extraneous information to activity attributes that doesn’t apply to the attribute.
· Clients must know which attribute contains the parameters and how to specify/access them
6.3 Alternate Approach 2 Expand the class VariabilityPointBinding
6.3.1 Description
Add a new attribute to the class VariabilityPointBinding. This will provide a way to associate the parameters with the activity using an existing metamodel relationship. See Figure 2 or Figure 3..
6.3.2 Pros
· Requires no new classes to be added to the metamodel
· Provides a mechanism to associate parameters to an activity through an existing relationship.
6.3.3 Cons
· No clear relationship between the activity and the parameters. The binding rules will have to be interrogated to find a particular binding rule and then process it.
· Using the VariabilityPointBinding class for this purpose doesn’t really seem like what the intended purpose is according to the RAS spec. It’s tied to a VariabilityPoint which doesn’t necessarily apply.
· A new attribute must be added to the VariabilityPointBinding class.
7. Design Artifacts
7.1 Figure 1
7.2 Figure 2
7.3 Figure 3
7.4 Example 1
An example expansion of the XML in a RAS manifest for an activity with parameters for the preferred solution:
<artifactActivity artifact="//@solution/@artifact.0">
<activity task="Build Deployable Project" role="com.ibm.xtools.ras.export" taskType="com.ibm.xtools.ras.BuildDeployableProject">
<activityParameter name="includeSource" value="true" defaultValue="false" />
</activity>
</artifactActivity>
Thanks,
Grant
-----------------------------------------------------------
Grant Larsen
STSM
IBM Rational software
Voice: (303) 932-7368
Mobile: (303) 601-1257
Fax: (303) 932-6963
Notes: Grant J Larsen/Denver/IBM
E-mail: gjlarsen@us.ibm.com
RAS FTF add support for Activi.gif
RAS FTF add support for Activi1.gif
RAS FTF add support for Activi2.gif