Assisting the Development of Aspect-based Multi-Agent Systems ...

Assisting the Development of Aspect-based Multi-Agent Systems using the SmartWeaver Approach J. Andrés Díaz Pace*

Federico U. Trilnik*

Marcelo R. Campo

ISISTAN Research Institute, Facultad de Ciencias Exactas, UNICEN University Campus Universitario, (B7001BB0) Tandil, Buenos Aires, Argentina *Also CONICET-Argentina E-mail:{adiaz,ftrilnik,mcampo}@exa.unicen.edu.ar

Abstract. The spreading of multi-agent systems (MAS) in software development, combined with object techniques such as frameworks, has been fostering new ways of designing applications regarding adaptability and autonomy. However, despite these strengths, agency features have also introduced more complexity into the design process, because they tend to be not orthogonal respect to object structures. Therefore, developers usually have to understand, select and organize a broad set of features when using MAS frameworks. In order to tackle these problems, this paper proposes a tool called Smartweaver, which basically provides assistance for the development of aspect applications based on object-oriented frameworks. As the tool is targeted to aspect-based development, agency properties are captured and kept separated from object functionality by means of aspectual relationships. Therefore, the approach allows developers to better take advantage of MAS patterns, components and frameworks.

1 Introduction Current trends in software development are increasingly reasoning about software applications in terms of multi-agent systems (MAS) (Jennings, 1999). The adoption of the agent paradigm involves necessarily new ways of conceiving systems, emphasizing properties such as modularity, autonomy, distribution and adaptability. However, despite agent benefits, the development of MAS has been mostly homegrown (Bradshaw, 1997) and it still requires an important grasp of experience and design skills. This fact has somehow limited the application of MAS in real-life applications. Nonetheless, it is reasonable to argue that a combination of agent with object-oriented techniques can contribute to provide computational models promoting better modularity and adaptability. In particular, object-oriented frameworks (Fayad et.al., 1999) can play a key role in this context. They can be useful means to express reusable designs and capture the essence of (agent) patterns, components, algorithms and architectures Besides, as it is stated by (Garcia and Lucena, 2000), the introduction of agents in object models poses additional problems, because many agent features are sometimes

intrusive or not orthogonal respect to object structures. As regards MAS frameworks, developers generally have to understand, select and organize a broad set of agency properties in order to build their applications (DiazPace, 2001). For these reasons, technologies like aspects have goods credits to address the issue of expressing these features more cleanly, so that core object functionality is kept separated from its crosscutting agency concerns. In this paper, an aspect-based CASE environment called Smartweaver (DiazPace et.al., 2002) and its application for assisting MAS development is presented. The tool provides semi-automated support for the development of systems using objectoriented frameworks. It was built under the Smartbooks approach (Ortigosa et.al., 2000), a documentation method to improve framework usability based on the idea of assistant agents. Thus, given the complexity of MAS frameworks, the method is tailored to this kind of frameworks, and also complemented with aspect-based design to deal with agency concerns. Essentially, framework developers supply to a special planning agent beforehand with structured knowledge on how to derive applications on top of the target framework. At the instantiation phase, the framework user can select different functionality items. Then, taking the list of selected requirements, the agent constructs an instantiation plan that consists of a set of tasks to be accomplished in some meaningful in order to produce a final application. To do the work, the tool relies also on some underlying framework support for both multi-agent systems and aspects. The rest of the paper is organized into 5 sections. In section 2, we discuss the suitability of frameworks to support MAS and aspects, and also describe two specific frameworks. Section 3 introduces the Smartweaver approach itself. Section 4 presents a workflow case-study based on a real-life system, and illustrates how the approach proceeds. In section 5, we analyze some related work. Finally, section 6 rounds up the conclusions of the work.

2 Underlying framework support From an object-oriented perspective, frameworks can be seen as open languages to capture both agent models and aspects, offering a general and reusable skeleton of classes and behavior patterns for a given domain. With the Smartweaver approach, we aim to somehow automate the activities dictated by framework documentation. Hence, the engine initially requires the definition of some framework infrastructure for agents and aspects before the assistantship process can take place. In the case of multi-agent systems, a MAS framework (Chauhan, 1997; Kendall et.al., 1999) usually permits the construction of different types of agents with several properties/capabilities, and it allows programmers to extend or adapt certain components/patterns according to the application requirements. This is accomplished by means of the traditional mechanisms for reuse available at the framework level (e.g., abstract methods, inheritance, template and hook methods) (Fayad et.al., 1999). Likewise, in the case of aspects, an AOP framework (Constantinides et.al., 2000) typically supports the definition of both aspects and crosscutting points, allowing programmers to customize aspects and relationships among them. In addition, the

framework may enable the implementation of general (and flexible) policies for aspect handling. In this context, we briefly describe two specific examples of a MAS framework and an AOP framework respectively, which will serve later as basis for the development of the approach. • Bubble: It is an object-oriented framework developed using a multi-agent approach based on reactive agents (Diaz Pace and Campo, 2002). The basic elements of the system are agents (Demazeau and Muller, 1990) described by an internal state and a set of executable tasks. The interaction among these agents is performed through events that the agents produce and receive. The agents are also equipped with associated sensors (like filters) that are registered to hear certain kinds of events with a defined criterion of relevance (local, by group, by event strength, regional, etc.). The behavior of a reactive agent is defined through tasks using a condition-action style, i.e. a task is a module composed by a series of actions to be executed by the agent (action part) when certain conditions are fulfilled (condition part). Conditions can be related either to the internal state of the agent or incoming events. The framework also admits agents containing groups of other agents, and tasks composed by groups of predefined tasks. The framework Bubble has been used to implement several simulation applications for different domains, and yet more importantly, it has supported the development of other frameworks. In particular, it supported the development of a software system called InQuality1, which provides a set of management tools oriented to structured document-based applications and quality control processes. For instance, one of the main components of the InQuality architecture is a workflow engine handling different types of documents, and it was actually implemented as a multi-agent system using Bubble (see section 4). • Aspect-Moderator: It is an aspect-oriented framework (Constantinides et.al., 2000) extending the object model, which provides support for a cluster of cooperating objects and their aspect behaviors. A specially designated component called moderator takes the place of the weaver, coordinating the interaction between functional components and aspects. This interaction refers both to semantics and activation order of aspects. The approach introduces the concept of aspect bank, where the moderator of a cluster may initially need to collect all the required aspects from, and then decide about the integration policies. A proxy object controls the access to the class functionality. This proxy object uses the factory pattern to create aspect objects for each method of the functional component that has to be associated with some aspects. Aspects are first class abstractions and upon creation they should be registered within the aspect moderator. Within the proxy, each participating method is guarded by a pre-activation and post-activation phase. These phases are implemented in the aspect moderator. During the former phase, the proxy intercepts requests for access to the functional components and calls the moderator to evaluate all the required aspects. If the pre-activation phase returns successfully, then the proxy will call the actual participating method. Once this 1

InQuality® is a commercial software developed by Analyte, Lab Technology Solutions, Buenos Aires, Argentina.

execution is complete, the proxy will initiate the post-activation phase and call again the moderator to evaluate the associated aspects. 2.1 Dealing with Aspects in Multi-Agent Systems The aspect paradigm (Kickzales et.al., 1997) is now recognized as an important level of software development regarding separation of concerns (Parnas, 1972; Hürsch and Lopes, 1995). Basically, the paradigm provides special constructs (aspects) to modularize computational concerns. Among the benefits of the approach, we can mention greater comprehension, reduced complexity, customizability, and simplified component integration. We can say that a MAS approach seem to improve this separation of concerns (DiazPace, 2001), compared with a traditional object-oriented view, especially when these aspects come together with the benefits entailed to the agent paradigm, namely: modularity, decoupling and adaptability. However, the introduction of agents in object models does not come cost-free, because many properties and capabilities of agents are still intrusive or not orthogonal respect to object structures (Garcia and Lucena, 2000). Examples of such properties are autonomy, adaptation, interactions, learning, mobility and collaboration, among others. On the other hand, despite their advantages regarding flexibility and reusability, framework-based implementations usually favor some aspects within the framework organization, and neglect others. Thus, it is sometimes difficult for application developers to select the right aspects of the framework, without dealing at the same time with other undesired aspects. These “unfavored” aspects may present a poor flexibility. Here, the concept of software architecture can provide significant aid if the agent paradigm is conceived as mainly driven by models or architectures (DiazPace and Campo, 2001). This situation is observed in Bubble, where the inclusion of some architectural-driven features (e.g., events and implicit invocation, uniform decomposition and competing tasks) complemented agent autonomy, underlining component decoupling and also conferring a high degree of flexibility to the overall architecture. This way, developers can easily define diverse agent structures. Nonetheless, other aspects such as scheduling and synchronization are not managed at the framework-user level, rather they are provided as built-in features of Bubble. As design decision, this favors a better usability of the framework, but at the same time it may limit the possibility of defining alternative concurrency policies. To ameliorate these flaws, it is interesting to explore the integration of Bubble with a traditional AOP framework. Indeed, this perspective is taken by the Smartweaver approach.

3 Knowledge-driven weaving: the Smartweaver approach Supporting aspects at the design phase can greatly improve aspect-oriented development (Clarke, 2001), because aspects can be identified and incorporated earlier in the development process. From a conceptual viewpoint, the process of separation of concerns would take place at design time. Afterwards, a special tool is responsible for

weaving the components all together to produce a single application. There are different variants for the implementation of the weaving process, and this depends on the approaches supporting the aspect infrastructure (e.g., aspect languages, AOP frameworks). This leads us to the smart-weaving concept (DiazPace et.al., 2002). Essentially, designers should be able to describe the required functionality for an application in terms of object designs extended with generic aspect models (e.g., using a CASE tool), and then by means of an engine having adequate knowledge, these aspect models should be translated to particular aspect programs. Application Development

Instantiation Plan

Selection of Functionality Task Manager

Knowledge-driven Weaving Smartweaver Agent

Planner

Documentation of the Target Design Documentation Tool (UML Models)

Instantiation Knowledge Smartbooks

Object-Oriented Framework

Aspect-Oriented Framework

Figure 1. Assisting instantiation of aspect frameworks using the Smartbooks approach

Unfortunately, existent technologies are far to provide the aforementioned assistance. Instead of that, an intermediate approach is to think about a knowledge-based engine able to prescribe the developer what activities should be done to implement a given application. In particular, frameworks can naturally fit in this context. If we focus on the process of framework instantiation, it can be seen as a composition of relatively simple programming activities, which must be carried out in some meaningful order. The difficulty resides on determining which activities have to be executed for creating a given application, and also how these activities need to be combined to obtain the desired functionality. Here, we can take advantage of software agents (Bradshaw, 1997), and more specifically intelligent personal assistants, in order to help developers with the process of framework instantiation. Basically, these assistants can observe users, or interact with them, making suggestions, changes, or directly altering the result of computations. In other words, assuming an agent with adequate knowledge about the different functions that can be implemented using the framework resources, this agent could guide developers with the programming steps

required to implement such functionality. An outline of this proposal is shown in Figure 1. Following these guidelines, we have developed as previous work an experimental tool for framework instantiation (Ortigosa et.al., 2000; Ortigosa and Campo, 2000). The tool, called now Hint, takes into account the requirements listed below. • It shows the user what functionality can be implemented using the framework, allowing him to choose the functionality required for the application being implemented. • Depending on the selected functionality, it can elaborate a plan of necessary activities to implement a concrete application. • It guides the user through the instantiation process by effectively executing these activities. Documentation knowledge is described through a predefined format of rules that we call the Smartbooks documentation method. In the next sub-sections, we shortly explain the Smartbooks method and the corresponding assistant agent. 3.1 The Smartbooks Documentation Method The Smartbooks method (Ortigosa et.al., 2000) conceives the instantiation of frameworks as an activity based on a well-defined number of basic instantiation tasks, for example, class specialization or method overwriting, among others. The method prescribes that the framework designer should describe the functionality provided by the framework, how this functionality is implemented by different framework components, and provide rules to somehow constraint the ways the framework can be specialized. This knowledge is represented through what is called instantiation rules. The purpose of these rules is twofold. On one side, the framework user will use these rules to express the intended functionality of his new application, so the user is oriented to define what his application is supposed to do. On the other side, the Smartbooks engine will take these requirements and the knowledge rules documenting a target framework, in order to guide the user through the process of application development. Instantiation rules can be graphically specified using a UML extension called TOON (Tasks and Object-Oriented Notation), to express framework structures and instantiation activities associated with them. All these rules are directly associated with the concept of tasks as programming activities. The execution of these activities will effectively generate code implementing the desired functionality. 3.2 The Smartbooks Engine As we mentioned before, a special tool is in charge of collecting all the Smartbooks documentation and assisting the user through the process of framework instantiation. The architecture of this tool comprises several components with different responsibilities. For the sake of simplicity, we just give an outline of them. A more complete covering of these issues can be found in (Ortigosa et.al., 2000). The main components are the following:

• A documentation tool used by framework developers to write the framework documentation. This documentation is internally represented as instantiation rules in Prolog format. • A functionality collector (wizard) to help the user describe the functionality required for the application currently being developed. This functionality is again expressed as Prolog rules. • A planning module using least commitment planning techniques to build alternative instantiation plans. • A task manager keeping track of the tasks involved in instantiation plans. The task manager is responsible for coordinating tasks, so that they may be executed, interrupted in order to work on other tasks, or even cancelled at any time. The consistency manager checks if any user action can produce an inconsistent state, and then creates the tasks that should be executed to correct this situation. It is based on a pattern-matching mechanism to compare software configurations and detect inconsistent states. The planning agent takes a list of functional requirements (written as instantiation rules), and then elaborates a list of required instantiation tasks based on the core knowledge provided by the framework designer. During the planning phase, the tool uses a UCPOP-like algorithm called PHint. It follows the least-commitment principle (Weld, 1994), that is, it produces a partially ordered sequence of tasks, delaying decisions as much as possible. This flexibility allows the framework user to choose about task execution alternatives when they are really needed.

4 Applying smart guidance on an application example In order to better understand the Smartweaver approach, this section describes a case-study based on a workflow application (Diaz Pace and Campo, 2002), and explains each of the phases developers should go through to implement the application using the Smartweaver tool. This workflow is actually part of the InQuality system, and it deals with documentation processes such as creation of documents, release of new versions, deletion of old documents and distribution of copies. The functionality required for this example can be informally described as follows. The application defines a workflow model for structured documents, with different users having access to these documents. Users can play different roles (e.g., supervisor, editor, or auditor), and each role has set its own permissions to operate on the documents. During its lifecycle, a document typically goes through a number of predefined states, e.g. edition, approval and publishing. Initially, the document is empty, waiting for edition. As the editor adds information to the document following certain standards, the document is sent to the auditor for approval. If the auditor considers the document contents relevant to the system, it is marked as ready for distribution. If so, every user potentially interested in this type of documents is notified about the event. If not, the document is sent back to the edition phase for revision. However, the auditor may reject the document if defective. In addition, a supervisor can review

documents at any time and decide about their status. After certain period of time, some documents may become useless or require modifications. In such cases, a new version of the document is generated. As a result, the old version of the document is not longer available. Old documents are temporary stored as items pending of deletion, until they are finally removed from the system. For simplicity, we suppose a supervisor can read, write or check documents, an editor is only allowed to read or write some documents, and an auditor can read or check other documents. 4.1 Basic Workflow Implementation using Bubble The workflow application2 was originally implemented on top of the multi-agent infrastructure prescribed by Bubble. In the resulting implementation, each document type has an associated workflow, and each workflow is generated by means of a Petri-net-based graphical editor. The editor produces a specification of the net that is used to configure the specific workflow instance. Instead of having a centralized workflow engine, every particular workflow instance (or workflow process) associated with a document is represented as a container agent. Each activity within the workflow instance is represented as a single agent. The workflow instance agent encapsulates the knowledge related to the structure of the particular workflow and related to creating the corresponding agents and associated tasks that will implement the workflow. Activity agents listen to events generated by the execution of previous activities, and react when these events arrive. Tasks associated with activity nodes of the workflow will produce messages directed (through a blackboard component) to the specific role or participant in charge of executing such activity. The resulting design helped to simplify the representation and flexible configuration of documents, roles and activities, thus reducing development efforts. The aspects identified in the application model are listed below. • Concurrency: It mainly deals with synchronization and scheduling issues, by controlling the access to a given document of many potential readings or writings coming from different user sessions. It should consider mechanisms to lock/unlock documents and mechanisms to determine who is the next reader/writer when a document is available (unlocked). • Authorization: It refers to security policies regarding document handling, so that only authorized users can access to certain document contents. • Logging: It is in charge of keeping track of activity on the documents after some abnormal situation involving security issues has occurred in the system. Typically, any unsuccessful authorization should dynamically activate the logging aspect to register user actions from that point on. • Event handling: Event mechanisms are frequently used in the Bubble architecture with notification purposes. For instance, an event may have information about the next activity to execute or about changes in certain document properties. As a re2

Some details of the workflow application have been modified or simplified for clarity reasons, and also due to academic-industrial confidentiality agreements.

sult, the system behavior is strongly influenced by the policies in charge of managing event flow within the system 4.2 Introducing the Smartweaver Assistance This section deals with the development of the same workflow application, but based on the Smartweaver approach. To apply smart guidance on a given application, it is necessary to accomplish four main activities. Firstly, we need to create some documentation books of support technology, that is a Smartbooks representation of particular approaches for multi-agent systems and aspects. Then, we should proceed with the design the target application. After that, we are required to add mapping rules to effectively generate a weaving plan. Finally, all these things are put to work together so that the tool can suggest a series of programming tasks producing the desired aspect multi-agent functionality. Figure 2 shows a summary of the required activities. Design of the target application Documentation of Bubble with Smartbooks

Documentation of AMF with Smartbooks Documentation books of support technology

First workflow instantiation on top of Bubble, using the TaskManager assistance

Refinement of the workflow design to include aspects (UML models)

Definition of mapping rules for the AMF framework Weaving information

Final aspect-based workflow application using the Smartweaver engine Putting it all together

Figure 2. Steps required to apply smart-assistance on the workflow application

4.2.1 Building Documentation Books of Support Technology. At the beginning, the approach requires the definition of the core Smartbooks knowledge documenting a given aspect implementation. If we take the Aspect-Moderator framework (AMF), this knowledge should be represented in terms of instantiation rules. In a similar way, documentation for the Bubble framework should be provided. As an example, Figure 3 shows an instantiation rule described using the TOON notation corresponding to the definition of a proxy for aspect behavior in the AMF framework. The head of this rule states that in order to have a functional proxy for a component, the proxy class should implement the FunctionalProxyIF interface and wrap the component. More precisely, the diagram prescribes that four tasks should be carried out by the user: • An ImplementInterface task that has to produce a subclass of FunctionalProxyIF. • A DefineVariable task, which must add a myComponent attribute to the proxy. • A DefineMethod task in charge of overriding a functional method of the component (to incorporate aspect behavior). • Finally, an OptionalDefineMethod task if any update to the constructor is required.

Figure 3 also depicts other instantiation rule corresponding to the definition of a simple agent in the Bubble framework. Here, the rule specifies how to create an agent using a default implementation. The new agent needs just to extend the Agent class, and then complete the methods initialize and run. Each rule description can give explanations about the expected behavior of methods, or specify some constraints that must be followed by a code skeleton. For example, the [Method] method of ComponentProxy in Figure 3 should call the same method of the wrapped class. The kind of tasks presented in these examples can be seen as basic tasks or programming tasks, because they refer to programming activities associated with framework code.. Note that the designer arbitrarily fixes the terms used to document the framework functionality. Anyway, this framework documentation, either automated or not, is usually hard to come by framework developers. The method gives little assistance for this process, and hence good documentation is ultimately up to developers’ experience.

createFunctionalProxy(Component,ComponentProxy,Method,´composition´)

Opt ionalUpdateMethod

[ ComponentProxy] myComponent new() [ Method]()

DefineV ariable

[Component] [Method]()

FunctionalProxyIF

DefineMethod

ImplementInterface

defineSimpleAgent(ConcreteAgent, ´default´)

Agent [ConcreteAgent]

DefineClass

new() initialize() run()

Opt ionalUpdateMethod

DefineMethod

Task: createFunctionalProxy Input: [ComponentProxy, Component, Method ] Output: [] Preconditions: definedClass(ComponentProxy), definedClass(Component), not(definedMethod(Component, Method)), proxyOption(´composition´) Postconditions: definedMethod(ComponentProxy, Method), wrapped(ComponentProxy, Component) Body: do implementInterface(ComponentProxy, ´FunctionalProxyIF´) do defineVariable(ComponentProxy, ´myComponent´) do defineMethod(ComponentProxy, Method, ´It should call Method in Component´) do optionalUpdateMethod(ComponentProxy, ´new´) Task: defineAgent Input: [ConcreteAgent] Output: [] Preconditions: definedClass(´Agent´), not(definedClass(ConcreteAgent)), not(definedMethod(ConcreteAgent, run)), agentOption(´default´) Postconditions: definedClass(ConcreteAgent, Agent), definedMethod(ConcreteAgent, run), Body: do createClass(ConcreteAgent, ´Agent´) do defineMethod(ConcreteAgent, ´run´, ´It should execute agent tasks´) do optionalUpdateMethod(ConcreteAgent, ´initialize´)

Figure 3. Some instantiation rules for the frameworks AMF and Bubble

4.2.2 Designing the Target Application. Here, developers should define the design of the core workflow components as well as the crosscutting properties affecting components’ functionality. In this line, we have extended conventional UML models including additional stereotypes and relationships to support different AOP features. Figure 4 shows a class diagram with some of the classes involved in the workflow application and its associated aspects3. For example, it defines advice for the WFDocument class, and also exposes the conditional activation of the WFLogging aspect as a result of evaluating the WFAuthorization aspect. These descriptions may be complemented with more detailed views documenting aspect behavior. Note that in order to specify which aspects crosscutt the workflow application, developer have to previously sketch out the main workflow classes as instantiation of the Bubble framework. In the general case, developers can incrementally specify portions of aspect diagrams and define particular properties regarding before/after crosscutting, aspect priorities or conditional activation, among others. These specifications are based on a new kind of tasks called design tasks.

4.2.3 Adding Weaving Information. During this phase, developers provide more details about their previous aspect diagrams. That is, they should specify the ways crosscutting relationships and aspect design tasks should be translated into aspect programming constructs according to the aspect support available in the environment. Aspect diagrams usually include special tasks, which correspond with activities that 3

Aspects can be seen as special classes defining attributes and operations, and also incorporating advice operations.

developers should carry out in order to tune specific details of the aspect-based application. These tasks are different from programming tasks, mainly because they operate at different levels of abstraction. Design tasks indicate how abstract weaving specifications are mapped to a particular aspect implementation (an AOP framework in our example), which has been previously documented in terms of programming tasks during phase 1 (section 4.2.1). The code template of Figure 5 illustrates (partially) how the Aspect-Moderator framework would implement before/after advice and conditional activation of aspects according to the design given in Figure 4. Bold code distinguishes those parts defined by means of programming tasks. Note that not everything can be expressed in terms of programming tasks. Some framework constraints are just documented by means of warning messages. WFAuthorization passwordsMap : Hashtable rolesMap : Hashtable

WFManager currentUsers : Hashtable doUserLogin(String name, String password) : WFParticipant crosscutting createProcess(String name) : WFProcess

isAuthorizedParticipant(WFParticipant) : boolean validateUserLogin(...) : boolean authorizeOperation(...) : boolean crosscutting

initializes >> WFProcess

WFActivity

defines >>

setupActivities() : boolean startWorkflow(WFDocument)

status : int 1.. * onRunningActivity(WFEvent) onSuspendedActivity(WFEvent) processWFEvent(WFEvent) : boolean

performs >>

includes >> WFParticipant 1..*

conditional activation

cros scutting

doOperation(String op, WFDocument) : boolean hasCapability(String) : boolean

crosscutting

cross cutt ing

WFEventFiltering checkProcessWFEvent(...)