Skip to main content
Log in

A new Hierarchical Agent Protocol Notation

  • Published:
Autonomous Agents and Multi-Agent Systems Aims and scope Submit manuscript

Abstract

Agent interaction descriptions (or protocols) are a key aspect of the design of multi-agent systems. However, in the authors’ extensive experience, the notations commonly used for specification are both difficult to use, and lack expressiveness in certain areas. Some desired modular representations are impossible to express, while others result in specifications that are unwieldy and difficult to follow. In this paper we present a new notation for expressing interaction protocols, focussing on key issues that we have found to be problematic: the ability to define flexible data-driven protocols; representation of roles including their mapping to agents; and hierarchical modularity. We provide the semantics for our notation and illustrate its use with three diverse case studies. Finally we evaluate this notation using objectively assessable criteria that we argue contribute substantially to pragmatic usability, and using a human subject evaluation of the notation’s usability.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16

Similar content being viewed by others

Notes

  1. A parameter can also be tagged as “nil”.

  2. Or, more precisely, when a message appears in more than one currently active protocol instance, since two different protocols can use the same message name.

  3. The protocol is a design-time specification: it does not regulate run-time messaging, so does not prevent a message from being sent.

  4. More precisely, for any state with sub-protocols, any transitions from that state are considered to have an implicit guard that is true iff for all sub-protocols, either the sub-protocol has no final states, or it is in a final state.

  5. Notation: r1 and r2 denote “request variable 1” and “request variable 2” respectively, “g1” denotes “give information for variable 1”, “f1” denotes “forget information for variable 1”, “c” is the cancel request, “c1” is “cancel related to variable 1”, and “conf” is “confirm”.

  6. \({\mathsf {Bs}}\)—note that we use an “s” to highlight that this is a set of agents, and hence that a message \({\mathsf {A}} \rightarrow {\mathsf {Bs}}\) is a broadcast, which we highlight by using a double arrow \(\Rightarrow \) instead of the usual \(\rightarrow \).

  7. In an electronic auction such as ebay where the set of potential bidders is huge, and the set of actual bidders is initially unknown, the individual conversation/protocol instances would be lazily instantiated as potential bidders actually interacted.

  8. Note that this protocol, which is taken from the literature, is not a great design (e.g. using goto/label instead of a loop, and terminating the Initiator when a not-understood message is sent).

  9. Although the protocol does specify that the table T grants the lock, this can be easily generalised by replacing T with LG (Lock Granter) and adding LG to the protocol’s interface variables.

  10. Since this paper was written, and possibly influenced by it, BSPL has been extended to handle auctions [11]. However, the extensions add substantial complexity to BSPL.

  11. Ethics approval was obtained from the University of Otago (D15/224).

  12. Note that FSMs are not covered in INFO211, so we were expecting, and found, that few students indicated familiarity with them.

  13. The manufacturing problem used for the evaluation is a simplified version of the one presented in Sect. 5.3: it only handles a single join, and the protocol does not model the flipper or rotating the table.

  14. Kruskal–Wallis, since the scores are not expected to be normally distributed, where, as usual, a difference is statistically significant when \(p<0.05\).

  15. Two participants only provided an assessment of writability for the notation that they had used for the writing task.

  16. They had a message: “U \(\rightarrow \) S: search(keyword\(\Vert \)Artist&&Keyword)” which is not valid HAPN.

  17. Currently, the tool does not track values assigned to the variables and hence lacks the ability to evaluate guards.

  18. https://github.com/nwjs/nw.js/.

  19. We are indebted to an anonymous reviewer for this suggestion.

  20. For details on the papers see (e.g.) http://www.otago.ac.nz/courses/papers/index.html?papercode=COMP150.

References

  1. Alur, R., Kannan, S., & Yannakakis, M. (1999). Communicating hierarchical state machines. In J. Wiedermann, P. van Emde Boas, & M. Nielsen (Eds.), Automata, languages and programming (pp. 169–178). Berlin: Springer.

  2. Ancona, D., Ferrando, A., & Mascardi, V. (2016). Comparing trace expressions and linear temporal logic for runtime verification. In E. Ábrahám, M. Bonsangue, & E. B. Johnsen (Eds.), Theory and practice of formal methods: Essays dedicated to Frank de Boer on the occasion of his 60th birthday (pp. 47–64). Cham: Springer.

    Chapter  Google Scholar 

  3. Baldoni, M., Baroglio, C., Calvanese, D., Micalizio, R., & Montali, M. (2016). Data and norm-aware multiagent systems for software modularization (position paper). In M. Baldoni, J. P. Müller, I. Nunes, & R. Zalila-Wenkstern (Eds.), Engineering multi-agent systems (EMAS) (informal workshop proceedings) (pp. 23–38). Singapore.

  4. Baldoni, M., Baroglio, C., & Capuzzimati, F. (2014). A commitment-based infrastructure for programming socio-technical systems. ACM Transactions on Internet Technology, 14(4), 23:1–23:23.

    Article  Google Scholar 

  5. Baldoni, M., Baroglio, C., Marengo, E., & Patti, V. (2013). Constitutive and regulative specifications of commitment protocols: A decoupled approach. ACM Transactions on Intelligent Systems and Technologies, 4(2), 22.

    Google Scholar 

  6. Baldoni, M., Baroglio, C., Marengo, E., Patti, V., & Capuzzimati, F. (2014). Engineering commitment-based business protocols with the 2CL methodology. Autonomous Agents and Multi-Agent Systems, 28(4), 519–557.

    Article  Google Scholar 

  7. Basu, S., Bultan, T., & Ouederni, M. (2012). Deciding choreography realizability. In J. Field & M. Hicks (Eds.), Proceedings of the 39th ACM SIGPLAN-SIGACT symposium on principles of programming languages (POPL) (pp. 191–202). Philadelphia, Pennsylvania: ACM.

  8. Bhattacharya, K., Caswell, N. S., Kumaran, S., Nigam, A., & Wu, F. Y. (2007). Artifact-centered operational modeling: Lessons from customer engagements. IBM Systems Journal, 46(4), 703–721.

    Article  Google Scholar 

  9. Bultan, T., Su, J., & Fu, X. (2006). Analyzing conversations of web services. IEEE Internet Computing, 10(1), 18–25.

    Article  Google Scholar 

  10. Cabac, L., Duvigneau, M., Moldt, D., & Rölke, H. (2005). Modeling dynamic architectures using nets-within-nets. In G. Ciardo & P. Darondeau (Eds.), 26th International conference on applications and theory of Petri nets (ICATPN), volume 3536 of lecture notes in computer science (pp. 148–167). Berlin: Springer.

  11. Chopra, A. K., Christie, S. H. V., & Singh, M. P. (2017). Splee: A declarative information-based language for multiagent interaction protocols. In S. Das, E. Durfee, K. Larson, & M. Winikoff (Eds.), Autonomous agents and multi-agent systems (AAMAS) (pp. 1054–1063). São Paulo, Brazil: IFAAMAS.

    Google Scholar 

  12. Chopra, A. K., & Singh, M. P. (2015). Cupid: Commitments in relational algebra. In B. Bonet & S. Koenig (Eds.), Proceedings of the twenty-ninth AAAI conference on artificial intelligence (pp. 2052–2059). Austin, TX: AAAI Press.

    Google Scholar 

  13. Chopra, A. K., & Singh, M. P. (2016). Custard: Computing norm states over information stores. In C. M. Jonker, S. Marsella, J. Thangarajah, & K. Tuyls (Eds.), Autonomous agents & multiagent systems (AAMAS) (pp. 1096–1105). Singapore: IFAAMAS.

    Google Scholar 

  14. Cohn, D., & Hull, R. (2009). Business artifacts: A data-centric approach to modeling business operations and processes. IEEE Data Engineering Bulletin, 32(3), 3–9.

    Google Scholar 

  15. Desai, N., Chopra, A. K., & Singh, M. P. (2009). Amoeba: A methodology for modeling and evolving cross-organizational business processes. ACM Transactions on Software Engineering and Methodology, 19(2). doi:10.1145/1571629.1571632.

  16. Desai, N., & Singh, M. P. (2008). On the enactability of business protocols. In D. Fox & C. P. Gomes (Eds.), Proceedings of the twenty-third AAAI conference on artificial intelligence (pp. 1126–1131). Chicago, Il: AAAI Press.

  17. Eshuis, R. (2009). Reconciling statechart semantics. Science of Computer Programming, 74(3), 65–99.

    Article  MathSciNet  MATH  Google Scholar 

  18. Günay, A., Winikoff, M., & Yolum, P. (2015). Dynamically generated commitment protocols in open systems. Autonomous Agents and Multi-Agent Systems, 29(2), 192–229.

    Article  Google Scholar 

  19. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3), 231–274.

    Article  MathSciNet  MATH  Google Scholar 

  20. Huget, M.-P., Bauer, B., Odell, J., Levy, R., Turci, P., Cervenka, R., & Zhu, H. (2003). FIPA modeling: Interaction diagrams. On www.auml.org under “Working Documents”. FIPA Working Draft (version 2003-07-02).

  21. Huget, M.-P., & Odell, J. (2005). Representing agent interaction protocols with agent UML. In J. Odell, P. Giorgini, & J. P. Müller (Eds.), Agent-oriented software engineering V: 5th international workshop, AOSE 2004, Revised Selected Papers (pp. 16–30). Berlin: Springer.

    Chapter  Google Scholar 

  22. Huget, M.-P., Odell, J., & Bauer, B. (2004). The AUML approach. In F. Bergenti, M. P. Gleizes, & F. Zambonelli (Eds.), Methodologies and software engineering for agent systems (pp. 237–257). Berlin: Springer.

    Chapter  Google Scholar 

  23. Jarvis, J., Rönnquist, R., Jarvis, D., & Jain, L. C. (2008). A conceptual model for holonic manufacturing execution. In Holonic execution: A BDI approach, volume 106 of studies in computational intelligence (pp. 33–42). Berlin: Springer.

  24. Jarvis, J., Rönnquist, R., McFarlane, D., & Jain, L. (2006). A team-based holonic approach to robotic assembly cell control. Journal of Network and Computer Applications, 29(2–3), 160–176.

    Google Scholar 

  25. Kazhamiakin, R., & Pistore, M. (2006). Analysis of realizability conditions for web service choreographies. In E. Najm, J. Pradat-Peyre, & V. Donzeau-Gouge (Eds.), Formal techniques for networked and distributed systems FORTE, volume 4229 of lecture notes in computer science (pp. 61–76). Berlin: Springer.

  26. Koning, J., Huget, M., Wei, J., & Wang, X. (2001). Extended modeling languages for interaction protocol design. In M. Wooldridge, G. Weiß, & P. Ciancarini (Eds.), Agent-oriented software engineering II, second international workshop, Revised Papers and Invited Contributions, volume 2222 of lecture notes in computer science (pp. 68–83). Berlin: Springer.

  27. Lanese, I., Guidi, C., Montesi, F., & Zavattaro, G. (2008). Bridging the gap between interaction- and process-oriented choreographies. In Sixth IEEE international conference on software engineering and formal methods (pp. 323–332).

  28. Mazouzi, H., Fallah-Seghrouchni, A. E., & Haddad, S. (2002). Open protocol design for complex interactions in multi-agent systems. In Autonomous agents & multiagent systems (AAMAS) (pp. 517–526). ACM.

  29. Montali, M., Calvanese, D., & De Giacomo, G. (2014). Verification of data-aware commitment-based multiagent system. In A. L. C. Bazzan, M. N. Huhns, A. Lomuscio, & P. Scerri (Eds.), Autonomous agents and multi-agent systems (AAMAS) (pp. 157–164). Paris, France: IFAAMAS.

    Google Scholar 

  30. Moody, D. L. (2009). The “physics” of notations: Toward a scientific basis for constructing visual notations in software engineering. IEEE Transactions on Software Engineering, 35(6), 756–779.

    Article  Google Scholar 

  31. Moody, D. L., & van Hillegersberg, J. (2009) Evaluating the visual syntax of UML: An analysis of the cognitive effectiveness of the UML family of diagrams. In D. Gasevic, R. Lämmel, & E. V. Wyk (Eds.), First international conference on software language engineering, volume 5452 of lecture notes in computer science (pp. 16–34). Berlin: Springer.

  32. Nigam, A., & Caswell, N. S. (2003). Business artifacts: An approach to operational specification. IBM Systems Journal, 42(3), 428–445.

    Article  Google Scholar 

  33. Reisig, W. (1985). Petri nets: An introduction. EATCS Monographs on Theoretical Computer Science. Berlin: Springer.

  34. Singh, M. P. (1998). Agent communication languages: Rethinking the principles. Computer, 31, 40–47.

    Article  Google Scholar 

  35. Singh, M. P. (2011). Information-driven interaction-oriented programming: BSPL, the Blindingly simple protocol language. In Proceedings of the 10th international conference on autonomous agents and multiagent systems (AAMAS) (pp. 491–498).

  36. Singh, M. P. (2011). LoST: Local state transfer—An architectural style for the distributed enactment of business protocols. In IEEE international conference on web Services (ICWS) (pp. 57–64). IEEE Computer Society.

  37. Singh, M. P. (2012). Semantics and verification of information-based protocols. In Proceedings of the 11th international conference on autonomous agents and multiagent systems (AAMAS) (pp. 1149–1156).

  38. Singh, M. P. (2014). Bliss: Specifying declarative service protocols. In Proceedings of the 11th IEEE international conference on services computing (SCC) (pp. 1–8).

  39. Taleghani, A., & Atlee, J. (2006). Semantic variations among UML StateMachines. In O. Nierstrasz, J. Whittle, D. Harel, & G. Reggio (Eds.), Model driven engineering languages and systems, volume 4199 of lecture notes in computer science (pp. 245–259). Berlin: Springer.

  40. Telang, P. R., & Singh, M. P. (2012). Comma: A commitment-based business modeling methodology and its empirical evaluation. In W. van der Hoek, L. Padgham, V. Conitzer, & M. Winikoff (Eds.), International conference on autonomous agents and multiagent systems AAMAS (pp. 1073–1080). Valencia, Spain: IFAAMAS.

    Google Scholar 

  41. Thielscher, M., & Zhang, D. (2010). From general game descriptions to a market specification language for general trading agents. In E. David, E. Gerding, D. Sarne, & O. Shehory (Eds.), Agent-mediated electronic commerce. Designing trading strategies and mechanisms for electronic markets (pp. 259–274). Berlin: Springer.

  42. Winikoff, M. (2006). Designing commitment-based agent interactions. In IEEE/WIC/ACM international conference on intelligent agent technology (IAT).

  43. Winikoff, M. (2006). Implementing flexible and robust agent interactions using distributed commitment machines. Multiagent and Grid Systems, 2(4), 365–381.

    Article  MATH  Google Scholar 

  44. Winikoff, M. (2007). Implementing commitment-based interactions. In Autonomous Agents and multi-agent systems (AAMAS) (pp. 873–880).

  45. Winikoff, M., Liu, W., & Harland, J. (2004). Enhancing commitment machines. In J. Leite, A. Omicini, P. Torroni, & P. Yolum (Eds.), Declarative agent languages and technologies II, number 3476 in lecture notes in artificial intelligence (pp. 198–220). Berlin: Springer.

  46. Winikoff, M., & Padgham, L. (2013). Agent oriented software engineering, chapter 15. In G. Weiß (Ed.), Multiagent systems (2nd ed., pp. 695–757). Cambridge, MA: MIT Press.

    Google Scholar 

  47. Yadav, N., Padgham, L., & Winikoff, M. (2015). A tool for defining agent protocols in HAPN: (demonstration). In Autonomous agents and multiagent systems (AAMAS) (pp. 1935–1936). IFAAMAS

  48. Yolum, P. (2005). Towards design tools for protocol development. In F. Dignum, V. Dignum, S. Koenig, S. Kraus, M. P. Singh, & M. Wooldridge (Eds.), Autonomous agents and multi-agent systems (AAMAS) (pp. 99–105). Utrecht, The Netherlands: ACM Press.

  49. Yolum, P., & Singh, M. (2002). Commitment machines. In J.-J. C. Meyer & M. Tambe (Eds.), Agent theories, architectures, and languages (ATAL), volume 2333 of lecture notes in computer science (pp. 235–247). Berlin: Springer

  50. Yolum, P., & Singh, M. P. (2002). Flexible protocol specification and execution: Applying event calculus planning using commitments. In Autonomous agents and multiagent systems (AAMAS) (pp. 527–534).

Download references

Acknowledgements

This work is partially supported by the Australian Research Council and Real Thing Entertainment Pty. Ltd. under Linkage Grant No. LP110100050. We would like to thank Tim Miller for discussions relating to the empirical evaluation described in Sect. 6.2. We would also like to thank the anonymous reviewers for detailed and insightful comments that helped to improve this paper.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Michael Winikoff.

Appendices

Appendix A: Evaluation materials: usability of notations for designing interactions in software systems

Firstly, thank you for participating!

Please note that this is not an examination of your individual ability, but instead is a study to assess how well people understand the three notations. As such, we would like participants to attempt to answer correctly and honestly, but do not feel pressured if you feel that you cannot answer some questions.

There are four parts to this test:

  1. 1.

    A brief pre-survey

  2. 2.

    Brief comprehension questions about three different interaction protocols

  3. 3.

    Creating a new interaction protocol

  4. 4.

    A brief post-survey

Important: Please complete these parts in the order that they appear in this document.

You will also be asked to write down the time at a number of places in the test. This is so we can see how long different questions take to answer. So, if possible, please complete the tasks without taking any breaks. If you do need to take a break, please note this by writing “break from (start time) to (end time)” at the place where you take the break (e.g. “took break from 10:13 to 10:47 a.m”).

The time now is: (please fill in the current time)

Fig. 17
figure 17

The Playdate protocol in AUML

Fig. 18
figure 18

The Playdate protocol in HAPN

Fig. 19
figure 19

The Playdate protocol in the Statechart notation

Pre-survey

figure a

Footnote 20

figure b

Comprehension of protocols

The time now is: (please fill in the current time)

This section presents three interaction protocols, each in a different notation. For each protocol you will be asked a sequence of questions to test how easy the protocol is to understand.

1.1 Playdate

The following interaction protocol for the Playdate scenario is in the \(\langle \)NOTATION\(\rangle \) (e.g. Agent UML (AUML) notation). Please read the brief tutorial introduction to the notation now.

Once you have read the notation tutorial, please proceed.

The time now is: (please fill in the current time)

The protocol below captures an interaction where the system (“S”) is organising a play date for a user (“U”). In order to confirm the playdate the system needs to know who the playdate is with (“person”), where it will be held (“location”), and when (“day”).

Please take a few minutes to read the protocol in Fig. 17. Note that v can be any one of day, person, or location. (Note: the other versions of the Playdate protocol, in the other two notations, can be found in Figs. 18 and 19.)

Once you have finished reading the protocol in Fig. 17, please proceed.

The time now is: (please fill in the current time)

The following questions each give a sequence of messages. In some cases ending with “...” to indicate that there may be other messages. For each sequence please indicate whether that sequence is allowable according to the protocol (“ok”) or whether, according to the protocol, the sequence of messages cannot occur (“no”). A sequence is allowable according to a protocol if that sequence can occur, and if it is a complete interaction (i.e. the interaction can validly stop at that point). If the sequence of messages ends with “...” then there may be further messages, and so to be acceptable it only needs to be valid, i.e. it does not need to be possible for the interaction to end at that point.

For each question you will also be asked to indicate how confident you are in your answer (1 \(=\) not at all confident, to 5 \(=\) very confident).

figure c

The time now is: (please fill in the current time)

Suppose that the following sequence of messages has been sent as part of an interaction:

            requestPD ; request(day) ; giveInfo(person,Pat) ; request(day) ; giveInfo(day,Monday)

Which one or more of the following messages are allowed to be sent next according to the protocol in Fig. 17? For each prospective next message, please indicate whether it can occur, and indicate how confident you are in your answer (1 \(=\) not at all confident, 5 \(=\) very confident).

figure d

The time now is: (please fill in the current time)

1.2 Auction

The following interaction protocol for the Auction scenario is in the Hierarchical Agent Protocol Notation (HAPN). Please read the brief tutorial introduction to the notation now.

Once you have read the notation tutorial, please proceed.

The time now is: (please fill in the current time)

The protocol below captures an interaction where an Item is being auctioned by an Initiator, with a number of Participants taking part in the auction. An auction begins with the Initiator announcing the auction to all Participants (“start-auction(Item,Time)”). The auction then consists of one or more rounds. Each round begins with an announcement calling for bids (“call-for-bids(Item,CurrentPrice)”). During a bidding round a participant may bid (“bid(Item,Price)”), and each bid is either accepted or rejected by the Initiator (“accept-bid(Item)” or “reject-bid(Item)”). A Participant can also decline to bid (“no-bid(Item)”) in which case they cannot bid in the future. Once the allowed time is up, the Initiator announces the end of the auction (“end-auction(Item)”) and, if there is a winner, informs them (“inform-winner(Item,Price)”).

Please take a few minutes to read the protocol in Fig. 20. (Note: the other versions of the Auction protocol, in the other two notations, can be found in Figs. 21 and 22.)

Once you have finished reading the protocol in Fig. 20, please proceed.

The time now is: (please fill in the current time)

Fig. 20
figure 20

The Auction protocol in AUML (asterisk highlights a message to multiple recipients)

Fig. 21
figure 21

The Auction protocol in HAPN. Note that the protocol on the right (\(\mathcal {P}_\mathcal {B}\)) is a sub-protocol of state \(s_2\) (shaded) in the protocol on the left, with one instance for each active bidder agent b in Bs

Fig. 22
figure 22

The Auction protocol in the Statechart notation

The following questions each give a sequence of messages. In some cases ending with “...” to indicate that there may be other messages. For each sequence please indicate whether that sequence is allowable according to the protocol (“ok”) or whether, according to the protocol, the sequence of messages cannot occur (“no”). A sequence is allowable according to a protocol if that sequence can occur, and if it is a complete interaction (i.e. the interaction can validly stop at that point). If the sequence of messages ends with “...” then there may be further messages, and so to be acceptable it only needs to be valid, i.e. it does not need to be possible for the interaction to end at that point.

For each question you will also be asked to indicate how confident you are in your answer (1 \(=\) not at all confident, to 5 \(=\) very confident).

The notation “P1:bid(ItemA,20)” indicates that Participant number 1 bids $20 for ItemA, and “P1:accept-bid(ItemA)” indicates that the Initiator accepted the bid on ItemA by Participant 1. In addition to using “P1” and “P2”, the bids or responses relating to Participant 1 are in and those relating to Participant 2 are in .

You should assume that the examples below are auctions with two Participants (P1 and P2).

figure e
figure f
figure g
figure h
figure i

The time now is: (please fill in the current time)

Suppose that the following sequence of messages has been sent as part of an interaction:

Which one or more of the following messages are allowed to be sent next according to the protocol in Fig. 17? For each prospective next message, please indicate whether it can occur, and indicate how confident you are in your answer (1 \(=\) not at all confident, 5 \(=\) very confident).

figure j
figure k

The time now is: (please fill in the current time)

1.3 Manufacturing

The following interaction protocol for the Manufacturing scenario is in the Statechart notation. Please read the brief tutorial introduction to the notation now.

Once you have read the notation tutorial, please proceed.

The time now is: (please fill in the current time)

The protocol below captures a manufacturing scenario where raw parts are assembled into composite parts. The version we use is considerably simplified from a real scenario.

There is a table which has two jigs, each able to hold securely parts that are to be joined (see below). The table is able to rotate (but this is not captured in the simplified design). On one side of the table is a joiner robot, that is able to perform a JoinParts(Jig) action to join two parts together. On the other side of the table is a Loader robot that is able to load individual parts onto the table, and unload the finished joined part from the table (actions: LoadPart(Part) and UnloadPart(jig)). The system should support simultaneous manufacturing of two composite parts, but there is an important constraint that the relevant jig must be locked while loading, or unloading, or joining is taking place. Note that the table cannot rotate while either jig is locked, in other words locking either jig also implicitly locks the table.

figure l

Please take a few minutes to read the protocol in Figure 23. (Note: the other versions of the Manufacturing protocol, in the other two notations, can be found in Figs. 24 and 25.)

Once you have finished reading the protocol in Fig. 23, please proceed.

The time now is: (please fill in the current time)

Fig. 23
figure 23

The Manufacturing protocol in AUML

Fig. 24
figure 24

The Manufacturing protocol in HAPN

Fig. 25
figure 25

The Manufacturing protocol in the Statechart notation

The following questions each give a sequence of messages. In some cases ending with “...” to indicate that there may be other messages. For each sequence please indicate whether that sequence is allowable according to the protocol (“ok”) or whether, according to the protocol, the sequence of messages cannot occur (“no”). A sequence is allowable according to a protocol if that sequence can occur, and if it is a complete interaction (i.e. the interaction can validly stop at that point). If the sequence of messages ends with “...” then there may be further messages, and so to be acceptable it only needs to be valid, i.e. it does not need to be possible for the interaction to end at that point.

For each question you will also be asked to indicate how confident you are in your answer (1 \(=\) not at all confident, to 5 \(=\) very confident).

figure m
figure n
figure o

The time now is: (please fill in the current time)

The remaining questions involve a situation where two parts are being manufactured at the same time, which corresponds to two instances of the interaction protocol that evolve simultaneously, the notation “1:message” is used to indicate that the message is part of the first protocol (and similarly “2:message” indicates it’s part of the second protocol). In order to visually emphasise this, the messages associated with the first protocol instance are in and those associated with the second protocol instance are in .

Recall that the two parts are being manufactured on the same table, and that the table needs to be locked while parts are being loaded, joined, or unloaded.

figure p

The time now is: (please fill in the current time)

Creating a new interaction protocol

1.1 Voice-driven music system for visually impaired

Services such as Spotify and Pandora allow users to search, play, and manage music. Software that provides these services generally allow interactions via keyboard and mouse, both of which are unsuitable for visually impaired users. Hence, the need for a system that allows voice driven interactions, thus enabling visually impaired users to use such services.

We need to build a protocol specification for a system that will allow users to search for music based on certain information, select a song from the search results, and then play the selected track.

Search The user will initiate the search by providing an artist, a song keyword, or both. For the system, the song search keyword needs to be specified for it to be able to search. That is, song information is compulsory but an artist information is optional. Upon receiving the required information the system will fetch the search results. If the search results are empty, the system will convey this to the user and the search will start again from scratch.

Select The system will present search results to the user one at a time by reading a songs title and its artists name. The user can navigate through the results by sending next and previous messages. In case of an invalid navigation message (e.g., a previous message on the first result), the system will respond with an invalid command message.

Play When a user sends a play message, the song whose title and artist was most recently presented is played by the system. When a song is being played, the user can control the player be sending messages for repeating the song, pausing a song, and resuming a paused song.

Cancel The user can close the software anytime by sending a cancel message. At the level of the protocol, the cancel message simply terminates the active communication between the user and the system.

This task requires you to model a protocol specification that will meet the above requirements using the Agent UML (AUML) notation. If you make any assumptions please state them clearly. You may use any aspects of the Agent UML (AUML) notation and if needed you can add extra comments. However, please try to avoid the need for additional comments. You do not need to think about the internal development of the system, such as the programming language, etc., only the protocol specification.

Please note the time now, before you start on designing your protocol.

The time now is: (please fill in the current time)

Please write your protocol on the provided paper, noting any assumptions required.

Once you have completed the protocol, please note the time.

The time now is: (please fill in the current time)

Post-survey

(Note that the order of protocols in the post-survey was varied to match the order in which the participant used the protocols)

figure q

The time now is: (please fill in the current time)

Thank you for your time!

Appendix B: Marking rubric for the creation task

Search:

  1. 1.

    Does the protocol allow for specifying only the SongKeyword before searching?

  2. 2.

    Does it deal sensibly with an attempt by the user to search with only an Artist (not allowed, since SongKeyword is required)?

  3. 3.

    Does it allow Artist and SongKeyword to be specified in either order (if both are provided)?

  4. 4.

    Does it check for the search returning an empty result?

Select:

  1. 5.

    Does it allow the user to use Next and Prev (or similar) to navigate?

  2. 6.

    Does it check for invalid navigation? (e.g. Prev when at the start)

Play:

  1. 7.

    Does it allow for Repeat to be issued at while playing? (technically also possible while paused, but did not require this)

  2. 8.

    Does it allow for Pause & Resume, but only in alternating order? (i.e. cannot Resume unless paused, and cannot Pause unless playing)

Cancel:

  1. 9.

    Does it allow for a Cancel message to be received at any point in the interaction?

  2. 10.

    Does the Cancel message terminate the protocol?

Overall: Is the overall sequence of Search;Select;Play realized?

  1. 11.

    Is a successful search followed by reading the song details? (and hence Select)

  2. 12.

    Is a Play message followed by the protocol playing the song?

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Winikoff, M., Yadav, N. & Padgham, L. A new Hierarchical Agent Protocol Notation. Auton Agent Multi-Agent Syst 32, 59–133 (2018). https://doi.org/10.1007/s10458-017-9373-9

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10458-017-9373-9

Keywords

Navigation