In the creation of the design of the agent, the concepts that distinguish agent systems from other software have to be captured appropriately. Since the Unified Modeling Language (UML) is the notation of choice for modeling many software systems and UML is aimed at object-oriented software and therefore does not support agents directly, these concepts have to be emulated. There are a number of possibilities to do this and some of them are outlined in the following. Special attention is given to UML profiles and meta-models. BDI agents based on beliefs, goals, and plans are considered separately since this structure is very common and merits special attention.

UML Profiles

The simplest way to accommodate the requirements of agents in the design is to create an UML profile with fitting stereotypes to describe the concepts of the agent. The PosoMAS Auxiliary UML Profile is a minimal example of such a profile. Using stereotypes to denote certain model elements can aid in the readability of the models and is useful when model transformations or model-to-text transformations are applied in the development process to generate artefacts or code from the models. Profiles are supported by mature modeling tools and can easily be exchanged between designers and developers.

Existing Meta-Models

Often, specialised meta-models are used to express the meta-classes and concepts relevant in agent systems. The authors of [1], e.g., outline such a meta-model that encompasses Beliefs, Goals, and Plans, the basic components of BDI agents (see below). A general overview of different meta-models from the literature is given in [2]. Many agent-oriented software engineering process are build on specific meta-models as well and many of the steps in the process rely on the presence of concepts from that meta-model.

Selecting a suitable meta-model is not an easy task and usually requires some notion of the capabilities that the finished system needs to possess. In many cases, meta-models in the research literature are aimed at a certain implementation platform which supports the elements of the meta-model directly. If a different platform is used, these abstractions might prove cumbersome to implement. The concepts provided by the meta-model also implicate a certain design and modeling philosophy that might not be appropriate. If the process or implementation platform does not prescribe a certain model, it is recommended to create a first rough design and evaluate the different meta-models available with this design in mind to make sure that the concepts can be mapped.

An interesting aspect of specialised meta-models is their use in model-driven development approaches (MDD/MDA): if they are specific to a platform, they should neither be used in the modeling of the computational independent model (CIM), nor in the modeling of the platform independent model (PIM). Only when the transformation to the platform-specific model (PSM) is performed can they be used as the basis to specify the transformation rules. MDA for agent-based systems is briefly discussed in [4].

BDI Agents

Bauer et al. [3] suggest using fields for beliefs, desires, and intentions. These fields should be typed as logical formulas and initialised with corresponding well-formed formulas when the agent is initialised. More current approaches move away from such a representation towards a more explicit and flexible one. Goals and plans are often expressed as regular classes, either instances of specific meta-classes or stereotyped with according elements from a UML profile. Beliefs can be represented by any field or association but should be labelled by an appropriate stereotype as well.

In [4], Bauer and Odell also discuss using other kinds of diagrams for the representation of goals and plans. In particular, activity charts can be used to describe processes and the sequence of events to complete them. Likewise, state diagrams are useful to describe the states an agent can have in interactions with others. Interaction diagrams are similarly suited to describe the protocols that define those interactions. All these diagram types are helpful additions to class diagrams.

References