From A Conceptual Framework For Agents and Objects To A Multi-Agent System Modeling Language

Autonomous Agents and Multi-Agent Sytems, 9, 145189, 2004 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.
From a Conceptual Framework for Agents and Objects to a Multi-Agent System Modeling Language
VIVIANE TORRES DA SILVA AND CARLOS J. P. DE LUCENA {viviane,lucena}@inf.puc-rio.br Department of Computer Science, PUC-Rio, SoC+Agent Group, Rua Marques de Sao Vicente, 225 Ed. Pe Leonel Franca, 13o andar, 22453-900 Rio de Janeiro, RJ, Brazil
Abstract. In this paper we propose a multi-agent system modeling language (MAS-ML) that extends UML (Unied Modeling Language) based on structural and dynamic properties presented in a conceptual framework (metamodel) called Taming Agents and Objects (TAO). Our focus is the adaptation according to TAO concepts of the static Class diagram and the interaction Sequence diagram proposed by UML. These two diagrams have been chosen because they are the most commonly used and because it is possible to use them to illustrate both the structural and dynamic aspects of TAO metamodel. We propose a conservative extension of the UML metamodel, which includes agent-related notions that are part of the TAO conceptual framework while preserving all object-related concepts, which constitute the UML metamodel. The main dierence between our approach and the others presented in the literature is the clear denition and representation of the elements that compose MASs and their corresponding behavior. In order to extend UML with TAO non-object concepts, it is not possible to use only the three basic extensions mechanisms provided by UML and new metaclasses and stereotypes have been created and associated with the UML metamodel. Keywords: multi-agent system, UML, modeling language, metamodel, conceptual framework.
1. Introduction Multi-agent systems (MAS) are gaining wide acceptance in both industry and academia as a powerful paradigm for designing and developing software systems. Since MAS diers from object-oriented systems, the success of MASs application depends on the development of new techniques, methodologies, modeling languages, development platforms, tools and programming languages to support the specication, analysis, design and implementation of software agents and the systems in with they are embedded. MASs are composed of dierent elements that have dierent properties and characteristics and are related using dierent relationships. To reduce the risk when adopting a new technology it is necessary to present it as an incremental extension of known and trusted methods, and to provide explicit engineering tools that support industry-accepted methods of technology deployment [1, 26]. In this paper we propose a multi-agent system modeling language (MAS-ML) that extends UML (Unied Modeling Language) metamodel [34] based on Taming Agents and Objects (TAO) conceptual framework [30]. The main goal of MAS-ML
146
TORRES DA SILVA AND DE LUCENA
is to address the particular characteristics of MAS that are not addressed in the UML and are not addressed in a satisfactory manner in the proposals available in the literature. The MAS-ML denes a set of four diagrams that describes the static aspects (the elements, their properties and relationships) and dynamic aspects of MAS (the interaction between the MAS elements). The paper presents the extended UML metamodel describing the new metaclasses and stereotypes used to model MAS characteristics and the four MAS-ML diagrams that extend the UML static and interaction diagrams. TAO is an evolving innovative conceptual framework based on agent and object abstractions, which are the foundations for modeling large-scale distributed software systems. The main role of the TAO framework is to provide a unied conceptual framework to understand distinct abstractions and their relationships in order to support the development of large-scale MASs. The proposed framework elicits an ontology that connects consolidated abstractions, such as objects and classes, and other abstractions, such as agents, roles and organizations, which are the foundations for agent and object-based software engineering. The modeling language UML is widely accepted as a de jure standard for objectoriented modeling. However, in its original form it provides insucient support for modeling MASs. In order to model MAS applications it is necessary to extend the UML metamodel preserving all object related concepts while including agent-related abstractions. The extension mechanisms described in UML are the creation of new metaclasses, tag denitions, constraints and stereotypes. The creation of new metaclasses is dened as the rst-class extension mechanism [34]. Tag denitions specify new kinds of properties that may be associated with model elements. Constraints can also be attached to any model element to rene its semantics linguistically. A stereotype is a model element that denes additional values (based on tag denitions), additional constraints and optionally a new graphical representation. All model elements that are branded (classied) by one or more particular stereotype receive the values and constraints dened by the stereotype in addition to the attributes, associations and superclasses that the element has in the standard UML. Stereotypes provide a way of dening virtual subclasses of UML metaclasses with new metaattributes and additional semantics. When extending UML according to TAO concepts, it is not possible to use only the tag, constraints and stereotypes extensions mechanisms provided by UML. Sometimes it was necessary to add new metaclasses to the UML metamodel. For instance, stereotypes, which are the second most powerful extension mechanism in UML, were not used to dene agents and organizations because objects and those elements have dierent properties and dierent relationships. If stereotypes were used, the extended element would have the same properties and relationships dened on the basic class of the stereotype and also additionally values and constraints dened by the stereotypes. Although we have extended UML by creating new metaclasses, we have produced a conservative extension [33], i.e., the extensions made to UML were strictly additive to the standard UML semantics, which remained unaltered. By augmenting the
MULTI-AGENT MODELING LANGUAGE
147
metamodel we have helped to incorporate new modeling capabilities into UML therefore contributing to its evolution. The potential benet of such extension is that it could fully capture every desired feature and provide native support for MAS modeling in UML. Other proposals such as [5, 26, 35, 37] have also extended UML to encompass agent characteristics. The main important dierence between our approach and others presented in the literature is (i) the proposal of a clear denition and representation of the elements that compose MASs, (ii) the clear denition and representation of the relationships between the elements in static diagrams, and (iii) the representation of the interactions between all these elements in a dynamic diagrams. We create dierent diagram elements and dierent diagram features to represent the new elements, relationships and their semantics. As MAS-ML is based on TAO, by using the diagrams proposed by MAS-ML the designer is capable of representing all abstractions associated with the MAS application and of describing their static relationships and dynamic interactions. Each proposed static diagram describes a specic view of the application modeling the elements and the relationships related to the view. For instance, the Role diagram describes the roles played by agents, organizations and objects and the relationships associated with them. In addition, the users of MAS-ML models easily identify the abstractions and the relationships presented in the models, since they are represented as dierent diagram elements dening specic semantics. The modeling language presented in this paper is a partial description of MASML since its complete version will require extensions to all the UML metamodels (its complete set of diagrams). In this paper we concentrate on the approach used to extend UML and on the concepts that justify the extensions. The paper is organized as follows. Section 2 explains the relationship among UML, TAO and MAS-ML based on a four layer metadata architecture and presents a description of an example that is modeled by using the MAS-ML. Section 3 describes the structural and dynamics aspects of the TAO metamodel. Section 4 describes the extension of UML metamodel according to the TAO framework. Section 5 illustrates the use of MAS-ML. Section 6 reviews some related work. Finally, Section 7 discusses some future directions and presents the conclusions of our work.
2. The relationship among UML, TAO and MAS-ML The MAS-ML is a modeling language that extends UML based on the concepts of multi-agent systems dened in TAO. To better explain the relationship among UML, TAO and MAS-ML we use a four-layer metadata architecture described in the MOF specication [22]. The four architecture layers are: meta-metamodel layer, metamodel layer, domain model layer and instance layer (see Figure 1). The meta-metamodel layer (Figure 1 rst layer) is comprised of the description of the structure and semantics of metametadata. OMG species a meta-metamodel called MOF that denes an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels. In TAO we use the ER model (Entity-Relationship model) [7] to
148
Meta-metamodel layer
MOF meta-metamodel
ER meta-metamodel
instantiation
UML metamodel
TAO metamodel
MAS-ML metamodel
Metamodel layer Domain model layer
MAS-ML models
Instance layer
Figure 1. Four-layer metadata architecture.
describe the entity and relationship meta-metadata that appear in this layer. In our approach, ER is used as a meta-metamodel because it describes meta-metadata in the architecture. The entity and relationship meta-metadata provide the basic denitions to describe the dierent entities and relationship instances that appear in the metamodel layer. The metamodel layer (Figure 1 second layer) is comprised of the description of the structure and semantics of metadata that are informally aggregated as metamodels. Metamodels are instances of meta-metamodels and metadata are instances of metametadata. OMG denes the UML metamodel that is an instance of the MOF meta-metamodel. We dene the TAO metamodel that is an instance of the ER metametamodel and call it a conceptual framework in [30]. The UML metamodel species a modeling language that incorporates the objectoriented communitys consensus on core modeling concepts. The TAO metamodel species the MAS core concepts (abstractions and their relationships) that incorporate all object-oriented concepts presented in the UML and new concepts specically dened for agent-oriented development based on our experience and on work described in the literature. Our proposal is to create the MAS-ML metamodel that extends the UML metamodel according to the concepts described in the TAO metamodel, as illustrated in the second layer of Figure 1. The MAS-ML species a modeling language that incorporates the object and agent-oriented concepts. The domain model layer (Figure 1 third layer) depicts the data specic to the application domain. The metadata at the metamodel layer are instantiated into data
149
through domain models using domain information. The concepts modeled using the MAS-ML modeling language are instantiated according to the domain information creating the domain models. The instance (information or implementation) layer (Figure 1 fourth layer) characterizes the possible domain model occurrences. This layer describes the specic instances of the domain model data that may occur during the lifetime of the modeled application. This paper presents the MAS-ML metamodel that unies the UML metamodel and the TAO metamodel. Section 3 presents the denition of the entities and relationships described in TAO. Section 4 presents the extension of the UML metamodel according to these denitions. Note that Section 3 describes the entities, their properties and relationships in a conceptual level. The presentation of the implementation characteristics of these concepts is not the aim of this paper, i.e., the paper will not describe the map between the conceptual level and the implementation level. Section 5 illustrates the use of the MAS-ML metamodel to generate MAS-ML models following a small example of a domain. The system under development is a marketplace system that presents characteristics of three dierent types of markets: a market for used goods, an auction market and a supermarket. Examples of a used goods market is a market that sells used books and CDs and examples of auction markets are markets that sell items using, for instance, an English auction and a Dutch auction. Supermarkets are markets that may sell wholesale or retail items. Consider a supermarket domain where buyers and sellers negotiate the exchange of products. Sellers advertise their desire to sell products, publishing oers in the supermarket. Buyers access the supermarket in order to buy products. They look for oers that match their needs. Buyer can buy wholesale or retail items. Usually, wholesale items have a lower price per unit. However, sometimes the buyer does not need all the units packaged as one item. Therefore, buyers can form groups to nd other buyers interested in the same item. The group of buyers buys the item and distributes the units among the buyers.
3. TAO metamodel To make the explanation in this paper as self-contained as possible, we will summarize the TAO metamodel or conceptual framework as presented in [30] in the present section. Currently, TAO focuses on the structural aspects of MASs and does not describe the dynamics processes involved in MASs. In this section, we extend TAO by describing some dynamic behavior of MASs. We do not present a complete set of dynamic properties of the TAO framework since potentially there are an innite number of dynamic behaviors involving MAS elements. We concentrate on a set of behavioral notions that, when associated with the TAO framework, allows us to extend UML to deal with objects and agent-related abstraction in its structure and interaction diagrams.
150
3.1. Structural aspects TAO The entities dened in TAO are object, agent, organization, role (agent role and object role), environment and event. Because of similarities among some entities, we have dened a new abstraction called element that is the basis for the denition of most entities. An element is an entity that has properties (state and behavior) and relationships with other elements. Objects, agents, environments, organizations, object roles and agent roles are entities whose denitions are based on the element abstraction. Their denitions extend an element by identifying specic properties and relationships. Event is the only entity in TAO that is not based on the denition of element. This is because events do not have state, behavior or relationships. The state of an element denes information about other elements of the system and the behavior of an element denes the actions or operations that the element can perform. An element must be related to another element, i.e., a relationship must exist between two elements, so that they can interact. The relationships link two elements and describe how these elements are related to each other. Dierent elements are related in dierent ways, i.e., there are dierent types of relationships. An element class denes properties and relationships that are common to all its instances. An element instance is a concrete manifestation of an abstraction to which a set of properties and relationships are applied [4]. An element instance of a class fullls the description of its class. 3.1.1. Object. An object is an element that has state, behavior and relationship. The state of an object does not have any predened structure. It stores information about itself, about the environment and about other objects. The behavior of an object denes the operations that it can perform. The object relationships describe how objects are linked to system elements, such as other objects, agents, and roles. Moreover, objects can play roles dened by the organization that uses the object. An object class denes the structure and behavior of similar objects [3]. An object has control of its state. During the object lifetime, it performs operations that can modify its state. On the other hand, a traditional object cannot modify its behavior and has no control over it, i.e., an object is not autonomous in the sense it does everything that another element requests. In this way, objects are passive elements that do whatever anyone asks them to do and only when they are asked. 3.1.2. Agent. Agents are elements that dene structural state and behavioral properties. The state of an agent is expressed through mental components such as beliefs, goals, plans and actions [13, 24, 29] characterizing the mental state of the agent. The mental state of an agent is characterized by the set of goals, beliefs, actions and plans dened by the agent. An agent has beliefs or knowledge about the environment, about itself and about other agents. The beliefs include what the agent knows, what the agent views, its memories and its perceptions about everything that happens in the MAS. The agents goals consist of future states or desires that agents would like to reach, or satisfy. An agent achieves a goal by executing a plan, which can be selected from a list of plans. A plan can be modeled using state machines. A
151
state machine is composed of an initial state, intermediate states, nal states and transitions that link two states. When a state machine is associated with a plan, the initial state describes restriction to the mental state of an agent before executing the plan. Similar to the denition of pre-conditions, an agent can execute a plan only if its mental state is equivalent to the restrictions described in the initial state of the plan. Intermediated states describe the actions that the agent must execute. The agent may change its mental state while executing actions. Transitions are dened based on the changes of the agent mental state. An agent changes from a state to another if its mental state changes according to the denition of the transition that links the states. Finally, nal states describe the mental state of the agent after it executes the plan. An agent should be able to choose a plan based on internal goals. The actions associated with the plan will bring the agent closer to its goals. For instance, goals can be expressed using temporal logic and beliefs can be expressed using rst-order logic. The behavior of an agent is expressed through its plans and actions that are based on its agent characteristics, e.g., interaction, autonomy and adaptation [12, 15, 24]. The relationships describe how an agent is linked to another element. An agent class denes the relationships between it and other elements and the initial mental state of its instance. The agent class denes the initials beliefs, goals, actions and plans of the agent instance. Each agent instance can change its initial mental state adding, modifying or removing its initials beliefs, goals, actions and plans. Agent vs. object. The state of an agent has a mentalistic structure [35], as we have already seen. The agents mental state extends the denition of state dened for objects because it adds to its state the denition of its behavior. Thus, the mental state of an agent consists of both its state and behavior. In addition, the behavior of agents extends the behavior of objects. Another dierence between agents and objects is related to agent characteristics. An agent is an autonomous and interactive element that sends and receives messages. An object is an interactive element but it is not autonomous. Objects are reactive and passive elements since they need the assistance of another element to do their job and since they respond to any request for assistance. 3.1.3. Environment. Agents, organizations and objects inhabit (or are immersed in) environments [13, 21]. An environment extends the denition of an element since it further denes its properties, i.e., its state and its behavior, and its relationships. The state and behavior of an environment is dened based on its characteristics. An environment can be a passive element, such as an object, or it can be an active element, such as an agent having agency characteristics such as autonomy, adaptation and interaction. An environment class modeled as an object class denes the initial attributes, the methods and the relationships that link the environment class and other classes. During the lifetime of an environment instance modeled as an object it performs operations that can modify its state, i.e., its attributes. An environment class modeled as an agent denes the relationships between it and other elements and the initial mental state of the environment instances. The environment
152
instances of this class can change their initial mental states adding, modifying or removing their initial beliefs, goals, actions and plans. 3.1.4. Event. Events are generated in dierent ways. They can be generated by objects and environments modeled as objects through the execution of their operations, and by agents, organizations and environments modeled as agents [35] through the execution of their actions. An event generated by the environment, by an agent, by an organization or by an object can trigger the execution of actions associated with agents or operations associated with objects that perceive the event. As a consequence, events are related to actions and operations that generate them and to actions and operations that perceive them. 3.1.5. Organization. Organizations group together the agents of a MAS [5, 29]. An organization denes sub-organization and a set of axioms that agents and suborganizations must obey. Axiom is an established rule, principle or law. The axioms characterize the global constraints of the organization. An organization also denes roles that must be played by the agents and sub-organizations within it. Every agent or sub-organization of the MAS plays at least one role in an organization. The state of an organization is represented by its goals, beliefs and axioms. An organizations behavior is characterized by its actions and its plans and by the behavior of the agents that play roles in this organization. The relationships describe how an organization is linked to other elements. An organization class denes the relationships between it and other elements and the initial mental state of its instance, i.e., the organization class denes the initials beliefs, goals, actions, plans and axioms of the organization instances. Each organization instance can change its initial mental state adding, modifying or removing its initials beliefs, goals, actions, plans and axioms. 3.1.6. Role. The two most important properties of roles are (i) its denition in the context of an organization and (ii) the fact that a role instance must be played by an agent, by an object or by a sub-organization. A role guides and also restricts the behavior of the instances that play the role. A role is an element since it denes a set of properties and relationships. Object role. An object role guides and restricts the behavior of an object since it describes a set of features that are viewed by other elements [17]. Since an object is not an autonomous element its behavior is directly associated with the features viewed (or accessed) by other elements. The state and behavior of an object role are similar to the denition of the objects state and behavior. The state of an object role keeps information and the behavior of an object role keeps operations. The element associated with the object role manipulates the object role that inuences the object related to it. An object is not aware of the role that it is playing. It is the object role that knows the object that it is associated with. The element that wants to access the object interacts through the object role that it will play. An object
153
role may restrict access to the state and behavior of an object but may also add information, behavior and relationships to the object that plays the role. The relationships of object roles describe additional relationships and types of relationships that were not previously available to objects. An object role class denes the relationship between it and other elements, the methods and initial attributes of the object role instances. During the lifetime of an object role instance it can modify its state, i.e., its attributes. Furthermore, it can inuence the object that is playing the role, calling the objects methods. Agent role. An agent role diers from the denition of an object role, since an agent role guides and restricts the behavior of an agent. This is because it describes the goals of the agent when playing the role, additional beliefs, the actions that an agent must perform and the actions that an agent can perform while playing the role. An agent role adds new goals and beliefs to the set of goals and beliefs associated with an agent and describes duties, rights and protocols related to an agent while it is playing the role. An agent role does not add actions or plans to the agent. An agent must be capable of performing actions and plans described in the role. An agent role is an element since it has state, behavior and relationships with other elements. The state of an agent role is dened by its beliefs and goals. The beliefs of the roles are related to the organizations facts, e.g., information about the other roles and information about the objects available in the organization. The goals of the roles characterize the goals that the agent must achieve while playing the role. The goals of the roles grouped together form the organizations goals. The duties, rights and protocols dene the behavior of an agent role. The duties dene actions assigned to the agent playing the role, i.e., its responsibilities, and the rights describe actions that the agent can execute when playing the role, i.e., they describe permissions to actions. The protocols dene the interactions between roles and other elements through the specication of the messages. A protocol denes the set of messages that an agent is allowed to send to another agent in an interaction and the message that it can receive from the other agent. The denition of the relationships of an agent role is based on the protocols associated with the role. In this way, the agent role adds a set of relations to the agent that plays the role. An agent role class denes the beliefs and the goals associated with all its instances. When an agent role is instantiated by an agent, for instance, the set of beliefs associated with the agent is added to the set of beliefs associated with the agent role instance and the set of goals of the agent is added to the set of goals of the role. Moreover, an agent role class denes the duties, rights and protocols associated with all its instances. The agent playing the role instance must execute according to the duties, rights and protocols specied at the agent role instance that it is playing. The agent that is playing an agent role bases its execution on the denition of the role. Every agent plays at least one role in an organization, i.e., each agent is assigned to at least a specic role in the system [28, 40]. However, an object is not compelled to play roles. Objects play roles in an organization depending on the relationships that
154
the organization denes. For instance, organizations may dene relationships between agent roles and object roles. 3.1.7. Relationships. The most important relationships dened in UML are dependency, generalization, association and realization. Semantically, all relationships, including generalization, association and realization are kinds of dependencies. Generalization, association and realization have enough important semantics about them that they warrant treatment as distinct kinds of relationships in the UML [4]. During the extension of the UML new entities and new relationships were added to the set of entities and relationships dened in the UML. Due to the particular way that new entities are related, some relationships dened in the UML were redened and other relationships were created. The redenition of existing relationships and the denition of new relationships were based on the study of a set of MAS applications presented in the literature [13, 15, 38]. The dierent interactions between the elements that compose MASs were analyzed and new relationships were dened. For instance, the relationship between an environment and the entities that inhabit the environment is semantically dierent from the relationship between an organization and the role that it denes. As a consequence TAO denes eight relationships among its elements. Semantically, the inhabit, ownership, play, control, and aggregation relationships are kinds of association, and the association and specialization relationships are kinds of dependencies. Inhabit. The inhabit relationship species that the element that inhabits the citizen is created and destroyed in the habitat and may leave and enter habitats, respecting the habitat permissions. The habitat knows all the citizens that inhabit it and the each citizen knows it habitat. This relationship is applied to environments and agents, environments and objects and environments and organizations. Ownership. The ownership species that an element the member is dened in the scope of another element the owner and that a member must obey a set of global constraints dened by its owner. The member does not exist outside of the scope of it owner. The owners know their members and each member knows it owner. This relationship is applied to roles the members and to organizations the owners. A role can only be played by elements in the organization that it has dened. The owner has full control of its member, i.e., it is the organization that denes who can play the roles that it identies and what role can be played by an element. Those decisions are based on the organization goals. Play. The play relationship species that an element is related to a role. When an agent (or an organization) is playing a role the set of goals and beliefs of the agent (or organization) are increased by the goals and beliefs of the role. The actions of the agent or organization are restricted by the duties, rights and protocols dened by the roles. Moreover, agents and organizations interact through the roles that they
155
play. The relationships that link two roles dene the interactions between the elements that play those roles (see the control and dependency relationships, for instance). When an object is playing a role, elements interact with the object through its role. The relationship between the element and the object is dened by the relationship between the element and the object role. In addition, the elements view the properties of the object role and not the properties of the object. It is the object role that accesses the properties of the object. Specialization/inheritance. The specialization relationship denes that the sub-element that specializes the super-element inherits the properties and relationships dened in the super-element. The properties inherited may also be redened by the sub-element. Moreover, the sub-element may also dene new properties and new relationships. When an agent class B specializes an agent class A, the goals, plans, beliefs and actions dened by the agent class A are inherited by the agent class B. The agent B can dene new properties and can also redene inherited ones. For instance, the agent class B may dene new plans and may also redene a plan inherited from agent class A, associating dierent actions. When an organization class B specializes an organization class A, the goals, beliefs, plans, actions and axioms dened in the organization A are inherited by the organization B. The organization B can dene new goals, beliefs, plans, actions and axioms and can also redene any goal, belief, plan, action or axiom. Control. The control relationship denes that the controlled element must do anything that the controller element requests. The controller element knows the elements that it controls and each controlled element knows the elements that control itself. The control relationship can be used between two agent roles. The controller and controlled elements will be the agents or organizations that are playing the roles. For instance, suppose an agent role Boss and an agent role Employee related through the control relationship. The role Boss controls the role Employee. Agents playing the role Boss control agents playing the role Employee. The control relationship is not dened between object roles because an object always controls other objects. A traditional object has no control of behavior, i.e., an object does everything that another element requests. Dependency. This relationship denes that an element the client may be dened to be dependent on another one the supplier to do the clients job. A dependency is a using relationship specifying that a change in the specication of one thing may aect another thing that uses it but not necessarily the reverse. The client always knows its suppliers but the opposite may not be true. An agent role may depend on another agent role or on an object role. Object roles can only depend on another object role. Suppose an agent role Employee related to an agent role Manager by the dependency relationship. Agents playing the role Employee will depend on agents playing the role Manager.
156
Association. If an element is associated with another element, it knows that the other element exists. The association relationship denes that an element interacts with another one. Associations may be used between roles (object roles or agent roles), environments, objects, agents and objects, organization and objects, and roles and objects. Aggregation. If an element is aggregated with another element, we say that it is part of an aggregator. The aggregator may use the functionality available in its parts. This relationship may be applied between object roles, agent roles, objects, agents and organizations. For instance, the relationship that links an organization and its sub-organizations is the aggregation relationship.
3.2. Dynamic aspects of TAO A large amount has been reported on dening the dynamic properties of the MAS elements [8, 10, 13, 31, 32]. In this section, some dynamic properties will be described based on the denition of elementary and high-level dynamic processes. The elementary dynamic processes are domain-independent dynamics that are the basis for other higher-level dynamic patterns and domain specic behavior. These dynamics are related to the statements issued while dening the elements of MASs. The dynamics of MASs involve the creation of the elements, the destruction of the elements and the interaction between the elements. We consider the creation and destruction processes as elementary dynamics that occur in every MAS. Some interaction, such as agents entering or leaving an organization, is considered a higher-level domain-independent dynamic based on elementary behavior. In this paper, we will focus on ve dynamic processes: organization instance creation, agent instance creation, role instance creation, agent entering into an organization and agent creating sub-organizations. The ve dynamic processes have been chosen because they are related. The creation of an agent is related to the creation of an organization since an agent plays at least one role in an organization. The creation of a role depends on the creation of an agent, the creation of a sub-organization, or on the intention of an agent to play a role in an organization. The inclusion of an agent in an organization is associated with the creation of a role instance to be played by the agent. The creation of an organization by an agent depends on the creation of a role instance to be played by the organization and the creation of another role instance to be played by the agent in the organization. The dynamic of creating an organization instance describes the general process of creating any organization in the system and the dynamic of an agent creating an organization describes what motivates an agent to create a sub-organization and how an agent accomplishes this task. The behavioral constructs to be described as follows inuence the choices made in the sequence diagram of our UML extension. This will be discussed in Section 4.3. 3.2.1. Elementary dynamic behavior. Next we present a number of representative situations of domain-independent primitive dynamic behavior of agent-related abstraction.
157
Creation of an organization. The creation of every MAS element is conditional upon the creation of an environment instance. The environment must be created before the other elements because the elements inhabit the environment. At least one organization must inhabit the environment [30]. We call this organization mainorganization. The creation of agents is conditional upon the existence of the mainorganization. Agents are created to play roles in organizations. Every instance must be created based on a dened class. Each organization instance is created based on an Organization class. Upon the creation of an organization instance it is possible to modify the initial values of organization features like goals, beliefs and axioms. Nevertheless, it is not possible to dene new agent role classes. After it is created, the organization must be registered in the environment. The register allows agents to nd organizations to play roles. When an organization is created, the role instances associated with the organization are not created. A role is created only when there is an agent or sub-organization to play the role. If the organization being created is a sub-organization, a role instance must be created and associated with the sub-organization. Every sub-organization plays at least one role in the organization that owns it. The organization that owns the sub-organization denes a set of role classes that are instantiated based on the creation of sub-organizations. The only organization that does not play roles is the main-organization since it is not a sub-organization of any other organization. Creation of an agent. An agent instance must be created based on one of the agent classes available in the system. An agent is created in an environment to play a role in an organization that is registered in the same environment. When created, the agent instance is registered in the environment and a role instance is associated with it. As every agent has to play at least one role in an organization, a role instance must be created and associated with the agent instance. The role instance created is related to the organization where the agent will play the role. The process of creating an agent is completed when it is registered in the environment and is playing a role. Creation of a role. The creation of a role instance is conditional upon the denition of the agent, object or sub-organization that will play the role [17]. It is not possible to create a role instance without an agent, object or sub-organization to play the role. A role instance is created when an agent or sub-organization commits to the role or when an element wants to interact with an object through the object role dened in an organization. Objects are associated with a role by the element that interacts with the object through the object role. Agents and suborganizations commit to a role when they are created. Moreover, agents commit to roles when they need to enter an organization to play another role. The creation of a role instance is based on one of the agent role classes or object role classes associated with an organization. After the creation of the role instance, it is associated with an agent, an object or a sub-organization instance. A
158
role instance relates the element that plays the role to the organization where the role is dened. Every organization instance knows the role instances being played in it. 3.2.2. Higher-level dynamic behavior. Because of the richness of the agent model there is a potentially innite number of higher-level domain-independent dynamic behaviors involving agents, roles and organizations. The systematic classication of these higher-level dynamic behaviors may lead to patterns of behavior. This classication and respective use in meaningful examples is outside of the scope of this paper. In this paper we will describe two higher-level dynamic processes and the corresponding questions that motivates them. Agent entering an organization. When an agent enters an organization, a role instance must be created and associated with the agent. The dynamics of an agent entering an organization depend on the dynamics of role creation. Two things may motivate an agent to enter an organization and to create an organizations: the agent is nding it dicult to achieve its goals or a sub-set of its goals; or the agent realizes that it can increase its eciency in achieving its goals. An agent may nd it dicult to achieve its goals for many reasons. We enumerate a list of three possible reasons: (i) There is no available time for an agent to achieve its goals. The agent knows the set of tasks that it must perform and can perform those tasks but does not have available time to execute the tasks without assistance. (ii) The agent is not capable of performing a set of tasks alone. The agent knows how to execute its tasks and has available time but it is not capable of accomplishing a set of tasks alone. For example, an agent needs a resource that it does not have permission to access. (iii) The agent does not know how to do a set of tasks. The agent knows the tasks it is supposed to perform but it does not know how to go about executing the tasks; for instance, it is not a specialist in the problem. The agent needs to interact with other agents that know how to perform the tasks. When an agent is not able to achieve its goals without the help of others, the agent needs to collaborate with other agents in order to ask for help. Each organization denes a set of role relationships that specify the collaboration between the agents that play the roles. The agent that needs help has two possibilities: either enter an organization or create a new organization. In both cases, the agent will choose a role to play and collaborate with other agents. Assuming that the environment registered all its organizations and agents, when an agent wants to play a role it looks for organizations in the environment. The register of organizations may contain the identier of organizations, the goals of the organizations and the goals of its roles. The register of an organization can be viewed as an announcement of the roles that may be played by agents in that organization. An agent may decide whether to enter an organization based on the goals of the organization and on the agents own goals. The agent matches the organization
159
goals to its own goals to see if they are compatible. The match of goals may be as simple as comparing the elements of a set of goals or as complex as matching logical expressions. It is outside the scope of this paper to deal with the details of such matching. If the agent nds that the goals are compatible, the agent next should decide which role it should play. If the environment does not register the information about the goals of the role, the agent can get the information from the organization. An agent decides which role it should play based on the goals of the role and on its own goals. The agent matches the goals of the role to its own goals. If the goals are compatible, the agent may ask the organization to play the role. Organizations can permit or deny the inclusion of agents. An organization decides the necessity of having an agent playing the chosen role based on its goals. Having the agent playing the chosen role may be contrary to the organizations goals, it may not inuence the goals of the organization or it may prevent the organization from achieving its goals. If the agent eectively enters an organization, the agent commits to the organization to play the role and a role instance is created. The agent agrees to obey the duties and rights described in the role and the axioms described in the organization (Section 3). Agent creating a sub-organization. Depending on the specication of the MAS, an agent may or may not be allowed to create sub-organizations. Sometimes an agent may only be allowed to play roles in organizations that already exist. The reasons for an agent to create an organization and enter an organization to play a role are basically the same. The agent is nding it dicult to achieve its goals. The agent should then look for organizations already created in the system before trying to create a new organization to play a role. The agent should look for organizations that have the characteristics needed by the agent to achieve its goals. The agent should only create a new organization in the case that there is no organization that has goals that are compatible with the goals of the agent. If an agent wants to create an organization it must verify if the organization can be created. The agent can either ask the environment or the organization that will be the owner of the new organization. Moreover, depending on the system design, there may be an agent that has the power to decide if a specic type of an organization can be created. The agent needs to know how to create organizations or the agent needs to know about who has this knowledge. The organization creator needs to know the set of features of the new organization. When creating organizations, the initial values of the organization features can be modied. After creating the organization and the role instance that the organization will play, the agent may choose one role to play in the organization. 3.2.3. State machine representation. We present two state machines that describe the states associated with the dynamic processes described in Sections 3.2.1 and 3.2.2. Figure 2 shows a state machine representing the creation of an agent, a role
160
Creation of an agent Creation of a role
Creation of an organization
Choosing an Agent class
Choosing an AgentRole class
Choosing an Organization class
Creating the agent instance
Creating the role instance
Creating the organization instance
Registering the agent in the environment
Associating the role to the agent
Registering the organization in the environment [sub-organization] [main-organization]
Figure 2. State machine I: the creation of an agent, a role and an organization.
and an organization. Note that the creation of an agent and a sub-organization is conditioned to the creation of a role, since agents and sub-organizations must play at least one role. The only organization that does not play roles is the main-organization. Figure 3 illustrates a state machine representing an agent entering an organization and an agent creating a sub-organization. Agents decide to search for organizations when they nd it dicult to achieve their goals. If an agent does not nd an organization to play a role the agent may decide to create an organization. State machine II includes two of the primitive dynamic behaviors represented in state machine I (it assumes the agent has already been created). The creation of roles and the creation of organizations are used as basics components to express the higher-level behavior of an agent entering an organization and an agent creating an organization and entering it to play a role.
4. Extending UML according to the extended TAO metamodel The TAO metamodel describes concepts related to both the object and MAS theories and the UML metamodel describes concepts related to object-oriented theory. Our purpose is to extend the UML metamodel to incorporate concepts related to the MAS theory. In order to extend UML according to TAO non-object concepts, new metaclasses and stereotypes have been created and associated with the UML metamodel. As a consequence, new diagrams such as Organization Diagram and Role Diagram have been created and UML diagrams that already exist such as Class Diagram and Sequence Diagram have been adapted.
161
Agent creating an sub-organization
Agent entering an organization
Playing roles [difficult in achieving the goals]
[all roles have been already searched] [goalOrg not match goalAgent]
[all orgs have been already searched]
Searching for an organization in the environment Choosing a role [org already searched] [org found] [new org found]
Verifying if a new organization can be created [can not be created] [can be created] [the agent knows how to create] Creation of an organization [agent does not know how to create]
Verifying if goalOrg match goalAgent
[goalOrg match goalAgent]
Selecting a role type in an organization [role type already searched] [new role type found] Verifying if goalRole match goalAgent [goalRole not match goalAgent] [goalRolel match goalAgent]
[role type found] Searching organization creator [creator not found] [creator found]
Choosing an Organization class
Giving the information about the new org to the creator [create org] Creation of a role
Creating the organization instance
Asking organization permission to enter Choosing an AgentRole class [create a role to the organization] [entrance not allowed] [entrance allowed & create a role to the agent]
Registering the organization in the environment
Creating the role instance
Associating the role to the agent
[role associated to an agent] [role associated to an organization]
Figure 3. State machine II: an agent entering in an organization and an agent creating a sub-organization.
The goal of the proposed diagrams is to visually present the elements, their properties and relationships as dened in Section 3. TAO denes three main concepts elements, properties and relationships that have been mapped to the UML metamodel. Some elements dened in TAO were directly mapped to existing UML metaclasses and some properties were directly associated with existing UML features through the use of stereotypes. Other elements caused the creation of new metaclasses and other properties caused the creation of new UML features. A set of relationships such as association and aggregation described in TAO have been associated with the respective relationships dened in the UML Class diagram. Some relationships that are typical of MAS have been created and incorporated into new structure diagrams.
162
4.1. Extending the UML metamodel As described in Section 3, TAO denes seven entities. An element is a special entity that has properties (state and behavior) and relationships with other elements. The elements of TAO are objects, agents, organizations, object roles, agent roles and environment. A special entity that is not an element is called an event. An element declared in TAO is represented as an extension of the Classier metaclass dened in UML since they share similar characteristics. A Classier has structural features, behavioral features and relationships to other Classiers. While extending the UML and dening the elements and their properties in a conceptual level, some oversimplications were made in order to make the modeling representation of the properties easier and clear. The aim of the models is to graphically represent the properties of each modeling element. Note that the paper does not describe the implementation level related to these concepts. The belief and goals associated with agents, agent roles and organizations are represented by attributes that have a name, a type and a value. It is not the aim of this paper to discuss complex implementation of goals and beliefs that could be implemented using temporal logic and rst-order logic, for instance. Axioms associated with organizations were also dened as attributes. Plans of agents and organizations are represented by the name of the plan and the actions related to the plan. During the creation of design models it is important to identify the plans and not completely describe them. Actions, duties and rights are identied by their assignment. The implementations of actions are not addressed in the models. The protocols dened by agent roles are represented by the name of the protocol and the set of messages associated with it. Each message is represented by its name, the identication of the sender and the receiver, and its content. 4.1.1. Object and event. The denitions presented in TAO for the entities object class and event are similar to the denitions presented in the UML metamodel for the metaclasses called Class (specialization of the Classier metaclass) and Event, respectively. So, we have used a direct mapping from these TAO entities to the respective UML metaclasses. 4.1.2. Agent. Based on the dierence between agents and objects presented in Section 3.2, we did not create a stereotype < <agent> and refer it to the UML > metaclass Class as others proposals such as [1, 2, 11, 26] have done. We have proposed a new metaclass called AgentClass. The AgentClass extends the UML metaclass Classier that is associated with the StructuralFeatures and BehavioralFeatures metaclasses. The StructuralFeatures metaclass is a generalization of the Property metaclass (attributes of a class are represented by instances of Property) and the BehavioralFeatures metaclass is a generalization of the Operation metaclasses, according to the UML denition [34]. The structural features dened by an agent are goal and belief and its behavioral features are action and plan. To describe the AgentClass completely it is necessary to dene the agent features goal, belief, action and plan.
163
Goal and belief. Goal and belief are dened as stereotypes based on the metaclass Property instantiated as an attribute. The stereotype < <belief> is a simple > extension of Property. It does not specify any tag or constraints. It only describes the attributes, which are beliefs. The stereotype < <goal> describes one tag and one > constraint. The tag planTag links the goal to a set of plans that achieves the goals. The constraint states that the stereotype < <goal> is dened by an agent, a sub> organization or by an agent role. When an agent or sub-organization denes a goal, the tag planTag is associated with a set of plans, but when an agent role denes a goal, the planTag is empty since roles do not dene plans. Action. Actions cannot be dened as a stereotype based on the metaclass Operation since the denition of actions and operations are dierent. An operation may be implemented by a method that can be requested from an object. And actions are never called by another object or agent, but rather only executed under the control of the agent itself. Agents interact, sending and receiving messages and not calling the execution of actions. Moreover, we have not used the metaclass Action dened in the UML common behavior package to represent actions of agents because the denition of the actions of agents that we propose is dierent from the denition of action that UML proposes. The metaclass Action dened in the UML metamodel is an abstract metaclass and it can be realized by sending a message to an object, something that is contrary to our denition. We have created a new metaclass called ActionAgent that extends the metaclass BehavioralFeature to represent the actions executed by agents. Similar to the metaclass Operation, the new metaclass ActionAgent is associated with the metaclass Constraints that denes the stereotype < <precondition> and < > <postcondition> The stereotype < >. <precondition> is used to describe the condi> tions that must be satised before the execution of the action and the stereotypes < <postcondition> is used to describe the conditions that must be checked after > the execution of the action. If the post-conditions are satised the correctness of the action is guaranteed. Plan. A new metaclass called PlanClass has been created to specify the agent feature plans in UML. A plan is represented by a sequence of actions that is executed by an agent to achieve goals. A new metaclass should be created because there is no metaclass in the UML metamodel with the same meaning of plan. The metaclass PlanClass is a specialization of the BehavioralFeature metaclass. A stereotype to describe plan based on the denition of the metaclass ActionAgent was not created because a plan is not an abstraction to be executed but a sequence of such abstractions, that we call actions. 4.1.3. Object role. The UML metamodel denes a metaclass called ConnectableElement that denes the role of objects in collaborations. This denition in UML states that an object role restricts the view of an object that participates in collaborations. The features viewed by other objects in a collaboration are the ones dened in the role. Nevertheless, Kristensen and other authors in [15, 1719, 20] dene that
164
the power of roles is not limited to restricting the features of an object but also can be used to enhance an object with additional features. An object role guides and restricts the behavior of an object since it describes a set of features that are viewed by other elements. Since an object is not an autonomous element, its behavior is directly associated with the features accessed by other elements. In order to comply with these ideas, we have two options: to create a new metaclass or to adapt the metaclass ConnectableElement. We propose to create a new metaclass called ObjectRoleClass since, besides adapting the denition of the metaclass ConnectableElement, we would need to change the representation of a ConnectableElement in Class diagrams. The UML metamodel illustrates a role played by an object in a relationship associating a string with the objects Class. The role does not describe the features that are viewed by other objects. The new metaclass ObjectRoleClass is a specialization of Classier. So the ObjectRoleClass has BehavioralFeature and StructuralFeature. The features of the ObjectRoleClass represent the view other elements have of the object playing the role. The ObjectRoleClass may restrict the access to attributes and methods described in the objects Class and may also add new attributes and methods to the objects Class. 4.1.4. Agent role. An agent role diers from the denition of an object role, in that an agent role guides and restricts the behavior of an agent (or an organization) because it describes the goals of an agent (or organization), additional beliefs, the actions that an agent (or organization) must perform and the actions that an agent (or organization) may perform while playing the role. While the object role is concerned with guiding and restricting the behavior of an object, the agent role is concerned with guiding and restricting the autonomous behavior of the agent (or an organization). Objects act based on the interactions with other objects and agents act based on their autonomous characteristics. To illustrate better the dierence between the role played by an object and the role played by an agent we have created a new metaclass called AgentRoleClass to represent the roles played by agents. The AgentRoleClass can add or restrict the agent StructuralFeatures because it species some goals and beliefs. The AgentRoleClass does not add BehavioralFeatures to the agent playing the role but restricts its actions by describing duties, rights and protocols that the agent must obey. From the perspective of elements outside of an organization, sub-organizations can be viewed as agents that play roles in the organization where they are dened. So, the denition of the AgentRoleClass metaclass is applied to both agent and sub-organizations. In [26, 35, 36] the agent type of a problem domain represents a role played by agents of a more generic type. An agent is an instance of an agent type described in the model. Agent type (or role) is the class abstractions instantiated to generate agents. Therefore, the denition of agent type presented in [26, 35, 36] is dierent from the denition of agent role and agent class (or type) presented in this paper. An agent is an instance of an agent class. And an agent role instance is an instance of an agent role class. Agent classes dene the properties (beliefs,
165
goals, plans and actions) and relationships of agents and agent role classes dene the properties (beliefs, goals, duties, rights and protocols) and relationships associated with agent roles instance. In [5, 6] the authors present the organization and agent/role views that identify the agents, organization and roles. However, they did not describe the properties of the agent roles and the relationships between the agents and their roles. Duty and right. Duty and right are dened as a stereotype of the metaclass ActionAgent. The < <duty> stereotype denes actions that agents playing the role > must perform, and the < <right> stereotype denes actions that agents playing > the role have permission to perform. The actions described in those stereotypes do not have implementations. They describe the signature of the action. The agents that play the role implement the actions. Protocol. A new metaclasss called Protocol has been created to describe the protocols that the agent must obey when playing the role and interacting with other system elements. The metaclass Protocol specializes the metaclass BehaviorFeature because it is part of the behavior of the agent that is playing the role. The notion of agent protocols is dierent from the notion of object protocols. An agent protocol denes the set of messages that an agent is allowed to send to another agent in an interaction and the message that it can receive from another agent. Note that a protocol does not describe the content of the messages but species them type. Message. In order to completely dene protocols it is important to dene what is a message sent and received by an agent. The messages sent and received by an agent are dierent from the messages sent and received by an object dened in [34]. The UML metamodel denes a message sent and received by objects as a specic kind of communication in an interaction. A communication can be raising a signal, invoking an Operation or creating and destroying an instance. Thus, a message sent and received by an object may be related to an operation and consequently also related to a method executed by the object that receives the message. As we have already seen, a message sent and received by an agent is never connected to the actions executed by the agent that receives the message. An object may call methods of other object sending messages to it but an agent cannot call the execution of actions of other agent sending a message to it. In order to make the dierence between the messages of objects dened by the UML metamodel and the messages of agents explicit, we have dened a new metaclass called MessageAgent to represent the messages sent and received by agents. Instantiating this metaclass (messages sent and received by agents) in an implementation level, it is possible to represent messages using the agent communication language (ACL) proposed by FIPA [9]. 4.1.5. Organization. Although we have dened in TAO that an organization extends the properties and relationships dened by agents, we have not created a stereotype < <organization> associated with the metaclass AgentClass. Al> though organizations extend the notion of agents, they have additional properties
166
and relationships. Organizations are collections of agents and sub-organizations with common goals. An organization denes a set of axioms (rules and laws) that agents and sub-organizations must obey. The axioms characterize the global constraints of the organization. An organization also denes roles that must be played by the agents and sub-organizations within it. To represent organization, a new metaclass called OrganizationClass was created. This metaclass species the metaclass AgentClass proposed in Section 4.1.2. Since organizations are extensions of agents, organizations have goals, beliefs, actions and plans and play roles in the organizations where it is dened. The organization goals, beliefs and axioms constitute the organization structural features. In turn, the actions and plans of the organization are its behavioral features. Associated with an organization are the roles and sub-organizations dened by the organization and the commitments between the organization and the roles that it plays. To represent the axioms of an organization we create the stereotype < <axiom> related to the metaclass Property. > In [35, 36], an organization is dened as an institutional agent. Organizations are not modeled in the proposed diagrams and the dierence between agents and organizations are not clearly dened. In [5, 6] organizations are modeled in organization views. The relationships between agents, organizations and roles are dened between two views. However, the interactions between them are not dened in the interaction view. In [23, 26, 27], organizations are not dened. 4.1.6. Environment. An environment can be modeled as an object or as an agent depending on its characteristics. For instance, an environment can be a reactive or proactive agent. Based on this denition, we have created two dierent stereotypes: < <objectEnvironment> and < > <agentEnvironment> The < >. <objectEnvironment> stereotype refers to the metaclass Class and the < > <agentEnvironment> > stereotype refers to the metaclass AgentClass. On one hand, if the environment has characteristics of an object its StructuralFeatures will be attributes and its BehavioralFeatures will be methods. On the other hand, if the environment is an agent its StructuralFeatures will be goal and belief and its BehavioralFeatures will be actions and plans. Environments are the habitat of MAS organizations, agents and objects. Organizations, agents and objects are registered in the environment that they inhabit. Although an environment may have features equivalent to the features declared by an agent, an environment does not have the same associations described by an agent. An environment does not play roles in organizations. Organizations are dened in the environment. In [23, 35, 36], the authors mention the interaction between agents and environments. However, they did not describe the properties of environments and the relationships associated with agents and environments. Moreover, environments are not modeled in the proposed diagrams. In [26], the environment abstraction is not dened nor modeled in the proposed diagrams. In [5, 6], environment is not presented as a concrete entity that interacts with other entities.
167
Element
Features
1..*
Classifier
MessageAgent
1 sender
1..*
* receiver
Structural Feature
Behavioral Feature
Class Reactive Environment
AgentClass Proactive Environment
ObjectRoleClass AgentRoleClass
Belief Property Axiom
Goal
OrganizationClass
Operation
ActionAgent 1..* Right Duty
PlanClass
ProtocolClass *
Legend Metaclasses of the UML metamodel New Metaclasses New Stereotypes
Figure 4. The extended UML metamodel.
Figure 4 presents a set of metaclasses of the UML metamodel and all the extensions that we have proposed. This gure shows the new metaclasses and the new stereotypes that have been proposed by the MAS-ML. The icons that represent the stereotypes are associated with the metaclasses on which the stereotypes are based. 4.1.7. Renements to the TAO metamodel. Besides extending the UML metamodel, some concepts described in TAO need to be rened in order to conform to UML denitions. There are three renements: (i) Four more properties besides the properties dened in the organization template of the TAO metamodel were associated with the Organization metaclass: goal, belief, action and plan. TAO denes an organization as an extension of agents; however, it does not include those properties in the organization template. To represent the extension clearly we have decided to include the properties dened in the Agent metaclass in the Organization metaclass. (ii) The TAO element named organization describes a set of rules and laws that characterize the global constraints of the organization. Since the words rule and law can be used as synonyms we have decided to describe a feature that synthesizes the two concepts. This feature is called axiom. Axiom is an established rule, principle or law. (iii) While describing the TAO dynamics, we have noticed that the feature commitment assigned to the role template should instead be assigned to the agent template. Agents need to know what roles instances they are committed to and role instances do not need to know what agents are playing them.
168
4.2. Structure diagrams When introducing new abstraction in the UML metamodel, new diagram elements to represent the new elements and relationships need to be created. In principal as TAO denes a set of seven entities and eight dierent relationships, we should need fteen new diagram elements to represent them. Fortunately, some entities and relationships dened in TAO are also present in the UML metamodel. Proposals presented in the literature such as [1, 26, 35] extend the UML metamodel incorporating, for instance, the denition of agents as a stereotype of objects but have not dened new diagram elements to represent agents in their structural and dynamic diagrams. One benet in dening new diagram elements to represent dierent abstractions is the easier identication of these abstractions in the proposed diagrams. 4.2.1. Structure diagram elements. The TAO denitions of object/class and event entities are similar to the denitions of the UML metaclasses Class and Event. Thus, we have not created new diagram elements to represent these two entities. New diagram elements have been associated with the metaclasses AgentClass, OrganizationClass, EnvironmentClass, ObjectRoleClass and AgentRoleClass. The association, specialization, aggregation and dependency relationships described in TAO are also described in UML with the same semantics. The dierence between the relationships dened in TAO and the ones dened in UML are the entities that participate in the relationship. For example, the aggregation relationship can be used between organizations to dene an organization and its suborganizations. Although TAO applies these relationships to elements such as organization, agent and agent role, we did not dene new diagram elements to represent them. New diagram elements have been created and associated with new relationships dened in TAO that do not exist in UML. Those relationships are Inhabit, Ownership, Play and Control. ObjectRoleClass. An ObjectRoleClass is shown as a solid rectangle with an angle in its left corner. It has three compartments separated by horizontal lines. The top compartment holds the role class name that must be unique in its enclosing namespace. The middle list compartment holds the list of attributes and the bottom list compartment holds a list of methods. Either or both of the middle and bottom compartments may be suppressed when necessary.
ObjectRoleClass attribute 1 attribute 2 method 1 method 2 structuralFeatures
behavioralFeatures
AgentClass. An AgentClass is shown as a rounded rectangle with three compartments separated by horizontal lines. The top name compartment holds the agent class name that must be unique in its enclosing namespace. The middle list
169
compartment holds the list of goals and beliefs of the agent and the bottom list compartment holds a list of actions and plans. Either or both of the middle and bottom compartments may be suppressed when necessary.
AgentClass <<goal>> g1, g2 <<belief>> b1, b2 a 1, a 2, action1, action2, ... , action2} 2} plan1{action1, a 2, plan2 {action2, ...} structuralFeatures
behavioralFeatures
AgentRoleClass. An AgentRoleClass is shown as a solid rectangle with a curve on its bottom. It has three compartments separated by horizontal lines. The top name compartment holds the agent role name that must be unique in its enclosing namespace. The middle list compartment holds the list of goals and beliefs associated with the role and the bottom list compartment holds a list of duties, rights and protocols. Either or both of the middle and bottom compartments may be suppressed when necessary.
AgentRoleClass <<goal>> g1, g2 <<belief>> b1, b2 <<duty>> a1, a2 <<right>> a3 <<protocol>> m1, m2 structuralFeatures
behavioralFeatures
OrganizationClass. An OrganizationClass is shown as a lozenge shape (a symbol with horizontal sizes and convex top and bottom) with three compartments separated by horizontal lines. The top name compartment holds the organization class name that must be unique in its enclosing namespace. The middle list compartment holds the list of the organization goals, beliefs and axioms and the bottom list compartment holds a list of the organization actions and plans. Either or both of the middle and bottom compartments may be suppressed when necessary.
OrganizationClass <<goal>> g1, g2 <<belief>> b1, b2 <<axiom>> ax1, ax2 <<action>> a1, a2 plan1 {a1,a2} structuralFeatures
behavioralFeatures
EnvironmentClass. An EnvironmentClass is shown as a package that brings together all of the entities that inhabit the environment. The package icon has two
170
compartments. The lower one contains the entities that inhabit the environment and the upper one contains the environment specication. The upper compartment is subdivided into three sub-compartments separated by horizontal lines. The top name compartment holds the environment class name that must be unique in its enclosing namespace. The middle list compartment holds the list of the environment structural features, while the bottom list compartment holds a list of the environment behavioral features. If the environment is an object, its behavioral features are methods and its structural features are attributes. If the environment is an agent, its behavioral features are actions and plans and its structural features are goals and beliefs. Either or both of the middle and bottom compartments may be suppressed when necessary.
EnvironmentClass structuralFeatures behavioralFeatures entities that inhabit the environment
Ownership relationship. The ownership relationship species that an element the member is dened in the scope of another element the owner and that a member must obey a set of global constraints dened by its owner. Roles are members of the owner organization. This relationship links (i) OrganizationClass and AgentRoleClass and (ii) OrganizationClass and ObjectRoleClass. This relationship is shown as a double line linking the owner and the member.
(i) (ii)
OrganizationClass
AgentRoleClass
OrganizationClass
ObjectRoleClass
Play relationship. The play relationship relates an object, an agent or a sub-organization to a role dened in an organization. The play relationship identies an element, a role and an organization where the element plays the role. This relationship is based on the ownership relationship that identies an organization and the role that can be played in the organization by the element. The play relationship identies the element that will play the role dened in the ownership relationship. It is important to relate the element to the role and to the organization that denes the role. Since dierent organizations can dene the same role type, the relationship play would not be completely dened if we use a simple link between an agent and a role. The play relationship links (i) an AgentClass to the relationship between an OrganizationClass and an AgentRoleClass, (ii) links an OrganizationClass to the relationship between an OrganizationClass and an AgentRoleClass, and (iii) links a
171
Class to the relationship between an OrganizationClass and a ObjectRoleClass. The relationship is shown as a simple line linking (i) an AgentClass, (ii) an OrganizationClass, or (iii) a Class to the double line that describes the ownership relationship that identies an organization and a role. The organizations that play roles in other organizations are sub-organizations of the organization that denes the role. The aggregation relationship between the organization and its sub-organizations is implicitly represented by the play relationship described between a sub-organization and a role dened in the organization, as shown in (ii). Therefore, the aggregation relationship between an organization and a sub-organization may be suppressed in diagrams where the play relationship between a sub-organization and a role is represented.
OrganizationClass
AgentRoleClass
OrganizationClass
AgentRoleClass
(i)
AgentClass
(ii)
OrganizationClass
OrganizationClass
ObjectRoleClass
(iii)
Class
Control relationship. The control relationship states that the controlled element that plays the role must respond to any request from the controller element. This relationship species that an AgentRoleClass can control another AgentRoleClass. The control relationship is shown as a simple line with a circle adornment at one end. The circle indicates the controller element.
AgentRoleClass AgentRoleClass
Inhabit relationship. The inhabit relationship species that the element that inhabits the citizen may leave and enter habitats, respecting a given habitats permissions. This relationship is applied to EnvironmentClass and its citizens AgentClass, Class and OrganizationClass. The relationship is shown by inserting the citizen in the lower compartment dened by the diagram element associated with the EnvironmentClass.
172
EnvironmentClass
4.2.2. Class diagram. A UML class diagram is a graph of elements connected by their various static relationships. Note that a class diagram may also contain interfaces, packages, relationships and other model elements. A class diagram is a graphic view of the static structural model. Because of the set of dierent elements and relationships dened in the TAO metamodel that have been incorporated in the UML metamodel, we have proposed dierent structure diagrams to focus on the dierent extension aspects to be covered by the resulting MAS-ML. The three structure diagrams Class, Organization and Role diagrams show all elements and all relationships dened in TAO. Other proposals such as [1, 2, 23, 35] also have extended the UML Class diagram and proposed new diagrams. However, some of them have not dened the relationships between agents and objects and others have not dened the organization and environment abstractions. As a consequence, the relationships between agents, organizations and environments were not dened. Moreover, the relationships between the roles played by agents and dened by organization also are not dened in many of them. Such proposals are incomplete because it is not possible to model all the elements of the MAS application and their relationships. One of our goals with the extension of class diagrams is to modify the class diagram to represent agents and relationships between agents and classes as dened in TAO. The extended class diagram represents the relationships between the objects found in the environment and between the objects and the agents or organizations that use these objects (resources). As the environments are related to all objects, all organizations and all agents since those elements inhabit the environments, it is not necessary to model the relationship between the environment and the other elements in the class diagrams but only in organization diagrams. However, in the event the environment instances know each other, the class diagram should model the auto relationship in the environment class. Agents and objects can be directly related or indirectly related between their roles. The same thing can happen between organizations and objects. Thus, the diagram classes model the association relationships between agents and objects and between organizations and objects. The relationships between their roles are modeled in role diagrams. The extended class diagram should be able to represent the relationships between agents, between agents and organizations and between organizations. Although there is no relationship between agents and organizations, since agents and organizations interact based on their roles, there are two dierent relationships that link two agents and two organizations. Two agents or two organizations may be related through the relationships aggregation or specialization.
173
The classes that may participate in this diagram are AgentClass, OrganizationClass, Environment, Class and other classes dened by UML. The relationships used in this diagram are those dened by UML plus the relationships listed below: (i) association used between agent and objects, between organizations and objects and between environments, (ii) aggregation used between agents and between organizations, (iii) specialization used between agents and between organizations. The set of class diagrams used when modeling a MAS dene all the objects, some agents and some organizations. The agents and organizations that are modeled in class diagrams are related to other agents and organizations, respectively, or to other objects. 4.2.3. Organization diagram. The objective of the organization diagrams is to model the organizations of the system, identifying their habitats, the roles that they dene and the elements objects, agents and sub-organizations that play those roles. Thus, as the focus of organization diagrams is to model organizations, these diagrams are used to model all system organizations. Moreover, all system environments are modeled by these diagrams because every organization inhabits environments and every environment is inhabited by at least one organization. As roles are dened by organizations and all organizations are modeled, all agent and object roles are also modeled. Since every system agent and sub-organization play at least one role and the organization diagrams model the elements that play the roles dened by the organizations, all agents and all sub-organization are dened in these diagrams. However, in the case of objects, only the objects that play roles are dened. The classes that may be used in organization diagrams are OrganizationClass, AgentClass, AgentRoleClass, Class, ObjectRoleClass and Environment. The relationships that may be used are: (i) ownership used between organizations and the roles that the organizations dene, (ii) play used between agents and agent roles, sub-organizations and agent roles, and objects and object roles, (iii) inhabit used between the environments and other elements.
4.2.4. Role diagram. The role diagram is responsible for clarifying the relationships between the agent roles and object roles. This diagram shows the relationships between AgentRoleClass and ObjectRoleClass and between these roles and Classes. The set of relationships used in this diagram is (i) control used between agent roles, (ii) dependency used between object roles, agent roles and object roles and between agent roles,
174
(iii) association used between object roles, agent roles and object roles, between agent roles and between roles and objects, (iv) aggregation used between object roles and between agent roles, (v) specialization used between object roles and between agent roles.
4.3. Sequence diagram A UML sequence diagram presents a set of interactions between objects playing roles in collaborations. In [1, 26, 27], Odell and others presented an incomplete agent-based extension of UML for the specication of agent interaction protocols and other commonly used agent-based notions. They have extended four diagrams that describe the interactions among model elements. Nevertheless, they did not describe some important aspects related to the dynamic process of MASs. They did not consider organizations and environments as activity elements that interact with other MAS elements. Since they can interact they must be represented in diagrams that describe the MASs interactions. Moreover, Odell and others did not represent elementary dynamic processes. It is not clear in their reported work how to represent the creation of agents and organizations or how to represent an agent committing to a role. We propose to extend the sequence diagram to represent the behavior of agents, organizations and environments. The extensions proposed to the UML sequence diagram were based on the TAO structural model and on the denition of the domain-independent dynamic processes presented in Section 3. While extending the UML sequence diagram, three sequence diagram elements were created and the exiting diagram element called object was modied. Moreover, we have created new stereotypes to identify new interaction types and have extended the denition of the stereotype < <create> and < > <destroy> dened in the > UML metamodel. The extensions proposed to the UML sequence diagram make it possible, for instance, to represent the ve dynamic processes (Section 3). 4.3.1. Sequence diagram elements. In UML, a sequence diagram element is represented by its pathname and by an icon. We propose the creation of dierent icons to represent dierent elements and dene dierent pathnames associated with those elements. UML denes the following name structure called pathname: simple pathname object : class complete pathname object/connectableElement : class :: package The simple pathname describes the object name and the class name separated by a colon. The complete pathname describes, on the left of the colon, the object and the name of the role that it is playing. On the right of the colon the complete pathname describes the class name and the package name of the class. The complete pathname completely species an instance participating in an interaction.
175
Object pathname. The object pathname was redened to extend the UML sequence diagram. TAO states that an object interacts with other objects or agents by playing a role in an organization that inhabits an environment. Therefore, to completely specify an object participating in an interaction we must mention the role instance that it is playing, the organization instance where the role instance is, and the environment instance where the organization inhabits. The complete pathname associated with objects in sequence diagrams is
object/role/org/env : Class=ObjectRoleClass=OrganizationClass=EnvironmentClass
On the left of the colon the complete pathname describes the instances names and, on the right of the colon, the class names. It is important to represent the role instance that the object is playing and the associated role class. An object may play more than one role that may be instances of dierent role classes and more than one role that may be instances of the same role class. Organizations may be sub-organizations of other organizations. In the case of a suborganization, in order to completely specify an object it is necessary to represent all organization instances involved. In this case, the pathname of the object should be modied to represent the hierarchy of organizations and the corresponding classes of each organization: object/role/org1/ . . . /orgN/env : Class=ObjectRoleClass=OrgClass1= . . . /OrgClassN/EnvClass The complete pathname can be replaced by a simple pathname where appropriate. The information about the role instance played by the object, about the location of the organization and about the environment that it inhabits can be suppressed. The designer may suppress this information when the context of the interaction is well known or irrelevant. For example, the pathname may not contain the information about the environment if there is only one environment instance in the application (see (a)) or may not contain the information about the organization if there is only one organization instance in a given environment (see (b)). (a) object/role/org : Class/ObjectRoleClass/Organization (b) object/role/env : Class/ObjectRoleClass/Environment
Agent pathname. The complete pathname that represents an agent in a sequence diagram is similar to the one that represents an object: agent/role/org1/ . . . /orgN/env : AgentClass=AgentRoleClass=OrgClass1= . . . /OrgClassN/EnvClass
176
The pathname describes the agent instance, the role instance that the agent is playing, the organization hierarchy where the agent is playing the role, the environment that it inhabits and their corresponding class names. The information about the role, organizations and environment can be suppressed and a simple pathname can be used. For example, if the information about the organization and the environment are well known, the pathname of the agent may be as simple as agent/role : AgentClass/AgentRoleClass
Organization pathname. Sub-organizations may play roles in organizations and may interact with other elements. A sub-organization is represented by the following pathname:
suborg/role/org1/ . . . /orgN/env : OrgClass=AgentRoleClass=OrgClass1= . . . /OrgClassN/EnvClass
The pathname describes the sub-organization instance, the role that the suborganization is playing, the complete organization hierarchy where the sub-organization is dened, the environment that it inhabits and their corresponding class names. A simple pathname may be used when appropriate. The information about the role, about the organization hierarchy where the sub-organization is dened and about the environment can be suppressed. For example, if the sub-organization plays only one role, and the organization hierarchy and the environment are well known, the pathname of the sub-organization may be as simple as suborg : OrgClass
Environment pathname. The pathname that completely species the environment is the simplest one. It describes the environment instance name and its class name: env : EnvironmentClass Table 1 identies the instances that may appear in sequence diagrams and their associated diagram elements. Objects are shown as rectangles, agents are shown as rounded rectangles and organizations are shown as double rounded rectangles. The environment is shown as a rounded rectangle if it is an agent and as a rectangle if it is an object. 4.3.2. Representing agents messages in sequence diagrams. Agents and objects interact sending and receiving messages. However, as we have already seen, the messages sent and received by objects are dierent from the messages sent
177
Table 1. The sequence diagram elements. Instances Object Agent Organization Environment Diagram element
obj/role/org/env : Class/ObjectRole/Organization/Environment agent/role/org/env : Agent/AgentRole/Organization/Environment org/role/org/env : Organization/AgentRole/Organization/Environment
Proactive element env :Environment
Reactive element env :Environment
and received by agents. The messages of objects can raise a signal, invoke an operation, create and destroy an instance. The messages associated with agents can also raise a signal, create and destroy an instance but cannot invoke the execution of an action. Moreover, the agents can send and receive messages as structural information (Section 4.1.4). Therefore, we propose to extend the representation of the messages used in the UML sequence diagrams in order to represent not only the messages of objects but also the messages of agents. We propose to represent the messages of agents using a horizontal solid arrow from the element that sends the message sender to the element that receives the message receiver tagging the arrow with the label of the message and with an index to identify the message. Modeling the example in Figure 12 we have used part of content of the messages to identify them. Since the elements dened in TAO have dierent characteristics, some elements cannot send messages to or receive messages from other elements. Objects cannot send messages to elements like agents and organizations and so cannot send messages to environments modeled as agents. The inability of objects to send messages to agents, organizations and environments modeled as agents is related to the fact that an object cannot create or destroy those instances and cannot create communication acts. Objects can receive messages from any other element since any other element is capable of invoking an operation of an object and can create and destroy an object. Agents and organizations can receive messages from other agents, organizations and environments modeled as agents and can send messages to any other elements. On one hand, an environment modeled as an agent can send messages to and receive messages from the same elements that are associated with agents. On the other hand, an environment modeled as an object can send messages to and receive messages from the same elements that are associated with objects. 4.3.3. The stereotypes associated with messages. The stereotypes < <create> > and < <destroy> dened in UML are associated with messages that are used to > represent the creation and destruction of objects. We propose to use the same stereotypes to represent the creation and destruction of agents, organizations and environments. However, the semantics of those stereotypes have to be specialized
178
Creation of an organization Anne/FruitBuyer : UserAgent/Buyer <<create>> AppleSale/SpecialGroup1: WholesaleGroup/SpecialGroup . . . Destruction of an organization - I Anne/FruitBuyer : UserAgent/Buyer . . . <<destroy>> . . . Destruction of an organization - II Anne/FruitBuyer : UserAgent/Buyer . . . <<destroy>> . . . AppleSale: WholesaleGroup . . . AppleSale/SpecialGroup1: WholesaleGroup/SpecialGroup . . .
. . .
Figure 5. Creation and destruction of an organization.
when using them in association with agents and organizations. As agents and organizations play at least one role, a role must be associated with agents and organizations when they are created. The stereotype < <create> was spe> cialized to represent the creation of agents, organizations and the environment and also to represent the association of a role instance to agent and organization instances. A role instance is created at the moment of the creation of an agent and its organization and is directly associated with the element. When an agent or an organization is destroyed all the role instances they are playing must also be destroyed at the same time. The stereotype < <destroy> was > specialized to represent the destruction of agents and organizations, and the destruction of all role instances associated with them. Figure 5 illustrates the creation and destruction of an organization by an agent. The rst block illustrates the creation of an organization. When the organization Apple Sale is created, a role instance called Special Group number 1 is also created. The second and the third blocks illustrate the destruction of an organization. The second block represents the organization Apple Sale being destroyed when playing the role Special Group number 1. To better illustrate the destruction of all role instances, the designer may represent the organization being destroyed without any role instance associated, as represented in block number three. Three new stereotypes associated with agents and roles were created to represent an agent committing to a role, an agent changing roles and an agent canceling a role. The stereotype < <role commitment> was created to represent an agent com> mitting to a role. When an agent commits to a new role it does not stop playing other roles. A new role instance is created and is associated with the agent. The new role
179
Bob/FruitBuyer : UserAgent/Buyer <<role_commitment>> Bob/ClothesBuyer: UserAgent/Buyer Level I . . . . . . <<role_change>> Bob/ClothesSeller : UserAgent/Seller . . . <<role_cancel>> Level III Level II
Figure 6. The three new stereotypes.
may be an instance of any role class dened by any organization class. However, the new role instance must be created in an organization that inhabits the same environment as the agent. Agents cannot play dierent roles in dierent environments. The stereotype < <role cancel> represents an agent canceling a role. An agent > cancels the commitment with the role and stops playing the role. The agent continues to play its other roles. The act of canceling a role can only be executed if the agent is playing more than one role. An agent cannot cancel its unique role. An agent must play at least one role in an organization. The stereotype < <role change> represents an agent changing its roles. The > agent stops playing a role and starts playing another role. The < <role change> > stereotype is a mix of < <role commitment> and < > <role cancel> stereotypes. > Figure 6 illustrates the use of the three new stereotypes. Suppose that the agent Bob commits to the role Clothes Buyer when playing the role Fruit Buyer. At level I, Bob is playing the role Fruit Buyer and the role Clothes Buyer at the same time. After a while, Bob changes his role from Clothes Buyer to Clothes Seller. Bob stops playing role Clothes Buyer and starts playing the role Clothes Seller. At level II, Bob is playing the roles Fruit Buyer and Clothes Seller. After that, Bob cancels the role Fruit Buyer when playing the role Clothes Seller. At level III, Bob is playing only the role Clothes Seller. The ve stereotypes presented in this section make it possible to create sequence diagrams to represent the three elementary dynamic processes and the two higherlevel dynamic behaviors presented in Section 3.
5. An example using MAS-ML 5.1. Structure diagrams of the example In order to illustrate the use of the structure diagrams proposed in Section 4, we have modeled some parts of the market place system presented in Section 2. Figure 7 illustrates an organization diagram (part I) presenting the Market Place mainorganization. This organization denes three dierent roles classes Auction Market, Market of Used Goods and Supermarket that may be played by three dierent
180
Virtual Market WebService MarketPlace Auction Market <<goal>> to earn $X monthly <<belief>> totalSold <<axiom>>every subOrg may pay 2% of the totalSold <<action>> plan ... Supermarket <<goal>> to earn at least $ Y monthly <<belief>> ... <<duty>> registerTheSale, acceptAnyBuyer, ... <<right>> allowTheCreationOfSubOrg <<protocol>> ...
English Auction Market
Retail Market Books Market
Retail or Wholesale Market Market of Used Goods <<goal>> to sell at least N items monthly <<belief>> sellersRegister, buyersRegister, totalSold, ... <<duty>>acceptOnlySellersIfRegister, acceptOnlyBuyersIfRegister, registerNumberOfItensSold , ... <<right>> ... <<protocol>> ... <<goal>> to exchange goods for money <<belief>> totalSold, ... <<axiom>>paymentDoneByCreditCard, <<action>> registerTheSale, acceptAnyBuyer, allowTheCreationOfSubOrg, registerSubOrg, ... planSubOrg {allowTheCreationOfSubOrg, registerSubOrg} planSale {registerTheSale} planAccept {acceptAnyBuyer}, ...
Figure 7. Organization diagram (Part I).
sub-organization classes English Auction Market, Books Market and Retail Market, respectively. The organization Retail and Wholesale Market is a specialization of Retail Market. All the elements dened in the Market Place inhabit the same environment called Virtual Market Web Service. In order to simplify the presentation, we will not represent the environment in the organization diagrams part II and III illustrated in Figures 8 and 9. In Figure 8, we focus on the modeling of the Retail and Wholesale Market organization illustrating another organization diagram (part II). The Retail and Wholesale Market organization denes four agent roles Creator, Buyer, Seller and Special Group and two object roles Oer and Desire. Two agents and one suborganization were dened and related to those four agent roles and one object was dened and related to the object roles: (i) The sub-organization called Wholesale Group is related to the Special Group agent role, (ii) User Agent is related to the Buyer and Seller agent roles, (iii) System Agent is related to the Creator agent role, (iv) The Item object is related to the Oer and Desire object roles.
181
Retail or Wholesale Market Offer <<goal>> to exchange goods for money <<belief>> totalSold, ... <<axiom>>paymentDoneByCreditCard, Item <<action>> registerTheSale, acceptAnyBuyer, allowTheCreationOfSubOrg, registerSubOrg, ... planSubOrg {allowTheCreationOfSubOrg, registerSubOrg} planSale {registerTheSale} planAccept {acceptAnyBuyer}, ... Wholesale Group <<goal>>to group buyers to by wholesale items <<belief>> item to buy <<axiom>> only accept buyer with the same interesting <<action>>acceptBuyer, ... planAccept {acceptBuyer,}
Special Group <<goal>>group buyers <<belief>> ... ...
Desire
SystemAgent
UserAgent
Creator <<goal>> to create special groups according to the limit of creations <<belief>> limit of number of special groups, ... <<duty>> createSpecialGroup, ... <<right>>... <<protocol>> ...
Buyer <<goal>> to buy items <<belief>> ... <<duty>>askForItem, payItem, ... <<right>>askForCreationOfSubOrg, ... <<protocol>> FIPAprotocol{...}
Seller <<goal>>to sell items <<belief>> ... <<duty>> ... <<right>> ... <<protocol>> FIPAprotocol{...}
Figure 8. Organization diagram (Part II).
Wholesale Group <<goal>>to group buyers to by wholesale items <<belief>> item to buy <<axiom>> only accept buyer with the same interesting <<action>>acceptBuyer, ... planAccept {acceptBuyer,} Member
UserAgent
Mediator
Figure 9. Organization diagram (Part III).
An instance of the sub-organization Wholesale Group may be created when the buyer needs to buy an item but does not want all the units in the package. This suborganization denes two roles member and mediator that also may be played by User Agent instances (see Figure 9). The organization diagrams part I, II, and III
182
Seller Offer <<goal>>sell items <<belief>> ... <<duty>> ... <<right>> ... <<protocol>> FIPAprotocol{...}
Buyer <<goal>> buy items <<belief>> ... <<duty>>askForItem, payItem, ... <<right>>askForCreationOfSubOrg,,... <<protocol>> FIPAprotocol{...}
Creator <<goal>> create special groups according to the limit of creations <<belief>> limit of number of special groups, ... <<duty>> createSpecialGroup, ... <<right>>... <<protocol>> ...
Desire
Member
Mediator
Figure 10. Role diagram.
illustrate the use of four relationships ownership, play, inhabit and specialization and the use of six elements organization, agent, environment, agent role, object and object role. We have divided the organization diagram in three parts to illustrate the modeling example better. The organizations, agents and objects that are illustrated in the organization diagrams were colored to facilitate their identication. Figure 10 shows a role diagram illustrating the relationships between Seller, Buyer, Creator, Member and Mediator agent roles, and Oer and Desire object roles. Four dierent kinds of relationships were used in this diagram: association, aggregation, dependency and control. The association relationship was used between Seller and Buyer, between Buyer and Desire and between Seller and Oer. These roles are associated because the agents and objects playing the roles must interact with each other. For example, agents playing the role Buyer and the Seller may interact based on a FIPA [9] protocol. The control relationship was used between the Buyer and the Creator because the agent that plays the role Creator should do all that Buyer asks it to do unless some implicit restriction is in place. The aggregation relationship was used between the Buyer and two other roles: Member and Mediator. An agent playing the role Buyer may need to be a Member or a Mediator when playing roles in a Wholesale Group organization where these two roles are dened. The Member depends on the Mediator to form the group and to buy the item. Thus, the dependence relationship was used to link the Member and the Mediator. In Figure 11, the class diagram shows the relationships between the objects of the system and the agents, and between the organizations. A User Agent can make a proposal and counter proposal when buying or selling an Item. However, this agent cannot make bids and does not know the rules of auctions. The User Agent
183
Counter Proposal
Market Place
UserAgent Item Proposal English Auction Market Books Market Retail Market
Bid
UserAgentAuctioneer Wholesale Group Retail or Wholesale Market
Figure 11. Class diagram.
Auctioneer is an agent that is an expert in playing the roles in the organization English Auction. The User Agent Auctioneer specializes the User Agent. It knows what is the denition of a bid and that it is associated with an Item. The relationship aggregations used between the organizations identify the sub-organization being part of another organization.
5.2. Sequence diagram of the example The sequence diagram illustrated in this section presents the dynamic process that describes an agent entering an organization (Section 3). The dynamic process was associated with the context of the example described in Section 2. Figure 12 shows a User Agent called Bob searching for an organization to play a role. Bob is interested in entering an organization to buy a wholesale item. This scenario describes interactions that occur in the Retail and Wholesale Market organization. Bobs goal is to buy 5 kg of apples paying less than $10.00 per kg. Bob is nding it dicult to achieve his goal since it cannot nd apples costing $10.00 per kg. Bob decides to look for an organization in the environment. Bob knows that if he nds an organization whose goal is to buy apples wholesale he will probably achieve his goals by playing a role in the organization, since to buy wholesale items is cheaper than to buy retail items. The environment sends the identication of organizations to Bob. Bob matches his goals with the goals of the organization and realizes that it is possible to achieve his goals in the organization. Bob asks the organization for the roles that it denes. The organization informs Bob that it denes the Mediator and Member roles. Bob tries to play the Mediator role but the organization does not let him. Bob commits to the Member role. After paying for the apples Bob cancels the role Member. Figure 12 shows three dierent elements types. It shows two agents playing roles, where one of the two is playing two dierent roles, an environment instance and an organization instance. The environment modeled in this example is an object. The elements are identied by using a simple pathname and a dierent icon. The complete pathname was not used because the information about the organization
184
Bob/FruitBuyer : UserAgent/Buyer
v : Virtual Market WebService
AppleSale: WholesaleGroup
Anne/MediatorApple : UserAgent/Mediator
request (organizations) inform (AppleSale to group buyers and buy apples) . . request (roles) . inform (Mediator and Member) question (canCommitWithMediator) answer (no) question (canCommitWithMember) answer (yes) <<role_commitment>> . . . Bob/Member3 : UserAgent/Member inform (numberOfItensWanted -5kg) . . . . . . . . . . . .
inform (numberOfItensBought-4kg) inform (payment = $7,00)
<<role_cancel>> . . . . . .
Figure 12. Incomplete sequence diagram representing some interaction.
where the agents are playing roles and about the environment instance is well known. The agents are playing roles in the same organization called Retail and Wholesale Market and there is only one environment instance in the system. Besides that, the role of the organization Wholesale Group is not illustrated in the diagram since it plays only one role.
6. Related work 6.1. AUML FIPA [9] and the OMG Agent Work Group [25] have been proposing AUML [1, 2, 11, 26], a UML extension based on characteristics identied in MASs. In [1, 2], agent and object are presented as completely dierent paradigms. Nevertheless, stereotypes are used to create agent classes based on the metaclass Class that describes object classes. The same metaclass is used to represent two dierent paradigms, i.e., paradigms that dene dierent properties and may be linked by dierent relationships. Stereotypes may be used to indicate a dierence in meaning or usage between two model elements with identical structures and so, based on the denition presented in the UML specication [34], stereotypes may not be used to represent two completely dierent paradigms. The use of a unique metaclass to represent dierent abstractions makes it impossible to describe specic agent properties. Moreover, the authors do
185
not propose any dierent diagram element to visually distinguish an agent from an object. The two paradigms are represented by the same diagram element, a rectangle with three compartments. In our proposal we dene the new metaclass AgentClass to characterize an agent and a new diagram element to easily identify an agent in any proposed diagrams, a rounded rectangle with three compartments. Although the proposals believe that agents and objects are coexisting paradigms, they do not describe the possible relationships between these paradigms. Moreover, the proposals do not describe other entities such as environment and organization that are frequently used in MAS models. They do not describe how to represent the interactions between agents, organizations and environment in their proposed sequence diagrams nor how to represent agents entering an organization, migrating to another environment and playing more than one role in an organization. In our proposal, it is possible to represent the static relationships between classes, agent classes, environment classes, organization classes and role classes using the Class, Organization and Role diagrams. Moreover, it also is possible to represent interactions between objects, agents, environment and organization playing roles, using the Sequence diagram. Huget [11] presents an extension of the work done in [1] and agents are also presented as stereotypes of Class. 6.1.1. Tropos and message. Other initiatives as in [5, 6, 23] also propose UML extensions according to MASs concepts. Although Tropos [23] also has proposed UML extensions, the authors have only extended the Use Case diagram based on its requirements methodology. As we have not yet extended the UML Use Case diagram, it is not possible to compare our proposal to this proposal. Message [5, 6] creates specic diagrams to represent agents and other MAS elements, adding those diagrams to the set of UML diagrams. They do not propose any modication in any UML diagram. Moreover, none of the proposed diagrams present the interaction among the MASs elements or present agents committing to roles or changing theirs roles. As we have already presented, in MAS-ML it is possible to model the interaction between the elements of a MAS in Sequence diagrams, including an agent committing to and changing roles.
6.2. AORUML In [35, 36], Wagner proposes the AORUML (Agent-Object-Relationship UML). AORUML uses stereotypes related to the metaclass Class to extend all its entities and uses stereotypes related to the metaclass Association to extend all its relationship types. Moreover, as in other proposals, AORUML does not describe the relationships among agents, objects and other MAS entities and consequently does not represent them in its proposal diagrams. In our proposal, we dene dierent kinds of relationships and do not extend the association relationship. From our point of view the new relationships should not be dened as stereotypes of the association relationship because they have enough important semantic to be described as new relationships. Furthermore, the relationships between all the elements of an MAS are modeled through the three MAS-ML static diagrams.
186
In summary, the main important dierences between our approach and others presented in the literature are (i) the proposal of a clear denition and representation of the elements that compose MASs, (ii) the clear denition and representation of the relationships between the elements in static diagrams, and (iii) the representation of the interactions between all these elements in a dynamic diagram. None of the analyzed proposals have dened the static relationship between agents, organizations and environments and none have described the interactions between these abstractions. Our proposal is based on a conceptual framework (TAO) that describes the structural and dynamic properties of MASs that contributes to an easier denition of the elements that compose the modeling language and their interactions. The elements that have dierent semantics, i.e., the elements that do not share the same characteristics, are presented in dierent ways in the proposed diagrams. Objects, agents, organizations, roles and environments that have dierent properties and relationships are described as dierent metaclasses and are presented as dierent icons in the proposed diagrams. Moreover, our proposal describes some elementary and other higher-level behaviors of the elements of MASs, helping the denition of diagram elements presented in the interaction diagram.
7. Conclusions and future work In this paper we propose a conservative extension of the UML metamodel that includes the agent-related notions that are part of the TAO conceptual framework (metamodel), while preserving all object-related concepts that constitute the UML metamodel. The proposed modeling language is called MAS-ML. As TAO concentrates on the structural aspects of MASs, we have described some elementary and higher-level domain-independent dynamic processes involved in MASs. Although the dynamic behavior of the elements of TAO is not completely described, the structural and behavior aspects presented in TAO allow us to extend UML to deal with objects and agent-related abstraction in its structure and dynamic diagrams. Although we have described some dynamics processes associated with the TAO metamodel, there still are some elementary and higher-level domain-independent dynamic processes that have not been described here. The dynamic processes are often related to statements that are issues while dening the elements of MASs. As well, some questions issued when specifying a MAS may motivate dynamics processes. Although the answers to some of these questions may be domain-dependent, we believe that we can identify patterns of higher-level behavior to help answer those questions. In this paper we have described the creation of agents, organizations and agent roles. We still have to describe the creation of environments, objects and object roles. Since all the elements of a MAS inhabit an environment, the creation of an environment instance is an elementary dynamic process that is associated with other dynamic processes. Objects play roles in organizations and may be created by agents, organizations or others objects. The creation of an object and the association
187
of an object role with an object are also elementary dynamic processes yet to be specied. Although the destruction of the MAS elements has not been described in this paper, it is also an important issue. Agents and organizations have goals and may be destroyed when they achieve their goals. The destruction of an agent and an organization, as other MAS elements, are also elementary dynamic behaviors. For example, when describing the destruction of an organization we may question what happens to the agents playing roles in the organization. Higher-level dynamic processes such as migration of an agent from one environment to another must also be described. Higher-level dynamic behaviors may be based on elementary dynamic behaviors such as the creation of an agent instance and the creation of a role instance. The extension of the UML metamodel incorporates new modeling capabilities into UML since new metaclasses, stereotypes and diagram elements are created to dene and represent the elements presented in TAO. As we have not completely extended the UML metamodel, i.e., as we have not presented the extensions of all the UML diagrams, this paper describes a partial version of MAS-ML. The extension of UML according to TAO impacts other diagrams besides the class diagram and the sequence diagram. We are in the process of analyzing all the UML diagrams and modifying them based on extension of the UML. Finally, our main contribution is the proposal of a multi-agent system modeling language based on the denition of the structural and dynamic properties presented in TAO. MAS-ML addresses the particular characteristics of MAS that are not addressed in the UML and are not addressed in a satisfactory manner in the proposals available in the literature. The advantages in the use of MAS-ML are: (i) it is possible to represent all abstractions associated with a MAS application, (ii) it is also possible to describe the static relationships and (iii) dynamic interactions between these abstractions. It is not possible to model all the abstractions nor their relationships and interactions using any proposal presented in the literature. Some proposals describe a sub-set of those abstractions and others do not model the interaction between the elements that they dene. Acknowledgments This work has been partially supported by CNPq under grant 140646/2000-0 for Viviane Silva. Viviane Silva and Carlos Lucena also are supported by the PRONEX Project under grant 664213/1997-9, by the ESSMA project under grant 552068/20020 and by the 1st art. of decree number 3.800, of 04.20.2001. The authors would also like to acknowledge the contributions of P. Alencar, D. Cowan and T. Oliveira. References
1. B. Bauer, UML class diagrams revisited in the context of agent-based systems, in M. Wooldridge, G. Weiss, and P. Ciancarini, (eds.), Agent-Oriented Software Engineering, Second International Workshop, AOSE 2001, Montreal, Canada, 2001, pp. 101118.
188
2. B. Bauer, J. Muller, and J. Odell, Agent UML: A formalism for specifying multiagent interaction, in M. Wooldridge, G. Weiss, and P. Ciancarini, (eds.), Agent-Oriented Software Engineering, Second International Workshop, AOSE 2001, Montreal, Canada, 2001, pp. 91103. 3. G. Booch, Object-oriented Analysis and Design with Applications, (2nd edn.) The Benjamin/Cummings Publishing Company, Inc.: USA, 1994. 4. G. Booch, J. Rumbaugh, and I. Jaconbson, The Unied Modeling Language User Guide, (1st edn.) Addison-Wesley Longman Publishing Co., Inc, 1999. 5. G. Caire, MESSAGE: Methodology for engineering systems of software agents initial methodology, Technical report, EDIN 0224-0907, Project P907, EURESCOM, 2001. 6. G. Caire, F. Chainho, and R. Evans, Agent-oriented analysis using Message/UML, in M. Wooldridge, G. Weiss, and P. Ciancarini, (eds.), Agent-Oriented Software Engineering, Second International Workshop, AOSE 2001, Montreal, Canada, 2001, pp. 119135. 7. P. Chen, The entity relationship model towards a unied view of data, ACM Trans. Database Syst., vol. 1, no. 1, pp. 936, 1976. 8. J. Ferber and O. Gutknecht, A meta-model for the analysis and design of organizations in multiagents systems, in Y. Demazeau, (ed.), Proceedings of the International Conference on Multi-Agent Systems, IEEE Press, 1998, pp. 128135. 9. FIPA, Foundation for Intelligent Physical Agents, http://www.pa.org, 2003. 10. N. Glaser and P. Morignot, The reorganization of societies of autonomous agents, in M. Boman, and W. Velde, (eds.), Proceedings of 8th European Workshop on Modeling Autonomous Agents in a Multi-Agent World, Sweden, 1997, pp. 98111. 11. M. Huget, Agent UML class diagrams revisited, in B. Bauer, K. Fischer, J. Muller, and B. Rumpe, (eds.), Proceedings of Agent Technology and Software Engineering (AgeS), Erfurt, Germany, 2002. 12. M. Huhns and M. Singh, Agents and multi-agent systems: themes, approaches and challenges, in M. Huhns and M. Singh, (eds.), Readings in Agents, Morgan Kaufmann, 1998, pp. 123. 13. T. Ishida, L. Gasser, and M. Yokoo, Organization self design of production systems, IEEE Trans. Knowl. Data Eng., vol. 4, no. 2, pp. 123134, 1992. 14. N. Jennings, Agent-oriented software engineering, in Proceedings of the Twelfth International Conference on Industrial and Engineering Applications of Articial Intelligence, Cairo, Egypt, 1999, pp. 410. 15. N. Jennings, On agent-based software engineering, Artif. Intell., vol. 117, no. 2, pp. 277296, 2000. 16. D. Kinny and M. George, Modeling and design of multi-agent systems, in J. Muller, M. Wooldridge, and N. Jennings, (eds.), Intelligent Agents III, Springer-Verlag, vol. 1193, 1997, pp. 1 20. 17. B. Kristensen, Object-oriented modeling with roles, in Proceedings of the 2nd International Conference on object-oriented information systems, Dublin, Ireland, 1995. 18. B. Kristensen, Subject Composition by Roles, in Proceedings Object-Oriented Information Systems, Brisbane, Australia, 1997. 19. B. Kristensen and K. Osterbye, Roles: Conceptual abstraction theory and practical language issues, in Theo. Prac. Object Syst., vol. 2, no. 3, pp. 143160, 1996. 20. V. Kuncak, P. Lam, and M. Rinard, Role analysis, in Proceedings 29th Annual ACM Symposium on the Principles of Programming Languages (POPL), Portland, OR, 2002. 21. J. Lind, MASSIVE: Software engineering for multi-agent systems, PhD Dissertation, Universitat des Saarlandes, Saarbrucken, Germany, 2000. 22. MOF, Meta object facility specication, Version 1.4, http://www.omg.org/cwm/a, 2002. 23. J. Mylopoulos, M. Kolp, and J. Castro, UML for Agent-Oriented Software Development: the Tropos Proposal, in Proceedings of the Fourth International Conference on the Unied Modeling Language, Toronto, Canada, 2001. 24. OMG, Object Management Group Agent Platform Special Interest Group: Agent Technology Green Paper. Version 1.0, 2000. 25. OMG, Object Management Group, http://www.omg.org, 2003. 26. J. Odell, H. Parunak, and B. Bauer, Extending UML for Agents, in G. Wagner, Y. Lesperance, and E. Yu, (eds.), Proceedings of the Agent-Oriented Information Systems Workshop (AOIS), Austin, 2000, pp. 317.
189
27. J. Odell, H. Parunak, and B. Bauer, Representing agent interaction protocols in UML, in P. Ciancarini and M. Wooldridge, (eds.), Agent-Oriented Software Engineering, LNCS, Springer-Verlag: Berlin, 2001, pp. 121140. 28. J. Odell, H. Parunak, and M. Fleisher, The Role of Roles in Designing Eective Agent Organizations, in A. Garcia, C. Lucena, F. Zamobnelei, A. Omicini, and J. Carstro, (eds.), Software Engineering for Large-Scale Multi-Agent Systems, LNCS, Springer-Verlag, 2003. 29. Y. Shoham, Agent-oriented programming, Artif. Intell., vol. 60, 1993. 30. V. Silva, A. Garcia, A. Brandao, C. Chavez, C. Lucena, and P. Alencar, Taming Agents and Objects in Software Engineering, in A. Garcia, C. Lucena, F. Zamboneli, A. Omicini, and J. Castro, (eds.), Software Engineering for Large-Scale Multi-Agent System, LNCS, Springer-Verlag, 2003. 31. Y. So and E. Durfee, An organizational self-design model for organizational change, in AAAI93 Workshop on AI and Theories of Groups and Organizations, 1993. 32. P. Stone and M. Veloso, Task decomposition, dynamic role assignment, and low-bandwidth communication for real-time strategic teamwork, Artif. Intell., vol. 110, no. 2, pp. 241273, 1999. 33. W. Turski and T. Maibaum, Specication of Computer Programs, Addison-Wesley Longman Publishing Co., Inc.: Boston, MA, 1987. 34. UML, Unied Modeling Language Specication, Version 2.0, http://www.omg.org/uml/, 2003. 35. G. Wagner, The agent-object-relationship metamodel, in Proceedings of the 2nd International Symposium: From Agent Theory to Agent Implementation together with EMCRS 2000, Vienna, Austria, 2000. 36. G. Wagner, Agent-oriented analysis and design of organizational information systems, in Proceedings of Fourth IEEE International Baltic Workshop on Databases and Information Systems, Vilnius, Lithuania, 2000. 37. G. Wagner, A UML Prole for External AOR Models, in Proceedings of 3rd International Workshop on Agent-Oriented Software Engineering (AOSE-2002), held at Autonomous Agents & Multi-Agent Systems, Palazzo Re Enzo, Bologna, Italy, 2002. 38. M. Wood and S. DeLoach, An overview of the multi-agent systems engineering methodology, in P. Ciancarini and M. Wooldridge, (eds.), Agent-Oriented Software Engineering, Springer-Verlag, 2001. 39. M. Wooldridge, N. Jennings, and D. Kinny, A methodology for agent-oriented analysis and design, in Proceedings of the Third International Conference on Autonomous Agents (Agents99), ACM Press, 1999, pp. 6976. 40. F. Zambonelli, N. Jennings, and M. Wooldridge, Organizational Abstractions for the Analysis and Design of Multi-agent Systems, in P. Ciancarini and M. Wooldridge, (eds.), Agent-Oriented Software Engineering, Springer-Verlag, 2001.

From A Conceptual Framework For Agents and Objects To A Multi-Agent System Modeling Language

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

From A Conceptual Framework For Agents and Objects To A Multi-Agent System Modeling Language

Uploaded by

Copyright:

Available Formats

Autonomous Agents and Multi-Agent Sytems, 9, 145189, 2004 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

Figure 1. Four-layer metadata architecture.

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

Creation of an agent Creation of a role

Choosing an Agent class

Choosing an AgentRole class

Choosing an Organization class

Creating the agent instance

Creating the role instance

Creating the organization instance

Registering the agent in the environment

Associating the role to the agent

Registering the organization in the environment [sub-organization] [main-organization]

Figure 2. State machine I: the creation of an agent, a role and an organization.

MULTI-AGENT MODELING LANGUAGE

Agent creating an sub-organization

Agent entering an organization

Playing roles [difficult in achieving the goals]

[all orgs have been already searched]

Verifying if goalOrg match goalAgent

[goalOrg match goalAgent]

Choosing an Organization class

Creating the organization instance

Registering the organization in the environment

Creating the role instance

Associating the role to the agent

[role associated to an agent] [role associated to an organization]

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

Class Reactive Environment

AgentClass Proactive Environment

Belief Property Axiom

ActionAgent 1..* Right Duty

Figure 4. The extended UML metamodel.

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

EnvironmentClass structuralFeatures behavioralFeatures entities that inhabit the environment

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA

MULTI-AGENT MODELING LANGUAGE

TORRES DA SILVA AND DE LUCENA