Campus Connect Team B Architecture Document

Campus Connect Team B – Winter 2007

Table of Contents
1.0 Introduction……………………………………………………………… 2
2.0 High Level Hierarchy…………………………………………………… 2
2.1 Hierarchy Diagram……………………………………………… 2
2.2 Hierarchy Description…………………………………………... 2
3.0 Components Classification……………………………………………… 3
3.1 Presentation Layer………………………………………………. 3
3.2 Controller Layer…………………………………………………. 4
3.3 Business Layer…………………………………………………... 4
3.4 Record Layer…………………………………………………….. 5
3.5 Data Access Layer……………………………………………….. 6
3.6 Database Layer…………………………………………………… 7
4.0 Process View……………………………………………………………... 8
4.1 Description……………………………………………………….. 8
4.2 Application Thread………………………………………………. 8
4.3 Presentation Thread……………………………………………… 8
4.4 Connection Thread……………………………………………….. 9
4.5 GPS Thread………………………………………………………. 9
4.6 Device Thread……………………………………………………. 9
1.0 Introduction

The Campus Connect Team B (CCB) Architecture Document is designed to illustrate and
identify the high level architecture systems used to design and implement the Campus
Connect application. The document contains an overall view of the system hierarchy,
logical views of the system components, and a process view of the system’s
communication.

2.0 High Level Hierarchy

2.1 Hierarchy Diagram

2.2 Hierarchy Description

The architecture system for the CCB application is an n-tier architecture. This
architecture system is designed to allow for proper information hiding, modular
components, and single system dependencies. The abstraction of the presentation layer,
and consequently the User Interface (UI), allow for a flexible pipeline for the
optimization of the UI to meet customer needs and expectations. There are multiple
layers between the Presentation Layer and the lowest level, due to the significant
challenges present in the optimization and control of the Processes design. The Database
layer is the lowest level in the hierarchy, and is an abstraction used to represent both text
data (in the form of XML files), and serial device data.
3.0 Components Classification

3.1 Presentation Layer

Purpose: To display forms, controls, images and sounds to the user to create a fluid and
efficient user experience.

Specific Nature: The presentation layer will be in charge of displaying appropriate

images, menus, and sounds to the user. This layer will also be in charge of handling stylus
clicks. When a user clicks a menu on the GUI, the code corresponding to that event will
be called. This layer will also be in charge of the spawning of appropriate threads. The
need of spawning extra threads is due to the fact that the main thread of the app will be
watching for event clicks, but we also need another thread constantly running to get the
users current position.

Subcomponents: Image Viewer, Audio Player, Current State

Current State – The Current State will be a global class that will get
updated by the Presentation Thread. The Current State class will be read
from the main thread of the app at a specified time interval as governed by
a timer. The Current State class will have the following design:

o Current State
 Landmark – Holds the current closest landmark. Will be of
type Landmark Record class.
 User – Holds the current User position. Will be of type
User Record class.
 Sound – Descriptor for the current sound or music to be
played.

The Current State must be synchronized. This is due to the idea of thread
safety. We do not want the main thread to read the Current State class
while the Presentation Thread updates the Current State class. The
synchronized keyword basically puts a lock on the Current State class
while a thread is using it.

Image Viewer – The Image Viewer subcomponent is used during the

Walking Tour and during the Interactive Map mode of the application. Its
responsibility is to display the appropriate image as determined by the
Landmark held in the Current State.

Audio Player – The Audio Player subcomponent is responsible for

playing the proper sound effect/music/description as determined by the
Current State. The Audio Player must be able to load and play .Wav files,
 as well as be able to pause and stop. Pending functionality is a fade-in
transition.
3.2 Controller Layer

Purpose: Processes and responds to events, typically user actions, and may invoke
changes on the model.

Specific Nature: The controller layer in our program will be in charge of getting the
closest landmark to the current user position. It will do this on a constant interval of k. k
is a 5-10 second time step that will be determined through testing. This layer populates
the closest landmark based off of user input. In this case, user input is the user walking
around. This will notify the presentation layer when the closest landmark has been
updated.

Associated Constructs: Landmark Controller

 Landmark Controller – Landmark Controller class will consist of the

closest current Landmark according to user position. This class will be
updated with the new closest Landmark every k seconds. This Landmark
Controller will be executed by the Presentation Thread while the user is
taking the Walking Tour.

o Landmark Controller
 Current Closest Landmark – Holds the current closest
landmark. Will be of type Landmark Record class.

3.3 Business Layer

Purpose: This layer is in charge of the heavy algorithm business logic found in complex
solutions.

Specific Nature: This layer will be used to compute the algorithm for finding the user’s
current position and the closest landmark. The closest landmark algorithm will be located
in a class called Landmark Manager. The user location algorithm will be located in a
class called User Manager. This layer will also contain a class called Error Manager. This
class is in charge of getting the appropriate error message based on the actions of the user.

Associated Constructs: Landmark Manager, User Manager, Error Manager

 Landmark Manager – Landmark Manager class will consist of a method

to find the closest landmark according to the current user position.

o Landmark Manager
  Get Closet Landmark() – Will compute the closest
landmark according to user position. Returns a Landmark
Record data type.

 User Manager – User Manager class will consist of a method to find the
current user position.

o User Manager
 Get Current User Position() – Will compute the current
user position. Will return a User Record data type.

 Error Manager – Error Manager class will consist of a method to find the
current error.

o Error Manager
 Get Error() – Will return the current error depending on the
actions of the user. Will return an Error Record data type.

3.4 Record Layer

Purpose: This layer is in charge of containing the classes that strictly consist of data.
Little to no functional methods will be found in these classes.

Specific Nature: This layer will be used to store User data, Landmark data, and Error
data and Location data. These classes will only contain properties (variables) that
describe each data type.

Associated Constructs: User Record, Landmark Record, Error Record

 User Record – User Record class will consist of only properties

describing a user. This class will be static, meaning there is only one copy
of this class in memory once initialized until the end of the program. This
will be static because of the ease of dynamically updating the latitude and
longitude of only one static user in memory.

o User Record
 User Type – Will hold the type of user that is using the
device. Possible values are: Technical and Non-Technical.
A Technical User Type signifies the user will be navigating
the device with a stylus and menus. A Non-Technical user
will signify that the user will be only walking around the
campus, without the use of menus and the stylus. This
property is of type string.
  Current Lat - This will hold the current latitude of the user.
This will be of type string.
 Current Long - This will hold the current longitude of the
user. This will be of type string.

 Landmark Record – Landmark Record class will consist of only

properties describing a Landmark.

o Landmark Record
 Name – Will hold the name of the landmark. This property
is of type string.
 Latitude – Will hold the latitude of the landmark. This
property is of type string.
 Longitude – Will hold the longitude of the landmark. This
property is of type string.
 Description – Will hold the description of the landmark.
This property is of type string.
 Image Source – Will hold the local path of the landmark’s
image. This property is of type string.
 Sound Source – Will hold the local path of the landmark’s
sound description. This property is of type string.

 Error Record – Error Record class will consist of only properties

describing an error.

o Error Record
 Name – Will hold the name of the error. This property is of
type string.
 Description – Will hold the description of the error. This
property is of type string.

3.5 Data Access Layer

Purpose: This layer is in charge of communicating to the database. This layer should
handle all of the database transactions and connectivity.

Specific Nature: This layer will be in charge of communication to our database which
will in turn lead to populating the record layer. Our database in this project will consist of
XML files and serial device data from GPS satellites. The GPSDAL class will be used to
strictly communicate to the external GPS satellites and return current latitude and
longitude coordinates of the user. The Landmark DAL class will be used to read the
Landmarks XML file and populate Landmark Record classes based on the data in the
Landmarks XML file. The User DAL class will be used to initialize a User Record class.
This User DAL class will only be in charge of initializing the User Record class to null
because we will not be storing different user types in an XML file. The Error DAL class
will be in charge of reading an Error XML file and populating all of the Error Record
classes according to all of the different types of errors the system can throw.

Associated Constructs: Landmark DAL, User DAL, Error DAL

 Landmark DAL – Landmark DAL class will be used to read the

Landmarks XML file and populate Landmark Record classes based on the
data in the Landmarks XML file.

o Landmark DAL
 Get Landmark() – This method will read in a Landmarks
XML file and populate a Landmark Record class. This
return type is of type Landmark Record.

 User DAL – User DAL class will be used to initialize a User Record class
to null.

o User DAL
 Get User() – This method will return an initialized User
Record.

 Error DAL – Error DAL class will be used to read the Errors XML file
and populate Error Record classes based on the data in the Errors XML
file.

o Error DAL
Get Error() – This method will read in an Errors XML file and
populate an Error Record class. This return type is of type Error
Record.

3.6 Database Layer

Purpose: This layer is in charge of storing data in persistent storage.

Specific Nature: This layer will consist of XML files. These together will be our
database management system. These XML files will store Landmarks, Errors, and
eventually Language Support. Serial device data received from the embedded GPS device
will also be considered part of the abstract database layer.

Associated Constructs: Landmarks XML, Errors XML, GPS Interface

 Landmarks XML – Landmarks XML will be used to store all Landmarks

that will be supported in our system.
 o Landmarks XML
<campus>
<building>
<name>Flarsheim Hall</name>
<lati>39.020119</lati>
<long>94.343871</long>
<descrip>blank</descrip>
<img>Resources//fh.jpg</img>
<snd>Resources//fh.wav</snd>
</building>
</campus>

 Errors XML – Errors XML will be used to store all Errors that could be
used in our system. *design is currently incomplete

 GPS Interface – This module is the direct interface between the database
layer and the available Mobile 5.0 methods provided for the embedded
GPS device.

 Get Longitude( ) & Get Latitude( ) methods are used to

obtain the current location of the device once an event is
fired by the GPS Thread.

4.0 Process View

4.1 Process View Description

The Process View is essential in understanding how the separate components and
subcomponents communicate with each other in a concurrent application. By better
understanding the necessary paths of communication between the components, it may be
possible to optimize the data flow and storage of the application, as well as ensuring
thread-safety.

4.2 Application Thread

This thread is the main application thread that is created at runtime of the program. The
program creates the thread; this is not a user created thread. This thread handles the basic
program flow by controlling navigation between forms, and processing window events,
including the handling of user input to the graphical forms.

4.3 Presentation Thread

This thread is user created, when the application enters the Walking Tour mode. This
thread is responsible for seeking the nearest landmark and then relaying this information
to the Presentation Layer, where this thread requests that Image Viewer and Audio Player
subcomponents update the current presentation when necessary.

4.4 Connection Thread

This thread is user created. This thread is in charge of always checking if the connection
to the GPS device is valid and working. Before we switch between certain forms in our
application, we will be checking this connection thread to ensure that the connection is
valid before proceeding. This thread is also in charge of keeping track of the seconds of
time that the connection has been invalid. If the connection has been invalid for a certain
time of k seconds, we will notify the user and try to re-connect. If the connection has
been invalid for less than a certain time of k seconds, we will continue with our program
flow without notifying the user that the connection has failed while attempting to
reestablish the connection.

4.5 GPS Thread

This thread is user created. This thread will always be reading the current user latitude
and longitude from the GPS device. This thread will be providing our program with all of
the necessary information about user position, and will be updated every time the user
changes position. The connection thread will be constantly checking with this thread for a
valid connection.

4.6 Device Thread

This thread is user created. This thread will always be reading the current state of the
device. This thread will keep track of the device state and if the device state has changed,
it will fire off an event notifying the change of the device state, thus resulting in the GPS
thread updating the current position. The Connection thread does not communicate
directly with this thread.