Baldoni, Matteo

Baroglio, Cristina

Micalizio, Roberto

Olivier, Boissier

Tedeschi, Stefano

English

Institutional Research Information System University of Turin

Distributing Responsibilities for Exception Handling in JaCaMoDemonstration TrackMatteo Baldoni1, Cristina Baroglio1, Olivier Boissier2, Roberto Micalizio1, Stefano Tedeschi11 Università di Torino, Dipartimento di Informatica, Italy2 Laboratoire Hubert Curien UMR CNRS 5516, Institut Henri Fayol, MINES Saint-Etienne, FranceABSTRACTWe present an extension of the organizational model and infras-tructure adopted in JaCaMo, that explicitly encompasses the notionof exception. We propose an exception handling mechanism fororganization management in multi-agent systems. This mechanismrelies on abstractions that are seamlessly integrated with organiza-tional concepts, such as responsibilities, goals and norms.KEYWORDSException Handling; Multiagent Organizations; JaCaMoACM Reference Format:Matteo Baldoni1, Cristina Baroglio1, Olivier Boissier2, Roberto Micalizio1,Stefano Tedeschi1. 2021. Distributing Responsibilities for Exception Han-dling in JaCaMo: Demonstration Track. In Proc. of the 20th InternationalConference on Autonomous Agents and Multiagent Systems (AAMAS 2021),Online, May 3–7, 2021, IFAAMAS, 3 pages.1 INTRODUCTIONA software is robust when it is able to keep an acceptable behaviorin presence of abnormal execution conditions, like unavailabilityof system resources, communication failures, invalid or stressfulinputs [13]. One specific mechanism that supports robustness isexception handling which, roughly speaking, amounts to equippingthe systemwith the capabilities needed to tackle classes of abnormalsituations, identified at design time. An exception is an “event thatcauses suspension of normal program execution” [1]. Therefore,the purpose of an exception handling mechanism is to provide thetools to (i) identify when an exception occurs, and (ii) apply suitablehandlers, capable of treating the exception and recover.The need of exceptions emerges from the desire of structuringand modularizing software, separating concerns into componentsthat interact. Following the seminal work of Goodenough on ex-ceptions in programming languages [14–16], exceptions permit theuser of an operation to extend the operation’s domain (the set ofinputs for which effects are defined) or its range (the effects ob-tained when certain inputs are processed). They allow tailoring anoperation’s results or effects to the purpose in using the operation,and they also allow generalizing operations, making them usablein a wider variety of contexts than would otherwise be the case.Consequently, an exception’s full significance is known only outsidethe detecting operation: the operation is not permitted to deter-mine unilaterally what is to be done after an exception is raised.The invoker controls the response to the exception that is to beactivated. This increases the generality of an operation becauseProc. of the 20th International Conference on Autonomous Agents and Multiagent Systems(AAMAS 2021), U. Endriss, A. Nowé, F. Dignum, A. Lomuscio (eds.), May 3–7, 2021, Online.© 2021 International Foundation for Autonomous Agents and Multiagent Systems(www.ifaamas.org). All rights reserved.the appropriate “fixup" will vary from one use of the operation tothe next. To this aim, an invoker must be given enough informa-tion about the failure. This differentiates exception handling fromthe simple detection of norm violation or like contrary-to-duties[28], which do not systematically encompass the responsibilities ofraising and dealing with the exception, see [2–4, 8, 9].Multiagent organizations (MAOs) are widely used for the de-sign and development of distributed, non-centralized, autonomoussystems. Key features of many organizational models (see e.g., [5–7, 10, 19]), are a functional decomposition of the organizationalgoal and a normative system. Norms shape the scope of the respon-sibilities that agents take when joining the organization, capturingwhat they should do to contribute to the achievement of the organi-zational goal [12, 26, 27]. In particular, they allow to coordinate thedistributed execution notifying agents when something must bedone to discharge their responsibilities as members of the organi-zation. This demonstration shows how exception handling can begrafted inside the normative system of a MAO and, consequently,how the normative system can be used to gain robustness in theexecution. Specifically, we introduced exception handling in thewell-known JaCaMo multi-agent platform [6], integrating it bothat a conceptual level, within the high-level abstractions that areprovided by the model of JaCaMo’s organizational component, andat a software level, by enriching its infrastructure.2 RESPONSIBILITY IN EXCEPTIONHANDLINGMulti-agent systems bring software structuring, modularization,and separation of concerns to an extreme. Here, autonomous agentscooperate and rely on one another to pursue their aims. However,exceptions handling (besides a few attempts) has never been ap-plied as postulated in the work by Goodenough. What explainedin the first paragraph brings forward two important aspects of ex-ception handling. First, it always involves two parties: a party thatis responsible for raising an exception, and another party that isresponsible for handling it. Second, it captures the need for someinformation/account from the former to the latter that allows cop-ing with the exception. Since MAOs, in essence, are built uponresponsibilities, we claim that MAOs are naturally suited to encom-pass an exception handling mechanism. Indeed, in a MAO, eachagent has only a partial view of the organizational goal, whoseachievement is distributed among the agents. From this perspec-tive, we can interpret an exception as an event which denotes theimpossibility, for some agent, to fulfill one of its responsibilities –e.g. the failure in the achievement of a goal or a missed deadline. Asa consequence, the distributed achievement of the organizationalgoal will be suspended.Demonstration Track AAMAS 2021, May 3-7, 2021, Online1752In the context of MAO, we propose to leverage on responsibilitynot only to model the duties of the agents in relation to the organi-zational goal, but also to enable agents to report about exceptions,occurring within the organization operation, and to identify thoseagents entitled for handling them. When agents join an organiza-tion, they will be asked to take on the responsibilities not only forthe organizational goals, but also: 1) for providing accounts aboutthe context where exceptions are detected while pursuing organi-zational goals, and 2) if appointed, for handling such exceptionsonce the needed information is available. Responsibilities, thus,define the scope of the exceptions, expressed with respect to theorganizational state, that agents ought to raise or treat.Related works. Differently than the approach by Platon et al. [22–25], where exception handling is seen as a tool that the individualagent can activate internally, to preserve control on itself despite theoccurrence of exceptions, the proposal leverages on the distributednature of exception handling, typical of programming languagesand of the actor model [17], and suited to distributed systems madeof cooperative parties, like MAO. In [11, 20, 21], an approach isproposed, that is based on a shared exception handling service. Theservice provides sentinels, that are equipped with handlers (inspiredby research on management), to be plugged into existing agentsystems. The service actively looks for exceptions in the system andprescribes specific interventions from a body of general procedures.Sentinels communicate with agents using a predefined language forquerying about exceptions and for describing exception resolutionactions. Agents, for their part, are required to implement a minimalset of interfaces to report on their own behavior and modify theiractions according to the prescriptions given by the sentinels. As adifference, our proposal seamlessly integrates exception handlinginto the agents themselves, without centralizing it. In this way, itaccommodates Goodenough’s recommendation that appropriate“fixup" will vary from one use of the operation to the next.3 EXTENDING JACAMOJaCaMo [6] is a conceptual model and programming platform thatintegrates agents, environments and organizations. Moise [18, 19]implements the organizational programming model. It comprisesa structural dimension, a functional dimension, including a set ofschemes that captures how the organizational goals are decomposedinto subgoals, grouped into missions, and a normative dimensionbinding the other two. Agents, in fact, are held to explicitly committo missions, i.e., taking responsibility for mission goals.We propose to enrich the schemes and missions of the functionalspecification of a organization with the following new concepts1.Recovery Strategy encodes when and how a given exception is tobe raised and handled within the organization. It includes a notifica-tion policy and one or more handling policies.Notification Policyspecifies when the exception must be raised. It includes a throw-ing goal, enabled when such circumstances hold and an exceptiontype encoding the kind of information to be produced. HandlingPolicy specifies a way in which the exception must be handled,once the needed information is available. It includes a catching goaland specifies when such goal is to be enabled. Throwing Goal1The full code of Moise extended with exception handling, together with some exam-ples, is available at http://di.unito.it/moiseexceptions.denotes the organizational goal of raising the exception, i.e., it willmake the agent that is responsible for it to provide the informationthat is needed for recovery. Catching goal captures the course ofaction to handle the exception and remediate. Its aim is to restorethe execution of the scheme after an exception is raised. Throw-ing goals and catching goals specialize the goal specification andare incorporated into mission just like standard ones. As a result,missions become a tool to distribute the responsibilities, not onlyconcerning the normal execution, but also for the management ofexceptional situations. Policies, in turn, delimit the scope of suchresponsibilities, specifying when and how they are to be discharged.To illustrate, we rely on the building-a-house example, origi-nally introduced in [6]. Here, the organizational goal is to build ahouse on a plot in a dynamic environment, where robustness ofthe organization coordinating the building of the house is impor-tant. Achievement involves the coordination of multiple companiesexecuting the various subgoals, part of which can be executed inparallel, while part depends on others. For instance, site prepara-tion must be completed before any other step. Should the agent incharge of it face a failure in the fulfillment of its responsibility, thewhole house construction could not proceed. We can, then, extendthe functional specification of the organization with the followingrecovery strategy, targeting a failure in the achievement of goalsite_prepared:1 <recovery -strategy id="rs1">2 <notification -policy id="np1">3 <condition type="goal -failure">4 <condition -argument id=" target" value=" site_prepared" />5 </condition >6 <exception -type id=" site_preparation_exception">7 <exception -argument id=" errorCode" arity ="1" />8 </exception -type >9 <goal id=" notify_site_preparation_problem" />10 </notification -policy >11 <handling -policy id="hp1">12 <condition type=" always" />13 <goal id=" handle_site_problem">14 <plan operator =" parallel">15 <goal id=" inspect_site" />16 <goal id=" notify_affected_companies" />17 </plan >18 </goal >19 </handling -policy >20 </recovery -strategy >Notification policy np1 specifies that, should a goal failure con-cerning site_prepared occur (see the condition at Lines 3-5),the throwing goal notify_site_preparation_problem is to beenabled. Its purpose is to make the agent responsible for it pro-vide the information needed for recovery. To this end, an excep-tion type site_preparation_exception (Lines 6-8) specifying anerrorCode is defined. Handling policy hp1, in turn, expresses whatneeds to be done to solve the site preparation exception, once it hasbeen raised and the error code provided. In this case, the catchinggoal is a complex one (Lines 13-18): the site should be inspectedand, at the same time, the other companies involved in the houseconstruction notified. It’s worth noting that agents in charge ofthese goal will likely leverage the information provided beforehandto achieve them. Site inspection, e.g., will be performed in differ-ent ways in case the error code denotes a flooding rather than thefinding of archaeological remains. Corrective actions undertakenby the agents will be different, as well.Demonstration Track AAMAS 2021, May 3-7, 2021, Online1753REFERENCES[1] 2010. ISO/IEC/IEEE International Standard - Systems and software engineering –Vocabulary. ISO/IEC/IEEE 24765:2010(E) (Dec 2010), 1–418. https://doi.org/10.1109/IEEESTD.2010.5733835[2] Matteo Baldoni, Cristina Baroglio, and Roberto Micalizio. 2020. Fragility andRobustness in Multiagent Systems. In Post-Proc. of the 8th International Workshopon Engineering Multi-Agent Systems, EMAS 2020, Revised Selected Papers (LNAI,12589), C. Baroglio, J. F. Hubner, and M. Winikoff (Eds.). Springer, Auckland, NewZealand, 61–77. https://doi.org/10.1007/978-3-030-66534-0_4[3] Matteo Baldoni, Cristina Baroglio, Roberto Micalizio, and Stefano Tedeschi. 2020.Is Explanation the Real Key Factor for Innovation?. In Proc. of Italian Workshop onExplainable Artificial Intelligence, XAI.it 2020, C. Musto, D. Magazzeni, S. Ruggieri,and G. Semeraro (Eds.), Vol. 2742. CEUR, Workshop Proceedings, Online Event,Italy, 87–95. http://ceur-ws.org/Vol-2742/[4] Matteo Baldoni, Cristina Baroglio, Roberto Micalizio, and Stefano Tedeschi. 2021.Robustness based on Accountability in Multiagent Organizations. In Proc. of 20thInternational Conference on Autonomous Agents and Multiagent Systems, Engi-neering Multiagent Systems Track, AAMAS 2021, U. Emdriss, A. Nowé, F. Dignum,and A. Lomuscio (Eds.). IFAAMAS, Richland, SC, Online.[5] B. Bauer, J.P. Müller, and J. Odell. 2001. Agent UML: A formalism for specifyingmultiagent software systems. Software Engineering and Knowledge Engineering11, 3 (2001), 207–230.[6] Olivier Boissier, Rafael H. Bordini, Jomi F. Hübner, Alessandro Ricci, and AndreaSanti. 2013. Multi-agent Oriented Programming with JaCaMo. Sci. Comput.Program. 78, 6 (2013), 747–761. https://doi.org/10.1016/j.scico.2011.10.004[7] Paolo Bresciani, Anna Perini, Paolo Giorgini, Fausto Giunchiglia, and John My-lopoulos. 2004. Tropos: An Agent-Oriented Software Development Methodol-ogy. Autonomous Agents and Multi-Agent Systems 8, 3 (2004), 203–236. https://doi.org/10.1023/B:AGNT.0000018806.20944.ef[8] Amit K. Chopra and Munindar P. Singh. 2016. From social machines to socialprotocols: Software engineering foundations for sociotechnical systems. In Proc.of the 25th Int. Conf. on WWW.[9] Amit K. Chopra and Munindar P. Singh. 2018. Sociotechnical Systems and Ethicsin the Large. In AIES ’18: Proceedings of the 2018 AAAI/ACM Conference on AI,Ethics, and Society. ACM, 48–53.[10] Anne Dardenne, Axel van Lamsweerde, and Stephen Fickas. 1993. Goal-directedrequirements acquisition. Science of Computer Programming 20, 1 (1993), 3 – 50.https://doi.org/10.1016/0167-6423(93)90021-G[11] Chrysanthos Dellarocas and Mark Klein. 2000. An experimental evaluation ofdomain-independent fault handling services in open multi-agent systems. InProceedings Fourth International Conference on MultiAgent Systems. IEEE, 95–102.[12] Christophe Feltus. 2014. Aligning Access Rights to Governance Needs with theResponsability MetaModel (ReMMo) in the Frame of Enterprise Architecture. Ph.D.Dissertation. University of Namur, Belgium.[13] Jean-Claude Fernandez, Laurent Mounier, and Cyril Pachon. 2005. A Model-based Approach for Robustness Testing. In Proceedings of the 17th IFIP TC6/WG6.1 International Conference on Testing of Communicating Systems (Montreal,Canada) (TestCom’05). 333–348.[14] John B. Goodenough. 1975. Exception Handling Design Issues. SIGPLAN Not. 10,7 (July 1975), 41–45. https://doi.org/10.1145/987305.987313[15] John B. Goodenough. 1975. Exception Handling: Issues and a Proposed Notation.Commun. ACM 18, 12 (Dec. 1975), 683–696. https://doi.org/10.1145/361227.361230[16] John B. Goodenough. 1975. Structured Exception Handling. In Proceedings of the2nd ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages(Palo Alto, California) (POPL ’75). Association for Computing Machinery, NewYork, NY, USA, 204–224. https://doi.org/10.1145/512976.512997[17] Carl Hewitt, Peter Bishop, and Richard Steiger. 1973. AUniversalModular ACTORFormalism for Artificial Intelligence. In Proceedings of the 3rd International JointConference on Artificial Intelligence (Stanford, USA) (IJCAI’73). Morgan KaufmannPublishers Inc., San Francisco, CA, USA, 235–245.[18] Jomi F. Hübner, Olivier Boissier, Rosine Kitio, and Alessandro Ricci. 2010. In-strumenting multi-agent organisations with organisational artifacts and agents.Autonomous Agents and Multi-Agent Systems 20, 3 (1 5 2010), 369–400.[19] Jomi F. Hübner, Jaime S. Sichman, and Olivier Boissier. 2007. Developing Organ-ised Multiagent Systems Using the MOISE+ Model: Programming Issues at theSystem and Agent Levels. Int. J. Agent-Oriented Softw. Eng. 1, 3/4 (2007), 370–395.https://doi.org/10.1504/IJAOSE.2007.016266[20] M. Klein and Chrysanthos Dellarocas. 1999. Exception handling in agent systems.In AGENTS ’99.[21] Mark Klein and Chrysanthos Dellarocas. 2000. A knowledge-based approach tohandling exceptions in workflow systems. Computer Supported Cooperative Work(CSCW) 9, 3-4 (2000), 399–412.[22] Eric Platon. 2007. Modeling exception management in multi-agent systems. Ph.D.Dissertation. Université Pierre et Marie Curie, France.[23] Eric Platon, Nicolas Sabouret, and Shinichi Honiden. 2007. Challenges for Excep-tion Handling in Multi-Agent Systems. In Software Engineering for Multi-AgentSystems V, Ricardo Choren, Alessandro Garcia, Holger Giese, Ho-fung Leung,Carlos Lucena, and Alexander Romanovsky (Eds.). Springer Berlin Heidelberg,Berlin, Heidelberg, 41–56.[24] Eric Platon, Nicolas Sabouret, and Shinichi Honiden. 2007. A Definition ofExceptions in Agent-Oriented Computing. In Engineering Societies in the AgentsWorld VII, Gregory M. P. O’Hare, Alessandro Ricci, Michael J. O’Grady, and OğuzDikenelli (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 161–174.[25] Eric Platon, Nicolas Sabouret, and Shinichi Honiden. 2008. An architecture forexception management in multiagent systems. International Journal of Agent-Oriented Software Engineering 2, 3 (2008), 267–289.[26] Ian Sommerville. 2007. Models for Responsibility Assignment. Springer London,London, 165–186.[27] Ian Sommerville, Tim Storer, and Russell Lock. 2009. Responsibility modellingfor civil emergency planning. Risk Management 11, 3 (2009), 179–207.[28] LeendertW. N. van der Torre and Yao-Hua Tan. 1999. Contrary-to-duty reasoningwith preference-based dyadic obligations. Ann. Math. Artif. Intell. 27, 1-4 (1999),49–78. https://doi.org/10.1023/A:1018975332469Demonstration Track AAMAS 2021, May 3-7, 2021, Online1754

Distributing Responsibilities for Exception Handling in JaCaMo

https://iris.unito.it/bitstream/2318/1788642/1/p1752.pdf

Distributing Responsibilities for Exception Handling in JaCaMo

Abstract

Similar works

Full text

Available Versions

Institutional Research Information System University of Turin