pathfinder 1.0 the terrabyters © 2004. terrabyters kristi olson, team leader heather koyuk,...
TRANSCRIPT
PathFinder 1.0
The TerraByters
© 2004
TerraByters
Kristi Olson, Team Leader Heather Koyuk, Technical Lead Chris Ochap, Developer Susmita Chatterjee, Developer
PathFinder 1.0 Requirements
Users must find the process seamless. Users with any level of technical expertise
should be able to use PathFinder correctly on their first try.
PathFinder needs to consistently return correct images.
PathFinder needs to handle images of up to 1.5K.
PathFinder 1.0 Iterations
Group decided on iterative development.– Each iteration was tested and verified before
moving on to further iterations.– Iteration 1 was to meet basic requirements as
defined by Dr. Mock.– Iteration 2 incorporates panning and zooming.– We had time to incorporate other features beyond
what we originally anticipated.
Features of iteration 1
User interface with drop down menu:– File: Open, Close
Route images initially drawn at a scale calculated from the size of the route.
Route images initially centered on the screen.
Features of iteration 2
Panning– Uses an offset to ensure image remains on
screen for first panning operation.
Zooming– Pop up error windows if the user tries to pan too
far in or too far out.
More features of Iteration 2
Ability to save images.– Saves as type .jpg
Print Preview and Print options. Ability to switch between Aerial
(photographic) and Topographical images. User manual linked to “Help” on user
interface.
Features iteration 2 continued
Properties box:– Information for name, size, and location of file.– Number of data points in file.– Minimum and Maximum latitude and longitude.
About box:– Information about program and developers.
Center latitude and longitude points are displayed on the user interface.
Team process
Group decisions:– TerraService API
.NET environment and C#.
Splitting up the work:– Defined four basic modules:
User interface XML parsing Getting the Terra Server images Drawing the route
SE
Heather’s design decoupled the modules and made the processes of integrating the modules and iterative development simple.
Who worked on What
Heather:– Technical lead. – Developed design.– Classes Coded:
View, Controller, Error Dialog, About, Map, Properties, DataPoint.
Modified Weiss code for LinkedList, LinkedListItr.– Fixed anything we couldn’t and improved much of what we
wrote.– Handled integration.– Wrote the Test Plan and large part of Requirements and
Design documentation.
Who worked on What
Chris:– CoursePlot and File.– Wrote User’s Manual and contributed to
documentation.
Susmita:– XML parsing.– Wrote User’s Manual and contributed to
documentation.
Who worked on What
Kristi:– Team Leader.– Wrote GetImage, modified LinkedList.– Contributed to documentation.– Meeting notes.– Supplied the bagels and cheese!
What we learned
The importance of Human Communication– Check, double check, triple check to make sure we are all
on the same page.
The importance of deadlines– Without a deadline of iteration 1, we may never have gotten
around to iteration 2.
User interface– If this were a product intended for the general public, we
would have needed to test the user interface sooner with members of the general public.
More of What We Learned
Theoretical side of SE vs. Reality– Design modifications: from "Main with Shared
data" / ADT to MVC with Observer then settled on MVC with shared data.
– XML Parser: from pre-existing parser with interface, to modifying a pre-existing parser to using .NET XML libraries.
– More about this in a minute…
Yet More of What We Learned
Gained experience in integrating modules. Learned about the benefits of a formal
documentation process for Requirements and Design.
Learned about XML, .NET, and C#. Gained experience working with APIs.
The Software Engineering Process
Heather will now talk about the process and design
The Software Engineering Process
The Language – C# The Environment - .NET The Design The Implementation
The Software Engineering Process
The Language – C# The Environment - .NET The Design The Implementation
The SE Process – The Language
We decided on C# for interfacing with the TerraService API and for code re-use
C# is very similar to Java– Sample C# code:
public void openFile(string filename, Route r)
{
myRoute = r;
this.parseXML(filename);
}
The Software Engineering Process
The Language – C# The Environment - .NET The Design The Implementation
The SE Process – The Environment
The .NET environment helped a lot in the development of PathFinder– “Point and Click” GUI development– “Nice” (i.e., useful) compiler error messages– Precompiled dialog boxes (Open File, Save As,
Print Preview, and Print boxes)– Useful help files– Helpful prompts
The SE Process
The Language – C# The Environment - .NET The Design The Implementation
The SE Process – The Design
Began with “Main with Shared Data” combined with “Abstract Data Types”
Then, Model-View-Controller with Shared Data, Observer Pattern– Model split into two parts, Operators and Data– Operators would be observers, Data would be
subjects– Controller’s only job was to initialize other
modules
Model-View-Controller
Model-View-Controller with Observer Pattern
The SE Process – The Design
Issues with Observer Pattern Final Design: MVC with the following
changes:– Model split into two parts, Operators and Data
classes– Operators operate directly on Data– All other method calls go through the Controller– Data notifies the Controller when it’s been
changed
Model-View-Controller with Operators and Data
The SE Process
The Language – C# The Environment - .NET The Design The Implementation
The SE Process – The Implementation
Of course, the code itself changed dramatically throughout the semester
For instance, we had originally wanted to use an external XML Parser
– Looked at 3 different parsers in 2 different languages– Finally, we wrote our own parser based on preexisting XML
functionality built into .NET– Which left nothing for our File class to do, so we combined
our parser with our File class
FINAL IMPLEMENTATION
Our final implementation includes 13 classes– Controller: the “brains” of the program – View: the Graphical User Interface– 3 Operator classes
File: Opens a file, parses the XML, and create a Route GetImage: Retrieves and puts together the image from
TerraServer CoursePlot: Draws the route on top of the image
– 2 major Data classes Route: contains a linked list of data points from the XML file Map: the map image and associated data
FINAL IMPLEMENTATION
3 supplemental data classes– LinkedList: a linked list of DataPoints– DataPoint: structure to hold information (latitude, longitude,
etc.) from each point in the XML file– LinkedListItr: Iterator for the Linked List
3 internal dialog boxes– About: Displays information about PathFinder and its
developers– Properties: Displays information about the current XML file
and current Route– ErrorDialog: displays a variety of errors to the user
FINAL IMPLEMENTATION
Additionally, 4 external .NET dialog boxes are used:– OpenFileDialog– SaveAsDialog– PrintPreviewDialog– PrintDialog
FINAL IMPLEMENTATION
The following slide shows the general structure of the PathFinder program (not including the dialog boxes or LinkedListItr)
Operator Classes in more detail
File– Opens a file, parses the XML, and create a Route
GetImage– Retrieves and puts together the image from
TerraServer
CoursePlot– Draws the route on top of the image
File Module: Chris Ochap
Uses a Linked List of DataPoints:– The Linked List is a logical representation of the entire
route.– Each DataPoint within the Linked List is a logical
representation of a trackpoint from the Garmin XML file.
Uses C# XML parsing libraries:– Each <trackpoint>…</trackpoint> tag within the XML input
file contains coordinate information needed to populate the necessary fields in a DataPoint object .
File Module: parseXML()
Recursive: – Could have been written iterative, is more elegant
when written recursive.– The module will only call itself if an XML node has
another level of child node(s) below it.
File Module: parseXML()
For example, <Position> is a child node of <Trackpoint> and <Latitude>, <Longitude>, & <Altitude> are all child nodes at the same level below <Position>.
- <Trackpoint>– - <Position>– <Latitude>61.19035</Latitude> – <Longitude>-149.82023</Longitude> – <Altitude>47.723</Altitude> – </Position>– <Time>2004-08-27T20:15:13Z</Time> – </Trackpoint>
File Module: parseXML()
The parseXML() method calls itself twice to read in the values displayed above once it is at the <Trackpoint> node level.
As the parseXML() method extracts data for a specific trackpoint, new DataPoint objects are created, and inserted into a Linked List.
Operator Classes in more detail
File– Opens a file, parses the XML, and create a Route
GetImage– Retrieves and puts together the image from
TerraServer
CoursePlot– Draws the route on top of the image
GetImage: Kristi Olson
TerraService API– GetImage uses the TerraService
AreaBoundingBox to retrieve the tiles.– Works off the center most point of the XML data.– For panning, update the center point with each
panning operation.– For zooming, update the scale parameter.– For image type, update the Theme parameter.
Operator Classes in more detail
File– Opens a file, parses the XML, and create a Route
GetImage– Retrieves and puts together the image from
TerraServer
CoursePlot– Draws the route on top of the image
CoursePlot: Chris Ochap
This module works with a Linked List of DataPoint’s and the composite map image retrieved using the GetImage() module.
The Linked List of DataPoints that the CoursePlot() module uses is assembled using the parseXML() method contained in the File() module.
Each DataPoint object contains all available coordinate information for each specific recorded point within the XML input file.
CoursePlot
X & Y coordinates are calculated as the CoursePlot() module iterates though the Linked List of DataPoint’s.
A line is drawn on the composite map image using the calculated X & Y coordinates of the current DataPoint and the DataPoint next in the Linked List until the end of the list.
C# graphics manipulation libraries are used to draw lines representing the route on top of the composite map image retrieved from TerraServer by the GetImage() module.
CoursePlot
My team is mean because they wouldn’t let me draw cute little points for each <Trackpoint>…</Trackpoint>.
When CoursePlot() is done iterating through the Linked List of DataPoint’s, it notifies the Controller() that it’s task is complete.
User command: Open File
User presses Open File button
User command: Open File
View opens an OpenFileDialog box
User command: Open File
User selects a file
User command: Open File
View sends command to Controller
User command: Open File
Controller sends command to File
User command: Open File
File changes Route
User command: Open File
Route notifies Controller
User command: Open File
Controller sends command to GetImage
User command: Open File
Using data from Route, GetImage operates on Map
User command: Open File
Map notifies Controller
User command: Open File
Controller sends command to CoursePlot
User command: Open File
Using data from Route, CoursePlot draws route on Map
User command: Open File
Map notifies Controller
User command: Open File
Controller sends command to View
User command: Open File
View redraws its picturebox image
PathFinder 1.0
Demo