7º Simposio Argentino de Inteligencia Artificial - ASAI2005 Rosario, 29-30 de Agosto de 2005
UML Profile for Agent-Oriented Software Engineering Claudia Marcos, Jane Pryor E-mail:
[email protected] 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 multiagent 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 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/ Description Constraint AgentActor Actor AgentActors can only It is an actor whose behavior have Associations to is system responsibility. AgentUseCases, Subsystems, and Classes. These Associations are binary. AgentUseCase Use Case N/A It is a use case that interacts with actors and AgentActor. Its functionality is agents responsibility. Monitoring Extend Types: [parallel It represents a relationship relationship conditional monitoring, between a use case and an nonparallel conditional AgentUseCase monitoring, parallel fixed monitoring, nonparallel fixed monitoring]
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 or r.type.oclIsKindOfSubsystem or r.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, .
Figure 2 – Use case diagram for Home Sweet Home
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: 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
