$63 fixed project work

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:

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

· 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.

.