Page 137 -

122 HENDERSON-SELLERS
the object-oriented software engineering and the agent-oriented paradigms. The methodology
adopts (and largely extends/adapts) the UML notation for its work products and targets the FIPA
implementation environment. Prometheus (Padgham and Winikoff, 2002a, 2002b, 2004), on the
other hand, is an agent-oriented methodology that reuses elements from object technology only as
appropriate, including several UML diagram types. There are three phases of systems specifica-
tion. In the first phase, the basic functionality of the system is identified, using percepts (inputs),
actions (outputs), and any necessary shared data storage. This is followed by the architectural
design stage; here, the agents and their interactions are identified. Finally, there is the detailed
design phase in which the internal details of each agent are addressed.
From the published literature, it is not possible to identify any direct influences from OO
methods (although, of course, some may exist implicitly) for Cassiopeia, CAMLE, and Agent
Factory (Figure 8.1). Cassiopeia (Collinot, Drogoul, and Benhamou, 1996) provides an (argu-
ably incomplete) methodological framework for the development of collective problem-solving
MASs. This method assumes that, although the agents can have different aims, the goal of the
designer is to make them behave cooperatively. It adopts an organization-oriented approach to
MAS design, as do some other AO approaches, viewing a MAS as an organization of agents that
implement/encapsulate roles. These roles reflect not only the agents’ individual functionality but
also the structure and dynamics of the organization of the MAS. CAMLE (Shan and Zhu, 2004) is
described as a caste-centric agent-oriented modeling language and environment. It is caste-centric
because castes, analogous to classes in object-orientation, are argued to provide the major model-
ing artifact over the life cycle by providing a type system for agents. A significant difference is
claimed between castes and classes: while objects are commonly thought of as statically classified
(i.e., an object is created as a member of a class, and that is a property for its whole lifetime),
agents in CAMLE can join and leave castes as desired, thus allowing dynamic reclassification.
CAMLE provides a graphical notation for caste models (similar to class models in OO modeling
languages), collaboration models, and behavior models. Caste diagrams also include support for
the non-OO relationships of congregation, migration, and participation. CAMLE relies heavily
on the fact that an information system already exists when a new project is started, so that the
new system is designed as a modification to the current one. Although this situation is indeed
common, the construction of systems from scratch also happens. CAMLE, however, seems to
ignore this possibility. Finally, in this group, Agent Factory (Collier et al., 2003, 2004) offers a
four-layer framework for designing, implementing, and deploying multi-agent systems. It con-
tains (1) an agent-oriented software engineering methodology, (2) a development environment,
(3) a FIPA-compliant run-time environment, and (4) an agent programming language (AF-APL);
with a stated preference for the belief-desire-intention (BDI) agent architecture according to the
analysis of Luck, Ashri, and D’Inverno (2004). By employing UML and Agent UML, the Agent
Factory methodology provides a visual, industry-recognized notation for its models—regarded
by its authors as a major advantage over other approaches, such as Gaia (Wooldridge et al., 2000)
and Tropos (Bresciani et al., 2004), which have nonstandard (i.e., non–UML-compliant) notations.
These models are capable of promoting design reuse (via the central notion of role) and being
directly implemented by automated code generation (Collier et al., 2004).
In a slightly different class, Tropos (Bresciani et al., 2004; Castro, Kolp, and Mylopoulos, 2002;
Perini et al., 2001) uses agent, rather than object, concepts and was designed to support agent-
oriented systems development with a particular emphasis on the early requirements engineering
phase. The stated aim was to use agent concepts in the description and definition of the methodology
rather than using OO concepts in a minor extension to existing OO approaches. Tropos takes the
BDI model (Kinny, Georgeff, and Rao, 1996; Rao and Georgeff, 1995), formulated to describe