Process Documentation Standardization: An Initial …

1 Process Documentation standardization : AnInitial EvaluationMassimo Cossentino1, Alma G omez-Rodr guez2, Juan C. Gonz alez-Moreno2,Ambra Molesini3, and Andrea Omicini31 Istituto di Calcolo e Reti ad Alte PrestazioniNational Research Council, Palermo, de Inform atica, Universidade de Vigo, Ourense, Mater Studiorum Universit`a di Bologna, creation of new ad-hoc methodologies through the Sit-uational Method Engineering approach needs the Process fragments tobe defined and available. Thus, it is necessary to previously define andextract such fragments from the global development Process . So, it isimportant to provide the means of documenting the whole Process fromwhich fragments will be obtained. This paper presents an experimen-tal evaluation of the methodologies Documentation template proposedby the IEEE FIPA Design Process Documentation and Fragmentationworking group. The template will be used for documenting three dif-ferent agent-oriented methodologies in order to evaluate the template sstrengths and IntroductionNowadays, in the software engineering field, there is a common agreement aboutthe fact that there is not a unique methodology or Process that fits all the appli-cation domains; this means that the methodology or Process must be adapted tothe particular characteristics of the domain for which the new software is devel-oped.

2 There are two major ways for adapting methodologies: tailoring (partic-ularisation or customisation of a pre-existing processes) or Situational MethodEngineering (SME) [1, 2]. In the last case the Process is assembled from pre-existing components, called fragments, according to user s needs. This approachenhances reusability since a method component can be used several research on SME has become crucial in the Agent-Oriented SoftwareEngineering (AOSE) since a variety of (special-purpose) agent-oriented (AO)methodologies have been defined in the past years [3 7] to discipline and sup-port the multi-agent system (MAS) development. Each of the AO methodologiesproposed up to now exhibits a specific metamodel, notation, and Process . All ofthese features are fundamental for a correct understanding of a methodology,and should be suitably documented for supporting the creation of new ad-hoc29AO methodologies. In fact, the SME technique is strictly related to the docu-mentation of the existing methodologies since the successfully construction ofa new Process is based on the correct integration of different fragments thatshould be well formalized.

3 So, methodologies Documentation should be done ina standard way in order to facilitate the user s understanding, and the adoptionof automatic tools able to interpret the fragment this context, the IEEE FIPA Design Process Documentation and Frag-mentation (DPDF) working group [8] has recently proposed a template for doc-umenting AO methodologies. This template takes into account the three afore-mentioned methodologies features. In first place, it has been conceived withoutconsidering any particular Process or methodology, and this should guaranteethat all processes can be documented using the proposed template. Moreover,the template is also neutral regarding the MAS metamodel and/or the mod-elling notation adopted in describing the Process . Secondly, the template has asimple structure resembling a tree. This implies that the Documentation is builtin a natural and progressive way, addressing the Process general description andmetamodel definition which constitute the root elements of the Process , the Process phases are described as branches of the tree.

4 Finally, thin-ner branches like activities or sub-activities can be documented. This means thetemplate can support complex processes and very different situations. In thirdplace, the use of the template is easy for any software engineer as it relies on veryfew previous assumptions. Moreover, the suggested notation is the OMG s stan-dard Software Process Engineering Metamodel (SPEM) [9] with few extensions[10].So, the goal of this paper is to present an experimental evaluation of theFIPA DPDF template by means of the application of such a template to threedifferent AO methodologies: PASSI [11], INGENIAS [12], andSODA[13].Accordingly, the remainder of the paper is organized as follows. Section 2 pro-vides a brief description of the FIPA DPDF template, while Section 3 presentsthe application of the template to the three chosen AO methodologies. Sec-tion 4 presents some proposals for the improvement of the current version ofthe FIPA template, whereas Section 5 presents a discussion about the resultsobtained by the applicaiton of the template to the Documentation of the threechosen methodologies.

5 Finally, the conclusions of the whole work are reportedin Section Process Documentation Template in a NutshellThe IEEE FIPA DPDF working group has recently proposed a template fordocumenting AO methodologies. Here we report only a brief presentation of thetemplate interested readers can refer to [8] for the details of the template is based on the definition of Process and Process model as pro-posed by [14]. A Process model is supposed to have three basic components: thestakeholders ( roles and workers), the consumed and generated products ( products), and the activities and tasks undertaken during the Process 30these being particular instances ( work definitions) of the work to be important component of the template is the MAS metamodel, as pre-viously considered in [10], because it is thought that the MAS metamodel mayconstrain the way in which fragments can be defined and ( Process name) Process ( Process name) Definition of MAS metamodel of the ( Process name) (First) (Second) (further phases).

6 Product DependenciesTable proposed Process templateThe template schema reported in Table 1 introduces the fundamental com-ponents of the Process model definition. As it can be easily seen, the templatehas a structure that provides a natural decomposition of the Process elementsin a tree-like structure where theIntroduction including a description of theprocess lifecycle and the MAS metamodel is at the root. Introduction is meantto give a general overview of the Process detailing the original objectives ofthe Process /methodology, its intended domain of application, scope, limits andconstraints (if any), etc. TheMetamodelpart provides a complete descriptionof the MAS metamodel adopted in the Process with the definitions of its com-posing elements. This means the different conceptual elements considered whenmodeling the system must be identified and described. The focus on the MASmetamodel is not new in the agent-oriented community, and is also coherentwith the current emphasis on model-driven approaches, which are always basedon the system metamodel.

7 The Process is supposed to be composed from thework-to-be-done point of view by phases. Each phase is composed of activi-ties that, in turn, may be composed of other activities or tasks. This structure iscompliant to the SPEM specification which is explicitly adopted as a part of thistemplate although with some (minor) extensions (see [10]). The next templatepart is represented by several Phase sections, one for each phase composing thewhole Process . The main aim of each phase is to define the phase from a prettyprocess-oriented point of view; that is, workflow, work products and processroles are the center of the discussion. Initially, the phase workflow is introducedby using a SPEM activity diagram which reports the activities composing the31phase, and by doing a quick description of work products and roles. A SPEM diagram follows reporting the structural decomposition of each activity in termsof the involved elements: tasks, roles and work the last section, the template discusses work products with a twofold goal:the first part aims at detailing the information content of each work product byrepresenting which MAS model elements are reported in it (and which operationsare performed on them).

8 The second part focuses on the modeling notationadopted by the Process in the specific work product. The work products aredescribed by using a SPEM work product structured document. This diagramis a structural diagram reporting the main work product(s) delivered by eachphase, and the diagrams are completed by a table that describes the scope ofeach work product. Finally, work product dependencies are reported in a Case StudiesThe next subsections discuss the Documentation of three AO processes (PASSI,INGENIAS, andSODA) using the previously proposed template. In this way,the paper tries to evaluate the suitability of the template for modeling pro-cesses. The validation is significant because the chosen methodologies followdifferent kinds of Process and have significant differences in other composingelements. For space reason, here we report only some excerpts of the method-ologies Documentation the interested reader can found more details in [8].

9 Inparticular, the next subsections present the requirement analysis phase for eachof the three AO methodologies considered in this PASSIPASSI ( Process for Agent Societies Specification and Implementation) is a step-by-step requirement-to-code methodology for designing and developing multi-agent methodology integrates design models and concepts fromboth object oriented software engineering and artificial intelligence PASSI design Process is composed of five models: the System Require-ments Model regards system requirements; the Agent Society Model deals withthe agents involved in the solution in terms of their roles, social interactions,dependencies, and ontology; the Agent Implementation Model is a model of thesolution architecture in terms of classes and methods; the Code Model depictsthe solution at the code level; and the Deployment Model describes the distri-bution of the parts of the the schema proposed in Section 2, Figure 1 summarize the de-scription of the System Requirements phase.

10 In particular, this phase involvestwo different Process roles, eight work products (four UML models and four text4 PASSI Documentation can be found System Requirements activities, work products and stakeholdersdocuments) and four guidance documents (one for each UML model). The phaseis composed of four activities: Domain Requirements Description, Agents Iden-tification, Roles Identification and Task Specification, each of them composedof one or more tasks (for instance Identify Use Cases and Refine Use Cases)and delivering one work product as described by Figure 1. Tasks are under theresponsibility of one or more stakeholders involved with the responsibility toperform or assist in the work to be System Requirements Model generates four composed work products(text documents including diagrams). Their relationships with the MAS meta-model elements (MMM) are described in Figure 2 where the containment rela-tionship between each MMM element and a work product is labelled accordingto the action performed on the element (D means define/instantiate, R meansrelate, Q means quote/cite, RF means refine).