The aim of this phase consists in representing the agent society structure; we use one class diagram to show the whole MAS (of course, several diagrams could be used if the number of classes requires this), each agent is depicted using a class and detailed in terms of its knowledge and tasks.
This diagram represents the structure of the agents in a simple compact form that we found very useful to comprehend the MAS structure at a glance and to describe architectural choices (like for instance a multi-layer solution).
In the next figure we can see a portion of the MASD representing the agent society for the proposed case study. This diagram differs from common UML class diagrams only for the presence of actors. We think that in a social representation of the system that is also a ‘personified’ view of agents it is important to represent the relationships of the agents with both users and external agents because a social representation could not be thought to be complete without explicitly considering the external elements that interacts with the system and often determine its collective behavior.
In order to complete this phase, the designer should access the initial system description performed in the ASE (Agent Structure Exploration) phase. This corresponds to start from the analysis results and then enriching them with considerations coming from the social model. In this diagram, agents coming from the ASE diagram are detailed in terms of the knowledge they need in order to cope with their social relationships (communications coming from the COD phase), and the tasks they use to accomplish their functionalities (some of these already identified in the ASE phase, some others now introduced while refining the agent).
It is also possible to introduce new agents in order to allow a better decomposition of the system from a (social) architectural point of view. A frequent example of that consists in an agent that is supposed to interact with an user via a GUI and then performs some kind of (heavy) computational task (or similarly a complex series of queries on a knowledge base/ database). If non-functional requirements prescribe that user interface should be done using a small device like a cellular phone or a PDA, the heavy-duty agent of the initial hypothesis is not a good solution and therefore it is likely to be decomposed in two (or more) different agents the first of which is a light-weighted GUI agent that can be run on strongly constrained devices.
Next phase: Multi-Agent Behavior Description
Previous phase: Role Description
Home: PASSI 2 homepage