Computing Science 465 | Class Project

SAINT MARY'S UNIVERSITY
Department of Mathematics and Computing Science
CSC 465.2
Object-Oriented Programming
2003 Winter Term 2003

Class Project
Timeline and Software Development Notes

This page contains a timeline and software development notes for the Mastermind class project. It will be updated regularly as the project proceeds.

Timeline

The milestones shown in this table apply to all teams, unless there is some indication to the contrary. The dates in the "Complete by ..." column should be interpreted to mean "by the beginning of class on that date".

Things to do ... Complete by ... Notes and Comments

1. Create two programs and one applet to display Mastermind "banner" pages (modeled on the "Hello, world!" examples)
2. Search the web for at least two interesting Mastermind sites and hand in on 3 by 5 card Week 02
(January 15) To be done individually, then best console app, best applet, and best GUI app to be copied to team account by Sunday, Jan 19 midnight and tested by evaluating team by Week 03 class

Create a test suite (test class) for the supplied Menu class, then implement your own Menu class (with the same interface, of course) Week 03
(January 22) To be done as a team; each team must have something ready for testing by Week 03 class, with full-blown testing to take place later. Check the end of Week 02 notes for further details.

Create a test suite (test class) for the supplied TextItems class, then implement your own TextItems class (once again, with the same interface, as you did for the Menu class). See below for the TextItems interface. These two classes (Menu and TextItems) help create a large part of the user interface for any console program, at least the part that is not application specific. Also, this week, begin to think seriously about Mastermind itself and the classes you will need (possibilities include Codemaker, Codebreaker, Code, Score, Board, for example). Go wild with Use Cases and CRC cards. Week 04
(January 29) To be done as a team; each team must again have something ready for testing by Week 04 class, with full-blown testing to take place after Sunday midnight. This time you will evaluate the team 3 places ahead of you: So, team 01 evaluates team 04; team 12 evaluates team 02; and so on. Check the end of Week 03 notes for further details.

1. Create a "package mm" for testing.
2. Complete an initial design for Mastermind, to be handed in. Check the end of Week 04 notes for further details, which was updated in several respects after class. Week 05
(February 5) To be done as a team; each team must again have something ready for testing by Week 05 class, with full-blown testing to take place after Sunday midnight. This time you will evaluate the team 5 places ahead of you: So, team 01 evaluates team 06; team 12 evaluates team 04; and so on.

1. Create a mm.jar file containing your Banner, Menu and TextItems classes, and then place it in your public directory so that it's ready for testing during the next class.
2. Pay special attention this time around to page 2 of the evaluation form, making sure you have a full set of intelligent tests that the classes in your target team's mm.jar file should pass.
3. Use a driver called PlayMastermindJar.java (see below and/or end of Week 05 notes for further details). Week 06
(February 12) 1. To be done as a team; each team must have have completed the work and have it ready for testing by Week 06's class. Testing will take place in class, and your evaluation sheet should contain a full suite of tests and comments.
2. For the testing you do this week (package mm, after Sunday evening) you will evaluate the team 7 places ahead of you: So, team 01 evaluates team 08; team 12 evaluates team 06; and so on.

Let's summarize what should be in place for the first week after the break :
1. You must have implemented the Computer-as-Codemaker aspect of Mastermind. (See development notes below the table for details.)
2. Your driver must be in PlayMastermindJarX.java.
3. The rest of your classes (Banner.class, Menu.class, TextItems.class, and all new classes for Mastermind itself) must be in mm.jar, which in turn must be in your public/mm directory.
4. Your driver must continue to take the text items file (mastermind.dat) as a command-line parameter.
5. You must provide a secondary menu (available when the "Get information" option is chosen from the main menu) that has the text item titles from mastermind.data as its options and displays the corresponding text item (with appropriate pauses for a 24 by 80 screen) when that option is chosen from this secondary menu. Week 07
(February 26) Teams are now going their own way. From now on, each team will be using their own design, and therefore their own interfaces to their own classes. This means that when Team A is testing Team B's work, Team A will no longer be able to use their own driver and will have to use Team B's driver as well. Otherwise, the testing process will proceed as before. This scheme will be in place for testing the first week after the break. Meanwhile, the last "mix and match" testing was of the PlayMastermindJar driver with the mm.jar file, which took place during the last week before the break (and your target team was 9 places ahead of your own).

This week you will implement the last major component of the Mastermind game, text-interface version, namely the Computer-as-Codebreaker capablility. See the notes below for one simple algorithm to use (if you can't devise any better one) for this part of the program. Week 08
(March 5) Let's agree that from Week 08 on, i.e., for the "final" version of the "complete" Mastermind game, and for any extensions and/or revisions henceforth, everyone will use a driver called PlayMM.java, which will be in your public directory, along with your mastermind.dat file, which may be modified as needed to contain any particular additional or different information needed for your particular implementation. All supporting classes will be in mm.jar in the mm subdirectory of your public directory. Also, starting this week, and for every week after the break, we will start using even numbers for determining target teams. So, for evaluating the PlayMastermindJarX and Computer-as-Codemaker your target team will be two positions after you (but remember, Team 11 no longer exists).

This week you will put the finishing touches on your text-based version of Mastermind (the complete program) and do the fine-tuning suggested by the items at the end of the Week 08 notes. You will also begin thinking about your Mastermind GUI, since that is the next stage. Week 09
(March 12) Note that we changed our minds on the driver name again. PlayMM will be retained for the final version of the text-based Mastermind, and we will use PlayMMGUI as the driver name for the next version(s) that will have a GUI. We should be able to coninue using mm.jar, as before, as the file containing all the other classes. For evaluating the Computer-as-Codebreaker using the PlayMM driver (after Sunday, March 9) your target team will be four positions after you (and remember, Team 11 no longer exists).

This week you begin to implement your Mastermind GUI. This can be just a front-end that is not connected to anything and doesn't yet "do" anything, but simply shows what you want your particular GUI to look like. Or it can be a partial implementation of a part of the GUI connected to just a part of the "model". Or something else, depending on your team's situation and design ... Note that this flexibility is going to make the testing next week harder ... Think about the implications. Week 10
(March 19) For evaluating the complete, final, fine-tuned, text-based version of Mastermind using the PlayMM driver (after Sunday, March 16) your target team will be six positions after you (ignoring Team 11). Remember that your driver for the GUI version is now going to be PlayMMGUI.

This week you finalize your your Mastermind GUI. Week 11
(March 26) For evaluating the PlayMMGUI (after Sunday, March 23) your target team will be eight positions after you (ignoring Team 11). Note that for this evaluation the form of the GUI has not been specified, so you will have to look at the thing you're evaluating first, and then decide what to test.

By now your Mastermind GUI should have its final overall configuration and most or all of its final functionality. In this last week for the class project (second last week of the course), do whatever fine-tuning you think necessary, and you should plan to have your final version "frozen" by Sunday, midnight, March 30. Week 11/Week 12
(March 30) This time you should evaluate the same team you did last week (8 positions ahead, not counting team 11), so that you are better able to evaluate the progress/improvement/fine-tuning done for the final phase, and based on what you have pointed out in the previous test. Note as well that Steven will be looking at the final version as well and we will be assigning a final class project grade based on the team evaluations and the "condition" of the final product. In theory at least, the condition of the final product should be consistent with the sequence of team evaluations.

Software Development Notes

The Menu class interface that we "agreed" we are implementing is this:

Two constructors:

a default constructor, and

a constructor that takes a single String parameter that will be the title of the Menu object

setTitle(String title)

addOption(String title)

display()

int getChoice()

You need to devise a TestMenu class that shows what the capabilities and limitations of this Menu class are. Only then are you ready to ready to start implementing your own Menu class. But remember this: We have "agreed" what the interface is to be. Don't go modifying or adding to what you see above, the only result of which will be chaos.

Here is the TextItems class interface:

Two constructors:

a default constructor, and

a constructor that takes a single String parameter that must be the name (or name with path) of a valid file of "text items" (See textitems.dat for an example.)

displayItem(itemTitle)

A class called Banner.class, compiled from a file called Banner.java, which contains a single public static method called display() is the third class to be added to your mm package and your mm.jar file. This method should display your Mastermind "banner page", as before.

For the driver file to test mm.jar, make a copy of your previous PlayMastermind.java. call it PlayMastermindJar.java, and remove the imports mm.*; statement from this file. For consistency as well, make sure a copy of your mastermind.dat file is in the same directory as your the driver. Make sure the package mm; statements are removed from those versions of Menu.java, TextItems.java and Banner.java that you plan to put into the .jar file.

Implementing the Computer-as-Codemaker aspect of Mastermind involves the following:

The computer must "choose" a "random" secret code (but actually this must be supplied by the user for the moment, while we are in testing mode).

The human Codemaker must then make a sequence of guesses that are scored by the computer and shown to the user, who uses the previous guesses to make each new guess.

This continues until the user guesses the secret code or runs out of guesses.

Messages are displayed for the user, as appropriate.

Note that we have not described the interface in any way. It is still text-based, of course, and you can always look at the HUSKY1 example, but there is no reason why yours has to "look like" that. For example, there is no reason why you have to use digits for pegs, or have ten guesses maximum. This is now your design. On the other hand, you don't necessarily want to get so far afield as to annoy your users or have them wondering if this really is Mastermind, or some other game.

What about implementing Computer-as-Codebreaker? We describe in this item a simple algorithm for codebreaking that you can use for when the computer is playing the role of Codebreaker. It turns out to be one that would be difficult (or at least very tedious and mind-numbing) for a human codebreaker to use, but is ideally suited for a computer to apply.

As always, the job of the Codebreaker at any given time is to choose the next guess. So, how does the computer make this choice?

When breaking a code, the computer seaches through all possible codes looking for the "right" one. In order to make guesses that are more and more "educated" as time goes on, it must keep track of all the previous guesses it has made and the scores those guesses received from the human Codemaker. Now suppose the computer is about to offer a new guess. If this guess is correct (i.e., if it is identical to the secret code) then it must have the same score when scored against each previous guess that that guess had when scored against the secret code. If it doesn't, it can't be the secret code and there is, therefore, no point in offering it as a guess.

That is the basic idea. Of course, there are many ways to choose a first guess, and many ways to search through all possible codes. Care needs to be taken, of course, to ensure that all possible codes are in fact examined, when searching for guesses.

Things to do ...	Complete by ...	Notes and Comments
1. Create two programs and one applet to display Mastermind "banner" pages (modeled on the "Hello, world!" examples) 2. Search the web for at least two interesting Mastermind sites and hand in on 3 by 5 card	Week 02 (January 15)	To be done individually, then best console app, best applet, and best GUI app to be copied to team account by Sunday, Jan 19 midnight and tested by evaluating team by Week 03 class
Create a test suite (test class) for the supplied Menu class, then implement your own Menu class (with the same interface, of course)	Week 03 (January 22)	To be done as a team; each team must have something ready for testing by Week 03 class, with full-blown testing to take place later. Check the end of Week 02 notes for further details.
Create a test suite (test class) for the supplied TextItems class, then implement your own TextItems class (once again, with the same interface, as you did for the Menu class). See below for the TextItems interface. These two classes (Menu and TextItems) help create a large part of the user interface for any console program, at least the part that is not application specific. Also, this week, begin to think seriously about Mastermind itself and the classes you will need (possibilities include Codemaker, Codebreaker, Code, Score, Board, for example). Go wild with Use Cases and CRC cards.	Week 04 (January 29)	To be done as a team; each team must again have something ready for testing by Week 04 class, with full-blown testing to take place after Sunday midnight. This time you will evaluate the team 3 places ahead of you: So, team 01 evaluates team 04; team 12 evaluates team 02; and so on. Check the end of Week 03 notes for further details.
1. Create a "package mm" for testing. 2. Complete an initial design for Mastermind, to be handed in. Check the end of Week 04 notes for further details, which was updated in several respects after class.	Week 05 (February 5)	To be done as a team; each team must again have something ready for testing by Week 05 class, with full-blown testing to take place after Sunday midnight. This time you will evaluate the team 5 places ahead of you: So, team 01 evaluates team 06; team 12 evaluates team 04; and so on.
1. Create a mm.jar file containing your Banner, Menu and TextItems classes, and then place it in your public directory so that it's ready for testing during the next class. 2. Pay special attention this time around to page 2 of the evaluation form, making sure you have a full set of intelligent tests that the classes in your target team's mm.jar file should pass. 3. Use a driver called PlayMastermindJar.java (see below and/or end of Week 05 notes for further details).	Week 06 (February 12)	1. To be done as a team; each team must have have completed the work and have it ready for testing by Week 06's class. Testing will take place in class, and your evaluation sheet should contain a full suite of tests and comments. 2. For the testing you do this week (package mm, after Sunday evening) you will evaluate the team 7 places ahead of you: So, team 01 evaluates team 08; team 12 evaluates team 06; and so on.
Let's summarize what should be in place for the first week after the break : 1. You must have implemented the Computer-as-Codemaker aspect of Mastermind. (See development notes below the table for details.) 2. Your driver must be in PlayMastermindJarX.java. 3. The rest of your classes (Banner.class, Menu.class, TextItems.class, and all new classes for Mastermind itself) must be in mm.jar, which in turn must be in your public/mm directory. 4. Your driver must continue to take the text items file (mastermind.dat) as a command-line parameter. 5. You must provide a secondary menu (available when the "Get information" option is chosen from the main menu) that has the text item titles from mastermind.data as its options and displays the corresponding text item (with appropriate pauses for a 24 by 80 screen) when that option is chosen from this secondary menu.	Week 07 (February 26)	Teams are now going their own way. From now on, each team will be using their own design, and therefore their own interfaces to their own classes. This means that when Team A is testing Team B's work, Team A will no longer be able to use their own driver and will have to use Team B's driver as well. Otherwise, the testing process will proceed as before. This scheme will be in place for testing the first week after the break. Meanwhile, the last "mix and match" testing was of the PlayMastermindJar driver with the mm.jar file, which took place during the last week before the break (and your target team was 9 places ahead of your own).
This week you will implement the last major component of the Mastermind game, text-interface version, namely the Computer-as-Codebreaker capablility. See the notes below for one simple algorithm to use (if you can't devise any better one) for this part of the program.	Week 08 (March 5)	Let's agree that from Week 08 on, i.e., for the "final" version of the "complete" Mastermind game, and for any extensions and/or revisions henceforth, everyone will use a driver called PlayMM.java, which will be in your public directory, along with your mastermind.dat file, which may be modified as needed to contain any particular additional or different information needed for your particular implementation. All supporting classes will be in mm.jar in the mm subdirectory of your public directory. Also, starting this week, and for every week after the break, we will start using even numbers for determining target teams. So, for evaluating the PlayMastermindJarX and Computer-as-Codemaker your target team will be two positions after you (but remember, Team 11 no longer exists).
This week you will put the finishing touches on your text-based version of Mastermind (the complete program) and do the fine-tuning suggested by the items at the end of the Week 08 notes. You will also begin thinking about your Mastermind GUI, since that is the next stage.	Week 09 (March 12)	Note that we changed our minds on the driver name again. PlayMM will be retained for the final version of the text-based Mastermind, and we will use PlayMMGUI as the driver name for the next version(s) that will have a GUI. We should be able to coninue using mm.jar, as before, as the file containing all the other classes. For evaluating the Computer-as-Codebreaker using the PlayMM driver (after Sunday, March 9) your target team will be four positions after you (and remember, Team 11 no longer exists).
This week you begin to implement your Mastermind GUI. This can be just a front-end that is not connected to anything and doesn't yet "do" anything, but simply shows what you want your particular GUI to look like. Or it can be a partial implementation of a part of the GUI connected to just a part of the "model". Or something else, depending on your team's situation and design ... Note that this flexibility is going to make the testing next week harder ... Think about the implications.	Week 10 (March 19)	For evaluating the complete, final, fine-tuned, text-based version of Mastermind using the PlayMM driver (after Sunday, March 16) your target team will be six positions after you (ignoring Team 11). Remember that your driver for the GUI version is now going to be PlayMMGUI.
This week you finalize your your Mastermind GUI.	Week 11 (March 26)	For evaluating the PlayMMGUI (after Sunday, March 23) your target team will be eight positions after you (ignoring Team 11). Note that for this evaluation the form of the GUI has not been specified, so you will have to look at the thing you're evaluating first, and then decide what to test.
By now your Mastermind GUI should have its final overall configuration and most or all of its final functionality. In this last week for the class project (second last week of the course), do whatever fine-tuning you think necessary, and you should plan to have your final version "frozen" by Sunday, midnight, March 30.	Week 11/Week 12 (March 30)	This time you should evaluate the same team you did last week (8 positions ahead, not counting team 11), so that you are better able to evaluate the progress/improvement/fine-tuning done for the final phase, and based on what you have pointed out in the previous test. Note as well that Steven will be looking at the final version as well and we will be assigning a final class project grade based on the team evaluations and the "condition" of the final product. In theory at least, the condition of the final product should be consistent with the sequence of team evaluations.