• Aucun résultat trouvé

F/oss Process Reference Model

5.1. FOSS-PRM MODEL 57

Figure5.3:ConceptualMapofCorePRMArtifacts

58 CHAPTER 5. F/OSS PROCESS REFERENCE MODEL

Project

The Project PRM Artifact provides information needed to describe aF/OSSproject. A Projectp gathers community memberspA⊆Actor around a given set of topicspTo⊆Topicin order to provide a goal represented as a set of functionalitiespF. For instance in the case of aF/OSSproject such as OpenOf-fice.org the functionalities which are put forward may be the ones indicating that the project provides a word processor, a spreadsheet, and so on, while the topics inform Actors that the project is related to an office software suite. Projects can have a parent Project and multiple sub-Projects. Table5.8summarizes Project’s Attributes list.

Attribute Name Attribute Type Description

name Text Project’s name

acronym Text Project’s acronym

description Text Project’s description

contact Actor Contact Actor for the Project topics PTopic Topics the Project is working on

url Url URL of the Project

parentProject Project Parent Projects of the Project subProjects PProject sub-Projects of the Project

Table 5.8: Project Artifact Attributes

Activity

Each F/OSS Project involves a collection of Activities. As stated before, common F/OSS activities include Community Management, Metrics Management, Rights Management, Projects Management, Distribution Management, Production Management, Defects Management, Testing Management or De-pendency Management, Process Management and Task Management.

Figure 5.4: PRM Interactions

AF/OSSActivity indicates how the Artifacts it is responsible for can be handled. It defines the means which have to be provided by their implementations, making sure that required information is available

5.1. FOSS-PRM MODEL 59 and retrievable. These means are represented as operations. For instance, the operations provided by the Artifact Management Activity allow to match Artifacts, retrieve them and verify their substitutability .

Activities have to be implemented then their operation be used to handle Artifacts. Figure5.4 illus-trates the interaction of an application with an implementation 1 which interacts with two other activity implementations 2 and 3.

The set of Activities of aF/OSSProjectpis notedpAc. Each activityacprovides a set of operations acO. A single operation λ∈O of the interface ac is then noted ac.λ. Each operation can take an Artifacts Directory as parameter, and can return a Directory of Artifacts.

The attributes of the Activity Artifact are listed in Table 5.9. Note that Directoryλ,PIntegrityRule

indicates a Directory containing an operationλalong with an associated set of integrity rules.

Attribute Name Attribute Type Description

name Text Integrity Rule name

description Text Activity description

topics PTopic Topics the Activity is related to

operations PDirectoryλ,PIntegrityRule the set of operations provided by the Activity

Table 5.9: Activity Artifact Attributes

The PRM includes a set of core Activities providing all necessary means to provide the minimal set of operations on top of which otherF/OSSActivities can be built. These Activities include Community Management, in order to handle contributors, Project Management in order to create and handle Projects, to define rights and obligations of contributors in the scope of existing Projects, Events Management in order to enable asynchronous communication, Metrics Management for measurement as well as an Activity for Activity Management itself.

Further, the PRM provides a means for adding new Activities and remove them through thedeclare andremoveoperations. These operations make available the Activity, and thus related operations, to PRM users in the scope of a Project and thus ensures the evolvability of Projects through the addition of new Activities. Related operations are further discussed in the next section.

Integrity Rule

For each operation of each declared activity, the PRM can define Integrity Rules. These rules ensure that the Activity and resources used within the activity do not endanger theF/OSSProcess. They ensure thus the correctness and integrity of the behavior of each operation. Multiple Integrity Rules can be associated with these operations. The attributes of the Integrity Rule Artifact are listed in Table5.10

Attribute Name Attribute Type Description

name Text Integrity Rule name

description Text Integrity Rule description

topics PTopic Topics the Integrity Rule is related to

operation λ Operation to which the Integrity Rule is bound rule IntegrityRuleExpression Expression of the Integrity Rule

Table 5.10: Integrity Rule Artifact Attributes

An integrity rule ir is an Artifact including an expression irexpr which is a first class object and defines the rule to be enforced. Enforcement is done prior to the execution of the operation. Associating ir to an operationλof an Activityacresults in the verification ofir each timeac.λis called.

60 CHAPTER 5. F/OSS PROCESS REFERENCE MODEL The set of integrity rules forac.λis notedac.λIR. Whenac.λis called, eachir ∈ac.λIRmust be enforced. If anyir fails, the operation call is canceled.

Note that Integrity Rules can also be associated to Artifact types. In such a case, the Integrity Rule is checked at Artifact instantiation.

Right

Multiple Actors can interact with each Activity, each having specific responsibilities. ControllingF/OSS

Activities’ usage is mandatory in order to be able to better understand the whole F/OSS Process, to be able to coordinate activities, refine Actors’ responsibilities and thus be able to highlight workflows, analyze them, streamline theF/OSSprocess.

Thus, for security reasons, some behavior must be restricted and only allowed to authorized com-munity members. It is thus mandatory to have a way to declare in the scope of a Project who is allowed to do what and then be able to easily retrieve such information and handle it.

The Right PRM Artifact aims at describing how Actors can behave in the scope of each Activity. As the rules and constraints related to rights management may differ depending on the Project, Rights are generic and expressed in function of PRM operations. A Right defines which operations an Actor can triggerif he receives the express authorization - the Right- to do itand the concrete context (represented by a Task Artifact, which is presented in a further section) in which they can be called.

Rights declaration, assignment, revocation as well as verification are handled through a set of oper-ations which are described in the next section. Table5.11summarizes Right’s Artifact attributes.

Attribute Name Attribute Type Description

Task Task Task in the scope of which a Right can be used activity Activity Activity for which the Right is valid

operation λ operation for which the Right is valid extensionOf DirectoryRight The Right

Table 5.11: Right Artifact Attributes

The PRM does not only provides a means to express Rights, it also provides full support for Rights management, from Community members registration to Rights assignment.

Process

The interactions with the PRM are a sequence of calls to the different Activity operations provided by Projects. These sequences are described using the Process Artifact. The Process Artifact indicates thus how users have to interact with the PRM to reach a goal. This allows to have different Process descriptions which can be exchanged by projects.

The structure of the process is formalized in figure 5.5. A Processπ is a series of calls, to any Activity operationac.λpassing a directoryD of parameters. These calls can be organized as a graph, containing loops and conditions and each of them returns a valuev as an Artifact Directory. Further a Process can be executed a given nuber of times (n), 0 or multiple times () or at least one time (+).

Processes can be executed in parallel. To synchronize them, Events are used. The waiting process can wait for a Event type through theobserveoperation, and other processes can raise an Event of this type through theraiseoperation of the Event management Activity. Events and related operations are described later in this chapter.

The requirements of a processπof a Projectp are defined by Actorsa∈pA, which are responsible for process definition. The requirements are expressed as an Artifact Directory notedπD. It represents