ANote:
A Modeling Language for Agent-Based Systems
Ricardo Choren and Carlos Lucena
Pontificia Universidade Catolica do Rio de Janeiro
Departamento de Informatica - Laboratorio de Engenharia de Software Rua M. de S. Vicente 225, Predio Pe. Leonel Franca, 10 andar - Gavea
Rio de Janeiro/RJ - CEP: 22453-900 - Brasil {choren, lucena}@inf.puc-rio.br
Abstract. Agent-oriented software engineering allows software design- ers to model a system in terms of interacting agents. Although there are a number of proposals for modeling languages to support multi-agent system development, they are usually based on some other abstraction, e.g., object-oriented. This paper presents a new notation language to de- sign agent-based systems whose diagrams show agency characteristics, such as adaptation and autonomy, and use ontology and UML to model the agent environment.
1 Introduction
Agents are becoming one of the main areas of interest in software engineering.
But this evolution has not been supported by a consequent increase of the design and developing techniques that, conversely, well support the design of conven- tional object-oriented (OO) software. Without reasonable software engineering methodologies, the development of agent-oriented (AO) systems becomes infor- mal, error prone and expensive [9].
Software development is the process of creating software solutions to given application problems. These problems should be stated in terms relevant to the application area or problem domain. To develop a solution, the software developer must create, implicitly or explicitly, computer domain models of the problem domain elements and abstractions [24].
The main domain element in a multi-agent system is an agent. An agent is defined as an element of a society that can perceive (often limited) aspects of its environment and affect that environment, either directly or through cooperation with other agents [15]. Also, an agent is a software system that should have a subset of the following characteristics enumerated in [8, 10–12, 26]: autonomy, interactivity, reactivity, proactivity and adaptability.
Each agent tries to accomplish its own tasks and it usually will need to interact with other agents and its environment to gain access to information it does not possess to ensure its goals can be met [28]. In other words, a multi- agent system can be seen as a society of agents, where the mutual interactions
between agents and with their environment lead to a useful global behavior. The agent organization provides more knowledge and skills than those provided by the agents individually. This additional functional value is not seen in an OO system.
This article focuses on the analysis of multi-agent systems using ANote, a modeling language that has the concept of agent as its center. ANote defines a notation set to picture agency characteristics, environment descriptions, agents and their behavior. Section 2 describes some related work. Section 3 describes the ANote modeling language, its views and diagrams. Section 4 shows a sample case study using ANote notation. Section 5 shows the contributions ANote makes to agent-based system modeling. Finally, section 6 presents some conclusions and future work.
2 Related Work
There is an extensive body of work being done in the field of agent-based systems modeling, most of it related to development methodologies. AgentUML (AUML) [17], for example, defines extensions to Unified Modeling Language (UML) [18]
with notations for agent concepts. AUML has extended UML interaction dia- grams to handle only the agent interaction protocols. However, AUML does not use the notion of an agent as a central concept. Moreover, specifying an object in terms of interaction protocols does not make it an agent.
The Gaia [27] methodology contains two analysis models and three design models. While the analysis models are based on well-defined concepts, they do not represent agency concepts and they mix the specification of non-agent com- ponents with the specification of roles. Besides, the design models are not clearly explained and the authors envisage OO methods being used for detailed design.
MESSAGE [4, 9] defines six agent models, and it is, probably, the most com- prehensive method. Yet, it adopts UML and AUML, i.e. OO, to detail the system design. In fact, using the OO paradigm to model agent-based systems is not de- sirable since an agent and an object do not share the same characteristics. An object does not provide support to reactive and proactive behaviors. Further- more, the OO paradigm does not directly support an organizational structure, with asynchronous interactions and autonomous behavior.
It may be reasonable to use an OO programming language to implement multi-agent systems as there is no widely accepted commercial AO programming language. Nevertheless, during the modeling phases of an agent-based system development life cycle, it is desirable to manipulate abstractions and elements that are more closely related to the problem domain.
3 The ANote Modeling Language
ANote is a graphical language for visualizing, specifying, constructing and doc- umenting the artifacts of a multi-agent system specification. ANote intends to
offer a standard way to write conceptual things concerning the multi-agent sys- tem modeling process. The primary goals of ANote are:
– To provide a basis for understanding the modeling of multi-agent systems.
– To provide users with an expressive visual modeling language to develop and exchange meaningful agent models.
– To support specifications that are independent of particular agent program- ming languages and development processes.
– To provide a modeling language that does not simply extends OO concepts.
ANote has a metamodel that emphasizes its declarative semantics. The meta- model decomposes the language into three logical packages: Structural, Dynamic Behavior, and Model Management. Each of these packages defines modeling views that are expressed by diagrams.
The Structural package provides the language infrastructure to specify the static structure of a system. It describes the basic elements that build the system and their relationships. ANote assumes that a multi-agent system is structurally defined (limited) by its goals, its agents, its environment and its resources. This package comprises three logical views: Goal, Agent and Ontology.
The Dynamic Behavior package defines the language infrastructure to specify agent behavior. Behavior means the set of actions and reactions of the agents in the system, and it initially is described as a set of scenarios. A scenario can be further detailed into action plans and interactions. This package comprises three logical views: Scenario, Planning and Interaction.
The Model Management package defines the language infrastructure to spec- ify the physical units within a system. It describes the agents’ organizations. An organization offers a set of services that can be accessed through a well-defined interface, as a multi-agent component. This package comprises only one logical view: System Model.
3.1 Goal View
The Goal View specifies the system goals. A goal defines some system function- ality, and it is useful to identify the requirements [20, 21]. The diagram for this view is the Goal Diagram.
The main concept in this view is the goal. A goal defines a service/functionality that must be offered by one or more agents. A goal is something that some system user expects to get in the future.
ANote defines three logical levels of goals. A generic goal indicates a con- text in which agents execute, structuring the agents’ main service requirements.
A functional goal indicates an agent goal within a context (generic goal). It corresponds to a basic service offered by an agent. A sub function shows an implementation step of an agent functional goal. The sole purpose of ANote’s logical levels of goals is to help developers understand the system requirements.
The language makes no actual distinction between them.
A generalization defines a relationship between goals. Semantically, a gen- eralization defines ancestor and descendant goals, establishing a generalization structure as a directed graph into which a child goal fits as a specification of a generic goal.
A goal is shown as a rectangle with rounded corners. A goal’s name must be unique within the entire set of goal models, i.e. the enclosing namespace.
A generalization is shown as an arrow that points from the more specific goal (child) to the more generic goal (parent).
Fig. 1. Goal and Generalization notation
3.2 Agent View
The Agent View specifies the agent types that exist in a multi-agent application solution, defining its structural basis. The diagram for this view is the Agent Diagram.
The main concept in this view is the agent class. An agent class is a descrip- tion of a set of agents that share the same goals, relationships, and semantics.
An agent class describes the system behavioral entities as discrete modeling elements; that is, it does not provide any further details about agent behavior in the system. An instance of an agent class is an agent, who is responsible for accomplishing one or more functional goals described in the Goal View. Thus, an agent provides a set of services that is its set of functional goals.
An association defines a relationship between agent classes. It has two asso- ciation ends, which one connected to an agent class. Semantically, an association represents a set of connections among instances of the agent classes. An instance of an association is a link, which corresponds to a connection through which agents can interact in the system. Therefore, for two agents to be able to in- teract, there must be an association connecting the two corresponding agent classes.
An agent class is shown as a rectangle with a gear in its upper left corner.
An agent class must have a name that is unique to its enclosing namespace. An association is shown as a solid line connecting two agent classes and may have a name, which also must be unique to its enclosing namespace.
3.3 Ontology View
The Ontology View specifies the non-agent components that exist in a multi- agent system environment. These components, along with the agents, comprise
Fig. 2. Agent Class and Association notation
the structure of a multi-agent application solution. The diagram for this view is the Ontology Diagram.
Ontology is a definition of a conceptualization [13]; it is a description - as a formal specification - of concepts and their relationships. A conceptualization is an abstract and simplified view of the world where the agents live, i.e., the environment.
ANote defines two kinds of non-agent components that make up a multi-agent system ontology: entities and facts. An entity represents a particular instance of something that can be manipulated by agents in the system. It is a resource with identity and attributes values. A fact represents an event or a particular data that can be used by agents to make a transition in their state. It is not an entity itself, but it may be related to one or more entities. Usually, a fact is a constant value or a notification that something happened in the environment.
An entity is related to a physical thing in the environment, and a fact is related to a subjective thing. Usually, an agent manipulates an entity during an action execution, whereas an agent uses a fact to make transitions in its rational (decider) internal component.
Describing an ontology means modeling its concepts and their relationships.
UML, together with its associated Object Constraint Language (OCL) [25], can be used as an alternative to represent it. Some advantages of using a UML subset to model an ontology can be seen in [2, 6]. Therefore, ANote uses a variation of the UML Class Diagram to model the non-agent components (ontology) of a multi-agent system.
Entities and facts are shown as stereotyped UML classes. An entity is shown with an ”entity” stereotype and a fact is shown with a ”fact” stereotype. Entities can participate in the same relationships that are in the UML Class Diagram (association, dependency, generalization, usage). Facts can only have dependency relationships with entities. All relationships are shown the same way they are in the UML Class Diagram.
Fig. 3. Entity and Fact notation
3.4 Scenario View
The Scenario View captures agent behavior in specific situations or contexts. The main concept in this view is the scenario. A scenario is a description denoting similar parts of possible behaviors limited to a context, i.e., to a purposeful state where actions and interactions take place among two or several agents.
Scenarios are useful for acquiring and validating requirements since they give stakeholders insight into general requirements and help in the system refinement process [20]. There are proposals that interpret scenarios as containing informa- tion about how goals can be achieved [1, 14, 19]. The goal-scenario combination has already been used to operationalize goals [23], and this combination is spe- cially helpful for building a bridge between ANote’s Structural and Dynamic Behavior packages.
In ANote, a scenario is shown as a description of one or more end-to-end transactions involving agents and their goals, represented as a table that iden- tifies an agent and its actions and interactions. The parts of a scenario table are:
– Name: identifies the scenario and must be unique to the enclosing namespace.
– Lead Agent: identifies the agent that starts (or controls) the main action plan execution.
– Preconditions: identify what must happen or be true before it is possible for the lead agent to start the main action plan.
– Main Action Plan: lists the actions that must be performed, denoting the usual agent behavior in the scenario context.
– Interactions: identify the agents with whom the lead agent interacts while executing the main action plan.
– Variant: is used to denote possible emergent behaviors the agents can show in the scenario context. A variant lists some other courses of action the lead action may take to adapt itself to a particular state in the context. It is described as a scenario table fragment, and may contain variation precondi- tions, action plans and interactions.
3.5 Planning View
The Planning View represents the execution states, or actions, an agent must perform to compute an action plan. The diagram for this view is the Planning Diagram.
The main concept in this view is the action graph. An action graph is a graph whose nodes are action states. An action state represents an action execution in a workflow. It means that the flow is waiting for the action to end in order to make a transition to the next set of possible action states.
In ANote, the action graph is shown as a graph whose nodes represent action states, and the arcs represent transitions. There are five kinds of action states and two kinds of transitions in ANote:
– Initial State: describes the start pseudo-action of an action plan. An initial state indicates that the agent must use its rational component to check the action plan preconditions listed in the scenario. The exit transition happens if and only if the preconditions are true.
– Final State: describes the end pseudo-action of an action plan.
– Action State: describes an atomic action of an action plan. The exit transi- tion happens when the action computation ends.
– Selection State: describes an pseudo-action whose exit transition depends on a guard condition.
– Adaptation State: describes a pseudo-action that indicates the agent must use its rational component to check variant preconditions. If their evaluation is true, the exit transition leads the action workflow to execute a variant action plan.
– Transition: indicates a passage from one state to another within an action plan. It may have forks and joins to allow concurrent action execution.
– Adaptation Transition: indicates a passage to a variant action plan. It always is seen after an adaptation state.
ANote action graph also has notation elements for entire action plans, entities and entity flow, to allow more detailed action plan modeling.
Fig. 4. States and Transitions notation
3.6 Interaction View
The Interaction View represents the set of messages the agents exchange to compute an action plan. The diagram for this view is the Collaboration Diagram.
The main concept in this view is the message. A message defines a particular communication between agents. A message is always an asynchronous commu- nication; that is, the sender dispatches the message and immediately continues with the next step in the execution of its action plan.
A message is an information flow between two agents - a sender and a receiver - and it can have a set of parameters. These parameters must be instances of entities from the Ontology View. The message name and parameter set define the message protocol.
A message is shown as a solid arrow that points from the sender to the re- ceiver. The message name and parameter set must be shown. Sequence numbers may also be shown since they are useful for identifying threads of messages.
Fig. 5. Message notation
3.7 System Model View
The System Model View represents system organizations and their relationships.
The diagram for this view is the Organization Diagram.
The main concept in this view is the organization. An organization is a multi-agent system implementation unit that offers a set of services, accessed by an interface. An organization acts as a container of agents. Typically, an organization exposes a set of interfaces, which represent the services provided by the agents that reside on it. An organization is shown as a cube that must have a unique name, and may present the agents that reside on it (the organization’s Agent Class Diagram).
A dependency defines a relationship between organizations. Semantically, an organization dependency shows a supplier-client relationship. It means that a client depends, in some way, on one or more services provided by the supplier to carry on its own services. A dependency is shown as a dashed arrow from a client organization to a supplier organization it depends on.
Fig. 6. Organization and Dependency notation
4 ANote Examples
The notation presented in this paper has been applied and refined in different types of multi-agent systems:
– A multi-agent solution [3] for a simple multi-agent marketplace on the Web.
– A supply-chain management application [22] involving the acquisition and integration of several components.
– An e-insurance application [16] for the discovery and commercialization of insurance products on the Web.
– An application [5] that simulates the manufacture of personal computers.
The above preliminary list illustrates that the ANote modeling language can be applied to a wide range of problem domains. The following section illustrates ANote diagrams for the latter example.
4.1 Example Description
A PC manufacturer receives an order to build a computer assigned to him from an user. The application assumes a very simple model of computer. It consists of the following components: a keyboard, a monitor, a CPU (motherboard), a laser or inkjet printer, and a printer cartridge. The manufacturer must then acquire and integrate these components to fulfill the user’s order. To acquire a component, the manufacturer buys it from a supplier. The supplier builds a component and then sells it. The printer supplier, however, is a different kind of supplier since it must first buy a cartridge in order to sell a printer to the manufacturer. After acquiring all of the necessary components, the manufacturer assembles them and delivers the computer to the user.
4.2 Solution Analysis
Goal View. The analysis starts with the system’s goals, focusing on its services and functionalities. As for the Goal View, the main goal of the system (i.e.
providing computers to users) is decomposed according to the services needed to fulfill it. Figure 7 shows the Goal Diagram where the lowest level of goals shown is the functional level.
Agent View. The Agent View shows the agent classes that build the multi- agent application solution. The system is not concerned about the final user; that is, the user that creates the demands is not a software agent. Thus, the system comprises the following agent classes: manufacturer, basic supplier and inter- mediate supplier. A manufacturer interacts with both basic and intermediate suppliers, and an intermediate supplier interacts with a basic supplier.
Ontology View. The Ontology View shows the entities and facts manipu- lated by agents to build a computer. Basically, they describe computers, com- ponents, orders and order completions.
Fig. 7. Goal Diagram
Fig. 8. Agent Class Diagram
Fig. 9. Ontology Diagram
Scenario View. For each one of the functional goals depicted in the Goal Diagram there must be one or more scenario descriptions. The scenarios describe the execution behavior of agents in order to accomplish their goals. For space reasons, figure 10 shows only two scenario descriptions.
Fig. 10. Scenario Diagrams
Planning View. The Planning View details the action plans described in the scenarios. Figure 11 shows the Planning Diagrams for the action plans described in the above scenarios.
Interaction View. The Interaction View details the interactions described in the scenarios. Figure 12 shows the Collaboration Diagrams for the interactions described in the above scenarios.
Organization View. This case study describes a simple system that is composed of only one organization. Thus, the Organization Diagram is another way to show the Agent Class Diagram.
5 ANote Discussion
The previous section presented ANote, a notation language for multi-agent sys- tems modeling. Below, some of the language’s impacts are listed:
New Language. ANote neither uses nor extends an OO modeling language.
Thus, there is no conflict about the semantic of the agent-modeling element in ANote.
Viewpoints. ANote offers a logical division of a multi-agent system mod- eling process in views. These views are integrated and they help the system’s intra- and inter-agent modeling aspects of the system.
Environment Modeling. ANote offers more comprehensive environment modeling. Developers can use ontology to model the things contained in the environment, and can use scenarios to show how these things are manipulated by agents.
Fig. 11. Planning Diagrams
Fig. 12. Collaboration Diagrams
Agency Characteristics Modeling. ANote model elements are able to model some agency characteristics, allowing them to be part of the system doc- umentation. For instance:
– Autonomy: autonomy can be shown in the Scenarios and Planning Diagrams whose set of preconditions is empty. This means that the lead agent can perform the actions described at anytime, based only on its desire.
– Interactivity: interactivity is directly shown in the Scenarios and Collabo- ration Diagrams. These diagrams show that agents interact to accomplish their goals.
– Reactivity: reactivity is shown in the Scenarios Diagrams along with the Ontology Diagram. These diagrams are able to show that agents are situated in an environment and how these agents react to (and manipulate things in) the environment.
– Proactivity: proactivity is directly shown in the Goal and Scenario Diagrams.
These diagrams show that agents have goals and they act to accomplish these goals.
– Adaptability: adaptability is shown in the Scenarios and Planning Diagrams that have variants. A variant is able to show that an agent adapts its behavior under certain situations.
6 Concluding Remarks
This paper has presented the ANote modeling language and illustrated it through an example case study. ANote is an agent-based notation and it neither extends nor uses an object-oriented modeling language. ANote is a set of agent knowledge level concepts, and it provides diagrams with notations for viewing them.
ANote is not a development process, it is just a notation. A notation is only a means, not an end itself. A good notation is important for good models are essential for communication among project teams. ANote offers a single, inte- grated, agent-based semantic model with corresponding graphical and textual notation.
ANote is organized in terms of analysis views and diagrams. The underlying views integrate multi-agent system perspectives and the diagrams provide the notation for these perspectives so that a self-consistent system can be analyzed and built. The language illustrates the following aspects: goal decomposition, agent classes, environment/ontology description, behavior modeling and agent organization.
In future work, efforts will be concentrated on refining the language notation to allow extension mechanisms, and on developing a graphical tool to support its automated use as a plug-in for the Eclipse [7] open platform.
7 Acknowledgments
This research was supported, in part, by the Brazilian Ministry of Science and Technology (MCT) through the National Council for Scientific and Technological Development (CNPq), ESSMA Project (552068/2002-0).
References
1. Anton, A. I., McCracken, W. M., Potts, C. Goal decomposition and scenario anal- ysis in business process reengineering. Proceedings of the Advanced Information Systems Engineering, CAiSE, 1994. Springer-Verlag, Berlin, 1994, pp. 94-104.
2. Bergenti, F., Poggi, A. Exploiting UML in the design of multi-agent systems. Pro- ceedings of the First International Workshop Engineering Societies in the Agent World, ESAW, 2000. Springer-Verlag, Berlin, 2000, pp. 106-113.
3. Bigus, J. P.; Bigus, J. Constructing intelligent agents using java. 2.ed. John Wiley
& Sons, New York, 2001.
4. Caire, G., Leal, F., Chainho, P., Evans, R., Garijo, F., Gomez, J., Pavon, J., Kear- ney, P., Stark, J., Massonet, P. Agent oriented analysis using MESSAGE/UML.
Proceedings of the Second Agent-Oriented Software Engineering International Workshop, AOSE, 2001. Springer-Verlag, Berlin, 2001, pp. 119-135.
5. Colis, J. PC Manufacture: a supply chain simulation. British Telecommunications, Technical Report, London, 1999.
6. Cranefield, S., Purvis, M. UML as an ontology modelling language. Proceedings of the Workshop on Intelligent Information Integration, 1999, pp. 46-53.
7. Eclipse Consortium. Eclipse.org Main Page. http://www.eclipse.org/.
8. Etzione, O., Weld, D. S. Intelligent agents on the Internet: fact, fiction, and fore- cast. IEEE Expert, 10(4), 1995, pp. 44-49.
9. Evans, R. (ed.) MESSAGE - methodology for engineering systems of software agents: methodology for agent-oriented software engineering. EURESCOM Tech- nical Report, 2001.
10. Ferber, J. Multi-agent systems: an introduction to distributed artificial intelligence.
Addison-Wesley, Oxford, 1999.
11. Franklin, S., Graesser, A. Is it an agent or just a program? A taxonomy for au- tonomous agents. Proceedings of the Agent Theories, Architectures and Languages, ATAL, 1996. Springer-Verlag, Berlin, 1996, pp. 21-35.
12. Genesereth, M. R., Singh, N., Syed, M. A distributed and anonymous knowledge sharing approach to software interoperation. International Journal of Cooperative Information Systems, 4(4), 1995, pp. 339-367.
13. Gruber, T. R. A translation approach to portable ontology specifications. Knowl- edge Acquisition, 5(12), 1993, pp. 199-220.
14. Holbrook, C. H. A scenario-based methodology for conducting requirements elici- tation. ACM SIGSOFT, Software Engineering Notes, 15(1), 1990, pp. 95-104.
15. Lugger, G. F., Stubblefield, W. Artificial intelligence: structures and strategies for complex problem solving. 3ed. Addison-Wesley, Massachusetts, 1998.
16. Nogueira, L., Oliveira, E. A multi-agent system for e-insurance brokering. Proceed- ings of the Workshop on Agent Technologies for e-Services, 2002, pp. 354-372.
17. Odell, J., Parunak, H. V. D., Bauer, B. Extending UML for agents. Proceedings of the Agent-Oriented Information Systems Workshop at the 17th National Con- ference on Artificial Intelligence. ICue Publishing, Berlin, 2000.
18. OMG. Unified modeling language, 1999-2002. http://www.omg.org/uml/
19. Potts, C. Fitness for use: the system quality that matters most. Proceedings of the International Workshop on Requirements Engineering, REFSQ, 1997, pp. 15-28.
20. Potts, C., Takahashi, K., Anton, A. Inquiry-based requirements analysis. IEEE Software, 11(2), 1994, pp. 21-32.
21. Prat, N. Goal formalisation and classification for requirements engineering. Pro- ceedings of the Third International Workshop on Requirements Engineering: Foun- dations of Software Quality, REFSQ, 1997.
22. Ribeiro, M. B. Web Life - An architecture for the implementation of multi-agent systems on the Web. PhD. Thesis - Computer Science Department - PUC-Rio.
23. Rolland, C., Souveyet, C., Achour, B. Guiding goal modelling using scenarios.
IEEE Transactions on Software Engineering, 24(12), 1998, pp. 1055-1071.
24. Seidewitz, E., Stark, M. Reliable object-oriented software. SIGS Books, New York, 1995.
25. Warmer, J. B., Kleppe, A. G. The object constraint language: precise modeling with uml. Addison-Wesley, Massachusetts, 1998.
26. Wooldridge, M., Jennings, N. Intelligent agents: theory and practice. Knowledge Engineering Review, 10(2), 1995, pp. 115-152.
27. Wooldridge, M., Jennings, N. R., Kinny, D. The Gaia Methodology for Agent- Oriented Analysis and Design. Autonomous Agents and Multi-Agent Systems, 3(3), 2000, 285-312.
28. Zambonelli, F., Jennings, N. R., Omicini, A., Wooldridge, M. Agent-oriented soft- ware engineering for internet applications. In: Omicini, A. et al. (eds.) Coordination of internet agents: models, technologies, and applications. Springer-Verlag, Heidel- berg, 2000, pp. 326-346.
