Vol. 2, No. 2, March–Aprile 2003
Automating the refinement of multi-agent models using an MDD approach Joaquin Pe˜ na1 Richard F. Paige2 Antonio Ruiz-Cort´ es1 Dimitrios S. Kolovos2 Luis Velasco1 University of Seville, Spain; and University of York, UK Modern software systems are increasingly complex, and their construction benefits from the use of tailored software engineering tools that support abstraction and refinement. Multiagent systems are particularly complex, and specialised methodologies and tools for their construction are becoming available. In this paper, we propose a technique for refining models of multiagent systems within the context of the MaCMAS methodology, thus providing the means to better manage complexity. The approach makes use of standard model-driven development techniques, particularly model-to-model transformation. We present automated tool support for the approach, based on an integration of ArgoUML (tailored to support MaCMAS) and the Epsilon model management framework. We focus on clarifying those parts of the methodology that benefit from automated refinement support.
1 INTRODUCTION Modern software-intensive systems are increasingly complex. Some of this is due to the increasing distributed nature of these systems. A variety of approaches have been proposed to better manage the development of modern software-intensive systems, including Model-Driven Development (MDD). Of particular interest amongst different MDD approaches is agent technology, which has been demonstrated to have substantial value for building distributed systems. Agents describe complex software components capable of acting with a certain degree of autonomy in order to accomplish tasks. Agents are described in terms of their behaviour, not in terms of methods and attributes. While the use of models has been proposed as a means to manage complexity in building software-intensive systems, it has been realised that the process in which models are used also plays a substantial role. A traditional process model in software engineering is top-down refinement. In this approach, abstract models are created and successively refined with additional details, until models are Cite this document as follows: http://www.jot.fm/general/JOT template LaTeX.tgz
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
available that contain sufficient detail to allow implementation. This approach is widely used in MDD, and particularly in the Model-Driven Architecture (MDA) [1], which supports refinement through modelling, model-to-model transformations, and serialisations. While MDD approaches for building distributed systems using agents have been proposed, limited work has been done on supporting refinement in the context of MDD using agents. To the best of our knowledge, the only approach for this is [2], where authors describe an set of algorithms to transform models. However, this approach is not automated. As such, it makes it more difficult to make use of standard software engineering techniques – such as decomposition, composition/merging of models, and reuse – for building agent-based systems. There are thus substantial benefits to be obtained by using standard MDD languages, which support refinement, for building systems using agents. This paper therefore proposes an approach that integrates an agent-oriented software engineering methodology, called MaCMAS, with an MDD approach, for building multi-agent systems (MAS). The methodology has been presented previously [2], but in this paper we focus on the transformations and automated tool support. In more concrete terms, we propose transformations that helps to refine abstract, platform independent models (PIMs). This is a process of elaboration, or (as we discuss in the next section) horizontal refinement, since we do not add platformspecific details in this refinement process. The transformations are semi-automatic and are implemented in a standards-compliant MDA toolset called Epsilon [3], thus providing the links between MaCMAS and MDA. We present an implementation of the integration between MaCMAS and Epsilon in the CASE tool ArgoUML. The rest of the paper is structured as follows. We provide a brief overview of related work on refinement in MDD, and then outline the MaCMAS methodology, highlighting how refinement is currently carried out within it. We explain how we can implement the refinement process using Epsilon’s concrete languages and the ArgoUML CASE tool. Elements of a case study are briefly touched on to contextualise the approach.
2 RELATED WORK AND MOTIVATION Model refinement is the process of transforming (abstract) models into (concrete) models so that a set of properties (e.g., consistency) is maintained. The notion of refinement is used in several approaches to MDD, both as a modelling concept (e.g., refinement relationships in UML 2.0 [4]) and as parts of an MDD process (e.g., the notion of transformation in MDA). Refinement can be vertical, between levels of abstraction – which is what is typically seen when applying transformations in MDA – and horizontal, wherein a model is refined in-place, and the level of abstraction is maintained. An example of the latter is where we refine a PIM to an alternative PIM, e.g., capturing a new configuration of a system. We focus on horizontal refinements, 2
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
2 RELATED WORK AND MOTIVATION
particularly refining a PIM to a new PIM, in this paper. In MDA there is a strong relationship between refinement and transformation; transformation languages are a general-purpose mechanism for supporting and implementing refinement. A large number of task specific languages for mapping transformations have been proposed including QVT [5], ATL [6] and EOL. QVT is an OMG standard, whereas the other technologies are supported within Eclipse (though EOL and its related languages [7] support metamodelling infrastructure other than EMF). These languages can support both vertical and horizontal refinement. A specialised language, called EWL [8], has also been developed to support update transformations, which are a specialised form of horizontal refinement that requires user input, e.g., from a CASE tool. We chose to use EOL to implement support for the refinements in this paper, for several reasons. EOL supports both declarative and operational styles for transformation rules, and we have found that being able to mix styles can lead to easier-to-read transformations. EOL supports transformations on both EMF and MDR models, but has actually been designed to be metamodel-agnostic and technology independent. In this manner, it is relatively straightforward to provide EOL support within non-Eclipse tools, such as ArgoUML. This is particularly important in this paper as tool support for MaCMAS already exists in ArgoUML. Refinements can be supported by model transformations. A key aspect of this is identifying typical refinement rules, which are implemented by transformation rules, and providing support for applying these rules, either within a development process or a tool. Examples of the former appear within the KobrA [9] methodology for building product-lines using UML. The KobrA process provides a selection of pattern-based transformations for both horizontal and vertical refinements. KobrA was focused specifically on UML and product-line development, not multi-agent systems, and did not specifically address automated transformations. While transformations are useful to support and implement refinement, it has been noticed by Wagelaar [10] that it is essential to include context-dependent details in transformation rules when supporting a model refinement process. Wagelaar introduces a general notion of context-driven model refinement, where contextual constraints annotate transformation rules. He presents a framework for automatically selecting applicable transformation rules for specific concrete contexts. The notion of context constraint is important in the approach presented in this paper. Because we work in a specific domain (multi-agent systems), contextual information is not represented explicitly as constraints on transformations, but as additional domain knowledge captured in resources and dependency models. However, the distinction made by Wagelaar is extremely useful in clarifying what refinements in MaCMAS are meant to do. An alternative approach to MDA refinement is presented in [11], in terms of consistency checking. In such an approach, refinements can be constructed manually, or automatically, and the preservation of properties is checked post facto, by checking consistency rules written in, e.g., OCL 2.0. This approach is more general VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
3
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
Focus of this paper
Requirements
Macro-Level
Abst. Layer 2 Abst. Layer 3
Decomp./ Ref.
… reuse
traceability
abstraction Micro-Level
reuse
Abst. Layer 1 Comp./ Abst.
Abst. Layer n-1 Abst. Layer n
Requirements
Figure 1: Process Overview than the one we use in this paper, and in fact may be useful to supplement the refinement process presented herein, particularly to capture refinement steps that may be challenging to express using transformation rules. However, we leave this for future work.
3 CASE STUDY We now illustrate parts of the refinement process of MaCMAS by example, using a case study that was proposed for evaluating how agent-oriented methodologies represent aspects of interaction. The problem to be solved is based on representing, and refining, the UN Security Council’s procedures to Issue Resolutions1 ; we consider a simplification in this paper. The UN Security Council (UN-SC) consists of a number of members, which can submit a new proposal of resolution that has to be voted by all the members of UN in order to be accepted/rejected. In order to exemplify our approach we focus on the votation process. It consist on given a vote for a particular resolution. As the vote is public, all the members has to be informed of it. Finally, the chair of UN must monitorize the votes.
4 ENGINEERING MULTIAGENT SYSTEMS WITH MACMAS MaCMAS is a methodology for engineering complex multiagent systems that is focused in the coordination aspect. It has been applied in the domains of autonomic computing [12], software product lines [13, 14] and evolving systems [15] in order to model complex distributed systems composed of agents. 1
The original version of the problem is available at http://www.auml.org/auml/documents/ UN-Case-Study-030322.doc 4
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
4 ENGINEERING MULTIAGENT SYSTEMS WITH MACMAS
An abstract overview of the MaCMAS process is in Figure 1. The coordination models of a system are structured into a set of abstraction layers, with the top layer presenting abstract models, with successive refinements appearing in successive layers. In order to build subsequent layers, MaCMAS provides a set of vertical and horizontal transformations. Vertical transformations are applied to split models or to compose models, while horizontal transformations are used to refine and abstract from models in order to address bottom-up and top-down development. In horizontal transformations, two kinds of refinements are supported and used in MaCMAS. The first type focuses on refining models given the requirement information in form of hierarchies of system goals. The second kind of refinement – and the focus of this paper – is based on analysing model element dependencies to recommend refinements. This particular kind of refinement was first presented in the context of MaCMAS in [2, 16], without a UML profile, nor tool support. In this paper we provide an implementation of this kind of refinement, using a UML 2.0 profile, with MDD-based tool support. System Goal Static Acquaintance Organisation Model
Role Model
1.. * +initiator
1.. participates in * +responder
Role
1
1.. *
1
+multiplicity
1.. *
0.. * 0.. *
Multi-Role Interaction
Role 1.. *
1
participates
1.. *
1.. *
is internally defined by
^ fulfil *
Multi-Role Interaction
is constrained by 1
*
*
* *
manage
Instantiation Rule
1
* 1
1 follows
Knowledge entity
*
+in knowledge
* *
+out knowledge
1
Coordination Type
fulfils
+mRI data
1.. *
1.. +Communication Ontology * < defines knowledge
A) Role model metamodel
1.. *
participates in
Sequence Diagram
0.. *
*
1.. *
represents ^
Optional
1.. *
Ontology
1
Postcondition
B) Multi-Role interaction metamodel
Figure 2: Role Model metamodel and mRI metamodel Metamodel element Stereotype mRI > System goal > instantiation rule > postcondition > Knowledge entity >
Uml Base Class Collaboration Class Precondition Postcondition Attribute
Tags coordType String NT NT NT NT
Table 1: UML 2.0 Profile extensions for mRIs From all the model proposed in MaCMAS, we present here only such directly related with refinements: role models, knowledge dependency models, role model plans. The models in MaCMAS are defined using metamodels since this is crucial to follow an MDD approach. The mapping of metamodel constructs to concrete VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
5
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
Goal
Role Goal
System Goal
* 1.. *
* 1
partially fulfils
^ fulfils
^ achieves
< achieves
1
^ achieves
+initiator *
1 1 *
participates in 1.. *
*
1
*
Multi-Role Interaction
Role
Interface
Service
1.. *
+multiplicity 1.. * participates in +responder
* 1.. *
1
Role Model
1 1.. *
Knowledge Entity
1
+Communication Ontology
Ontology Passive Role
Environmental Role 1
*
defined in
Figure 3: Role metamodel Metamodel element Stereotype Role > Passive Role > EnvironmentalRole > Role goal > Role Interface >
Uml Base Class CollaborationRole > > Class Interface
Tags multiplicity NT NT NT NT
Table 2: UML 2.0 Profile extensions for roles UML elements are summarised in tabular form, following the style for describing profiles proposed by the OMG. A Role Model shows the coordination aspect of a a sub organization of agents, represented with their roles, collaborating by means of several multi-role interactions (mRIs). As mRIs allow abstract representation of interactions, we can use these models at whatever level of abstraction we desire. In Figure 2.a) we present the metamodel for the Role Model. The mRI metamodel is presented in Figure 2.b), and its profile in Table 1. An mRI represents an interaction between several roles that coordinate to fulfill a system goal. The Instantiation Rule represents constraints over the set of components that can play roles in the model. Postcondition represents the condition that must hold after the execution of the corresponding mRI. Knowledge In and Out elements represent the knowledge consumed and produced by an mRI. The Role metamodel is presented in Figure 3, and its profile in Table 2. We omit a detailed description of its elements due to space constraints. In Figure 4, 6
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
4 ENGINEERING MULTIAGENT SYSTEMS WITH MACMAS
! "# $ % & ' ( ) * + , - - , . / + 0 + 1 , + - , 2 2 1 3 4 5 6 7 0 - z { | } ~
: ; ; ; 9 * + %% # ) # $ ( ) ! %% < C 4 + > + ? "# $ % & ' ( ) < -- , %% # ) # $ ( ) ! %% . C 4 + > + ? "# $ %& ' ( ) . - - , = > ? + < + % % # ) # $ ( ) ! % % C 4 + > + ? " # $ %& ' ( ) -
z
X i W W Q O Tc S T Q k c S T Q _R k UYT c S TQ Y _j k UYT M Q j ` Q W Y NTQ k NTQ
D E FG
I K \ H I J K L Q UO S W j Q S N R S TQ I [ \ H I J K L Q UO S W j Q S N R S TQ
H I JK L M NO NP Q R S TUO P V W S X Q YY
Z J[ [ \] ^ L XS __N` S W NTUS O a^ L b c S T Q W de f g e
_ R k U Y T c S T Q Y
h J[ JL l m [L O i j c S T Q Y k UO T n o p q r f stu n v w x y f u y f stu
8 9:; < ! " # $ %& ' ( ) * + < + - , = > ? + < + < ! "# $ %& ' ( ) * + < + - , / * + ? 1 / * + ? @ 2 + A A B / * + ? 1 C 4 ! . / -- 2 2 1 3 4 5 6 7 0
I K \ H I J K L M NO NP Q R S TUO P V W S XQ YY I [ \ H I J K L M NO NP Q R S TUO P V W S XQ YY
z
I K \ H I J K L c S TQ S W NP NUO YT N V W S V S YN_ I [ \ H I J K L c S TQ S W NP NUO YT N V W S V S YN_
V W S V k WS V S YN_ U k M Q j ` Q W R S TQ k c S TQ
Figure 4: Role model for vote ¡ ¢£ ¤ ¥ £ ¤
ª « ¬£ ¤
¦ § ¨ ©¤
®
·¸ °°³¹ ²º ±²³
® ±²³
¯ °±¯
´µ
®
µ »²³
¶
Figure 5: Knowledge dependency model for mRI vote we present the role model for the voting process of our case study. Boxes represent roles and the ellipse represents an mRI. A Resource dependency model provides ways to document the dependencies between the knowledge produced/consumed by each role and the services provided in the context of an mRI. In Figure 5, we show the resources dependency model for the mRI vote. The behavioral aspect of an organization of agents shows the sequencing of mRIs in a particular role model. A Role Model Plan represents the ordering of mRIs in a role model with a centralized description. A role plan represents the partial view of the role model plan affecting a role. In this paper, we show only how to work with role model plans. In Figure 6, we present role model plans and role plans metamodels with profile presented in Table 3. Role model plans are based on UML Protocol State Machines, VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
7
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
Role Model Plan
Role Plan *
1
Role Model
1
1
State Machine
1
Role State Machine
1
has 1
1.. *
1 +outgoing
1
+source *
Multi-Role Interaction
1
*
1
1..*
Role Multi-Role Interaction
Role State 1..*
Final State
1..* 1.. *
1..*
+target *
Initial State
Precondition 1
Guard participates in
*
Whole State
1 +incoming
1
1
1
1 1
Role
< has 1..*
*
1
1
Role Initial State
Role Final State
1..*
1..*
Figure 6: Behaviour metamodel Metamodel element Stereotype Role State > Whole State > Role mRI > mRI > Guard >
Uml Base Class Tags State NT State NT Transition NT Transition NT Guard NT
Table 3: UML 2.0 Profile extensions for Behaviour Metamodel and Role Plans are based on UML State Machines. As shown, both models represent the sequencing of mRIs: the former in the context of a role model, and the later in the context of a role.
5 AUTOMATING REFINEMENT IN MACMAS The previous section described MaCMAS. In this section, we focus on refinement in MaCMAS, particularly on the automated tool support that we provide. Different refinement techniques have been implemented using the Epsilon framework, and we explain how these support the overall MaCMAS refinement process. The overall MaCMAS process was illustrated in Figure 1. The key part of this process in which refinement is important is in establishing and refining a goal hierarchy. In this phase, mRIs are refined using a process show in Figure 7. In particular, the mRI is refined via decomposing dependencies. The process in Figure 1 is approximately as follows. The determine feasible decomposition task consists of modelling a knowledge dependency model for the mRI that must be refined, and analyses the graph searching subgraphs. Later, in 8
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
5 AUTOMATING REFINEMENT IN MACMAS
¼ ½ ¾ ¿ ÀÁ½  ½ Ã Ä Å Ð Í ÇÉ Æ Ä Ç Ä ½  ½ Ã Ä Ñ À½ Á Ç Á Ì Ò Ó
Û Ì¾ × Ô ÁÙ × Ï ÍʽÉ
¼ ½ ÅÍ ¿ Á̽ Å Ë ½Î× Ï ÍÊ½É Ó½Å
Ë ½ Ä ½ Á  Àà À à ٠ֽ Ç ÅÀÕ É½ ʽÌÍ Π×
Ü ½ Ç ÅÀÕ É½ Ê ½ Ì Í Â Î Í ÅÀÄÀÍ Ã Å
Æ ½ ɽ Ì Ä Ê½ÌÍ Π×
Æ ½ ɽ Ì Ä½ Ê Ë ½ÌÍ Π×
È ¿ ÀÉÊ Ô Õ Ä Ç ÀÃ Í Á Ê ½ Á Í Ö Ë ½ Ì Í Â Î Í Å½ Ê Ê ½ÌÍÂ Î × Â ¼ ØÅ ¼ Í É½ Ï Í Ê ½ É
¼ Í É½ Ï Í Ê ½ É
Û Ý Ç ÀÉ Ç Õ É½ Ž ¾ ¿ ½ Ã Ì ½ Å Ê ½ Ľ Ì Ä½ Ê
È ¿ ÀÉÊ ¼ Í É½ Ï Í Ê ½ É Ú ÉÇÃ
¼ Í É½ Ï Í Ê ½ É Ú ÉÇ Ã
ÃÍ Ë ½ Ľ Ì Ä Ê ½ Ç Ê ÉÍ Ì Þ Å
Ë ½ Ç Ê ÉÍ Ì Þ Åà
Ë ½ Ç Ê ÉÍ Ì Þ Æ ÄÇĽ Å
ß Í Â Î Í Å½ Û Ì¾ × Ô ÁÙ × Ï ÍʽÉ
Û Ì¾ × Ô ÁÙ × Ï ÍʽÉ
Figure 7: Refinement of mRI via dependency decomposition build decomposed role model each subgraph is used to build a refined mRI. Finally, we analyse the underlying graph for ordering the refined mRIs and build a refined role model plan. Thus, in a nutshell, the process identifies, then refines one mRI of a Role Model. Some of these steps from Figure 7 can be automated, namely determine feasible decomposition, build decomposed role model, and build role model plan which are described in this section. The step detect deadlocks can also be partly automated, but this is described elsewhere [2].
Determine feasible decompositions The first stage in the process of Figure 7 is to determine feasible decompositions of a resources model of an mRI. A resources model is effectively a directed acyclic graph. Informally, this phase of the refinement process consists of finding sub-graphs in the resources model of an mRI. Later, these sub-graphs can be used to produce a refined mRI. For example, as shown in the example of Figure 10, analysing the resource dependency model of the mRI vote, we should be able to identify the sub-graph in the rounded rectangle; thereafter, we should be able to use this sub-graph to produce a new mRI that only manages the resources in the sub-graph. This kind of refinement is based on using simple structural properties of graphs to obtain sub-graphs. To provide automated tool support, we require languages and tools that allow us to navigate graph structures and define structural properties. The Epsilon Object Language [3] provides metamodel-agnostic model navigation and modification capabilities, and is computationally complete – it is an appropriVOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
9
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
ate candidate. As well, its plug-in architecture makes it feasible to integrate with different CASE tools, e.g., ArgoUML. Thus, we make use of EOL to capture the refinement rules that are inherent in MaCMAS. We now illustrate the determine feasible decompositions phase of refinement with two examples, showing two different ways in which sub-graphs can be identified and mRI’s later refined. The two variants are called splitting and decoupling at the dependency level, and are based on [17, 18, 2]. Other variants are of course possible. We show how we have implemented these variants using EOL.
Splitting The splitting refinement transforms a certain mRI into a set of mRIs where the knowledge exchanged between participants is processed separately. We can apply this refinement when we can identify several unconnected dependency graphs in an mRI. Since no dependency exists between these graphs, each of them can be isolated into a new refined mRI. Formally, each component in a dependency graph represents a new refined mRI. This process can be implemented in EOL as shown in Figure 8. var resourceSet: new Set(Uml!Class); resourceSet:=model.getAllResources(); var subgraphsSet: new Set(Uml!Package); while (resourceSet.size()>0){ var subgraph: new Uml!Package; var reachableResources: new Set(Uml!Class); var r: Uml!Class; r:=resourceSet.at(0); -- gets one random element of the set -- Next will get all the resources connected with r resourceSet.remove(r); subgraph.add(model.getRole(r)); for ( iterator in resourceSet){ if(r.isReachable(iterator)){ subgraph.includeInPackage(model.getRole(iterator)); reachableResources.add(iterator); } } resourceSet.removeAll(reachableResources); -- remove the used resources subgraphsSet.add(subgraph); }
Figure 8: EOL implementation of the splitting refinement
The EOL program works by generating all resources in a model, and then identifying subgraphs (contained in subgraphsSet). Subgraphs are identified through a straightforward component connectivity algorithm. By using the function isReachable we can check if two resources are connected (directly or through another resources). The key idea is to maintain a set with the used resources in resourceSet, so that we consider them exactly once in the process of constructing subgraphs. 10
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
5 AUTOMATING REFINEMENT IN MACMAS
Decoupling at the dependency level The second kind of refinement at this stage of the process is to carry out decoupling at the dependency level. Although, we can accomplish many refinements by the refinement technique shown previously, we do not achieve bi-partite granularity, since a knowledge entity may depend on knowledge from n roles, thus obtaining mRIs with n + 1 participant roles. In such situations, more fine-grained refinement could be achieved if we encapsulated each dependency itself into an mRI. We call this refinement decoupling at the dependency level. This is the most powerful refinement technique of all presented in MaCMAS, since the technique always produces a set of bi-partite mRIs. If a knowledge dependency involves several roles, we add one mRI for each arc and a knowledge entity in the role where the knowledge is calculated. Finally, we add an single-party mRI in order to calculate the new knowledge. The EOL implementation of this refinement is shown in Figure 5. var subgraphsSet: new Set(Uml!Package); for ( iterator in model.getAllDependencies()){ var subgraph: new Uml!Package; var resource1: new Uml!Class; var resource2: new Uml!Class; resource1:=iterator.connection.at(0).participant; resource2:=iterator.connection.at(1).participant; subgraph.includeInPackage(model.getRole(resource1),model.getRole(resource2)); subgraphsSet.add(subgraph); }
Figure 9: EOL implementation of decoupling at the dependency level The EOL program operates as follows. As discussed previously, we need to analyze all the dependencies between pairs of resources. This can be done by iterating over the set of dependencies in the current model. For each dependency, we create a UML package to encapsulate the subgraph composed by the two roles containing the resources. Finally we add the package into a set for later analysis. If we apply the EOL implementation of Figure 5 to the mRI vote in Figure 10, we obtain the sub-graphs shown in dashed rectangles in Figure 10. Each subgraph represents a refined mRI. As can be seen, we have assigned an mRI identifier to each subgraph. Participant elimination and Decoupling by knowledge grouping Additional refinement techniques are useful within MaCMAS. Two additional techniques are participant elimination, and decoupling by knowledge grouping. The former eliminates participants that do not consume or produce knowledge in an mRI. The latter is similar to decoupling at the dependency level but it groups each knowledge entity together with what it is connected. Future work will investigate automating these techniques. VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
11
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
ü ýþ ÿ ê ãí å êâ í ä æ ì í ä
ü ýþ ãä ÿ æ ì íä
ë ì íäå
á â ãä å æ ä å
ü ýþ ãíì å ä æ ì íä
ç è é êå
îï
øù ñ ñ ôú óû ò ó ô
ï òóô
îï
ð ñòð
öóô
õö
ü ý þ ÿ ä ê ÿ ä æ ì íä
î÷
ü ýþ êÿ ä íê ü ä ü â ä å
Figure 10: Subgraphs obtained by decoupling at dependency level for mRI vote
Build decomposed role model The refinement techniques in the previous section produce sub-graphs. The next stage in MaCMAS is to build a role model per sub-graph, or produce a complete role model, which will replace the initial mRI with refined ones. In Figure 7 this step is called build decomposed role model. Only parts of this step can be automated, in part because the mRI must be linked with system goals and user requirements at this stage, and this must be done manually. EOL support for this step has been produced, but because it supports only a small part of the step, we omit it and concentrate on the next refinement technique, which benefits from more substantial automated tool support.
Build Role Model Plan A critical step of the refinement process in Figure 7 is building a role model plan. Prior to this step we have built a decomposed role model and have constructed an ordering for decomposed mRIs. There are side-effects to refining mRIs. When a new role model is drawn for each refined mRI, we do not have to provide plan models, since all role models use a single mRI. However, if we apply the refinement to the initial role model, we have to modify the plans. Once we have divided an mRI into a set of simpler ones, we have to sequence them. When we apply splitting or participant elimination, the new order is obtained easily. In splitting, because refined mRIs do not share resources, they can be executed in any order so that the designer has to decide which the new plan model is. In participant elimination, we can keep the plan models without modification. 12
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
5 AUTOMATING REFINEMENT IN MACMAS
In the rest of the refinement, we can determine all the possible orders of execution automatically as follows. We start from the topological sort algorithm, which sorts the vertexes in the resources model [19]. The first element of a sequence of resources obtained by this algorithm is the last to be calculated, and the last element of the sequence is the first element to be calculated. This algorithm produces several valid sequences of resources. However, as we intend to get the available orders of refined mRIs, we have to process all sequences produced by the topological sort to transform them into the equivalent set of sequences of mRIs. var resourceSet: new Set(Uml!Class); var associationSet: new Set(Uml!Association); var orderedSequences: new Set(Sequence(Uml!Class)); associationSet:=model.getAllAssociations(); resourceSet:=model.getAllResources(); while (resourceSet.size()>=0) { finalNodes := resourceSet.getNodesWithNoOutcoming(); orderedSequences.addInAllPossibleWays(finalNodes); resourceSet.remove(finalNodes); for ( iterator in associationSet) { if ( iterator.hasNoFinalNode()) { associationSet.remove(iterator); } } } convertToRoleModelPlan(orderedSequences)
Figure 11: EOL implementation for building the plan of the refined model In Figure 11, we show the EOL implementation of this algorithm. As shown, this code returns all the possible order of executions of mRIs in form of a Sequence of Sequences. The result of this, orderedSequences is then transformed into a role model plan using the function convertT oRoleM odelP lan. This function uses well known algorithms from the graph theory field [20], and from the automata and languages theory field [21]. For example, conversion of a set of words to a regular expression, conversion from a regular expression to a finite state machine (FSA), and so on. To get the sequences of sequences of mRIs, it analyses each resource and adds the mRIs that can be completely calculated. An mRI can be added when all the dependencies that we find in a resource point to resources that precede it in the sequence and this resource is the last to be calculated by one of the refined mRIs. This means, that at this point, all the resources needed to resolve it are already available. This is the reason why we reverse the sequences produced by the topological sort before applying this function. Notice that in subgraphs obtained using decomposition by knowledge grouping and decomposition at dependency level, we can always find a resource that is the last to be calculated/used, that is to say, it does not have clients in the same subgraph VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
13
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
T ((res ∈ ref inedDM ) ∧ ((res.client ref inedDM.resources = ∅))). When we find a resource that fulfills these requirements and those exposed previously, we can say that the refined mRIs that contain this resource has been terminated, and thus, we can include its mRIs in all the possible sequences of mRIs already calculated using the sequence of resources. Finally, by this transformation we obtain a set of sequences of mRIs which can be used to build automatically a state machine. This is done by taking all of them and producing the finite state machine (FSA) that recognises the language that contains all these words [21]. This state machine can be modelled in form of sub-state machine and included in the role model plan by replacing the initial mRI transitions with this substate machine. In addition, the transitions of the initial mRI can be directly replaced by the plan of the refined mRIs. The obtained role model plan has to be analysed by engineers to optimise it by parallelising mRIs that can be executed in parallel or to delete undesired traces of execution. Now we show how to obtain the role model plan for our case study. Applying the algorithm presented in Figure 11 to the resources dependency model of the vote role model, we can obtain all the sequences produced by the topological sort of the resources dependency model of the mRI vote. Two of these these sequences and their transformation into mRI sequences are (notice that we have reversed the results of the topological sort to show the example):
1. . Which produces the mRI sequence: . 2. . Which produces the mRI sequence: . Notice that in this result of topological sort it only changes IObserver.lv and IChair.lv that have been exchanged.
If we obtain all sequence produced by the topological sort, we can see that identify member mRI can be executed in any order and that, as shown before, Distribute Vote and Store Vote can be executed in any order. Given these results, we can obtain the role model plan that considers all the mRI orders. This must be analysed to delete any path that we consider not adequate. The role model plan after deleting the path that we have considered not adequate is the following: 14
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
7 CONCLUSIONS AND FUTURE WORK
! " # $
% $
% $
Figure 12: Role model plan for refined mRI vote
6 IMPLEMENTATION In order to provide tool-support for the refinement techniques discussed above, we have implemented an extension to the version of ArgoUML that supports the extended UML metamodel discussed above. This extension introduces new types of diagrams in which the graphical representations of UML elements have been adapted to fit the MaCMAS requirements. Moreover, to implement automated refinements, we have developed a further extension to ArgoUML that enables users to compose and execute endogenous EOL transformations on the currently edited model. This extension consists of a panel where the user can manage (create, update, delete) and execute EOL templates on the currently selected model elements, and a console, where messages, either specified by the user or resulting from runtime-errors, are emitted. To enable users specify modular transformations, templates can pass parameters and invoke one another programmatically. This allows users to realize complex refinements in a structured manner. In Figure 6, we show an screenshot of the tool, and in james.eii.us.es/MaCMAS/ demos/ a video showing the example of this paper can be found and a complete version of the case study.
7 CONCLUSIONS AND FUTURE WORK In this paper, we have presented which, by the best of our knowledge, is the first approach to refine PIM models of multiagent systems to obtain more detailed models also at the PIM level following an MDD approach. In addition, we presented the VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
15
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
tool support for modelling following the MaCMAS methodology and a plugin for implementing the MDD transformations needed for refinements.
8 THANKS We would like to thanks all the people that participated and are participating in the development and implementation of the CASE tool. Specially to Francico Gonzalez Guill´en, Agust´ın Mar´ın Ortega, and Christian L´opez Esp´ınola.
References [1] Object Management Group. Model Driven Architecture, official web-site. [2] J. Pe˜ na, R. Corchuelo, and J. L. Arjona. A top down approach for mas protocol descriptions. In ACM Symposium on Applied Computing SAC’03, pages 45–49, Melbourne, Florida, USA, 2003. ACM Press. [3] Dimitrios S. Kolovos, Richard F.Paige and Fiona A.C. Polack. The Epsilon Object Language. In Proc. European Conference in Model Driven Architecture (EC-MDA) 2006, volume 4066 of LNCS, pages 128–142, Bilbao, Spain, July 2006. [4] Object Management Group (OMG). Unified modeling language: Superstructure. version 2.0. Final adopted specification ptc/03–08–02, OMG, August 2003. www.omg.org. 16
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
8 THANKS
[5] Object Management Group. MOF QVT Final Adopted Specification. http://www.omg.org/cgi-bin/doc?ptc/05-11-01.pdf. [6] Atlas Transformation Language, official web-site. http://www.sciences.univnantes.fr/lina/atl/. [7] Dimitrios S. Kolovos, Richard F. Paige and Fiona A.C. Polack. Merging Models with the Epsilon Merging Language (EML). In Proc. ACM/IEEE 9th International Conference on Model Driven Engineering Languages and Systems (Models/UML 2006), Genova, Italy, October 2006. LNCS 4199. [8] Update Transformations in the Small with the Epsilon Wizard Language. [9] C. Atkinson, J. Bayer, and et al. Component-Based Product Line Engineering with UML. Addison-Wesley, 2001. [10] D. Wagelaar. Context-driven model refinement. LNCS, 3599:189–203, 2004. [11] Richard F. Paige, Dimitrios S. Kolovos and Fiona A.C. Polack. Refinement via Consistency Checking in MDA. In Refinement Workshop 2005. Elsevier Science B. V., 2005. [12] Joaquin Pena, Michael G. Hinchey, and Roy Sterritt. Towards modeling, specifying and deploying policies in autonomous and autonomic systems using an aose methodology. In EASE ’06: Proceedings of the Third IEEE International Workshop on Engineering of Autonomic and Autonomous Systems (EASE’06), pages 37–46, Washington, DC, USA, 2006. IEEE Computer Society. [13] J. Pe˜ na and M. G. Hinchey. Multiagent system product lines: Challenges and benefits. Communications of the ACM, 49(12), December 2006. [14] J. Pe˜ na, M. G. Hinchey, and P. Trinidad A. Ruiz-Cort´es. Building the core architecture of a nasa multiagent system product line. In 7th International Workshop on Agent Oriented Software Engineering 2006, page to be published, Hakodate, Japan, May, 2006. LNCS. [15] J. Pe˜ na, M. G. Hinchey, Manuel Resinas, R. Sterritt, and J. L. Rash. Designing and managing evolving systems using a mas-product-line approach. Journal of Science of Computer Programming, 2006. [16] J. Pe˜ na, R. Corchuelo, and A. Ruiz-Cort´es. A Top-Down Approach for Describin the Acquaintance Organization of Multiagent Systems. Journal of Scalable Computing: Practice and Experience, 8(1):to appear, 2007. [17] R. Corchuelo. Prototyping Distributed Systems Constraints–Based Specifications Using TESORO (Prototipado de Especificaciones de Sistemas Distribuidos Basadas en Retricciones. Aplicaci´on al Lenguaje TESORO). PhD thesis, Facultad de Inform´atica y Estad´ıstica. Dpto. de Lenguajes y Sistemas Inform´aticos. Universidad de Sevilla, 1999. VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
17
AUTOMATING THE REFINEMENT OF MULTI-AGENT MODELS USING AN MDD APPROACH
[18] N. Francez and I. R. Forman. Interacting Processes. Addison–Wesley, 1996. [19] N. Wirth. Algorithms + Data Structures = Programs. Prentice–Hall, 1976. [20] N. Christofides. Graph theory: an algorithmic approach. Acad.Press, 1975. [21] J.E. Hopcroft and J.D. Ullman. Introduction to Automata Theory, Languages, and Computation. Addison–Wesley, 1979.
ABOUT THE AUTHORS
Joaquin Pena is a Lecturer at the Department of Computer Science and Languages at University of Seville, Spain. He can be reached at
[email protected].
Richard F. Paige is a Lecturer at the Department of Computer Science at The University of York, United Kingdom. He can be reached at
[email protected]. See also http://wwwusers.cs.york.ac.uk/∼paige.
Antonio Ruiz-Cort´ es is a Lecturer at the Department of Computer Science and Languages at University of Seville, Spain. He can be reached at
[email protected].
Dimitrios S. Kolovos is a PhD student and research associate at the Department of Computer Scinece at The University of York, United Kingdom. He can be reached at
[email protected]. See also http://www-users.cs.york.ac.uk/∼dkolovos.
18
JOURNAL OF OBJECT TECHNOLOGY
VOL 2, NO. 2
8 THANKS
Luis Velasco is a a PhD student at the Department of Computer Science and Languages at University of Seville, Spain. He can be reached at
[email protected].
VOL 2, NO. 2
JOURNAL OF OBJECT TECHNOLOGY
19
