CIS2344 Assignment 2010/2011
Hugh Osborne
Contents
1
Assignment Description
1
1.1
Bots and Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
The Assignment
3
2.1
Greedy Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
What You Should Implement . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Quick Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
What You Should Implement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4
Dealer Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4.1
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4.2
What You Should Implement . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4.2.1
Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4.2.2
Managing Deals . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4.2.3
Implementing Dealer Bots
. . . . . . . . . . . . . . . . . . . . . .
6
3
Marking
7
3.1
What You Need to Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
Handing In Your Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.1
Important Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.2
What You Should Hand In . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
How Your Work Will Be Marked . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3.1
Marking Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3.2
Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3.3
Quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1
Assignment Description
1.1
Bots and Graphs
In this assignment you will be programming bots to find its way round mazes. The mazes will
be modelled as connected graphs. As the bot travels around a maze it may lose or gain resources
each time it visits a node. If a bot’s resources ever reach 0% the bot dies. The bot will always
start with its resources at 0%, but an entry node must always increase a bot’s resources. Clearly,
a bot’s resources can never exceed 100%. If a visit to a node would take the bot’s resources above
100% the bot’s resources will only be increased to a maximum of 100%.
Figure 1 shows how a simple maze might be modelled. Entrances to the maze are shown in
this colour and exits are in this colour. The indices in the nodes show the increase or decrease
in a bot’s resources, expressed as a percentage of the bot’s maximum possible resources, that will
occur each time the bot visits this node. I.e. a visit to A or F will increase a bot’s resources by
1

---

CIS2344 Assignment 2010/2011
 d
 d
 d
 
d'
 
E
d'
 
E
d
10%
dA+20% 
d B  
dC−
 
 
d d
s
 
d
 
  
d
d
T
 
d
 
d
 
d
c  
 
 d
 
d
‚ d 
©
 d 
©
 
d'
 
E
d'
 
E
d
10%
10%
dD−  
dE−
 
dF+20% 
 
d
 
d
 
d d
sd
Figure 1: A simple maze
20% (of the bot’s maximum capacity), a visit to C, D or E will decrease the bot’s resources by
10% of that capacity, and a visit to B will have no effect on a bot’s resources.
In sections 2.1 and 2.2 you will be asked to programme bots that inhabit graphs of their own.
These bots should be programmed so as to make optimal traversals of the graphs. See sections 2.1
and 2.2 for definitions of what is meant by “optimal”.
In section 2.4 the bots will be implemented as concurrent processes, and multiple bots will
inhabit the same graph. These bots may not leave a node until after they have traded with
another bot that is at the same node. This deal may increase or decrease the bots’ resources,
as detailed in section 2.4, with details of what you should implement in section 2.4.2.3. These
bots will have the option of spawning new bots, with the originator bot’s current resources shared
between the originator bot and it’s children. The aim of a concurrent bot will be for it and its
children to emerge from the graph at then end of a run in such a way as to maximise their total
resources.
1.2
Code
Some changes have been made to the code issued with the formative assignment. The main change
is that Resource is no longer an inner class of Bot but is now a class of its own. With this change
it is now possible to make use of Java generics in the Bot and Graph code. These classes now have
the signatures:
public class Bot<BotResource extends Resource,NodeResource extends Resource>
and
public class Graph<BotResource extends Resource,NodeResource extends Resource>
The idea behind this change is to make it easy to extend the Resource class to model resources
the exact value of which is uncertain (e.g. “I went into this node with my resources at 75% and
they are now at 100%, so this node must increase resources by at least 25%”), and then use the
Graph class to model a graph with these uncertain values. A consequence of this change is that
there are no longer constructors to construct graphs from graph files. Instead there are two static
methods with signatures
public static Graph<ExactResource,ExactAdjustment>
parseGraph(String file) throws BuildError
and
public static Graph<ExactResource,ExactAdjustment>
parseGraph(String graph,String java) throws BuildError
2

---

CIS2344 Assignment 2010/2011
that will do the same.
Another change is the introduction of bot “families” in the BotFamily class. This is primarily
intended for the “dealer bot” exercise (see sections 2.4 and 2.4.2.3) where your bot is allowed to
spawn new bots that will inhabit a maze at the same time as your original bot (and bots of other
students). All of your bots will have the same family name, which will be different from any other
student’s bots’ family name. This change does not affect the behaviour of your bots.
I have also introduced a TraceMode type into the Bot class. This enables you to select the
mode of tracing that you can use in your bots using the method setTraceMode. This is a static
method that will set the trace mode for all bots. Current trace mode options are:
• OFF no tracing at all
• TERMINAL print traces to the terminal
• POP UP use pop-ups to display traces
Traces are made up of the arguments of the trace(String message) method.
Finally, the Message class is also no longer an inner class. As part of your work you may
want to define your own Message class. Any Message class you implement must implement the
Cloneable interface, and therefore implement the
public Object clone() throws CloneNotSupportedException
method, which must implement a “deep” clone. See the current Message class for an example.
See the code’s javadoc documentation for further details of these and other classes.
2
The Assignment
2.1
Greedy Bot
2.1.1
Description
Your first challenge is to implement a bot that can navigate its way through mazes in such a way
as to arrive at an exit from the maze with its resources at the highest possible level. For example,
in the maze in figure (1) the maximum resource level achievable on reaching the only exit, C, is
80%. It certainly can’t be higher than this, as the only path to C passes through D, which lowers
the bot’s resources by 10% of its maximum capacity, and node C itself lowers the bot’s resources
by another 10% of that capacity. So even if the bot enters node D with its resources at 100% it
will only have 80% left by the time it reaches C.
One possible path that achieves this 80% result is A20% → B20% → A40% → B40% → A60% →
B60% → A80% → B80% → A100% → B100% → E90% → D80%. A shorter route is A20% → B20% →
E10% → F30% → F50% → F70% → F90% → F100% → E90% → D80%. Either of these paths would
be an acceptable route for a greedy bot. What is important is that the bot leaves the graph with
its resources at 80%.
Several generations of your bot will be sent through the same test graph. It is possible for bots
to leave messages at nodes for later bots to pick up (see section 1.2) so you might want to consider
using this message mechanism to improve later bots’ chances of finding an optimal route.
2.1.2
What You Should Implement
You will be provided with a class called Bot.java that already provides some of the functionality
of sequential bots. See this class’s javadoc documentation for details of those methods that are
already implemented, and of those that you must implement as part of the assignment. The later
are all declared abstract in Bot.java, and are all clearly identified in the documentation.
You will also need to implement these methods for the QuickBot class (see section 2.2). Obvi-
ously, the implementations of some of these methods will have to differ between GreedyBots and
QuickBots.
3

---

CIS2344 Assignment 2010/2011
2.2
Quick Bot
2.2.1
Description
Your second challenge is to implement bots that can find the shortest path to an exit. In the maze
shown in figure 1 A20% → E10% → D0% is not an acceptable path since the bot arrives at D with
its resources at 0% and dies. A shortest path in the maze in figure 1 is A20% → E10% → F30% →
E20% → D10%, though going back to A, rather than going to F, would be just as good. if there is
more than one “shortest” path it doesn’t matter which one your bot finds.
A single bot is unlikely to be able to find a shortest path on its own. So for this exercise it is
essential that you make use of the bots’ message mechanism. By doing this you should be able to
help successive bots to learn how to make their way through the maze. Eventually bots entering
the maze should be able to find their way directly, by the shortest path, to an exit.
2.3
What You Should Implement
You will be provided with a class called Bot.java that already provides some of the functionality
of sequential bots. See this class’s javadoc documentation for details of those methods that are
already implemented, and of those that you must implement as part of the assignment. The later
are all declared abstract in Bot.java, and are all clearly identified in the documentation.
You will also need to implement these methods for the GreedyBot class (see section 2.1).
Obviously, the implementations of some of these methods will have to differ between QuickBots
and GreedyBots.
2.4
Dealer Bot
2.4.1
Description
Dealer bots are concurrent bots, and will share the same graph with other dealer bots. For a
sequential bot, as described above, the sequence of actions is:
• enter node;
• adjust resources according to node’s effect;
• choose next node;
• go to next node.
For a concurrent bot the sequence will be
• enter node;
• adjust resources according to node’s effect
• if there is a bot waiting here to do a deal
then do a deal with that bot
else wait for such a bot to arrive (and then do a deal)
end if;
• choose next node;
• go to next node.
A deal consists of the two bots concerned deciding, individually, whether to “cooperate” or “de-
fect”. They will each know the identity of the other bot, but not the other bot’s decision. If
both bots decide to cooperate they are both rewarded with an increase of their resources by an
absolute 10% (e.g. if the bots currently have resources of 10% and 75%, and they both cooperate
their resources after the deal will be 20% and 85% respectively). The 100% ceiling for resources
4

---

CIS2344 Assignment 2010/2011
still applies. If both bots defect neither bot receives anything — their resources are unchanged.
If one bot cooperates but the other defects the defecting bot’s resources are increased by 20%
(absolute), and the cooperating bot’s resources are decreased by 5%. This is summarised in the
following table:
Bot A
Bot B
cooperates
defects
cooperates
+10%
+10%
+20%
-5%
defects
-5%
+20%
0%
0%
Bot A
Bot B
Bot A
Bot B
Bots do not participate in deals until they have travelled to a new node — i.e. a bot must have
executed at least one call of graph.move(...) before trading.
Bots will be allowed to provide a list of names of bots that they “distrust” and are not willing
to deal with.
2.4.2
What You Should Implement
2.4.2.1
Process Model
Before implementing dealer bots your should analyse the behaviour
of the bots and the nodes in the graph. This is your third challenge. For the purpose of this
analysis you can think of a node in a graph as an active process that manages deals between bots
— i.e. it waits until two offers have been received, calculates the “payoff”s, and communicates
these back to the bots.
A possible partial specification of this interaction, in ltsa, is:
const MaxBot = 3
const MaxNode = 2
set Bots = {b.[0..MaxBot]}
set Nodes = {[0..MaxNode]}
Bot = Bot[0],
Bot[node:Nodes] = (
enter[node] ->
offer[node] ->
respond[node] ->
exit[node] ->
select[new:Nodes] -> Bot[new]).
where actions enter and exit model a bot entering a node, actions offer and response model
the bot making an offer on a deal and receiving a response on that deal, and action select models
the bot selecting the next node to go to. This is a simplified model:
• There is no attempt to model the actual offer or response, all that is modelled is the making
of the offer and the receipt of the response.
• There is no attempt to model restricted connectivity of a graph — select can select any
node in the graph.
You should complete this simplified model so that it includes a model of node processes, as
described above, and combines a number of nodes and a number of bots in a Graph process, with
the correct synchronisation of actions between nodes and bots. You should use this model to
analyse, using ltsa, under which circumstances (e.g. combinations of bots and nodes) deadlock is
and isn’t possible.
5

---

CIS2344 Assignment 2010/2011
2.4.2.2
Managing Deals
Assume that we have a maze with multiple dealer bots travelling
around in it. As described in section 2.4.2.1 we can think not only of the bots as being active
processes, but also the nodes, which must manage the deals between bots. The core code of a bot
process is
do {
String nextNode = chooseNextNode();
graph.move(this,chooseNextNode());
graph.trade(this);
exitStatus = ExitStatus.ALIVE;
}
while (!graph.hasLeft(this));
Note the call of graph.trade(this) which, essentially, asks the graph to broker a deal for this
bot. The definition of trade in Graph.java is
public void trade(Bot bot) throws BotError, BotDeath {
locations.get(bot).trade(bot);
}
which gets the bot’s current location (a Node) to broker the deal. In the Node implementation
provided (in the Graph class) the trade method does nothing — no deals take place. Your
fourth challenge is to provide code that could be used in the Graph.Node class to broker deals
between bots. The relevant parts of the bot and node processes are provided in the classes
StrippedBot.java and StrippedNode.java. You should implement the trade(Bot bot) method
in StrippedNode.java, plus any other methods you feel would help in your implementation. You
may submit either a standard implementation in which every bot is willing to do a deal with every
other bot (i.e. every bot’s distrusts() method always returns an empty list [and the distrusts()
method therefore need not be consulted]) or an advanced implementation in which the result of
the distrusts() method may not be empty, so that the node also has to manage the selection of
a suitable trading partner. See section 3.3 for details of how this may affect your marks.
2.4.2.3
Implementing Dealer Bots
Your fifth challenge is to implement dealer bots which
will exhibit the behaviour described in section 2.4. A partial implementation is already provided
in TraderBot. You will need to implement the following methods:
• boolean makeOffer(Bot tradingPartner): Make an offer (cooperate or defect) for a deal
with the bot tradingPartner.
• ArrayList BotFamily distrusts(): Return an array list of the bot families your bot is
not willing to do deals with. This method is already implemented in Bot.java to return an
empty array list — i.e. the default is to be willing to do a deal with any bot.
You should also, in theory, implement the methods required for GreedyBot and QuickBot. How-
ever, any test graphs used to test your dealer bots will be relatively “bot friendly”. They will not
be as challenging as some of the graphs used to test greedy bots and quick bots. The resource
adjustments made at each node will generally be small, and with significantly more positive ad-
justments than negative. A DemoBot travelling through such a graph, using its random selection
strategy to choose the next node to go to should, on average, see its resources increase slowly and
should be unlikely to run out of resources (note that a DemoBot does not participate in deals). A
more intelligent bot would, of course, see its resources increase more rapidly.
Typically, a dealer bot will continue to travel around the graph trying to maximise its resources,
both by choosing an optimal route, in the greedy bot sense, through the graph and by making
advantageous deals. Bots will be told when the graph is going to “shut down” and will be given
time to leave the graph before the whole programme terminates. All trading ceases when the
“shutting down countdown” begins, and any bot waiting for a trading partner will be released.
6

---

CIS2344 Assignment 2010/2011
Your bot’s trading strategy will be decided by the two methods described above. Behaviour
defined by makeOffer could range from the “saintly” (always cooperate, no matter what other
bots do) through the “erratic” (just make a random choice between cooperating and defecting)
to the “satanic” (always defect, no matter what other bots do). Alternatively, you could try to
build some learning into your implementation so that your bot can adjust its behaviour based
on its observation of other bots’ behaviours. Note that when encountering any one of the three
strategies described above the rational behaviour for an “all-knowing” bot (i.e. one that knows for
certain that the bot encountered is using one of these strategies) is to choose to defect.
• If the other bot is “saintly” you will gain 20% at every encounter. This is the best possible
outcome.
• If the other bot is “erratic” you will, on average, gain 20% when the other bot cooperates, and
neither lose nor gain anything when it defects, whereas if you had cooperated the outcomes
would have been 10% and -5% respectively.
• If the other bot is “satanic” it is impossible to earn anything from a deal with it. The best
you can hope for is to break even by also defecting.
Do not assume, however, that the best strategy is always to defect. If other bots are observing
your bot’s behaviour, and basing their response on what it does, they may soon learn that your
bot is “satanic” and therefore decide always to defect when dealing with your bot. Thereafter it
would be impossible for your bot to earn anything from any further deals.
If your bot does observe that another bot is “satanic”, or exhibits some other undesirable
trading behaviour it can prevent any further deals with that bot, or any other bot from its family,
by adding the bot’s family to its list of distrusted bot families (i.e. the array list returned by
distrusts). There is a downside to this, however. The more possible trading partners you
exclude the longer you may have to wait at a node for one to come along. During this waiting
time you will not be earning any resources.
See the javadoc documentation for TraderBot.java and Bot.java for details of the methods
that are already implemented.
3
Marking
3.1
What You Need to Do
This assignment has descibed five challenges, in sections 2.1, 2.2, 2.4.2.1, ??, and 2.4.2.3. Each
challenge is worth 25% of your marks for this assignment. You should therefore aim to complete
at least four of these challenges. If you attempt all five your best four marks will count.
3.2
Handing In Your Work
3.2.1
Important Dates
Assignment hand out 12.15, Friday 4th March, 2011
Assignment hand in 12.15, Friday 6th May, 2011
Assignment hand back 12.15, Friday, 27st May, 2011
3.2.2
What You Should Hand In
You must submit your work by emailing it to me at h.r.osborne@hud.ac.uk as a zip file attach-
ment. The subject header of your email should be
student ID :
CIS2344 Assignment 2010-2011 submission
7

---

CIS2344 Assignment 2010/2011
student id
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Jav
LTS
Documenptation
p
A
p
p
p
p
a
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Bot
Dea
bots.ltsa
any other documents
p
ls
p
p
p
s
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
StrippedBot.java
p
p
p
p
p
p
p
p
Sequential
Concur
StrippedNode.java
p
rent
p
p
p
p
p
p
any other relevant code
p
p
p
p
p
p
p
GreedyBot.java
DealerBot.java
QuickBot.java
any other relevant code
any other relevant code
Figure 2: The directory structure for submitting code.
where, of course, student ID is your student ID, starting with a lower case u, followed by seven
digits. The body of your email message must confirm that you have read and understood the
University’s regulations on academic misconduct.
You must submit your work as a zip file. No other format (e.g. .rar) will be accepted. On a
Unix/Linux machine you can create a zip archive using the zip command. E.g. zip archive Directory
will create a zip archive, called archive.zip, of the folder Directory. On a Windows machine
you can use the WinZip tool.
The zip archive you submit must unpack into the directory structure shown in figure 2.
GreedyBot.java, QuickBot.java and DealerBot.java should be your implementations of chal-
lenges 2.1, 2.2, and 2.4.2.3. The LTSA directory should contain your answer to challenge 2.4.2.1,
as a ltsa process specification in the file bots.ltsa. This file should include comments detailing
how you tested your specification for deadlock. Any other documentation you wish to submit
should be in the Documentation directory.
In the file structure shown in figure 2 you should, of course, replace student id with your
student id. Your zip archive must be called student id .zip. Do not submit any other files. The
Code subdirectory should contain your implementation of your implementations of challenges 2.1,
2.2, and 2.4.2.3. You should also include as indicated any other classes (e.g. Message.java) that
you have defined. Do not resubmit any of the classes issued with this assignment. Your code will
be tested with the original code issued with the assignment. Any changes you make to this code
will be ignored. If your code relies on changes you have made to the code issued it is likely to fail
the tests when tested with the original code. If changes that you have made cause to the code
issued with the assignment cause the testing system to fail your code will not be marked.
The Documentation directory is for any other documentary files you may wish to submit. If
you feel that it is essential that these are taken into account in marking your code please say so
in the body of the email you use to submit your work.
Note the following important information
Work that is not emailed to me with a subject header as detailed above — i.e.
student ID :
CIS2344 Assignment 2010-2011 submission
will not be marked, and you will not get any feedback. If you do not confirm, in the email to
which the code is attached, that you have read and understood the University’s regulations on
academic misconduct your code will not be marked, and you will not get any feedback.
Work that is not submitted as a zip file will not be marked, and you will not get any feedback.
Work that is submitted in a file called anything other than student id .zip will not be marked
8

---

CIS2344 Assignment 2010/2011
and you will not get any feedback. A student id .zip file that does not unpack into the structure
shown in figure 2 will not be marked, and you will not get any feedback. In the programming
challenges, code that does not compile will not be marked, and you will not get any feedback.
Work that is submitted after the hand in date (see section 3.2.1) will not be marked and you
will not get any feedback.
If you have genuine reasons for not being able to hand in your work by the hand-in date
you can ask your year tutor for an extension to the deadline. Note that there is no right to an
extension, and the reasons given need to be sufficiently serious, and of sufficient duration, to justify
an extension.
Backups
You may submit a backup of your work, in the same format as described above, on a floppy,
CD or other sensible removable medium, or by submission to the module’s digital dropbox on
Blackboard, but you must also submit your work by email as detailed above. It is this work (i.e.
the work emailed to me) that will be marked.
3.3
How Your Work Will Be Marked
3.3.1
Marking Scheme
Your work will be marked both on its functionality and on its quality. Functionality is a measure
of how well your code performs its tasks, quality is a measure of how well written it is. In both case
the assessment can be comparative and/or absolute. In comparative assessment the performance
of your code is compared to that of the other students’ code, whereas in absolute assessment your
code’s performance is measure against fixed targets.
The functionality of work submitted for the five exercises will be marked as follows:
2.1 (Greedy bot) comparatively and absolutely
2.2 (Quick bot) comparatively and absolutely
2.4.2.1 (Process model — LTSA) absolutely only
2.4.2.2 (Managing deals — StrippedNode) absolutely only
2.4.2.3 (Dealer bot) comparatively only
The quality of all the Java exercises will be marked both comparatively and absolutely, while
the quality of the LTSA exercise will only be marked absolutely. Your final mark for each exercise
will be weighted 70% for functionality and 30% for quality.
3.3.2
Functionality.
To measure the functionality of work submitted for the bot exercises its performance on a number
of test graphs will be measured. For GreedyBot.java the measure will be the level of the bot’s
resources on leaving the graph, either measured agains the levels the other students’ bots achieve,
or against the theoretical maximum possible. For QuickBot.java the measure will be the length
of the route taken by the bot to get to an exit node, either measured against the lengths of the
routes taken by other students’ bots, or against the theoretical minimum length possible. For
DealerBot.java the measure will be the total resources of all members of your bot family that
exit the graph. This will be measured against the performance of other students’ bot families.
A selection of these test graphs will be released to you, along with information, where relevant,
on the targets your bots should be aiming to achieve on those tests.
The functionality of the StrippedNode and LTSA exercises will be assessed by observation of
their behaviour and by analysis of their properties to determine how well they manages synchro-
nisation of the bot processes making deals.
9

---

CIS2344 Assignment 2010/2011
3.3.3
Quality.
The comparative quality measure for your code will be calculated by submitting all code submitted
to a software quality metric analysis. This analysis will look at such things as:
• Code layout: Does the code make good use of indentation to reflect it’s structure?
• Commenting: Is the code well commented, and do the comments make use of javadoc
conventions?
• Code element names: Are user defined names sensible, and do they make use of standard
Java conventions on the use of capital and lower case letters?
• Method parameters: A large number of parameters is considered bad style.
• Method size: Methods should not be too large.
• Nesting: Deep nesting is considered bad style.
The absolute assessment of your code’s quality will come from a holistic inspection of your
code. The criteria used will be similar to the criteria applied in the software quality metric
analysis descibed above, though obviously these will be adapted to some extent for the LTSA
exercise.
Good Luck!
http://poseidon.hud.ac.uk/staff/scomhro/Courses//Texts/TextSummative
10

---

Document Outline

• Assignment Description
  • Bots and Graphs
  • Code
• The Assignment
  • Greedy Bot
    • Description
    • What You Should Implement
  • Quick Bot
    • Description
  • What You Should Implement
  • Dealer Bot
    • Description
    • What You Should Implement
      • Process Model
      • Managing Deals
      • Implementing Dealer Bots
• Marking
  • What You Need to Do
  • Handing In Your Work
    • Important Dates
    • What You Should Hand In
  • How Your Work Will Be Marked
    • Marking Scheme
    • Functionality.
    • Quality.

---