Here - Agents Lab - University of Nottingham

Recommendations

Info

attend the evaluation, leaving 45 submissions. Additionally one other studentfrom the non-ACRE group instead submitted a solution that did use ACRE.Of the remaining 21 students in the non-ACRE group, one submission wasnot included in this research as only one protocol had been attempted and thisattempt had not been successful, leaving a total of 20 non-ACRE submissions.24 submissions were received that had used ACRE. Again, one of these hasnot been included in this analysis, as the agent submitted did not successfullyinteract with any core agent. This left a total of 23 submissions using ACRE.The submissions were evaluated using both objective and subjective measures.Initially, some simple objective measures were employed to measure programmereffort (following the examples outlined in Section 2). Following this, theimplementations were examined to identify any issues that the implementationsmay have failed to address.5.1 Objective MeasuresThe principal aim of ACRE is to help developers to deal with complex communicationmore easily. As such, it is important to ensure that the use of ACRE doesnot add to the effort required to develop MASs. Objective measures are requiredto attempt to quantify programmer effort. Two simple metrics were employedfor this purpose: 1) the number of protocols implemented within a specified timeperiod and 2) the number of non-comment lines of code per protocol.The first of these can be used to compare the two participant groups in termsof the time taken to implement protocols. Because of the ordering of the tasks,participants are encouraged to implement the protocols in the same order asone another. For example, it is not productive for a participant to begin byimplementing the complex auctioneer protocols while others are implementingthe simple protocol required to open a bank account. This helps to prevent themetric being skewed by certain subjects being delayed by the order in whichthey chose to implement their system.Because there is variation in the number of protocols successfully implementedby each participant, the count of code lines is averaged for the numberof protocols implemented. Again, the clear implementation sequence means thatthis is to the greatest extent possible measuring like-with-like.Table 2. Objective measures of programmer effortProtocols Implemented Lines per ProtocolACRE 5.43 18.35Non-ACRE 5.85 27.06Table 2 shows the average number of protocols implemented by each group,along with the average number of non-comment lines of code present per protocolimplemented. For the number of protocols implemented, the difference is not93
statistically significant using an unpaired t-test for p = 0.05. There is, however,a statistically significant difference in lines per protocol using the same test.It can be seen that the participants in the ACRE group implemented marginallyfewer protocols on average within the three-hour period. However, as this differenceis not significant, it indicates that the speed of development is comparablewhether ACRE is being used or not. This suggests that ACRE does not impose asteep learning curve compared to traditional methods of conversation handling.It is interesting that the ACRE implementations did tend to have significantlyfewer lines of code per protocol. Although this is a somewhat crude metric, itdoes suggest that the automated conversation handling of ACRE does reducethe amount of code that is required in order to successfully implement protocols.Although objective measures are desirable in any evaluation, it is importantto take a subjective view of the code also. While no significant difference inthe amount of programmer effort required was observed, these metrics do notcapture the quality of the implementations. The next section presents subjectiveanalysis of the code submitted that attempts to identify this quality.5.2 Subjective AssessmentThe adoption of ACRE will be most beneficial if it improves code quality. Togauge this, the code was examined and a number of issues were found to beprevalent in the non-ACRE code. These issues meant that the solutions thatwere submitted were very closely tied to the scenario as presented, and wouldhave required much more additional work to be done for an extended MAS.By its nature, AF-AgentSpeak reacts to the receipt of messages using rulesthat have a triggering event and a context. The triggering event is a some eventthat has occurred (i.e. a change in the belief base) whereas the context is a setof beliefs that should be present for the rule to be relevant. When writing non-ACRE code in AF-AgentSpeak, the event that triggers the rule is the receipt ofan incoming message and the context consists of beliefs about the state of theconversation (checking the sender, ensuring that the message follows the correctpreceding message etc.). This can be seen in Figure 2. For the issues that wereidentified, the context of the rules were not written in the best way possible.Identification of Issues The particular issues that were identified are as follows.Words in parentheses are short descriptions that are used to refer to eachissue in the ensuing analysis:– No Checking of Message Senders (Sender): Incoming messages were matchedonly using their performative and content, with no checks in place to ensurethey were sent by the correct agent.– No Checking of Conversation Progress (Progress): As the messages followedparticular protocols, they were exchanged in a clearly-defined sequence.Many programmers did not attempt to check the context of messages thatwere received, treating them as individual messages.94
Page 2 and 3:
Proceedings of the Tenth Internatio
Page 4 and 5:
OrganisationOrganising CommitteeMeh
Page 6:
Table of ContentseJason: an impleme
Page 10 and 11:
in Sect. 3 the translation of the J
Page 12 and 13:
init_count(0).max_count(2000).(a)(b
Page 14 and 15:
For instance, a failure in the ERES
Page 16 and 17:
{plan, fun start_count_trigger/1,fu
Page 18 and 19:
single parameter, an Erlang record
Page 20 and 21:
1. Belief annotations. Even though
Page 22 and 23:
decisions taken during the design a
Page 24 and 25:
Conceptual Integration of Agents wi
Page 26 and 27:
Fig. 2. Active component structurep
Page 28 and 29:
the service provider component. As
Page 30 and 31:
Fig. 4. Web Service Invocationretri
Page 32 and 33:
01: public interface IBankingServic
Page 34 and 35:
tate them in the same way as in the
Page 36 and 37:
01: public interface IChartService
Page 38 and 39:
implementations being available for
Page 41:
deliberative behavior in BDI archit
Page 44 and 45: layer modules (i.e. nodes) can be d
Page 46 and 47: different methods to choose the cur
Page 48 and 49: also a single scheduler module, imp
Page 50 and 51: andom choice (OR), conditional choi
Page 52 and 53: - Dealing with conflicts based on p
Page 54 and 55: 5. Brooks, R. A. (1991) Intelligenc
Page 56 and 57: An Agent-Based Cognitive Robot Arch
Page 58 and 59: It has been argued that building ro
Page 60 and 61: EnvironmentHardwareLocal SoftwareC+
Page 62 and 63: a cognitive layer can connect as a
Page 64 and 65: can reliably be differentiated and
Page 66 and 67: 4 ExperimentTo evaluate the feasibi
Page 68 and 69: learn or gain knowledge from experi
Page 70 and 71: A Programming Framework for Multi-A
Page 72 and 73: exchange and storage of tuples (key
Page 74 and 75: Although some success [13] [14] hav
Page 76 and 77: as well as important non-functional
Page 78 and 79: component plans have been instantia
Page 80 and 81: A in the example) can evaluate all
Page 83 and 84: 1. robot-1 issues a Localization(ro
Page 85 and 86: ACKNOWLEDGMENTThis work has been su
Page 87 and 88: The code was analysed both objectiv
Page 89 and 90: a conversation is following. Additi
Page 91 and 92: the context of a communication-heav
Page 93: Table 1. Core Agent ProtocolsAgent
Page 97 and 98: to the conversation and has a perfo
Page 99 and 100: principal reasons. Firstly, it is a
Page 101 and 102: 2. Muldoon, C., O’Hare, G.M.P., C
Page 103 and 104: In the following section we will at
Page 105 and 106: DevelopmentProductionHuman Readabil
Page 107 and 108: will then evaluate this new format
Page 109 and 110: encoder, it is first checked if the
Page 111 and 112: nents themselves. However, since th
Page 113 and 114: optimized for this format feature s
Page 115 and 116: Java serialization and Jadex Binary
Page 117 and 118: 10. P. Hoffman and F. Yergeau, “U
Page 119 and 120: Caching the results of previous que
Page 121 and 122: querying an agent’s beliefs and g
Page 123 and 124: or relative performance of each pla
Page 125 and 126: were run for 1.5 minutes; 1.5 minut
Page 127 and 128: Size N K n p c qry U c upd Update c
Page 129 and 130: epresentation. The cache simply act
Page 131 and 132: 6 ConclusionWe presented an abstrac
Page 133 and 134: Typing Multi-Agent Programs in simp
Page 135 and 136: 1 // agent ag02 iterations (" zero
Page 137 and 138: 3.1 simpAL OverviewThe main inspira
Page 139 and 140: 3.2 Typing Agents with Tasks and Ro
Page 141 and 142: Defining Agent Scripts in simpAL (F
Page 143 and 144: that sends a message to the receive
Page 145 and 146:
* error: wrong type for the param v
Page 147 and 148:
Given an organization model, it is
Page 149 and 150:
Learning to Improve Agent Behaviour
Page 151 and 152:
2.1 Agent Programming LanguagesAgen
Page 153 and 154:
choosing actions is to find a good
Page 155 and 156:
1 init module {2 knowledge{3 block(
Page 157 and 158:
of a module. For example, to change
Page 159 and 160:
if bel(on(X,Y), clear(X)), a-goal(c
Page 161 and 162:
mance. Figure 2d shows the same A f
Page 163 and 164:
the current percepts of the agent.
Page 165:
Author IndexAbdel-Naby, S., 69Alelc
show all

Here - Agents Lab - University of Nottingham

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?