services. To easily develop agents, we can use a methodology, because it aids the development providing ... approach cannot be specific to a programming.
Service-Oriented Agent Methodologies Giacomo Cabri, Letizia Leonardi, Mariachiara Puviani Dipartimento di Ingegneria dell’Informazione – Università di Modena e Reggio Emilia Via Vignolese, 905 – 41100 Modena – ITALY E-mail: {giacomo.cabri, letizia.leonardi, mariachiara.puviani}@unimore.it Abstract Agents and services are two concepts that more and more are integrating and exploiting the advantages of each other. Agent-oriented methodologies effectively support the development of agent-based system in the different phases. In this paper, we explore how and how much the most common agent-oriented methodologies are also oriented to the development of services. Rather than searching for the “best” methodology, we aim at defining some evaluation criteria and surveying the existing methodologies considering such criteria.
1. Introduction In the last years, services of every kind have increased their importance in everyday life and also the agent paradigm has been involved in this scenario, especially Multi Agent Systems (MAS). In according to [Jen01], we can say that MAS is a software engineering paradigm for designing and developing complex software systems, which often rely on services. To easily develop agents, we can use a methodology, because it aids the development providing guidance through the life cycle process and furnishing a set of predefined techniques, and it also allows modelling by providing a suitable notation [Rum91]. To write Service-Oriented Agents we especially have to take into consideration the main features of SOA (Service-Oriented Architecture): we can extract SOA’s characteristics and exploit the agentmethodology support to them. The selection of the right methodology is crucial for the success of any software project; it is the reason why, to write SO (Service-Oriented) Agents, it can be useful to use an appropriate Service-Oriented Methodology.
This paper details the criteria used to evaluate a SO Methodology (Section 2) and describes some wellknown methodologies that can be considered useful to develop SO Agents (Section 3). In Section 4, we compare the various methodologies with respect to the previously-defined evaluation criteria. Finally, Section 5 reports some conclusions and future work.
2. Evaluation Criteria According to [Huh05], SOA is an application architecture within which all functions are defined as independent services with well-defined interfaces, which can be called in defined sequences to form business processes. SOA draws inspiration from SOC (Service-Oriented Computing) and has some key elements from which we can select our evaluation criteria for agent methodologies: - Implementation neutrality: a service-based approach cannot be specific to a programming language and should allow new applications to interoperate, so it can be important to use standard and well know languages such as XML (eXtensible Markup Language) and UML (Uniformed Markup Language); - Flexible configurability: it is important to use diagrams as use-case diagrams, activity diagrams, and UML or AUML like diagrams; - Granularity: it is important to modelling the systems not only at detailed levels, but also at high-levels (this is possible with the use of diagrams); - Loose coupling: we must consider high-level contractual relationships to achieve system-level consistency; - Persistence: the services must exist long enough. We decided to extract two evaluation criteria from the first three key elements, because they are related to methodologies, while the other two are more connected to the implementation phase: (1) the use of standard
1
languages, referred to implementation neutrality; and (2) the use of diagrams, coming from flexible configurability and granularity. With regard to agents, they have some important characteristics that turn out to be useful in the service development: proactiveness, reactivity, autonomy, and sociality. In particular, the characteristics of proactiveness and autonomy, and agent’s ability to negotiate commitments and deal with exceptions are key enablers for developing a SOA. In fact, as readers can see in Figure 1 (taken from [Huh05]), goals are the main concepts of the SOA; so we will verify how much a methodology is goal directed (3rd criterion), which permits to connect SOA goals with agent proactivity.
Figure 1: Service Oriented Architecture
3. Agent Methodologies Methodologies proposed in the literature exhibit influences from several research areas; in particular: Object-Oriention (OO), Knowledge Engineering (KE) and Requirements Engineering (RE). Since SOA is particularly OO based, in this paper we have considered only methodologies based on the agentoriented paradigm that is an evolution of OO approach [Stu03]. In general, a SO methodology first describes the business collaboration as use-case diagrams, and then describes business transitions as activity diagrams; then a CASE-tool generates the code to implement the system. This is the motivation why we have considered only methodologies assisted by a tool, which should be easy to use and should support the whole development cycle.
In the following we shortly describe the considered agent methodologies, in alphabetical order. Then, in the next section we will evaluate these methodologies using the proposed evaluation criteria. ADELFE (Toolkit for Designing Software with Emergent Functionalities) The ADELFE methodology is used to develop Adaptative MAS (AMAS). It is based on well-known tools and notations coming from the object-oriented software engineering: UML (Unified Modelling Language) and the RUP (Rational Unified Process) [Ber02]. It is composed of three phases: Late Requirements, Analysis and Design. - Late Requirements provide the environment model, define a view of the system, transform it in a use-case model, organize and manage the requirements and their priorities. It is composed of five steps: Definition of the Studied System, Determination of the Actors, Definition of the Context, Characterization of the Environment and Determination of the Use Cases. - The Analysis phase develops an understandable system structuring it in terms of components. It is composed of four steps: Domain Analysis and Study of the Architecture of the system, Adequacy of the AMAS theory, Agent Identification, Study of the Interactions between the different entities. - The Design phase is composed by four steps: Detailed Architecture and Agent model, Agent Architecture, Non Cooperative Situations model, Class Diagrams. ADELFE is supported by an internal CASE-tool called OpenTool. GAIA Gaia [Zam03] was the first methodology proposed to guide the process of developing a MAS from analysis to design; starting from Requirements Statements, it is composed of two phases [Cer04]: - The Analysis phase that create a Preliminary Roles model, a Preliminary Interactions model, an Environment model and an Organizational Rule model. - The Design phase that defines the system structure considering the organizational rules, completes the preliminary models, defines the Agent model (specifying agent types) and instances and defines the Services model. The support tool for GAIA is MASDK. MaSE (Multiagent Systems Engineering) This methodology is drawn from the legacy of object-oriented methodologies such as Rumbaugh’s
2
Object Modelling Technique (OMT) [Nwa96] and the Unified Modelling Language (UML) [Mul97]. MaSE proposes a complete life cycle methodology for MAS, it uses two languages to describe agents: the Agent Modeling Language (AgML) and the Agent Definition Language (AgDL) [Del99]. It is composed of two main phases: Analysis phase and Design phase. - The Analysis phase consists of three steps: Capturing Goals, which includes identifying and structuring goals and build a Goal Hierarchy Diagram (GHD); Applying Use Cases, that create a Sequence Diagram by capturing use case from the initial system requirements; and Refining Roles that define a Role Model by transforming the structured goals of the GHD into useful construct. - The Design phase has four steps: Creating Agent Classes, identified from component roles; Constructing Conversations; Assembling Agent Classes, where the internal of agent classes are created; and System Design, that instantiates every agent class into an actual agent, using a Deployment Diagram. The methodology is iterative: every object created during the two phases can be traced forward or backward through the different steps to other related objects [Woo00]. MaSE is supported by AgentTool. MESSAGE MESSAGE methodology extends the UML metamodel and extends/modifies it with new meta-concepts (Agent, Goal, Task …). The methodology is composed of five analysis models: Organisation model, that capture the structure of the system specifying number and types of agents and their relationships; Goal/Task model, that capture what agents do in terms of goal; Agent model, which is a description of each individual agent and role within the MAS; Domain (Information) model, that acts as a repository of information concerning domain’s problem; Interaction model, which captures the manner in which agents communicate. MESSAGE is supported by MetaEdit+. PASSI (Process for Agent Societies Specification and Implementation) PASSI is a step-by-step requirement-to-code methodology, composed of five models that include
different phases [Cos03]. It has adopted UML as the modelling language. The models are [Cos02]: - System Requirement Model, composed in terms of agency and purpose. It has four phases: Domain Description, Agent Identification, Role Identification, Task Specification; - Agent Society model, a model of the social interaction and dependences between the agents involved in the solution. It has four steps: Role Identification, Ontology Description, Role Description, Protocol Description; - Agent Implementation Model, a model of the solution architecture in terms of methods and classes. It has two steps: Agent Structure Definition and Agent Behaviour Description; - Code Model, composed of Generation of Code and Manual Completion of the Source Code; - Deployment Model, a model of the distribution of the system’s part and their migration. It has only one step, Deployment Configuration. PASSI is supported by PTK (PASSI Tool-Kit). Prometheus Prometheus methodology is composed of three design phases [Kha03]: - System Specification phase, which involves two activities: determining the system’s environment, and determining goals and functionality of the system. - Architectural Design phase, which defines agent types, the interaction between agents, and designs the system structure (System Overview diagram). - Detailed Design phase, which focuses on defining capabilities, internal events, plans and detailed data structures for each agent. Prometheus’ scenarios are a variant of the scenario part of UML’s use cases because the interaction diagrams are essentially UML sequence diagrams [Pad02]. Prometheus is supported by two tools: PDT (Prometheus Design Tool) and JDE (JACK Development Environment). Tropos Tropos methodology is intended to support all phases of software development [Bre01]: - Early requirement, concerning the understanding of a problem by studying its organizational setting. It creates an Organizational Model which includes actors, goals and their dependences; - Late requirement, where the system-to-be is described within its operational environment;
3
-
Architectural design, where the system’s global architecture is defined in term of subsystem, interconnection between data and control flows; - Detailed design, where the behaviour of each component is defined in detail; - Implementation. Tropos adopts Eric Yu’s i* model which offers the notions of actor, goal and actor dependency [Yu95]; it is supported by TAOM (Tool for Agent Oriented Modeling]) and OpenOME (Goal-oriented RE tool for the i*/Tropos methodology). We decide to not choose other OO methodologies for different reasons. For example, we did not choose Agent Modelling Technique for BDI Agents [Zha03] because it is not always seen as a methodology, but more often as a model, linked to a specific platform (BDI platform), and this is not useful to meet the platform independence requirement. Moreover, we do not consider some very specific methodologies that are not so exploited in the literature.
4. Discussion For the comparison of the methodologies we consider each evaluation criteria and discuss the features of each methodology, in order to better understand how and how much a methodology is SO. In the following explaining, we first consider the methodologies that especially focus on the given criterion, and then the others. 1- Standard language PASSI uses an XML content language for messages between agents; in fact, in the Code Production phase we can extract XML code from diagrams and use it as a content language for the messages composing the communication [Cos02]. PASSI represents the model and the code of each pattern using XML: in the case of the model, it uses the diffused XML representation of the UML diagrams while for the code it introduces some intermediate levels of representation in XML from which it obtains the final code [Cos03]. Instead, MaSE uses two different languages to describe agents and MAS: the Agent Modeling Language and the Agent Definition Language. AgML is a graphic-based language that describes the type of agents in a system and their interfaces to other agents. AgDL is based on the first order predicate logic and is used to completely describe the internal behaviour of each individual agent [Del99]. On the contrary, ADELFE uses UML notations, adopting UML’s agent-oriented extensions, and adding some specific steps to adaptive system design; it also
adopts the AUML (Agent Unified Modelling Language) formalism to model interactions between agents [Ber03]. Like ADELFE, MESSAGE uses UML and AUML notation: it extends the UML with agent knowledge level concepts, and provides graphical notations for viewing them [Ber04]; in fact, the MESSAGE modelling language extends the basic UML concepts of Class and Association with knowledge level agent centric concepts [Cai01]. GAIA uses XML to pass from the model diagram to code. It has been also proposed an interaction between Gaia and AUML to introduce its advantages to this methodology. To support the specification of agent communication and agent behaviour, in Tropos Detailed Design phase, languages such as AUML are adopted [Ber04]. Its modelling language is defined in term of UML metamodels [Giu02]. Prometheus uses only UML diagrams without any support for standard languages. As a final general remark, if a methodology does not directly use XML language, the latter can be usually implemented by the CASE-tool, especially using XML-Schema. 2- Diagram From our study emerges that every methodology uses diagrams. ADELFE permits to realize different UML/AUML diagrams. In particular, it uses UML notations, reusing UML’s agent-oriented extension, and adds some specific steps to adaptive system design. In fact, in the Late Requirement phase, in Determination of Use Cases, the main objective is to clarify the different functionalities the system must respond to and than a use case is the result of a functional requirement set. Each use case is detailed in a specific sequence diagram, a textual description and Graphical User Interface (GUI) prototypes [Ber02]. Also in MaSE Applying Use Cases phase, after creating the GHD, extracts the main scenarios from the system context and restructures them as a Sequence Diagram, similar to UML sequence diagram. First, use cases are drawn from the system requirements, then from each use case diagram, at least a sequence diagram is created [Woo00]. As said before, MaSE diagrams may look similar to OMT or UML diagrams; in fact this methodology uses a number of graphicbased models derived from standard UML models to describe the type of agents in a system and their interfaces to other agents. [Ber04] Like MaSE, in Prometheus an aspect of system specification is the use case scenarios, which describe examples of the system in operation and are a variant
4
of the scenario part of UML’s use cases [Pad02]. In the Architectural Design phase the interaction between agents are defined using interaction diagrams and interaction protocols. The notation used to do this is a simplified variant of UML sequence diagrams for interaction diagrams, and AUML for the interaction protocol [Pad04]. Prometheus describes structural overviews at various levels (system, agent, capability) with a single diagram type. In addition, diagrams are used to show data coupling and agent acquaintance relationship. Dynamic behaviour is described with existing models from UML and AUML [Ber04]. Tropos modelling language is defined in terms of UML diagrams. In the Detailed Designed phase, it uses UML activity diagrams to represent capabilities and plans at the detailed level, and also the interaction between agents in the system is represented by agent interaction diagram, that is an AUML interaction diagram. We can also consider that it also uses models from i* framework. PASSI, in the Domain Description phase of the System Requirements Model, builds a functional description of the system using conventional use-case diagrams; in the Agent Identification phase it attributes the responsibility to agents, represent them as stereotyped UML packages [Cos02]; and in the Task Specification phase, it specifies the capabilities of each agent with an activity diagram. Instead MESSAGE, like MaSE, has activity diagrams and a meta-model extending UML metamodel and therefore adding new meta-concepts (such Agent, Goal and Task) and meta-relations (e.g. Implication, Assignment, Acquaintance) to those already considered in UML. In fact the idea underneath MESSAGE is that of exploiting as much as possible the UML meta-model and extending/modifying it where necessary. The diagram extends UML Class and Activity diagrams. Also GAIA diagrams can be represented by using UML and AUML language. We noticed that the first two criteria are strictly connected, because using UML diagrams is indirectly using UML language. Finally we can say that all the considered methodologies well satisfy the second criterion. 3- Goal Tropos is strictly based on goals, in fact in the Early Requirement phase it uses the concept of goal and actor to model the stake holders in the target domain and their intentions respectively. It divides goal into two different types [Kha03]: hardgoals, which lead to functional requirements and softgoals, which relate to non-functional requirements, whose satisfaction conditions cannot be precisely defined. A goal diagram
is built, and it shows the analysis of goals and plans with regard to the specific actor who has the responsibility for achieving them. Goal and plan models allow to analyze goals and plans from the perspective of a specific actor by using three basic reasoning techniques: means-end analysis, contribution analysis, and AND/OR decomposition. For goals, means-end analysis proceeds by refining a goal into subgoals in order to identify plans, resources and softgoals that provide means for achieving the goal. Contribution analysis allows the designer to point out goals that can contribute positively or negatively in reaching the goal being analyzed. AND/OR decomposition allows for a combination of AND and OR decomposition of a root goal into sub-goals, thereby refining a goal structure. Goal models are first developed during early requirements using initiallyidentified actors and the goals, and are then depicted through goal diagrams. Goal models play an analogous role in identifying actor dependencies during Late Requirements and Architectural Design [Giu02]. Also for MaSE goals are very important, in fact in the Analysis phase there is the Capturing Goal step, which takes the initial system specification and identifies goals and structures in the system; goals are then represented in a GHD, where are organized by importance. In this methodology, a goal is always defined as a system-level objective. Lower-level constructs may inherit or be responsible for goals, but goals always have a system-level context. There are two parts of the Capturing Goal phase: identifying and structuring goals. The goals are identified by distilling the essence of the set of requirements. But once these goals have been captured and explicitly stated, they are less likely to change. Goals are then analyzed and structured into a form that can be passed on and used in the Design phase [Woo00]. MaSE has a third phase in which transform the structured goals of the GHD into a form more useful for constructing MAS: roles. The general case transformation of goals to roles is one-toone: each goal maps to a role. Goals are used in MaSE because they capture “what” the system is trying to achieve and tend to be more stable over time than functions, process, or information structures [Ber04]. Less goal-oriented than MaSE is Prometheus where, in the System Specification phase, goals and functionality in the system are determinate; in fact determining the system’s functionality is done by identifying goals, identifying functionalities that achieve these goals, and by defining the use case scenarios. The process for capturing the goals of the system begins by capturing an initial set of goals from the high-level system description. These initial goals are then developed into a more complete set of goals by considering each goal and asking how that goal
5
could be achieved [Lam01]: this identifies additional sub-goals. In addition, the set of goals is also revised when common sub-goals are identified. Goals are here represented using a goal diagram [Pad04]. In Prometheus and MaSE agents are associated to system goals, however Tropos is more goal-oriented, because both system and individual goals in addition to the contribution/decomposition of plan are described [Sud04]. Also during GAIA Analysis phase, goals of the organizations that constitute the overall system and their expected global behaviour are identified, and this step is very important to identify useful decomposition of the global organization in sub-organization [Cer04]. For MESSAGE, a goal associates an agent with a state. If a goal instance is present in the agent’s working memory, than the agent intends to bring about the state references by the goal. This is important but very different from the goal driven view of Tropos and MaSE. In the Analysis phase, the goal/task view shows a detail of the goals that the agents/roles pursue and the tasks that they perform to reach them [Ber04]. The goal view also shows how the main goals of the system are structured in sub-goals [Dar93]. Goals are not so well dealt with by ADELFE and PASSI methodologies. Considering all these criteria we can drown the graphic in Figure 2 where readers can easily have a picture of the considered methodologies, in connection with the proposed criteria; the more a methodology is near a criterion corner, the more the criterion itself is supported by the methodology. Instead, in the centre of the triangle we can find the best trade-off of the three criteria. Of course, it is not possible to select the best methodology, but developers can chose it on the base of the system requirements.
5. Conclusions and future work In this paper we have compared different agentoriented methodologies under the point of view of the development of services. In fact, services can achieve advantages from the agent main features. The assumed criteria for the evaluation are: (i) the exploitation of standard languages; (ii) the adoption of UML-like diagrams; and (iii) the support to goals definition. The positive point that emerges from our evaluation is that all considered methodologies meet the criteria in some way. As an important consideration, even if different methodologies are placed in the centre of the triangle, thus meeting all criteria, we can point out that they meet such criteria in a generic way, without providing a specific support for each criterion. We can suggest who aims at propose an agentoriented and service-oriented methodology to consider the proposed criteria since they can make the two research areas in connection. With regard to future work, we point out a couple of direction. First, since each methodology has some interesting features, we will study the chance of improving them by adding the missing or less considered features; an alternative is to extract interesting “fragments” of methodologies and put them together in a not new but composed methodology that takes the advantages of all the fragments. Then, we will evaluate how the developing tools concretely meet the criteria proposed in this paper. Of course, the tools are connected to the related methodology, but it is not a foregone conclusion that they completely follow all the criteria treated by the methodology.
References
Figure 2 Representing our criteria and surveyed methodologies
[Ber02] C. Bernon, M.-P. Gleizes, G. Picard, P. Glize, The Adelfe Methodology for an Intranet System Desig, Fourth International Bi-Conference Workshop on Agent-Oriented Information Systems at CAiSE'02, Toronto, Canada, P. Giorgini, Y. Lespérance, G. Wagner, E. Yu (Eds.), CEUR Workshop Proceedings (ISSN 1613-0073), Technical University of Aachen, May 2002. [Ber03] C. Bernon, V. Camps, M.-P. Gleizes, and G. Picard. Tools for Self-Organizing Applications Engineering, First International Workshop on Engineering Self-Organizing Applications at the AAMAS'03, G. Di Marzo Serugendo, A. Karageorgos, O.F. Rana, and F. Zambonelli, editors, - of Lecture Notes in Artificial Intelligence, Springer-Verlag, Vol. 2977, pp. 283-298, Melbourne, Australia, 2003.
6
[Ber04] F. Bergenti, M-P. Gleizes, F. Zambonelli, Methodologies and Software Engineering for Agent Systems, Kluwer Academic Publishers, 2004. [Bre01] P. Bresciani, A. Perini, , F. Giunchiglia, P. Giorgini, and J. Mylopoulos, A Knowledge Level Software Engineering Methodology for Agent Oriented Programming, Fifth International Conference on Autonomous Agents, Montreal, Canada, May 2001. [Cai01] G. Caire, P. Chainho, R. Evans, F. Garijo, J. Gomez Sanz, P. Kearney, F. Leal, P. Massonet, J. Pavon and J. Stark, Methodology for Agent Oriented Software Engineering, EURESCOM Project P907 Deliverable 3, 2001. [Cer04] L. Cernuzzi and F. Zambonelli, Experiencing AUML in the GAIA methodology, 6th International Conference on Enterprise Information Systems, pp. 283–288, Porto, Portugal, April 2004. [Cos02] M. Cossentino and C. Potts, A case tool supported methodology for the design of multi-agent systems, International Conference on Software Engineering Research and Practice, Las Vegas, USA, June 2002. [Cos03] M.Cossentino, L.Sabatucci, S.Sorace, and A.Chella, Pattern reuse in the PASSI methodology, ESAW’03, Imperial College London, UK, October 2003. [Dar93] A. Dardene, A. van Lamsweerde and S. Fickas, Goal-Directed Requirements Acquisition, Science Computer Programming, 20(1-2), pp. 3-50, 1993. [DeL99] S. DeLoach, Multiagent systems engineering: a methodology and language for designing agent systems, Agent Oriented Information Systems, May 1999. [Giu02] F. Giunchiglia, J. Mylopoulos, and A. Perini, The Tropos software development methodology: Processes, models and diagrams, in F. Giunchiglia, J. Odell, and G. Weiß, (eds.), Agent-Oriented Software Engineering III, Third International Workshop (AOSE2002), LNCS, SpringerVerlag, Bologna, Italy, July 2002. [Huh05] M. N. Huhns and M. P. Singh, Service-Oriented Computing: Key Concepts and Principles, IEEE Internet Computing, vol. 9, no. 1, pp. 75-81, January/February 2005. [Jen01] N. R. Jennings, An agent-based approach for building complex software systems, Communication of the ACM, Vol. 44, No. 4 pp. 35–41, April 2001. [Kha03] H. D. Khanh, Evaluating agent-oriented software engineering methodologies, master’s thesis, School of
Computer Science and Information Technology, RMIT University, Melbourne, Australia, 2003. [Lam01] A. van Lamsweerde, Goal-oriented requirements engineering: A guided tour, 5th IEEE International Symposium on Requirements Engineering (RE’01), pp. 249– 263, Toronto, Canada, August 2001. [Mul97] P. Muller, Instant UML, Wrox Press, Birmingham, UK, 1997. [Nwa96] H. S. Nwana, Software Agents: An Overview, Knowledge Engineering Review, Vol. 11, No. 3, pp. 205244, 1996. [Pad02] L. Padgham and M. Winikoff, Prometheus: A Pragmatic Methodology for Engineering Intelligent Agents, workshop on Agent-oriented methodologies at OOPSLA 2002, November 2002. [Pad04] L. Padgham and M. Winikoff, The Prometheus Methodology, Chapter 11 in [Ber04], pp. 217-234. [Rum91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, Object-Oriented Modeling and Design, Prentice-Hall, 1991. [Stu03] A. Sturm and O. Shehory, A Framework for Evaluating Agent-Oriented Methodologies, Workshop on Agent-Oriented Information System, Melbourne, Australia, 2003. [Sud04] J. Sudeikat, L. Braubach, A. Pokahr, and W. Lamersdorf, Evaluation of Agent-Oriented Software Methodologies: Examination of the Gap Between Modeling and Platform, Workshop on Agent-Oriented Software Engineering (AOSE), New York, USA, July, 2004. [Woo00] M. F. Wood and S. A. DeLoach, An Overview of the Multiagent Systems Engineering Methodology, First International Workshop on Agent-Oriented Software Engineering (AOSE-2000), Limerick, Ireland, June 2000. [Zam03] F. Zambonelli, N. R. Jennings and M. Wooldridge, Developing multiagent systems: the Gaia Methodology, ACM Transactions on Software Engineering and Methodology, Vol. 12, No. 3, pp. 317-370, 2003. [Zha03] T. Zhang, E. Kendall and H. Jiang, A Software Engineering Process for BDI Agent-Based Systems, IEEE/WIC International Conference on Intelligent Agent Technology (IAT03), October 2003.
7
