CS680 hw2 TrainSet Project Analysis and Refactoring

Due Tuesday, Sept 22: paper in class, files by midnight in UNIX cs680/hw2 directory.

Study the supplied trainset project from Ethan Bolker's cs680 class. Unlike hw1's code, this project has mostly very good code, worth study for ideas for our Pong project. Note these good features:
--Javadoc on public methods
--Class header comments, generally good comments
--Sealed up classes except for a few things
--Good names for classes and methods, no cryptic abbreviations in names
--Good procedurization

 It attempts to be MVC, but in fact, has a few non-MVC dependencies we need to fix.

At first, for problem 1, concentrate on the following core classes:
TrainSet
TrainSystemGUI
Controls 
TrainOnTrack
Train
*Layout
TrainSetGUI
*Segment
where the *s are wildcards.  

0. Post a test message in the new Google group for this class, in discussion "hw2test" after registering for it following directions in the email you should receive in your cs.umb.edu email account on Thurs, Sept. 11.
1. Draw a UML class diagram on paper showing the relationships between the above classes. Use Fig. 2-27 and 2-29 as a guide for level of detail. Fill in any diamonds, and note that you don't need a "1" next to a filled-in diamond because that is required by composition. After doing the next step, rearrange the diagram if necessary to show the GUI classes on the left side and the model classes on the right side of the diagram. Connect two pieces of notebook paper for a larger drawing area. 
2. Subdivide all the trainset classes into model classes and GUI classes. Don't count "paint" methods as forcing a class into the GUI camp if it is otherwise part of the model. We'll allow model elements to know how to paint themselves for now, as long as they use just the passed-in Graphics object. Set up two packages, trainset.presentation and trainset.model, and put the appropriate classes in each. Put Animator in model for now. The "control" code of MVC will be in the presentation package here. In memo.txt, explain how you decided where to put each class, and for each class, give a one sentence description that should appear at the beginning of the file. In some cases you can find such a statement in the provided sources and copy it. Also, put your sentence in the sources, if needed there.
3. Study the GUI classes for how they use Swing Components. First find all the Swing classes in use that are Components, and draw a UML class diagram (an inheritance hierarchy) for them, adding any classes to the picture that are superclasses of classes in use. Then add in the subclasses of these classes that are in use in the program, such as TrainSetGUI. Again just label with class names.
4. When the program is fully initialized, it will have various Swing objects of type Component. Draw a UML object diagram showing how these Components (all Containers) are related by relationships known to Swing, that is, established by Container.adds. The JFrame object is the root. Don't worry about the detailed contents of Box objects. Since we don't have field names for the resulting objects, just use the class names to identify the boxes on the diagram, for example TrainSystemGUI (JFrame) or just JMenuBar because it has no app-specific subclass.
5. Ideally the presentation (GUI) classes reference the model classes but not vice versa. Find the case where a major model class references a major GUI class. Do a refactoring to get rid of the backwards reference (this does not need the Observer pattern, just simple code movement between classes, to rearrange the "installLayout" and "addTrain" work). Explain how you did this in memo.txt. Specifically, did you use any eclipse capabilities?
6. Find all non-private fields in the above-listed classes and determine if they are in actual direct use by other classes, not counting protected fields that are used by subclasses of the current class. Note that for classes in the same package, protected fields are effectively public fields. In eclipse, it is easy to find all references to a field or method: just select its name and right-click, use "References". Seal up any fields not accessed from outside and provide getters/setters for the others. In memo.txt, record what you found and fixed.
7. The Animator class straddles the model and GUI boundary. Can you figure out how to straighten this out? I think this does require the Observer pattern. You don't have to code this, just discuss it in memo.txt, including what new classes/inner classes are needed.
Deliverables

We will collect your work electronically from a hw2 subdirectory of the cs680 directory the Department's UNIX system created for you when it approved your account for this course. Do not modify the permissions for that directory.

You may work on any machine with any operating system and development environment you choose, but the programs you deliver must compile and run on the Department's UNIX system. The supplied build.xml allows Swing programs to run on our UNIX systems even from a remote login, by using my office screen.

Your memo should be pure ascii text, with no markup (no html, no MS Word). When printed on the Department printers no text should be lost at the ends of lines. If you want to submit some hard copy of diagrams, you may bring them to class the day the assignment is due.

We will look in your cs680/hw2 directory. It should contain