Java程序辅导

Informatics 2c Assignment 1
Introduction
In this assignment, you will be expected to work in groups of 3. Each group must have a leader and 
the leader of each group should send an email to the TA for this course (Kate Ho, 
K.L.Ho@sms.ed.ac.uk) saying who is in the group, including names and matriculation numbers. You 
should do this by end of week 5 (4pm, 20th October 2006). 
The deadline for this assignment is 4pm, 3rd November 2006. 
Please note that whilst the lecturer and the TA will do their best to answer all questions quickly, this 
does not translate to questions being answered the night before an assignment is due. You are 
expected to start this assignment as soon as possible – this is for your own good, not ours! The 
weight of this part of the coursework is 50% (of the Software Engineering part). The next assignment 
is worth 50% (again, of the marks for the Software Engineering thread of the course). This means that 
each of the two SE assignments is worth 25% of the total coursework marks for Inf2c. 
Submission guidelines are available towards the end of this document. 
Background
You and your team are part of a project assigned the task of writing the software to control a new rail-
based railway transport system. The system is intended to enable individual traffic of people and 
goods, which today is mainly conducted by cars and trucks, by autonomously acting shuttles on rail. 
This autonomy is supposed to eliminate the disadvantages of modern trains concerning individual 
transport. 
Currently you are engaged in a feasibility study which involves writing simulation software to support 
experimentation with different algorithms etc., in order to mitigate some of the risks associated with 
this transport revolution. Software will be developed to simulate the behaviour and interactions of all 
relevant parties. In this exercise, Task 1 involves getting an overview of the intended behaviour of the 
real-world system; Tasks 2, 3 and 4 deal with the development of the kernel of the simulation system; 
Task 5 concerns the development of one possible version of the software for an individual shuttle.
Fortunately, because this is a big project, other members of your project team have actually met with 
the client and have produced a system overview of the whole system. They have kindly provided you 
with a copy. See Appendix A: Shuttle System Overview. 
Task 1 – Understanding the system
For your first task, your team has to read through the System Overview document and answer the 
following questions [1 mark each – 10 in total]:
1. How many shuttles are allowed at a station at any one time?
2. What happens if a train does not deliver its order on time? 
3. What modes of payment are there? And how long does it take to gather each payment?
4. Which part of the software deals with the invoicing?
5. What is the process by which orders are assigned?
6. What is the process once a shuttle has been assigned an order? 
7. Is it possible for a shuttle to transport two or more orders at the same time?
8. How is a shuttle retired? And what does that mean?
9. Apart from the starting capital, what other ways are there to generate capital?
10. What happens when a section of the track is disrupted?
After having a basic understanding of the system's requirements, your next task is to start seeing how 
they can be implemented. Tasks 2 and 3 are tools to help you to do this. 
Task 2 – Use Case Diagram
Develop a use case diagram for the kernel of the simulation system [20 marks]. (The kernel should be 
responsible for simulating the physical environment and for managing the interactions between the 
parties involved, such as the shuttles themselves and any other actors you identify.) 
Note that in this task, you only need to use the Systems Overview in Appendix A, not the code.
[Hint: start with identifying what actors/entities there are, and then list what tasks they can perform 
and how they interact with the other actors and kernel of the system]
Task 3 – Interaction Diagrams
All information is passed on in the form of messages in the simulation. This simulates asynchronous 
communication. These messages are of a basic command and reply structure. The shuttle expresses its 
wish to perform a certain action, and the shuttle process checks this request, and gives the appropriate 
response. With this in mind, your team's next task is to draw interaction diagrams for [20 marks]:
a) when an available order is issued 
b) the following sequence of events:
● Order A is available
● Shuttle bids for Order A
● Order B is available
● Shuttle bids for Order B
● Shuttle is assigned the Order B and carries out the order
● Shuttle is paid by credit card
Your last interaction in (b) should be from the banking agent telling the shuttle that money has been 
received.
Again, you should only need the System Overview for this task.
Task 4 – Class diagrams
Another team on the project has developed the system architecture for the system, and has 
implemented most of the classes. However, due to a computer fault and insufficient backups, the class 
diagrams were lost. The next task is to (re-)draw class diagrams of the system. In this task, you need 
to download the Java source files from:
http://www.inf.ed.ac.uk/teaching/courses/inf2c/coursework/
and unzip them. The files you will need are under the .../de/upb/swtpra03/kernel. 
Your manager has asked you to draw one or more class diagrams which between them show the 
following classes: Agent, BankingAgent, BrokerAgent, DisablingAgent, Element, OrderGenerator, 
RandomOrderGenerator, ScriptedOrderGenerator, ShuttleAgentBase, Stations, Switch, Thread, 
TopologyAgent, Track.
You must show the associations and generalisations between the classes. On the associations you 
should show rolenames (with markers for public, private and protected where you can determine 
them), navigability and multiplicities, where known. You need not list the attributes or operations of 
the classes.
As you do this task, take the opportunity to begin familiarising yourself with the structure of the 
system overall, which you will need to understand later. If you decide that the class diagrams would 
be clearer if you included classes not listed above, you may do so, but should include a brief note 
(perhaps in a UML comment) to indicate why you have chosen to include each extra class.
Task 5 – Designing a Shuttle
For the final task of this assignment, your team has been assigned to design parts of the ShuttleAgent 
class in the system. This is the class that dictates how the shuttle should react once a command has 
been received by the kernel. For example, if the shuttle has arrived at a station, the Shuttle Agent 
needs to work out whether it is at the right station (for a start) and then whether it should starting 
loading or unloading and send an appropriate message to the shuttle. 
There is a current half implementation of the ShuttleAgent class under
/de/upb/swtpra03/Inf2c/agent/FlyingScotsman.java
Make sure you study it, and understand the basic mechanics of how the class works. 
Each of your members have to write the pseudo code for two of following methods (that's two EACH 
– no more, no less)  [15 marks for each method – 30 in total]:
● calculateOffer(Message nmsg)
● moveToStation()
● unloadShuttle(Message nmsg)
● connectionOK(Message nmsg)
● assignOrder(Message nmsg)
● shuttleArrived(Message nmsg)
You should put the pseudo code of each method into an individual plain text file, with exactly the 
same name as the method (e.g. the moveToStation code should be in a file called moveToStation). At 
the top should appear the authoring team member's name, matriculation number and group number. If 
your name is not marked at the top of a file, you risk not getting your individual mark for the work! 
In this task, we will be looking for the pseudo code to be written at a suitable level (e.g. “Do 
calculations” would be too high level, whereas “assign a new variable i and increment it by one” 
would be too low level). Use your best judgement – a rule of thumb is that pseudocode should given 
enough information that the programmer working from it doesn't have to think much, but should not 
be specific to one implementation language; if you can tell that you're targeting Java code, you're 
writing at too low a level.
Submissions
The submission for this assignment will be in electronic form. You should submit the following:
● a pdf file containing the answers for Task 1 – named Task1.pdf
● a pdf file containing the answers for Task 2 – named Task2.pdf (this should be done using the 
save as pdf command in the Umlet plugin)
● Two pdf files containing the answers for Task 3 – named Task3a.pdf and Task3b.pdf
● a pdf file containing the answer for Task 4 – named Task4.pdf
● 6 text files each named after one of the methods (calculateOffer, moveToStation, 
unloadShuttle, connectionOK, assignOrder, shuttleArrived)
Make sure you identify all your files with the matriculation numbers of all the members in your team 
plus your group number at the top of the files.
Put all the files into a folder in which you MUST call inf2c-se1. Once you have your files, your group 
leader should run the following command on a terminal window (making sure you are in the directory 
where inf2c-se1 resides):
submit inf2 inf2c se1 inf2c-se1
Some comments on Plagiarism
1. Submitting another student's work (even if modified) as it is your original work is plagiarism.
2. Assisting another student to plagiarise (eg. By sharing code wihtout the borrowing student 
acknowledging the use) is also penalised.
3. Discussing the assignment in broad terms is OK, but not at the level detailed answers or code. 
Detailed discussions are expected to take place within each team, however.
4. Even partial, non-working submissions get partial credit.
5. A failed assignment is not a ruined career. Getting caught at plagiarism could ruin it.
6. We use various techniques to detect plagiarism, including automated tools.
7. If you have difficulty doing the assignment, first ask for help from your demonstrators or tutor 
or the newsgroup eduni.inf.course.inf2c . If you are still having problems, contact your TA, 
Kate Ho (K.L.Ho@sms.ed.ac.uk). If some other external reason prevents you from completing 
the assignment on time, please contact your Director of Studies and/or the Course Organiser.
8. Change the protections on your homework files and directories so potential plagiarists cannot 
access your solution. If your file is called XXX, then use the UNIX command: chmod go-rwx 
XXX. 
Some addition Information
What is Pseudo code?
Pseudo-code is not actual code. Just write what that statement should do. For example:
If (message received = ShuttleRepaired)
THEN
print out (“Shuttle is repaired”)
pick a station from random
move to station
See http://www.csc.calpoly.edu/~jdalbey/SWE/pdl_std.html for more explanation. 
Working with Java packages
This section is more relevant in the next assignment (and this information will be repeated then). 
When you are working with Java packages, you have to compile the code from the top-most relevant 
directory. Therefore, in this assignment, if you wish to compile the code, you have to be in the 
directory which has a subdirectory de, and type the following command to compile the code:
javac de/upb/swtpra03/prototype/agent/*.java
Alternatively, of course, you can load the code into Eclipse and build there.
Tips and Tricks on Using Umlet 
Saving working in Umlet:  to save a file in Umlet, you have to use Umlet's own File/Save menu item, 
which appears at the top of the Umlet mini panel/window. Trying to use Eclipse's save (or type  Crtl-
S) does not work. 
Changing Palettes – you can change palettes to give you the best selection of graphic elements. For 
example, in tasks 3 and 4, you might want to switch to the Sequence or Class palettes instead of the 
default.
Acknowledgements
The lecturer and TA would like to thank Florian Klein, Andres Seible and Holger Giese whose 
Shuttle System case study is the basis for this assignment. In addition, parts of this assignment were 
inspired by last year's assignment, written by Manuel Marques-Pita and Julian Bradfield. 
Informatics 2c – Shuttle System Overview
Consider a railway. The railway consists of interconnected stations. Shuttles bid for orders to 
transport passengers between certain stations. Successful completion of an order results in a monetary 
reward for the shuttle involved. In case an order has not been completed in a given amount of time, a 
penalty is incurred. New orders are made known to all shuttles, thus all shuttles can make an offer. 
The shuttle with the best, i.e. lowest offer will receive the assignment. Using the tracks will incur a 
toll, depending on the distance covered. Maintenance of the shuttles is possible at 
any station and will cost both time and money.
1. The Railway network
The railway network consists of stations, track and switches. Tracks can be travelled upon in
one direction only. A switch is configured as a converging or branching junction depending
on the directions of the adjoining tracks. A section of tracks consists of any number of
connected tracks and switches. A section of tracks between stations is called a connection.
The direction of a connection is determined by the direction of its constituent sections of
tracks. A connection can only be traversed in the predefined direction and changing the
direction while underway is not possible. Connections can share sections of tracks and
switches, while there must only be one connection between two stations in one direction
1.1. Stations
Any number of shuttles can be present at a station at the same time. The duration of a shuttles 
stay at a station is not considered maintenance time. Maintenance must be explicitly
scheduled.
1.2. Connections
Connections between stations can be temporarily disrupted. Shuttles currently travelling on a
section of tracks at the time of the disruption are not affected by it, and will be able to
complete their journey. Shuttles at stations will not be able to use the connection. They can
however use a different route. All shuttles will be informed of the disruption and its duration.
1.3. Orders
Orders are made known to all shuttles by a broker (the Broker Agent). An order defines start and 
destination stations as well as the allowed time for completion. The deadline is derived from the time 
of acceptance of an order and the predefined processing time, which begins at the time of
acceptance. Additionally, an order has a certain size, namely the number of people wishing to 
travel. Orders will be paid for by the passengers either by credit card or invoice. (See Income)
Order assignment follows a strict pattern. Firstly, all shuttles are informed of the new order.
Within a certain period of time, any shuttle can make an offer, which defines the payment it
will receive after successful completion of that order. The shuttle having made the lowest
offer will receive the assignment. In the event of two equal offers, the assignment will go to
the shuttle that first made the offer. 
1.4. Shuttles
Order processing is handled by the shuttles. Every shuttle can transport passengers up to a
maximum capacity determined at the start of the simulation. This means that a shuttle can
transport more than one order at the same time, as long as the orders do not exceed the
maximum capacity. The number of orders assigned - but not necessarily loaded - to a shuttle
at any given time, is not limited. 
To complete an order a shuttle has to travel to the start station, load the order and then
proceed to the destination station to unload. This sequence must be completed in a predefined 
time span; otherwise a penalty will be levied. (See Expenses) Order-processing begins
with the loading at the start station and ends with unloading at the destination. Loading or
unloading at other stations is not permitted.
A shuttle travelling on a section of tracks can neither change direction nor choose another
destination. A travel decision is only possible at a station before the journey has begun.
1.5. Income and Expenses
1.5.1. Income
In the beginning, every shuttle will receive a fixed starting capital. Afterwards, a shuttle’s
only means of income generation is to successfully complete orders. Payment occurs after an 
order is delivered and an invoice is sent to the banking agent. If the order specified payment
by credit card, then the money is transferred to the shuttle immediately. If the payment
method was invoicing, the banking agent may need up to two reminders before the shuttle
receives the money. The actual number of reminders needed is random and will not be
disclosed to the shuttle. Reminders sent less than 2500 simulation periods after an invoice or
reminder for the same order will not be accepted.
1.5.2. Expenses
There are the following three different types of costs:
1. Toll: Travelling from station to station costs a fee. The actual amounts can differ,
depending on the topology used. Payment is due when a station is reached.
2. Maintenance: After travelling a certain distance, maintenance has to be carried out.
The distance depends on the number of tracks and switches travelled. If a shuttle
exceeds this limit, maintenance will be carried out at the next station automatically,
and it will not be able to leave the station until maintenance is finished. However,
repairs can be scheduled before the distance limit is reached, and carried out at any
station. Payment is immediate.
3. Penalties: If an order has not been delivered in time, a penalty will be imposed. If a
shuttle currently carries the order, it has to complete it. The transport will always be
paid, but the penalty is incurred at the deadline. If a shuttle has not loaded the order at 
that time, it has to pay the amount it has offered to get the order plus a penalty fee,
which is specified in the order. If the order has been loaded already, then the penalty
consists merely of the amount offered. It is important to realize that no profit can be
made if either deadline is not met. 
If a shuttle is at a station and its account shows a negative balance, it will not be permitted to 
leave this station, and is retired. Trains are retired by the kernel.