Contents:
As usual, the source code that you need can be found by updating your cse331 directory from SVN.
In this problem set, you will implement a graphical user interface for Husky Maps and document your complete system.
You were asked to mock-up a graphical user interface for Husky Maps in Problem Set 6. In this problem set, you will implement your GUI (taking into account your TA's feedback and comments).
It is possible that you might have designed a very fancy and comprehensive user interface in Problem Set 6. Although it would be good for you to implement the GUI (or perhaps an improved version after taking into account comments from your TA), you are allowed to implement a simpler interface. Your GUI must support at least the following minimal set of features:
In addition to the features that you incorporated into your GUI design in Problem Set 6, Husky Maps will also display a map of the generated route and connecting roads (to provide context); the user will be able to toggle the display of street names on the map.
The user must be able to resize the map — perhaps by resizing the Husky Maps application window that contains it. When you start Husky Maps, the default map view must be 500 pixels wide and 300 pixels high.
In the map display, the route should be scaled to be as large as possible, then centered in the display. The scaling should be uniform in the x and y directions, and should leave a 5% buffer on each side of the route between the route and the window edge. Here are two diagrams demonstrating route positioning:
Here is another way to state the requirement. First, find the bounding box of your route. The bounding is a rectangle that the route fits inside, and that the route touches on all 4 sides (possibly in the middle of a side, possibly at a corner). Now, scale the route (grow or shrink it, keeping its aspect ratio) until the bounding box edges that are closest to the map view edges are exactly 5% away. In the other direction, the bounding box edges might be 5% away (if the bounding box has exactly the same aspect ratio as the window), but they are likely to be further away.
To provide the user with context, the map will display all roads that are accessible from the path without traveling off the edge of the map. As shown in the diagram below, the route should be shown in green while other streets are shown in black.
Hint:Note that some road segments are only partially drawn because the road goes off the visible part of the map. This is very easy to handle: your code can just draw the entire segment, and the Swing components will only display the visible portion.
The roads shown in blue below are not drawn because they are only accessible by traveling outside the displayed region. (This restriction simplifies your algorithm.)
To implement the map, we suggest that you modify your Directions and DirectionsFinder classes as follows:
You may also need to make other changes. Be sure to write specifications for any functions and classes you write. You should also run regression tests on your Problem Set 6 solution.
The width of the streets should correspond to the type of street segment. Primary highways should be drawn thicker than secondary highways, which are drawn thicker than local roads, which are drawn thicker than unknown roads. Be sure to document how the various types of roads are displayed.
By default, your GUI should display each street name that appears in the route. Do not display street names for streets that are not part of the route. For each set of contiguous street segments with the same name, display the street name once (think GeoFeature). Draw the street name horizontally, centered in the bounding box of the GeoFeature.
The user can toggle the display of street names (it starts in the "on" state). Optionally, you could also permit the user to display names for streets in the context.
Your GUI should be named ps7/GraphicUI.java, so that
the command java ps7.GraphicUI (with the appropriate
classpath) launches Husky Maps's graphical user interface. Your program may
interpret additional command-line parameters, but the system must run
when invoked without any additional command-line parameters.
Use only components from the Swing widget set for this assignment. You are also allowed to use components from AWT, on which Swing is built, but should try to stick to Swing when possible.
For such a simple GUI, programming from scratch in Java is a very
reasonable choice (and the only one officially supported by the course staff).
Alternately, you are allowed to
use NetBeans (or some other
visual GUI builder) to auto-generate the code for your GUI.
If you do so, you
should state clearly in your documentation what GUI builder was used, you
must check the GUI builder source file(s) (for example, the NetBeans
.form file) into SVN, and you must document those source files
to enable another developer to understand or modify them.
You will hand in a self-contained project that includes a problem analysis, a design, module specifications, commented code, testing artifacts, and user documentation. The details for these items can be found in the handout Documenting a Software System and your documentation should follow the format suggested there. The documentation for this problem set should be approximately 5 pages, with a hard limit of 6; you will need to actively think about how to effectively present the information to meet the page length requirement
IMPORTANT NOTE: Your grade will depend on the quality of your ideas as you present them. This policy reflects good practice in industry and research: however good your ideas are, they are worth little if you cannot convey them to others. You will not receive a good grade for this problem set if your documentation is found wanting, even if your system works perfectly.
After you have completely implemented, tested, and documented the required functionality, you might wish to implement some of these features (or others of your own devising):
If any of these features are added, they cannot affect the
behavior of the ps6.TextUI class. Therefore, in order to
demonstrate them, you could:
ps7.GraphicUIWork on optional features will gain special credit. Such credit will be held in reserve and applied when we compute your final grade after we have ranked the students in the class. This will ensure that students who do not choose to work on optional features will not be penalized in any way, but students who do are rewarded appropriately. Please remember to document the optional features that you implement clearly. If you should implement a feature that is not visually obvious, it is possible that your TA might miss it and not award you credit for it.
Please answer the following questions in a file named collaboration.txt in your answers/ directory.
The standard collaboration policy applies to this problem set.
State whether or not you collaborated with other students. If you did collaborate with other students, put their names and a brief description of how you collaborated.
The following files should be checked into SVN before you run
ant validate:
Unlike previous problem sets, this problem set is not divided into separate questions. The distribution of credit for this problem set is (roughly) as follows:
If you're having trouble, the forums are a good place to look for help.
The user should be able to select any TigerDB -- i.e. the user should be able to specify any directory. You might consider using a JFileChooser.
If you try to run your GUI and get a message similar to
Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it.
, you will need to enable X11 forwarding for your ssh session. If you are are using Linux, this can be done using the -X switch when starting ssh:
ssh -X YourUserName@attu.cs.washington.edu
If you are using Windows, you will need to obtain special software such as Cygwin (available for free) or Reflection X.