As defined previously, the PRM model is meant to be generic and extensible. The main reason for this feature being that in the context of totally decentralized information systems such asF/OSS informa-tion systems, there must be a way to extend the process with new activities and integrate them seamlessly with existing elements. These new activities have to be able to handle new types of resources. Multiple questions may arise concerning the operations involved in this new activity, the resources involved, the new resources to be created, the information to be left accessible to other activities or the integration of the activity with existing ones. In this chapter we present first the problems which may be encountered when extending the model if not doing it properly. Then we propose a simple method for extending the PRM model with new Activities and Artifacts, highlighting thedoes and don’ts.
6.1 Extension shelves
While the PRM model provides all needed tools to extend it to handle any activity and resource, multiple problems can occur if additional Activities and Artifacts are not correctly defined.
Scoping A first possible problem is the lack of a clear definition of the purpose of Activities, and of their domain, which can lead to Activity and thus responsibility mixing. Each Activity has to handle one specific domain and provide the resources and operations to achieve this task. The borders with other related activities have thus to be well known and described.
The same problem applies to Artifact definition as Artifacts have to represent a selected resource.
The attributes of each Artifact have to be strictly related to this Artifact and no information should be merged. A clear scoping of Artifacts is needed for information responsibility management and for the ease of information retrieval. If information is mixed, errors or inconsistencies are possible, especially in a totally decentralized environment.
Thus the scoping of Activities and Artifacts must be precisely defined in order not to be too large nor too tight.
Information famine . The goal of an Activity is to provide all needed Information to Activity users through operations as well as to provided all needed means to act in the scope of the Activity. Providing too little information or limited means to use provided information makes the Activity useless as it tempers the ability to interact with it.
Similarly, Artifacts have to provide meaningful and adequate information through their attributes.
Again, a severe lack of information (attributes) can temper the usefulness and usability of an Artifact.
83
84 CHAPTER 6. EXTENDING THE PRM MODEL Imagine for instance an Artifact used to represent Linux content units (or packages) which would lack description information. There would be no use for such an Artifact.
Thus the information famine problem is directly related to the scoping problem seen above as both Activities and Artifacts must provide the information related to the purpose of their existence.
Integration limitation Activities and Artifacts are not meant to be used alone. Activities are supposed to communicate through Processes and Artifacts are meant to be used by other Activities to benefit from existing information.
In this context, a possible problem which may appear when defining these elements is to limit pro-vided information and behaviors to a minimal set the creatorthinksthat it has to be provided, forgetting to externalize information that users, be they Activities of Actorsmay need to access. Again, the ex-ample of Linux content units applies here: not providing dependency information, makes the testing activity unable to do its work as this information is required to evaluate the consistency of a package, by checking the non existence of cyclic dependencies.
Lack of integrity enforcement While providing integrity rules is not mandatory for the PRM to func-tion correctly, the lack of integrity enforcement implies informafunc-tion poorness that may temper the use of both Activities and Artifacts. One of the goals of the PRM is to ensure information integrity. Infor-mation which verifies integrity rules is useful and guarantees its quality. Inversely, inforInfor-mation which has not passed even a single integrity check may be difficult to use in a context where this integrity is mandatory. An example of simple integrity rule is that only content units which have passed all checks can be distributed.
Thus the information that such a rule has been enforced has to be explicit to Activity and Artifact users. It has to guide their choice of PRM elements they are using. Further, for each Activity behavior and each Artifact, an analysis has to be done in order to ensure that in the scope of the element and of its integration with other Activities, no key integrity rule is forgotten.
6.2 Extension method
The previous section highlighted possible problems that may appear if the definition of Activities and Artifacts is inaccurate. This implies that guidelines need to be provided to PRM users to correctly achieve their PRM model extensions and thus avoid further problems. The method to ensure that these extensions handle required and useful information include the steps listed in Table6.1:
Step Description
1. Activity domain definition 2. Activity integration
3. Highlight of Activity dependencies
4. Selection of information provided by the Activity 5. Selection of resources involved in the Activity 6. Selection of Integrity rules
7. Activity refinement
Table 6.1: Steps involved in PRM extension.
Activity domain definition. The initial step of the method consists of the provision of a clear defini-tion of the Activity domain. This definidefini-tion has to indicate the purpose of the Activity along with the
6.3. ADDITIONAL ELEMENTS REGISTRATION 85 behaviors the Activity is supposed to enable and the behaviors which are out of its scope. This definition has thus to provide the background and limits which will help achieving the next steps of the method.
Activity integration Once the definition of the Activity domain is done, the second step consists of integrating the new Activity with other existing and related Activities. The aim of this step is to highlight the information flows existing between the different Activities or which may exist with them. Thus, a fundamental part of this step is to imagine the potential of the new Activity. Projections are needed, then when these information flows are detected, they should be submitted to the contributors of the other Activities, to be sure that the ways communication is predicted is correct and that nothing is missing.
Definition of Activity dependencies . When registering the newly created Activity for a Project, Activity dependencies detected during the previous step must be available for the Project. Then, these dependencies indicate where the information comes from, and thus indicates the integrity rules which have to be enforced. This enables Activity analysis to detect for instance Activity incompatibility which may result from incompatible domains being handled or to detect problems due to incomplete sets of integrity rules, which may involve slight adjustments.
Selection of information provided by the Activity. The information flows which have been high-lighted in the Activity integration part of the method not only help choose the Activities the new Activity is depending on, but also indicate the information which has to be provided to other Activities. Based on this analysis the operations of the Activity have to be selected.
Selection of resources involved in the Activity The different operations provided by an Activity as well as the Activities on which the Activity is dependent suggest the resources to be used, i.e. Artifacts, which are involved in the Activity. Some of these are provided by other Activities, but some resources may have to be provided by the Activity itself. In such a case, corresponding Artifacts have to be defined and correct attributes have to be chosen in order to ensure that all needed information to have a meaningful Artifact is provided. As for Activities, the scope of each Artifact has to be defined as well as the corresponding limits. In general, only information directly bound to the description and use of the Artifact should be set as an attribute.
Selection of integrity Rules The next step consists of choosing adequate integrity rules for both Activ-ity operations and Artifacts. ActivActiv-ity related rules must ensure the integrActiv-ity of the information held and provided by the Activity accordingly to the previously defined domain, and to the various information flows which have been highlighted.
Activity refinement. Once all previous steps are done and the Activity and Artifacts are ready to be registered, the whole Activity should be analyzed again, to be sure that nothing has been forgotten.
6.3 Additional elements registration
Once additional Artifact types and Activities are defined they must be registered for the project which will have to use them. The operation is simple. Each Artifact Type T must be registered using the registerArtifactTypePRM operation and each ActivityAmust be declared using thedeclareActivityPRM operation.
Note that in order to register an Activity Ai if any integrity ruleiri of an operation Ai.λi needs access to an operationAj.λj of an ActivityAj,Aj must be registered first for dependency reasons.
86 CHAPTER 6. EXTENDING THE PRM MODEL