PASSI has been designed keeping in mind the possibility of designing systems with the following peculiarities: (i) highly distributed, (ii) subjected to a (relatively) low rate of requirements changes, (iii) openeness (external systems and agents that are unknown at design time will interact with the system to be built at runtime), (iv) various.Robotics, workflow management, and information systems are the specific application areas where it has been applied.
As regards the implementation architecture because we consider remarkably important the adoption (and enhancement) of standards for the diffusion of the agent-base software engineering, we decided to use the FIPA architecture although; this however, does not mean that PASSI cannot be largely applied for the design of non FIPA agents (like BDI ones).
Actors involved in the design process are supposed to be designers with:
From its initial definition, PASSI has been applied to a large number of small-medium student projects (many of them are graduating thesis works with up to 60 thousands lines of code) and some research projects funded by the European Community and the Italian Education and Research Ministery.
The results of these experiences are largely satisfactory, not only for the quality of the resulting products but also for the availability of a complete documentation (automatically produced by the PASSI design tool, PTK) and the overall design/implementation time and cost that are positively affected by the use of this methodology and its supporting tools.
Even less skilled students (with only one fundamentals of software engineering course in their curricula) produced convincing designs and good implementations.
The PASSI 2 methodology is composed of three models (view Figure) that address different design concerns and nineteen phases in the process of building a model.
Yet a time in PASSI 2 we use UML and adapts it to the need of representing agent systems through its extension mechanisms (constraints, tagged values and stereotypes). Within the agent design community, a variant or dialect of UML, has been proposed as a standard but it is not sufficient for our aims because of its by now limited scope (it re-defines the semantics and syntax of only a few different diagrams, not the whole UML set of views). Only very recently, a more extensive language (AML) has been presented and in the next future we will evaluate it for a possible adoption in the PASSI artifacts. This however will not have a drastic impact on the PASSI process since the process itself is well separated by the syntax adopted for producing the prescribed artifacts.
Click here for a description of the phases and steps of the methodology.
We think that designing a system corresponds to create an instance of its meta-model that could fulfill the requirements. The system meta-model in the case of object-orientation is someway well known and usually designers do not need to debate about that. It is not so when working with multi-agent systems. Several different approaches propose different MAS meta-models. As an example we can consider the three different methodologies (ADELFE [39], GAIA [37], and PASSI) analyzed by the FIPA Methodology Technical Committee in its work and the related (different) MAS meta-models [61]. Limiting the comparison to the agent and role definitions we can find that:
Another important issue that makes the exploitation of the MAS meta-model very important is that system meta-models traditionally refers to two different domains: the problem domain (where the requirements are captured) and the solution domain (where the implemented system lives). It should be noted that both of these domains are exactly the same if we talk about a conventional O-O approach or our A-O (agent-oriented) approach. Even the implementation of agent systems is today very commonly performed using object oriented languages like JAVA
We think this duality does not properly reflect the needs of an agent approach and therefore in our meta-model we introduce the agency domain. It represents the transition from problem-related concepts to the corresponding solution in an agent-based approach. Later, in the solution domain this agency-level system will finally be implemented accordingly to the chosen implementation framework (like JADE or FIPA-OS) and this often includes coding agents in an object-oriented language (commonly JAVA).
Now we will discuss more in detail the elements and the structure of the PASSI MAS meta-model. As already said, its elements are clustered in three domains: problem, agency and solution.
The Problem Domain deals with the user's problem in terms of scenarios, requirements, ontology and resources.
Scenarios describe a sequence of interactions among actors and the system. These scenarios are initially expressed using a textual description and later depicted in form of UML sequence diagrams.
Requirements initially are a textual description of the system requirements and they are later represented with conventional use case diagrams.
Ontological description of the domain is composed of concepts (entities, categories of the domain), actions (performed in the domain and effecting the status of concepts) and predicates (asserting something about a portion of the domain elements).
Resources of the domain are accessed/shared/manipulated by agents. A resource could be a repository of data (like a relational database), an image/video or also a good to be sold/bought.
The Agency domain contains the elements of the agent-based solution. None of these elements is directly implemented, they are converted to the correspondent object-oriented entity that constitutes the real code-level implementation.
Each agent in PASSI is responsible for realizing some functionalities descending from one or more requirements. These functionalities are made available to other agents (also external ones in open systems) through services to [link to J. Dale papers] The direct link of the MAS meta-model between requirements and the responsible agent, is one of the strategic decisions taken when conceiving PASSI and strongly characterizes it.
Agents can have access to resources; this means they can access an information (for example stored in a DB) or perceive something in the environment using its sensors (like in the case of embodied robotic agents) or even manipulate that with their actuators. Resources are essential elements of the system since they are used by agents to provide services (for instance in a robot a self-localization agent can provide the correct position to the remaining part of the system only if it has available the proper set of data and images collected by its sensors).
Each agent during its life plays some roles; a role in PASSI is a portion of the social behavior of an agent that is characterized by some specificity such as a set of attributes (for example responsibilities, activities, and communication protocols) or providing a functionality/service. From this definition easily descends that roles could use communications in order to realize the agent’s social relationships and are composed of portions of behavior (called tasks) to actuate the role proclivity. In order to avoid confusion, in this work, we use the term task with the significance of a meaningful part of the overall agent behavior while we will call behavior a generic part of the agent activity.
A task, therefore, describes some agent capabilities and the agent can accomplishing its duties differently composing the set of its own tasks. Tasks cannot be shared among agents, but their possibilities could be offered by the agent to the society as services (often a service is obtained composing more than one task). Each task is composed of actions that are atomic activities.
Obviously according to agent autonomy, each single agent has the possibility of accepting or refusing to provide a service if this does not match its personal attitudes and will (for instance it is not enough lucrative). This is totally different from an object-oriented service where an object/component could not refuse a service that is requested via the strong relationship of a method invocation instead of the weak connection established by agents' with their asynchronous communications.
A communication (also called conversation in FIPA specifications) is composed of one or more messages expressed in an encoding language (e.g. ACL [ref]) that is totally transparent to agents. The message content could be expressed in several different content languages (SL, CCL, KIF, RDF, … [refs]); we prefer RDF and the PASSI supporting tool (PTK) offers a concrete aid in generating the RDF code from the design models of ontology but this is only an option and not a constraint. Each communication explicitly refers to a piece of ontology (in the sense that information exchanged are concepts, predicates or actions defined in the ontology) and its flow of messages is ruled by an interaction protocol (AIP).
Interaction rules of agent conversations plays an important role in the FIPA Abstract Architecture; these have been formalized primarily through two concepts: the communicative act and the AIP (Agent Interaction Protocol). Each conversation has to respect a protocol and has to be made up of communicative acts. A communicative act [36] is a way to associate a predefined semantic to the content of a message so that it can be univocally understood by agents. Some examples of communicative acts are: request, refuse, agree, inform, and failure. An Agent Interaction Protocol defines which communicative acts may be used in a conversation and in what order the related messages have to be sent to give the proper meaning to the communication. Therefore, a protocol compels the use of determined messages with a specific semantic according to a specific sequence. When an agent starts a conversation with another agent it specifies a protocol; a conversation without a protocol is not possible. If a message does not respect the rules of the protocol or violates the prescribed order, then the conversation fails.
The Service element describe a set of functionalities offered by the agent under a specific name that is registered in the system yellow pages and therefore can be used by other agents to reach the server who provides a specific service. This description is also useful to ensure the system openness and the reusability of its components. We refer to OWL-S [refs] for the description of services and we store some of it’s descriptors in the yellow pages directory in order to allow useful and complete answers to service quests. It is now worth to note that FIPA specifications provide (yet) no good support for service description and for this reason we preferred to adopt the OWL-S specification instead of a more agent-oriented one.
The Implementation Domain describes the structure of the code solution in the chosen (usually FIPA compliant) implementation platforms (commonly in our experiments FIPA-OS or JADE) and it is essentially composed of two elements: (i) the Implementation-Platform Agent that represents the implementation class for the agent entity represented in the Agency domain; (ii) the Implementation-Platform Task that is the implementation structure (usually an inner class of the agent class) available for the agent's Task. All of these classes will obviously need of the proper structure in terms of properties (attributes mapping the agent knowledge) and operations (implementing the agent capabilities).
