View this PageEdit this Page (locked)Attachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team Us M4 Case Study

Other Case Studies: Team Us M3 Case Study Team Us M5 Case Study Team Us M6 Case Study

The Problem:

Check out the milestone description - Sp2002 P4 - Do the WHOLE campus

Our Approach

Our first approach was to walk through all of the requirements to see if we could think of anything that we missed in P3. We decided to go with our design for P3, however, soon afterwards we had to rethink our idea of representing buildings as a subclass of SketchMorphs. The main reason for this change was the inclusion of zooming which we were not able to think of a proper way of doing using SketchMorphs. For this reason we decided to continue to add buildings the way we had done in previous assigments. Our approach to the GUI was to use a SystemWindow for displaying.

Our Solution

When we ran into the problem of using buildings as sketchmorphs we turned to using forms for the buildings. The problem with SketchMorphs is that when you place a SketchMorph inside another Morph, its relative position is preserved indefinitely. If you zoom in, the sketchmorph would move outside the bounds of its owner but would still be on the screen. The solution with buildings as images seemed to work better because we were able to show a building even if half of the image should fall off the form. To perform the zoom we wrote a function to enlarge the map and then display the portion of the map around the mouse click. For building clicks, we placed a rectangle to bound the buildings image and register whether or not it had been clicked. After most of the program had been coded, we ran into a problem with these clickable rectangles. After troubleshooting we found that the problem was not an error in our calculations, but something caused by using a SystemWindow. It turns out that the SystemWindow throws off the coordinate system of the form. Once we changed to a SketchMorph, without a bounding SystemWindow, the coordinate system lined up again. After some discussion, our group decided that the best way to allow for zooming to a building was through a menu selection.

Map with all buildings shown:
Uploaded Image: m4screenshot1.gif

Our Code:
Uploaded Image: P4 Diagram.gif

Class Descriptions

Map - the core of the 'business logic' of the system. the map contains a collection of Nodes or graph composed of Nodes (either intersection or building nodes) that it can traverse to find routes from one building to another. The traversal algorithm it uses is breadth-first, ensuring the shortest distance between two points. However, this shortest distance will be the route with the fewest number of intersections and buildings not simply the shortest statute distance. Given two endpoints (buildings) the Map will traverse its graph to find a route and then create a Route to represent the sequence of streets needed to make the traversal in the graphical representation. In addition to containing the graph representation of the the map components, the Map contains the coupled presentation data (but no presentation logic - that is handled by Display Related classes) that complements the logical graph representation. The Map also contains all created Tours and Routes that can be used by presentation logic to move the user through a virtual tour of the campus (respectively in 2D and 3D).

MapMorph - the 2D rep of the Map. Extends SketchMorph Composed of BuildingMorphs and lines drawn by a pen onto the morph to represent a flat view of the map. Handles user interaction such as mouse clicks for zooms or selection of buildings for route finding. Relyies on Map for the data representation of what it is responsible for displaying as well as for finding routes between buildings. Handles zoom functions, since these are very specific to a 2D display (but relies on Map for data rep of this). Also, handles display of a route between two buildings in the 2D environment.

ImageRectangle - subclass of rectangle that is used to create a represenation of the clickable image of a building that is being displayed on the map. The image rectangle is checked to see if the mouse click occured within it. If the click was inside, the building is able to be accessed by the owner.

Building - data representation of a buiding on the map. Simply a data class for a particular building

Street - data rep of a street on the map. Contains info necessary for describing a street in the system.

Reflections on our Solution

Like I had stated before, we had problems initially with using a SystemWindow that was corrected by using a Form inside a SketchMorph. Our solution of making buildings forms bounded by a Rectangle instead of SketchMorphs proved very flexible and worked out very well. For the most part our overall design and class structure for P4 worked out well. The function used for calculating the zoom allowed us to do other things besides zooming. We were able to provide functionality for recentering on a point without zooming. Our zooming function allowed us to do this by simply calling the function but passing in the current zoom level again instead of the zoom increased by one. Our choice of using a menu for zoom turned out well, it allowed the user a simple but easy to use way of choosing between options without crowding the GUI with lots of buttons.

Refactoring Ideas

One change that we should of done for P4 that was implemented in P5 was the arranging of building in the menu list. Out P4 had a large list of buildings (over 150) that were not sorted, so finding a particular building could be a little tedious.

Words of Wisdom

Links to this Page