Your working project must interact with its user in a GUI application. You also need to provide for persistent information (via file or database) from one use of the application to the next use of the application. So for instance, let's say that you alter the runner's performance during a race in the Tortoise and Hare project, then exit the program. When you start it again, the most recent performance parameters must still apply. You would not need to store the race outcomes (though there's nothing wrong with doing that as well).

For your design, you need to at least create UML Class Diagrams for each class in your solution. You should also show mock-ups of what your GUI windows will contain.

Project D: Tortoise and the hare race

Console

Get set...Go! Tortoise : 10 Tortoise : 20 Tortoise : 30 Tortoise : 40 Hare : 100 Tortoise : 50 Tortoise : 60 Tortoise : 70 Tortoise : 80 Hare : 200 Tortoise : 90 Tortoise : 100 . . (output lines omitted) . Hare : 500 Tortoise : 900 Tortoise : 910 Tortoise : 920 Tortoise : 930 Tortoise : 940 Tortoise : 950 Tortoise : 960 Tortoise : 970 Tortoise : 980 Tortoise : 990 Tortoise : 1000 Tortoise: I finished! The race is over! The Tortoise is the winner. Hare: You beat me fair and square.

Operation

This application simulates a race between two or more runners. The runners differ in their speed and how often they need to rest. One of the runners, named "Tortoise," is slow but never rests. The other runner, named "Hare," is ten times as fast but rests 90% of the time. Control these ratios from a text configuration file which is read at the start of each race.

There is a random element to the runners' performance, so the outcome of the race is different each time the application is run.

The race is run over a course of 1000 meters. Each time one of the runners moves, the application displays the runner's new position on the course. The first runner to reach 1000 wins the race.

When one of the runners finishes the race, the application declares that runner to be the winner and the other runner concedes.

After each race, store the results to a text file or a database table.

Specifications

Each runner should be implemented as a separate thread using a class named ThreadRunner. The ThreadRunner class should include a constructor that accepts three parameters: a string representing the name of the runner, an int value from 1 to 100 indicating the likelihood that on any given move the runner will rest instead of run, and an int value that indicates the runners speedthat is, how many meters the runner travels in each move.

The run method of the ThreadRunner class should consist of a loop that repeats until the runner has reached 1000 meters. Each time through the loop, the thread should decide whether it should run or rest based on a random number and the percentage passed to the constructor. If this random number indicates that the runner should run, the class should add the speed value passed to the constructor. The run method should sleep for 100 milliseconds on each repetition of the loop.

If the run method is interrupted, it should display a message that concedes the race and quits.

The main method of the application's main class should create two runner threads and start them. One of the threads should be named "Tortoise." It runs only 10 meters each move, but plods along without ever resting. The other thread should be named "Hare." It should run 100 meters each move, but should rest 90% of the time.

This class should also include a method named finished that one of the threads can call when it finishes the race. That method should declare the thread that calls it to be the winner and should interrupt the other thread so it can concede the race.

The finished method should provide for the possibility that the two threads will finish the race at almost the same time. If that happens, it should ensure that only one of the threads is declared the winner. (There are no ties!)

Modify the main application class so that it runs the race 100 times and reports how many times each runner wins. (To make the application run faster, you may want to reduce the sleep time in the runner threads.)

Modify the application so it can support up to 9 runners.

Add an additional random element to the runner's performance. For example, have a "clumsiness percentage" that indicates how often the runner trips and hurts himself. When the runner trips, he sprains his or her ankle and can run only at half speed for the next five moves.

Add the ability for runners to interfere with each other. For example, have an "orneriness percentage" that indicates how likely the runner is to trip another runner who is passing him. This will require additional communication among the threads.

Hints

To determine whether a thread should run or rest, calculate a random number between 1 and 100. Then, have the thread rest if the number is less than or equal to the percentage of time that the thread rests. Otherwise, the thread should run.

The finished method in the main application class will need to know which thread called it.

This application demonstrates the basics of creating independent threads that don't require much synchronization. Even so, you must coordinate those threads to declare one of the threads the winner and have the other thread concede.