Project scope
Report for the Weather Tracking System
This project is a prototype electronic weather tracking system which monitoring three simulated sensors, temprature sensor, humidity sensor and light sensor. The simulated sensors generate data in intervals and store the data in to database. The users of the system can subscibe weather changing message, such as when the temprature is turing very high.
- The weather tracker: the weather tracker generates random values for the active sensors which are implemented by threads, the samping frequency is stored in thedatabase. When clear the sensor, all the data about the sensor is removed.
- The weather subscriber: the weather subscriber contains the email information and the threshold values for sensors. The weather subscriber is managed by the notification page.
- The send mail manager: the send email manager
- The status of the sensor: the status of the sensor is active or not
active, start and stop the sensor will change the status.
Project Tools
The project is implemented on the computer which has Intel CoreTM i3 CPU [email protected] with 2 cores, total memory is 4GB. The develop tool is Eclipse Java EE IDE for Web Developers, the version is Luna Service Release 2(4.4.2). To support the project, the system uses JDK 8.0.
To deploy the project, make sure that you have all these softwore installed. On the server side, Tomcat v8.0 and MySQL Server 5.1 are required. On the client side, a browser which supports HTML5 is on demand. Follow these steps:
(1)Unzip the server.zip on the server and on the tomcat work directory webapps
(2) Start the mysql server, and run the sql script file weathertrack.sql on the mysql server.
(3)Configure the server side, if the mysql server is not on the same
machine with tomcat, configure the property file WEB-INF/classes/config.properties.
Edit the jdbc.url,jdbc.username,jdbc.password.
- (4) Put the client.zip on the client, unzip it.
- (5) Configure the client side, configure the property file config.js,
Edit the server_url.
- (6) Open the html pages with the browsers.
Requirement Analysis
Theres no user role management in this system which only has one kind of user rule: user. The user can manage the sensor, view the sensor data and manage the subscriber. For sensors, the client needs to start and
stop sensors, clear sensors, select active sensors. The operations on the sensor can change the sensor data. For the sensor data view, the difference of the active sensor and not active sensor is displaying colorful image versus gray image. For subscribers, the user can query the subscribers, or add subscriber, delete subscriber or edit subscriber.
active the sensor
<<uses>>
clear restart the sensor
weather tracking system
manage sensor
<<uses>>
stop the sensor
select all sensor
<<extends>>
add subscriber
select subscriber
remove subscriber
select active sensor
select sensor data
manage subscriber
edit subscriber
user
Implementation
On the server side, the nearly all the use cases has its servlet. Theres a thread sending email to the subcribers when their intrested weather happens. I use a blockingqueue to store the emails which have not been sent. The weather tracker generated random values, which will update the send mail
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
<<includes>>
manager to check wheather trigger the threshold. So the send mail manager contains a list of subscribers. Start another thread to send email is for that sending email is always time consuming.
The statistics is done by the sensor jdbc classes. The algorithm is as follows.Assume the new generated data is x, its the ith data, then
??? =???+?
??? = ??? ?+1
?? = (??2 +???2)(?1)+?2 ???2 ??
On the client side, the html use css to control its view, java script to control its structure. The javascript changes the sensor image depends on whether its active and updates the statistics data when the sensor generates new data.
Design
On the server side, the UML class diagram has many classes, its unimpossible to display them in one picture. So we split it to several small ones by the relations.
The sensor management class diargram contains all the operations on sensr. The QuerySensorEndpoint is like the SelectSensorServlet, the difference is that it can send to the client without a request. This is the C/S pattern.
The sensor data related class diagram is simple without servlets. The WeatherTracker starts several SensorThreads to generate data for active sensors.
The weahter subscriber related class diagram is as follows, which includes server
Servlets to update the database and an EndPoint class to send data to client.
The mail sending related diagram is as follows. SimpleMailSender is responsible for send a mail. SendMailManager starts a thread to send mails and check the subscribers threshold.
Some utils related class diagram is as follows. The MySQLConnector is used to connect the mysql database server. The SimpleMail reprents the email object.
For the client side, the follow table gives a summarization for all the functions in the javascript.
javascript functions on setup.html
function name |
description |
weatherTrackerClient.onmessage |
the web socket client will change the html page when receive message from the web socket server |
weatherTrackerClient.onopen |
do what when the web socket client connect the web socket server, usually request data |
active_sensor |
active sensor when click the button, send request to the servlet and change the color of the button |
stop_sensor |
stop sensor function when click the button, send request to the servlet and change the color of the button |
clear_sensor |
Clear sensor when click the button |
selectActiveSensors |
select active sensors when click the button |
selectAllSensors |
select all the sensors when click the button, default display all the sensors |
javascript functions on dataview.html
function name |
description |
randomColor() |
to generate random color to display the statistics data |
weatherTrackerClient.onmessage |
the web socket client will change the html page when receive message from the web socket server |
weatherTrackerClient.onopen |
do what when the web socket client connect the web socket server, usually request data |
javascript functions on notification.html
function name |
description |
weatherTrackerClient.onmessage |
the web socket client will change the html page when receive message from the web socket server |
weatherTrackerClient.onopen |
do what when the web socket client connect the web socket server, usually request data |
createDataTable |
create an empty table to display the subscribers when no search |
send |
the websocket client send data to the server, for send queries |
deleteSubscriber |
delete the subscriber when the link is clicked, post request to the servlet |
editSubscriber |
edit the subscriber when the link is clicked, post request to the servlet |
nextPage |
when query the subscribers, go to the next page of the query results |
prevPage |
when query the subscribers, go to the previous page of the query results |
firstPage |
when query the subscribers, go to the first page of the query results |
Modularity
The MVC design pattern is used both on the server side and the client side. On the server side, the model is the JavaBeans, the controller is the servelet, the view is the websocket server. The JavaBean represents the actual data on the mysql table. The websocket server communicates with the client side when the data changes, so the websocket server must know the recent data. The servlet get requests from client side forms, then the servlet call JDBC to change the database, the servlet call the websocket server to send the new data to the client side.
On the client side, the model is the websocket client, the view is the HTML page, and the controller is the javascript function. The websocket client communicates with the websocket server and receives changed data from it. When data changes, websocket client calls the javascript functions
to change the view, both the HTML structures and the displaying text content. Besides, the HTML page post user requests to the servlet on server.
Besides, I used the observer design patterns otherwhere. Theres a thread for the sensor whic is active to generate data. There is a thread to send email when the data changes and reaches someones threshold. So the thread generating data is the observable object, the thread sending email is the observer object, and the websocket server is also the observer object.
Database
All kinds of sensors are in a table and so their datas. Each sensor may have many datas and many discribers. Each email can subscribe different sensors on different value.
1 1*
*
sensor |
weather_subscriber |
sensor_data |
Table for sensor
column |
Type |
constrains |
id |
Tinyint |
primary key,auto increment |
sensorType |
Varchar |
not null, unique |
maxValue |
Tinyint |
not null |
minValue |
Tinyint |
not null |
isActive |
Tinyint |
not null |
activeDate |
datetime |
not null |
samplingInterval |
Int |
not null |
Table for sensor_data
column |
Type |
constrains |
id |
Int |
primary key,auto increment |
date |
datetime |
not null |
sensorId |
Tinyint |
not null,foreign key |
nth |
Int |
not null |
value |
Tinyint |
not null |
sum |
Int |
not null |
avg |
Double |
not null |
sd |
Double |
not null |
Table for weather subscriber
column |
Type |
constrains |
id |
Int |
primary key,auto increment |
|
varchar(255) |
not null |
opchars |
varchar(8) |
not null |
threshold |
Tinyint |
not null,foreign key |
sensorId |
Tinyint |
not null |
Reviews
There are no reviews yet.