It is currently admitted in mainstream software engineering and agent oriented software engineering that there is no one-size-fit-all methodology or process. Indeed, as stated in [6] "traditional rigid IS engineering methods are inadequate to provide the necessary support in new IS developments. New methods, more flexible and better adaptable to the situation of every IS development project, must be constructed".
One possible solution is based on the situational method engineering paradigm [5]. This latter provides means for constructing ad-hoc software engineering processes following an approach based on the reuse of portions of existing design processes, the so-called method fragments, stored in a repository called method base.
The Foundation for Intelligent Physical Agents (FIPA) is part of the IEEE Computer Society and promotes agent-based technology and interoperability of its standards with other technology. Among the current existing FIPA subgroups, the Design Process Documentation and Fragmentation (DPDF) working group aims at proposing a definition of method fragment to be used during a situational method engineering process, the fundamental elements it is composed of and the metamodel it is based on.
The result of the work of the working group members is the definition of a template in order to document method fragments [8]. This paper illustrates the use of this template for a specific methodology, namely aspecs1 [1].
The paper structure respects the FIPA DPDF template. Section 2 introduces aspecs with its global process and the metamodel which defines the underlying concepts of the methodology. After this initial section, the FIPA DPDF template contains a section per phase of the methodological process. Due to the lack of space, only a part of the first phase of aspecs is described in Section 3. Eventually, Section 4 concludes.
2 Documented introduction to ASPECS
The aspecs life cycle consists of three phases that are explained below and illustrated by Figure 1. It is not very different from typical iterative processes. Each iteration (through a phase) refine previous ones. The System Requirements phase aims at identifying a hierarchy of organisations, whose global behaviour may fulfil the system requirements under the chosen perspective. It starts with a Domain Requirements Description activity where requirements are identified by using classical techniques such as use case driven functional analysis. Domain knowledge and vocabulary associated to the problem domain are then collected and explicitly described in the Problem Ontology Description activity. Then, requirements are associated to newly defined organisations. Each organisation will therefore be responsible for exhibiting a behaviour that fulfils the requirements it is responsible for. This activity is called Organisation Identification and it produces an initial hierarchy of organisations that it is later extended and updated, with further iterations, in order to obtain the global organisation hierarchy representing the system structure and behaviour. The behaviour of each organisation is realised by a set of interacting roles whose goals consist in contributing to the fulfilment of (a part of) the requirements of the organisation within which they are defined. In order to design modular and reusable organisation models, roles are specified without making any assumptions on the structure of the agent that may play them. To meet this objective, the concept of capacity has been introduced. A capacity is an abstract description of a know-how, i.e. a competence of a role. Each role requires certain skills to define its behaviour and these skills are modelled by capacities. Besides, an entity that wants to play a role has to be able to provide a concrete realisation for all the capacities required by the role. Finally, the last step of the system requirements phase is the capacity identification activity. It aims at determining the capacities required by each role.
The second phase is the Agent Society Design phase that aims at designing a society of agents whose global behaviour is able to provide an effective solution to the problem described in the previous phase and to satisfy associated requirements. The objective is to provide a model in terms of social interactions and dependencies among entities (holons and agents). Previously identified elements such as ontology, roles and interactions, are now refined from the social point of view (interactions, dependencies, constraints, etc). At the end of this design phase, the hierarchical organisation structure is mapped into a holarchy (hierarchy of holons) in charge of realising the expected behaviours. Each of the previously identified organisations is instantiated in form of groups. Corresponding roles are then associated to holons or agents. This last activity also aims at describing the various rules that govern the decision-making process performed inside composed holons as well as the holons' dynamics in the system (creation of a new holon, recruitment of members, etc). All of these elements are finally merged to obtain the complete set of holons involved in the solution.
The third and last phase (that may be decomposed in two sub-phases), namely Implementation and Deployment firstly aims at implementing the agent-oriented solution designed in the previous phase by deploying it to the chosen implementation platform, in our case, Janus [4]. Secondly, it aims at detailing how to deploy the application over various computational nodes. Based on Janus, the implementation phase details activities that allow the description of the solution architecture and the production of associated source code and tests. It also deals with the solution reusability by encouraging the adoption of patterns. The code reuse activity aims at integrating the code of these patterns and adapting the source code of previous applications inside the new one. It is worth to note that system developed by using other platforms can be designed as well with the described process. This phase ends with the description of the deployment configuration; it also details how the previously developed application will be concretely deployed; this includes studying distribution aspects, holons physical location(s) and their relationships with external devices and resources. This activity also describes how to perform the integration of parts of the application that have been designed and developed by using other modelling approaches (i.e. object-oriented ones) with parts designed with aspecs.
The Problem Domain metamodel (see Figure 2), describing the concepts of the first phase, includes elements that are used to catch the problem requirements and perform their initial analysis: Requirements (both functional and non-functional) are related to the organisation that fulfils them. An organisation is composed of Roles, which are interacting within scenarios while executing their Role plans. An organisation has a context that is described by an ontology. Roles participate to the achievement of their organisation goals by means of their behaviours and capacities. In this subsection we will discuss the three most important elements of this domain: organisation, role, capacity. Definitions of all aspecs metamodels can be found in [1] and on the aspecs website2 .
An organisation is defined by a collection of roles that take part in systematic institutionalised patterns of interactions with other roles in a common context. This context consists in a shared knowledge, social rules/norms, social feelings, and it is defined according to an ontology. The aim of an organisation is to fulfil some requirements. An organisation can be seen as a tool to decompose a system, and it is structured as an aggregate of several disjoint partitions. Each organisation aggregates several roles and it may itself be decomposed into suborganisations.
In our approach, a Role defines an expected behaviour as a set of role tasks ordered by a plan, and a set of rights and obligations in the organisation context. The goal of each Role is to contribute to the fulfilment of (a part of) the requirements of the organisation within which it is defined.
In order to cope with the need of modelling system boundaries and system interactions with the external environment, we introduced two different types of roles: Common Role and Boundary Role. A Common Role is located inside the designed system and interacts with either Common or Boundary Roles. A Boundary Role is located at the boundary between the system and its environment and it is responsible for interactions happening at this border (i.e. GUI, Database wrappers, etc).
Roles use their capacities for participating to organisational goals fulfilment; a Capacity is a specification of a transformation of a part of the designed system or its environment. This transformation guarantees resulting properties if the system satisfies a set of constraints before the transformation. It may be considered as a specification of the pre-and post-conditions of a goal achievement. This concept is a high level abstraction, which proved to be very useful for modelling a portion of the system capabilities without making any assumption about their implementations as it should be at the initial analysis stage.
A Capacity describes what a behaviour is able to do or what a behaviour may require to be defined. As a consequence, there are two main ways of using this concept:
it can specify the result of some role interactions, and consequently the results that an organisation as a whole may achieve with its behaviour. In this sense, it is possible to say that an organisation may exhibit a capacity. -capacities may also be used to decompose complex role behaviours by abstracting and externalising a part of their tasks into capacities (for instance by delegating these tasks to other roles). In this case the capacity may be considered as a behavioural building block that increases modularity and reusability.
In order to complete the description of the possibilities offered by the application of our definitions of Organisation, Roles and Capacity, let us consider the need of modelling a complex system behaviour. We assume it is possible to decompose it from a functional point of view, and in this way we obtain a set of more finer grained (less complex) behaviours. Depending on the considered level of abstraction, an organisation can be seen either as a unitary behaviour or as a set of interacting behaviours. The concept of organisation is inherently a recursive one [2].
The same duality is also present in the concept of holon as it will be shown later in this article. Both are often illustrated by the same analogy: the composition of the human body. The human body, from a certain point of view, can be seen as a single entity with an identity, its own behaviour and personal emotions. Besides, it may also be regarded as a cluster/aggregate of organs, which are themselves made up of cells, and so on. At each level of this composition hierarchy, specific behaviours emerge. The body has an identity and a behaviour that is unique for each individual. Each organ has a specific mission: filtration for kidneys, extraction of oxygen for lungs or blood circulation for the heart.
An organisation is either an aggregation of interacting behaviours, and a single behaviour composing an organisation at an upper level of abstraction; the resulting whole constitutes a hierarchy of behaviours that has specific goals to be met at each level. This recursive definition of organisation will form the basis of the analysis activities performed within aspecs. In most systems, it is somewhat arbitrary as to where we leave off the partitioning and what subsystems we take as elementary (cf. [7, chap. 8]). This remains a pure design choice.
3 Phase: Domain The global objective of the Domain Requirements Description (DRD) activity is gathering needs and expectations of application stake-holders and providing a complete description of the behaviour of the application to be developed. In the proposed approach, these requirements should be described by using the specific language of the application domain and a user perspective. This is usually done by adopting use case diagrams for the description of functional requirements; besides, conventional text annotations are applied to use cases documentation for describing non-functional requirements. In aspecs, we advocate the use of a combination between use-case driven and goal-oriented requirements analysis where the description of functional requirements is completed by the one of associated goals and goal failures. Organisation Identification (OID) The goal of the Organisation Identification activity is to bind each requirement to a global behaviour, embodied by an organisation. Each requirement is then associated to a unique organisation in charge of fulfilling it. As already said, an organisation is defined by a set of roles, their interactions and a common context. The associated context is defined according to a part of the Problem Ontology, described in the previous activity.
Starting from use cases defined in the DRD activity, different approaches could be used to cluster them and identify organisations. We advocate the use of a combination between a structural (or ontological) approach mainly based on the analysis of the problem structure described in the POD and a functional approach based on requirement clustering.
Structural analysis focuses on the identification of the system structure. It is based on the association between use cases and related ontological concepts. In structural organisation identification, use cases that deal with the same ontological concepts are often put together in the same organisation. This approach assumes the same knowledge is probably shared or managed by the different members of the organisation. The structure of the ontology itself can often con- Behavioural analysis aims at identifying a global behaviour for the organisation intended to fulfil the requirements described in the corresponding use case diagram. The set of organisation roles and their interactions have to generate this higher-level behaviour. For this task, the use of Organisational Design Patterns may be useful to the designer. In behavioural organisation identification, use cases dealing with related pieces of the system behaviour are grouped (for instance an use case and another related to it by an include relationship). This means that members of the same organisation share similar goals.
The global objective of the Domain Requirements Description (DRD) activity is gathering needs and expectations of application stake-holders and providing a complete description of the behaviour of the application to be developed. In the proposed approach, these requirements should be described by using the specific language of the application domain and a user perspective. This is usually done by adopting use case diagrams for the description of functional requirements; besides, conventional text annotations are applied to use cases documentation for describing non-functional requirements.
The global objective of the Problem Ontology Description is to provide an overview of the problem domain. Problem ontology is modelled by using a class diagram where concepts, predicates and actions are identified by specific stereotypes. The workproduct of the Organisation Identification activity (OID) refines the use case diagram produced by the DRD activity and add organisations as packages encapsulating the fulfilled use cases.
The result of the Interaction and Role Identification is a class diagram where classes represent roles (stereotypes are used to differentiate common and boundary roles), packages represent organisations and relationships describe interactions among roles or contributions (to the achievement of a goal) from one organisation to another.
Scenarios of the Scenario Description (SD) activity are drawn in form of UML sequence diagrams and participating roles are depicted as object-roles. The role name is specified together with the organisation it belongs to.
The resulting work product of the Role Plan (RP) activity is an UML activity diagram reporting one swimlane for each role. Activities of each role are positioned in its swimlane and interactions with other roles are depicted in form of signal events or object flows corresponding to exchanged messages.
The workproduct produced by the Capacity Identification is a refinement of the IRI diagram by adding capacities (represented by classes) and relating them to the roles that require them.
This paper has presented the use of the FIPA DPDF working group template with a specific MAS methodology, namely aspecs [1]. Only the first of the three phases composing aspecs is presented and in this phase two activities are detailed. The aim were twofold, first to prove the usability of the FIPA DPDF template and second to show a glimpse of the fragmentation of the aspecs methodology. For more details about the methodology, the reader may refer to either the aspecs reference paper [1] or its website: http://aspecs.org.
In this section we will discuss the work done for and the results obtained by adopting the novel FIPA process documentation template to the ASPECS process in order to evaluate its suitability and to estimate possible advantages of producing such a documentation. There are several steps to consider in the path towards the documentation of a process according to the new FIPA template. First, the (original) process has to be documented at a level of detail that is not common to most existing contributions from literature. Second, the documentation has to be converted to the FIPA specification. This means: (i) adopting the SPEM metamodel for process-related aspects, (ii) adopting a proper decomposition of the process (according to FIPA template), (iii) conveniently documenting the different parts, and finally, (iv) studying the metamodel and its relationship with activities and workproducts. The documentation of ASPECS according has proved to be quite an easy task. This is due to the specific origin of ASPECS. Differently from almost all the other AOSE processes, ASPECS has been built by rigorously following a situational method engineering approach (PRODE more specifically). This means ASPECS is essentially composed by process fragments originating from PASSI, RIO and from specifically created new ones. In such an approach, the fragments have been built (and documented) largely before the new process and therefore their resulting assembly has been easily documented. Referring to the previously listed of steps for obtaining a FIPA compliant documentation, the first step (obtaining a sufficiently refined documentation) has not really been an effort. The ASPECS development history directly produced that. As regards the second step (converting the documentation to the FIPA specification), we will discuss the specific details: (i) as regards SPEM adoption, we already were adopting it during ASPECS development so we had no troubles with that, (ii) as regards process decomposition, we identified the correct granularities and (iii) we extracted the proper information from existing ASPECS documents. This has been the greatest part of the job and it took about one day of work. Finally, the metamodel-related part of the work (iv) was really straightforward because creating ASPECS with PRODE caused to have a deep study of metamodel and its relationships with activities and work products as required by the FIPA template. Trying an evaluation of the obtained results, we can say that the work done was not so much but the outcome documentation has some evident advantages. The most evident consisting in highlighting the similarities (and differences) with the methodologies that are the parents of ASPECS: PASSI and RIO. Summarizing, the template proved to be efficient, of easy application to a huge process like ASPECS and it supported all the needs we faced in the work.