ColdWatch Design Description Version 1.5 - FER-a

towerdevelopmentΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 8 μήνες)

193 εμφανίσεις




















ColdWatch

Design Description


Version
1.5


Doc. No.:





ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
2



Revision History


Date

Version

Description

Author

2011
-
10
-
24

0.1

Initial draft, introduction, external
interfaces, error handling

Kristijan Šimunić

㈰ㄱ
-

-


MK2

Add敤 p楣瑵r敳Ⱐsys
瑥m sp散ifi捡瑩tn

Kristijan Šimunić

㈰ㄱ
-

-


MKP

䑥瑡楬敤 d敳楧n 䑥獣a楰瑩tn in捯rpor慴楯n

䅮g楥iAng慲楴愬 卲p敨慲i

㈰ㄱ
-

-


1K1

卥捴楯n 2 r敶楥wing

Luka Postružin

㈰ㄱ
-

-


1K2

卥捴楯n 2, 數瑥tna氠楮瑥tf慣敳⁲敶楥w敤

Luka Postružin

㈰ㄱ
-

-


1


卥捴楯n PKP brror 䡡ed汩lg r敦楮em敮琠

䅮g楥iAng慲楴i

㈰ㄱ
-

-


1K4

卥捴楯n 4KP 慮d 4K4 r敦楮em敮琠
(m敲g攠 of
bo瑨 s散瑩tns 慮d 瑲慣敡b楬楴y b整w敥n us攠
捡s攠d敳捲楰瑩tns 慮d d楡irams)

䅮g楥iAng慲楴愬 卲p敨慲i

㈰ㄱ
-

-


1K5

brror h慮d汩lg has b敥n 數pa
nd敤,
do捵m敮琠tas b敥n form慴瑥a
K

Luka Postružin

㈰ㄱ
-

-


1KS

乥w d慴慢慳攠schem愠pr敳敮t敤

Luka Postružin


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
3



Table of Contents
1.

Introduction

................................
................................
................................
............

4

1.1

Purpose of this document

................................
................................
...............................

4

1.2

Intended Audience

................................
................................
................................
.........

4

1.3

Scope

................................
................................
................................
.............................

4

1.4

Definitions and acronyms

................................
................................
...............................

4

1.4.1

Definitions

................................
................................
................................
................................
.......

4

1.4.2

Acronyms and abbreviations

................................
................................
................................
..........

4

1.5

References

................................
................................
................................
.....................

5

2.

External interfaces

................................
................................
................................
..

5

2.1

Sensor network

................................
................................
................................
..............

5

2.2

Web application user interface

................................
................................
.......................

5

2.2.1

User role

................................
................................
................................
................................
.........

5

2.2.2

A
dministrator role

................................
................................
................................
..........................

5

2.3

Notifications

................................
................................
................................
...................

5

2.3.1

Email notifications

................................
................................
................................
..........................

6

2.3.2

SMS notifications

................................
................................
................................
............................

6

3.

Software architecture

................................
................................
..............................

6

3.1

Conceptual design

................................
................................
................................
..........

6

3.2

System specification

................................
................................
................................
.......

7

3.3

Error handling

................................
................................
................................
................

8

3.3.1

GSN errors

................................
................................
................................
................................
.......

8

3.3.2

Database errors

................................
................................
................................
..............................

8

3.3.3

Web interface errors
................................
................................
................................
.......................

8

4.

Detailed software design

................................
................................
.......................

10

4.1

Deployment Diagram:

................................
................................
................................
...

10

4.2

Component Diagram

................................
................................
................................
.....

10

4.3

Sequence Diagrams

................................
................................
................................
......

12

4.4

Class Diagram

................................
................................
................................
...............

20

4.6

Database design

................................
................................
................................
...........

21

1.

Approvals

................................
................................
................................
..............

22


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
4



1.

Introduction


1.1

Purpose of this document


The purp
ose of this document is to provide the detail design information of the ColdWatch project and its
components (website, databases, global sensor network).


1.2

Intended Audience


This document is intended for following parties:

• Project team; to use it as gui
dance during the project

• Project supervisor; to see if the project is on the right path

• Customers; to see if they are satisfied with the system and its functionality


1.3

Scope


The scope of this document is the project design description. Each component o
f the system will be described
(its purpose, architecture and interface).


1.4

Definitions and acronyms


1.4.1

Definitions


Keyword

Definitions

DBS

Database requirements

WEB

Web interface towards the user

WEB
-
A

Specific requirements for administrator role

WEB
-
U

Specific requirements for user role

NFR

Non Functional Requirements

SECR

Security Requirements

CUS

Customer

SYS

System requirements to be implemented

RET

Requirements proposed by team



1.4.2

Acronyms and abbreviations


Acronym or

abbreviation

Definitions

DSD

Distributed system development

GSN

Global Sensor Networks

ETL

Extraction, transformation, loading


pro捥ss of d慴愠慣qu楲ing

塍i

bx瑥ts楢汥l䵡rkup ianguage

C啓

Cus瑯m敲

䵄e

䷤污ld慬敮 啮iv敲s楴y

䙅c

䙡捵汴y of b汥捴l楣慬ibng楮敥r楮g and Compu瑩


卍p

卨or琠t敳eag攠卥pv楣i

䙅cw敢

佦f楣楡i w敢s楴i for 䙅c on wh楣h 慬氠 r敬ev慮t do捵m敮瑳 w楬i b攠
pub汩lh敤


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
5



1.5

References


Main reference to this project can be found on DSD webpage on FERweb:



http://www.fer.unizg.hr/rasip/dsd/projects/coldwatch


Project proposal can be found on this link:



http://www.fer.unizg.hr/_download/repository/proposal_igor_slid
es.pdf


Design decision document:



http://www.fer.unizg.hr/rasip/dsd/projects/coldwatch/documents/


2.

External interfaces


The system itself is exposed to the users in three diff
erent ways. Main web application has all system
functionality that is available to the administrators and users. SMS and Email application interface are available
for clients to receive useful information about their properties that are under the surveilla
nce.


2.1

Sensor network


Base for all of our features, and a starting point in our system is sensor network. It can be used as an interface
towards the environment we want to observe. Sensor network consists of multiple sensors and a gateway that
collect data
. This will not be developed on this project, because it crosses project scope boundaries. What we
will manage is to develop a virtual sensor network, which will

act as a real one, with similar sensors and value
span that we would have in real life. Since
this is crucial for testing, we will also try to provide getting
information through internet as we could than find more accurate data for testing.


2.2

Web application user interface


The user interface of the ColdWatch system is a user
-
friendly web applicati
on. It is based on HTML, CSS and
PHP. Each user must login with their given username and password. There are two roles: administrator and
common user. Administrator can add and remove users and modify all options that web application offers (more
details i
n section 3 and 4). Users can view all data that is available for them in tables, charts and reports.

2.2.1

User role

After logging in as user, home page is opened with a menu for further actions. User role is defined when adding
a user to the database. There c
an be more than one user in the system of course. Their privileges are not handled
with a role since there will be lot of combinations. Instead, privileges are added later when user can access the
webpage, through already defined interface. User will be ab
le to ask for privileges for GSN servers, and sensors
that are present in the database. This request can only be approved by our administrator.

2.2.2

Administrator role

When logging in as administrator different interface is provided for user. This interface is
more like a panel on
which actions can be selected. Those actions are a connection between our users and GSN since every
communication needs to go through user privilege granting.


2.3

Notifications


There is a specific feature that will be implemented on GSN
server. This features purpose is to alarm our user
when alarming value is read from sensor. All of the parameters for this action will be changeable through a form
that user will need to fill. This feature will be implemented on GSN server and will consist

of two basic ways of
alarming.

ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
6



2.3.1

Email
notifications

First to show is email notifications sending. This will consist of sending emails from exim4 email sender on the
GSN server, through Gmail system. Email address from which this message will be sent will b
e
coldwatch2011@gmail.com
. Gmail is a brand in email world, and will be used because of its reliability and
usefulness. Messages will be sent to our user on email he/she provides to us.

2.3.2

SMS notifications

There

will also be a possibility of SMS notification sending through GSN. When alarming value is measured,
user will get
a

message on his/hers mobile phone. This is pretty useful if someone does not have internet access
all the time, since this service will be
considered
one

of the most important features in our system.

SMS will be
sent from internet provider which works like a
middleman
. We will send simple email to the specified address to
the provider. Message sent that way will be forwarded to our user on pr
eviously specified phone number.



Figure
1

SMS example


3.

Software architecture


3.1

Conceptual design


A Conceptual diagram contains the high level diagram of the design. (See picture 3.1)


User:



Admin user



Registered user.

Web
-
serve
r:

1.

A webserver will have at least one user. That is admin. And many registered users.

2.

Web
-
server to database will have one
-
to
-
one relation.

3.

Web
-
server to GSN will have one
-
to
-
one relation.

Database:

ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
7




1. Database to Web
-
server will have one
-
to
-
one relation.

2.

Database to GSN will have one
-
to
-
one relation.

GSN server:

1.

GSN to Web
-
server will have one
-
to
-
one relation.

2.

GSN to Database will have one
-
to
-
one relation.

3.

GSN can be subscribed to zero or many users.

Sensors: Zero or many sensors can be con
nected to GSN sever.


Picture 3.1


3.2

System specification


Web application is powered by:


Virtual machine: Linux OS

Server: Apache 2.2

Database: PostgreSQL

Languages: PHP, XML

Frameworks: Codeigniter (PHP)

Styles: HTML, CSS

IDE: NetBeans, Dreamweaver


GSN
is powered by:

Virtual machine: Linux OS

Server: Apache 2.2

Database: PostgreSQL

Languages: java

IDE: Eclipse (build with ant)


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
8



3.3

Error handling

3.3.1

GSN errors

On the beginning of our project, there are sensors which collect data from the real world. They could
produce
numerous errors from the application written in Java, which are already shown automatically to server
administrator. Since this application should be taken for granted, we won’t do much on this particular field of
error handling.

Main point of conc
ern will be errors that could be produced from our changes on the code that we write in the
process. These errors should be taken on minimum since every error on the down
-
level system as this one, will
produce a set of errors on the upper
-
level components.

Since these prolongations should be avoided, we intend
to make a backup for each action we make. For instance, when making a notification subscription file, we will
save 2 copies on the system, so that if something goes wrong, we can always reset the syst
em, and start working
from the beginning point. This is the least we can do, and the most we will have time to produce in the process.

3.3.2

Database errors

Our database is going to be frequently filled with data from our GSN server with values measured on senso
rs.
This means we will have a lot of opportunities to make something wrong in those steps. All of this needs to be
shown to our user (administrator) so he can make decisions and actions that will make changes on the system in
respect to the error system pr
oduced.

Main point of concern is error when inserting data from the system. We are using a log file, in which all of the
errors (and some observations during script execution) are saved. Also, these errors are being sent to our
administrator on email he pr
ovided while creating cron job.

Name of the log file is made according to GSN server from which we extracted the data when error occurred.
Also, we needed to double check the problem when our error should stop the script from executing. Main
concern is to

double the data, or have data loss in the process. Because of this, our scripts should make double
check on the end of execution if everything went ok. If not, administrator will be informed with appropriate
message, and script should then be executed aga
in. This will also be done in time of the next periodical
execution.


3.3.3

Web interface errors

We will use se
veral methods to capture errors since
CodeIgniter
lets us

to

build error r
eporting into
this
application

using

the functions described below or by usin
g customized java script controllers:


-

ShowError ('message')
:
This function will display the error message supplied to it using the
following error template:

“application/errors/error_general.php”


-

show404('page')
This function will display the 404 error m
essage supplied to it using the
following error template: “application/errors/error404.php”


-

log_message ('level',

'message')
:

this

will show customizable messages with respect to
the given error action table.


-

In addition, it has an error logging class th
at permits error and debugging messages to be saved as text
files.


There are three message types (error, debug, info):

1.

Error Messages. These are actual errors, such as PHP errors or user errors.

2.

Debug Messages. These are messages that assist in debugging.

For example, if a class has been
initialized, you could log this as debugging info.

3.

Informational Messages. These are the lowest priority messages, simply giving information regarding
some process.

ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
9



With respect to
J
ava
S
cript controllers, it was implemente
d a framework from Dreamweaver called spry that uses
spry widgets to combine AJAX controllers, HTML, CSS and JavaScript elements to enable user interaction and
validation errors
. This assist developers to implement standards and error handling with respect

to: Invalid
format value, Invalid password, required field and other errors that especified in following table:


Error

Action

P
age doesn’t exist

卨ow 4M4 敲ror p慧e

r
s敲nam攠or p慳aword 楳 in捯rr散t

䵥ssag攺e楮捯rr散琠ts敲nam攠or p慳aword

r
s敲 name 慬a
敡dy ex楳瑳 楮 瑨攠d慴慢慳攬 when
慤d楮g 瑨攠us敲

䵥ssag攺eus敲 慬a敡dy exis瑳

䙡楬敤 捯nn散瑩tn 瑯 d慴慢慳a

A汥l琠us敲 慮d 慤m楮is瑲慴ar

m䡐 s捲楰瑩tg 敲ror

A汥l琠us敲 慮d 慤m楮is瑲慴ar

䙩敬c no琠ti汬敤

Message: “name of the field” can’t be empty.

fnv
慬楤 em慩氠慤dr敳e

䵥ssag攺eema楬⁡ddr敳e 楳 no琠v慬楤

fnv慬楤 phon攠numb敲

䵥ssag攺ephon攠numb敲 楳 no琠t慬楤

Sensor doesn’t give any information

A汥l琠tdm楮楳瑲慴ar

啳敲 no琠tubs捲楢敤 瑯 no瑩t楣i瑩tns

䵥ssag攺eus敲 mus琠subs捲楢攠愠no瑩t楣i瑩tn

fnva
汩l d慴攠form慴

䵥ssag攺efnv慬楤 d慴攠form慴a

o敱u楲敤 f楥汤

䵥ssag攺eTh楳 楮forma瑩tn 楳 r敱u楲敤K

o敱u楲敤 s敬散瑩tn

䵥ssag攺eyou mus琠獥汥t琠tn op瑩tnK


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
10



4.

Detailed software design

4.1

Deployment Diagram:

Deployment diagram describes how our software is de
ployed in mentioned hardware. (See picture 4.1)


1.

Any explorer (chrome) can be installed in the client computer. The explorer communicates with apache
web server using HTTP protocol. We will this as web application.

2.

The apache server will directly communica
te with database server, GSN using TCP/IP protocols.

3.

Database is communicated by apache and ETL process using TCP/IP protocol.

4.

ETL process and GSN are located in Data Manager.


Picture 4.1


4.2

Component Diagram


This component diagram describes various softw
are components involved in the system. This system contains
four components. PC will send request to this web application through user helper. The web application contains
the HTTP modules and PHP modules. The web application communicates with database us
ing query helper.
Also web application has the ability to communicate with GSN server directly using
DataparserHelper
. GSN
server and ETL server work together for storing the sensor information in database. The modules that help for
this communication are
getdatatotransform

and
getupdate
. (See diagram 4.2)

ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
11




Picture 4.2


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
12



4.3

Sequence Diagrams

A set of sequence diagrams have been designed with respect to general Use cases described in following table
that states use case ID, use case description (this represent

a fingerprint textual representation about sequence
diagrams and state machines) from requirement document and sequence diagram or state machine name:

Use case
ID(UID)

Use case Title

Sequence Diagram/State machine
name

Picture ID

1

Manage sensors

Manage
sensor Sequence
Diagram

4.3.1

2

Manage profiles

manage profiles sequence
diagram

4.3.2

3

Authentication

It is stated in all sequence
diagrams and state machines

NA

4

Notifications

Notification Sequence Diagram

4.3.4

5

Generate Report

Generate Report Se
quence
Diagram

4.3.5

6

Display information

Display Information Sequence
Diagram

4.3.6

7

Manage sensors data

It is similar to
Manage sensor
Sequence Diagram

NA

8

Temperature
prediction

Temperature Prediction
Sequence Diagram

4.3.8

9

Send notifications

S
end a Notification State Machine

4.3.9


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
13




Picture

4.3
.
1



ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
14




Picture
4.3
.
2

ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
15




Picture
4.3
.4


ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
16




Picture
4.3
.5
















ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
17




Picture
4.3
.6
















ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
18




Picture
4.3
.
8














ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
19




Picture
4.3
.
9



ColdWatch


Version:
1.4

Design Description


Date: 2011
-
12
-
06





Page
20



4.4

Class Diagram









ColdWatch


Version:
1.0

Design Description


Date:

2011
-
10
-
24





Page
21



4.6

Database design

ColdWatch


Version:
1.5

Design Description


Date: 2011
-
12
-
08





Page
22



5.

Approvals



Name

Title

Date

yyyy
-
mm
-
dd

Signature

Mario Žagar

Customer

2011
-
30
-
10