ROADMAP: Extending the Gaia Methodology for Complex Open Systems

Thomas Juan Adrian Pearce

221 Bouverie Street Carlton, Victoria, 3010, Australia

Leon Sterling

Department of Computer Science and Software Engineering, The University of Melbourne,

tlj@cs.mu.oz.au ABSTRACT

pearce@cs.mu.oz.au

leon@cs.mu.oz.au

This paper is concerned with improving the software engineering of agent-based open systems. It critiques the existing Gaia methodology in the light of a motivating example of intelligent home networks. It describes the ROADMAP1 methodology, which extends Gaia with four improvements - formal models of knowledge and the environment, role hierarchies, explicit representation of social structures and relationships, and incorporation of dynamic changes.

modeling and designing open systems. The high level and knowledge oriented view of agents makes them a natural abstraction to allow modularization of knowledge in the system. Methodologies for Agent Oriented Software Engineering are beginning to emerge. [5,15] survey current methodologies and approaches. On the whole, agent-oriented methodologies are immature. They lack some important capabilities to facilitate the development of complex open systems. They remain to be tested to see if they scale for large systems. One important missing capability is run-time reflection, which enables the dynamic change of system behavior. Perhaps the most developed agent-oriented software engineering methodology is Gaia [17]. We extend the methodology to allow better engineering of open systems. We discuss the improvements needed in the light of a motivating example, an intelligent networked home. Section 2 introduces the home network system. Section 3 reviews existing methodologies, concentrating on Gaia. Section 4 describes ROADMAP, and its extensions to Gaia. Section 5 focuses on the models and procedures of the specification and analysis phase. Section 6 discusses the models and procedures for the design phase. Section 7 provides example artifacts of the extended models based on the motivating example. Section 8 discusses related work and Section 9 concludes.

Categories and Subject Descriptors

D.2.10 [Software Engineering]: Design methodologies.

General Terms
Design, theory.

Keywords
Agent oriented software engineering, methodology, multi-agent system, agent organization, open system, knowledge model.

1. INTRODUCTION
Software has been usually developed under the assumptions that all system requirements must be determined and frozen during the analysis stage, and any factors to be accounted for at run-time must be anticipated and designed for during the design stage. These assumptions are problematic from two perspectives. Firstly they unnecessarily constrain complex open systems [8,12]. Secondly, they are difficult to enforce during all stages of development. There is an increasing demand for open systems in the industry [1,9,13,18]. A methodology that provides appropriate support for engineering large-scale open systems is significant and useful. Multi-Agent Systems (MAS) [10,14,16] are intended to adapt to unexpected situations. They are an appropriate abstraction for __________________
1

2. THE MOTIVATING EXAMPLE: A HOME NETWORK SYSTEM

Imagine an intelligent network of household appliances. Such a network would probably consist of a fast PC (the home server), connected to the Internet with a broadband connection, and connected to a wide diversity of home appliances via wireless Ethernet or other appropriate technologies. A large number of sophisticated software agents would reside on the home server and on the Internet, providing services in cooperation with the appliances. The Hive project [9] and the oxygen project [3] are similar in spirit. The scope of the home network system is open, with new agents and appliances being able to be added at any time, and existing devices moving in and out of the system frequently. A watch for example, would leave the system with its wearer to work or play in the morning, and return in the evening. Software agents can be downloaded to add new functionality to the system, or cease to exist when services are not paid for. Let us consider a scenario on security. Imagine there are video cameras installed in every room of the house. When a stranger appears in the house, a software agent will identify him/her as a person from the video feed. A face recognition agent cooperating

ROADMAP is an acronym for Role Oriented Analysis and Design for Multi-Agent Programming.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. AAMAS 02, July 15-19, 2002, Bologna, Italy. Copyright 2002 ACM 1-58113-480-0/02/0007$5.00.

with an agent maintaining the family profile will point out that the stranger is neither a family member nor a friend. Other agents will cooperate to deduce that the current visit is not scheduled, and the strangers behavior is a security concern. The system will attempt to query any device the stranger is carrying to determine identity. The owner of the house will be notified through the most appropriate channel, for example, the mobile phone or a PC at work, with the video feed. Family members and scheduled visitors might receive warning to stay away temporarily. Meanwhile the agents will protect the house, temporarily deadlock the windows, the doors, the car and the safe. Confidential files on the local PCs are encrypted or removed; outbound access to the Internet is disabled. Local software agents will cooperate with software agents of the police to report the incident, and provide images so the suspect can be identified. A police officer may talk directly to the suspect over the Internet, with microphones and speakers installed in the room. If an arrest is required, the system will provide the floor plan and details of the house to the police agent planning the arrest. The system will also provide the exact location of the suspect as he moves and the video feed to the PDAs carried by the arresting officers. Obviously issues such as user privacy have to be carefully considered. There are interesting and implicit social relationships in the scenario, that determine which agent receives which piece of information. There are scalability concerns, as a potentially large number of events might need to be handled. In general, issues arising from such systems are outside the traditional domain of Agent Oriented Software Engineering.

do not address the characteristics of architectural independence, robustness and scalability adequately. In particular, there has been insufficient coverage on facilitating the specification of dynamic social interactions.

3.2 The Gaia Methodology

We focus on the Gaia Methodology [17] for its architectural independence and simplicity. The methodology presents explicit and useful models of the social aspect of agents. Although it was not designed for open systems, and provides weak support for scalability, its simplicity allows improvements to be made with relative ease. The Gaia methodology models both the macro (social) aspect and the micro (agent internals) aspect of the multi-agent system. Gaia takes the view that a system can be seen as a society or an organization of agents. The methodology is applied after the requirements are gathered and specified, and covers the analysis and design phases. Figure 1 shows the artifacts produced by using Gaia.

3. AOSE METHODOLOGIES 3.1 Desired Characteristics

Engineering complex open systems requires the methodology employed to have two characteristics: 1. Architectural Independence: as the requirements of the system are dynamic, and the potential scope and complexity of the system vary through its lifetime, the methodology should not subscribe to any particular programming paradigm, programming language, agent architecture or implementation framework. Instead, different paradigms and architectures must be accommodated naturally. 2. Robustness and Scalability: the methodology must facilitate dynamic changes without compromising the system robustness. Scalability should be promoted to facilitate the growth of the open system to any given complexity. To achieve this, the methodology must support the modeling of complex and often dynamically formed social interactions between agents within the system. We consider existing methodologies with these two characteristics in mind. The traditional OO approach [2], although well established in the industry, is not suitable, failing to meet both characteristics. In addition, many properties processed by the software entities in the intelligent home network scenario, such as autonomy, are not well modeled by the object abstraction. The OO mechanisms to relate objects, namely inheritance and aggregation, cannot easily capture the complex, and often dynamically initiated relationships between the software entities. A variety of agent-based methodologies have been proposed - [5] provides a comprehensive survey. Most of these methodologies

Figure 1. The Gaia Models In the analysis phase, the role model and the interaction model are constructed. The two models depict the system as interacting abstract roles. These two models are then used as input to the design stage. The agent model, the services model and the acquaintance model are constructed during initial stages of design. These three models are then taken into the detailed design stage. Gaia does not cover detailed design and relies on conventional methodologies for that purpose.

3.3 Analysis with Gaia

In the analysis stage, roles in the system are identified, and their interaction is modeled. These roles are abstract constructs used to conceptualize and understand the system. They have no realization in the implemented system after the analysis stage. In Gaia, all roles are atomic constructs and cannot be defined in terms of other roles. They are defined in terms of four attributes: responsibilities, permissions, activities and protocols. Permissions limit the resources available to the role, usually expressed as some information that the role can read, write or create. The permissions specify both what the role can and cannot use. Activities are tasks or actions a role can take without interacting with other roles, and protocols are tasks or actions a role can take that involve other roles. Responsibilities of a role define its functionalities. There are two types of responsibilities, liveness properties, and safety properties. The former describes the lifecycle or generalized behavior

The safety properties are properties that the agent acting on the role must always preserve. Safety properties are expressed as predicates over the variables in the permissions of the role, specifying the legal values these variables can take. The role model is simply a collection of role schema, detailing the attributes for each role in the system. An interaction model is developed based on the initial role model. It contains a protocol definition for each protocol of each role in the system. The protocol definition describes the high level purpose of the protocol, ignoring implementation details such as the sequence of messages exchanged. The protocol definition outlines the initiating role, the responding role, the input and output information, as well as a brief description of the processing the initiator carries out during the execution of this protocol. Table 1. Partial Syntax of Liveness Properties Operator x.y x|y xw x || y Interpretation x followed by y x or y occurs x occurs infinitely often x and y interleaved

3.5 Weaknesses
Gaia was designed to handle small-scale, closed systems. It has weaknesses that render it inappropriate for engineering complex open systems. We have identified the following weaknesses through our work on the motivating example, in order of encounter: 1. Gaia assumes complete specification of requirements and does not address the requirement-gathering phase. It does not guide developers to take advantage of richer requirements enabled by agent technologies. The methodology does not facilitate regular changes of requirements typical to open systems. 2. Environmental information is implicitly encoded in the permissions and protocols of individual roles. Gaia does not present a holistic model of the execution environment to the developers. This omission renders Gaia inappropriate for engineering applications with dynamic and heterogeneous environments. 3. Domain knowledge in the system is implicitly encoded in the attributes of the individual roles. Gaia does not present a holistic model of the structure of the domain knowledge and the interaction and dependencies of knowledge components in the system. This omission prohibits knowledge in the system to be shared, re-used, extended and maintained in a modular fashion. 4. Roles are not hierarchical in Gaia. The role model provides strictly one level of abstraction for the developers to conceptualize the system. The methodology does not facilitate iterative refinement of the system through different levels of abstraction. As a result, Gaia does not scale to handle complex systems. 5. Gaia cannot explicitly model and represent important social aspects of a multi-agent system. Gaia cannot explicitly model the organization structure of the agents in the system, or alternatively, the architecture of the system. It also lacks the ability to explicitly model the social goals, social tasks or social laws within an organization of agents. 6. Gaia offers no mechanisms to model the dynamic reasoning, extension and modification of the above social aspects at runtime. 7. The roles, representing responsibilities and capabilities of agents, are not realized in design or at runtime. The lack of such information at runtime makes peer verification of agent behaviors difficult.

Analysis within Gaia involves refining the role model and the interaction model iteratively. They serve as the initial input to the design stage.

3.4 Design with Gaia

In the design phase, the abstract constructs from the analysis stage, such as roles, are mapped to concrete constructs, such as agent types, that will be realized at runtime. Gaia requires three models to be produced, see Figure 1. The agent model outlines the agent types in the system. The services model outlines the services required by the roles assigned to the agent types. The acquaintance model depicts communication links between agent types. Assigning the roles to agent types creates the agent model. Each agent type may be assigned one or more roles. For each agent type, the designer annotates the cardinality of agent instances of that type at runtime. Figure 2 shows a sample agent model.

Figure 2. A sample Agent Model In Gaia, a service is simply a coherent block of functionality neutral to implementation details. The service model lists services that agent types provide. They are derived from the activities and protocols of the roles. For each service, four attributes must be specified, namely the inputs, outputs, pre-conditions and post-

8. At an individual agent level, Gaia offers no mechanisms to model the dynamic reasoning, extension and modification of responsibilities and capabilities of agents at runtime. Complex open systems, such as the one outlined in the motivating example, cannot be effectively engineered with Gaia, due to its weaknesses listed above. To extend Gaia for open systems, we expect the following features to be included: 1. Support for requirements gathering.

@  2 0 0 % '& %    4 $98& 76)5%431)&("!$#"!

pattern of the role. Liveness properties are represented by a wregular expression over the sets of activities and protocols the role processes. The syntax of liveness properties used in this paper is shown in Table 1.

conditions. They are easily derived from attributes such as protocol input, from the role model and the interaction model. The acquaintance model is a directed graph between agent types. An arc A allowing A to send messages to B. The purpose is to allow the designer to visualize the degree of coupling between agents. In this light, further details such as message types are ignored.

2. Explicit models to describe the domain knowledge and the execution environment. 3. Levels of abstraction during the analysis phase, to allow iterative decomposition of the system. 4. Explicit models and representations of social aspects and individual agent characteristics, from the analysis phase to the final implementation. 5. Runtime reflection, modeling mechanisms to reason and change the social aspects and individual agent characteristics at runtime.

Similar to roles in Gaia, ROADMAP roles have permissions to access or modify information resources (objects in the environment). To model runtime reflection, we extend the original framework and allow a role to have permissions to access or modify the definition of other roles. Given that roles in ROADMAP have runtime realization, this mechanism allows runtime reasoning, extension and modification of social aspects such as social structure, social laws, and individual agent characteristics and capabilities. In summary, the system is defined as a computational organization of interacting roles at the analysis stage. The organization is then optimized for quality goals, and populated with agents at the design stage.

4. THE ROADMAP METHODOLOGY

The ROADMAP methodology extends Gaia with the features outlined in the last section. Figure 3 shows the structure of the ROADMAP models. The analysis phase in the original Gaia methodology is extended to cover specification as well. A usecase model is introduced to support requirements gathering. An environment model and a knowledge model are derived from the use-cases and provide holistic views on the execution environment and the domain knowledge.

5. THE SPECIFICATION AND ANALYSIS MODELS AND PROCEDURES

In the specification and analysis phase we create the following models sequentially: use-case model, environment model, knowledge model, role model, protocol model and the interaction model. Each model takes all previous models as input. These models are refined iteratively until sufficient information about the system is captured.

5.1 The Use-case Model

Creating use-cases has proven to be a very effective and sufficient method to discover requirements. At this stage, this is the only method we use to extract requirements. Adapted from OO methodologies, the use-case model includes generalized graphical diagrams and specialized text scenarios. The scenarios outline the system response given a precise sequence of user actions. ROADMAP concepts such as zones and roles can be used in the use-cases. Figure 3. The ROADMAP Models The collection of protocol descriptions is renamed to the protocol model. An interaction model, based on AUML interaction diagrams [11], is added to model the dynamic aspect of the system. The original role model is extended with a role hierarchy. The role hierarchy is represented as a tree and allows arbitrary levels of abstraction. The leaf nodes of the tree are atomic roles. The atomic roles retain their original definition and represent characteristics of individual agents. All other nodes in the tree are composite roles, defined in terms of other roles, whether atomic or composite. A composite role represents a localized organization of agents. Its attributes model social aspects of that organization, such as the organizational structure, social goals, social tasks and social laws. All the analysis models are carried into the design phase. They are optimized towards chosen quality goals and updated to reflect design decisions. The extended role model and the protocol model, together define the social aspects within the system as well as characteristics of individual agents, are further carried into implementation. Components of these two models, such as roles, are no longer considered abstract. They are concrete first class entities in design and will have realization in the final implemented system. To better capture the richer agent behaviors, the semantics of usecases are different from the traditional OO approach. Instead of imagining the user interacting with the software system to do work, we imagine the user interacting with a team of abstract ideal agents. The agents are considered ideal and possess any knowledge, ability or mental states required to provide the best service. The concept of ideal agents with perfect knowledge and ability is unrealistic. However, with ROADMAP support for open systems, we expect such an ideal agent to be approximated by a dynamic complex multi-agent system. The methodology provides adequate support, allowing the complexity and knowledge in the multiagent system to scale modularly to any arbitrary level required. The scenario of handling a home intruder in Section 2 is a good example as part of the use-case model.

5.2 The Environment Model

The environment model is proposed to provide a holistic description of the system environment. Complex open systems usually have highly dynamic and heterogeneous environments. By formally describing the environment, we create a knowledge foundation on which environment changes are handled consistently. The environment model is derived from the use-case model. The model contains a tree hierarchy of zones in the environment, and a

set of zone schema to describe each zone in the hierarchy. In the scenario from Section 2, three primary zones are identified. They are the Internet, local PC, and the physical environment of the house. Sub-zones are then identified by partitioning the Internet to yield the police website and web services, home owners communication web services at work and commercial web services such as the face recognition service. The physical environment of the house includes sub-zones such as rooms in the house and the garden. A zone schema includes a text description of the zone, and the following attributes: static objects, objects, constraints, sources of uncertainty and assumptions made about the zone. Static objects are entities in the environment whose existences are known to the agents, with which the agents do not interact explicitly. Objects are similar entities with which agents interact. Sources of uncertainty in the environment are identified and analyzed. The zone hierarchy uses OO-like inheritance and aggregation to relate zones and various objects inside zones. The zone schema is not an exhaustive listing of zone properties. It only contains related information from the use-cases. The developer will go through the scenarios in the use-case model, and for each scenario, identify new zones and update new information into the existing zones. This process builds up a description of the environment iteratively and can be re-used when building future applications in similar environments.

Figure 4. A sample Role Hierarchy All the other roles are composite roles. As shown in the example, they are A, B and C. They are defined in terms of other roles, whether atomic or composite. The mechanism we use is aggregation. The root of the tree, A, is a special composite role; it represents the entire system.

5.4.1 Composing with Aggregation

The semantic of aggregation is different from that of traditional OO approaches. In OO approaches, aggregation usually has a static object containment semantic, assuming only one thread of execution. It takes a bottom-up view and the aggregate has direct control over the components. The class hierarchy is effectively a control hierarchy. To illustrate the autonomous nature of agents and the social aspects in multi-agent systems, a more dynamic and distributed view is needed. Aggregation in the proposed role hierarchy assumes a dynamic teamwork semantic. The individual sub-roles are said to participate in the super-role; each may own a thread of execution, a set of knowledge and functionality. The super-roles are said to involve the sub-roles, with that involvement dynamically adjusted if necessary. A sandwich approach sees sub-role responsibilities interacting to achieve the super-role responsibilities, and sub-role actions interacting so that super-role action emerges. The superrole may not have complete and fine-grained control over subroles. The role hierarchy models societies at different levels of abstraction, instead of depicting a control hierarchy. Inheritance is not used in the methodology for three reasons. First, a relationship expressed as inheritance can be re-expressed as aggregation [6]. Two entities A and B having a common entity C can both aggregate C as a component, rather than inheriting from C as a parent class. Secondly, inheritance represents the is-a relationship. This relationship creates more implicit coupling than the has-a relationship of aggregation. In a dynamic system with constant change in organization, inheritance will leave more legacy dependency/coupling between types. This reduces the maintainability and extensibility of the system. Thirdly, in light of an open system, the architecture of the system is expected to be refactored regularly. Having a uniform mechanism to compose the system instead of two simplifies the refactoring.

5.3 The Knowledge Model

The knowledge model is proposed to provide a holistic description of the domain knowledge in the system. The model consists of a hierarchy of knowledge components, and a description for each knowledge component. From the use-case model and the environment model, the developers identify the knowledge required to deliver the agent behaviors in the appropriate zones for each use-case. The knowledge identified is then decomposed into small coherent blocks. The lifecycles of these knowledge components are analyzed, focusing on how the knowledge component is generated, consumed and stored. The dependencies between knowledge components are analyzed, and the knowledge components are organized into a hierarchy. A potential knowledge component in the Section 2 scenario contains the floor plan and other architectural specifications of the house. The creation of the role model happens in parallel and roles are identified from the scenarios. As knowledge components are created, they are assigned to roles; effectively making roles units of knowledge in the system. The knowledge model connects the role model with the use-case model and the environment. When the expected behavior of the system or the environment changes, the knowledge in the roles can be conveniently revised.

5.4.2 Modeling Social Aspects with Composite Roles

A composite role represents a localized organization or society of roles. Its attributes model social aspects, most notably the organization structure, social goals, social tasks or social laws, of that society. The revised role schema is identical to the original schema with the addition of two attributes, namely the Sub-roles and the Knowledge attribute. For a composite role, its Sub-roles attribute lists its sub-roles, representing the local organization structure. Its Knowledge attribute arises from the interaction of sub-role knowledge, and represents local social knowledge. Its protocol and activities are social actions or tasks emergent from the

5.4 The Revised Role Model

The revised role model now consists of two artifacts: a role hierarchy, and a set of role schema describing each role in the hierarchy. The role hierarchy is represented as a tree; Figure 4 shows an example. The leaf nodes of the tree are atomic roles. In this example they are D, E, F and G. They retain their original semantics from Gaia and represent characteristics of individual agents.

interaction of sub-role protocols and activities. Its liveness responsibilities, still defined as w-regular expressions over the sets of activities and protocols the role processes, represent local social goals that the sub-role responsibilities interact to achieve. Its safety responsibilities, still defined as predicates, represent local social laws emergent from sub-role safety responsibilities, hence respected by sub-roles.

attribute a permission to modify all protocols belonging to another role B. There are three logical levels of reflection, on the entire role, on an attribute, such as protocols, or on a particular member in an attribute, such as the Auction protocol. A star notation signals recursive permission on all sub-roles, direct or indirect. For example, B.protocols* represents reflection on protocols of B and all its sub-roles down the hierarchy.

5.4.3 Social Participation and Information Hiding

We use the involved keyword to denote social participation. Assuming the protocol Protocol_B1 of composite role B is the emergent action from the interaction of protocol Protocol_D1 of role D and activity Activity_E1 of E. We can then depict this participation in the super-roles (B) role schema, under the protocol attribute, by the statement: Protocol_B1 involves D.Protocol_D1 and E.Activity_E1. Lets look at a similar statement on Bs liveness responsibility resp: resp = (work | wait) w involves D.resp1 and E.resp2. The statement defines resp as a w-regular expression in terms of Bs activities work and wait. The statement also points out that resp is a result of interaction between Ds liveness responsibility resp1, and Es liveness responsibility resp2. Any attribute of the superrole can only involve attributes of the same type from the direct sub-roles, with the exception that protocols and activities can both involve any mixture of sub-role protocols and activities. The participation relationship is intrinsic to the role hierarchy and cannot be removed. Modeling this relationship explicitly highlights the dependencies and simplifies changes frequent to open systems. To a composite role, its internal social participation of sub-roles is essentially its implementation detail. Hence its sub-role participation and internal structure is hidden from and invisible to its super-role, sibling roles under the same super-role and interacting peer roles. This is to prevent these roles to depend on the implementation details. To these roles, the composite role considered appears identical to an atomic role. Only its sub-roles are allowed to see their participation in achieving mutual goals. In the example of Figure 4, the internal participation in B by D and E is only visible to D and E, not to A, C, F or G. With the above mechanism, a role B, whether atomic or composite, can be easily extended to a multi-role system (composite role) of any complexity. By preserving Bs original interface, none of the super-role, sibling roles and interacting peer roles will be affected. This mechanism allows seamless extension to the system.

5.5 The Protocol Model and the Interaction Model

Apart from the new name, the protocol model is the same as the original Gaia interaction model. The ROADMAP interaction model is based on the AUML interaction diagrams, with roles and zones represented graphically.

6. DESIGN MODELS
All analysis models are carried into the design phase. During design they are updated to reflect the design decisions. Three design models: the agent model, the service model and the acquaintance model are created from the updated analysis models. These models are refined iteratively until sufficient design information is captured.

6.1 Roles as Agreements of Behavior

As an agent takes a role in the system, we can see it as entering a contract with the rest of system to perform certain duties and functions. Hence roles can be seen as contracts of behavior similar to the interfaces in OO programming. The scope of roles covers the social aspects, the knowledge aspects of the organization, as well as the individual agent responsibilities and abilities. It is much richer and more expressive in comparison to OO interfaces, to better constraint richer agent behaviors. The agent classes are similar to the OO classes and agents are similar to the objects. One obvious implication of this analogy is accessing multiple agent classes through their common role to model polymorphism. Unlike interfaces, roles can be changed at runtime, and should be considered as variable-term agreements on agent behaviors, rather than immutable contracts. This difference makes the architecture of role-based systems more flexible at runtime than traditional systems. In general, if an agent behaves according to the appropriate role in the appropriate zone, other agents in the organization can then trust this agent to act to achieve the overall goal of the organization.

6.2 The Role Model and the Agent Model

The role model in the specification and analysis phase only aims to provide a conceptual view of the system. Its organization structure has not been optimized as the architecture of the system towards any quality goals. In the design phase the role model is refactored, for the chosen quality goals. The agent model is created in parallel by assigning roles to agent classes as in the original Gaia. At runtime we expect an agent to have a pointer to each of its roles. This pointer allows us to access agents via their roles at runtime. The role assignments are also subject to change at runtime. For every agent class, a number of associated services are named. For each service, we can specify whether it implements a protocol or activity from the assigned roles, using the implements keyword. For each protocol or activities, there must be at least one

5.4.4 Modeling Runtime Reflection

Many applications in our scenario are expected to be highly available. To extend and maintain these applications, we need the ability to change the application architecture as well as the ability of individual agents at runtime. A rich body of work exists for reflection and adaptive software [1,4,7,8,12,18]. At the methodology level we do not subscribe to any particular implementation. We only model it abstractly. To do so, we extend the permissions attribute of roles. We allow a role to have read, write or create permissions on definitions of other roles. For example, a role A might include in its permissions

implementing service. This allows the correct service to be invoked at runtime. Such dependency is intrinsic to the system. By providing formal descriptions of the dependency, applying future changes to the system will require less effort.

Liveness: Admin = Work =

6.3 Other Design Models

All analysis models are optimized for quality goals in the design stage, following the same model syntax. The service model and the acquaintance model are the same as in Gaia. The only exception is that roles can now be represented as nodes in the acquaintance diagram like agents.

Safety:

Protocols:

7. EXAMPLE
In this section we show a partial role hierarchy (Figure 5), a role schema, and an agent class definition derived from the Section 2 scenario.

Activities:

(Work | Wait) w QueryConfig* || SetConfig* || QueryProfile* || UpdateProfile* || QueryPayment* || MakePayment* involves sysConfig, deviceMgt, profiles, install and payment Consistent (software and hardware settings) Consistent (user profile) Consistent (payment info) QueryConfig involves SysConfig.QueryConfig & DevMgt.QueryConfig SetConfig involves SysConfig.SetConfig & DevMgt.SetConfig QueryProfile involves Profiles.QueryProfile UpdateProfile involves Profiles.UpdateProfile QueryPayment involves SysConfig.QueryConfig & Payment.Query MakePayment involves Payment.Pay Wait

The AdminAgent class (shown below) takes the Admin role, and implements the protocols and activities of the role. Agent Class: Role Assigned: Description: Services: AdminAgent Admin Taking the role of Admin and provide services for protocols and activities of Admin. QueryConfigSvc implements Admin.QueryConfig SetConfigSvc implements Admin.SetConfig QueryProfileSvc implements Admin.QueryProfile UpdateProfileSvc implements Admin.UpdateProfile QueryPaymentSvc implements Admin.QueryPayment MakePaymentSvc implements Admin.MakePayment WaitSvc implements Admin.Wait

Figure 5. A Partial Role Hierarchy The roles Reliability and Performance are non-functional roles as they specify how the rest of the system functionalities should be delivered. These roles illustrate the use of roles to model and optimize quality goals at the knowledge level. The Admin role below is composite. Its sub-role list is non-empty and sub-role involvements are shown. It also has permission to reflect on all parts of the system. Role Name: Description: Sub-roles: Knowledge: Admin General administration of the system SysConfig, DevMgt, Profiles, Install and Payment Software and hardware types, versions and settings. User profile, and service payment terms Changes all software / hardware settings Changes all user profiles Changes all payment info Changes System* // reflection

8. RELATED WORK
Other attempts to extend Gaia for complex open systems include [19, 20]. So far they do not cover all the issues we addressed in this paper and offer less complete support for open systems. [19] proposes an additional coordination model to the original Gaia models in the analysis stage (please refer to Figure 1). The coordination model captures the nature of the coordination medium. It also allows definition of social laws to govern all communication through the medium modeled. There are a few drawbacks to this approach: 1. The rest of the environment, besides the coordination medium, is not modeled. 2. Unlike ROADMAP, only one level of social law is allowed. Hence changing the existing social law affects all agents using the medium.

Permission:

Responsibilities:

3. Social laws are embedded into the communication medium. This monolithic approach does not facilitate frequent changes and complicates the communication medium unnecessarily. In addition, this approach lacks essential features to support open systems such as a role hierarchy, and representation of other social aspects. See section 3.5 for the list of features. An organization-oriented methodology is sketched in [20]. To avoid early commitment to any organization structure, only general organization rules are outlined in the analysis stage. The organizational structure is designed in the design phase. This approach suffers from the fact that general organization rules are inadequate in conceptualizing complex systems. The potential scope of the development is restricted unnecessarily.

[7] Kiczales, G., des Rivieres, J., and Bobrow, D. The Art of the
Metaobject Protocol. The MIT Press, 1991.

[8] Ladaga, R., Active Software, in Self-Adaptive Software, P.

Robertson, H. Shrobe, and R. Lagada, Editors. 2000, Springer-Verlag: New York, NY. P.11-26

[9] Minar, N., Gray, M., Roup, O., Krikorian, R., Maes, P.,
Hive: Distributed Agents for Networking Things, Proceedings of. ASA/MA `99. 1999

[10] Nwana, H. Software Agents: An Overview. The Knowledge

Engineering Review 11 (3). 1996, p205-224

[11] Odell, J., Parunak, H. and Bauer, B., Extending UML for
agents. In the Proceedings of the Agent-Oriented Information System Workshop at the 17th National Conference on Artificial Intelligence, 2000.

9. CONCLUSIONS AND FUTURE WORK

This paper discussed issues concerning complex open systems, examined the Gaia methodology and described the ROADMAP methodology. ROADMAP extensions Gaia to provide support for requirement gathering, a formal model for the environment and knowledge, a role hierarchy, explicit modeling of social aspects between agents, and modeling of dynamic changes. We plan to extend the motivating example to a full case study to better evaluate ROADMAP. Through the process we would verify ROADMAP more thoroughly and obtain valuable feedback to our current research.

[12] Robertson, P., R. Ladaga, and H.Shrode, Introduction: The

First International Workshop on Self-Adaptive Software, in Self-Adaptive Software, P.Robertson, H.Shrobe, and R. Ladaga, (eds). 2000, Springer-Verlag: New York, NY. P.1126

[13] Waldo, J. The Jini Architecture for Network-centric

Computing. Communications of the ACM, 1999. p76-82.

[14] Weiss, G. (ed). Multiagent Systems : a modern approach to

distributed artificial intelligence. MIT Press, Cambridge, Mass, 1999.

10. ACKNOWLEDGMENTS
We would like to acknowledge our colleagues at the Intelligent Agent Lab, the University of Melbourne.

[15] Wooldridge, M. and Ciancarini, P. Agent-Oriented Software

Engineering: The State of the Art. In Agent-Oriented Software Engineering. Ciancarini, P. and Wooldridge, M. (eds), Springer-Verlag Lecture Notes in AI Volume 1957, 2001.

11. REFERENCES
[1] Blair, G., Coulson, G., Robin, P. and Papathomas, M. An
Architecture for Next Generation Middleware, Proc. Middleware '98, The Lake District, England, 1998

[16] Wooldridge, M., and Jennings, N. Intelligent Agents: Theory

and Practice, The Knowledge Engineering Review, 10 (2), pp. 115-152, 1995.

[2] Booch, G. Object-Oriented Analysis and Design (2

edition). Addison-Wesley: Reading, MA, 1994.

nd

[17] Wooldridge, M., Jennings, N. and Kinny, D. The Gaia

Methodology for Agent-Oriented Analysis and Design. Journal of Autonomous Agents and Multi-Agent Systems 3 (3). 2000, 285-312.

[3] Dertouzos, M. The future of computing, Scientific American,

July 1999.

[4] Forman, I. and Danforth, S. Putting Metaclasses to Work.

Addison-Wesley, Reading, MA, 1999

[18] Yokote, Y. The Apertos Reflective Operating System: The

Concept and its Implementation, Proc. OOPSLA `92, ACM, 1992, p414-434.

[5] Iglesias, C., Garijo, M., and Gonzalez, J. A Survey of AgentOriented Methodologies. In Intelligent Agents V Proceedings of the Fifth International Workshop on Agent Theories, Architectures, and Languages (ATAL-98), Lecture Notes in Artificial Intelligence. Springer-Verlag, Heidelberg. 1999

[19] Zambonelli, F., Jennings, N., Omicini, A. and Wooldridge,

M. Agent-Oriented Software Engineering for Internet Applications. in Coordination of Internet Agents (eds. A. Omicini, F. Zambonelli, M. Klusch and R. Tolksdorf), Springer-Verlag, 2001, p326-346.

[6] Johnson, R. and Opdyke, W. Refactoring and aggregation. In

International Symposium on Object Technologies for Advanced Software, Nishio, S. and Yonezawa, A. (eds) 1993. Kanazawa, Japan, Springer Verlag, Lecture Notes in Computer Science. p264-278.

[20] Zambonelli, F., Jennings, N. and Wooldridge, M.

Organisational Abstractions for the Analysis and Design of Multi-Agent Systems, Proc. 1st Int. Workshop on AgentOriented Software Engineering, Limerick, Ireland, 2000, 127-141