SPREADING THE CROSSCUTTING TO SUBSEQUENT ARTIFACTS

The problems associated with heterogeneous agent architectures are typically disseminated from the agent architecture specifications to artifacts generated later in the software life cycle. Hence, the crosscutting of agent concerns is inevitably spanned over the resulting artifacts in the detailed design level and implementation. It does not matter what kind of decomposition and

Traveling
abstractions the agent-based ^Decision Autonomy
software developers are relying
on; the problem is the same if
you are using an agent-oriented Bahavior
design language [ 2], or an OO ^Adaptation
modeling language, such as
^UML. Knowledge Adaptation Services
For example, the architectural ^Bahavior Adaptation
abstractions and composition
rules are not directly supported in
Message Sending
OO design and programming _{Role Binding}
languages. They are not aligned
with the composition and decom-
position mechanisms of the object ^Protocol _Enforcement
paradigm, which makes it diffi- ^{Role Binding}
cult to handle the heterogeneous
agent types in a single system [ 6].

For instance, the inheritance mechanism usually leads to large inheritance trees with replication ^{Figure 1.} of code and an explosion of the ^{Crosscutting concerns in} _{heterogeneous agent} number of classes [ 5, 6, 12]. Even architectures. in some simple agent architectures, bringing them into the detailed design and code also raises similar problems (examples are shown in the table), such as scattering and tangling.

Figure 2a illustrates how the reification of heterogeneous agent architectures in the design tends to be scattered over many classes of the system design. It shows a partial representation of an agent-based system [ 6] composed of three agent types, each with a different internal architecture. Each set of classes, surrounded by a gray rectangle, has the main purpose of modularizing a specific agent concern, namely the agents’ basic functionality and collaboration. The figure shows that agent-specific concerns crosscut the classes implementing those surrounded classes, such as “Information Agent” and “Role.” The use of OO mechanisms breaks not only the class-level modularity, but also the operation-level modularity. Figure 2b shows the partial implementation of a searcher agent, which consists of a class and respective operations with

a confusing tangle of lines of code for different concerns. On the left, there is the code for a class as a non-agent entity. On the right, there is an equivalent class with code for implementing agent-specific concerns. After analyzing the code on the right, it is clear that such code has lost the functional encapsulation of the non-agent version (left side). Moreover, it is a confus-

 

Autonomy

Message

Traveling Knowledge AdaptationServices Processing _Protocol Bahavior Adaptation _Enforcement

Execution Autonomy Message Processing

Execution _Message Autonomy _Sending

Message Role Binding Reception

Message Processing

(b) Mediator Architecture

Message Reception

Legend:

Message Reception

Concerns

(a) Layered Architecture

Basic Functionality Autonomy

Interaction

Adaptation

Collaboration

Learning

Mobility

 

ing intermingling of lines of code for different agent concerns, and the modularization of several agent-specific concerns is lost across the system classes.

 

ARCHITECTING SOFTWARE AGENTS WITH ASPECTS Aspect-oriented software development [ 9] is an evolving paradigm to modularize concerns that existing software engineering abstractions and mechanisms are not able to capture explicitly. The notion of aspects encourages modular descriptions of complex software by providing support through new composition mechanisms for cleanly separating the system functionality from its crosscutting concerns. However, existing aspect-oriented approaches have not been explored in the context of heterogeneous agent architectures; they have focused on the context of classical crosscutting concerns, such as distribution [ 11], persistence [ 11], and design patterns [ 7]. These concerns have been mostly studied in an isolated way and from the implementation point of view.

Aspects and its new composition possibilities can be exploited at the architectural level to capture the multiple interacting agent concerns that are difficult to