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 M3 Case Study

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

The Problem:

Check out the milestone description - Sp2002 P3 - Design the whole thing

Our Approach

When we first began working on the project, we each took time to read all of the milestone descriptions through M7, taking special note of functional requirements. After we were all familiar with the problem - as much as we could be having never completed a large-scale squeak project - we began developing scenarios (use cases) to describe the functional requirements of each milestone.

With our use cases in hand, we began brainstorming for classes that would comprise the system. In doing this, we took time to talk about what exactly comprises a map, a campus, a tour, a building, a street, etc... as far as real world objects are concerned. Then we began translating these real world objects into classes focusing on behavior and data, as well as its interface. Once we had a framework for the class structure, we began filling out the classes by walking through our use cases and breaking them into discreet responsibilities, then assigning those responsibilites to the classes in the form of method stubs. For each collaboration relationship between classes, we wrote method stubs on the collaborating object to represent this interaction.

As we were not familiar with Ecode at the beginning, we used Ecode as a way to develope a second draft of our design. We found Ecode to be quite constraining (only one collaborator per responsibility collaborator pair, for example) so it forced us to rethink our design in terms of the Ecode model of OOA&D. We already had the analysis and design, putting it into Ecode just allowed us to refactor it a bit.

Our Solution

Our Code:
Uploaded Image: UmlDiagram.gif

Class Descriptions

These are the descriptions of the responsibilities for the classes we came up with.

Data Related
Building - data representation of a buiding on the map. Simply contains data for a particular building
Street - data rep of a street on the map. Contains info necessary for describing a street in the system.
Intersection - data rep of the interesection of two streets containing info needed to fully describe such an intersection
Route - the data representation of the transition from one building (location) to another via the data rep of the streets
Tour - a collection of Routes coupled with an optional description of each endpoint that is to be read aloud by the system.

Graph Related
Node - a generalization or superclass for the two types of nodes that exist in the sytem.
It can provide a list of adjacent nodes for use in traversals/searches.

BuidlingNode - a special node that represents a building's place in the map's graph structure.
Is composed of a Building class that represents the data detail for the node

IntersectionNode - a special node that represents the intersection of two streets in the structure
of the maps graph. Is composed of an Intersection object that represents the data detail for the node.

Business Logic Related
Map - the core of the 'business logic' of the system. the map contains a collection of Nodes or graph composed of 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. 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).

GTCampusMap - this class is simply a subclass of map used to initialize the map with data specific to a Georgia Tech
campus map. Other, similar maps such as EmoryCampusMap and GSUCampusMap could be created to represent their
respective campuses.

Display Related
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.

BuildingMorph - the 2D rep of a building. Able to handle user interaction such as mouse clicks used for zooming. In this case, BuildingMorph would rely on MapMorph to zoom/center according to how the BuildingMorph was selected by the user.

3DDisplay - rep of map in 3D world. Repsonsible for handling user interaction such as selecting a tour, and taking a tour of buildings. Relyies on Map for data representation of everything that it displays. It also relies on Map for Tours and finding Routes. 3DDisplay can use such a route to allow the user to move directly to a buildings location without being on a tour.

Reflections on our Solution

At the time, we felt that we had a pretty solid solution. As with most projects, imperfections in our design surfaced once we started implementing it. One of the most notable was having BuildingMorph extend SketchMorph. This was changed for a number of reasons described under the M4 Case Study. Looking back now, after having completed all 7 milestones, it is gratifying to see that all the work we spent in the intial design really paid off. While implementation may have changed as methods were moved about or added, the class structure and initial high-level design changed very little.

Refactoring Ideas

If we were to refactor, from this initial design phase, we may have delegated several of Map's responsibilities to other (or possibly new) classes. Most of the business logic of the program is in Map and while it worked out very well in this way, it may have not been the most elegant solution.

Words of Wisdom

Links to this Page