2-APL UPC project.
1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2<html><head><meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"><title>Tutorial</title><link rel="stylesheet" type="text/css" href="http://www.westciv.com/style/style.css"><link href="styles.css" rel="stylesheet" type="text/css"></head>
3<body>
4<p></p><h1 style="text-align: center;">Meteorology example.</h1><p>
5 <br>
6For
7this example we will be creating an agent-based weather warning system
8using the <a href="http://www.cs.rmit.edu.au/agents/pdt/">Prometheus Design Tool</a> and the JACK programming language. The associated PDT design file can be found <a href="Meteorology%20v0.3.pd">here</a>.</p>
9<a name="top"></a>Contents:<br>
10<ul class="mylist">
11<li><a href="#problem_specification">Problem Specification</a>
12 <ul>
13 <li><a href="#analysis_overview">Analysis Overview</a></li>
14 <li><a href="#scenarios">Scenarios</a></li>
15 <li><a href="#goal_overview">Goal Overview </a>
16 <ul>
17 <li><a href="#obtain_data_scenario">Obtain Data Scenario
18 </a>
19 <ul>
20 <li><a href="#obtain_aws_data_h4">Obtain AWS data</a></li>
21 <li><a href="#obtain_taf_data_h4">Obtain TAF data </a></li>
22 </ul>
23 </li>
24 <li><a href="#alert_user">Alert User</a>
25 <ul>
26 <li><a href="#detect_alertable_situation">Detect alertable situation </a></li>
27 </ul>
28 </li>
29 <li><a href="#subscribe_user">Subscribe User </a></li>
30 </ul>
31 </li>
32 <li><a href="#system_roles">System Roles </a>
33 <ul>
34 <li><a href="#obtain_aws_data">Obtain AWS data</a></li>
35 <li><a href="#obtain_taf_data">Obtain TAF data</a></li>
36 <li><a href="#create_forecast">Create Forecast</a></li>
37 <li><a href="#check_for_high_wind">Check for High Wind</a></li>
38 <li><a href="#check_for_forecast">Check for forecast discrepancy</a></li>
39 <li><a href="#check_for_change_in_immediate_forecast">Check for change in immediate forecast</a></li>
40 <li><a href="#create_warning">Create Warning</a></li>
41 <li><a href="#add_subscription">Add Subscription</a></li>
42 <li><a href="#subscribe_to_airport">Subscribe to Airport</a></li>
43 <li><a href="#display_warning">Display Warning </a></li>
44 <li> </li>
45 </ul>
46 </li>
47 </ul>
48</li>
49<li><a href="#architectural_design">Architectural Design</a>
50 <ul>
51 <li><a href="#data_coupling">Data Coupling </a></li>
52 <li><a href="#agentrole_grouping">Agent Role Grouping </a>
53 <ul>
54 <li><a href="#airport_agent">Airport Agent</a></li>
55 <li><a href="#gui_agent">GUI Agent</a></li>
56 <li><a href="#forecaster_agent">Forecaster Agent </a></li>
57 </ul>
58 </li>
59 <li><a href="#agent_acquaintance">Agent Acquaintance </a></li>
60 <li><a href="#system_overview">System Overview</a>
61 <ul>
62 <li><a href="#data_retrival">Data Retrieval</a></li>
63 <li><a href="#subscriptions_protocol">Subscriptions Protocol</a></li>
64 <li><a href="#warnings_protocol">Warnings Protocol </a></li>
65 </ul>
66 </li>
67 </ul>
68</li>
69<li><a href="#detailed_design">Detailed Design </a>
70 <ul>
71 <li>Airport Agent </li>
72 <li>Gui Agent </li>
73 <li>Forecaster Agent </li>
74 </ul>
75</li>
76</ul>
77<span style="font-weight: bold;"><p class="h1"><a name="problem_specification"></a>Problem Specification</p>
78<span class="backtotop"><a href="#top">back to top</a></span>
79</span>The
80problem calls for a multi-agent system to provide various types of
81weather warnings to users based on forecasts and actual sensor readings
82from various airports. Any number of users should be able to subscribe
83to one or more airports and receive warnings for specific scenarios at
84those airports.<br>
85<br style="font-weight: bold;"><span style="font-weight: bold;">
86Forecast data</span><br>
87The forecast data will be sent
88from one central forecaster and will contain hourly predictions for all
89airports for 12 hours into the future. These predictions will include:<br>
90 -Predicted wind speed (in knots)<br>
91 -Predicted rainfall (in mm)<br>
92 -Predicted temperature (in degrees
93celsius)<span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span><br>
94 -</span>Predicted fog<br>
95<br><span style="font-weight: bold;">
96AWS data</span><br>
97The
98AWS data is produced from sensors on the ground at the various
99airports. This data changes every minute however will only be sent to
100the system every 15 minutes. The system is able to request additional,
101up-to-date data and this will be accurate to the nearest minute. Each
102airport will produce and send its own set of AWS data so each set will
103only contain readings for a single airport. The data includes:<br>
104 -Actual current wind speed (in knots)<br>
105 -Actual rainfall (in mm)<br>
106 -Actual current temperature (in degrees
107celsius)<br>
108 -The presence of fog<br>
109<br><span style="font-weight: bold;">
110Warnings</span><br>
111There
112are several specified situations which should trigger a warning which
113will be sent to all subscribed users. Users can then select which types
114of warnings they want displayed.<br>
115<br><span style="font-weight: bold;">
116Discrepancy between forecast and actual reading</span><br>
117A
118warning should be displayed when there is a significant difference
119between the forecast for a given hour and the actual reading.
120Specifically where:<br>
121 - There is a difference of 5 knots in
122wind speed<br>
123 - There is a difference in the presence
124of fog<br>
125<br style="font-weight: bold;"><span style="font-weight: bold;">
126High wind situation likely</span><br>
127A
128warning should be displayed where there is a significant concern that
129there will be a high wind situation at an airport in the next 6 hours.
130A high wind situation is considered likely if :<br>
131 -There is a forecast for wind greater
132than 30 knots<br>
133
134-Current wind strength is greater than 5 knots, is significantly higher
135than forecast, and is increasing fairly rapidly.<br>
136 -Wind strength is increasing, is over 20
137knots, and is higher than forecast<br>
138<br><span style="font-weight: bold;">
139Significant change in the forecast for the next 2 hours</span><br>
140A
141warning should be displayed where there is a significant difference in
142the forecast for the next 2 hours from what was previously forecast
143with respect to any of the following :<br>
144 -Whether there is a high wind situation
145of not (where high wind is considered to be 30 knots or greater)<br>
146 - The presence of fog<br>
147 -Temperature below zero<br>
148 -High rainfall situation (over 10mm)<br>
149<br><span style="font-weight: bold;">
150Starting a new Prometheus Design file</span><br>
1511. Open the Prometheus Design Tool using the command<br>
152 <span style="font-style: italic;">java
153-jar pdt_jar_file.jar<br>
154 </span>where <span style="font-style: italic;"><span style="font-style: italic;">pdt_jar_file.jar </span></span>is
155the pdt application file.<br>
156<br>
1572. Start a new design document using File | New.<br>
158<br>
1593. Give the document a name and description as shown below:<br>
160 <img src="fig1.jpg" style="width: 340px; height: 290px;" alt="Figure 1"><br>
161Figure 1: Project properties<br><br><h2 style="text-align: center;">System Specification</h2>
162<p class="h2"><a name="analysis_overview"></a>Analysis Overview Diagram</p>
163<span class="backtotop"><a href="#top">back to top</a></span>
164<br>
165The
166analysis overview diagram is designed to show the interactions between
167the system and the environment. At this abstract level it is necessary
168to identify the actors, scenarios, percepts and actions involved in the
169system. This consists of a two step process. Firstly, we identify the
170actors and the scenarios they participate in with the system. Secondly,
171we identify and define the actions and percepts between the actors and
172the system.<br>
173<br>
174The actors are all the people or external systems associated with the
175system. In our system we can identify three actors :<br>
176User
177- the end user who will be accessing the system via GUI and
178will
179be capable of viewing warnings and making subsriptions.<br>
180AWS Sensor - the individual sensors at each airport which will produce
181the actual readings<br>
182Forecaster - the person/system which will produce the 12 hour forecasts
183for each airport<br>
184<br style="color: black;"><span style="color: black;">
185The
186scenarios are the processes which the system uses to handle the
187percepts and produce the actions.</span> <span style="font-weight: bold;"></span>In our system we can identify three
188high level scenarios:<br>
189Subscribe User Scenario - the process which handles the user
190subscription and stores it.<br>
191Alert User Scenario - the process which detects an alertable situation
192and displays the warning to the user<br>
193Obtain Data Scenario - the process which subscribes to the
194sensor/forecaster and stores the incoming data.<br><span style="font-style: italic;">Note
195PDT will automatically add the name Scenario to help differentiate
196between goals with the same name and as such it is not necessary to
197include yourself.</span><br><br>
198The
199percepts are all the types information which come into the system from
200the environment. In our system we can identify three percepts:<br>
201Subscription - the subscription sent to an airport from a user.<br>
202AWS readings - the actual readings from sensors sent to the system
203every 15 minutes<br>
204TAF data - the forecasts sent from a central forecaster to the system
205every hour<br>
206<br>
207The actions are everything that is sent from the system to the
208environment. In our system we can identify four actions:<br>
209Show Warning - the warning that is displayed to the User actor via a
210GUI.<br>
211Subscribe
212AWS source/Subscribe TAF source - the system must send a subscrption to
213the airport sensors and the central forecaster, registering it as the
214destination for AWS readings and TAF data.<br>
215Request data - a request sent to an airport sensor for up to date data.<br>
216<br>
217Using
218the various buttons in the toolbar we can create the analysis diagram
219from the components we have identified. We can then link these
220components as appropriate using the Edge tool which is found in the toolbar on the left and circled in the diagram below..<br>
221<br><span style="font-weight: bold; font-style: italic;">
222Exercise: - Using the information provided above, create the Analysis
223Overview Diagram.</span><br>
224<img src="fig2.jpg" style="width: 905px; height: 447px;" alt="Figure 2. Analysis Overview Diagram"><br>
225Figure 2 : Analysis Overview Diagram<br>
226<br>
227<p class="h2"><a name="scenarios"></a>Scenarios Details </p>
228<span class="backtotop"><a href="#top">back to top</a></span>
229<br>You iterate over the scenario specification and goal diagram. They
230are inter-related. Scenarios are an example of the dynamics - the
231process of how something will (or rather, can - its just one example)
232happen. It is a sequence for simplicity of understanding, and is
233therefore <span style="font-style: italic;">one possible</span>
234sequence and should be thought of as a high level trace of a particular
235possible (common) run. Conversely, the goal hierarchy is a static
236representation - it tries to break down all the high level goals
237into subgoals.<br> Each scenario must be associated
238with some goal, that represents what that scenario is trying to
239achieve. By default, a goal is created with the same name as the
240scenario, though this can be changed: you can edit the name of the goal
241associated with the scenario in the scenario descriptor).<br>
242The scenario diagram (in the diagram pane) is not always useful. It
243exists to allow access to scenario specifications by clicking on an
244icon although these cannot also be accessed via the Entities menu. It
245also shows which scenarios are used within other scenarios which may be
246useful. While it may not need to be used in the design process, it can
247be used in cases where the top level scenario in the Analysis overview
248diagram is really a collection of discrete scenarios. This is in fact
249the case for the Obtain Data Scenario.<br><br>From the Analysis overview diagram three key scenarios which the
250system must perform have been identified. The scenario diagram can be
251used to go into these processes in more depth and identify the key
252goals, actions and percepts and the sequence in which they take place.
253It must be made clear here that the designing of a system using PDT is
254an <span style="font-style: italic;">iterative </span>process
255and it is not expected that in the first iteration, all of the
256information will be known. For example, in each of the scenario
257editors, it is possible to specify which role each goal and action
258applies to however much of this information will not be known at this
259stage of the process. Instead, leave these fields blank, and as they
260are identified in later sections of the design, you should come back
261and fill them in appropriately.<br><br><span style="font-weight: bold;">Obtain data scenario</span><br><div style="margin-left: 40px;">This
262scenario can logically be split into two separate high level processes
263- obtaining AWS data and obtaining TAF data. As these are relatively
264isolated processes, they can be separated into two different scenarios
265before describing the details. Using the Scenario diagram, you can add
266two new scenarios, namely the Obtain TAF data scenario and the Obtain
267AWS data scenario. Then using the edge tool, create a link from the
268Obtain Data scenario to each of the new scenarios.<br><br>To
269edit the details of a scenario, double click on its icon in the
270Scenario diagram to bring up the Scenario Dialog. Steps can now be
271added, removed or rearranged using the buttons at the bottom. To insert
272a step, click the Insert Step button, then choose the step type and
273name.<br>Note: This dialog can also be accessed via the Entiites menu.<br><img src="fig45.jpg" style="width: 468px; height: 539px;" alt="Fig 45"><br>Figure 45: Scenario details can be described using the Scenario Dialog, accessed by double clicking on the icon.<br><br><img src="fig27.JPG" style="width: 401px; height: 131px;" alt="Figure 27"><br>Figure 27: The Obtain Data Scenario is split into two separate scenarios<br><br><span style="font-weight: bold;">Obtain TAF data scenario</span><br><div style="margin-left: 40px;"> This
274scenario covers the necessary processes to obtain forecasts. This
275includes all goals, actions and percepts relating to the system in the
276order in which they take place:<br><div style="margin-left: 40px;">- Subscribing to the forecaster<br>- Data arriving for all airports<br>- Splitting the data into individual airports and communicating individual forecasts to the appropriate airports<br>- Receiving the individual forecast at the airport<br>- Storing the forecast in an appropriate data store</div><br> For
277each of the above processes, each can be identified as either an
278Action, Percept or Goal. Actions are processes inside the system which
279affect the external environment. Percepts are changes to the
280environment which may affect the system. Goals relate to processes
281which the system should complete internally.<br><br><span style="font-style: italic;"><span style="font-weight: bold;">Exercise:
282Using the information provided in the Analysis Overview diagram and
283your knowledge of Goals, Actions and percepts, can you identify which
284of the above processes are Goals, Percepts and Actions? Create the
285Obtain TAF scenario, adding each of the above steps with the
286correct identifier.</span></span><br><br></div></div><div style="margin-left: 40px;"><br><span style="font-weight: bold;">Obtain AWS data scenario<br></span><div style="margin-left: 40px;"><span style="font-weight: bold;"> </span>This
287scenario covers the necessary processes to obtain AWS readings from the
288sensors and store them appropriately. The following steps can be
289identified as was done with the Obtain TAF scenario:<br><br><div style="margin-left: 40px;">- Data arriving for an individual airport (Percept)<br>- Reading the incoming data (Goal)<br>- Updating beliefsets with new data (Goal)<br>- Subcribing to the forecaster (Action)<span style="font-weight: bold;"></span></div></div><div style="margin-left: 40px;">The
290sequence of steps is an important part of a scenario as knowing the
291order of events can help determine the roles which will be associated
292with them.<br><br><span style="font-style: italic;"><span style="font-weight: bold;">Exercise:
293The above steps are in a random order. Can you identify a feasible
294sequence of the steps shown above? Create the Obtain AWS Data Scenario,
295adding each of the above steps in the correct order.</span></span><br></div></div>
296<br><span style="font-weight: bold;">Subscribe User Scenario<br></span>This
297scenario covers the necessary processes to subscribe a user to the
298system. First, the user must make the subscription attempt, probably
299via a GUI. This subscription is received by the system, passed to the
300appropriate agent and stored appropriately<span style="font-weight: bold;">.</span> Thus we can identify the following steps, in order:<br><div style="margin-left: 40px;">- User makes a Subscription attempt via GUI (Percept)<br>- Create subcription and communicate with relevant agent (Goal)<br>- Update beliefs with new subscription (Goal)</div><br><span style="font-weight: bold;">Alert User Scenario<br><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span>This
301scenario covers the steps necessary to warn a user about an alertable
302situation. Once a situation is detected, by testing if any of the
303conditions described in the Problem Specification hold against the
304beliefs, a warning containing the appropriate information must be
305created. The list of subscribed users should be checked to determine
306those subscribed to receive warnings about the given airport. The
307warning should then be displayed to the user via a GUI. Thus we can
308identify the following steps, in order:<br><div style="margin-left: 40px;">- Detect Alertable situation (Goal)<br>- Create warning with relevant information (Goal)<br>- Check subscribers for given airport (Goal)<br>- Display warning to user (Action)</div><br>
309<p class="h2"><a name="goal_overview"></a>Goal Overview Diagram</p>
310<span class="backtotop"><a href="#top">back to top</a></span> <br>The
311iterative nature of the design process is very important to note when
312working with the goal overview diagram and the Scenario specifications.
313Changes made to one diagram should be reflected in the other, and PDT
314helps to ensure this by propogating some changes across automatically.
315The goal overview should still be considered a high level diagram, and
316although there is some control information (specifically with AND vs
317OR), this diagram does not show the control structure of a program.
318ANDed subgoals may not be used in all cases, only some. This detail is not considered/need at this level.<br>
319<br>
320<img src="fig3.jpg" style="width: 506px; height: 187px;" alt="Figure 3: Base goals" title="Figure 3: Base goals"><br>
321Figure 3: The automatically created high-level goals.<br>
322<br>
323From these high-level goals several sub goals can be defined. For each
324set of sub-goals either an AND or OR constraint can be attached. AND
325constraints indicate that all of the sub-goals must be achieved in
326order to achieve the parent goal. An OR constraint indicates that only
327one of the sub-goals needs to be achieved in order for the parent goal
328to be achieved. By default PDT uses an AND constraint however you can
329change to an OR constraint using the OR refinement checkbox under the
330parent goal's descriptor.<br><img src="fig41.jpg" style="width: 522px; height: 174px;" alt="Fig 41"><br>Figure 41: The OR refinement.<br>
331<br>
332<span class="h3"><a name="obtain_data_scenario" id="obtain_data_scenario"></a>Obtain Data</span><br>
333<div style="margin-left: 40px;"><span class="backtotop"><a href="#top">back to top</a></span>
334From the Problem Description it is clear that we have two distinct data
335sources and as such, the parent goal of Obtain Data can easily be split
336into two sub-goals
337of obtaining AWS data and TAF data. Each of these are seperate
338processes which must both be completed to achieve the parent goal and
339thus an AND constraint is used.<br>
340We can then break each of these sub-goals down further:<br></div>
341<p class="h4"><a style="font-weight: bold;" name="obtain_aws_data_h4"></a><span style="font-weight: bold;">Obtain AWS data</span>
342</p><p>
343<span class="backtotop"><a href="#top">back to top</a></span>
344 <br> Subgoals:<br>
345
346 -Request AWS data - as AWS data can
347optionally be requested, this goal can be added and marked as optional.<br>
348
349 -Recieve AWS data - the system needs to
350receive the AWS data and translate it into the appropriate format<br>
351
352 -Update AWS beliefs - the system needs
353to store the incoming data in an appropriate data store.<br>
354<br>
355</p><p class="h4"><a name="obtain_taf_data_h4"></a><span style="font-weight: bold;">Obtain TAF data</span></p>
356
357<span class="backtotop"><a href="#top">back to top</a></span>
358 Subgoals:<br>
359
360 -Send to airports - as the TAF data
361arrives with data for all airports, it will need to be split up and
362sent to each individual airport<br>
363
364 -Receive TAF data - each airport needs
365to receive the TAF data and translate it into the appropriate format<br>
366
367 -Update TAF beliefs - each airport needs
368to store the incoming data in an appropriate data store.<br>
369<br>
370<img src="fig4.jpg" style="width: 637px; height: 162px;" alt="Figure 4 - Obtain data subgoals"><br>
371<br>
372<br>
373<span class="h3"><a name="alert_user"></a>Alert User<br>
374</span>The alert user goal is a very high-level goal that
375encapsulates much of the system logic. There are 4 key goals we can
376identify that will need to be achieved in order to achieve the goal of
377alerting the user:
378<p class="h4"><a name="detect_alertable_situation"></a><span style="font-weight: bold;">Detect alertable situation</span></p>
379<span class="backtotop"><a href="#top">back to top</a></span><span style="font-weight: bold;">
380 </span>This
381high-level goal encapsulates all of the processing involved in
382determining if there is an alertable situation at an airport. It can
383very logically be broken down into detecting each of the different
384types of alertable situations as specified in the problem description:<br>
385
386 -Recognise change in immediate forecast<br>
387
388 -Recognise forecast discrepancy<br>
389
390 -Recognise high wind situation<br>
391
392 As it is only necessary for one of the sub-goals to succeed
393in order for the parent goal to succeed, an OR constraint can be
394utilised.<br>
395<br>
396<div style="margin-left: 40px;"> Each of these
397goals can then be broken down further into their respective subgoals:<br>
398 <span style="font-weight: bold;">Recognise change in immediate
399forecast</span><br>
400 Subgoals:<br>
401
402 -Check high wind change -<span style="font-style: italic;"> identify if there has been a
403change in the high wind situation in the immediate forecast</span><br>
404
405 -Check fog change - <span style="font-style: italic;">identify if there has been a
406change in the presence of fog in the immediate forecast</span><br>
407
408 -Check temp below zero -<span style="font-style: italic;"> identify if there has been a
409change in the presence of below zero temperatures in the immediate
410forecast</span><br>
411
412 -Check high rain - <span style="font-style: italic;">identify if there has been a
413change in the presence of high rain in the immediate forecast</span><br>
414 <img src="fig5.jpg" style="width: 425px; height: 105px;" alt="Figure 5 - Recognise change in immediate forecast"><br>
415 <span style="font-style: italic;">Figure 5: Recognise change in
416immediate forecast</span><br>
417<br>
418 <span style="font-weight: bold;">Recognise forecast discrepancy</span><br>
419 Subgoals:<br>
420
421 -Check wind - <span style="font-style: italic;">identify a discrepancy of 5
422knots or more between the forecast and actual reading</span><br>
423<span style="font-style: italic;">
424 -</span>Check
425fog - <span style="font-style: italic;">identify a
426discrepancy in the presence of fog between the forecast and actual
427reading</span><br>
428<span style="font-style: italic;">
429 <img src="fig6.jpg" style="width: 248px; height: 109px;" alt="Figure 6: Recognise forecast discrepancy"></span><br>
430<span style="font-style: italic;">
431 Figure 6: Recognise forecast discrepancy</span><br>
432<span style="font-style: italic;"></span><br>
433<span style="font-style: italic;">
434 </span><span style="font-weight: bold;">Recognise high wind situation</span><br>
435<span style="font-weight: bold;">
436 </span>Subgoals:<br>
437
438 -Check high wind - <span style="font-style: italic;">identify wind speeds of greater
439than 30 knots</span><br>
440<span style="font-style: italic;">
441 -</span>Check
442really unexpected, increasing wind - <span style="font-style: italic;">identify wind that is greater
443than 5 knots, is significantly higher than forecast and is increasing</span><br>
444<span style="font-style: italic;">
445 -</span>Check
446high, unexpected, increasing wind - <span style="font-style: italic;">identify wind that is greater
447than 20 knots, higher than forecast and </span>is increasing<br>
448 <img src="fig7.jpg" style="width: 625px; height: 119px;" alt="Figure 7 - Recognise high wind situation"><br>
449 <span style="font-style: italic;">Figure 7: Recognise high wind
450situation</span><br>
451<br>
452</div>
453<br>
454
455 As well as detecting an alertable
456situation, there are three other goals which must be achieved in order
457to achieve the Alert User goal:<br>
458<div style="margin-left: 40px;">
459 Create Warning - <span style="font-style: italic;">create a warning with an
460appropriate message<br>
461 </span>Send
462to Users - <span style="font-style: italic;">determine
463which users are subscribed and send the warning to them<br>
464 </span>Display
465Warning - <span style="font-style: italic;">display the
466warning to the user via the GUI.</span>
467 <img src="fig8.jpg" style="width: 693px; height: 361px;" alt="Fig 8 - Alert Users"><br>
468<span style="font-style: italic;">Figure 8 - Alert User
469goal hierarchy</span><br>
470<span class="h3" style="font-weight: bold;"><a name="subscribe_user"></a>Subscribe
471User<br></span>
472<span class="backtotop"><a href="#top">back to top</a></span>
473
474<div style="margin-left: 40px;">The subscribe user goal is
475relatively simple and can be split into two subgoals:<br>
476 Make
477Subscription - <span style="font-style: italic;">create a
478subscription and send it to the appropriate airport</span><br>
479<span style="font-style: italic;">
480 </span>Update Subscriptions
481Beliefs - <span style="font-style: italic;">store the
482subscription in an appropriate data store.</span><br>
483</div>
484<p class="h2"><a name="system_roles"></a>System Roles</p>
485
486<span class="backtotop"><a href="#top">back to top</a></span>
487<br>
488<div style="margin-left: 40px;">The next stage of the process is to
489group similar goals together into roles. Each role should be limited in
490scope, and be able to be described fully be 1-2 sentences. Grouping is
491done using the System Roles diagram. Select a tole icon, click on the
492diagram pane, and provide a suitable name. Then select the goal icon,
493and one by one, add goals, and connect them to the role icon using the
494arrow. Do this for each grouping of goals. It is not necessary to
495include <span style="font-style: italic;">every </span>goal
496from
497the goal hierarchy. If all of the sub goals are related to the same
498role, it will suffice to simply add the parent goal. Likewise, if all
499the sub-goals are displayed amongst various roles, it is not necessary
500to add the parent goal anywhere. The actions and percepts identified in
501the analysis overview diagram will automatically be placed in this
502diagram. Percepts and actions are also part of roles, and should be
503linked to a role in the same way as goals. Each percept and action
504should be part of some role. They can also be part of multiple roles.<br><br>While
505at this stage it is not strictly necessary to consider the agents to
506which these roles will be allocated, it is a good practice to keep
507roles small and specific so that at the appropriate time it is possible
508to consider different ways of combining things within agents.<br>
509<br>
510For this system, the following roles were identified:<br>
511<br>
512</div>
513<div style="margin-left: 40px;"><span class="h3" style="font-weight: bold;"><a name="obtain_aws_data"></a>Obtain AWS data</span><br>
514<span class="backtotop"><a href="#top">back to top</a></span>
515This role receives AWS data, both automatically and on request, and updates all necessary storage of this data..<br>
516<div style="margin-left: 40px;">Goals:<br>
517<div style="margin-left: 40px;">-Update AWS beliefs<br>
518-Recieve AWS data<br>
519-Request AWS data<br>
520</div>
521Actions:<br>
522<div style="margin-left: 40px;">-Request Data<br>
523-Subsribe AWS source data</div>
524Percepts:<br>
525<div style="margin-left: 40px;">-AWS data <br>
526</div>
527<br>
528</div>
529</div>
530<div style="margin-left: 40px;"><img src="fig9.jpg" style="width: 391px; height: 145px;" alt="Figure 9 - Obtain AWS role"><br>
531<span style="font-style: italic;">Figure 9: Obtain AWS
532data role diagram</span><br>
533<br>
534<span style="font-weight: bold;"><span class="h3"><a name="obtain_taf_data"></a>Obtain TAF data</span><br>
535<span class="backtotop"><a href="#top">back to top</a></span> </span>This is This role deals solely with receiving an individual forecast,
536translating it into the appropriate format and then storing it into an
537appropriate data store.<br>
538<div style="margin-left: 40px;">Goals:<br>
539<div style="margin-left: 40px;">-Receive TAF data<br>
540-Update TAF beliefs</div>
541</div>
542<span style="font-weight: bold;"></span><br>
543<img src="fig10.jpg" style="width: 137px; height: 124px;" alt=""><br>
544<span style="font-style: italic;">Figure 10: Obtain TAF
545data role diagram</span><br>
546<br>
547<span style="font-weight: bold;"><span class="h3"><a name="create_forecast"></a>Create Forecast</span><br>
548<span class="backtotop"><a href="#top">back to top</a></span>
549</span>This roles handles the incoming percept, then splits it and sends individual forecasts to the appropriate locations<br>
550<div style="margin-left: 40px;">Goals:<br>
551<div style="margin-left: 40px;">-Send to airports <br>
552</div>
553Percepts:<br>
554<div style="margin-left: 40px;">-TAF data</div>
555</div>
556<span style="font-weight: bold;"><span style="font-weight: bold;"></span><br>
557<img src="fig11.jpg" style="width: 225px; height: 104px;" alt=""><br>
558</span><span style="font-style: italic;">Figure 11:
559Create forecast role diagram</span><span style="font-weight: bold;"><br>
560<br>
561<span class="h3" style="font-weight: bold;"><a name="check_for_high_wind"></a>Check for High Wind</span><br>
562<span class="backtotop"><a href="#top">back to top</a></span>
563</span>This role detects high
564wind situations, which involves checking the AWS readings and TAF
565forecasts for the presence of high wind, really unexpected, increasing
566wind and high, unexpected, increasing wind.<br>
567<div style="margin-left: 40px;">Goals:<br>
568<div style="margin-left: 40px;">-Check for High wind<br>
569-Check for really unexpected, increasing wind<br>
570-Check for high, unexpected, increasing wind <br>
571</div>
572</div>
573<br>
574<img src="fig12.jpg" style="width: 408px; height: 129px;" alt=""><br>
575<span style="font-style: italic;">Figure 12: Check for
576High wind role diagram</span><br>
577<span class="h3"><a name="check_for_forecast"></a>Check for forecast
578discrepancy</span><br>
579<span class="backtotop"><a href="#top">back to top</a></span>This
580role detects a
581discrepancy in the presence of fog or high wind between forecasts and
582actual readings by comparing the AWS readings and TAF forecasts.<br>
583<div style="margin-left: 40px;">Goals:<br>
584<div style="margin-left: 40px;">-Check for fog<br>
585-Check wind</div>
586</div>
587<span style="font-weight: bold;"></span><br>
588<img src="fig13.jpg" style="width: 204px; height: 124px;" alt=""><br>
589<span style="font-style: italic;">Figure 13: Check for
590forecast discrepancy role diagram</span><br>
591<br>
592<span style="font-weight: bold;"><span class="h3"><a name="check_for_change_in_immediate_forecast"></a>Check for change in
593immediate forecast</span><br>
594<span class="backtotop"><a href="#top">back to top</a></span>
595</span>This role checks the current and recent TAF forecasts for a
596change in the immediate forecast in the areas of high wind,
597temperatures below zero, high rain or the presence of fog.<br>
598<div style="margin-left: 40px;">Goals:<br>
599<div style="margin-left: 40px;">-Check for high wind change<br>
600-Check for temp below zero change<br>
601-Check for high rain change<br>
602-Check for fog change</div>
603</div>
604<br>
605<img src="fig14.jpg" style="width: 479px; height: 132px;" alt=""><br>
606<span style="font-style: italic;">Figure 14: Check for
607change in immediate forecast role diagram</span><br>
608<br>
609<span style="font-weight: bold;"><span class="h3"><a name="create_warning"></a>Create warning</span><br>
610<span class="backtotop"><a href="#top">back to top</a></span>
611</span>This role is used to create a relevant warning message, and pass
612it on to the appropriate users by checking the user subscriptions.<br>
613<div style="margin-left: 40px;">Goals:<br>
614<div style="margin-left: 40px;">-Create Warning<br>
615-Check users</div>
616</div>
617<br>
618<img src="fig15.jpg" style="width: 333px; height: 63px;" alt=""><br>
619<span style="font-style: italic;">Figure 15: Create
620warning role diagram<br>
621<span style="font-style: italic;"><br></span></span>As with the Obtain
622TAF Data roles, the subscription process can logically be broken into
623two roles. One role to accept incoming subscriptions from a user,
624process them and pass to the appropriate airport. A separate role could
625be created to handle the subscriptions for a specific airport and store
626in a relevant datastore.<br><span style="font-weight: bold;"><span class="h3"><a name="add_subscription" id="add_subscription"></a>Add
627Subscription</span><br>
628<span class="backtotop"><a href="#top">back to top</a></span>
629</span>This role deals only with storing the subscriptions for a particular airport into an appropriate data store.<br>
630<div style="margin-left: 40px;">Goals:<br>
631<div style="margin-left: 40px;"> -Update
632Subscriptions beliefs</div>
633</div>
634<br>
635<span style="font-style: italic;"><span style="font-style: italic;"></span></span><span style="font-weight: bold;"><span style="font-weight: bold;"><img src="fig16.jpg" style="width: 190px; height: 107px;" alt=""></span></span><br>
636<span style="font-style: italic;">Figure 16: Add
637subscription role diagram</span><span style="font-weight: bold;"><span style="font-weight: bold;"><br>
638</span></span><span class="h3"><br>
639<span class="backtotop"><a href="#top">back to top</a></span>
640<span style="font-weight: bold;"><a name="subscribe_to_airport"></a>Subscribe to airport</span></span><span style="font-weight: bold;"><br>
641</span>This role must handle the user subscription from the user and pass it to the appropriate airport. and passing it to the
642appropriate airport agent.<span style="font-weight: bold;"><br>
643</span>
644<div style="margin-left: 40px;">Goals:<br>
645<div style="margin-left: 40px;">-Make subscription <br>
646</div>
647Percept:<br>
648<div style="margin-left: 40px;">-User subscription</div>
649</div>
650<span style="font-weight: bold;"><br>
651<img src="fig17.jpg" style="width: 205px; height: 146px;" alt=""></span><br>
652<span style="font-style: italic;">Figure 17: Subscribe to
653airport diagram<br>
654</span><br>
655<span class="h3" style="font-weight: bold;"><a name="display_warning"></a>Display Warning</span><span style="font-style: italic;"><br>
656</span>
657<span class="backtotop"><a href="#top">back to top</a></span>This role covers displaying the warning on the screen so
658that it can be viewed by the user.<br>
659<div style="margin-left: 40px;">Goals:<br>
660<div style="margin-left: 40px;">-Display warning</div>
661Actions:<br>
662<div style="margin-left: 40px;">-Show warning</div>
663</div>
664<br>
665<img src="fig18.jpg" style="width: 141px; height: 141px;" alt=""><br>
666<span style="font-style: italic;">Figure 18: Display
667Warning role diagram</span><br>
668<br>
669Together, this creates the following System Roles diagram:<br>
670<img src="fig19.jpg" style="width: 753px; height: 378px;" alt=""><br>
671<span style="font-style: italic;">Figure 19: Complete
672System Roles Diagram</span><span style="font-style: italic;"><span style="font-style: italic;"><br>
673<br><span style="font-style: italic;"></span></span></span>For each of
674the roles identified above it is necessary to fill in the relevant
675fields in the descriptor of the role. <br><br>An example is given below:<br><img src="fig42.jpg" style="width: 900px; height: 460px;" alt="Fig42"><span style="font-style: italic;"><span style="font-style: italic;"></span><br>Fig 42: Example Role descriptor<br><br><br></span><span style="font-weight: bold;"></span><span style="font-weight: bold;"></span><span style="font-weight: bold;"></span></div><br><h2>Scenario Specification</h2>At
676this point in the design process it is necessary to return to the key
677scenarios we identified earlier and add in the information we have on
678roles. This will also help us to determine the data stores which will
679be required by the system. We will now look at this process for the
680Obtain TAF data scenario.<br><br>By double clicking on the Obtain TAF
681Data scenario in the Scenario Diagram we can see the following steps
682already place in the Scenario Dialog:<br><br><img src="fig46.jpg" style="width: 588px; height: 539px;" alt="Fig46"><br>Figure 46: Scenario Dialog for Obtain TAF data before role descriptors are added.<br><br>For
683each of the steps we will identify the role that the step is associated
684with. In the System roles section above we have identified two roles
685which are related to the TAF data acquisition process, so it is logical
686that each step probably belongs to one of these roles. In order to
687assign a role to a step, select that step in the list and then click
688the "Edit" button. This will bring up a Edit Step dialog as shown below.<br><br><img src="fig47.JPG" style="width: 762px; height: 396px;" alt="Fig47"><br>Figure 47: Editing a step.<br><br>From
689this dialog it is possible to edit the step description, as well as
690identify the data and roles it is associated with by clicking the
691appropriate edit button. By examining our role descriptions in the
692previous sections we can determine which steps logically belong to each
693role and assign them:<br><br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Type</span></td><td style="font-weight: bold;">Step</td><td style="font-weight: bold;">Role</td></tr><tr><td>Action</td><td>SubscribeTAFSourceAgent</td><td>Create Forecast</td></tr><tr><td>Percept</td><td>TAF data Percept</td><td>Create Forecast</td></tr><tr><td>Goal</td><td>Send to Airports</td><td>Create Forecast</td></tr><tr><td>Goal</td><td>Receive TAF data</td><td>Obtain TAF data</td></tr><tr><td>Goal</td><td>Update TAF beliefs</td><td>Obtain TAF data</td></tr></tbody></table><br>Another important detail to add to the Scenario descriptors is any data
694which will be read or written by the step. This helps to identify which
695types and instances of data stores will be required. Note that there is
696a difference between data <span style="font-style: italic;">types</span> and data <span style="font-style: italic;">instances</span>.
697A data type defines the fields and queries that will be used to store
698and access the data. However there may be many data instances for any
699given data type. For example an AWS data type could be defined with the
700necessary fields and queries to store AWS readings in a suitable
701format. Many agents could then create their own instance of this data
702type and store their own beliefs inside. Identifying the data types
703which will be used helps to determine how the roles will
704be grouped into agent types.<br>
705<br>From the Obtain TAF data example given above each step must be
706considered in regards to what data it would require access to. In this
707example, only the final step of the scenario requires any data access
708as it will be required to write to a forecast data store of some
709description. In much the same way as assigning a role to a step before,
710we can assign a datastore to a step. By clicking Edit with the step
711selected we are able to edit the data which is written to by the step.
712However as we are yet to define any datastores, we will enter an
713appropriate name to create a new datastore. This datastore will then be
714propogated down to lower level of the design.<br><br><img src="fig48.jpg" style="width: 267px; height: 184px;" alt="CreateDataStore"><br><span style="font-style: italic;">Figure 48: Creating a data store.</span><br><br><span style="font-style: italic;"><span style="font-weight: bold;">Exercise: Add in the roles and data stores for each of the other Scenarios you have identified in the Scenario Diagram.</span></span><br><br><h2 class="h1"><a name="architectural_design"></a>Architectural Design</h2>The purpose of the Architectural Design phase is to do the following:<br> - group roles int o agents (using the Agent Role Grouping diagram)<br> - introduce and develop agent interactions (using the protocol diagram and system overview diagram)<br> - specify the details of the data stores in data descriptors<span style="font-weight: bold;"><br><br></span><h3><a name="agentrole_grouping"></a>Determining the agent types
715<span class="backtotop"><a href="#top">back to top</a></span></h3>
716
717<span style="font-weight: bold;"></span>It
718is now necessary to consider the different agent types which will be
719utilised by the system and assign roles to them. There are several things to consider before
720deciding on agent types and role grouping:<span style="font-weight: bold;"><br>
721</span>
722<div style="margin-left: 40px;"><span style="font-weight: bold;"></span><br>
723<span style="font-weight: bold;">Data coupling</span><br>
724<div style="margin-left: 40px;">While it is certainly
725possible to share data between agent types it can make the system more
726complex than necessary. Wherever possible, roles which use the same
727data stores should be allocated to the same agent type.</div>
728<br>
729<span style="font-weight: bold;">Coherence</span><br>
730<div style="margin-left: 40px;">It is a design decision how many agent
731types should be created. However the roles within an agent type should
732be related to each other, such that you can give a simple name to the
733agent that includes all the roles. The system is usually simpler if you
734do combine roles where it is possible, rather than having each role be
735an agent. (Agents can later be split into modules, called Capabilities,
736many of which may map back to roles).</div><br><span style="font-weight: bold;">Cardinality</span><br>
737<div style="margin-left: 40px;">Sometimes there will be many instances
738of a role needed, and sometimes only one. E.g. there would be only one
739instance of the role "Create Forecast" but there may be multiple
740instances of the role "Obtain AWS data" or "Obtain TAF data" as each
741instance, one per airport, will receive its own set of data.Roles
742requiring different cardinality should be put into different agents.</div>
743<span style="font-weight: bold;"></span><span style="font-weight: bold;"></span><br>
744<span style="font-weight: bold;"></span></div>
745<span style="font-weight: bold;"><br>
746</span>With these considerations in mind, the following agent
747types were decided upon:<span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><br>
748</span></span></span>
749<div style="margin-left: 40px;"><span style="font-weight: bold;"><a name="airport_agent"></a><span class="h3">Airport agent</span><br>
750<span class="backtotop"><a href="#top">back to top</a></span>
751</span>There will be one Airport Agent per airport. It will
752handle the updating of beliefs and all logic relating to the detection
753of alerts<span style="font-weight: bold;"><br>
754</span>Roles:<br>
755</div>
756<div style="margin-left: 40px;">
757<div style="margin-left: 40px;">-Obtain AWS Data<br>
758-Obtain TAF Data<br>
759-Add Subscription<br>
760-Check for High wind situation<br>
761-Check for Change in Immediate Forecast<br>
762-Check for Forecast Discrepancy<br>
763-Create Warning<br>
764</div>
765<br>
766<span class="h3" style="font-weight: bold;"><a name="gui_agent"></a>GUI agent</span>
767<span class="backtotop"><a href="#top">back to top</a></span><br>
768There will be one GUI Agent per user. It will handle all interactions
769with the user including the handling of user subscriptions and
770displaying of warnings.<br>
771Roles:<br>
772<div style="margin-left: 40px;">-Subscribe to Airport<br>
773-Display warnings</div>
774<br>
775<span class="h3" style="font-weight: bold;"><a name="forecaster_agent"></a>Forecaster agent</span>
776<span class="backtotop"><a href="#top">back to top</a></span><br>
777There will be one Forecaster agent in the system. It will handle the
778incoming forecasts, split them and send them to the appropriate Airport
779Agents.</div>
780<div style="margin-left: 40px;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span>Roles:<br>
781<div style="margin-left: 40px;">-Create Forecast</div>
782</div>
783<span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><br></span></span></span></span>Each
784of the roles defined in the System Roles diagram will already have
785propagated down to the the Agent-Role Grouping diagram. To create a new
786Agent type, click on the Agent tool and then click in the Agent-Role
787Grouping diagram. Using the edge tool connect each new agent type with
788the appropriate roles as determined above to produce the following
789diagram.<span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><br>
790<img src="fig23.jpg" style="width: 365px; height: 395px;" alt=""><br>
791</span></span></span></span><span style="font-style: italic;">Figure 23: Agent-role grouping
792diagram</span><br><br>For
793each of the agents it is appropriate to fill in all of the relevant
794fields in the agent descriptor. An example of this is shown below:<br><br><img src="fig43.JPG" style="width: 800px; height: 1200px;" alt="Agent Descriptor"><br>Figure 43: Agent descriptor diagram.<br>
795<br><p>
796Neither the Agent Acquaintance diagram or the Data Coupling diagram are
797essential to the design process. They can help with considering
798different combinations of agents and roles and can allow you to see how
799the system will interact and consider the coherence and flexibility of
800the system. The Agent Acquaintance diagram is not editable and only
801reflects relationships described elsewhere. While the Data Coupling
802diagram allows you to link roles to data stores, this is better done
803when describing the scenarios.<br>
804</p>
805<p class="h2"><a name="system_overview"></a>Agent Interaction</p>
806<span class="backtotop"><a href="#top">back to top</a></span>The interaction between agents and between agents and the environment is described using the <br> With the
807agent types defined, we must now consider how they will interact with
808each other and with the environment. PDT will automatically link the
809agents with their interactions with the environment so the actions and
810percepts should already be accurate. It is therefore only necessary to
811define the interactions between the agents and this can be done using
812either individual messages or through protocols. Protocols group
813messages in a single conversation together and show the legal sequence
814of message exchanges. When there are several messages relating to the
815same conversation, it is better to use a protocol and when there is
816only a single message which is sent from one agent to another this can
817simply be put on the diagram on its own.<br>
818 <br>
819 Protocols can be created by clicking on the protocol icon and adding it
820 into the diagram. Doubling clicking on the protocol will open an
821 editing window in which the protocol can be described using AUML2. AUML2 is described in this paper: Michael Winikoff.
822<i>Defining syntax and providing tool support for Agent UML using a textual
823notation</i>,
824International Journal Agent-Oriented Software Engineering, Vol. 1, No.
8252, pp.123-144, 2007. To specify a protocol, enter text into the text
826area and then click "Save". Clicking on the Diagram tab will then show
827the protocol in a graphical format. The MDP panel is obsolete and can
828be ignored.<br>
829 <br>
830 There are three interactions which need to take place between agents.
831 For each of them, it is necessary to identify the actors and agents
832 involved and each of the messages which will need to be sent. This
833 information can then be used to create the protocol diagram.<br>
834 <br>
835 <span class="h3" style="font-weight: bold;"><a name="data_retrival"></a>Data Retrieval</span><br>
836 Both the airport agent and the forecaster agent need to subscribe to
837 the appropriate data sources.<br>
838 When the forecast data arrives at the forecaster agent, it then needs
839 to be sent to the individual agents.<br>
840 There is the optional ability to send a request for AWS data at any
841 time.<br>
842 Agents:<br>
843 -Airport agent<br>
844 -Forecaster agent<br>
845 Actors:<br>
846 -Airport sensors<br>
847 -Forecaster actor<br>
848 Actions:<br>
849 -AWS subscription - sent from Airport
850 Agent to Airport sensor<br>
851 -TAF subscription - sent from Forecaster
852 agent to Forecaster<br>
853 -AWS data request - sent from Airport
854 Agent to Airport sensor<br>
855 Percepts:<br>
856 -AWS data - sent from Airport sensor to
857 Airport agent<br>
858 -TAF data - sent from Forecaster to
859 Forecaster agent<br>
860 Messages:<br>
861 -Forecast - sent from Forecaster agent
862 to Airport agent<br>
863 <br>
864 From these elements we can produce the following AUML2:<br>
865
866<div style="font-style: italic;">
867<div style="margin-left: 80px;">start Data retrieval<br>
868actor A Airport Sensor<br>
869agent B AirportAgent<br>
870actor C Forecaster<br>
871agent D ForecasterAgent<br>
872action B A subscribeAWSSourceAgent<br>
873action D C subscribeTAFSourceAgent<br>
874box loop<br>
875box opt<br>
876action B A AWSRequest<br>
877end opt<br>
878percept A B AWS DataE<br>
879percept C D TAF dataE<br>
880message D B ForecastE<br>
881end loop<br>
882finish<br>
883<br>
884</div>
885<br>
886Which will result in the following protocol diagram:<br>
887<br>
888<img src="fig24.jpg" style="width: 562px; height: 318px;" alt=""><br>
889Figure 24: Data retrieval protocol diagram<br>
890<br>
891</div>
892<span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-style: italic;"><span style="font-style: italic; font-weight: bold;"></span></span></span></span></span></span><span style="font-style: italic;"></span><br style="font-weight: bold;">
893<span style="font-weight: bold;"><span class="h3"><a name="subscriptions_protocol"></a>Subscriptions protocol</span><br>
894<span class="backtotop"><a href="#top">back to top</a></span>
895</span>The user actor will click on the GUI to subscribe to an
896airport<br>
897This subscription will get passed on to the appropriate airport agent<br>
898<br>
899Actors:<br>
900 -User actor<br>
901Agents:<br>
902 -Airport agent<br>
903 -GUI agent<br>
904Percepts:<br>
905 -Subscription - sent from User actor to
906GUI agent<br>
907Messages:<br>
908 -Subscription - sent from GUI agent to
909airport agent<br>
910<br>
911From these elements we can produce the following AUML2:<br>
912<div style="margin-left: 80px;">start SubscriptionsProtocol<br>
913actor A User<br>
914agent B GUIAgent<br>
915agent C AirportAgent<br>
916percept A B Subscription from User<br>
917message B C SubscriptionE</div>
918<br>
919Which will produce the following protocol diagram:<br>
920<img src="fig25.jpg" style="width: 345px; height: 103px;" alt=""><br>
921<span style="font-style: italic;">Figure 25: Subscription
922protocol</span><br>
923<br>
924<span style="font-weight: bold;"><span class="h3"><a name="warnings_protocol"></a>Warnings Protocol</span><br>
925<span class="backtotop"><a href="#top">back to top</a></span>
926</span>A warning will be created by an Airport Agent and sent to
927the GUI agent<br>
928The warning will then be displayed on the screen to the user.<br>
929<br>
930Actors:<br>
931 -User<br>
932Agents:<br>
933 -GUI agent<br>
934 -Airport agent<br>
935Actions:<br>
936 -Warning<br>
937Messages:<br>
938 -Warning<br>
939<br>
940From these elements we can produce the following AUML2:<br>
941<div style="margin-left: 80px;">start Warnings<br>
942actor A User<br>
943agent D GUIAgent<br>
944agent E AirportAgent<br>
945message E D WarningE<br>
946action D A Show Warning<br>
947</div>
948<br>
949Which will produce the following protocol diagram:<br>
950<img src="fig26.jpg" style="width: 345px; height: 103px;" alt=""><br>
951<span style="font-style: italic;">Figure 26: Warnings
952protocol.</span><br>
953<br><h3>Message Descriptors</h3>For each of the messages we have
954created, it is important to fill in the descriptors with as much detail
955as possible. This allows each agent to be implemented separately, using
956the protocol and message specifications to ensure they will work
957together correctly. This means it is important to describe the messages
958right down to the fields which they contain.<br><br><img style="width: 766px; height: 388px;" alt="Message Descriptor" src="fig50.JPG"><br>Figure 50: Message descriptor for ForecastE.<br><br><span style="font-style: italic;">Note the above figure does not show the all the information contained under "Carried Information". The complete text is:<br>rmit.cs.aopd.datastructures.WeatherDataRecord[]<br>where WeatherDataRecord contains:<br> float windStrength;<br> float temperature;<br> float rainfall;<br> boolean fog;<br> Date dateAndTime;</span><br><h3>Shared Data</h3>At
959this point it is also necessary to describe in more detail any of the
960data types which will be shared amongst agents. Like with the message
961descriptors, this provides a common specification so that the agents
962using the data type can be implemented separately. More detailed
963descriptions of non-shared data types can be completed at the Detailed
964Design stage.
965<h3 class="h1"><a name="detailed_design"></a>Detailed Design</h3>In
966detailed design we take one agent at a time and specify the internals
967of the agent in a manner that is consistent with the roles the agent
968has been assigned, and the interface that has been specified with both
969the environment and other agents.<br>Sometimes, as the detailed design
970is developed, it becomes necessary to modify aspects of the
971architectural design. This should be done as needed, in order to
972maintain consistency of the overall system design.<br><br>The tasks in detailed design for each agent are:<br>1) create the agent overview<br>2) create the overview of any capabilities<br>3) develop the plan descriptors<br>4) develop the event descriptors<br>5) develop the details of any data<br><br>There is substantial iteration between all of these steps within a single agent.<br><br>The
973agent overview diagram is the top level view of the agent internals,
974and inherits the interface items (data, percepts, actions and messages)
975based on the architectural design. Capabilities and plans are then
976added into the diagram in a manner similar to the other diagrams. All
977inherited entities must be connected to some capability or plan. New
978messages may be created as connections between capabilities or plans.
979New data that is internal to the agent, but shared amongst multiple
980capabilities/plans can also be added in this diagram.<br><br>Each diagram should be kept relatively simple and easy to understand, using hierarchical layers to develop details.<br><br>We will look now at the details for each agent.<br><br style="font-weight: bold;"><span style="font-weight: bold;">Airport Agent<br><br></span><div style="margin-left: 40px;"><br>The roles associated with the Airport agent are shown below:<br>
981
982
983-Obtain AWS Data<br>
984-Obtain TAF Data<br>
985-Add Subscription<br>
986-Check for High wind situation<br>
987-Check for Change in Immediate Forecast<br>
988-Check for Forecast Discrepancy<br>
989-Create Warning<br><br>From
990the System Roles diagram we can identify the goals, actions and
991percepts associated with each of the roles which the agent is assigned.
992It is envisaged that there
993should be some correlation between goals and plans, percepts and
994incoming messages, and actions and outgoing messages. This is
995not strictly enforced, and plans can achieve more than one goal
996and vise versa, more than one plan can be used to achieve the one goal.
997The percepts, incoming
998messages and actions are automatically added to the diagram as shown
999below:<br><br><img src="fig49.JPG" style="width: 537px; height: 200px;" alt="Empty Airport Agent"><br>Fig 49: Automatically propogated entities into the airport agent.<br><br>Each
1000of these entities should then be connected to either a plan, or a
1001modular collection of plans - a capability. In our example, rather than
1002performing the subscribeAWSSourceAgent action from within a plan, we
1003will perform it directly at the agent initialisation. Thus in this
1004specific instance that action will remain unconnected however that
1005should be considered uncommon.<br>For each role associated with the
1006agent, a good guide is to consider whether the goals associated with it
1007can be achieved using a single plan. If this is the case, then the
1008single plan can be inserted into the top level overview diagram. If
1009not, the plans should probably be combined into a capability which is
1010inserted at the top level diagram and contains all the plans and events
1011necessary to achieve the role's goals. <br><br>You can get a rough
1012idea of this by looking at the goals associated with the role and how
1013complicated it needs to be. Of course this may change as you start to
1014create the plans but is a good starting point.<br><br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td style="font-weight: bold;">Role</td><td style="font-weight: bold;">Goals</td><td style="font-weight: bold;">Plan/Capability?</td></tr><tr><td>Obtain AWS Data</td><td>Update AWS beliefs, Receive AWS data, Request AWS data</td><td>Capability</td></tr><tr><td>Obtain TAF Data</td><td>Update TAF beliefs, Receive TAF data</td><td>Plan</td></tr><tr><td>Add Subscription</td><td>Update Subscriptions Beliefs</td><td>Plan</td></tr><tr><td>Create Warning</td><td>Check Subscribers</td><td>Plan</td></tr><tr><td>Check for High wind Situation</td><td>Check high wind, Check really unexpected, increasing wind, Check high, unexpected, increasing wind</td><td>Capability</td></tr><tr><td>Check for Forecast Discrepancy</td><td>Check wind, Check fog</td><td>Capability</td></tr><tr><td>Check for change in immediate forecast</td><td>Check high wind change, Check high rain, Check temp below 0, Check fog change</td><td>Capability</td></tr></tbody></table><br><br><span style="font-weight: bold;">Obtain AWS Data<br></span><div style="margin-left: 40px;">For each of the plans we should consider the events which will trigger
1015the plans execution and any events or messages it will post or send.
1016The data stores which will be read from or written to should also be
1017identified.</div><div style="margin-left: 40px;"><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Update AWS beliefs, Receive AWS data</td><td>UpdateAWSP</td><td></td><td>AWS Data</td><td></td><td>AWSReadings</td></tr><tr><td>Request AWS data</td><td>RequestAWSP</td><td>Request Data Action</td><td></td><td>AWS Data Needed</td><td></td></tr></tbody></table><br>A
1018decision has been made to combine the Update AWS beliefs and Receive
1019AWS data as it can logically be achieved by the same plan. <br>From this we can produce the following detailed design:<br><br><img src="fig28.JPG" style="width: 253px; height: 249px;" alt="Figure 28"><br>Figure 28: Obtain AWS data detailed design<br></div><span style="font-weight: bold;"><br>Obtain TAF data<br><br></span><div style="margin-left: 40px;">As above we can produce the following table based on information provided in the architectural design:<br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Update TAF Beliefs, Receive TAF data</td><td>UpdateTAFP</td><td>N/A</td><td>N/A</td><td>ForecastE</td><td>forecasts</td></tr></tbody></table><br>As
1020was done with the AWS data, we can combine the receiving and updating
1021goals into one plan. This produces the following detailed design:<br><img src="fig29.JPG" style="width: 104px; height: 175px;" alt="Figure 29"><br>Figure 29: Obtain TAF data detailed design</div><br style="font-weight: bold;"><span style="font-weight: bold;">Add Subscription<br><br></span><div style="margin-left: 40px;">This
1022role relates to subscribing a user to this airport agent so that any
1023warnings created at the airport are sent to the user. A message will be
1024sent from the GUI agent associated with the user, so the airport agent
1025must simply write this to a datastore. Thus we can identify the
1026following information:<br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Update Subscriptions Beliefs</td><td>AddSubscriptionP</td><td>N/A</td><td>N/A</td><td>SubscriptionE</td><td>subscriptions</td></tr></tbody></table><br>and the following detailed design:<br><br><img src="fig30.JPG" style="width: 121px; height: 175px;" alt="Figure 30"><br>Figure 30: Add Subscription detailed design</div><br style="font-weight: bold;"><span style="font-weight: bold;">Create warning</span><br>At
1027this point it is also necessary to consider the Create Warning role as
1028it has a close relationship with each of the "checking" roles. There is
1029the potential to combine the Create Warning role with each of these
1030roles and we must consider the advantages to doing so.<br><br>The
1031Create Warning role consists of two reasonably seperate tasks. First, a
1032warning must be created with the relevant information included. Second,
1033the subscriptions datastore must be checked and the warning sent to the
1034relevant agents. Notice that there is a strong link between the first
1035task and each of the "checking roles", wherein an alertable situation
1036must be identified, and then a warning based on that information must
1037be created. From here there are two possible design options:<br><br>a) Keep create warning as a distinct role seperate from each of the checking roles:<br><img src="fig31.jpg" style="width: 141px; height: 277px;" alt="Figure 31"><br>Figure 31: Design a.<br><br>b) Combine the "Checking" roles with the Create Warning role:<br><img src="fig32.jpg" style="width: 161px; height: 175px;" alt="Figure 32"><br>Figure 32: Design b<br><br>In
1038design b, we have combined the checking for high rain with the creating
1039of a relevant warning into one plan. This makes the design less complex
1040and logically makes sense so we will go with this design,<br><br>The Create Warning Role now only consists of the following:<br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Check Subscribers</td><td>PostWarningP</td><td>N/A</td><td>N/A</td><td>NewWarningE, WarningE</td><td>subscriptions</td></tr></tbody></table><br>And the design is simply:<br><img src="fig33.jpg" style="width: 210px; height: 127px;" alt="Figure 33"><br>Figure 33: Create Role detailed design</div><span style="font-weight: bold;"><br>Check for high wind situation<br><br></span><div style="margin-left: 40px;">As
1041described in the Create Warning Role detailed design above, we are
1042integrating the creation of warnings into the same plan as the one
1043which will do the checking.<br><br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Check high wind, Create warning</td><td>ReportReallyHighWindP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>AWS_readings, forecasts</td></tr><tr><td>Check really unexpected, increasing wind, Create warning</td><td>ReportReallyUnexpectedIncreasingWindP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>AWS_readings, forecasts</td></tr><tr><td>Check high, unexpected, increasing wind, Create warning</td><td>ReportHighUnexpectedIncreasingWindP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>AWS_readings, forecasts</td></tr></tbody></table><br>From this we can create the following detailed design:<br><img src="fig34.jpg" style="width: 620px; height: 358px;" alt="Figure34"><br>Figure 34: Check High wind situation detailed design.</div>
1044<br><br><span style="font-weight: bold;">Check for Change in Immediate Forecast</span><br style="font-weight: bold;"><br><div style="margin-left: 40px;">Similar to checking for high wind, the Check For Change in Immediate Forecast role can be broken down as follows:<br><br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Check high wind change, Create warning</td><td>ReportHighWindChangeP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts</td></tr><tr><td>Check fog change, Create warning</td><td>ReportFogChangeP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts</td></tr><tr><td>Check temp below zero change, Create warning</td><td>ReportTempBelowZeroChangeP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts</td></tr><tr><td>Check high rain change, Create warning</td><td>ReportHighRainChangeP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts</td></tr></tbody></table><br>Which can be used to create the following detailed design:<br><img src="fig35.jpg" style="width: 634px; height: 350px;" alt="Figure 35"><br>Figure 35: Check for change in Immediate Forecast detailed design<br></div><br style="font-weight: bold;"><span style="font-weight: bold;">Check for Forecast Discrepancy</span><br><br><div style="margin-left: 40px;">As with the other Checking roles, Check for Forecast Discrepancy can be broken down as follows:<br><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Check Wind, Create warning</td><td>ReportWindDiscrepancyP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts, AWS_readings</td></tr><tr><td>Check Fog, Create warning</td><td>ReportFogDiscrepancyP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts, AWS_readings</td></tr><tr><td>Check Trends, Create warning</td><td>ReportTempBelowZeroChangeP</td><td>N/A</td><td>N/A</td><td>NewDataE, NewWarningE</td><td>forecasts, AWS_readings</td></tr></tbody></table><br><span style="font-style: italic;"><span style="font-weight: bold;">Exercise: Based on the information provided in the table above, create the detailed design for Check for forecast discrepancy.</span></span></div><br><span style="font-weight: bold;"><big>Capabilities</big><br><br></span></div><div style="margin-left: 80px;">Capabilities
1045are a set of related plans which achieve a common goal or common set of
1046goals. Their use helps to reduce the complexity of the design and
1047logically seperate processes into individual components. There are many
1048different ways to combine plans into capabilities and there is not
1049necessarily a right or wrong way. However a good guide to considering
1050whether a set of plans should be combined into a capability or not is
1051to ask the following questions:<br><div style="margin-left: 40px;">- Are the plans related and do they together achieve a higher level goal as identified in the Goal Overview diagram?<br>- Will putting the plans into a capability make the design simpler?<br></div><br>By asking these questions for the design so far, we can come up with the following capabilities for the airport agent design:<br><br><div style="margin-left: 40px;">-ObtainAWSdataCap<br> - This will include everything shown in the detailed design for Obtain AWS data<br>-RecogniseHighWindCap<br> - This will include everything shown in the detailed design for Check High Wind<br>-RecogniseImmediateChangeCap<br> - This will include everything shown in the detailed design for Check for Change in Immediate Forecast<br>-RecogniseForecastDiscrepancyCap<br> - This will include everything shown in the detailed design for Check for Forecast Discrepancy</div><br>Note
1052that we will not create a capability for Obtain TAF data, Add
1053Subscription or Create Warning as although these are satisfy the first
1054requirement of being a related set of plans that achieve a higher level
1055goal, they do not satisfy the second component. i.e. Putting them
1056together into a capability would not make the design any simpler.<br><br><span style="font-style: italic;"><span style="font-weight: bold;">Exercise:
1057Create each of the capabilities described above, placing the relevant
1058plans and events inside. You should be able to produce the following
1059complete detailed design for the Airport Agent:</span></span><br><br><img src="fig36.jpg" style="width: 656px; height: 407px;" alt="Figure36"><br>Figure 36: Complete detailed design for the Airport agent, with capabilities included.<br><br></div><div style="margin-left: 40px;"><br><span style="font-weight: bold;">GUI agent</span><br><br>We
1060will now create the detailed design for the GUI agent. From the
1061Agent-Role grouping diagram, we can identify two roles that the GUI
1062agent is expected to achieve:<br><br><div style="margin-left: 40px;">- Subscribe to Airport<br>- Display warning</div><br><span style="font-weight: bold;">Subscribe to airport</span><br><div style="margin-left: 40px;">This
1063role requires the GUI agent to accept an incoming subscription from the
1064user, create a subscription in an appropriate format, and send it to
1065the relevant airport. Thus we have the following table:<br><br></div><table style="text-align: left; width: 100%; margin-left: 40px;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td><span style="font-weight: bold;">Actions</span></td><td><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold;">Internal Events</td><td><span style="font-weight: bold;">Data</span></td></tr><tr><td>Make Subscription<br></td><td>MakeSubscriptionP</td><td>N/A</td><td>Subscription From User</td><td>SubscriptionE<br></td><td>N/A<br></td></tr></tbody></table><div style="margin-left: 40px;"><br>From this we can create the following detailed design:<br><br><img src="fig37.jpg" style="width: 199px; height: 206px;" alt="Figure37"><br>Figure 37: Subscribe to Airport detailed design.<br></div><br><span style="font-weight: bold;">Display Warning</span><br><div style="margin-left: 40px;">This role requires the GUI agent to receive a warning from an airport agent and display it to the user. <br><br></div><table style="text-align: left; height: 60px; margin-left: 80px; width: 1083px;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td><span style="font-weight: bold;">Goals</span></td><td><span style="font-weight: bold;">Plans</span></td><td style="width: 140px;"><span style="font-weight: bold;">Actions</span></td><td style="width: 143px;"><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold; width: 137px;">Internal Events</td><td style="width: 103px;"><span style="font-weight: bold;">Data</span></td></tr><tr><td>Display Warning<br></td><td>AlertUserP</td><td style="width: 140px;">Show Warning</td><td style="width: 143px;">N/A</td><td style="width: 137px;">WarningE<br></td><td style="width: 103px;">N/A<br></td></tr></tbody></table><div style="margin-left: 40px;"><br>From this we can create the following detailed design:<br><img src="fig38.jpg" style="width: 121px; height: 196px;" alt="Figure38"><br>Figure 38: Display Warning detailed design.<br></div><br><span style="font-weight: bold;">Capabilities<br></span><div style="margin-left: 40px;"><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span>The
1066detailed design of the GUI agent is already very simple and the use of
1067capabilities would provide no extra value. Therefore we have chosen not
1068to use any capabilities and instead keep the detailed design as below:<br><br><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span><img src="Fig39.jpg" style="width: 323px; height: 213px;" alt="Fig39"></span><br><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span>Figure 39: Complete detailed design for the GUI agent<span style="font-weight: bold;"><span style="font-weight: bold;"></span></span><br><span style="font-weight: bold;"></span></div><br><br style="font-weight: bold;"><span style="font-weight: bold;">Forecaster Agent</span><br><div style="margin-left: 40px;">From
1069the Agent-Role groupings diagram, we can see that the only role
1070associated with the Forecaster Agent is Create Forecast. This role
1071entails receiving a set of forecasts from a Forecaster, splitting them
1072into individual airports and sending them.<br><br><table style="text-align: left; height: 60px; margin-left: 0px; width: 1042px;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td style="width: 212px;"><span style="font-weight: bold;">Goals</span></td><td style="width: 186px;"><span style="font-weight: bold;">Plans</span></td><td style="width: 161px;"><span style="font-weight: bold;">Actions</span></td><td style="width: 135px;"><span style="font-weight: bold;">Percepts</span></td><td style="font-weight: bold; width: 151px;">Internal Events</td><td style="width: 147px;"><span style="font-weight: bold;">Data</span></td></tr><tr><td style="width: 212px;">Send to Airports<br></td><td style="width: 186px;">SendForecastsP</td><td style="width: 161px;">N/A</td><td style="width: 135px;">TAF data</td><td style="width: 151px;">ForecastE<br></td><td style="width: 147px;">N/A<br></td></tr></tbody></table><br>Clearly,
1073this detailed design is simple enough and using capabilities would not
1074achieve anything. The complete detailed design is as follows:<br><img src="fig40.jpg" style="width: 117px; height: 181px;" alt="Fig40"><br>Figure 40: Complete detailed design for Forecaster agent.<br><br></div><br>For
1075each plan we must fill in the relevant fields in the plan descriptor.
1076This should be as detailed as possible so that an implementor has all
1077the necessary information to implement the plan. A detailed example is
1078given below:<br><img src="fig44.jpg" style="width: 715px; height: 970px;" alt="fig44"><br><br>This concludes the complete design for the system.<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>dafsdfaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</div></body></html>