This work presents a way to describe GORMAS, an AgentOriented Software Engineering methodology, using the template proposed by the FIPA Design Process Documentation and Fragmentation Working Group. This template uses SPEM 2.0 notation and it is aimed at identifying the fragments of each process, in order to extract and reuse them in some different processes.
When developing Multi-Agent Systems (MAS), designers should be provided
with methodologies and design processes that can help them to achieve
welldesigned systems. In the last years, the community of Agent-Oriented Software
Engineering (AOSE) researchers has proposed several methods (see [
To give support in these topics, the IEEE FIPA Design Process
Documentation and Fragmentation working group1 (IEEE FIPA DPDF WG) is working
on providing a solution in terms of a shared and easily adoptable specification
for the documentation of the design process and of the process fragment. More
in details, this working group aims to propose a definition of method fragment
to be used during a situational method engineering process, the fundamental
elements of which it is composed, and the metamodel on which it is based. The
first step (currently undergoing) is the identification of the most suitable
metamodel and notation for the process: (i) for the representation of the existing
design processes from which the fragments have to be extracted; and (ii) for
the representation of fragments themselves. This step will outcome in the
definition of a proper template for the description of agent-oriented design processes.
Such a template will, obviously, refer to the selected process metamodel and
will suggest the adoption of good practices in documenting existing processes as
well as defining new ones. The final step will be the definition of the Method
Fragment Structure and Documentation Template. This template claims the
authors to use SPEM 2.0 notation to describe their processes, in order to achieve a
standardization. Currently, this FIPA group is working on specifications of the
following methodologies: ADELFE [
This paper describes an application of the FIPA DPDF WG template to a specific MAS methodology. The main objective of this work is to describe the GORMAS methodology by means of the template proposed by the IEEE FIPA Design Process Documentation and Fragmentation working group. By using this template, we are looking to achieve the following: – To facilitate the knowledge and diffusion of the GORMAS methodology by using a standardized description of the process. – To make an assessment of the possibilities that the proposed template offers, evaluating its advantages and the changes that the document could need. – To establish the fragments of the GORMAS process, that can be reused to improve other proposed processes.
The rest of this work is organized as follows. Section 2 describes the FIPA DPDF WG template. Section 3 gives an example of using the template with the GORMAS process. Section 4 presents a discussion on the proposed template. Finally, section 5 gives our conclusions on this work. 2
In the same way that the Unified Modeling Language (UML) [
The design process documentation template proposed in this specification
is also particularly relevant to researchers and practitioners working on
Situational Method Engineering (SME) [
The proposed template is suitable for process definition, since it has been conceived without referring to any specific process or methodology. Moreover, the template has a simple structure resembling a tree. This allows the definition to be given in a natural and progressive way. The proposed documentation is composed of three main sections (Introduction, Phases of the Process, and Work Product Dependencies). The Introduction section contains an overview of the process and a description of the metamodel used on it. The second section is split into as many subsections as phases that the process has. Every subsection contains a description of the activities executed in that phase, the roles that are involved into it and the work products that will be generated in this phase.
Finally, the template allows presumably easy use by process designers with
a background on software engineering. It relies only on a few initial assumptions
common in the field. Moreover, the notation suggested for documenting the
process is the SPEM [
The next section uses this template for the GORMAS methodology. 3
The GORMAS methodology was completely described using the DPDF WG
proposed template. This description can be found in a technical report [
GORMAS (Guidelines for ORganizational Multi-Agent Systems) defines a set of activities for the analysis and design of Virtual Organizations, including the design of their organizational structure and their dynamics. With this method, 2 http://www.dsic.upv.es/docs/bib-dig/informes/etd-05182010-133045/ GORMASTechRep.pdf all services offered and required by the Virtual Organization are clearly defined, as well as its internal structure and the norms that govern its behavior.
GORMAS is based on a specific method for designing human organizations
by Moreno-Luz´on et al. [
The proposed guideline allows being integrated into a development process of
complete software, which may include the phases of analysis, design,
implementation, installation and maintenance of MAS. GORMAS methodology is focused
on the analysis and design processes, and it is composed of four phases (see Fig.
1), covering the analysis and design of a MAS: first phase is mission analysis,
that involves the analysis of the system requirements, the use cases, the
stakeholders and the global goals of the system; the service analysis phase specifies
the services offered by the organization to its clients, as well as its behavior,
and the relationships between these services; the organizational design phase
defines the structure for the Virtual Organization, establishing the relationships
and restrictions that exist in the system; and finally, at the organization
dynamics design phase, communicative processes between agents are established,
as well as processes that control the acquisition of roles along with processes that
enable controlling the flow of agents entering and leaving the organization.
Additionally, some norms that are used to control the system are defined. Finally,
the organization dynamics design phase is responsible of designing guides that
establish a suitable reward system for the organization. Implementation is
carried out in the THOMAS [
This methodology allows designing large scale, open and service-oriented
MAS, where organizations are able to accept external agents into them. In order
to model this kind of systems, GORMAS is supported by a CASE tool named
EMFGormas [
The Mission Analysis phase, the first of the GORMAS methodology, involves the analysis of the system requirements, identifying the use cases, the stakeholders and the global goals of the system. This phase involves two different process roles, four work products (one model diagram and three text documents) and one guidance document, as described in figure 2. This phase is composed of five activities. The process flow at the level of activities is reported in figure 3.
As a result of the activities carried out in this phase, a diagram of the Functional Dimension Model is drawn, detailing the products and services offered by the system, the global goals (mission) pursued, the stakeholders, the existing links between them, the system results and the resources or services needed.
Fig. 3. Activity diagram of Mission Analysis phase Process roles. There are two roles involved in the Mission Analysis phase: the System Analyst and the Domain Expert. The System Analyst is responsible for: (i) defining the mission and the context of the organization, by means of identifying the system results, the stakeholders and the environment of the organization; (ii) creating the documents that define the mission of the system; and (iii) defining the Functional Dimension Model diagram. The Domain Expert is responsible of supporting the system analyst during the Mission Analysis phase, by giving him all the information that he could need.
Activity details. In the Mission Analysis phase, the following concepts are defined: – The global goals of the system (mission). – The services and products that the system provides to other entities. – The stakeholders with whom the system contacts (clients or suppliers of resources/services), describing their needs and requirements. – The conditions of the environment or context in which the organization exists (i.e. complexity, diversity, restrictions, etc.). – The justification of the existence of the MAS system that it is being designed, in order to look that the GORMAS definition on a MAS could contribute on defining an organization.
In order to identify all these items, five activities are needed, detailed in table 1. These activities are aimed at looking for the system mission, by means of: (i) identifying the organization results; (ii) identifying the stakeholders; and (iii) identifying the environment conditions. Moreover, global goals of the system are described. Finally, it is necessary to justify whether the GORMAS approach for creating organizations is suitable for the current problem under study. Activity Activity Description Roles Involved Identify organiza- Describe the results (products or services) that the system System analyst tion results provides, to understand what the result is, what it does and and domain who is interested in. expert Identify stakehold- Identify and describe the main stakeholders that the orga- System analyst ers nization is related to (external actors, clients, users, etc.) and domain expert Identify environ- Identify and define the kind of environment in which the System analyst ment conditions organization will be developed, knowing if it is a physical and domain environment or a virtual environment; if it is a distributed expert environment, etc.
Define the System Identify the global goals pursued by the system. These goals System analyst Mission compose the mission of the organization. and domain expert Justify the MAS sys- Justify the existence of this kind of system, comparing it to System analyst tem other existing similar systems (that can use agents or not), and analyzing the advantages and disadvantages, and the singularities of the proposed system. Work products. The following section describes the products generated on the Mission Analysis phase. Firstly, the Functional Dimension Model diagram is defined, and three documents, related to organizational mission, stakeholders and environment conditions are generated (see table 2).
Fig. 4 describes their relation with the elements of the GORMAS metamodel
[
Organizational Mis- A document describing the basic aspects of the organization Structured text sion that will be defined.
Stakeholders A document describing the stakeholders that will take part Structured text in the organization.
Environment condi- A document describing the conditions that the environment Structured text tions of the organization will have.
Organizational Mission. This document is employed to define the mission of the organization. It is a structured text document, whose template is shown in
Stakeholders. This document is employed to describe the stakeholders of the organization, that have been defined in the Organizational Mission document. It is also a structured text document, whose template is shown in table 4. The identification of the stakeholders must be completed by providing the kind of stakeholder, the objectives that each group follows, their products and services provided and required, the benefits obtained by them and their position into the organization.
Stakeholders Name An identifier for the stakeholder Beneficiary Indicate if the stakeholder is a primary (essential) or a secondary beneficiary. Type Indicate if the stakeholder is a client, a provider or a regulator. Objectives Describe the objectives pursued by the stakeholder.
Requires A set of products and/or services that the stakeholder consume. Provides A set of products and/or services that the stakeholder offers to the organization. Frequency To point out if this stakeholder contacts the organization frequently, occasionally or in an established period of time.
Benefits Describe the benefits that the stakeholder wants to achieve.
Decision power Indicate if their needs are affecting to the requirements of products or services. Under the influ- Indicate if the organization can affect the interests of the stakeholder. ence of the system? Contribution To point out what the organization obtains for its relationship with stakeholders.
Environment conditions. This document is employed to describe the environmental conditions in which the organization will be placed. It is a structured text document, whose template is shown in table 5. This document analyzes five conditions: the change rate, the complexity, the uncertainty, the receptivity and the diversity of an environment.
Environment conditions Change rate: Are the stakeholders constants through time? Are their requirements constants? Are they modified in a cyclical and a predictable way? Is it possible to estimate the consumption of a product? Is the demand of a product or a service constant through time? If the answer is affirmative, the environment is stable. If not, it is an unstable or dynamic environment. Complexity: Is there a lot of different elements? Are there a lot of clients? Are there a lot of types of products and services to offer? Are there a lot of types of providers? Are providers not related between them? If any of the answers is affirmative, the environment is complex. If not, it is a simple environment.
Uncertainty: If the environment is dynamic and complex, uncertainty is high. If the environment is stable and simple, uncertainty is low.
Receptivity: Are the inputs and resources available? Are they obtained in an easy and secure way? If the answer is affirmative, the environment is munificent. If not, it is an hostile environment. Diversity: Are different groups of clients served? Is it provided a set of different products or services, with no relationship between them? If any of the answers is affirmative, the environment is diverse. If not, it is a uniform environment. tionality of the system, based on services, tasks and goals, as well as system interactions. Figure 5 shows an example of a Functional Dimension Model diagram. An Organizational Unit representing the system (UPV), as well as the stakeholders (Students, Governing organs and Teachers), the objectives pursued by the organization (’Efficient management of the financial resources’, ’Increase scientific production’), the products (Databases and Bills) and the services (Budget mnt. and PhD mnt.) of the system are defined on this diagram. posed template. On the one hand, the advantages found during this work are: – This template allows describing a development process using a standard language like SPEM 2.0. The use of a standard will improve the comparison of GORMAS with other methodologies. – The phases of the GORMAS methodology were clearly depicted in its original definition. Therefore, a correct fragmentation of the process was easily obtained after applying the template to GORMAS. – The metamodel used by the GORMAS methodology has its own section inside the template, providing a clear and easy-reading description of it. – The activities developed inside every phase of GORMAS can be easily defined. Therefore, the methodology is not only described in an overview, but in a detailed way. – The work products are described and an example is given. Additionally, their evolution during the whole process is shown and their dependencies. – The roles participating in the process are identified and the activities that they are responsible for are identified. – Several tables are used in order to improve the identification of some elements such as the work products and the activities of the methodology.
On the other hand, these are the disadvantages of this template: – The Phases of the process section of the template describes the functionality of every phase by means of its activities, and the tasks composing each activity. Activities are provided with a deeper description than tasks. However, in the Organizational Dynamics Design phase of our example, tasks are more important than activities as they contain the most relevant information related to this phase. In order to solve this problem, we defined the tasks of Organizational Dynamics Design phase using the best possible way that the template guidelines allowed us, by means of descriptive tables. Designers should be allowed to describe tasks in a similar way to activities, i.e. with a similar deep description, so as to achieve the desired level of detail in every phase of a process. – The template has not a discussion nor conclusion section. It can be very useful to add a section like this, in order to provide developers with the possibility of remarking or pointing out some features that could be considered as important. Additionally, a section describing guidance documents can be very interesting, in which work products were described. – The template provides a deep and detailed description of a design process, but it does not include a ’light view’ of the process. This feature reduces the focus of possible future readers, that will be mainly bounded to process designers and developers. – The adaptation of a methodology from its classic representation to the representation proposed by the template must be done by a human. That is, we must know how to deal with human errors, that could make a methodology not to be properly translated to the structure of the template.
As seen, there are more interesting advantages than disadvantages on using this template. The use of a well-known standard graphic language such as SPEM 2.0 drives the methodologies to a better understanding of their processes and approaching them to the standardization. Moreover, the usage of this template will improve the task of identifying and extracting the fragments of a methodology. These fragments will be available for the rest of the AOSE community, that would use them to improve their existing methodologies or to create new design processes based on a compilation of these fragments.
Possibly, the main lack of AOSE is a standard methodology. Using this template, all the methodologies will adopt the same structure, allowing the authors to compare them to test every feature of the processes, in order to find which is the methodology that best solves a concrete problem. After this analysis, there will be possible to define a methodology, taking the best from the existing methodologies, that could be considered as a standard. 5
This work presents the template to describe an AOSE methodology proposed by the IEEE FIPA DPDF WG. As an example, the GORMAS methodology, used to describe Virtual Organizations, was described using this template. After using this template over a concrete design process, it becomes expressed in a standard notation such as SPEM 2.0 and their fragments are identified. In our concrete example, GORMAS became properly translated into the structure of the template. Nevertheless, there could be some methodologies whose adaptation to the template is harder. As a conclusion, we can state that the template allows to describe a methodology in a proper way and it is recommended to adopt it to improve the understanding and study of the design processes. Acknowledgments. This work is supported by TIN2009-13839-C03-01, TIN2008-04446 and PROMETEO/2008/051 projects of the Spanish government and CONSOLIDER-INGENIO 2010 under grant CSD2007-00022.