be tested in more application domains. The explicit and implicit analysis and specification where the system
engineer may be managing the structure complexity and the system dynamics with the use of CPN. The use of
fusion place, for modeling the system hierarchically, is a viable solution for representing the communication
simultaneous interactions among agents. An attractive area is business to consumer (B2C) systems, which are high dependent of the user decisions in the interactive model, and may required to consider temporal and fuzzy aspects that need to be modeled with the IMCIS.
References
1. P.R Cohen and H.J. Levesque, “Communicative actions for artificial agents”, Proceedings of the International Conference on Multi-Agent Systems, AAAI Press, San Francisco, June, 1995.
2. P.R. Cohen and H.J. Levesque, “Rational Interaction as a Basis for Communication”, Cohen P. R., Morgan, J., and Pollack, M. E. (eds.), in Intentions in Communication, SDF Benchmark Series, MIT Press, pp. 221-255, 1990.
3. J.M. Cordero, and M. Toro, “A Components Model based on Interaction-Nets”, ISAS/SCI 1999, Orlando, Florida, 1999.
4. R.S. Cost, Y. Chen, T. Finin, Y. Labrou and Y. Peng, “Modeling Agent Conversations with Coloured Petri Nets”, To appear in Working Notes of the Workshop on Specifying and Implementing Conversation Policies, Autonomous Agents ´99, Seattle, WA, May 1999.
5. R.S. Cost, Y. Chen, T. Finin, Y. Labrou and Y. Peng, “Using Coloured Petri Nets for Conversation Modeling ”, IJCAI ´99, 1999.
6. R.S. Cost, Y. Chen, T. Finin, Y. Labrou and Y. Peng, “A Negotiation-based multi-agent system for supply chain management ”, in Working Notes of the Agents ´99 Workshop on Agents for Electronic Commerce and Managing the Internet-Enable Supply Chain, Seattle, WA, April 1999.
7. K. Decker, “Environment centered analysis and design of coordination mechanisms”, PhD Thesis, University of Massachusetts Amherst, 1995.
8. A. El Fallah, and S. Haddad, “A Recursive Model for Distributed Planning”, ICMAS-96, p.307-314, 1996.
9. A.El Fallah, S. Haddad and H. Mazouzi, “Observation répartie et analyse des interaction dans un système multi-agents”, JFIADSMA-98, Eds Hermès, Nancy 1998.
10. A. El Fallah, S. Haddad and H. Mazouzi, “Une demarche méthodologique pour l´ingénierie des protocols d´interaction”, JFIADSMA-99, Eds Hermès, Nancy 1999.
11. A. El Fallah, S. Haddad and H. Mazouzi, “Protocol Engineering for Multi-agent Interaction”, 9 th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, MAAMAW´99, Springer, 1999.
12. Y. Demazeau, J.L. Koning, and G. Françoise, “Formalization and pre- validation for interaction protocols on multi-agent systems”, Distributed AI and Multi-agent Systems, p- 298-302, 1998.
13. FIPA, Foundation for Intelligent Physical Agents, “Agent Communication Language Specification”, http://www.fipa.org, 2000.
14. F. Flores, and T. Winograd, “Understanding computer and cognition, a new foundation for design”, Addison Wesley, 1986.
15. F. Flores, “Introducción al Ciclo Básico de la Acción (“Loop”)”, Business Design Associates, Inc., 1996.
16. A. Haddadi, “Towards a Pragmatic Theory of Interactions”, Morgan Kaufmann Publishers, San Francisco California, United States of America, 1998.
17. M. Huhns, and M.P. Singh, “Readings in Agents”, Morgan Kaufmann Publishers, San Francisco California, United States of America, 1998.
18. K. Jensen, “Coloured Petri Nets, Basic Concepts, Analysis Methods and Practical Use”, volume 1, 2, 3, second edition, Springer, Germany, 1997.
19. V. Lesser, “Reflections on the nature of multi-agent coordination and its implications for the agent architecture”, Autonomous agents and multi-agent systems, Kluwer academic publishers, 1, 89-111, July 1998.
20. H. Levesque and P. Cohen, "Teamwork", Nous 25(4), Special Issue on Cognitive Science and Artificial Intelligence, pp. 487-512. To appear in: Handbook of MultiAgent Systems, 1991.
21. D. Moldt and F. Wienberg, “Multi-agent systems based on coloured Petri nets”, Proceedings of the 18 th International Conference on Application and Theory of Petri Nets (ICATPN´97), number 1248 in Lecture Notes in Computer Science, p-82-101, Toulouse, France, June 1997.
22. M. Papazoglou and G. Schlageter, “Cooperative Information Systems, Trends and Directions”, Academic Press, San Diego, 1998.
23. F. Ramos-Quintana, J. Frausto-Solis and F. Camargo-Santacruz, “A Methodology for Modeling Interactions in Cooperative Information Systems Using Coloured Petri Nets”, to appear in the International Journal of Software Engineering and Knowledge Engineering, World Scientific, http://www.ksi.edu/ijsk.html, 2001.
24. H.J. Wooldidge and N.R. Jennings, “Intelligent Agents: Theory and Practice”, The Knowledge Engineering
Review, 10 (2), p. 115-152, 1995.
Systems with the Object Coordination Net Approach
HolgerGiese
SoftwareEngineeringGroup
UniversityofPaderborn
hg@upb.de
Abstract. Object-orientedmodellingistoday themainstreamapproachfor tacklingthe
designofdistributedsystems.Itpermitstohandlethestructureandbehaviourofcomplex
realworldproblems.Theoftenoccurringexplicitdelegationbetweenobjectshoweverresults
in considerableproblemsinthe domainof distributed systems.A moreexibleand open
schemeforcoordinationisinsteadrequired.Autonomousagentswhichcooperatetoachieve
their goalsratherthanexplicitlydelegatetasks havetherefore beenproposedtoovercome
theseproblems.However,legacysystemssupportingonlytheexplicitdelegationstylehave
to be integrated and ne graininteractionis often better modelled using the traditional
explicit delegation style. Therefore, in practice a purely agent-oriented approach is not
applicable.Theobjectcoordinationnetapproachoersanobject-orienteddesigntechnique
basedonUMLnotations employingaspecialtypeofhigh-levelPetri-Netsthatpermitsto
modeldistributedsystemsusingbothstylesinanintermixedmanner.Anexampleisused
to demonstratehowitsupportsthecrucialaspectsofdistributedsystem designbymeans
ofstandardobject-orientedandagent-orientedmodellingatthesametime.
1 Introduction
ThesystematicandpredictableengineeringoflargesoftwaresystemsisaninherentdiÆcult
prob-lem. When distributed systems are considered their specic nature further results in a set of
additional problems not present when designing traditional single computer systems. Roughly
stating these are the phenomena of distribution, heterogeneity, coordination, resource
manage-ment,andpartialfailures.Aratherimplicitresultingpropertyisconcurrencythat addsitsshare
tothecomplexityofhandlingdistributeddesignproblems.Whileseveralproblemscanbehandled
using available technologies, others remain inherent and have to be tackled in a more explicit
fashion.Distributionaswellassystemheterogeneityarehandledbyapplyingaccessandlocation
transparency oered by today's middleware systems. For the remaining aspects no comparable
transparenttechnologymappinghasbeendeveloped,whichensurethattheresultingsystemsare
predictableacceptable(cf.[35]).Thegreatdierencebetweennetworklatencyandcomputational
speedmakesasynchronousoperatingaswellasparallelisminseveralformsmandatorywhen
scala-bilityorhigherthroughputrequirementsaredemanded.Therefore,moreautonomouslyoperating
componentsratherthantightcoupledobjectsarerequired.
Based on the success of object-oriented programming, object-oriented analysis (OOA) and
object-orienteddesign(OOD) [31,36] havebeendeveloped.Incontrastto structuredanalysis an
increasinglyseamlesstransitionthroughtheearlierstagesofthesoftwarelifecycleisprovided.The
objectsand theirtypes(classes) aremorestable withrespectto requirementanddesignchanges
emphasisingthe directmappingconcept(cf. [22]).Thus, theobject-orientedparadigmisamore
suitableapproachforlargesoftwareprojects.
However,the main principles of object-orientation can be employed in quite dierent ways.
One concept is data-driven design [31].It starts during analysis with a domain model which is
stepbystepextendedandrenedusingforinstanceadditionaltechnicalclassesduringthedesign.
Incontrastto data-drivendesigntheconceptofresponsibility-drivendesign[36] triesto identify
responsibilities and map them to classes rather than use classes to represent data elements of
the problem domain. Therefore, it avoids both centralised and overly distributed designs. The
The dierent responsibilities of a class can be further structured when dierent roles [29] are
distinguished.Theyallowto consider dierentresponsibilities in isolationandthereforeimprove
the separation in a design. Role and responsibility-driven design therefore results in a suitable
designfordistributedsystemswherecoordinatorstakecareoftheirresponsibilitiesbycoordinating
otherinstances,whiledetailsaredelegatedtosubordinatedcoordinators.Thisincludesreactiveas
wellasproactivebehaviour.Byfurtheremphasisingthecoordinatorrolestereotypeandavoiding
controllerstereotypes,asuitabledesignstylefordistributedsystemsisachieved.Thisdesignstyle
is also appropriate for variability and adaptability, because changes will only eect other parts
whenthechangesaresodrasticthat overallcoordinationrequires adjustment.
Intoday'ssoftwareengineeringtheparadigmofobject-orientationisseenasthemostsuitable
approachforthedesignofdistributed systems(cf.[9]).Theseamlesssupportforallphases,from
analysistodesignandimplementationanditssuccessfulconceptstohandlethecomplexityofreal
softwareprojectsjustiesthisview.However,thecommondesignstyle,whichdelegatesbehaviour
to explicitlyknownsubordinatedobjects,resultsofteninatootightcoupling.Agentshavebeen
proposed for a long time [2,34] as an alternative approach that due to the inherent autonomy
of each agent avoids this drawbacks of the object-oriented approach. Today, bothconcepts are
not further considered as contradicting paradigms. Instead, agents are rather understood as a
conceptualextensionoftheobject-orientedparadigm[27].
Inagent-orientedmodellinganagentis characterisedbyitsreactiveandproactivenature,its
autonomywithrespecttostateandbehaviour.Anagentisfurther situatedinsomeenvironment
(cf. [38]).Whilecompared withdata-drivendesigntheagentparadigmisquitedierent,a
com-parisonwiththeresponsibility-drivendesignstylerevealsthattheessentialdierenceisonlythe
agentautonomy and its context awareness. Therefore agent technology canbebetter combined
withtheresponsibility-drivendesignstylewhichnotionofresponsibilitydoescloselyrelatetothe
agentspecicnotionofdesire.
Agentsaretodaynolongerproposedwithaclosedworldassumptionin mind. Wooldridgeet
al.[39]insteadnote thatagent-baseddesignand techniques areoftenmoresuitableemployedat
thecoarse-grainviewof asystemratherthanat itsne-grainview.Therefore,theagentconcept
canbeseenratherasaspecicsoftwarearchitecturalstyle.Theagentrealizationitselfmightbe
done using object-oriented technologies or special purpose agent languages.The agent-oriented
paradigmreectsthisbyfurtherdistinguishingbetweenamicroandmacroviewtodenotedesign
atdierentlevelsofgranularities.Themicroviewdescribingtherealizationofasingleagent.The
macroviewcanberelatedtothecoarse-graindesignorsoftwarearchitecture.
The agent paradigm currently evolves from a programming language technology to
agent-oriented software engineering [8]. Therefore, modelling techniques are required which support,
besidesthe pure agent-orientedstyle, the combination with traditionally build systems. This is
not only requiredfor legacy systemintegration. It is also reasonable to ensure, that the
agent-orienteddesigncanuseobject-orientedframeworksanwillbeabletointeractwithothermodules
buildin andobject-orientedstyle.
The presented Object Coordination Net approach (OCoN) oers an object-oriented design
techniquebasedonUML[26]thedefactostandardforobject-orientedmodelling.Theunderlying
conceptis aspecialtypeof high-levelPetri-Netsthat permitsto modeldistributed systems
sup-portingboththeobject-orientedandagent-orientedstyleofdesign.Thementionedcrucialaspects
fordistributedsystemdesigncanbemodelledusingthePetrinetconceptscontainedinthevisual
designlanguageOCoN.Itsupportsboth,standardobject-orientedaswellasagent-oriented
mod-elling.TheOCoNcontractnotionfurthersupportsthedemandeddesignofcoordinationaspectsin
amodularmanner.Contractscanvaryfromdelegationtocooperationlikestyles,allowingawide
range of protocols. The contractsare further smoothly integrated into thelanguage and ensure
thepropercoordinationbetweenitsparticipants.
ThebasicconceptsoftheapproachandashortoverviewispresentedinthefollowingSection
2.Then,anexampleis presentedandseveraldesignalternativesand theirsystematicevaluation
arediscussed(seeSection3).RelatedworkiscomparedinSection4andanal conclusioncloses
thearticle.
TheObject-Coordination-Net(OCoN)approachintroduced in[37]providestherequired
integra-tionbetweenobject-orientedandagent-orientedmodellingbymeansofreactiveaswellasproactive
contracts.ItcombinesthematureUMLstructurediagramswithappropriatevisualbehaviour
de-scriptions based on Petri-Nets [6]. The approach further seamlessly integrates the concepts of
object-orientation,concurrencyhandlingandresourcecoordination(see[15]).Wefurtherassume
thereaderto befamiliarwiththemostimportantdiagramsoftheUML (oritspredecessors)and
withbasicPetri-Nets[6].
Fig.1.UMLembeddingofOCoNdiagrams
In order to integratetheapproachwith the suitableparts of theUML [26] weadd only
spe-cicelementsas wellas newdiagrams where necessary(see Figure1). Whendealingwith static
structurethiscanbedoneusingtheUML extensionmechanisms.Thecommoninterfacenotionis
extendedto contractsby aso-calledprotocol net (PN) tospecifynonuniformserviceavailability.
Theyare used to specify externallyvisible behaviourand to decouplesystemsbyclearly
distin-guishingbetweenaninterfaceanditsimplementation.Astereotypecontractisusedtoembedthis
concept into aUML class diagram (see Figure 1contract Contract1). In class diagrams we will
sometimesonlyusethe UMLinterfaceshortcut(circle withinterface name)insteadofthis
com-pletestereotype.Aclassmayprovidemultiple contractsto theoutsidewhichhavetobefullled
byimplementingitspublicservices.Aninstance-localdescriptionwhichresourcesareneededand
howtheyarecoordinatedisadditionallyrequired.TheUMLstereotypeimplementationisusedto
denoteanactiveUMLclass.Itsreactiveandproactivebehaviourisfurtherdescribedbyaso-called
resourceallocation net(RAN)asvisualised forclassContractImpl in Figure1.If asingleservice
containsinterestinginternalparallelismorrelevantresourceallocationsteps,thiscanbyspecied
by a so-called service net (SN), otherwisea method implemented, e.g.,using Javacan be used
whichprovidesaninterfacetolegacycode.A servicenetisanalogouslyintegratedusingaservice
stereotype(seeFigure1serviceContractImpl::op1).Notethatin contrasttohierarchicalcoloured
Petrinets[20]andtheirsubpagemechanismsuchclassdiagramscandescribealsonon-hierarchical
objectstructures.