Professional Documents
Culture Documents
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.
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
Purpose: To display forms, controls, images and sounds to the user to create a fluid and
efficient user experience.
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.
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.
o Landmark Controller
Current Closest Landmark – Holds the current closest
landmark. Will be of type Landmark Record class.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.