The creation of new ad-hoc methodologies through the Situational Method Engineering approach needs the process fragments to be defined and available. Thus, it is necessary to previously define and extract such fragments from the global development process. So, it is important to provide the means of documenting the whole process from which fragments will be obtained. This paper presents an experimental evaluation of the methodologies documentation template proposed by the IEEE FIPA Design Process Documentation and Fragmentation working group. The template will be used for documenting three different agent-oriented methodologies in order to evaluate the template's strengths and weaknesses.
Nowadays, in the software engineering field, there is a common agreement about
the fact that there is not a unique methodology or process that fits all the
application domains; this means that the methodology or process must be adapted to
the particular characteristics of the domain for which the new software is
developed. There are two major ways for adapting methodologies: tailoring
(particularisation or customisation of a pre-existing processes) or Situational Method
Engineering (SME) [
The research on SME has become crucial in the Agent-Oriented Software
Engineering (AOSE) since a variety of (special-purpose) agent-oriented (AO)
methodologies have been defined in the past years [
In this context, the IEEE FIPA Design Process Documentation and
Fragmentation (DPDF) working group [
So, the goal of this paper is to present an experimental evaluation of the
FIPA DPDF template by means of the application of such a template to three
different AO methodologies: PASSI [
Accordingly, the remainder of the paper is organized as follows. Section 2 provides a brief description of the FIPA DPDF template, while Section 3 presents the application of the template to the three chosen AO methodologies. Section 4 presents some proposals for the improvement of the current version of the FIPA template, whereas Section 5 presents a discussion about the results obtained by the applicaiton of the template to the documentation of the three chosen methodologies. Finally, the conclusions of the whole work are reported in Section 6. 2
The IEEE FIPA DPDF working group has recently proposed a template for
documenting AO methodologies. Here we report only a brief presentation of the
template—interested readers can refer to [
The template is based on the definition of process and process model as
proposed by [
Table 1. The proposed process template
The template schema reported in Table 1 introduces the fundamental
components of the process model definition. As it can be easily seen, the template
has a structure that provides a natural decomposition of the process elements
in a tree-like structure where the Introduction – including a description of the
process lifecycle and the MAS metamodel – is at the root. Introduction is meant
to give a general overview of the process detailing the original objectives of
the process/methodology, its intended domain of application, scope, limits and
constraints (if any), etc. The Metamodel part provides a complete description
of the MAS metamodel adopted in the process with the definitions of its
composing elements. This means the different conceptual elements considered when
modeling the system must be identified and described. The focus on the MAS
metamodel is not new in the agent-oriented community, and is also coherent
with the current emphasis on model-driven approaches, which are always based
on the system metamodel. The process is supposed to be composed – from the
work-to-be-done point of view – by phases. Each phase is composed of
activities that, in turn, may be composed of other activities or tasks. This structure is
compliant to the SPEM specification which is explicitly adopted as a part of this
template although with some (minor) extensions (see [
In 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 by representing which MAS model elements are reported in it (and which operations are performed on them). The second part focuses on the modeling notation adopted by the process in the specific work product. The work products are described by using a SPEM work product structured document. This diagram is a structural diagram reporting the main work product(s) delivered by each phase, and the diagrams are completed by a table that describes the scope of each work product. Finally, work product dependencies are reported in a specific diagram. 3
The next subsections discuss the documentation of three AO processes (PASSI,
INGENIAS, and SODA) using the previously proposed template. In this way,
the paper tries to evaluate the suitability of the template for modeling
processes. The validation is significant because the chosen methodologies follow
different kinds of process and have significant differences in other composing
elements. For space reason, here we report only some excerpts of the
methodologies documentation—the interested reader can found more details in [
PASSI (Process for Agent Societies Specification and Implementation) is a stepby-step requirement-to-code methodology for designing and developing multiagent societies.4 The methodology integrates design models and concepts from both object oriented software engineering and artificial intelligence approaches.
The PASSI design process is composed of five models: the System Requirements Model regards system requirements; the Agent Society Model deals with the agents involved in the solution in terms of their roles, social interactions, dependencies, and ontology; the Agent Implementation Model is a model of the solution architecture in terms of classes and methods; the Code Model depicts the solution at the code level; and the Deployment Model describes the distribution of the parts of the system.
Following the schema proposed in Section 2, Figure 1 summarize the description of the System Requirements phase. In particular, this phase involves two different process roles, eight work products (four UML models and four text 4 PASSI documentation can be found at http://www.pa.icar.cnr.it/cossentino/ fipa-dpdf-wg/docs/PASSI_SPEM_2_0_ver0.2.8.pdf. documents) and four guidance documents (one for each UML model). The phase is composed of four activities: Domain Requirements Description, Agents Identification, Roles Identification and Task Specification, each of them composed of 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 the responsibility of one or more stakeholders involved with the responsibility to perform or assist in the work to be done.
The System Requirements Model generates four composed work products (text documents including diagrams). Their relationships with the MAS metamodel elements (MMM) are described in Figure 2 where the containment relationship between each MMM element and a work product is labelled according to the action performed on the element (D means define/instantiate, R means relate, Q means quote/cite, RF means refine).
The INGENIAS methodology covers the analysis and design of MAS and is
intended for general use—that is, with no restrictions on application domains.5
The software development process proposed by the methodology is based on
Rational Unified Process [
As discussed above, one of the diagrams proposed in the template relates workproducts to the metamodel elements. In 4, the diagram is used for describing that the INGENIAS organisation models defines (D) the organization of the system and the agents related (R) to this organisation; while goal and role elements are only used (Q) but must have been defined previously. 3.3
SODA (Societies in Open and Distributed Agent spaces) [
a,s Requirement >tsis > p <<prede<cessor>> ni< >tu up p > > > or s redecestuo<< Description <<per <<>t >>t << upni
ent-LegacySystem
Environment Layering<< o utput>> Legacy- <<performs, assist>>
Systems Requirements Description < < o utput>> uo<< t up t >> >> t upn i < < << p e ro f rm s ,a s sist> > LegacySystemRelation Table
Leg Actor Relation LegacySystem
In particular, the Requirements Analysis step involves three different process roles, nine work products (relational tables). The step is composed of three normal activities and four layering activities: the normal are Requirements Modelling, Relations Modelling, Environment Modelling, while the layering are Requirement Layering, Relation Layering, Environment Layering, and Layering. Tasks are under the responsibility of one or more roles involved with the responsibility to perform or assist in the work to be done.
Figure 6 reports only an excerpt of the Requirements Analysis documents
structure. In SODA the work products are represented as relational tables
organized in different sets. In particular, the diagram in Figure 6 reports the
Requirements Tables set. This set describes the system requirements in terms of
Requirement and Actor concepts of the SODA’s metamodel: each table has a
specific relationships with one or more MAS metamodel elements. For example,
the Actor table and the Requirement table define (D) [
During the application of the FIPA DPDF template to the three methodologies, we collected some important feedbacks on its effectiveness. Most of them will be discussed in the next section as an assessment of the work done, whereas a couple are now proposed in terms of proposals for the improvement of the FIPA DPDF template.
The first issue concerns the absence in the template of a clear indication of
where to describe the techniques and guidances [
In order to manage the above issues we created a new sub-section in the template introduction (Table 1); this is like the description of the single phases, since the layering technique has a portion of process with its specific activities and tasks, and obviously its work products. The proposed change perfectly suits the need for introducing the layering technique before the description of the details of the process and the structure of the section is flexible enough to fit similar needs arising in other processes.
Another limit we found in the FIPA DPDF template is the lack of a
specification for detailing the content of a task. Activities are decomposed – or better
decomposable according to the needs – in tasks in section 2.1.2 (see Section 2) of
the template but this may not be general enough. What about the description
of quite a complex task? SPEM provides the method engineer with the
opportunity to use the Step element for decomposing tasks. It is worth to remind that –
according to SPEM specification [
Actually, the FIPA DPDF template specification document [
- Roles involved.
Optionally, the control flow within a Task can be illustrated by a stereotyped UML Activity Diagram. These diagrams explain the execution of complicated Tasks by denoting the possible sequences of Steps, which are identified by the << steps >> stereotype. Details on this modeling of Tasks can be found in the current SPEM specification.
When documenting a Task in this way, the diagrams are appended and each diagram is discussed in a separated paragraph that explains the illustrated steps and theirx relations.
Table 2. The activity description section in the current FIPA DPDF template The FIPA DPDF template already prescribes the possibility to detail tasks by using steps in forms of activity diagrams, however it does not give any hint on how to document them. In order to improve the template, we propose to introduce a new optional subsection in each activity description section as depicted in Table 3.
As an example of such an extension, the decomposition of the INGENIAS Identify Environment Application task is presented in Table 4. The activity diagram depicting the workflow is omitted because of space concerns and also because the steps are performed one after the other in a simple way. 4.1.2.1.1 Decomposition of Task x of Activity 1 GOAL: Describe the work to be done within Task x of Activity 1.
STRUCTURE: The workflow may be depicted by using an activity diagram reporting the steps to be done within the task.
Details of steps are specified with a table reporting the following columns: - Activity: name of the activity the task studied in this subsection belongs to. - Task: name of the task detailed in this subsection. - Step: name of the Step described in this row of the table - Step Description: plain text describing the work to be done within this step. - Roles involved: roles involved in executing this step.
Table 3. The proposed extension to the FIPA DPDF template for a detailed
description of tasks decomposition in steps.
This paper evaluates a template for process documentation that seems to provide
a good framework in the documentation of processes for AO development. This
template is based on an approach similar to the one proposed by Rumbaugh
[
In particular, the figures show the flow of activities, the work products and the stakeholders of the first phase of each methodology. By analysing the figures, it is easy to understand the specific flow of activities and tasks to be followed when using the methodologies. On the other hand, the diagrams highlight the differences among the three methodologies such as for instance the different attention paid to the environment modelling. This is a primary activity in SODA, a task in INGENIAS, while PASSI delays the study of the environment to the next phase. Another difference regards the identification of roles and agents: this is done in the first phase of the process in PASSI and INGENIAS, whereas SODA defines the same abstractions only in the design phase.
An important feature of the template is the attention paid to the MAS metamodel adopted in the process. Such a feature provides an interesting point in methodological comparison. For instance, from the comparison of the documentations produced in this study, we easily deduce that INGENIAS (Figure 4) has a reduced set of models, which however are quite complex since each of them includes many concepts. On the other hand, PASSI and SODA – Figures 2, 6 – have respectively more diagrams and tables, but each of them introduces only a few concepts. The use of the template easily supports the identification of such differences.
Furthermore, in the template, the MAS metamodel elements and their
relationships are also related with work products depicting them—see respectively
Figures 2, 4, and 6. Considering work products as a part of the process is
fundamental for fragment definition and usage, as long as, the user must take into
account the desirable results for selecting a fragment or she/he must consider
what inputs are needed before it is possible to initiate a phase or an activity of
the process. Moreover, the definition of different processes for several
methodologies using this template – see also [
As previously discussed, we point out several benefits in using the proposed template. First of all, the template makes it easier to understand the process workflow, and also produces a documentation that may help in studying it. Moreover, it seems evident that it will be easier to study a new methodology when this new one is documented with an already known approach. For instance, PASSI and SODA metamodels are different in the content – different elements, concepts and models – but the similar description approach largely allows for an easy identification and study of differences between them.
Another important benefit of defining the process is that it provides a starting point for fragments extraction, and therefore for process elements reuse. The reuse would start by identifying fragments considering, for instance, as a starting point the work products produced by the fragment. The template provides diagrams that facilitate the identification. For instance the work products dependencies diagram makes it possible to introduce an order in the work products obtained. On the other hand, the diagrams detailing the activities identify the input and output work products of each task. All such information should be considered when defining a fragment.
Some limitations where noticed when documenting the processes. One issue is related to the SPEM notation: the presence of the layering activities in SODA leads to the construction of diagrams that are very difficult to understand due to the huge number of strictly-related activities. In particular, in Figure 5 there are four different layering activities – one for the iteration and three for the models refinement –, and the only predecessor relation is not powerful enough for explaining the right flow of activities in the Requirements Analysis phase—so this diagram alone is not sufficiently expressive. In this diagram, at the best of our knowledge, there is no way for expressing too many information in a clear way. The problem mainly arises in SODA because of the adoption of the layering technique but generally speaking it may regard other methodologies. The essence of the problem is deeply relied to the SPEM notation and we have not solved this problem yet; we plan to find alternative solutions in the future.
Some other minor problems have arisen when documenting the processes. These problems are more related with identifying specific details of the process from available documentation rather than with the template itself. Usually, when defining a methodology authors are more worried about identifying the models to construct, the concepts to define, etc. than in detailing phases and activities to be done or in indicating the order of these activities. In some way, the adoption of the template would force the designer for a new methodology to produce a complete specification thus improving the quality of the result. 6
In this paper we used the FIPA DPDF template for documenting three different AO design processes. Documentation of processes has many advantages such as: comparing and evaluating methodologies in an easy way, simplifying fragment definition and selection, and so on. This work has demonstrated the power of the template in process documentation, and sketched some of its advantages. Nevertheless, it has been made available to the scientific community, so that other processes and/or other methodologies may be defined used the template.
This work is an initial step toward the definition of a standard for fragment documentation, extraction and use. This means that in the future the models produced for these methodologies will be used for identifying and documenting fragments. The fragments will then be reused and integrated so as to provide new ways of developing AO systems. Besides, although all this work has been done within the frame of AO development, we guess that the template could be general enough to define methodologies in other fields of development. Further work should be done to prove such a statement. 7
This work has been partially supported by the project Novos entornos colaborativos para o ensino supported by Xunta de Galicia with grant 08SIN009305PR and by the FRASI project of the Italian Ministry of Education and Research (MIUR).