cláudio sant’anna*, cidiane lobato and uirá...

34 Int. J. Agent-Oriented Software Engineering, Vol. 2, No. 1, 2008

Copyright © 2008 Inderscience Enterprises Ltd.

On the modularity assessment of aspect-oriented multiagent architectures: a quantitative study

Cláudio Sant’Anna*, Cidiane Lobato and Uirá Kulesza Computer Science Department Pontifical Catholic University of Rio de Janeiro (PUC-Rio) Rua Marques de São Vicente 225, Rio de Janeiro – RJ, 22453–900, Brazil E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author

Alessandro Garcia Computing Department Lancaster University InfoLab21, South Drive LA1 4WA, Lancaster, UK E-mail: [email protected]

Christina Chavez Computer Science Department Federal University of Bahia Av. Adhemar de Barros s/n, Salvador, BA, 40170–110, Brazil E-mail: [email protected]

Carlos Lucena Computer Science Department Pontifical Catholic University of Rio de Janeiro (PUC-Rio) Rua Marques de São Vicente 225, Rio de Janeiro – RJ, 22453–900, Brazil E-mail: [email protected]

Abstract: A number of concerns in Multiagent Systems (MAS) have a broadly-scoped impact on the system architectural decomposition, which in turn hinder the design of modular MAS architectures. Typical examples of crosscutting concerns in MAS architectures include learning, mobility, coordination, and autonomy. Nowadays there are some architectural proposals that envisage an emerging aspect-oriented architectural pattern as a potential solution to address modularity shortcomings of conventional architectural

On the modularity assessment of aspect-oriented multiagent architectures 35

patterns for MAS designs. However, little effort has been dedicated to effectively assess when and which of these emerging and traditional architectural solutions promote in fact superior modularity in the presence of crosscutting MAS concerns. This paper presents a quantitative comparison between aspect-oriented and conventional MAS architectures. Our analysis evaluates how the architectures under comparison support the promotion of enhanced modularity in the presence of architectural crosscutting concerns in MAS design. Our evaluation used two medium-sized MAS applications and was centred on fundamental modularity attributes.

Keywords: Multiagent Systems; MAS; software architecture evaluation; aspect-oriented architecture; software metrics.

Reference to this paper should be made as follows: Sant’Anna, C., Lobato, C., Kulesza, U., Garcia, A., Chavez, C. and Lucena, C. (2008) ‘On the modularity assessment of aspect-oriented multiagent architectures: a quantitative study’, Int. J. Agent-Oriented Software Engineering, Vol. 2, No. 1, pp.34–61.

Biographical notes: Cláudio Sant’Anna is a PhD candidate in the Department of Computer Science at the Pontifical Catholic University of Rio de Janeiro, Brazil. He received his MSc in Computer Science from the Pontifical Catholic University of Rio de Janeiro, Brazil. His research interests include software architecture, software metrics, aspect-oriented software development and agent-oriented software engineering.

Cidiane Lobato is a Researcher in the Software Engineering Laboratory at the Pontifical Catholic University of Rio de Janeiro, Brazil. She received her MSc in Computer Science from the Pontifical Catholic University of Rio de Janeiro, Brazil. Her research interests include agent-oriented software engineering and aspect-oriented software development.

Uirá Kulesza is a Researcher in the Software Engineering Laboratory at the Pontifical Catholic University of Rio de Janeiro, Brazil. He received his PhD in Computer Science from the Pontifical Catholic University of Rio de Janeiro, Brazil. His research interests include aspect-oriented software development and software product lines.

Alessandro Garcia is a Computer Science Lecturer in Lancaster University’s Computing Department. He received his PhD in Computer Science from the Pontifical Catholic University of Rio de Janeiro, Brazil. His research interests include empirical software engineering, aspect-oriented software development, software architecture, exception handling, software metrics, and agent-oriented software engineering.

Christina Chavez is an Assistant Professor in the Department of Computer Science at the Federal University of Bahia, Brazil. She received her PhD in Computer Science from the Pontifical Catholic University of Rio de Janeiro, Brazil. Her research interests include software architecture and design, model-driven engineering, aspect-oriented software development and agent-oriented software engineering.

Carlos Lucena is a Full-Professor of Computer Science at the Pontifical Catholic University of Rio de Janeiro, Brazil. He is also an Adjunct Professor of Computer Science and Senior Research Associate in the Computer Systems Group at the University of Waterloo, Canada. He received his PhD from the University of California in Los Angeles. His research interests include agent-oriented software engineering, aspect-oriented software development, software product lines, software architecture and design.

36 C. Sant’Anna et al.

1 Introduction

Software architecture is a fundamental element of Multiagent Systems (MAS). Architects strive to develop reusable and adaptable MAS architectures that are resilient in face of changes especially for systems in volatile business domains such as eCommerce, banking, and telecommunications. However, in order to be effectively reusable and adaptable, MAS software architectures must be modular. It requires from architects to make proper early design decisions, such as the adequate selection and composition of architectural patterns in order to achieve satisfactory separation of concerns. Modular MAS architectures also demand the careful employment of well-designed component interfaces, reduction of architectural coupling, maximisation of components’ cohesion, and the like. These all concern places where we explicitly consider elementary requirements in our MAS designs, such as reusability, adaptability, flexibility, maintainability, and so forth.

In fact, conceiving modular software architectures for complex MAS is not a trivial task mainly due to a number of recurring widely-scoped MAS concerns and application-specific concerns. A number of these concerns have a crosscutting impact on the MAS architectural decomposition, and systematically affect the boundaries of several architectural elements, such as components and their interfaces (Garcia and Lucena, 2006; Garcia et al., 2004b). Typical examples of crosscutting concerns in MAS architecture include learning (Garcia et al., 2003), mobility (Ubayashi and Tamai, 2001), autonomy (Weiss et al., 2003), and coordination (Amor et al., 2004). The problem is that to build flexible MAS applications and frameworks, many of those typical crosscutting features should be modularised in order to be separated and optionally exposed as architectural variabilities in the MAS architecture decomposition. This scenario becomes even more challenging when there is a need for reusing and composing MAS frameworks (and platforms), in which their architectures partially addresses each of those broadly-scoped MAS concerns and, at the same time, embody a number of crosscutting architectural decisions.

In this context, there are a number of architectural patterns proposed to build modular MAS (Kendall et al., 1999; Camacho, 2003). For example, Kendall et al. (1999) propose a specialisation of the layered architecture in order to provide a clear separation of MAS concerns as layers, with narrow interfaces between adjacent layers. Garcia and Lucena (2006) have defined an aspect-oriented architectural pattern for a similar purpose. There are also some existing MAS frameworks and applications that follow a similar aspect-oriented architecture design (Amor et al., 2004; Seiter et al., 2006). However, little effort has been dedicated to systematically assess to what extent this new aspect-oriented architectural solution promotes in fact superior modularity in the presence of typical crosscutting concerns in MAS architecture designs. Without a clear evidence of each solution strengths and drawbacks, modular MAS architects are not guided on when to use each of the available architecture patterns and how to compose them.

This paper presents two complementary case studies where we have quantitatively evaluated the degree to which aspect-oriented MAS architectures (Garcia and Lucena, 2006) scale up to promote improved modularity when compared to MAS architectures based on conventional patterns, such as mediator-based and publisher-subscriber styles. We have architected and implemented two medium-sized MAS with similar driving modularity-related requirements, from different domains, based on distinct MAS platforms and frameworks, and with distinct exploitation of typical MAS features. Our


evaluation is based on architectural metrics, which are rooted at fundamental modularity principles, such as separation of concerns, narrow interfaces, low architectural coupling, high component cohesion, and composition simplicity (Booch, 1994; Meyer, 1997; Parnas, 1972). Our assessment is mainly concerned with the degree with which the modularity supports the adaptability and variability of MAS features. This empirical assessment is one step ahead with respect to a first similar empirical study which compares aspect-oriented and object-oriented implementations for the same MAS application (Garcia et al., 2003).

The paper is organised as follows. Section 2 explains the concepts of modularity, architectural concerns and aspect-oriented software development. Section 3 presents conventional patterns for architecting MAS and the application of an aspect-oriented architecture pattern for MAS design. Section 4 describes the two case studies, and our used assessment procedures and metrics. Section 5 presents and discusses the architecture measurement results. Section 6 introduces a more general analysis and related work. Section 7 presents concluding remarks.

2 Background

This section presents a review of basic concepts associated with modularity (Section 2.1), architectural concerns (Section 2.2) and aspect-oriented software development (Section 2.3).

2.1 Modularity

Modularity is considered an essential concept of modern software design thought. Many software engineering methods and techniques are based on the premise that a modular structure of software can improve its quality in some degree. A high degree of modularity is claimed to bring a series of benefits, such as changeability, adaptability, reusability, and so forth. The IEEE Standard Glossary Terminology1 defines modularity as the degree to which a system programme is composed of discrete components such that a change to one component has minimal impact on other components. This definition is closely related to Booch’s (1994) one, which states that modularity is the property of a system that had been decomposed into a set of cohesive and loosely coupled modules. In fact, low coupling and high cohesion have been considered as important drivers to achieve modular design (Booch, 1994; Meyer, 1997). Besides, software engineering gurus also consider narrow interfaces as an important principle. A module interface should be as narrow as possible, since in a complex system a change in a module interface might result in changing many other modules (Booch, 1994; Meyer, 1997).

Although decomposing a system in independent modules is crucial, it is not sufficient to promote the benefits credited to a well modularised system. On other words, if the criteria used to choose the modules are not adequate to make the system concerns well localised in those modules, even a system decomposed into weakly-coupled modules might suffer from poor changeability, comprehensibility and the like. For instance, consider a system that comprises several independent modules, which can even be compiled separately. If a functionality is spread over an expressive number of these modules, then the effort required to understand and change it might be high.


Actually, the concept of modularity applied to software development was first introduced by Parnas (1972), and his ideas are still considered extremely relevant. In his paper, he claims that the effectiveness of a modularisation is dependent upon the criteria used in dividing the system into modules. He advocates that modularisation is more about deciding which must be done by each independent module than just having independent modules. In particular, Parnas proposes that information hiding is a good criterion to be used. Therefore, based on these ideas, we consider modularity as:

• the degree to which the system concerns (functionalities, features, requirements, etc.) are well localised over the system modules

• the degree to which the system modules are cohesive, loosely-coupled, and have narrow interfaces.

2.2 Architectural concerns

Concerns are important properties or areas of interest of a system that we want to treat in a modular way. Concerns can range from high-level notions like security and quality of service to low-level notions such as caching and buffering (Elrad et al., 2001). They can be functional, like features or business rules, or non-functional, such as synchronisation and transaction management (Elrad et al., 2001).

An architectural concern is a concern that manifests itself at the architecture specification, that is, some important part of the problem that we want to treat in a modular way at the architecture specification (Garcia et al., 2006; Garcia and Lucena, 2006). Much of the complexity of software architecture design is derived from the inadequate modularisation of architectural concerns. Architectural concerns can come directly from the system requirements or emerge during the architecting process.

In our work, we focus on architectural concerns that eventually evolve into concrete pieces of code and contribute directly to the functionality of the system, such as interaction and adaptation, which are agent properties. Persistence and exception handling are also examples of concerns that evolve into pieces of code. Our metrics do not rely on concerns that influence how the system is built but do not trace to any specific piece of code. In particular, we do not focus on concerns that influence the software process and are not observable when the system executes, such as maintainability. It is also important to bear in mind that the concerns that represent critical features of the systems, such as a variability, are strong candidates to be considered in the measurement process. In particular, in this paper, we are interested in assessing the modularisation of typical concerns of multiagent systems, such as, learning, mobility, autonomy, interaction, coordination and adaptation.

2.3 Aspect-oriented software development

Separation of concerns is a fundamental principle that addresses the limitations of human cognition for dealing with complexity. It advocates that to master complexity, one has to deal with one important issue (or concern) at a time (Dijkstra, 1976). In software engineering, the principle of separation of concerns is usually related to system decomposition and modularisation (Parnas, 1972): complex software systems should be


decomposed into smaller, clearly separated modular units, each dealing with a single concern. The expected benefits are improved comprehensibility, increased potential for evolution and reuse in complex software systems.

The abstraction and composition mechanisms supported by successive generations of programming languages have evolved to foster the expression of solutions to real world problems in a more natural way as well as to advance one’s ability to achieve separation of concerns at the source code level. Object-Oriented Programming (OOP) has been the dominant programming technology for several years and its benefits are broadly recognised. However, object-orientation has some limitations for dealing with concerns that address requirements involving global constraints and systemic properties, such as synchronisation, persistence, error handling, logging mechanisms, among many others. These concerns have been called crosscutting concerns since they naturally crosscut the boundaries of modular units that implement other concerns. Without proper means for separation and modularisation, crosscutting concerns tend to be scattered over a number of modular units and tangled up with other concerns. The natural consequences are lower cohesion and stronger coupling between modular units, reduced comprehensibility, evolvability and reusability of code artefacts.

Aspect-Oriented Programming (AOP) (Kiczales et al., 1997) is an evolutionary technology that supports a new flavour of separation of concerns at the source code level. AOP uses aspects as a new modular unit for separating crosscutting concerns and provides a new mechanism for composing aspects with other modular units at well-defined points called join points. Each aspect defines one or more first-order logic expressions, called pointcut expressions, to select the join points that will be affected by the aspect’s crosscutting behaviour. When programme execution reaches a join point selected by some pointcut expression, a body of code, called advice, can be executed before, after or around it. Additionally, aspects can provide intertype declarations, that is, attributes and methods that will be inserted in other modules. Aspects therefore may localise crosscutting features such as pointcut expressions, advice and intertype declarations, as well as local features, such as attributes and methods.

Pointcut expressions, advice and intertype declarations define a contract between the aspect module and the other modules it affects and constitute the aspect interface. However, the services provided by the aspect module may not be explicitly required by the other modules. In general, the aspect interface specifies when and how these ‘client modules’ will be affected by its crosscutting services. These concepts – aspects, pointcuts, join points, advice, intertype declarations – constitute a common standard vocabulary for AOP adopted from AspectJ (Kiczales et al., 2001), a general-purpose aspect-oriented extension to the Java language.

Aspect-Oriented Software Development (AOSD) is an increasingly important paradigm in software development whereby the novel AOP notions of modularity and related composition mechanisms are discussed with the goal of supporting the separation of crosscutting concerns in other phases of the software life cycle. In the context of software architecture, a number of aspect-oriented architecture description languages, such as AO-ADL (Pinto and Fuentes, 2007) and Aspectual ACME (Garcia et al., 2006), have been proposed to allow the representation of aspect-oriented abstractions at the architecture design. In architecture design, architectural aspects (or aspectual components) can be defined to modularise crosscutting properties and to separate them from other architectural components. Architectural aspects may affect components at


well-defined architectural join points. For instance, an architectural join point can be the invocation of a service (or operation) of some component interface. The aspectual component interface can be further decomposed into one or more narrower interfaces, or crosscutting interfaces (Chavez et al., 2006), that modularise subsets of related crosscutting features. Crosscutting interfaces promote comprehensibility of aspects themselves and the effects of their composition.

3 Architectural patterns and modular MAS

Every application, in general, requires a recurring architectural pattern which is the most appropriate to satisfy its modularity-related requirements. Although of course there is no single architectural pattern that is the most suitable for all MAS applications, modularity is a stringent software engineering property that underlies almost all architectural decisions in MAS designs. Architectural patterns provide guidelines to build modular software architectures in the sense that they prescribe a set of architectural roles, their interactions, and associated constraints. All these architectural rules are typically targeted at preserving basic design principles, such as simple interfaces, low coupling, and so forth.

A number of architectural patterns (Buschmann et al., 1996) have been proposed for the modular design of MAS architectures. Section 3.1 revisits some of those architectural solutions and briefly discusses architectural crosscutting in MAS decompositions. This discussion serves as a twofold purpose: it describes the consequences of not having explicit architectural support for the modularisation of crosscutting concerns in MAS designs, and works as a motivation for outlining an aspect-oriented architectural pattern (Garcia and Lucena, 2006) for MAS in Section 3.2.

3.1 Conventional architectural patterns for MAS

There are some architectural approaches (Amandi and Price, 1998; Camacho, 2003; Kendall et al., 1999) that promote enhanced modularity of architectural MAS concerns. They rest on traditional architectural patterns, such as the Layers pattern (Kendall et al., 1999), Mediator pattern (Camacho, 2003), the Reflection pattern (Amandi and Price, 1998), or the Publisher-Subscriber pattern (Helsinger et al., 2004). For instance, Kendall et al. (1999) propose the Layered Agent architectural pattern with multiple layers for the separate representation of agent concerns (Figure 1a). The use of mediators (Camacho, 2003) is also a common architectural approach to address the composition of agent concerns that interact in multiple ways. For instance, the Mediator pattern (Chan et al., 2002) provides means of allowing integration of agent properties using a central component, the mediator (Figure 1b). These conventional architecture patterns are general-purpose design solutions, which are agnostic to specific application domains. There are also architectural approaches that rely on MAS-specific architectural patterns (Davidsson et al., 2005), which are solutions specially defined for designing multiagent systems.


Figure 1 Manifestation of crosscutting concerns in conventional agent architectures

A previous empirical investigation (Garcia et al., 2003) has identified that implementation following conventional architectural patterns may hinder the development of modular agent architectures. The main reason is that such implementations fail to address the modularisation of crosscutting MAS concerns. The crosscutting manifestation leads to two major problems – scattering and tangling – which are fundamental anti-modularity factors in MAS architectures. Scattering in MAS architectures is the occurrence of architectural elements, such as interfaces, that belong to one agent concern in architectural components encapsulating other agent concerns (Garcia and Lucena, 2006). For example, the interaction-related interfaces are scattered over the agent architectures in Figure 1. Architectural tangling is the mix of multiple agent concerns together in the same module (Garcia and Lucena, 2006). For instance, tangling is evident in the agent kernel of Figures 1a and 1b as both are implementing interfaces associated with different agent concerns.

3.2 An aspect-oriented pattern for MAS architectures

In order to address such modularity breakdowns in MAS architectures, an aspect-oriented architectural pattern (Garcia and Lucena, 2006), and a number of aspectual MAS implementation frameworks and applications (Garcia et al., 2004b; Amor et al., 2004; Seiter et al., 2006) that realise this pattern have been defined. Table 1 summarises the main roles defined by the aspect-oriented architectural pattern, their respective responsibilities, and interaction constraints. This pattern documents the fundamental attributes of an aspect-oriented architectural design. Architectural aspects (or aspectual components) and aspectual interaction rules are exploited at the architectural level to


capture the crosscutting architectural concerns that are hard to modularise with existing architectural abstractions defined by other patterns. An architectural aspect is used to represent each crosscutting concern as an individual component at an early stage of design (Garcia and Lucena, 2006). Section 4 will describe two different instantiations of the aspect-oriented pattern in the context of our case studies.

Table 1 The aspect-oriented architectural pattern: architectural elements, their responsibilities and interactions

Architectural role Responsibilities and constraints Interaction constraints Base components (and interfaces)

Modularise services that realise a non-crosscutting concern Provide the architectural join points to aspects

Can be affected by one or more crosscutting interfaces Access services available in other conventional interfaces

Architectural aspects (or aspectual components)

Encapsulate an architectural crosscutting concern Contain at least one crosscutting interface May implement conventional interfaces

Affect base components and other aspects through its crosscutting interfaces Can be directly associated with other aspects

Crosscutting interfaces

Provide crosscutting services and specify when and how each of them affects other interfaces

Are allowed to affect both conventional and other crosscutting interfaces Affect base interfaces using aspectual composition operators, such as before, after, and around

In MAS design, architectural aspects are used to modularise typical crosscutting MAS properties and to separate them from other architectural components. The goal of aspectising MAS architectures is to allow the association of crosscutting agenthood properties with the non-crosscutting basic functionality at certain join points. In this context, crosscutting interfaces are a key abstraction to enable clean and evolvable compositions (Section 2.3). The crosscutting interface of an architectural aspect may specify:

• component interfaces’ operation(s) it is supposed to affect

• the behaviour that will affect the specified operations

• when that behaviour should be executed (before, after or around the affected operation).

4 Experimental settings

This section describes the configuration of our empirical assessment. We have performed a pair-wise comparison about the modularity of an Aspect-Oriented (AO) architecture and a second non-aspectual (non-AO) architectural solution in the context of two MAS case studies, which are described in Section 4.1 and Section 4.2. The first case study involved the comparative evaluation of a mediator-based and aspect-oriented architecture for a MAS framework (Garcia et al., 2004b), called AspectT, which supports the development of applications with heterogeneous agent architectures. AspectT framework


has been developed as an alternative to the object-oriented mediator-based architecture presented in Section 3.1. The second study encompassed a publisher-subscriber (Barbosa and Goldman, 2004) and an aspect-oriented version (Lobato et al., 2006) of the MobiGrid architecture (Barbosa and Goldman, 2004), used to develop mobile agents in Grid environments. The original MobiGrid non-AO architecture was defined based on the OO framework provided by the Aglets platform (Lange and Mitsuru, 1998). Other architectural patterns were also instantiated and composed in all the system versions, such the client-server. However, the aforementioned ones are the heart of the architecture design and, therefore, we concentrate our attention on them. The architectural designs presented in this paper focus on the component-and-connector view of the architectures and follow a simplified UML 2.0 notation and the AOGA notation (Kulesza et al., 2004) for the non-AO and the AO solutions, respectively. AOGA (Kulesza et al., 2004) is a simple extension of UML for describing aspect-oriented architectures that supports the description of crosscutting interfaces (Chavez et al., 2006).

The main goal of the measurement process was to compare the systems modularity in order to assess which solution provides better variability and adaptability of MAS concerns. In this context, both systems were ideal for our experimental investigation due to several reasons. First, the chosen systems have stringent modularity requirements due to the demand for producing adaptable and evolvable MAS architectures. Hence, all the system versions were developed with modularity principles as main driving design criteria, making sense the exploitation of AO software architectures. Second, the original non-AO architecture of each case study was developed in different contexts and laboratories. Finally, they are systems that involve emphasis on different MAS concerns, such as mobility, learning, autonomy, and their distinct compositions; they also encompasses the application of common MAS platforms and frameworks, such as JADE (Bellifemine et al., 1999), and Aglets (Lange and Mitsuru, 1998). Sections 4.1 and 4.2 focus on describing the main AO and non-AO architectural choices for both AspectT and MobiGrid case studies. Section 4.3 presents our evaluation steps and the architectural metrics applied.

4.1 The AspectT architecture

AspectT is an aspect-oriented agent framework (Garcia and Lucena, 2006; Garcia et al., 2004a–b; Garcia, 2004) which defines an architecture for implementing different kinds of agents, such as, information and user agents. This framework has been implemented using the AspectJ (Kiczales et al., 2001) and Java programming languages. We have used this framework in the implementation of two case studies:

1 Portalware – a web-based system for the development of e-commerce portals (Garcia et al., 2004b)

2 ExpertCommittee – a conference management MAS (Garcia et al., 2004a).

AspectT was structured following the aspect-oriented pattern for MAS architectures detailed in Section 3.2.

Figure 2 shows the framework architecture. It defines a set of components playing the roles of architectural aspects that address different crosscutting agent properties, such as interaction, autonomy, mobility, and learning. Crosscutting relationships connect architectural aspects and the modules they affect. Figure 3 shows a partial view of the


operations in the interfaces of three components: Kernel, Interaction and Adaptation. Similarly to traditional interfaces in UML, a crosscutting interfaces is represented by a rectangle with an extra compartment in the bottom of it. This extra compartment represents the events and services observed by the interface. The first compartment represents operations to be executed when an observed event is raised. This representation is inspired on the ASideML modelling language (Chavez and Lucena, 2001). Following we describe the main components of the AO architecture and their respective relationships.

The aspect-oriented architecture has the Kernel component as a central element. This component defines four interfaces:

1 KnowledgeUpdating – used to update the agent knowledge (belief, goal and plan)

2 Services – which allows to expose the agent services

3 PlanExecution – which exposes events related to the execution of agents’ plans

4 LearningKnowledge – used to update the agent domain-specific knowledge based on machine learning techniques.

KnowledgeUpdating is a provided interface which defines operations such as addBelief(), setGoal(), addPlan() and removePlan() (Figure 3). These operations are called by other components, such as Adaptation and Autonomy in order to update the agents’ knowledge (Figure 2).

Figure 2 The AspectT architecture

tnegAnoitaitnatsnI

egdelwonKgnitadpU

BehaviournoitatpadA

lenreKsecivreS

egdelwonKnoitatpadA

levarT

egasseMnoitpeceR

noitcaretnI

noitatpadA

noitucexEymonotuA

ymonotuA

gnidniB

noitaroballoC

egasseMgnidneS

tnemnorivnE

egdelwonK

yrosneS

noitamrofnIgnirehtaG

gninraeLegdelwonK

gninraeL

noisiceDgnikaM

nalPnoitucexE

niamoDegdelwonK

ytiliboMBehaviour

CollaborationBehaviour

:dnegeL

tnenopmoc

ecafretni dedivorpecafretni deriuqer

ecafretni gnittucssorc

tnenopmoc lautcepsa

pihsnoitaler gnittucssorc

ytiliboM


Figure 3 Details of AspectT interfaces

lenreKsecivreSniamoD

egdelwonK

gnitadpUegdelwonK>>ecafretni_dedivorp<<

)(feileBdda)(laoGtes)(nalPdda

)(nalPevomer…

noitucexEnalP>>ecafretni_dedivorp<<

)(tneve_liaFnalp)(tneve_hsiniFnalp

……

noitcaretnIyrosneS

noitpeceRegasseM>>ecafretni_gnittucssorc<<

)(egasseMeviecer

)(_egasseMgnimocni

gnidneSegasseM>>ecafretni_gnittucssorc<<

)(egasseMdnes…

)(_egasseMgniogtuo

noitatpadA

noitatpadAegdelwonK>>ecafretni_gnittucssorc<<

)(feileBtpada

)(_egasseMwen…

noitatpadAruoivaheB>>ecafretni_gnittucssorc<<

)(rouivaheBtpada…

)(_nalPdeliaf)(_nalPdehsinif

gnitadpUegdelwonK>>ecafretni_deriuqer<<

)(feileBdda)(laoGtes)(nalPdda

)(nalPevomer…

:dnegeL

tnenopmoc

ecafretni dedivorpecafretni gnittucssorc

tnenopmoc lautcepsa

pihsnoitaler noitatnemelpmi

A set of aspectual components are used to address different crosscutting agent concerns. Each of them either introduces new behaviour in other components or refines the components’ behaviour by observing specific services’ execution. The interaction aspect is used to modularise the crosscutting impact on the use of communication architectures, such as JADE (Lange and Mitsuru, 1998). The Interaction aspectual component specifies crosscutting interfaces for message receiving (MessageReception) and for message sending (MessageSending). For instance, the MessageSending interface observes events raised by other components (outgoing message events) in order to know when it is time to send a message. Messages are sent by means of the execution of the SendMessage() operation (Figure 3). For instance, the MessageSending interface observes the execution of the Mobility component; when an agent is about to move from the current environment, the Mobility component raises an event by means of its MobilityBehavior interface. Then, the Interaction component detects this event and sends a message to the other agents to inform them that an agent is leaving the environment.

The Adaptation component intercepts the MessageReception interface of the Interaction component by means of the KnowledgeAdaptation crosscutting interface. By means of the KnowledgeUpdating required interface, it updates the agent beliefs when new external messages are received. For instance, when a new message about a moving agent is received, the Adaptation component detects it. Then it uses the adaptBelief() operation in its KnowledgeUpdating interface (Figure 3) to require the Kernel component to adapt the other agents’ belief, making them aware about the moving agent.


The Autonomy aspectual component defines two crosscutting interfaces:

1 DecisionMaking – cuts across the Interaction component to create new goals when new external messages are received

2 ExecutionAutonomy – associates the agent with its own thread of control and also makes it possible the concurrent execution of agent plans.

The Collaboration, Mobility and Learning components encompass crosscutting agent properties that are necessary only on specific agent architectures.

The Collaboration component contains two crosscutting interfaces:

1 Knowledge – introduces new knowledge associated with roles to be played by the agent

2 Binding – affects specific services from the Kernel component in order to instantiate new roles and attach them to the agent according to certain conditions.

It also contains a provided interface – CollaborationBehavior – which raises collaboration events. The Interaction aspectual component observes these events in order to know when it is time to send a message.

The Mobility aspect is used to overcome the crosscutting nature of mobility concerns caused by the direct use of existing mobility platforms (Lange and Mitsuru, 1998). The Mobility component uses the Travel interface to introduce mobility capacities to the agent and to determine the execution points in which the agent can be moved. Finally, the Learning component is responsible for collecting information to execute its learning algorithms (InformationGathering interface). It also introduces new learning-specific knowledge associated with these algorithms (LearningKnowledge interface). The AspectT framework has been developed as an alternative to an equivalent object-oriented mediator-based architecture, presented in Section 3.2. The latter defines a central component which mediates all the communication between the other ones. The Kernel component plays this central role.

4.2 The MobiGrid architecture

Our second case study was the MobiGrid framework (Barbosa and Goldman, 2004; Lobato et al., 2007), which is a mobile agent system within a grid environment system. In this system, the agents can migrate whenever the local machine is requested by its user since they are provided with automatic migration capabilities. The original MobiGrid architecture was defined based on the OO framework provided by the Aglets platform (Lange and Mitsuru, 1998), and follows a publisher-subscriber architecture pattern.

We have evaluated two versions of the MobiGrid architecture: an AO and a non-AO. In both solutions, the separation of the mobility concerns and the integration between MobiGrid and distinct mobility platforms respectively resulted in the conception of two architectural components: the MobilityProtocol and the MobilityManagement. Figures 4 and 5 illustrate the two versions of the MobiGrid architecture: the non-aspectual architecture and the aspect-oriented one. The former follows the publisher-subscriber architectural pattern; the latter is based on the aspect-oriented architectural pattern (Section 3.2).


Figure 4 The non-AO MobiGrid architecture

elcyCefiLIebircsbuS

ecnerefeRIelbaT

mroftalPytiliboMtnemeganaMytiliboM tnemeganaMytiliboM

mroftalPIemitnuR

ecnerefeRIrevresbO

locotorPytiliboM locotorPytiliboM

noitcurtseDItnevE

mroftalPIsecivreStnegAeliboMI

dirGiboMlocotorPIsecivreS

tnegAeliboMIlocotorP

ecnerefeRItnegAeliboM

:dnegeL

tnenopmocecafretni dedivorpecafretni deriuqer

elcyCefiLIrehsilbuP

ecnerefeRIrebircsbuS

mroftalPIebircsbuS

mroftalPIrehsilbuP

noitacilppAItnegA

elcyCefiLytiliboMIrevresbO

noitcurtseDIrotagaporP

noitasilaitinIItnevE

noitasilaitinIIrotagaporP

noitargiMItnevE

noitaitnatsnIItnevE

noitaitnatsnIIrotagaporP

noitargiMIrotagaporP

elcyCefiLytiliboMIrebircsbuS

Figure 5 The AO MobiGrid architecture

eliboMItnemelE

noitacilppAItnegA

noitcurtseDItnevE

dirGiboM

ecnerefeRItnegAeliboM

noitasilaitinIItnevE

noitargiMItnevE

noitaitnatsnIItnevE

:dnegeL

tnenopmoc

ecafretni dedivorp

ecafretni deriuqer

ecafretni gnittucssorc

tnenopmoc lautcepsa

pihsnoitaler gnittucssorc

locotorPytiliboM

ecnerefeRIelbaT mroftalPytiliboM

mroftalPIsecivreS

tnegAeliboMI

mroftalPIstnevEecnerefeRI

revresbO

mroftalPIemitnuRtnemeganaMytiliboM

tnegAeliboMIlocotorP

In both cases, the MobiGrid architecture is composed of four kinds of components:

1 MobiGrid component, which modularises the basic concerns of an agent-based application

2 MobilityProtocol component, which modularises the mobility protocol execution – i.e., the instantiation, migration, remote initialisation, and destruction of MobiGrid agents


3 MobilityManagement component, which provides a flexible integration between MobiGrid and distinct mobility platforms

4 MobilityPlatform, which represents a specific mobility platform being used, such as Aglets (Lange and Mitsuru, 1998).

In both architectures, the main purpose of the MobilityProtocol component is the explicit separation of the mobility concerns from the MobiGrid component. In addition, the MobilityManagement component connects the MobiGrid with the MobilityPlatform component, which modularises and externalises the platform services.

The AO architecture in Figure 5 uses the crosscutting interface abstraction (Section 3.2) to make it possible a clean modularisation of the mobility concern in the MobiGrid. The MobilityProtocol component now implements a generic mobility protocol in order to prevent the explicit invocations of the mobility services by the MobiGrid component. Such explicit invocations happen in the non-AO architecture due to the interaction constraints imposed by the publisher-subscriber pattern. In other words, we invert the way in which access to the mobility services is typically designed in mobile agent systems. To do that, the IMobileElement crosscutting interface is used to determine when and how a mobile agent is instantiated on a platform to represent a specific agent on the MobiGrid. This interface also triggers the agent migration to other environments, since the mobile agent may have to migrate whenever elements of the MobiGrid are called or executed. That is, the IMobileElement interface is used to affect well-defined mobility join points in order to determine when MobiGrid agents should move. Thus, the IMobileElement interface allows an explicit separation of mobility issues from the other MobiGrid non-crosscutting concerns.

4.3 Evaluation procedures and assessment metrics

Our evaluation process has strictly focused on the assessment of architecture artefacts, since we are concerned with both:

• understanding the suitability of existing MAS architecture-level solutions in order to address the modularity problems associated with widely-scoped crosscutting properties

• investigating to what extent the crosscutting nature of certain MAS properties entail design anomalies visible earlier at the architecture stage.

The used architecture descriptions were based on conventional and aspect-oriented component-and-connector models (Kulesza et al., 2004). The evaluation has been basically rooted at the component-and-connector view (Bass et al., 2003) of the architectures, as they subsume the core abstractions in architecting processes, such as components, interfaces, and their relationships. They are also the models supported by a plethora of ADLs and, more notably, by UML.

We have used a suite of architectural metrics (Table 2) to support modularity evaluation of the investigated software architectures (Sections 4.1 and 4.2). We have not used conventional architectural assessment methods because they traditionally focus either on the architecture coverage of scenarios described in the requirements specification (Clements et al., 2002) without a clear focus on modularity assessment. Our


goal here was to assess structural attributes (Table 2) in the architecture description with a direct impact on architecture modularity. As a consequence, our investigation has provided us with a more fine-grained understanding of the overall architecture quality since modularity impacts a huge number of non-functional requirements in MAS, such as reusability, adaptability, flexibility, and changeability.

Table 2 Architectural metrics suite

Attribute Metric Definition Viewpoint

Architectural separation of concerns

Concern Diffusion over Architectural Components (CDAC)

Counts the number of architectural components which encompass a concern.

Concern

Concern Diffusion over Architectural Interfaces (CDAI)

Counts the number of interfaces related to a concern.

Concern Diffusion over Architectural Operations (CDAO)

Counts the number of operations (defined in architectural interfaces) that are related to a concern.

Architectural coupling

Architectural Fan-in Counts the number of components which require service from a component (caller components). It counts the number of components, not connections.

Component

Architectural Fan-out Counts the number of components from which the component requires service (callee components). It counts the number of components, not connections.

Component cohesion

Lack of Concern-based Cohesion (LCC)

Counts the number of concerns addressed by a component.

Interface complexity

Number of interfaces Counts the number of interfaces of each component. It does not differentiate among provided, required or crosscutting interface.

Number of operations Counts the number of operations in the interfaces of each component.

In some cases, when a concrete usage scenario requires the adaptation or reuse of an architectural concern, its adaptability or reusability is hindered if the concern is not well modularised. For instance, some researchers claims that in many existing middleware systems the goal of customising some features had been unattainable because these features did not exist in modular forms, that is did not have clear modular boundaries, and were tangled with other concerns (Zhang and Jacobsen, 2004). Therefore, in our case studies we assessed the modularity of the architectures in order to analyse which solution were less prone to hinder the evolution or reuse of the MAS concerns. A detailed discussion about the generic interplay between modularity and other external quality attributes is out of the scope of this paper.

We should bear in mind that in some specific situations, what the metrics suggest as a better solution in terms of modularisation can affect negatively other architectural qualities, such as performance and availability. In this case, the outcomes of our analysis can be used in conjunction with other architectural assessment methods, such as ATAM, for performing a trade-off evaluation with respect to the scenarios that represent those


qualities. However, the trade-off analysis among architectural qualities can be different in each distinct system. In the systems studied in this paper, we did not had any restriction in terms of other architectural quality but modularity.

A discussion about each of those architectural metrics is out of the scope of this work. Table 2 presents a definition for each of the used metrics and their association with distinct modularity attributes. This suite includes metrics for architectural separation of concerns, architectural coupling, component cohesion and interface complexity. The metrics can also be classified in two categories according to the architectural viewpoint under assessment: concern viewpoint or component viewpoint. On one hand, the results of the SoC metrics are obtained for each concern of interest in the system. On the other hand, the results of the other metrics are all gathered for each component in the system architecture. Table 2 also relates the metrics to the viewpoint from which their values are obtained. For all the employed metrics, a lower value implies a better result.

The metrics of Separation of Concerns (SoC) measure the degree to which a single concern in the system maps to the architectural elements (components, interfaces, operations and parameters). The interface complexity is measured in terms of the total number of interfaces, operations and parameters of each component. The coupling metrics measure the number of components connected to each component. The cohesion metric computes each component’s semantic cohesion based on the number of concerns addressed by it. The higher the number of different concerns in the component the lower the cohesion is.

In order to proceed with the measurement of separation of concerns, there is an architecture shadowing process in which the architect must assign every component element (interface, operation and parameter) to one or more concerns. The chosen architectural concerns to be assessed are related to the driven architectural issues that should be modularised in each system. For example, in the AspectT case, we have shadowed the architecture artefacts with respect to the kernel, adaptation, interaction, autonomy, collaboration, mobility, and learning concerns because these are the properties that should be adaptable, reusable, and easily (un)plugged from the system. As in the MobiGrid system the design was much more focused on modularising specific mobility issues (Section 4.2), we treated each of the core mobility features (mobility platform, mobility protocol, and mobility management) and the MobiGrid application as driving concerns in order to investigate their associated crosscutting structures in both architectural solutions. After the shadowing of the architecture models, the data of the separation of concerns metrics (CDAC, CDAI, and CDAO) was manually collected.

5 Empirical results

This section presents the results of the measurement process. The data have been collected based on the set of defined measures (Section 4.3) in the two case studies. The presentation is broken in three parts. Section 5.1 presents the evaluation results for the separation of architectural concerns. Section 5.2 presents the results for the coupling and cohesion metrics. Section 5.3 presents the results for the interface complexity metrics. We present the results by means of tables that put side-by-side the values of the metrics for the AO and non-AO architectures of each system.


5.1 Separation of architectural concerns

In the quantitative evaluation of the AspectT framework, the data collected for both AO and mediator-based architectures shows favourable results for the AO version for most of the metrics used. Table 3 presents the complete data collected for both AspectT architecture versions considering the SoC metrics. These metrics count the total number of components, interfaces and operations dedicated to implement a concern (Section 4.3).

Table 3 AspectT architectures: separation of concerns measures

#components (CDAC) #interfaces (CDAI) #operations (CDAO)

Concern AO Non-AO AO Non-AO AO Non-AO

Kernel 1 1 4 2 68 14

Interaction 1 2 3 9 10 22

Adaptation 1 2 2 6 5 34

Autonomy 1 2 3 7 31 80

Collaboration 1 2 4 6 37 87

Mobility 1 2 3 3 20 35

Learning 1 2 2 4 6 16

We can observe significant differences between the AO and non-AO versions for all the SoC metrics. Table 3 shows that the mediator-based architecture requires two components to address each of the system concerns (CDAC metric), except for the Kernel concern. It happens because the Kernel component needs to inevitably embody functionalities from the different concerns besides to implement the kernel-specific functionalities. It occurs because the Kernel component plays the mediator role and, as a consequence, propagates information relative to every concern to the other ‘colleague’ components. On the other hand, each component in the AO version is responsible for implementing the functionalities associated with exactly one concern because such information is directly collected from the context where it is generated through crosscutting interfaces; as a result, the design of the Kernel component and its interfaces are not affected by other concerns.

We can also observe in Table 3 that the AO version requires fewer interfaces (CDAI metric) and operations for most of the system concerns with exception of the Kernel concern. The Kernel concern in the AO version is represented by the Kernel component. This component needs to expose new interfaces in the AO version to enable the implementation of the different aspectual components. However, all these additional interfaces are part of the Kernel functionalities and separation of architectural concerns is not hindered.

Table 4 shows the results for the three SoC metrics for the MobiGrid architectures. The AO architecture performed better than the publisher-subscriber one in terms of SoC. As shown in Table 4, the mobility concerns are scattered over fewer architectural components in the AO architecture (CDAC metric). These concerns are present in four components in the non-AO architecture, whereas they crosscut only three components in the AO architecture. This occurs because, in the non-AO architecture, the MobiGrid component encompasses two mobility-related interfaces


– IMobilityLifeCycleObserver and IMobilityLifeCycleSubscriber – for explicitly handling of mobility life cycle events. These events are captured by the IMobileElement crosscutting interface in the AO architecture. Although this difference seems to be not striking, the AO architecture makes the mobility-related interfaces unnecessary in the MobiGrid component.

Table 4 MobiGrid architectures: separation of concerns measures

#components (CDAC) #interfaces (CDAI) #operations (CDAO)

Concern AO Non-AO AO Non-AO AO Non-AO

Mobility 3 4 13 23 326 407

Application (MobiGrid) 1 1 1 1 18 18

The SoC metrics also showed better results for the AO architecture in terms of number of interfaces (CDAI metric) – 13 versus 32 – and number of operations (CDAO metric) – 326 versus 407. This is mainly caused because the MobilityProtocol and MobilityManagement aspectual components need fewer interfaces and operations for handling events. This will be further discussed in Subsection 5.3.

5.2 Architectural coupling and component cohesion

Tables 5 and 6 present the results for architectural coupling and component cohesion metrics considering, respectively, the AspectT and MobiGrid architectures. As in Subsection 5.1, the tables in this subsection and in Subsection 5.3 put side-by-side the metrics values for the AO and non-AO architectures. However, since the values here are for each component (component viewpoint), the bottom of the tables also provide the total values (sum of all the component measures) that represent the results for the overall architecture viewpoint. Therefore, rows labelled ‘Total’ indicate the tally for the system architecture, while rows labelled ‘Diff’ indicate the difference (in percentage) between the AO and non-AO architectures in the system viewpoint relative to each metric. A positive value means that the non-AO architecture fared better, whereas a negative value indicates that the AO architecture exhibited better results.

Table 5 AspectT architectures: coupling and cohesion measures

Architectural fan-out Architectural fan-in #Concerns (lack of cohesion)

Component AO Non-AO AO Non-AO AO Non-AO

Kernel 0 6 5 5 1 7

Interaction 3 2 2 2 1 1

Adaptation 2 1 0 1 1 1

Autonomy 2 1 0 1 1 1

Collaboration 1 1 1 1 1 1

Mobility 2 1 1 1 1 1

Learning 1 0 0 1 1 1

Total 11 12 9 12 7 13

Diff –8.3% –25.0% –46.2%


Table 6 MobiGrid architectures: coupling and cohesion measures

Architectural fan-out Architectural fan-in #Concerns (lack of cohesion)

Component AO Non-AO AO Non-AO AO Non-AO

Mobility Platform 0 1 1 1 1 1

Mobility Manager 1 2 1 2 1 1

Mobility Protocol 2 2 0 2 1 1

MobiGrid 0 1 1 1 1 2

Total 3 6 3 6 4 5

Diff –50.0% –50.0% –20.0%

As we can observe in Table 5, there is an expressive coupling increase in the non-AO AspectT architecture considering the number of requiring components (Architectural Fan-in metric). The fan-in is 12 in the mediator-based architecture, while it is nine in the AO architecture, representing a difference of 25% in favour of the latter. This occurs because in the AO version the services of several aspects (e.g., Adaptation, Autonomy, Learning) are not requested by other components granted to the dependency inversion promoted by AO architectures.

As stated in Section 4.3, we assess the lack of cohesion of a component counting the number of distinct concerns addressed by it, which is captured by the Lack of Concern-based Cohesion (LCC) metric. LCC measurement resulted in better results for the AO version (13 versus 7 = 46.2%). This superiority is justified by the fact that in the mediator-based architecture, the Kernel component needs to implement required interfaces associated with the six system concerns (CBLC metric). Hence, there is an explicit architectural tangling in the Kernel component.

The AO architecture of the MobiGrid system presented better outcomes in terms of the two coupling metrics and in terms of the cohesion metric as well (Table 6). The non-AO architecture exhibited architectural fan-out 50% higher than the AO architecture. This difference is a consequence of the reduction of fan-out in both MobiGrid and MobilityManagement components in the AO version, since they do not have to explicitly call the MobilityProtocol component for notifying events. Being an aspectual component, MobilityProtocol captures the events by means of crosscutting interfaces. MobilityPlatform also contributes for decreasing the fan-out, because it does not need to be connected to the MobilityManagement component in order to notify events. In this case, the aspectual MobilityManagement component observes the events by means of its IReferenceObserver crosscutting interface. For the same reasons, the architectural fan-in metric also showed worse results for the publisher-subscriber version of the architecture (50% higher). In this case the fan-in reduction is observed in the MobilityProtocol and MobilityManagement components.

5.3 Interface complexity

Tables 7 and 8 show the results for the interface complexity metrics for the AspectT and MobiGrid architectures, respectively. Regarding the AspectT system (Table 7), the metrics demonstrate the modularity benefits obtained in the AO version compared to the


non-AO one. There was a bigger difference in the number of interfaces specified for each version (35 versus 22 = 37.1%) which favours the AO version. This difference is mainly due to the additional interfaces of the Kernel component, but it is also thanks to the values collected for other components. The increase in the number of interfaces metric for the mediator version is also reflected in the number of operations. Table 7 shows that the number of operations is 38.5% higher in the non-AO version. Again, it happens because the Kernel component plays the mediator role and, as a consequence, it has additional interfaces and operations to propagate information relative to every concern to the other ‘colleague’ components (Section 5.1).

Table 7 AspectT architectures: interface complexity metrics

#Interfaces #Operations

Component AO Non-AO AO Non-AO

Kernel 4 16 68 115

Interaction 3 5 10 13

Adaptation 3 4 5 29

Autonomy 3 4 31 49

Collaboration 4 4 37 47

Mobility 3 2 20 19

Learning 2 2 6 16

Total 22 35 177 288

Diff –37.1% –38.5%

Table 8 MobiGrid architectures: interface complexity metrics

#Interfaces #Operations

Component AO Non-AO AO Non-AO

MobilityPlatform 3 4 176 185

Mobility Management 4 9 124 155

MobilityProtocol 6 8 26 61

MobiGrid 1 3 18 24

Total 14 24 344 425

Diff –41.7% –19.1%

The use of aspects had a strong positive influence in the interface complexity of the MobiGrid architectural components, as shown in Table 8. For the non-AO architecture, the number of interfaces was more than 40% higher than in the AO solution. Also, the number of operations was higher in the non-AO solution (19.1%). The main reason for this result is the decrease on the number of required interfaces of the MobilityManagement aspect. In the non-AO solution, the conventional component has four required interfaces to propagate four mobility events relative to the initialisation, migration, destruction and instantiation of agents. These events are observed by the IReferenceObserver interface and propagated to the MobilityProtocol component. On the other hand, in the AO solution, the aspectual component


MobilityProtocol crosscuts the IReferenceObserver interface and directly observes the events when MobilityPlatform notify them. Hence, the required interfaces to propagate them are not necessary. Moreover, the inferiority of the non-AO version in the number of interfaces is granted to the fact it needs additional pairs of subscription interfaces involving the collaboration of the components MobilityManagement and MobilityPlatform, and the components MobilityProtocol and MobiGrid components.

6 General analysis and related work

This section provides a more general analysis with respect to modularity breakdowns observed in the results previously presented in Section 5. This section also brings discussions on how such results and conclusions are connected to observations made by related work.

6.1 Detecting early modularity anomalies in MAS architectures

The use of the architectural modularity metrics (Section 4.3) allowed us to observe some early design anomalies in the investigated MAS architectures. Our observations are classified into three main categories: (a) bidirectional architectural coupling, (b) architectural interface bloat, and (c) hindering of architectural variability and adaptability.

6.1.1 Bidirectional architectural coupling

First, after a careful joint analysis of the MobiGrid and AspectT architectures, we observed that both non-AO options – i.e., the mediator-based and the publisher-subscriber designs – imposed some undesirable bidirectional couplings. In the mediator architecture, all the ‘colleague’ components need to inevitably have references to the ‘mediator’ component and vice-versa. Similarly, in mediator-based architectures, all the ‘subscriber’ components need to know the ‘publisher’ components and vice-versa. Even though these architectural solutions overcome the problem of direct couplings between colleagues and between subscribers, the AO architectural solutions for both MobiGrid and AspectT systems have reduced even more the overall architecture couplings by making almost all the inter-component relationships unidirectional (aspects affect the components). This phenomenon is observed mostly from the fan-in and fan-out measures (Section 5.2). For example, the Kernel component has the fan-out zero in the AO version of the AspectT architecture, while it is six in the mediator version (Table 5). Also, Adaptation, Autonomy and Learning components have a fan-in zero.

6.1.2 Architectural interface bloat

The inter-component interaction constraints defined by the mediator-based and publisher-subscriber architectures did not scale respectively in the AspectT and MobiGrid systems, causing a complexity increase in the component interfaces. Such constraints have influenced the definition of extra operations and additional interfaces for the sake of realising certain crosscutting MAS concerns, such as mobility and learning issues. For example, the evidence of interface bloat can be observed in several parts of both


non-AO architectures. As discussed in Section 5.3, the Kernel component in the AspectT design (Table 7) and the MobiGrid component (Table 8) had clearly much ‘wider boundaries’ respectively due to their needs of mediating inter-component conversations and handling event subscriptions and notifications. In the particular case of MobiGrid, the event propagation is an issue that crosscuts the modularity of all the four architectural components.

6.1.3 Hindering of architectural variability and adaptability

Variability and adaptability were main driving requirements in the architecture design of both multiagent systems. For example, the design of the AspectT framework had the stringent requirement of making it optional the usage of the components Learning, Mobility, and Collaboration in order to allow for the flexible definition of heterogeneous agent architectures. In addition, the architecture design also required support for:

• adaptability of the Kernel elements, such as the provided services and agent plans

• adaptability of agent roles and protocols, which should be dynamically plugged and unplugged.

In the MobiGrid architectures, mobility issues should be modularised in order to promote easier variation and adaptation of the mobility platforms and protocols. However, the non-modularisation of architectural crosscutting concerns in the mediator-based and publisher-subscriber architectures hindered the satisfaction of these variability and adaptability goals. This problem can be observed in the SoC measures (Section 5.1) where the results in Tables 3 and 4 show the tangling and scattering of several concerns, such as mobility, learning, and collaboration. As a result, the plugability and adaptation of elements realising such concerns become cumbersome.

6.2 Related work

The body of knowledge on the interplay of MAS and software architecture has been mostly concentrated on suggesting and implementing new MAS architectures (Garcia and Lucena, 2006; Amandi and Price, 1998; Weyns et al., 2005; Camacho, 2003; Dong et al., 2005; Novák and Dix, 2006). In particular, aspect-oriented software architectures (Garcia and Lucena, 2006; Garcia et al., 2003; Amor et al., 2004; Seiter et al., 2006) are emerging as a promising way to develop modular MAS. However, less attempts has been done in studying how these architectures may be evaluated against modularity criteria (Davidsson et al., 2005; Shehory, 2000). To the best of our knowledge, no work has clearly indicated a framework on how to assess MAS architecture modularity and performed systematic case studies on the basis of such modularity evaluation framework.

Amandi and Price (1998) propose an agent architecture which explores meta-objects as abstractions to support the modularisation of agent concerns. In their architecture, each agent concern is modularised in specific meta-objects and associated with based-level objects, which implement the agents basic concerns. Camacho (2003) defines a mediator-based architecture which aims at supporting cooperation and knowledge sharing between agents in a distributed environment. Novák and Dix (2006) propose a modular


BDI agent architecture. The architecture consists of independent components for beliefs, desires, intentions and agents capabilities, which are glued together by rules governing their interactions in terms of component queries and updates.

An event-based blackboard architecture for MAS is defined in Dong et al. (2005). This approach uses the blackboard pattern (Buschmann et al., 1996) composed with the implicit invocation pattern (Buschmann et al., 1996) in order to manage the access of central repository by agents. Garcia and Lucena (2006) defined how to use an aspect-oriented design pattern to flexibly build heterogeneous agent architectures. They have also described guidelines to transit from the aspect-oriented definition of agent architectures to AspectJ-like (Kiczales et al., 2001) implementations. All these previous works propose architecture approaches which aim at improving MAS modularity. However, they do not evaluated the proposed approaches in the context of quantitative studies that systematically guide the architects to choose an architecture alternative.

Davidsson et al. (2005) used an Analytic Hierarchy Process to compare six MAS architectural styles for handling the task of dynamic and distributed resource allocation. Woods and Barbacci (1999) used the Architecture Tradeoff Analysis Method (ATAM) (Clements et al., 2002) for evaluating quality attributes of the agent-based system architectures. Similarly, Ivezic et al. (2000) used an ATAM-based methodology to assess different architecture alternatives for a supply chain management MAS. Shehory (2000) studied MAS architectural properties to support the assessment of MAS suitability to solution computational problems. Three MAS case studies were undertaken in order to demonstrate how the different architectural properties affects the system functionality. Although all these works encompass studies on MAS architecture evaluation, none of them have focused on supporting the assessment of modularity attributes in the studied architectures.

In this work, we have not focused on assessing existing reference architectures (Clements et al., 2002) for MAS such as the one proposed in Weyns et al. (2005), which may be seen as a complementary abstraction to be exploited at architectural stage. Reference architectures can embody one or more architectural patterns. As a result, we have centred on the assessment and comparison of architectural patterns, which may be seen as one of the most basic building blocks in MAS architectural decompositions. Further work could explore the evaluation of existing MAS reference architectures.

Garcia et al. (2003) developed a quantitative study which compared the AO and OO versions of a MAS using traditional software metrics. This quantitative study focused more at the design and implementation levels as opposed to this work which focuses more at the architecture evaluation. These authors also explored the analysis of evolution scenarios, such as the change of agent roles and creation of new agent types. The study results showed that the AO version of the investigated MAS brought better results than the OO version in terms of reuse and maintenance of the MAS concerns. This is a similar conclusion to the results presented in this paper.

Within the area of architecture assessment, there are only few works about architecture metrics related to modularity analysis. For instance, Briand et al. (1993) define architecture metrics for coupling, cohesion and visibility based on the module abstraction. Martin (1997) defines coupling metrics resting on the object-oriented package abstraction. In fact, our architectural coupling metrics (Table 2) were inspired on Martin’s metrics. However, none of these works applies those metrics to evaluate modularity in the context of MAS architectures.


6.3 Study constraints

The added value of our study was that it relied on a quantitative evaluation approach which focuses on architectural concerns as measurement abstractions. Although typical architecture modularity problems are related to the inadequate modularisation of concerns, a number of quantitative assessment methods are targeted at guiding decisions related to modularity without calibrating the measurement outcomes to the driving architectural concerns. It imposes certain shortcomings, such as the ineffective identification of desirable and undesirable couplings. However, the used approach imposes the identification and mapping of the concerns to the architecture elements. This task is timing-consuming and must be done by an architect who has previous knowledge of the assessed architecture alternatives.

Other limitation of our study is that our current suite of metrics considers crosscutting and conventional interfaces in the same way when measuring interface complexity. However, crosscutting interfaces are semantically richer than the conventional ones, because, besides providing services by means of operations, they also specify how and when they affect the other interfaces by means of pointcut expressions (Section 2.3). Nevertheless, we decided to use these metrics anyway, because we understand that operations and pointcut expressions are different abstractions and cannot be considered in the same metric. Hence, our interface complexity metrics were used to compare complexity in terms of the amount of provided and required services between the different architecture alternatives. In the future, we plan to define metrics that consider the complexity caused by pointcut expressions.

We should also emphasise that the conclusions obtained from our study are restricted to the specific assessed systems, chosen architecture alternatives and analysed concerns. On other words, results may not be directly generalised to other contexts. However, these examples allow us to make useful assessments of whether the use of architectural aspects for the modularisation of MAS concerns would be worth studying further. In spite of its limitations, the study constitutes an important empirical work.

7 Concluding remarks and future work

Modularity occupies a pivotal position in the design of good MAS architectures. It is during architectural design that crucial modularity-related requirements in MAS such as adaptability, flexibility, reusability, maintainability, testability, etc., must be addressed. Yet the task of considering the multi-dimensional facets of modularity remains a deep challenge to MAS architects. As adaptability, reusability, and maintainability are typically driving requirements in MAS designs, the architectural pattern that provides the most appropriate balance between the modularity attributes should be selected. However, building modular MAS architects is a challenging task mainly because they need to reason and make decisions with respect to a number of crosscutting architectural concerns. MAS architects need to deal with issues such as making an agent interact appropriately, handling the agents’ adaptive behaviour, structuring the agents’ autonomous behaviour, designing the agent roles and protocols for inter-agent collaboration purposes, and incorporating learning mechanisms into the agent’s structure in a modular manner.


This paper is a first attempt to systematically evaluate the added value of aspect-oriented software architectures for designing MAS. Without a clear evidence of its strengths and drawbacks, MAS architects are not guided on when to use them. As previously discussed (Section 6.2), there is no systematic assessment on what extent such an emerging aspect-oriented MAS architectures scale in different circumstances and applications. This work provides a first understanding towards how to determine for the use of aspects early at the design of adaptable and reusable MAS architectures in the presence of crosscutting concerns. A number of additional studies in the future should be performed to improve our body of knowledge regarding the interplay of aspects and MAS architectures. A next step in our assessments is to evaluate aspect-oriented MAS architectures in the light of different architectural attributes other than modularity issues, such as performance and availability. It would allow us to have a more broad understanding of when and when not using such an architectural style for MAS.

Acknowledgements

This work is partially supported by European Commission Grant IST-2-004349: European Network of Excellence on AOSD (AOSD-Europe). Claudio is supported by CAPES-Brazil under Grant No. 3651/05-3. The authors are also supported by ESSMA Project under grant 552068/2002-0.

References Amandi, A. and Price, A. (1998) ‘Building object-agents from a software meta-architecture’,

14th Brazilian Symposium on Artificial Intelligence (SBIA 1998), pp.21–30.

Amor, M., Fuentes, L. and Troya, J.M. (2004) ‘Training compositional agents in negotiation protocols using ontologies’, Journal of Integrated Computer-Aided Engineering, Vol. 2, No. 11, pp.179–194.

Barbosa, R.M. and Goldman, A. (2004) ‘MobiGrid’, International Workshop on Mobility Aware Technologies and Applications (MATA 2004), LNCS 3284, pp.147–157.

Bass, L., Clements, P. and Kazman, R. (2003) Software Architecture in Practice, Addison-Wesley.

Bellifemine, F., Rimassa, G. and Poggi, A. (1999) ‘JADE A FIPA-compliant agent framework’, 4th International Conference on the Practical Applications of Agents and Multi-Agent Systems (PAAM 1999), UK, pp.97–108.

Booch, G. (1994) Object-oriented Analysis and Design with Applications, 2nd ed., Benjamin/Cummings.

Briand, L., Morasca, S. and Basili, V. (1993) ‘Measuring and assessing maintainability at the end of high level design’, ICSM ‘93: Proceedings of the Conference on Software Maintenance, IEEE Computer Society, pp.88–97.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons.

Camacho, D. (2003) ‘Coordination of planning agents to solve problems in the web’, AI Communications, Vol. 16, No. 4, pp.309–311.

Chan, S., Dillon, T. and Siu, A. (2002) ‘Applying a mediator architecture employing XML to retailing inventory control’, Journal of Systems and Software, Vol. 60, No. 3, pp.239–248.


Chavez, C., Garcia, A., Kulesza, U., Sant’Anna, C. and Lucena, C. (2006) ‘Taming heterogeneous aspects with crosscutting interfaces’, Journal of the Brasilian Computer Society (SBC), Vol. 12, No. 1, pp.43–58.

Chavez, C. and Lucena, C. (2001) ‘Design-level support for aspect-oriented software development’, in K. De Volder, M. Glandrup, S. Clarke and R. Filman (Eds.) Workshop on Advanced Separation of Concerns in Object-Oriented Systems (OOPSLA 2001), October.

Clements, P., Kazman, R. and Klein, M. (2002) Evaluating Software Architectures: Methods and Case Studies, USA: Addison-Wesley.

Davidsson, P., Johansson, S. and Svahnberg, M. (2005) ‘Characterization and evaluation of multi-agent system architectural styles’, SELMAS Workshop, LNCS 3914, pp.179–188.

Dijkstra, E. (1976) A Discipline of Programming, Prentice-Hall.

Dong, J., Chen, S. and Jeng, J-J. (2005) ‘Event-based blackboard architecture for multi-agent systems’, ITCC ‘05: Proceedings of the International Conference on Information Technology: Coding and Computing – Volume II, IEEE Computer Society, pp.379–384.

Elrad, T., Filman, R. and Bader, A. (2001) ‘Aspect-oriented programming: introduction’, Communications of the ACM, October, Vol. 44, No. 10, pp.29–32.

Garcia, A. (2004) ‘From objects to agents: an aspect-oriented approach’, PhD thesis, Pontificial Catholic University of Rio de Janeiro, Brazil, April.

Garcia, A., Chavez, C., Batista, T., Sant’Anna, C., Kulesza, U., Rashid, A. and Lucena, C. (2006) ‘On the modular representation of architectural aspects’, European Workshop on Software Architecture (EWSA 2006), France.

Garcia, A., Kulesza, U. and Lucena, C. (2004a) ‘Aspectizing multi-agent systems: from architecture to implementation’, in R. Choren, A. Garcia, C. Lucena and A.B. Romanovsky (Eds.) Software Engineering for Multi-Agent Systems (SELMAS 2004), Springer, Vol. 3390 of Lecture Notes in Computer Science, pp.121–143.

Garcia, A. and Lucena, C. (2006) ‘Taming heterogeneous agent architectures with aspects’, Communications of the ACM, June, to appear.

Garcia, A., Lucena, C. and Cowan, D.D. (2004b) ‘Agents in object-oriented software engineering’, Software: Practice and Experience, Vol. 34, No. 5, pp.489–521.

Garcia, A., Sant’Anna, C., Chavez, C., da Silva, V.T., Lucena, C. and von Staa, A. (2003) ‘Separation of concerns in multi-agent systems: an empirical study’, SELMAS Workshop, LNCS 2940, pp.49–72.

Helsinger, A., Thome, M. and Wright, T. (2004) ‘Cougaar: a scalable, distributed multi-agent architecture’, SMC, IEEE, No. 2, pp.1910–1917.

Ivezic, N., Barbacci, M., Robert, J., Libes, D. and Potok, T.E. (2000) ‘An analysis of a supply chain management agent architecture’, International Conference on Multi-Agent Systems (ICMAS 2000), pp.401–402.

Kendall, E., et al. (1999) ‘Implementing application frameworks – OO frameworks at work’, Chapter A Framework for Agent Systems, John Wiley & Sons.

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J. and Griswold, W.G. (2001) ‘Getting started with AspectJ’, Communications of the ACM, October, Vol. 44, No. 10, pp.59–65.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J-M. and Irwin, J. (1997) ‘Aspect-oriented programming’, 11th European Conference on Object-Oriented Programming, LNCS 1241, Springer-Verlag, pp.220–242.

Kulesza, U., Garcia, A. and Lucena, C. (2004) ‘Towards a method for the development of aspect-oriented generative approaches’, Early Aspects Workshop at OOPSLA 2004.

Lange, D.B. and Mitsuru, O. (1998) Programming and Deploying Java Mobile Agents Aglets, USA: Addison-Wesley Longman Publishing Co., Inc.

Lobato, C., Garcia, A., Kulesza, U., Staa, A. and Lucena, C. (2007) ‘On the framework evolution with aspects: the MobiGrid case’, International Conference on Software Maintenance (ICSM 2007), submitted.


Lobato, C., Garcia, A., Lucena, C. and Romanovsky, A. (2006) ‘A modular implementation framework for code mobility’, IEE Mobility Conference.

Martin, R. (1997) ‘Stability’, C++ Report, February.

Meyer, B. (1997) Object-Oriented Software Construction, 2nd ed., Upper Saddle River, NJ: Prentice-Hall, Inc.

Novák, P. and Dix, J. (2006) ‘Modular BDI architecture’, AAMAS ‘06: Proceedings of the Fifth International Joint Conference on Autonomous Agents and Multi-Agent Systems, ACM Press, pp.1009–1015.

Parnas, A.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, December, Vol. 15, No. 12, pp.1053–1058.

Pinto, M. and Fuentes, L. (2007) ‘AO-ADL: an ADL for describing aspect-oriented architectures’, Early Aspects Workshop: Current Challenges and Future Directions at AOSD’07.

Seiter, L.M., Palmer, D.W. and Kirschenbaum, M. (2006) ‘An aspect-oriented approach for modeling self-organizing emergent structures’, International Workshop on Software Engineering for Large-scale Multi-Agent Systems (SELMAS 2006), USA, pp.59–66.

Shehory, O. (2000) ‘Software architecture attributes of multi-agent systems’, International Workshop on Agent-Oriented Software Engineering (AOSE 2000) at AAMAS 2000, LNCS 1957, pp.77–90.

Ubayashi, N. and Tamai, T. (2001) ‘Separation of concerns in mobile agent applications’, 3rd International Conference on Metalevel Architectures and Separation of Crosscutting Concerns (Reflection 2001), UK, pp.89–109.

Weiss, G., Rovatsos, M. and Nickles, M. (2003) ‘Capturing agent autonomy in roles and XML’, 2nd International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS 2003), USA, pp.105–112.

Weyns, D., Schelfthout, K., Holvoet, T. and Lefever, T. (2005) ‘Decentralized control of E’GV transportation systems’, International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS 2005), USA, pp.67–74.

Woods, S. and Barbacci, M. (1999) ‘Architectural evaluation of collaborative agent-based systems’, Technical Report CMU/SEI-99-TR-025, Software Engineering Institute, Carnegie Mellon University, PA, USA.

Zhang, C. and Jacobsen, H-A. (2004) ‘Resolving feature convolution in middleware systems’, OOPSLA ‘04, pp.188–205.

Note 1 ‘IEEE standard glossary of software engineering terminology’, IEEE Std 610.12.

cláudio sant’anna*, cidiane lobato and uirá...

Documents