-This paper presents an experimental evaluation of the methodology documentation template proposed by the IEEE FIPA Design Process Documentation and Fragmentation working group [1]. Generally aimed at agent-oriented methodologies, the template is here put to the test by documenting the SODA methodology, so as to obtain a partial but significant evaluation of the template's strengths and weaknesses.
While artificial systems grow in complexity, the role of models, methodologies and development processes in their engineering becomes increasingly relevant. In the field of computational systems, AOSE (Agent-Oriented Software Engineering) methodologies and processes are research subjects of foremost interest since agent-based models and technologies are nowadays recognised as providing one of the most suitable approaches to the engineering of complex software systems such as self-organising and pervasive systems.
There is common agreement both in the traditional software
engineering and in the AOSE fields that there is not a unique
methodology or process that fits all the application domains
[
A variety of (special-purpose) AOSE methodologies have
been defined in the past years [
Although it is possible to describe a methodology / process without an explicit documentation, formalising its underpinning ideas is valuable for checking consistency, or when planning extensions or modifications: there, a formal documentation can be exploited to check both the software development process and the completeness and expressiveness of methodologies. More generally, the relevance of documentation becomes clear when studying the completeness and the expressiveness of a methodology / process, and when comparing / integrating different methodologies / processes together.
In this context, the IEEE FIPA Design Process
Documentation and Fragmentation (DPDF) working group [
Accordingly, the paper is structured as follows. Section II briefly presents the IEEE FIPA DPDF template, while Section III presents some excerpts from the SODA documentation. Then, Section IV discusses the template’s strengths and weaknesses identified during the creation of the SODA documentation. Conclusions are reported in Section V. II. PROCESS DOCUMENTATION TEMPLATE IN A NUTSHELL
The IEEE FIPA DPDF working group has recently proposed a template for documenting AO methodologies and processes. This template takes into account the three aforementioned methodology features—meta-model, notation, and process. In the first place, the template has been conceived with no reference to any particular methodology—which should guarantee that all methodologies can be documented using the proposed template. Moreover, the template is also neutral regarding the meta-model and/or the modelling notation adopted in the description of the the methodology.
Secondly, the template has a simple structure resembling a tree—see above for further details. This implies that the documentation can be built up in a natural and progressive way, addressing in first place the general description and meta-model definition – which constitute the root elements of the methodology –, subsequently detailing the branches 1.Introduction 1.1.The (process name) Process lifecycle 1.2.The (process name) Metamodel 1.2.1. Definition of MAS metamodel elements 2.Phases of the (process name) Process 2.1.(First) Phase 2.1.1.Process roles 2.1.2.Activity Details 2.1.3.Work Products 2.2 (Second) Phase 2.2.1.Process roles 2.2.2.Activity Details 2.2.3.Work Products : : : (further phases) : : : 3.Work Product Dependencies representing the phases. Next, thinner branches like activities or sub-activities have to be described. As a result, the template can in principle support complex methodologies and different situations.
In the third place, the use of the template is easy for a
software engineer as it relies on few assumptions. Moreover,
the notation suggested is the OMG’s standard Software
Process Engineering Metamodel (SPEM) [
So, in the remainder of this section, we only report a brief
presentation of the template—interested readers can refer to
[
The template schema reported in Table I introduces the
fundamental components of the process model definition. The
template has a structure that provides a natural decomposition
of the process elements in a tree-like structure, whose root
is the Introduction section, which includes a description of
the process lifecycle and the MAS metamodel. Introduction
tries to provide a general overview of the process detailing the
original objectives of the methodology, its intended domain of
application, its scope, limits and constraints (if any), etc. The
Metamodel part provides a complete description of the MAS
metamodel adopted in the process, along with the definitions
of its composing elements. Thus, the different conceptual
elements considered when modelling the system should be
identified and described. The attention to the MAS metamodel
is not new in the agent-oriented community, and it is also
coherent with the emerging model-driven approaches, which are
always based on the system metamodel. The methodology’s
process is supposed to be composed (from the
work-to-bedone point of view) by phases. Each phase is composed of
activities that, in turn, may be composed of other activities or
tasks. Such a structure is compliant to the SPEM specification
that 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 focusses on the modeling notation adopted by the methodology 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.
This section presents only the main excerpts from the
SODA documentation—interested readers can find the full
documentation at [
SODA (Societies in Open and Distributed Agent spaces)
[
Layering
The abstractions belonging to the SODA meta-model –
called MAS Meta-model Elements (MMMElements) – [
In addition, since the SODA process (Fig. 1) is iterative,
each step can be repeated several times, by suitably exploiting
the SODA layering mechanism (Fig. 2). The layering in
Fig. 1 is represented as a simple Activity of the process:
actually, it is a capability pattern [
B. Phases of the SODA Process
1) Requirements Analysis: The goal of Requirements
Analysis is to characterise of both the customers’ requirements and
the legacy systems with which the system should interact, as
well as to highlight the relationships among requirements and
legacy systems. The diagram in Fig. 3 presents the
Requirements Analysis activities, each related to its corresponding
task(s) use [
As one could see in Fig. 3, other three activities appear in the diagram – Requirement Layering, Environment Layering, and Relation Layering – and are strictly related – through the predecessor relationship – to the previously described activities. These activities represent the Layering capability pattern since during each activity of this step it is possible to create a new (or, to select a specific) layer for detailing (or abstracting) the specific model under investigation. It is important to note
Requirement Layering tt<<
uopu>> >>tupnZi<<oomingtable >>>r>orsossesceedceerdpe<r<p<< that layerings do not represent an iteration of the step: instead, they refine the model over which they are applied—and are a peculiarity of SODA. The Requirements Analysis iteration is done through the Layering activity located between the Relation Modelling and the Requirements Modelling activities (Fig. 3). The same consideration also applies to the Analysis and Architectural Design steps.
2) Analysis: The first activity in the Analysis step is Moving from Requirements, where the MMMElements identified in the previous step are mapped onto the MMMElements adopted in this stage to generate the initial version of the Analysis models. The work product of this activity is represented by a set of relational table called Reference Tables depicted in Fig. 4, where the relation between Analysis workproducts and Analysis MMMElements are showed (D means define/instantiate, R means relate, Q means quote/cite, F means refine). In particular, Reference Tables defines (label D in Fig. 4) the Analysis MMMElements and puts them in relation (label R in Fig. 4) with the Requirements Analysis MMMElements.
The Analysis step expresses the requirement representation in terms of more concrete MMMElements such as tasks and functions. Tasks are activities requiring one or more competences and are analysed in the Task analysis activity, while functions are reactive activities aimed at supporting tasks analysed in the Function analysis activity. The structure of the environment, analysed in the Topology analysis activity, is also modelled in terms of topologies—i.e., topological constraints over the environment. The relations highlighted in the previous step are here the starting point for the definition of dependencies among such abstract entities in the Dependency analysis activity.
3) Architectural Design: This stage (Fig. 5) is one of the more complex sub-phases in SODA. The first activity is Transition (Fig. 5), where the MMMElements identified in the previous step are mapped onto the MMMElements adopted in this stage so as to generate the initial version of the Architectural Design models. The main goal is to assign responsibilities for achieving tasks to roles – Role Design activity composed by the Action Design task – and for providing functions to resources—Resource Design activity composed by Operation Design task. In order to attain one or more tasks, a role should be able to perform actions – Role Design activity –; analogously, the resource should be able to execute operations providing one or more functions—Resource Design activity. The topology constraints lead to the definition of spaces, i.e., conceptual places structuring the environment in the Space Design activity. Finally, the dependencies identified in the previous phase become here interactions and rules. Interactions represent the acts of the interaction among roles, among resources and between roles and resources, and are designed in the Interaction Design activity; rules, instead, enable and bound the entities’ behaviour and are designed in the Constraint Design activity.
4) Detailed Design: The Detailed Design step (Fig. 6) is the only stage where the layering principle is not applicable, since its goal is to choose the most adequate representation level for each architectural entity, thus leading to depict one (detailed) design from the several potential alternatives architectures outlined in the previous step. So, as shown in Fig. 6, the first activity of this sub-process is Carving, which represents a sort of boundary between the Architectural Design and the Detailed Design, where the chosen system architecture is “carved out” from all the possible architectures.
The next activity is Mapping (Fig. 6), where the carved MMMElements are mapped onto the MMMElements adopted in this stage, thus generating the initial version of the Detailed Design models. Then, the Detailed Design presents three different activities. The Agent Design activity design the active <<input>> c <<predecesCoro>>nstrainrrcsspdeeeo<<>>t Lay<e<rio<nu<grrsscoeeedp>><<topuu>ttp>u>t> Zoomi<n<ginputt>a>ble Titpun>><<oTpaobloleg>>siyrcamairpl,sAmrofrrDecp<eh<sitiegcnteurral <<predecesor>> <<predecessor>>
<<input>> part of the system in terms of Agent and agent Society. More precisely, agents are intended here as autonomous entities able to play several roles, while a society can be seen as a group of interacting agents and artifacts whose overall behaviour is essentially autonomous and proactive: they are designed during the Agent Design activity.
In the Environment Design activity, the resources identified in the previous step are here mapped onto suitable Artifact, while Aggregate is defined as a group of interacting agents and artifacts whose overall behaviour is essentially functional and reactive.
The Workspace Design activity defines the topology of the environment in terms of Workspaces that take the form of an open set of artifacts and agents: artifacts can be dynamically added to or removed from workspaces, and agents can >>tu<pni<<<predecessor>>>t>upni<<InteracDtieosnigDnetailed <<performs,primary>>
Environ<ment Design <output>> c Environment Design Tables c Environment
Design Tables <<input>> <<input>> InteracDtieosnigDnetailed <<output>> c
,frrsope<<m irryap>>m InteraTctaiobnleDsesign Detailed Designer
c Agent/Society Design Tables dynamically enter (join) or exit workspaces. Finally, during the Interactions Design activity, the interaction are designed in terms of Use – interaction between agents and artifacts –, Manifest – interaction between artifacts and agents –, SpeakTo – interaction among agents – and LinkedTo – interaction among artifacts – MMMElements.
The diagram in Fig. 7 describes the high-level dependencies among the different sets of SODA work products—called composite work products. In fact, due to the huge number of SODA work products – each table represent a work product – it is not possible to create a comprehensive and readable diagram depicting all the work products and their dependencies.
This paper evaluates a template for process documentation that seems to provide a good framework in the documentation of processes for agent-oriented development. However, the current version of the template presents several limitations— some of which related more to the notational language than to the template structure.
The main weakness of the current template structure is
related to the absence of a clear indication of where to describe
the tools and guidance [
The first issue was about the place where to place the layering description. From our experience in developing and explaining SODA, we understood that the layering should be presented before detailing the different SODA’s steps. This because the layering is not a simple mechanism for creating the iteration in the SODA process, but it is also a way for refining single SODA model, so it is largely adopted in the first three steps. Looking at Fig. 3 and Fig. 5, it is possible to see both the layering activity (Layering) that inducting – if necessary – a new iteration of the step and the different layering activities (such as Requirement Layering, Relation Layering, etc.) devoted to the models refinement. The above considerations led us to the definition of a new sub-section in the documentation introduction (TABLE I) where the layering is documented. After our requests for explanations, the right place where the process guidance and mechanisms should be positioned is now under discussion inside the IEEE FIPA DPDF working group.
The second issue coming from the layering documentation is related to the structure of the newly created sub-section. We decided to structure the new sub-section in a very similar way to the structure of the single phases, since the layering has its portion of process, its specific activities and tasks, and obviously its work product. We also created a specific diagram Requirements
Tables Relation Tables c c c Domain Tables Zooming table
c References
Tables c Transitions
Tables c c Responsibilities
Tables Dependencies
Table Topologies Tables
Zooming table c Entities Tables Interactions
Tables c Constraints
Tables
c Topological
Tables Zooming table
c
Mappings
Tables
a
Carving
Diagram
c
c
c
Agent / Society
Design Tables
– like the diagram in Fig. 4 – that puts the Zooming table –
i.e., the layering work product – in relation with the SODA’s
MMMElements, in order to explain how the layering is closely
related to the SODA meta-model [
The last layering issue is related to the SPEM notation.
In fact, the diagrams in Fig. 3 and Fig. 5 are very difficult to
understand due to the huge number of strictly-related activities.
In particular, in Fig. 5 there are six different layering activities
– one for the step iteration and five for the models refinement
– and the only predecessor relation is not powerful enough
for explaining the right flow of activities in the
Architectural Design step—so this diagram alone is not sufficiently
expressive. For instance, the Role Design activity in Fig. 5
is the predecessor of two different and alternative activities,
on the one hand the Role Layering and on the other hand
the Interaction Design. In this diagram, at the best of our
knowledge, there is no way for expressing this alternative.
Even though such an alternative is documented in another
activity diagram (see the SODA documentation at [
This consideration about the SPEM limitation leads to another SPEM issue tied to the work product documentation. In different diagrams such as those presented in Fig. 5 and Fig. 7 we are able to document only the SODA composite work products in order to have readable diagrams. The diagrams proposed by SPEM seems not so suitable for documenting those methodologies which a great number of work products like SODA.
Apart from the weaknesses highlighted above, the template seems very valuable, since it forced us to re-think the way of presenting our methodology. Usually, when discussing a methodology, authors are more worried about identifying the models to construct, the concepts to define, etc. than in detailing the phases and the activities to do, or in defining the order of these activities. Thanks to this template now the authors should pay more attention to process-related aspects.
In addition, a major task of the documentation template
should be to offer a good support for process evaluation and
comparison. When comparing SODA to the other
methodologies documented in [
In this paper, we used IEEE FIPA DPDF template for documenting the SODA design process, and represents an experimental evaluation of the template. SODA proved to be a good test for the template since the creation of the SODA documentation highlighted a weakness in the template structure. The SODA documentation showed the power of the template in process documentation, and sketched some of its benefits briefly comparing SODA to PASSI and INGENIAS.
In addition, the creation of the SODA documentation helped us formalising the SODA process and organising in a proper way the huge number of SODA work products. In particular, diagrams such as those depicted in Fig. 4 proved to be very valuable in relating the SODA work products to the SODA MMMElements. This improved the general SODA understanding—including ours. Finally, the SODA documentation could be considered as the starting point for the SODA fragmentation, since in the future the models produced for the documentation will be used for identifying and documenting fragments. Such fragments will be reused and integrated so as to provide new ways of developing agent-oriented systems.