UML Profile for Agent-Oriented Software Engineering

Claudia Marcos, Jane Pryor

E-mail: cmarcos@exa.unicen.edu.ar

ISISTAN Research Institute, Facultad de Ciencias Exactas, UNICEN

Paraje Arroyo Seco, B7001BBO Tandil, Argentina

EMail: [cmarcos, jpryor]@exa.unicen.edu.ar

Tel/Fax: + 54–2293–440362/3 http://www.exa.unicen.edu.ar/~isistan/

Abstract. The diversity of multi-agent systems creates the need for tools and

methodologies to achieve their designs. UML has been proposed as a new

approach for agent modeling, yet it does not support the concept of agents. This

paper describes a UML profile that we defined for Multi-Agent Systems MAS.

In order to support the definition of this profile the ArgoUML tool was

extended. The extended tool allows developers to specify a new profile and

automatically updates the standard UML, permitting the modeling of

applications with these new elements.

Keywords. UML metamodel, UML extension, agent modeling, use case

extension for agents.

1. Introduction

The incorporation of intelligent agents [7, 13] current software applications is ever

more frequent. An agent is a software component allocated in a run-time environment

to assist or represent someone or something, and acts by itself with some autonomy.

Besides this autonomy, there are several additional attributes by which it is possible to

characterize a software agent, such as reactivity, pro-activity, social ability,

adaptability and mobility [15].

An agent-based application has only one agent. However, frequently these

applications have several agents interacting and collaborating among themselves,

becoming a multi-agent system MAS. In this context, it is possible to identify a multi-

agent system as having at least two different kind of agents, each of them belonging

to one of the above five categories.

Because of the diversity of agent systems, their design is becoming more complex

and, as a consequence, tools and methodologies are necessary for their development.

The current work on tools and methodologies for agent systems is oriented towards

proposing different UML [19] extensions in order to cover the developers´ needs [9,

17, 5, 6]. However, these approaches are not sufficient for the modeling of all the

agent’s characteristics.

1

7º Simposio Argentino de Inteligencia Artificial - ASAI2005

Rosario, 29-30 de Agosto de 2005

1

This paper presents a UML profile which allows developers to extend UML

diagrams in order to introduce new modeling requirements for agent systems. We

have also extended the ArgoUML [1] tool in order to support the proposed profile and

to automatically update its UML metamodel.

The following section presents the Unified Modeling Language UML. Section 3

discusses some approaches for the modeling of agent-based applications and what

UML is lacking in order to satisfy these new modeling requirements. Section 4

describes how we solve the limitations of the current approaches, specifically how the

use case diagram has been extended in order to differentiate the system from the agent

functionality and describe the UML Agent Profile. Section 5 presents an example.

The remaining section presents the conclusions.

2. UML Unified Modeling Language

UML provides modeling concepts and notations that have been carefully designed

to meet the needs of typical software modeling projects. However, because of the

diversity of application domains, developers may require additional notations or

features beyond those defined in the UML standard. Moreover, sometimes developers

need to incorporate non-semantic information to their models. These needs are met in

UML by its built-in extension mechanisms: Stereotype, Constraint, and TaggedValue.

These extension mechanisms enable new kinds of modeling elements to be added to

the modeler’s repertoire as well as to attach free-form information to modeling

elements.

Stereotypes provide a way of classifying model elements at the object model level

and they facilitate the addition of "virtual" UML metaclasses with new meta-attributes

and semantics. The other built-in extension mechanisms are based on the notion of

property lists consisting of tags and values, and constraints. These allow developers to

attach additional properties and semantic directly to individual model elements, as

well as to model elements classified by a Stereotype.

The desired extensions have to be documented in a Profile which describes their

main characteristics. A fundamental constraint on all extensions defined using the

profile extension mechanism is that the extensions must be strictly additive to the

standard UML semantics [19]. This means that such extensions must not conflict with

or contradict the standard semantics. The extension mechanisms are a systematic way

to refine the UML standard semantic.

We are working on the definition of a profile for agent systems. This profile

provides the means for incorporating all the elements that may be needed for the

modeling of agent applications. ArgoUML is an open-source tool that supports the

UML metamodel. In the first place we extended this tool to support the incorporation

of new profiles. This extension takes the documentation of the proposed profile and

automatically updates its UML metamodel. By the extension of an existing tool its

tested functionality is reused and the designer can continue using it without any

change. Moreover, the applications already modeled with the tool are kept consistent.

2

2

3. Agent-Oriented Methodologies

There are two different approaches in order to support the development of agent

applications: to extend current object-oriented methodologies or to define a specific

new one. The most accepted approach is the first one, mainly the use of UML Unified

Modeling Language Rumbaugh with its extension mechanism, as in Agent UML [2],

MESSAGE/UML [9], Tropos [10], or the Bergenti y Poggi approach [4, 5, 6].

Agent UML describes the development of multi-agent systems from analysis to

design, that is, it covers some phases of the life cycle. It is specially focused on the

agent representation and communication protocols. Agent UML defines three

diagrams: agent’s class diagrams, sequence diagram, also called protocol diagram,

and diagram for groups.

MESSAGE Methodology for Engineering Systems of Software AGEnts covers the

analysis and design of multi-agent systems. MESSAGE defines views for the analysis

step: Organization, Objective/Task, Agent/Role, Interaction and Domain. The

organization view shows the agents, their organization, roles, and resources used by

the system. The objective/task view shows the objectives, tasks and dependency

among them. In the agent/role view, for each agent/role a template is filled with the

goals of the agent, resources needed, tasks to be developed and how they have to be

done. The interaction view describes for each agent interaction, who is the originator,

the information passed, the collaboration agents, and so on. Finally, the domain view

describes the concepts and relationships necessary for the system.

Tropos is an agent-oriented software methodology. It has two main characteristics:

the importance of the early requirement analysis and, on the other hand, the agent

notion and its mental notions are used in the software development phase, from the

early analysis to the implementation. Tropos uses the UML class diagram with some

stereotypes to represent the different actors, the sequence diagram to represent the

actor’s interactions, and the plan diagram to represent de agent’s plans.

Another approach is the Bergenti and Poggi proposal. This approach suggests

using a UML based notation for the agent modeling and the ParADE framework for

the system instantiation. This approach defines an ontology and architect model, and a

protocol and role diagrams. The ontology model represents the agents by an ontology

for the environment in entity and relationship terms. The architect model is composed

by a set of agents where each one is represented by a class with the agent

responsibilities. The protocol and roles diagram allow designers to model the

interaction among the agents.

The above UML extension approaches cover some of the needs for modeling agent

and multi-agent system. However, some aspects have not been considered yet.

Specifically, it is necessary to represent the agent’s plans and its details, the condition

that has to be true in order to execute each plan, etc. It is also important to identify the

agent and the system responsibility in the first development steps.

From the life cycle point of view, it is important to cover all the development

phases from the capture of requirements to the maintenance phase. The current

approaches are centered on some of the phases, mainly the design. Tropos is an

approach that tries to cover almost all the phases.

One of the most important limitations of the described approaches is that their

documentation is informal, that is, they lack a precise and formal documentation. This

3

3

produces incompatibility with the current CASE tools. Any proposed UML extension

must support documentation which follows the standard UML semantic [16].

4. Agent-UML Profile

Based on the previous discussion and taking into account the limitations mentioned

we are currently working on the definition of a profile for the construction of agent

systems. For example, to make a differentiation between the functionality of the

system and of the agent as from the first phases of the life cycle, we have extended

the UML use case diagram.

A use case diagram is used to model functional requirements and to delimit a

system. It consists of use cases and actors. An actor is a person, hardware, or

software, stimulating and interacting with the system. A use case specifies the system

behavior, described by a sequence of actions. It is possible to identify different

relationships between use cases. An example is the extension relationship which is

used when two or more use cases develop a set of the same functionality. This set is

factorized in a new use case related to the first ones (table 1).

The use case diagram can also be used for the modeling of agent-based systems.

However, it does not provide the elements to differentiate between the responsibilities

of the agents and the objects. To make this differentiation clear new elements have

been added to the use case diagram.

An AgentActor is an actor whose behavior is a system responsibility. This means

that the functionality of the AgentActor will be implemented during the construction

of the system.

An AgentUseCase is a use case that interacts with actors or AgentActors. An

AgentUseCase may be related to other AgentUseCases by the extend, include and

generalization relationships. On the other hand, an AgentUseCase may be related to a

use case by the monitoring relationship.

A Monitoring relationship means that the AgentUseCase controls and observes the

related use case behavior and carries out activities according to that behavior. A

monitoring relationship is defined when a use case contains the behavior defined in an

AgentUseCase or when additional behavior defined in an AgentUseCase is carried out

at the same time as the original use case. A monitoring relationship may be

conditional or fixed: conditional when a condition must be true for the AgentUseCase

to be activated, and fixed, when the AgentUseCase is always activated. Additionally,

a monitoring relationship may be parallel if the functionality of the AgentUseCase

does not modify or interfere with the functionality of the related use case, and

nonparallel or crosscutting if the AgentUseCase´s behavior affects that of the related

use case.

Figure 1 shows how the AgentActor is specified using the extension to the

ArgoUML tool that has been developed. In this figure it is possible to see how the

different characteristics are specified and how the new stereotype inherits the

constraints of its base class.

4

4

Table 1. Stereotypes for Use Case diagram.

Name Base Class Tagged Value/

Constraint

Description

AgentActor Actor AgentActors can only

have Associations to

AgentUseCases,

Subsystems, and

Classes. These

Associations are binary.

It is an actor whose behavior

is system responsibility.

AgentUseCase Use Case N/A It is a use case that interacts

with actors and AgentActor.

Its functionality is agents

responsibility.

Monitoring Extend

relationship

Types: [parallel

conditional monitoring,

nonparallel conditional

monitoring, parallel

fixed monitoring,

nonparallel fixed

monitoring]

It represents a relationship

between a use case and an

AgentUseCase

Figure 1. Stereotype specification

These constraints are described in natural language and specified in OCL [War98].

An AgentActor also defines its own constraint.

5

5

[1] AgentActors can only have Associations to AgentUseCases, Subsystems, and

Classes. These Associations are binary.self.associations->forAlla |

a.connection->size = 2 and a.allConnections->existsr | r.type.oclIsKindOfAgentActor and a.allConnections->existsr |

r.type.oclIsKindOfAgentUseCase orr.type.oclIsKindOfSubsystem orr.type.oclIsKindOfClass

The use case diagram extension belongs to an UML Profile for Agent Modeling

that we are developing. We have analyzed the problems found in the current

approaches and solved them in this profile trying to cover all the modeling needs of

agent-oriented applications. This profile consists of four different models:

Agent system functionality model: As an agent system is composed of objects and

different types of agents, it is necessary to identify the roles and responsibilities of the

agent and the functionality of the objects. Extensions of the use case, as we described

previously, and activity diagrams are used to model this differentiation clearly and to

specify in which circumstances each agent reacts.

Agent behavior model: Agents and their environments are identified by using an

extension of the class diagram which describes their beliefs, motivations and plans.

The behavior of the agents can be modeled by means of statechart diagrams. The

agent’s plan, its description, conditions that have to be true in order to execute each

plan is represented by activity diagrams.

Agent communication model: Agents frequently collaborate with each other in

order to carry out their tasks. The agent communication model describes the agent

communication, services, and negotiation protocols necessary to satisfy a task.

Extensions of interaction diagrams are used to describe the interaction between

objects and agents and between agents themselves.

System model: The structural aspect of an agent application is modeled by an

extension of a class diagram.

The following sections focus on the Agent System Functionality model in order to

describe and exemplify it in detail.

5. Home Sweet Home

In order to exemplify the use case diagram described above in this section we

developed a Home Sweet Home application. This system is a family application

which helps with the administration of family meals. It permits the user to store meals

with their corresponding ingredients, it makes up shopping lists, maintains food

preferences of family members and guests, and helps to plan and organize menus.

An agent is involved in the application and it has several responsibilities. An

example of this is that the agent has to learn the different days and weeks in which the

user does the shopping. This information is useful to suggest the ingredients needed

for the next menus. The user can also explicitly ask the agent for this information.

The agent continuously observes and learns about the user’s activities. Using this

information, when a menu is planned the user can ask the agent for suggestions. The

6

6

agent also controls the stock of ingredients. In this way, s/he can alert about the

ingredients that will run out within the following days or that have already run out.

The agent builds and maintains a profile for each person in order to make suggestions

about the most suitable menu.

Given this context it is possible to identify the system and agent responsibilities.

Figure 2 shows the corresponding use case diagram of the application modeled with

the proposed stereotype and using the extension of ArgoUML that we developed. As

the AgentUseCase does not have an associated icon, they are shown between

brackets, <<AgentUseCase>>.

In Figure 2 it is possible to identify several use cases. Some of them represent system

functionality and others represent agent behavior. The agent use cases are described

as follows:

Figure 2 – Use case diagram for Home Sweet Home

Name: Learn Meal Frequency

Description: The agent learns the frequency of meals. This learning is always

developed in parallel when the user is cooking, that is, it does not modify the original

use case functionality.

Monitoring: Cooking Kind: Parallel Fixed Monitoring

7

7

Flow of events:

1. The agent analyzes the meals being prepared.

2. The knowledge of the frequency of meals is updated with the new information.

Name: Inform lack of Ingredients (Figure 3)

Description: This use case is activated if the agent realizes that an ingredient is not

in stock, that is, it has a monitoring relationship with a condition.

Monitoring : Cooking Kind: Monitoring Condition

Pre-condition: A meal has to be prepared and the necessary ingredients are not in

stock.

Flow of events:

1. The agent verifies the missing ingredients.

2. The agent stores the information.

3. The agent changes to the suggestion state.

4. The agent informs the missing ingredients to the user.

Figure 3. Inform lack of Ingredients – Monitoring Condition

Name: Update Buying Day – Agent Activation

Description: The agent activates itself and, using the information of what has to be

bought and of buying days, it decides which is the most adequate day to do the

shopping.

8

8

Flow of events:

1. A learning algorithm is applied based on the shopping days of the month and the

ingredients to be bought.

2. The agent analyzes the old and new information and infers and suggests the new

shopping day.

3. The agent knowledge of the shopping days is updated.

Name: Suggest Meal

Description: When a menu is scheduled the agent always suggests meals

according to the preference of family members and guests.

Monitoring: Scheduler Meal Kind: Nonparallel Fixed Monitoring

Flow of events:

1. The family members and the guests are identified for a menu on a specific day.

2. The agent analyzes the people’s preferences and chooses the best meal

combination according to their preferences.

3. The suggested meals are presented to the user

Using these new modeling elements for the use case diagram it is possible to make

a differentiation between the object and agent functionality. In this way, the designer

can obtain a clear separation of responsibilities and behavior, and will be able to

design the required functionality in a non-ambiguous way.

6. Conclusions

The standard UML does not provide the means for modeling agent-oriented

applications, due to the diversity of these systems. A UML profile has been defined in

order to support the necessary modeling features.

To illustrate this approach, the Agent System Functionality Model has been

described. In this model three stereotypes have been incorporated: the AgentUseCase,

representing the agent behavior; the AgentActor, representing the agent whose

behavior has to be supported by the system; and the Monitoring relationship

representing the application functionality that has to be analyzed by an agent. This

modeling extension allows developers to identify the agent responsibilities and

behavior as from the first phases of the life cycle of the agent application. It is also

possible to identify in which situations the agent will be involved in the system’s

functionality.

The effectiveness of the approach has been evaluated applying it to the modeling

of simple scenarios and applications in different domains. Although we have found

that the approach is appropriate, we have found that additional models are necessary

in order to model the internal structure of an agent, the user-agent interaction, and the

distribution aspects of agent applications. We are exploring how UML can be used

and extended to specify these new models.

In addition, an attractive area of future research is to work more on methodological

aspects, by exploring how an existent software development process can be extended

to incorporate the notations and the iterative refinement process we are using. The

9

9

Unified Process [6] seems to be the most appropriate to explore, essentially because it

currently represents an extensible standard process for software development.

The ArgoUML tool has been extended in order to support the incorporation of new

UML profiles. This tool takes the new profile with the proposed elements in a

systematic way and automatically updates its UML metamodel. An example

application has been used to describe the extended ArgoUML. The example profile

presented in this paper centered on the extension of the use case diagram for the

modeling of an agent’s functionality. However, the tool can be used for the extension

of any UML diagram for the modeling of applications in different domains, such as

the design of aspects [18].

7. References

1. ArgoUML At www.argouml.tigris.org

2. Bauer B., Muller J. P. and Odell J. "An Extension of UML by Protocols for Multiagent

Interaction". In Proceedings of ICMAS 2000, Boston, MA, 2000.

3. Bauer B., Muller J. P. and Odell J. "Agent UML: A Formalism for Specifying Multiagent

Software Systems". In Proceedings of ICSE 2000 Workshop on Agent-Oriented Software

Engineering AOSE 2000, Limerick, 2000.

4. Bergenti F., Poggi A. Supporting Agent-Oriented Software Engineering with UML.

International Journal Software Engineering and Knowledge Engineering, 2002.

5. Bergenti F., Poggi A. Agent-Oriented Software Construction with UML. In S.K. Chang, ed.,

Handbook of Software Engineering & Knowledge Engineering - Volume 2 - Emerging

Technologies, pp. 757-769, World Scientific, 2002.

6. Bergenti F. and Poggi A. Supporting Agent-Oriented Software Engineering with UML.

International Journal Software Engineering and Knowledge Engineering, 2002.

7. Bradshaw J. An Introduction to Software Agents, in Software Agents, Bradshaw, J.M. ed.,

Cambridge, MA: MIT Press, 1997 3 – 46

8. Booch, G., Rumbaugh, J., and Jacobson, I. The Unified Modeling Language. User Guide.

Addison-Wesley, 1999.

9. Caire, G., Garijo, F. Gomez, J., Pavon, J., Leal, F., Chainho, P., Kearney, P., Stark, J., Evans,

R., Massonet, P. Agent Oriented Analysis Using MESSAGE/UML. In this volume 2001

10. Castro, J., Kolp, M. and Mylopoulos, J., Developing Agent-Oriented Information Systems

for the Enterprise, Proceedings of the Second International Conference On Enterprise

Information Systems ICEIS00, Stafford, UK, July 2000.

11. Huget, M., Odell, J., and Bauer B. "UML and Agents: Current Trends and Future

Directions". In Proceedings of OOPSLA Workshop on Agent-Oriented Methodologies. J.

Debenham, B. Henderson-Sellers, N. Jennings and J. Odell eds., Seattle, USA, November

2002.

12. Iglesias C., Garijo M., and Gonzalez J. A survey of agent-oriented methodologies. In J. P.

Müller, M. P. Singh, and A. S. Rao, editors, Intelligent Agents V LNAI Volume 1555.

Springer-Verlag: Berlin, Germany, 1999.

13. Jennings N., and Wooldridge M. Applications of Intelligent Agents. In "Agent

Technology: Foundations, Applications, and Markets", Springer-Verlag, eds Nicholas R.

Jennings and Michael J. Wooldridge - pages 3--28, 1998

14. Mylopoulos, J. and Castro, J., Tropos: A Framework for Requirements-Driven Software

Development, Brinkkemper, J. and Solvberg, A. eds., Information Systems Engineering:

State of the Art and Research Themes, Springer-Verlag, June 2000, pp. 261-273.

10

10

15. Nwana H. Software Agents: An Overview. Knowledge Engineering Review, Vol. 11 No 2 -

1996 205 - 244

16.OMG At http://www.omg.org.

17. Odell J., Van Dyke Parunak H. and Bauer B. "Extending UML for Agents". AOIS Worshop

at AAAI 2000, Austin, TX, 2000.

18. Pryor J. UML Extension for Aspect-Modeling. Technical Report TR-18-03, ISISTAN

Research Institute, Universidad Nacional del Centro de la Provincia de Buenos Aires

UNICEN, 2002. In Spanish.

19. Rumbaugh, J., Jacobson, I., and Booch G. The Unified Modeling Language. Reference

Manual. Addison-Wesley, 1999.

20. Shoham, Y. An Overview of Agent-Oriented Programming. In Software Agents, J. M.

Bradshaw Ed., pp. 271-290. MIT Press, 1997.

21. Schneider, G., Winters, J. Applying Use Cases. Second Edition. A Practical Guide. Addison

Wesley. 2001.

22. Warner, J., and Klepper, A.. The Object Constraint Language. Precise Modeling with UML.

Addison-Wesley 1998.

11

11