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

RF M3 Cases Page

Milestone 3 - Design in a can.


Current - Sp2002 P3 - Design the whole thing

Future - Sp2002 P4 - Do the WHOLE campus
Future - Sp2002 P5 - Help people find their way
Future - Sp2002 P6 - Make it 3D and allow for tours
Future - Sp2002 P7 - Make an IMAGINARY, BIG tour and test your design


As far as M3 was concerned, there were 5 major requirements.
1. Use case scenarios
2. CRC cards
3. UML class diagram
4. Team member responsibilities
5. Timeline w/ assignments and due dates

However this milestone demanded that all future milestones be considered, as we were asked to do all the above for all milestones up to the end of the semester. This milestone was not merely a practice in creating the forementioned materials, but an exercise in foresight. As such, we needed to analyze the following, major problems introduced by various future milestones. (In no particular order)

1. 2D view of the campus map (buildings and streets)
2. 3D view of the campus map (buildings and streets)
3. 2 levels of zoom on the 2D map, with visual adjustments based on the level of the zoom being used.
4. Pathfinding based on streets, buildings, and tours.
5. The data file containing information describing the campus, in terms of buildings, streets, tours, and # of dimensions must be totally interchangable.
6. User must be able to create new tours.

Note there are a variety of other goals and constraints, but these were the main objectives. For more information, follow the links under Problems.


Bring up CRC, and UML gifs. Ecode screenshots?

The following is the UML class diagram for M3. There are three major areas within the design. The first major area is the data model, which is depends entirely on the input data file read by GTCampusMap. The view mode of the map is determined, 2 or 3D based on a single character. Then, using a predetermined format, streets and buildings, and finally tours would be read in by the map parser. This in turn creates the MapData object, which in turn holds all the Street and Building objects. Each of these objects only serve to hold data pertaining to that object alone, and nothing regarding how they are supposed to be displayed.

The second major area of the design is the view and control component, which is embodied in MapView, MapControl, and MapView2D/MapView3D. Map Control is basically the area of graphic real estate where we place the user controls. Not too much specification was placed in this object, as we expected it to change with the demands of each future milestone. The MapView was an abstract superclass that forced the 2d and 3d views to implement the universal components. 1. Opening the map. 2. Moving the point of focus. 3. Redraw the map after some change. For more information on the requirements made upon the 2d and 3d views, please refer to the links under Problems.

There third area is the pathfinding area. At the time of this milestone, very little headway was made in predicting exactly how we wanted to do pathfinding. There were eventually going to be 3 different ways to find paths, building/street/tour, and we still weren't too sure on how to operate for the most immediate ones, much less all of them. And then there was the question of representation. Ultimately the goal was to produce a collection of points, and then toss that collection to the mapview in order for it to be implemented appropriately. Thus this area of the UML is rather incorrect, and was changed drastically as the project continued.

Class Diagram
Uploaded Image: p3uml.gif

CRC Cards
Uploaded Image: P3crc.gif

What went right:

Of our three major areas, one was a complete success, and the other was a half success. The first area, the model, was largely unchanged for the entire project. Streets, buildings, MapData, MapParser, and the data file format were almost unchanged for the entire project, even up to Milestone 7.

The second area, the view was half a success. As far as the overall working model, with the abstract mapview, and using instances of MapView2D and MapView3D, no change was necessary to fulfill the objectives of the future milestones.

What went wrong:

A vast number of changes had to be made to both MapView2D and MapView3D. We did not properly anticipate all the details and complexity of representation of the model in either Morphs, or Wonderland. We believe this resulted from a lack of knowledge about Squeak graphics. This lack of knowledge made it much harder, or impossible to use foresight. Instead we were forced to rely on experimentation, and trial by error.

Wrap Up:

With all things considered in hindsight, what observations can be made? The primary observation that can be made is this... Foresight and design are much easier in areas of the designers' expertese and familiarity. The areas of the project which dealt with data structures and algorithms posed very few problems during the lifetime of the project. However the inverse of that statement was true as well. None of us had any experience in Squeak graphics, and thus faced many problems in dealing with designing that area beyond methods which satisfied the use cases, but paid little regard to the implementation problems.

One potential, but untested, solution to this problem would be for that component of the design process take place while a group of the designers sit in front of unfamiliar area, and experiment in building a very simple prototype with tests the most basic functionality. Knowing beforehand how to manipulate agents in wonderland would have aided our design of MapView3D immensely, and would have allowed us more time to solve other problems, like the speed issues in Wonderland.

Link to this Page