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