2-APL UPC project.
+215
-241
+215
-241
docs/briscola_chiamata/bc-doc.tex
+215
-241
docs/briscola_chiamata/bc-doc.tex
···
1
-
%%% compile it with pdflatex
2
-
\documentclass[a4paper]{article}
3
-
\usepackage[T1]{fontenc}
4
-
\usepackage[utf8]{inputenc}
5
-
\usepackage{lmodern}
6
-
\usepackage{fancybox}
7
-
\usepackage{graphicx}
8
-
\usepackage{tabularx}
9
-
\usepackage{amssymb}
10
-
\usepackage{amsmath}
11
-
12
-
\begin{document}
13
-
14
-
\title{A Multi-Agent System for\\ playing Briscola Chiamata}
15
-
16
-
\author{Beltran Borja Fiz, Fabrizio De Santis, Marcos Gabarda\\
17
-
\small \texttt{\{beltran.borja.fiz, fabrizio.de.santis, marcos.gabarda\}@est.fib.upc.edu}\\
18
-
\\
19
-
Multi-Agent Systems Course\\
20
-
Master in Artificial Intelligence\\
21
-
Universitat Polit\`ecnica de Catalunya}
22
-
\date{\today}
23
-
24
-
\newenvironment{fminipage}%
25
-
{\begin{Sbox}\begin{minipage}}%
26
-
{\end{minipage}\end{Sbox}\fbox{\TheSbox}}
27
-
28
-
29
-
\maketitle
30
-
31
-
\tableofcontents
32
-
33
-
\newpage
34
-
35
-
\section{Introduction}\label{sec:intro}
36
-
37
-
2-APL stands for Abstract Agent Programming Language developed at the University of Utrecht as an academic tool for developing intelligent multi-agent systems.
38
-
39
-
Give it a short a introduction to the paper.
40
-
....
41
-
42
-
Why is suitable for a Multi-Agent System?
43
-
44
-
Put the following points in a discorsive form.
45
-
46
-
\begin{itemize}
47
-
\item Uncertainity (nobody knows who is actually its partner)
48
-
\item Sociality (its needed in order to discover partners/cheat opponents)
49
-
\item Coordination is needed
50
-
\begin{itemize}
51
-
\item Cooperation inside teams needed once partners are discovered
52
-
\item Competition between teams needed once partners are discovered
53
-
\end{itemize}
54
-
\item Trust/Reputation models needed
55
-
\item Main agent properties are satisfied
56
-
\begin{itemize}
57
-
\item Autonomy (players are autonomous, they plan alone once there are at least 5 players)
58
-
\item Flexibility
59
-
\item Reactivity (players has to play when its their turn)
60
-
\item Proactivity (players can decide if they want to play even if it's not their turn, players can decide to start cheating other players by sending them messages)
61
-
\item Social (players have to interact with each others in order to discover their partners)
62
-
\end{itemize}
63
-
\end{itemize}
64
-
65
-
Describe the methodoly used:
66
-
The Prometheus methodology involves 3 phases: System Specification, High-level (Architectural) Design and Detailed Design
67
-
68
-
The rest of the report is organized as follows...
69
-
70
-
\section{Game Description}
71
-
72
-
\emph{Briscola Chiamata} is the five-player version of \emph{Briscola}. Every player is dealt eight cards, so that no cards remain undealt. Then, each player, starting from the dealer's right\footnote{If the dealer is not a player, then starting from the declearer's right} and proceeding counter-clockwise, bids in an auction to declare how many points they will score. A player may pass, and hence cannot bid again in that game. The bid represents the number of points that player believes he is capable of accumulating. Bidding continues until all but one player have passed in a round. This remaining player has then "won the bid" and therefore gets to declare the Briscola. The declarer also declares a specific Briscola card (example, the ``Ace of Cups'' if Cups was the declared Briscola) and the holder of this card is then determined to be the declarer's partner. Logically, the declarer would declare the highest Briscola card he does not already hold in the hopes of creating the strongest combined hand between him and his partner.
73
-
The remaining three players are partnered with each other, without their knowledge. Each player, other than the declarer's partner, acts independently, until it is clear which players are partners. Infrequently, the declarer may declare a Briscola card he already holds (if he feels he has a very strong hand), in which case the other four players are partenered against him.
74
-
Game strategy is often devised to determine which player is partnered with the declarer, whereas the declarer's partner may devise ruses and decoy strategies to fool the other players, such as not taking a trick, or playing points on a trick that will be won by an opponent.
75
-
76
-
\paragraph{Scoring}
77
-
78
-
Each player collects tricks as per the regular version of the game, and counts points collected similarly. Partners, which are known by the end of the game, then combine their points. Game points are assigned as follows: if the declarer and partner accumulate card points greater than or equal to the points that were declared after the bidding process, then the declarer earns two game points, the partner earns one game point and the other players each lose one game point. If the declarer and partner accumulate fewer card points than declared, then the declarer loses two game points, the partner loses one game point and the other players each earn one game point. These points are accumulated after every game. The grand winner is the player with the most points at the end of the last match. Note that if the declarer calls a Briscola he holds, then the declarer will win or lose four points, and every other player will win or lose one point.
79
-
80
-
\section{System Specification}\label{sec:sysspec}
81
-
82
-
In this phase, actors (human or software) expected to interact with the system, are identified, along with the interface to the system in terms of actions and percepts; system goals are elaborated, and scenarios described in terms of sequences of steps are developed. Roles encompassing small chunks of functionality (identified by goals, percepts and actions) are described and captured.
83
-
84
-
\subsection{Analysis Overview Diagram}
85
-
86
-
The analysis overview diagram is designed to show the interactions between the system and the environment. At this abstract level it is necessary to identify the actors, scenarios, percepts and actions involved in the system. This consists of a two step process. Firstly, we identify the actors and the scenarios they participate in with the system. Secondly, we identify and define the actions and percepts between the actors and the system.
87
-
88
-
The actors are all the people or external systems associated with the system. The scenarios are the processes which the system uses to handle the percepts and produce the actions. The percepts are all the types information which come into the system from the environment. The actions are everything that is sent from the system to the environment.
89
-
90
-
%Specify key external actors that will use the system, and key scenarios they will be involved in.
91
-
%Link the actors to the scenarios they are involved in, using percepts and actions. Percepts are signals from actor to system. Actions are responses from the system, possibly directed towards a particular actor. This diagram can be used very freely to sketch a design of the system.
92
-
93
-
Actors:
94
-
\begin{itemize}
95
-
\item User: user of the system
96
-
\end{itemize}
97
-
98
-
Scenarios:
99
-
\begin{itemize}
100
-
\item Start the game scenario: join requests are received. Two options are possible: the request is accepted or queued. A message is then sent back acknowledging the request.
101
-
\item Dealing scenario: if there are 5 players subscribed in the system, then a card dealer is chosen that shuffle the deck and deal the cards to all the players.
102
-
\item Bidding scenario: once the dealing is over, players can start bidding in turn. The player who wins the bid, must declare the Briscola card. If nobody bids, then the game has to be restarted.
103
-
\item Play the Game scenario: once the Briscola card has been declared, the players start playing. The teams setting is unknown to all the players until the Briscola card is played. The players have to update their beliefs about teams setting each time a card is played. Of course, cheating is part of the game. Communication (sign exchange) among players is allowed to exchange information about players and cards. After each hand, points are counted.
104
-
\item End the game scenario: once the winner team is declared, scoring is updated and players are released from the system.
105
-
\end{itemize}
106
-
107
-
Inputs/outputs (percepts/actions)
108
-
\begin{table}[htp]
109
-
\begin{tabular}{|l|l|}
110
-
Join request & Subscribe user and manage request (the request has been accepted or queued) \\
111
-
\hline
112
-
5 players in the system & Choose the card dealer and start shuffling and dealing cards to the players \\
113
-
\hline
114
-
Dealing is over & Start bidding in turn \\
115
-
\hline
116
-
Bidding is over & Declare the Briscola card \\
117
-
\hline
118
-
Briscola declared & Start playing in turn \\
119
-
\hline
120
-
Card played & Update internal beliefs about teams setting \\
121
-
\hline
122
-
Message from other players (Sign exchange) & Update internal beliefs about teams setting \\
123
-
\hline
124
-
The hand is over & Count points \\
125
-
\hline
126
-
The game is over & Declare the winner \\
127
-
\hline
128
-
Winner declared & Update the system scoring \\
129
-
\hline
130
-
System scoring updated & Release the agents from the system \\
131
-
\hline
132
-
\end{tabular}
133
-
\end{table}
134
-
135
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/analysis_overview.png}
136
-
137
-
\subsection{Scenarios Diagram}
138
-
139
-
Scenarios are an example of the dynamics, the process of how something can happen. Conversely, the goal hierarchy is a static representation - it tries to break down all the high level goals into subgoals. Each scenario must be associated with some goal, that represents what that scenario is trying to achieve.
140
-
141
-
\begin{enumerate}
142
-
\item Start the game scenario
143
-
\begin{itemize}
144
-
\item Register players and inform them to wait if there are less than 5 players registered
145
-
\item Queue players if there are already 5 players registered
146
-
\end{itemize}
147
-
\item Dealing scenario
148
-
\begin{itemize}
149
-
\item Choose the card dealer
150
-
\item Shuffle the deck
151
-
\item Deal cards
152
-
\end{itemize}
153
-
\item Bidding scenario
154
-
\begin{itemize}
155
-
\item Start bidding in turn until the highest bid is established
156
-
\item Declare the Briscola card
157
-
\end{itemize}
158
-
\item Play the Game scenario
159
-
\begin{itemize}
160
-
\item Play cards in turn
161
-
\item Collect points for each hand
162
-
\end{itemize}
163
-
\item End the game scenario
164
-
\begin{itemize}
165
-
\item Count points
166
-
\item Declare the winner
167
-
\item Release the players
168
-
\end{itemize}
169
-
\end{enumerate}
170
-
171
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/scenarios.png}
172
-
173
-
\subsection{Goals Diagram}
174
-
175
-
The goal overview diagram is a directed acyclic graph of all goals in the system. Sub-goals can be generated by asking ``how will the system accomplish this goal'' Parent goals can be generated by asking ``why does the system accomplish this goal'' .
176
-
177
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/goal_overview.png}
178
-
179
-
\subsection{System Roles Diagram}
180
-
The next stage of the process is to group similar goals together into roles. Each role should be limited in scope, and be able to be described fully be 1-2 sentences. Grouping is done using the System Roles diagram. In a system roles diagram, we group different goals, percepts and actions under roles. This helps in further modularizing the system. The input is represented as a percept and the output as an action.
181
-
182
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/system_roles.png}
183
-
184
-
\section{High-level (Architectural) Design}\label{sec:highdesign}
185
-
186
-
In this phase, the agent types that will exist in the system are defined by combining roles, the overall structure of the system is described using a system overview diagram, and interaction protocols are used to capture the dynamics of the system in terms of legal message sequences.
187
-
188
-
\subsection{Data Coupling Diagram}
189
-
190
-
The roles that were formed in the last step of the previous phase are linked to data that has been identified as necessary for performing that role. In the data-coupling diagram you can see all roles and data types in the system.
191
-
192
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/data_coupling.png}
193
-
194
-
\subsection{Agent-Role Grouping Diagram}
195
-
196
-
In this diagram we group the roles into agent types. Decisions regarding how to group depend on role similarity, as well as analysis of data usage. The agent-role coupling diagram shows the group of roles that come under an agent.
197
-
198
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/aget-role_grouping.png}
199
-
200
-
\subsection{Agent Acquaintance Diagram}
201
-
202
-
In the agent acquaintance diagram you can see all agents within the system and which agents interact.
203
-
204
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/agent_acquaintance.png}
205
-
206
-
\subsection{System overview Diagram}
207
-
208
-
In the system overview diagram you can see all agents in the system, along with their interface and interactions. This diagram is the central diagram of the entire system design.
209
-
210
-
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/system_overview.png}
211
-
212
-
\section{Detailed Design}\label{sec:detaildesign}
213
-
214
-
n this phase, the internals of each agent are developed in terms of capabilities, events, plans and data. Detailed Design is done at the level of individual agents.
215
-
216
-
\subsection{Agent Overview Diagram}
217
-
The agent overview diagram shows the internals of an agent. There is one agent overview diagram for every agent in the system. In the detailed design, much finer details of the system are established. The messages used to communicate between the agents are decided upon. If the roles within an agent grow very large, they are grouped into capabilities. As in the system overview diagram entities can be inserted or removed and edges can be reated or deleted.
218
-
219
-
\subsection{Capability Overview Diagram}
220
-
In the capability overview diagram you can see the direct internal of a capability. This diagram allows you to specify the internals of a capability in terms of plans, or sub-capabilities and messages between them. Data internal to the capability can also be specified.
221
-
222
-
\section{Prototype}\label{sec:proto}
223
-
224
-
Description. Excerpt from the code.
225
-
226
-
\section{Conclusion}\label{sec:concl}
227
-
228
-
What's wrong with 2APL?
229
-
230
-
No security mechanisms, No documentation like a manual or of examples (only short example provided with the platform). Not all the constructs available are documented (e.g. random() or print())
231
-
232
-
If an agent requires an action not related with changing its mental state, it has to be done through the environment. It would be nice to have agents in which part of its executing plan will consist of running some classification algorithm or some numerical method which is only owned by the agent and so it could be encapsulated in its program.
233
-
234
-
The platform is well done, but it's still a tool for research
235
-
236
-
\section{Bibliography}
237
-
\nocite{*}
238
-
\bibliographystyle{plain}
239
-
\bibliography{bc-doc}
240
-
241
-
\end{document}
1
+
%%% compile it with pdflatex
2
+
\documentclass[a4paper]{article}
3
+
\usepackage[T1]{fontenc}
4
+
\usepackage[utf8]{inputenc}
5
+
\usepackage{lmodern}
6
+
\usepackage{fancybox}
7
+
\usepackage{graphicx}
8
+
\usepackage{tabularx}
9
+
\usepackage{amssymb}
10
+
\usepackage{amsmath}
11
+
12
+
\begin{document}
13
+
14
+
\title{A Multi-Agent System for\\ playing Briscola Chiamata}
15
+
16
+
\author{Beltran Borja Fiz, Fabrizio De Santis, Marcos Gabarda\\
17
+
\small \texttt{\{beltran.borja.fiz, fabrizio.de.santis, marcos.gabarda\}@est.fib.upc.edu}\\
18
+
\\
19
+
Multi-Agent Systems Course\\
20
+
Master in Artificial Intelligence\\
21
+
Universitat Polit\`ecnica de Catalunya}
22
+
\date{\today}
23
+
24
+
\newenvironment{fminipage}%
25
+
{\begin{Sbox}\begin{minipage}}%
26
+
{\end{minipage}\end{Sbox}\fbox{\TheSbox}}
27
+
28
+
29
+
\maketitle
30
+
31
+
\tableofcontents
32
+
33
+
\newpage
34
+
35
+
\section{Introduction}\label{sec:intro}
36
+
37
+
2-APL stands for Abstract Agent Programming Language , and is developed at the University of Utrecht as an academic tool for developing intelligent multi-agent systems. With its unique feature of integrating a declarative and an imperative style programming and the ability to use the JADE platform, 2APL is a resourceful environment to program in.
38
+
39
+
In a previous Paper we described the features of 2APL, along with a more formal description of the language. Its tools were presented and a few examples were showcased to see some agents in action.The aim of this Paper is to present our own prototype of a 2APL multiagent system to model the card game of Briscola Chiamata. In particular, we present in section 2 a description of the game . In the next sections we follow the Prometheus design methodology to create our system. We display the built prototype in Section 6 and w e conclude the paper in section 7 with some remarks, related works and conclusions on the overall success of the prototype.
40
+
41
+
There are hundreds of different card games, each with completely different approaches at building agents to play them. We selected Briscola Chiamata for the unique features of this game. Fistly having more computational power gives you no real advantage, so an agent being succesful will be thanks to its behaviour and its tactic and not thanks to its CPU. From a multiagent system point of view, the fact that partners in the game are unassigned and vary during the game adds a social problem for the agents to deal with : How do I recognise my partner?. Finally with the bidding system of the game, an agent also has the choice of risking more or less in a particular round. These uncertainties are what attracted us to this game and the reason why we decided to build a protoype in 2APL.
42
+
43
+
44
+
\section{Game Description}
45
+
46
+
\emph{Briscola Chiamata} is the five-player version of \emph{Briscola}. Every player is dealt eight cards, so that no cards remain undealt. Then, each player, starting from the dealer's right\footnote{If the dealer is not a player, then starting from the declearer's right} and proceeding counter-clockwise, bids in an auction to declare how many points they will score. A player may pass, and hence cannot bid again in that game. The bid represents the number of points that player believes he is capable of accumulating. Bidding continues until all but one player have passed in a round. This remaining player has then "won the bid" and therefore gets to declare the Briscola. The declarer also declares a specific Briscola card (example, the ``Ace of Cups'' if Cups was the declared Briscola) and the holder of this card is then determined to be the declarer's partner. Logically, the declarer would declare the highest Briscola card he does not already hold in the hopes of creating the strongest combined hand between him and his partner.
47
+
The remaining three players are partnered with each other, without their knowledge. Each player, other than the declarer's partner, acts independently, until it is clear which players are partners. Infrequently, the declarer may declare a Briscola card he already holds (if he feels he has a very strong hand), in which case the other four players are partenered against him.
48
+
Game strategy is often devised to determine which player is partnered with the declarer, whereas the declarer's partner may devise ruses and decoy strategies to fool the other players, such as not taking a trick, or playing points on a trick that will be won by an opponent.
49
+
50
+
\paragraph{Scoring}
51
+
52
+
Each player collects tricks as per the regular version of the game, and counts points collected similarly. Partners, which are known by the end of the game, then combine their points. Game points are assigned as follows: if the declarer and partner accumulate card points greater than or equal to the points that were declared after the bidding process, then the declarer earns two game points, the partner earns one game point and the other players each lose one game point. If the declarer and partner accumulate fewer card points than declared, then the declarer loses two game points, the partner loses one game point and the other players each earn one game point. These points are accumulated after every game. The grand winner is the player with the most points at the end of the last match. Note that if the declarer calls a Briscola he holds, then the declarer will win or lose four points, and every other player will win or lose one point.
53
+
54
+
\section{System Specification}\label{sec:sysspec}
55
+
56
+
In this phase, actors (human or software) expected to interact with the system, are identified, along with the interface to the system in terms of actions and percepts; system goals are elaborated, and scenarios described in terms of sequences of steps are developed. Roles encompassing small chunks of functionality (identified by goals, percepts and actions) are described and captured.
57
+
58
+
\subsection{Analysis Overview Diagram}
59
+
60
+
The analysis overview diagram is designed to show the interactions between the system and the environment. At this abstract level it is necessary to identify the actors, scenarios, percepts and actions involved in the system. This consists of a two step process. Firstly, we identify the actors and the scenarios they participate in with the system. Secondly, we identify and define the actions and percepts between the actors and the system.
61
+
62
+
The actors are all the people or external systems associated with the system. The scenarios are the processes which the system uses to handle the percepts and produce the actions. The percepts are all the types information which come into the system from the environment. The actions are everything that is sent from the system to the environment.
63
+
64
+
%Specify key external actors that will use the system, and key scenarios they will be involved in.
65
+
%Link the actors to the scenarios they are involved in, using percepts and actions. Percepts are signals from actor to system. Actions are responses from the system, possibly directed towards a particular actor. This diagram can be used very freely to sketch a design of the system.
66
+
67
+
Actors:
68
+
\begin{itemize}
69
+
\item User: user of the system
70
+
\end{itemize}
71
+
72
+
Scenarios:
73
+
\begin{itemize}
74
+
\item Start the game scenario: join requests are received. Two options are possible: the request is accepted or queued. A message is then sent back acknowledging the request.
75
+
\item Dealing scenario: if there are 5 players subscribed in the system, then a card dealer is chosen that shuffle the deck and deal the cards to all the players.
76
+
\item Bidding scenario: once the dealing is over, players can start bidding in turn. The player who wins the bid, must declare the Briscola card. If nobody bids, then the game has to be restarted.
77
+
\item Play the Game scenario: once the Briscola card has been declared, the players start playing. The teams setting is unknown to all the players until the Briscola card is played. The players have to update their beliefs about teams setting each time a card is played. Of course, cheating is part of the game. Communication (sign exchange) among players is allowed to exchange information about players and cards. After each hand, points are counted.
78
+
\item End the game scenario: once the winner team is declared, scoring is updated and players are released from the system.
79
+
\end{itemize}
80
+
81
+
Inputs/outputs (percepts/actions)
82
+
\begin{table}[htp]
83
+
\begin{tabular}{|l|l|}
84
+
Join request & Subscribe user and manage request (the request has been accepted or queued) \\
85
+
\hline
86
+
5 players in the system & Choose the card dealer and start shuffling and dealing cards to the players \\
87
+
\hline
88
+
Dealing is over & Start bidding in turn \\
89
+
\hline
90
+
Bidding is over & Declare the Briscola card \\
91
+
\hline
92
+
Briscola declared & Start playing in turn \\
93
+
\hline
94
+
Card played & Update internal beliefs about teams setting \\
95
+
\hline
96
+
Message from other players (Sign exchange) & Update internal beliefs about teams setting \\
97
+
\hline
98
+
The hand is over & Count points \\
99
+
\hline
100
+
The game is over & Declare the winner \\
101
+
\hline
102
+
Winner declared & Update the system scoring \\
103
+
\hline
104
+
System scoring updated & Release the agents from the system \\
105
+
\hline
106
+
\end{tabular}
107
+
\end{table}
108
+
109
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/analysis_overview.png}
110
+
111
+
\subsection{Scenarios Diagram}
112
+
113
+
Scenarios are an example of the dynamics, the process of how something can happen. Conversely, the goal hierarchy is a static representation - it tries to break down all the high level goals into subgoals. Each scenario must be associated with some goal, that represents what that scenario is trying to achieve.
114
+
115
+
\begin{enumerate}
116
+
\item Start the game scenario
117
+
\begin{itemize}
118
+
\item Register players and inform them to wait if there are less than 5 players registered
119
+
\item Queue players if there are already 5 players registered
120
+
\end{itemize}
121
+
\item Dealing scenario
122
+
\begin{itemize}
123
+
\item Choose the card dealer
124
+
\item Shuffle the deck
125
+
\item Deal cards
126
+
\end{itemize}
127
+
\item Bidding scenario
128
+
\begin{itemize}
129
+
\item Start bidding in turn until the highest bid is established
130
+
\item Declare the Briscola card
131
+
\end{itemize}
132
+
\item Play the Game scenario
133
+
\begin{itemize}
134
+
\item Play cards in turn
135
+
\item Collect points for each hand
136
+
\end{itemize}
137
+
\item End the game scenario
138
+
\begin{itemize}
139
+
\item Count points
140
+
\item Declare the winner
141
+
\item Release the players
142
+
\end{itemize}
143
+
\end{enumerate}
144
+
145
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/scenarios.png}
146
+
147
+
\subsection{Goals Diagram}
148
+
149
+
The goal overview diagram is a directed acyclic graph of all goals in the system. Sub-goals can be generated by asking ``how will the system accomplish this goal'' Parent goals can be generated by asking ``why does the system accomplish this goal'' .
150
+
151
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/goal_overview.png}
152
+
153
+
\subsection{System Roles Diagram}
154
+
The next stage of the process is to group similar goals together into roles. Each role should be limited in scope, and be able to be described fully be 1-2 sentences. Grouping is done using the System Roles diagram. In a system roles diagram, we group different goals, percepts and actions under roles. This helps in further modularizing the system. The input is represented as a percept and the output as an action.
155
+
156
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/system_specification/system_roles.png}
157
+
158
+
\section{High-level (Architectural) Design}\label{sec:highdesign}
159
+
160
+
In this phase, the agent types that will exist in the system are defined by combining roles, the overall structure of the system is described using a system overview diagram, and interaction protocols are used to capture the dynamics of the system in terms of legal message sequences.
161
+
162
+
\subsection{Data Coupling Diagram}
163
+
164
+
The roles that were formed in the last step of the previous phase are linked to data that has been identified as necessary for performing that role. In the data-coupling diagram you can see all roles and data types in the system.
165
+
166
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/data_coupling.png}
167
+
168
+
\subsection{Agent-Role Grouping Diagram}
169
+
170
+
In this diagram we group the roles into agent types. Decisions regarding how to group depend on role similarity, as well as analysis of data usage. The agent-role coupling diagram shows the group of roles that come under an agent.
171
+
172
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/aget-role_grouping.png}
173
+
174
+
\subsection{Agent Acquaintance Diagram}
175
+
176
+
In the agent acquaintance diagram you can see all agents within the system and which agents interact.
177
+
178
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/agent_acquaintance.png}
179
+
180
+
\subsection{System overview Diagram}
181
+
182
+
In the system overview diagram you can see all agents in the system, along with their interface and interactions. This diagram is the central diagram of the entire system design.
183
+
184
+
\includegraphics[keepaspectratio,scale=0.3]{pdt/images/architectural_design/system_overview.png}
185
+
186
+
\section{Detailed Design}\label{sec:detaildesign}
187
+
188
+
n this phase, the internals of each agent are developed in terms of capabilities, events, plans and data. Detailed Design is done at the level of individual agents.
189
+
190
+
\subsection{Agent Overview Diagram}
191
+
The agent overview diagram shows the internals of an agent. There is one agent overview diagram for every agent in the system. In the detailed design, much finer details of the system are established. The messages used to communicate between the agents are decided upon. If the roles within an agent grow very large, they are grouped into capabilities. As in the system overview diagram entities can be inserted or removed and edges can be reated or deleted.
192
+
193
+
\subsection{Capability Overview Diagram}
194
+
In the capability overview diagram you can see the direct internal of a capability. This diagram allows you to specify the internals of a capability in terms of plans, or sub-capabilities and messages between them. Data internal to the capability can also be specified.
195
+
196
+
\section{Prototype}\label{sec:proto}
197
+
198
+
Description. Excerpt from the code.
199
+
200
+
\section{Conclusion}\label{sec:concl}
201
+
202
+
What's wrong with 2APL?
203
+
204
+
No security mechanisms, No documentation like a manual or of examples (only short example provided with the platform). Not all the constructs available are documented (e.g. random() or print())
205
+
206
+
If an agent requires an action not related with changing its mental state, it has to be done through the environment. It would be nice to have agents in which part of its executing plan will consist of running some classification algorithm or some numerical method which is only owned by the agent and so it could be encapsulated in its program.
207
+
208
+
The platform is well done, but it's still a tool for research
209
+
210
+
\section{Bibliography}
211
+
\nocite{*}
212
+
\bibliographystyle{plain}
213
+
\bibliography{bc-doc}
214
+
215
+
\end{document}