MAS Meta-models on Test:
UML vs.OPM in the SODA Ca Study
Ambra Molesini1Enrico Denti1Andrea Omicini2
1DEIS,Alma Mater Studiorum,Universit`a di Bologna
Viale Risorgimento2,40136Bologna,Italy
amolesini@deis.unibo.it,enrico.denti@unibo.it
2DEIS,Alma Mater Studiorum,Universit`a di Bologna a Cena
Via Venezia52,47023Cena,Italy
二月份的英文Abstract In the AOSE(Agent-Oriented Software Engineering)area,
veral rearch efforts are underway to develop appropriate meta-models
for agent-oriented methodologies.Meta-models are meant to check and
verify the completeness and expressiveness of methodologies.
家里发现白蚁
屏幕解锁In this paper,we put to test the well-established standard Unified Mod-
elling Language(UML),and the emergent Object Process Methodology
(OPM),and compare their meta-modelling power.Both UML and OPM
are ud to express the meta-model of SODA,an agent-oriented method-
ology which stress interaction and social aspects of MASs(multi-agent
systems).Meta-modelling SODA allows us to evaluate the effectiveness of
the two approaches over both the structural and dynamics parts.Further-
more,this allow us tofind out some desirable features that any effective
approach to meta-modelling MAS methodologies should exhibit.
1Meta-models for MAS
The definition of a methodology is an interactive process,in which a core is defined and then extended to include all the needed concepts.Meta-modelling enables checking and verifying the completeness and expressiveness of a meth-odology by understanding its deep mantics,as well as the relationships among concepts in different languages or methods[1].According to[2], the process of designing a system(object or agent-oriented)consists of instantiating the system meta-model that the designers have in their mind in order to fulfil the specific problem requirements.In the agent world this means that the meta-model is the critical element(...)becau of the variety of methodology meta-models.
In the context of MASs,a meta-model should be a structural reprentation of the elements(agents,roles,behaviour,ontology,...)that constitute the actual system,along with their composing relationships.Several meta-models of AOSE methodologies can be found in the literature—for instance,GAIA[2],PASSI[2], ADELFE[2],Tropos[3],MESSAGE[4],IGENIAS[5].Although a number of
字笑
the(PASSI,MESSAGE,ADELFE)adopt some kind of UML extensions to express system models,w
hile others(GAIA,TROPOS,IGENIAS)adopt some ad-hoc symbology for the same purpo,the meta-models of all such methodo-logies are still expresd in UML.
1.1Why UML for Meta-models
The Unified Modeling Language(UML)[6]is the industry-standard language for specifying,visualising,constructing,and documenting the artifacts of software systems.Like other methods,UML is bad on the decomposition principle,here in the form of aspect decomposition.A system is then expresd as a multiplicity of different models,each reprenting a specific system aspect:actually,UML defines12types of diagrams,who4reprent the static application structure, 5are devoted to capture the system’s dynamic behaviour,and3are related to the organisation and management of application modules.Altogether,all the models are expected to convey a complete system specification.
However,although the availability of so many models constitutes a richness from the expressiveness viewpoint,each model introduces its own t of symbols and concepts,thus leading to an unnatural complexity in terms of vocabulary, model multiplicity and model integration[7].This is a problem both for main-taining consistency among the different system models and views,and for the mental integr
ation of such views,since integrating veral models within one’s mind an is a very difficult process.That is why the need to concurrently refer to different models in order to understand a system and the way it operates and changes over time is a critical issue,known as the multiplicity problem[8]. Despite this issue,however,the general adoption of UML as a world standard for system modelling makes it thefirst natural choice for reprenting meta-models.
Adopting UML to express meta-models of methodologies endors some spe-cific issues,since reprenting a methodology is inherently different from repres-enting a system at the object level.In particular,when meta-modelling method-ologies,UML leads to emphasi objects and object relations,leaving aside the procedural aspects,which can be revealed only indirectly,by object operations and message exchanges.Moreover,thefive behavioural diagrams provided by UML to capture the dynamic behaviour of a system at the object level become of little u at the meta-level,as they were defined to express which and how in-teraction occurs,rather than what interaction is and what role it plays—which is what is needed when reprenting a methodology.So,UML-bad meta-models usually exploit only package diagrams,class diagrams,and associations.
1.2Why OPM for Meta-models
In order to better address the issues of reprenting the dynamics at the meta-level,and possibly reduce the risk of inconsistency related to the multiplicity problem,it is natural to“look outside”the UML world,looking for some al-ternative approach.The Object Process Methodology(OPM henceforth)[9]is an integrated approach to the study and development of systems in general,and
时间就像
of software systems in particular.OPM is also a reflective a methodology that can model itlf without requiring any auxiliary means or ex-ternal tools.OPM unifies the system’s life-cycle stages(specification,design and implementation)within one single frame of reference,using a single diagram-ming tool—Object-Process Diagrams(OPDs)—and a corresponding subt of English,called Object-Process Language(OPL).
The basic assumption of OPM is that not only objects,but objects and pro-cess constitute two equally-important class of things,which together describe the functioning,structure and behaviour of a system in a single , without multiplying diagrams)in virtually any domain.Indeed,OPM’s basic principle is that structure and behaviour in a system are so intertwined that effectively parating them is extremely harmful,if not impossible.Therefore, unlike the object-oriented approach,behaviour in OPM is not necessarily encap-sulated within a particular object class construct:using stand-alone process, one can model a behaviour that involves veral object class
es and is integrated into the system structure.Process can be connected to the involved object class through procedural links,which are divided,according to their function-ality,into three groups:enabling links,transformation links,and control links.
Opposite to UML’s aspect-bad decomposition,which intrinsically violates the OPM’s goal of a single all-describing model,OPM adopts detail decom-position:rather then decomposing a system according to its various aspects, decomposition proceeds by exploring the system’s abstraction levels.This is done via three refinement/abstraction mechanisms:unfolding/folding,which re-fines/abstracts from the structural parts of a thing(mainly an object),in-zooming/out-zooming,which expos/hides the inner details of a thing(mainly a process)within its enclosing frame,and state expressing/suppressing,which expos/hides the states of an object.
1.3Why Meta-modelling SODA
Interaction is a major source of complexity in software systems.This is partic-ular true in multi-agent systems,where interaction can take different forms:for instance,social interaction is concerned with agents interacting with each other, while environmental interaction regards the agents’interaction with their en-vironment.Although most methodologies still focus on intra-agent issues,more recently,
methodologies like GAIA[10]and Hermes[11]have begun emphasising the role of interaction,shifting their focus toward social interaction.
So,since our purpo here is to exploit an agent-oriented methodology as a reference for stressing the pros and cons of different meta-modelling approaches, a methodology addressing only intra-agent issues would notfit:we need a meth-odology that widely deals with inter-agent issues,so that the social aspects of multi-agent systems are in the front line.SODA[12]is a methodology which explicitly focus on suitably modelling the social aspects of a MAS.As such, it assumes interaction to be the key aspect of its modelling process:a system entity appears in a SODA model only in that it is involved in some interactions. So,designing a multi-agent system in SODA amounts to defining agents in terms
of their required obrvable ,of the interactions in which agents are involved,and of the agents’roles in the MAS.In addition,taking interac-tion into account implies to consider relevant coordination issues,addresd by SODA in the design pha.Therefore,in the following wefirst define the SODA meta-model in UML(Section2.1)and in OPM(Section2.2),then comparat-ively discuss the pros and cons of such meta-models and,by doing so,of the two approaches in general(Section3).夜夜春色
西瓜的英文2SODA Meta-models
SODA(Societies in Open and Distributed Agent spaces)[12]is an agent-oriented methodology for the analysis and design of agent-bad systems.SODA focus on inter-agent issues,like the engineering of societies and infrastructures for multi-agent systems.Since this conceptually covers all the interaction within an agent system,the design pha deeply relies on the notion of coordination model [13].In particular,coordination models and languages are taken as a source of the abstractions and mechanisms required to engineer agent societies:social rules are designed as coordination laws and embedded into coordination artifacts,and the social infrastructure is built upon coordination system.
The analysis pha is characterid by three models:the role model,the resource model and the interaction model.The design pha is bad on three strictly-related models,deriving from the models defined in the analysis pha;in particular,the analysis’role model maps on the design’s agent model and society model,while the analysis’resource model maps on the design’s environment model.The analysis’interaction model,in its turn,generates the interaction protocols and coordination rules referenced by the design’s models(e[12]for more details).
2.1SODA Meta-model in UML
使命是什么The UML meta-model of SODA(Figure1)reflects the SODA distinction between the analysis pha(top)and the design pha(bottom).In the analysis pha, the boundaries between the resource model,the interaction model,and the role model are well defined;in the design pha,instead,no such boundaries are shown,becau the entities of the analysis sub-models do not map one-to-one onto analogous entities of the design model.It is worth noting that this UML model clearly emphasi the centrality of interaction which is typical of the SODA approach:in fact,if the interaction model were deleted,along with the corresponding class in the design pha,concepts such as roles and resources would turn out to be parate and unrelated from one another.
Although this model captures the SODA concepts and associations as far as UML’s(large yet somehow limited)graphical vocabulary makes it possible,the result is not completely satisfactory,for veral reasons.First,UML provides basically a unique type of concept/symbol(the class)to reprent entities which are conceptually distinct in the meta-model.More precily,while using the
Figure1.SODA Meta-model in UML
UML class notion to capture the SODA organisational structure—i.e.,entities such as roles,tasks,gro
ups,society,agents,resources,infrastructure class—leads to a satisfactory reprentation of the aspects,the same cannot be said for interaction,who class are qualitatively different from the others(both in the analysis and in the design pha),as they try to model an intrinsically dynamic dimension by means of an intrinsically static abstraction.
The model entities are connected to each other by different relations—inheritance,composition,aggregation,and generic association.In particular,the relations between Group and(respectively)Individual role/Social role emphas-i that a Social role may either coincide with an already defined Individual role(aggregation),or be defined ex-novo(composition).Moreover,the relations between the structural entities and the“interaction entities”are critical from the modelling viewpoint,since such entities are qualitatively different;this is why they are expresd by a generic(tagged)association.
Another key aspect concerns the connections from the analysis pha to the design pha.The label“map onto”is somehow vague,yet underlines the in-trinsic difficulty in expressing the complex mapping from the analysis to the design pha via a single association link.For instance,when mapping Role onto Agent,the association itlf is unable to express that Agent inherits task,per-missions and interaction protocols from Role:so,a suitable label is the only(yet unsatisfactory)way to
express this fact.
2.2SODA Meta-model in OPM
Figure2shows the SODA meta-model in OPM.Of cour,many aspects dis-
cusd above—the distinction between the two phas,the analysis sub-models,
the centrality of interaction,the association“map onto”,—still hold:so,the overall model structure is basically the same as in Figure1.
However,the richer expressiveness of OPM’s graphical vocabulary with re-spect to UML makes it possible to model the key aspect of interaction as an OPM process,rather than as a class,thus expressing the dynamic aspects that the(static)class notion alone could not capture.By doing so,the OPM meta-model of SODA captures the transient nature of interaction in much a better way than its UML counterpart.Furthermore,the richness of the OPM graphical vocabulary offers a better alternative to replace UML generic(tagged)asso-ciations with a new,mantically-clear symbology.For instance,the relation between Resource and Policy(and between Coordination Medium and Coordin-ation Rule)now adopts a specific symbol to express that Policy not only has a structural relation with Resource,but is also an attribute of Resource.
On the other hand,since OPM introduces just one symbol(the solid black triangle)to reprent both composition and aggregation,distinguishing between different relations(e.g Group/Individual Role,Group/Social Role)now requires a careful reading of the participation constraint of the relation(where*means “optional”,m means“many”,etc.).However,this aspect can be easily faced by using OPM’s textual counterpart,OPL,that provides a human-readable descrip-tion of the Object Process Diagram;the OPL of SODA meta-model is shown in Figure2(bottom).Despite the richness of OPM’s vocabulary,some meta-modelling relations are still difficult to express:this is particularly true for the relations between structural entities and“X-Interacting”process,that even the(veral)object/process link types provided by OPM are unable to capture at a mantically-satisfactory level(more details in Section3.2).
3Discussion
In this Section,we discuss and compare the SODA meta-models in UML and OPM,outlining the respective pros and cons.Generally speaking,both meta-models fall short in modelling the SODA concept of interaction and the relations between the structural parts and dynamic parts;in particular,this applies to the relation of“participation”,as we outline below.
3.1Pros and Cons of SODA Meta-model in UML
The structural parts of the SODA methodology are well modelled.Due to its graphical vocabulary,UML is forced to model the SODA concept of interaction via its class notion,thus giving a static view of interaction,as if it were always prent in the system—which is obviously misleading,since interaction has in-trinsically a transient nature;indeed,capturing the transient aspects through a class diagram can be difficult.
On the other hand,UML enables the concept of“participation”to inter-action to be expresd better than in OPM,thanks to the a generic tagged association:interestingly,this is possible just becau interaction is reprented
