CSE143 Summer 2003

Project 7: Mix 'n Match

Run, Bus, Run!

Your Horoscope and Fate

Supplied code

New!Mix 'n Matcher tool now available!

New! Fellow Student Class Files from Step 1 and 2!
(Please review the Readme.txt file before using them.)

Step 0

Step 1

Step 2

Naming and Packaging

FORMS: Step 0 choices form; Pre-grading form; Star Seach nomination form; appointment form

Hints, tips, and corrections

Turn-in forms

Credits

Due dates:

Friday lecture August 15: project choices (a form will be provided in class); electronically @9:00PM, one shallow version for one component of one application (you will be allowed to submit an improved version later).
Sunday evening, August 17: Electronically, versions of all three components. For your designated two shallow components, this will be their final deadline. For the deep component, turn in at least a shallow, working version. If you want your component to be eligible for any possible competition, turn in a "competitive" version at this point (there may or may not be any later opportunity).
Tuesday evening, August 19: Electronically, the final version of your deep component.
Wednesday lecture, August 20: Any and all remaining paperwork
Grading will take place in person with your TA, probably during appointments to be scheduled on Wednesday and Thursday.

Overview. Working with a partner is productive and fun. Imagine if you could collaborate with the whole class... In the project, you will implement pieces (Model, View, Controller) of two different applications, and fit your pieces with implementations from other teams in the class.

One application is called Run, Bus Run! It is similar in some respects to the Top-Level View project. With it, you can simulate busses, bus stops, bus routes, and people (passengers). The model for this application keeps track of what objects exist and where they are (in real-world latitude and longitude terms). The controller creates the various objects and can control some of their activities. The view, naturally, provides a visualization of how the world looks at a given time. The other application, Your Horoscope and Fate, can predict your fate if you give it your astrological sign. The model knows about astrological signs (their dates, names, fates and fortunes, etc.); the controller lets the user interact with the model; and the view shows what is going on. The two applications are not necessarily equal in complexity.

The capabilities of each application are suggested by, and limited by, the interfaces for each. Study the starter code carefully for more information. Some details about naming and implementation requirements are described there, and also in the table at the end of this document. Beyond that, the only limits are your imagination.

Starting Code. There are a number of interfaces which must be implemented. The package structure is important and must be preserved. There are also fixed class names which you must use. A set of compiled (.class), runnable components (mostly stubs) is also available for testing. The CalendarUtilities.java file is not required to be used; you might find it helpful if you do the horoscope application; same comment for the signs.txt file. ZIP file with all code. Code as a browsable directory.

Step 0: Read and understand the whole assignment before doing Step 0.

Step 1. Pick a Team Moniker by which the outside world will know you. The Team Monikers will be public, so protect your privacy; the moniker does not have to be based on your real names.

Pick a model, a view, and a controller to implement. They may not all come from the same application. Designate two of your choices as "shallow", and one as "deep".

General rules:

For each application, there is a specified interface for each component (MVC). You must implement that interface, and you may not add any public methods, except the constructors specifically mentioned (unfortunately, constructors can't be officially specified in an Interface).
There are also some naming and packaging requirements that relate mainly to making sure the components can be located and identified properly. You must follow any such requirements carefully. See the table at the end of this page.
You will be allowed to create additional classes for a component, but only within the same package, and clients will not know about them. They must not be used outside the package where they are defined.
You may also use any standard Java library classes, and any solution code from this quarter. All other code should be written by you.
None of the components should perform actions which would keep the application as a whole from progressing.
Your component doesn't "work" unless it works with any combination of (correct) components for that project.
For each component, prepare a README.txt file to be turned-in, describing your component and its capabilities in general terms, and giving specifics about any features (positive or negative) that should be brought to a user's attention (or a TA's attention!)

For the shallow tasks: make a complete, runnable implementation. It does not have to be fancy, or use all the capabilities of the interface. For the deep task: it's your chance to show off and/or be creative. Make an implementation that lets you do both! The notes below apply mainly to the deep task, but you should read them all anyway.

For the Model: Implement the interface completely. It should be robust enough not to crash, no matter what calls are made on it. When preconditions are violated, you are free to throw an (unchecked) exception, or to violate the postconditions or cause the application to terminate (of course, you might want to leave a trail so that anyone can see that it is clearly the client who was at fault!). The model may only have one constructor, and that constructor must take no arguments.

For the View: There should be only one constructor. That constructor should take exactly one argument: a reference to the Model. You must avoid any form of user interaction. You should do nothing which blocks the other components from proceeding (such as waiting or sleeping). You should not call any of the Model methods which change its state. [Footnote: a more elaborate design would have the model interface partitioned into smaller parts, with the view and controller functions separated.] Note: you are not required to implement a graphical viewer. However, if this is your deep task, you probably do want to. In that case, create your own JFrame so you won't have to share it with the Controller. Just as a convention for ease of use, place your frame toward the left side of the screen, and try not to take up more than half of the total screen real estate. This is just for courtesy, not a hard requirement.

For the Controller: Your implementation will contain the main class for the entire project. In main you should create a model and a view in that order, passing the model reference to the view. You can define any classes and methods you wish, but they all must be in the same package as your main class. The methods and classes you define will not be known to or used by the View or Model. Your program remains in control of the application. Any user input must be done at the initiation of the Controller. The Controller is not required to use all of the methods of the Model, nor is it required to do any user interaction, unless required by the application. If you use a GUI... see the notes above about the View GUI; place your JFrame towards the right of the screen.

Some mechanics: read through both applications and all the instructions before making your selection. Expect the turn-in, testing, and grading procedures for the project to be somewhat different from the previous ones.

Apologies in advance... the test set-up for this is project is elaborate, and has not been tried before. Grading may also be a bit unusual. There may be last-minute changes in the project instructions in order to accommodate these circumstances.

Step 2: Complete and submit your "deep" component.

Step 0: After studying these instructions, decide which components you are going to implement. Select a Team Moniker. Turn in a sheet declaring which ones those are (we will provide the form), and turn in a stub for one of them electronically.

The Mix 'n Matcher tool. One of our TAs has developed a tool which you can use to easily combine your components with those turned-in by your classmates. To use the tool, you will have to download the following .jar file to run on your computer; you may also have to arrange your local components (the ones on your computer) in a certain way. Please note that the use of this tool is completely optional and still in the experimental process. An explanation on how to use the tool . The MixMatcher.jar file.

This project is to be done by pairs of students. Working alone or changing partners is not permitted. Review the course and departmental guidelines for use of work not your own. In particular, any scrap of code which your team didn't originate or that isn't CSE143-supplied (e.g. you and some others brainstormed the idea) must be acknowledged.

Naming and Packaging Requirements and Conventions

	Run, Bus, Run!	Your Fortune
application package names	bussim	horoscope
Controller A shallow implementation should try to call all of the model methods for creating or changing the model. and call the view sufficiently often to show what the result is.	package: bussim.controller must implement ICollabController class name must be BusSimController	package: horoscope.controller must implement ICollabController class name must be HoroscopeController
Model A shallow implementation should provide at least a stub for each method, and should certainly not blow up or do things to cause other components to blow up.	package: bussim.model must implement IBusSimModel class name must be BusSimModel The model must also provide concrete classes for the interfaces IBus, IBusStop, IPerson. The names should not matter, as they will not be used outside the model package.	package: horoscope.model must implement IHoroscopeModel class name must be HoroscopeModel The model must also provide concrete classes for the interfaces IFortune and ISign. The names should not matter, as they will not be used outside the model package.
View A shallow implementation should provide a bit of information about each object it has been asked to create. In doing this, it should call as many as possible of the model methods which report status (as opposed to those which create or change something).	package: bussim.view must implement ICollabView class name must be BusSimView	package: horoscope.view must implement ICollabView class name must be HoroscopeView
	Required static, global variables in the principal class of each component: public static final String author = ".... public static final String description = ".. public static final String depth = "... Use your Team Moniker as the value of author. The description should be a short English phrase. The depth should be "shallow" or "deep". As usual, the Java identifiers (author, description, depth) are case-sensitive. These values will show up in the Mix 'n Match tool.
The package mvc143 contains the interfaces mentioned above. It is important to leave these and all other starter files in their original packages, and not to change any names or any of the file contents. If you do, your components may run with each other, but will not compile or run with components created by other teams.

Please turn in everything once per team unless otherwise requested. Put both partners' name on everything. It does not matter which person does the electronic turn-in.

Please read the turn-in forms carefully when they become available, including the fine print! After submitting a form, read what comes back, too.	There is a separate turn-in form for each of the applications.
For part 0, there is only one turn-in form for components of both applications. You do not need to turn in a receipt for part 0.	Turn-in for part 0.
You must print a receipt for part 1 to be turned in later.	Turn-in for part 1.
You must print a receipt for part 2 to be turned in when you meet with your TA. If you don't turn in your shallow implementations again for part 2 (although it would be better for your TA if you did), you will also need your receipt from part 1 to give to your TA. (Bring your receipt for part 1 just in case).	Turn-in for part 2.

Credits. Zuo Yan: Run, Bus, Run! application. David Tran: Your Horoscope application. Eric LeMar: Mix 'n Matcher tool.

Hints, Tips, and Corrections. Check here occasionally for major hints or corrections. Your best source of help is the Message Board, however, or office hours.

Avoid using console I/O (e.g., System.out). The console output from various components, and from the system, will get all mixed together. In some Java environments, there might not even be a visible console. Instead, use the Swing JOptionPane class, which has static methods showInputDialog and showMessageDialog. You can use these without having to create a JFrame or any of the other usual overhead of GUI programming. (Of course, in your deep component you may want to use a full GUI.)

You may need to load a resource in your component -- for example, a text file or an image file. Telling Java where to find such resources can be a bit tricky. It's essential that anyone using your component be able to load the resource successfully, without any manual moving or renaming of files. The best way to do this is to put the resource file within your component package, and then request the Java Class Loader to locate and load the file. Here is a method for loading a resource (as a BufferedReader). It should work without much adjustment as long as you follow the placement and naming conventions it expects. Note that this code is not a full, compilable class: just a single method.

August 15, 2003 CalendarUtilites has been updated to include the month of October.

August 18: The type designator String was left off in the global variables specifications (in the Naming and Packaging table above). A correction was made on the Message Board but these instructions weren't updated (until just now).