Docstoc

hss-rad

Document Sample
hss-rad Powered By Docstoc
					Team Members :

Adem DELIBAS               ademdelibas@st.fatih.edu.tr
Ahmet Volkan GUREL         avgurel@st.fatih.edu.tr
Ayse Betul GULBAGCI        abgulbagci@st.fatih.edu.tr
Melek OKTAY                melekoktay@st.fatih.edu.tr


                 Requirement Analysis Document
                             2003
TABLE OFCONTENTS
1. INTRODUCTION ................................................................................................................ 4

     1.1       PURPOSE OF THE HSS ............................................................................................... 4
     1.2       SCOPE OF THE HSS ................................................................................................... 5
     1.3       OBJECTİVES AND SUCCESS CRİTERİA OF THE HSS ..................................................... 5
     1.4       DEFINITIONS, ACRONYMS AND ABBREVIATIONS ........................................................... 5
     1.5 REFERENCES .................................................................................................................. 6
     1.6 OVERVIEW ...................................................................................................................... 7

2.      CURRENT SYSTEM ...................................................................................................... 8

3.      PROPOSED SYSTEM.................................................................................................... 9

     3.1       SYSTEM OVERVIEW.................................................................................................... 9
     3.2 FUNCTIONAL REQUIREMENTS ........................................................................................ 10
        3.3 Non- Functional Requirements 3.3.1 User Interface and Human Factors ...... 11
        3.3.2 Documentation .................................................................................................. 11
        3.3.3 Hardware Consideration ................................................................................... 11
        3.3.4 Performance Characteristics............................................................................ 12
        3.3.5 System Interfacing ............................................................................................. 12
        3.3.6 Quality Issues..................................................................................................... 12
        3.3.7 System Modifications ........................................................................................ 12
        3.3.8 Physical Environment ....................................................................................... 12
        3.3.9 Security Issues................................................................................................... 13
     3.4 PSEUDO REQUIREMENTS ............................................................................................... 13
     3.5 SYSTEM MODELS .......................................................................................................... 14
        3.5.1 Actors .................................................................................................................. 14
        3.5.2 Events ................................................................................................................. 14
        3.5.4 Use-Case Model ................................................................................................. 18
           3.5.4.1 HSS Use-Case Diagram .......................................................................... 18
           3.5.4.2 Use-Case Definitions .............................................................................. 19
               3.5.4.2.1 The “Create User” Use-Case ........................................................... 19
               3.5.4.2.2 The “Remote Management” Use-Case ........................................... 20


                                                                                                                                             2
           3.5.4.2.3 The “Calling” Use-Case ................................................................... 21
           3.5.4.2.4 The “Maintain Sensor Status” Use-Case ........................................ 22
           3.5.4.2.5 The “Record Camera View” Use-Case ............................................ 23

3.5.4.2.6 THE “CAPTURE CAMERA VIEW” USE-CASE .................................................. 23

        3.5.4.3 Happy Paths(Most Common Scenarios) Task Steps ........................... 24
           3.5.4.3.1 The “Change Camera View” Happy-Path ....................................... 25
           3.5.4.3.2 The “Remote-Management” Happy-Path ........................................ 25

3.5.4.3.3 THE “CALLING” HAPPY-PATH.......................................................................... 25

           3.5.4.3.4 The “Maintain Sensor Status” Happy-Path .................................... 26
           3.5.4.3.5 The “Record Camera View” Happy-Path ........................................ 26
     3.5.5 Object Models .................................................................................................... 27
        3.5.5.1. Class Diagram ........................................................................................ 27
     3.5.6 Dynamic Models ................................................................................................ 28
        3.5.6.1 Sequence Diagrams ................................................................................ 28
     3.5.7 User Interface ..................................................................................................... 30
       3.5.7.1 Web Interface ........................................................................................... 30




                                                                                                                                     3
1. INTRODUCTION

        1.1 Purpose of the HSS

        In 2001, there were 383,500 home fires in the United States, resulting in 3,110 deaths, 15,200
injuries, and $5.5 billion in direct property damage1. Also, there are an estimated 2,329,950 annual
burglaries, with an annual loss by victims of approximately $3.1 billion2. Homes without security
systems are 2.7 times more likely to be targeted by a burglar and 60% of residential burglaries occur
during the daylight3.
        The Home Security System, HSS, is intended to provide a full security for houses when
house owners are either home or away. We developed a system that monitors the house with sensors
and informs the house owners and fire department when it detects a fire with gas (smoke) sensor,
house owners and police department when it detects a thief with PIR sensors. The HSS also provides
users to view their home or office from web when they are away, and ability to access and direct the
system from mobile phone via Wireless Application Protocol, WAP. Moreover, in theft case the
system records the current camera view to its database to help police to identify the thief or the
thieves.
        The HSS, consists of four different types of sensors which are gas/smoke, aqua, PIR,
temperature; some cameras; a GPRS modem; a PC on which the main software that operates on data
acquired from sensors runs. Gas/smoke sensor invokes the main software when it detects a smoke in
room. As soon as this occurs, the system sends SMS to house owners and tells about the smoke
detected at home it also calls the Fire Department. Aqua sensor causes the same action to be taken
when it detects water flood in room. PIR sensors are placed to windows and doors, these Passive
Infra-Red - PIR sensors alert the software on PC when windows and doors on which those sensors
are placed are opened. Cameras, placed to desired rooms by the user, connected to the PC that is also
a web server and transmits the views of those cameras continuously to web. GPRS modem is also
connected to PC. It is used by the software on PC to send SMS to users, and to call Police and Fire
Departments.




1
  “2001 Catastrophic Fires”, NFPA journal, September/October 2002
2
  FBI Uniform Crime Reprots
3
  “Securing Home and Business” by Simon Hakiim and Ervin Blackstone


                                                                                                    4
       The HSS runs in two different modes: “home” and “away”. In away mode, signals produced
by all sensors in the system cause the corresponding actions to be taken. However, in home mode
some of those actions are not taken. The HSS enables users to configure home mode according to
their desires. The mode of the system can be changed by the users from web or wap via their wap-
enabled mobile phones.
       As a result, by adding a number of sensors, a number of cameras, and a GPRS modem to a
PC we turned it to a low-priced full security system for homes and offices and we called it the HSS
which is supported by web, WAP, and some GSM properties like SMS.


       1.2 Scope of the HSS
       In HSS, there are two user types: user and superuser. For each home, there is only one
superuser. A superuser has all the rights; that are:
       -changing system mode
       -changing the room that is watched
       -being sent SMS
       Moreover superuser is able to create new users and reconfigure home mode. Other users are
assigned rights by the superuser.


       1.3 Objectives and Success Criteria of the HSS
        HSS is a real time system designed mainly to protect homes and offices against fire and theft
when the house owners are away, so the primary objective behind HSS is security. However, it also
provides some supplementary services to households when they are either home or away. Reliability
and careful design of the system are the most important design criteria of HSS.


       1.4 Definitions, Acronyms and Abbreviations
       CSIDC: Computer Society International Design Competition
       GPRS: General Packet Radio Service
       GSM: Global System for Mobile communication, Group Special Mobile
       GUI: Graphical User Interface
       HSS: Home Security System
       JMF: Java Media Framework



                                                                                                      5
          JSP: Java Server Pages
          PC: Personal Computer
          PIR: Passive Infra-Red Sensor
          RAD: Requirement Analysis Document
          RUP: Rational Unified Process
          SMS: Small Message Service
          UML: Unified Modeling Language
          WML: Wireless Mark-up Language
          WAP: Wireless Application Protocol
          XP: Extreme Programming


          1.5 References
Literature References
[1] Application Development with Java and UML - Paul Reeds
[2] Advanced Java 2 Platform –How to Program- Deitel, Deitel, Santry
[3] Oracle the Complete Reference- George Koch, Kevin Loney
[4] Introduction to Algorithms – Thomas Cormen, Charles Leiserson, Ronald Rivest, Clifford Stein
[5] Object- Oriented Software Engineering- Bernd Bruegge, Allen Dutoit
[6] Distributed Systems: Principles and Paradigms- Maarten Van Steen, Andrew S. Tanenbaum
[7] "Computer Networks, 3rd edition" - Andrew S. Tanenbaum
[8] Wireless Communications for Intelligent Transportation Systems , Daniel J. Dailey, Scott D.
Elliott
[9] Multi-Sensor Fusion: Fundamentals and Applications with Software, Richard R. Brooks,
[10] Special Edition Using Java Server Pages and Servlets , Mark Wutka.


Internet References
[1] http://ww.wapforum.com/
[2] http://wireless.java.com/
[3] http://www.gumuskaya.com/
[4] http://msdn.microsoft.com/
[5] http://java.sun.com/



                                                                                                  6
[6] http://www.sensorproject.com/
[7] http://jakarta.apache.org/
[8] http://java.sun.com/products/java-media/jmf/




       1.6 Overview
       The HSS is a security system for homes and offices, and it is developed to make offices
and,especially, homes much more secure. Although there are existing security systems for homes,
the HSS differs from them in many ways.
       First, it combines different security techniques, such as sensors and cameras. Then, it makes
it very easy to access and direct the system with web and WAP interfaces. Accessibility from mobile
devices makes the HSS is really different from existing security systems.
       The HSS has lots of beneficial effects on society. Its social impact will be very important,
because people far away from their home need not to be worried about it. People will be able to
watch their home and give commands to the HSS by mobile devices. In the time of emergency they
will be warned by the system by SMS and at that time the necessary process (calling police, fire
brigade etc.) will be done by HSS. It is also very important for the police stations because the system
will help them to determine the identity of the thief by using the database that the views are
recorded.
       The HSS is a low-cost security system, and it is really easy to make a home secure with the
HSS. What you need to make your home secure with HSS is only four different types of
sensors(smoke, aqua, PIR and temperature), a camera and a PC.




       The system we have developed is an experimental platform; we have successfully
implemented and tested all the main functions that our system was intended to meet. In its
commercial release, the system may lead to great achievements in home and office security and
prevention of different dangerous situations such as fire and theft.
       In further release of the HSS, the system can be extended to transmit camera view of home to
the users via their mobile phones and other mobile devices like PDA.




                                                                                                      7
   2. CURRENT SYSTEM
   There are many systems designed to provide security for homes and offices. Some of them let
customers watch their home on web; others detect fire and inform the customers by alarm signal or
dialing.
   Although there are such systems, none of them provides complete security system solution.
We develop a system that ensures a complete security and accessible from anywhere and anytime.




                                                                                                    8
   3. PROPOSED SYSTEM
   3.1 System Overview
   The Home Security System, HSS, is a real time system designed mainly to protect homes and
offices against fire and theft when the house owners are away. However, it also provides some
supplementary services to house owners when they are either home or away.
   The system consists of a gas/smoke sensor, an aqua sensor, a temperature sensor, a
microcontroler module, a number of cameras, a GPRS modem and a PC. Sensors are wired to the
microconroller module, and this module is connected to PC via its serial port. These sensors cause
corresponding actions to be taken by the main software on PC. For example, when smoke sensor
detects smoke in room, the software sends SMS to house owners to inform them, and call the fire
department. The cameras placed to rooms by the users, are connected to PC from USB port. The
software transmits the views of those cameras to contionusly web. GPRS modem, used by the
software to send SMS to users and call police and fire departments, is connected to the PC via its
serial port(COM1). In HSS, the dedicated PC is the main part of the system. The microcontroller to
which sensors are wired, cameras and GPRS modem are connected to this PC. Also the software that
retrieves data from sensors, sends SMS to users, calls Police and Fire Departments, transmits camera
views to web, updates system information on web and wap runs on this PC. Figure 3.1.1 shows the
components and structure of Home Security System.
   The system can also be accessed and directed by user from his wap-enabled mobile phone. This
feature provides mobility to HSS.




                                                                                                  9
                                 Figure 3.1.1 Structure of HSS


3.2 Functional Requirements
The HSS provides various functionalities for users to make their home secure such as:
 -Detect fire in home,
 -Detect thief in room,
 -Detect water flood in home,
 -Inform the users by SMS about the fire or smoke in their home,
 -Inform the users by SMS about the open doors and windows in their home (which possibly
means there is someone not desired in home),
 -Dial the Police Department when it detects someone suspected in home,
 -Dial the Fire Department when it detects fire in home
Although all this services are desired when the household is away, some of them may not be
wanted when the house owners are home. For example, when they are home, they will, not
surprisingly, open doors and windows. Receiving an SMS whenever household opens any door
or window possibly will be disturbing. By considering this situation, we defined two different
modes in which the HSS works: home and away.




                                                                                             10
      3.3 Non- Functional Requirements
      3.3.1 User Interface and Human Factors
    The HSS comes with easy to use user interfaces to enable the users to access and direct the
system. We developed two types of interfaces: a web interface to access the system with TCP/IP
connection using a browser, a wap interface to access the system with a mobile phone using
Wireless Application Protocol-WAP.
        Web interface lets users
              -Watch the camera views
              -Switch to different views
              -See the status of sensors (whether they are detecting at current time)
              -See the temperature of the room
              -Change the system mode
              -Create new users only if logged in user is “superuser”.




        The HSS provides users to access and direct the system from wap-enabled mobile phone.
With WAP interface the user is able to change the system mode and get information about sensor
current status.




        3.3.2 Documentation
        A HSS tutorial will be avaible for the users in the web site. Also user will be able to use the
“help” from WAP and web. The documents that are required in RUP will be prepared.




        3.3.3 Hardware Consideration
        The server should be always on and it will serve as a web and wap server. The server should
run Apache on a Windows NT based operating system, so that JSP applications can be executed.
Oracle9 will be used as DBMS. JMF should be installed on the server and client machines (the PCs
that camera view will be transmitted). A GPRS modem will be used to send SMS to users. A camera
and a sensor module(a microcontroller card that sensors will be wired) are also needed.




                                                                                                      11
       3.3.4 Performance Characteristics
       In emergency occasions, users must be alerted as fast as possible so the programs that will
send SMS to users must run fast. To transmit camera view, Java Media Framework must be
installed on both server and client machines. The server PC is always on and connected to internet.
Also, the capacity of the database must be enough to hold the recorded views.




       3.3.5 System Interfacing
       There will be bean interfaces between web classes and database.




       3.3.6 Quality Issues
       The most important dimension of quality that concerns HSS is reliability. The system should
be kept online as long as possible, without any interruptions. System will be designed modular to
enable user to add new cameras and sensors to system. The superuser can create new users.




       3.3.7 System Modifications
       The HSS lets users increase the number of sensors and cameras. System can be modified to
transmit camera view over wap. As new advances in technology occur, the server may be upgraded,
especially in terms of the CPU and the primary memory. A sensor module can be designed for each
sensor. Data can be accused from those modules by bluetooth.




       3.3.8 Physical Environment
       There will be no need for huge locations to store the system. Server with camera, sensor and
modem will be located at home.




                                                                                                    12
       3.3.9 Security Issues
       Since HSS is a security system, its own must also be secure. Password of the users must be
encrypted before recorded to database.


       3.4 Pseudo Requirements
       In HSS we defined to different modes in which the system works. We might not consider the
home mode, but it would not be suitable for real situtaions because the need for the services
provided by HSS is different when household is home and when the household is away. For that
reason, we introduce a different mode called home that is configurable by the users.
       Although we have only four sensors, we will use a PICNet 8 Port Sensor Module as a
intermediate module between PC and sensors to make it possible to add new sensors to the system.
       The HSS has two different user interfaces: web interface and wap interface. Maybe, it would
be enough to have only web interface to access and direct the system. However, we will develop also
a wap interface to make the system accessible from anywhere and anytime.
       We used SIEMENS M20 GPRS modem to dial and send SMS to the users. It is also possible
to use a mobile phone with an RS-232 cable, we use this modem since it is faster.
To inform the users, we used SMS instead of dialing, because SMS is much more reliable. Because
the user may not be reached by dialing anytime but SMS is never lost.
       The HSS is designed to meet all the needs of a home to be secure. In security systems, speed
of data transer and reliability is much more important than cost. Therefore, we prefer more costly
but much more reliable tools in system design.
       Calling Unit is a software tool will be developed to send SMS to users and dial Police and
Fire Departments. This unit will be implemented in Java.
       Sensor detection unit is also a software tool will be developed to detect which sensors start
working. This unit will also be implemented is Java.
       Web Interface will be developed to provide users access the system via TCP connection. This
interface will be developed by Java Server Pages, JSP.




                                                                                                       13
3.5 System Models
3.5.1 Actors
   Actor                                 Definition
   Superuser                             Changing the system mode
                                         Creating new users
                                         Assigning permission to users
                                         Deciding camera to be watched

   User                                  Changing the system mode
                                         Deciding camera to be watched

   Water sensor                          Invoking the system in water flood occasion

   PIR                                   Invoking the system in thief occasion

   Gas sensor                            Invoking the system in fire occasion

   Temperature sensor                    Sending the temperature to the system


                Table 1- Proposed actors for Home Security System-HSS Project

3.5.2 Events
Event List:
Users login to the system
User changes the system mode
Superuser creates new users
Superusers assigns permissions
User decides the camera view seen from web
Water sensor calls the fire department
Water sensor updates water sensor status
Water sensor sends SMS to the users
PIR sensor calls the police
PIR sensor updates PIR sensor status
PIR sensor records the view to the database
PIR sensors sends SMS to the users
Gas sensor calls the fire department
Gas sensor updates gas sensor status
Gas sensor sends SMS to the users


                                                                                       14
          System transmits the camera view to web
          Temperature sensor updates temperature sensor status


Event Table:
Subject       Verb         Object           Use-Case          Arrival      Response
                                                              Pattern
Superuser     Creates      New users        Create User       Episodic     New users are created and
                                                                           recorded to db.
Superuser     Grants       New users        Create User       Episodic     New users are granted permission.
              Permission
User          Changes      System           Remote            Episodic     System    mode     is  changed:
                           mode             Management                     home/away.
User          Changes      Camera           Remote            Episodic     Camera view is changed
                           View             Management
Water         Calls        Fire Dept.       Calling           Episodic     The fire department is called by the
Sensor                                                                     HSS.
Water         Updates      Water            Maintain          Episodic     Water sensors are updated.
Sensor                     Sensor           Sensor
                           Status           Status
Water         Sends        SMS              Calling           Episodic     HSS sends SMS to the users to
Sensor                                                                     inform them about their home
                                                                           status.
Gas           Calls        Fire dept.       Calling           Episodic     The fire dept is called.
Sensor
Gas           Updates      Gas              Maintain          Episodic     Gas sensor status is updated on
Sensor                     Sensor           Sensor                         web.
                           Status           Status
Gas           Sends        SMS              Calling           Episodic     HSS sends SMS to the users to
Sensor                                                                     inform them about their home
                                                                           status.
PIR           Calls        Police           Calling           Episodic     The Police dept is called.
Sensor                     dept.
PIR           Updates      PIR              Maintain          Episodic     PIR Sensors Status is updated.
Sensor                     Sensor           Sensor
                           Status           Status
PIR           Records      Camera           Record            Episodic     Camera view is recorded to the db.
Sensor                     View             Camera View
PIR           Sends        SMS              Calling           Episodic     HSS sends SMS to the users to
Sensor                                                                     inform them about their home
                                                                           status.
Temperatu     Updates      Temperatu        Maintain          Episodic     Temperature Sensors Status is
re Sensor                  re Sensors       Sensor                         updated.
                           Status           Status
System        Transmits    Camera           Capture           Episodic     Selected camera view is transmitted
                           view             Camera View                    to web continuously.
User          Login        System           Remote            Episodic     Users login to the HSS by their
                                            Management                     username and password
User          Watches      Camera           Remote            Episodic     User watches the view from the
                           View             Management                     web

                                        Table 2 – Event table for HSS project




                                                                                                                  15
3.5.3 Scenarios


Scenario name                   createUser

Participating Actor Instances   mehmet : Superuser

Flow Of Events                  1- Mehmet login.
                                2- Mehmet clicks on the “create new user ” link.
                                3- Mehmet assigns a username to the new user.
                                4- Mehmet assigns a password to the new user.
                                5- Mehmet can grant mode changing right to the new user.
                                6- Mehmet can grant camera view changing right to the new user.
                                7- Mehmet can grant being informed by SMS right to the new
                                user.
                                8- Mehmet records the GSM number of new user to the system.
                   Table 3 - createUser scenario for the CreateUser use-case.


Scenario name                   changeCameraView

Participating Actor Instances   okkesh : User

Flow Of Events                  1- The okkesh login
                                2- The okkesh selects a different view from list.
                                3- The new camera view begin to be transmitted to the web.
          Table 4 - changeCameraView scenario for the ChangeCameraView use-case.


Scenario name                   remoteManagement

Participating Actor Instances   pir : PassiveInfraRedSensor
                                aqua : AquaSensor
                                smoke : SmokeSensor
Flow Of Events                  1- The pir, aqua or smoke works.
                                2- System determines which sensor works.
          Table 5 - remoteManagement scenario for the RemoteManagement use-case.




                                                                                              16
Scenario name                   calling

Participating Actor Instances   pir : PassiveInfraRedSensor
                                aqua : AquaSensor
                                smoke : SmokeSensor
Flow Of Events                  1- The pir, aqua or smoke works.
                                2- System determines which sensor works.
                                3- System sends SMS to the users and informs the user in the
                                emergency occasion.
                                4- System calls Fire Dept. Or Police Dept.
                       Table 6 - calling scenario for the Calling use-case.




Scenario name                   maintainSensorStatus

Participating Actor Instances   pir : PassiveInfraRedSensor
                                aqua : AquaSensor
                                smoke : SmokeSensor
Flow Of Events                  1- Pir, Aqua and Smoke sends their status info to system.
                                2- System updates WAP by new status info of Pir, Aqua and
                                Smoke
                                3- System updates WEB by new status info of Pir, Aqua and
                                Smoke
       Table 7 - maintainSensorStatus scenario for the MaintainSensorStatus use-case.




                                                                                               17
3.5.4 Use-Case Model
3.5.4.1 HSS Use-Case Diagram




                   Figure 3.5.4.1.1 – HSS Use-Case Diagram




                                                             18
         3.5.4.2 Use-Case Definitions

         3.5.4.2.1 The “Create User” Use-Case
Name: Create user


Description:
         This use-case starts when the superuser decides to create a new user and logs in the system
         grants access rights to them.It ends when the new user is created.


Precondition:
         Superuser decides to create a new user


Postcondition:
         A subuser is created and access righs are given to him by superuser


Trigger Events:
         Superuser creates new users
         Superuser assigns permissions


Actor:
         Superuser


The Most Common Scenario:
         The superuser decides to create a new user and then gives a username, password and grants
         permission to the new user


Alternate Scenarios:
         None


Exceptional Scenario:
         The superuser try to create a new user with an already existing username.




                                                                                                       19
3.5.4.2.2 The “Remote Management” Use-Case
Name: The Remote Management


Description:
         This use-case starts when the user connects the system.The camera view and the system
         mode is changed.It ends when the user logs out the system.


Precondition:
         The user connects the system.


Postcondition:
         A different camera view is captured
         With the changing the system mode, some of the sensors start/stop working
Trigger Events:
         Users logs in the system,
         User changes the system mode,
         User decides the camera view seen from web


Actor:
         User


The Most Common Scenario:
         User changes the camera view


Alternate Scenarios
         User changes the system mode to home
         User changes the system mode to away


Exceptional Scenarios:
         User tries to login with a wrong username or password




                                                                                                 20
3.5.4.2.3 The “Calling” Use-Case

Name: The Calling
Description:
      This use-case starts when one of the sensors works. The system calls the Fire Dept., User,
      Police Dept. This ends when calling process ends.


Precondition:
      The sensor starts to work.
Postcondition:
      An SMS is sent to the user.
       The fire dept. or police dept.is called by the system.
Trigger Events:
      Water sensor calls the fire department
      Water sensor sends SMS to the users
      PIR sensor calls the police
      PIR sensors sends SMS to the users
      Gas sensor calls the fire department
      Gas sensor sends SMS to the users
Actors:
      Water sensor
       PIR
      Gas sensor
The Most Common Scenario:
          One of the PIR, water and gas sensor sends SMS to user
Alternate Scenarios:
      Water sensor works and system calls the fire department
      PIR sensor works and the system calls the police
      Gas sensor works and the system calls the fire department




                                                                                                   21
Exceptional Scenarios:
      User’s celular phone can be off
      Police dept. can not be reached
      Fire dept. Can not be reached


3.5.4.2.4 The “Maintain Sensor Status” Use-Case

Name: Maintain Sensor Status


Description:
      This use-case starts when one of the sensors works. The system updates the working status
      and use case ends.
Precondition:
      The sensor starts to work.
Postcondition:
      Status of the sensor is updated on web for informing the users
Trigger Events:
      Water sensor updates water sensor status
      PIR sensor updates PIR sensor status
      Gas sensor updates gas sensor status
      Temperature sensor updates the value of temperature on web
Actors:
      Water sensor
          PIR
      Gas sensor
      Temperature sensor
The Most Common Scenario:
          The value of tempreture is updated on web.




                                                                                                  22
Alternate Scenarios:
      PIR sensor status is updated
      Water sensor status is updated
      Gas sensor status is updated
Exceptional Scenarios:
      None


3.5.4.2.5 The “Record Camera View” Use-Case
Name: The Record Camera View
Description:
      This use-case starts when PIR sensor works. This ends when view recorded to the database.
Author:
Precondition:
      The PIR sensor starts to work.
Postcondition:
      Current view of the camera is recorded to the database.
Trigger Events:
      PIR sensor records the view to the database
Actors:
          PIR
The Most Common Scenario:
          The view is recorded to the database.
Alternate Scenarios:
      None
Exceptional Scenarios:
      System can not connect to the database

3.5.4.2.6 The “Capture Camera View” Use-Case

Name: Capture Camera View
Description:
      This use-case starts and never ends.


                                                                                              23
Author:
Precondition:
       The system starts working.
Postcondition:
       View of the camera is captured and transmitted to the web.
Trigger Events:
       System transmits the camera view to web
Actors:
The Most Common Scenario:
          The view is recorded to the database.



3.5.4.3 Most Common Scenarios Task Steps

3.5.4.3.1 The “Create User” Scenario


“The superuser decides to create a new user and then gives a username, password and grants
permission to the new user”


1- The superuser login.
2- The superuser clicks on the “create new user ” link.
3- The superuser assigns a username to the new user.
4- The superuser assigns a password to the new user.
5- The superuser can grant mode changing right to the new user.
6- The superuser can grant camera view changing right to the new user.
7- The superuser can grant being informed by SMS right to the new user.
8- The superuser records the GSM number of new user to the system.




                                                                                         24
3.5.4.3.2 The “Change Camera View” Happy-Path

“User changes the camera view”
   1- The user login
   2- The user selects a different view from list.
   3- The new camera view begin to be transmitted to the web.




3.5.4.3.3 The “Remote-Management” Happy-Path

“One of the PIR, water and gas sensor sends SMS to user”


  1-The PIR, water or gas sensor works.
  2-System determines which sensor works.
  3-System sends SMS to the users and informs the user in the emergency occasion.




3.5.4.3.4 The “Calling” Happy-Path

“One of the PIR, water and gas sensor sends SMS to user”

  1-The PIR, water or gas sensor works.
  2-System determines which sensor works.
  3-System sends SMS to the users and informs the user in the emergency occasion.




                                                                                    25
3.5.4.3.5 The “Maintain Sensor Status” Happy-Path

“The value of tempreture is updated on web.”

 1- Temperature of the room changes.
 2- Temperature sensor informs the system about the new temperature.
 3- The value of temperature on web is updated.



3.5.4.3.6 The “Record Camera View” Happy-Path

“The view is recorded to the database.”

 1-PIR sensor works.
 2-The camera view is recorded to the database.




                                                                       26
3.5.5 Object Models
3.5.5.1. Class Diagram




                         Figure 3.5.5.1.1 HSS Class Diagrams




                                                               27
3.5.6 Dynamic Models
3.5.6.1 Sequence Diagrams




                       Figure 3.5.6.1 Sequence diagram of creating user




                                                                          28
                          User                      CameraView                 CaptureView




 1: val idate
                                 1.1: switchVi ew
                                                           1.1.1: cap ture




                      Pathway : User changes the camera view



     Figure 3.5.6.2 Sequence diagram of switching camera view




                          User                                               SystemMode




      1: val idate
                                 1.1: setModeToAway
                               {:SystemMode.mode .getMo deName != "Away'}




                Pathway : User changes the system mode to home



Figure 3.5.6.3 Sequence diagram of setting system mode to “away”.



                                                                                             29
                                          User                                         SystemMode




                        1: val idate
                                                 1.1: setModeToHome
                                                 {:SystemMode.mode .getMo deName != "Ho me"}




                             Pathway : User changes the system mode to home



                          3.5.6.4 Sequence diagram of setting system mode to “home”


       3.5.7 User Interface
       The HSS comes with easy to use user interfaces to enable the users to access and direct the
system. We developed two types of interfaces: a web interface to access the system with TCP/IP
connection using a browser, a wap interface to access the system with a mobile phone using
Wireless Application Protocol-WAP


       3.5.7.1 Web Interface
       The HSS provides users to access and direct the system from web. Users can connect internet
and watch the condition of their home whenever they want. We use Java Server Pages, JSP and
Servlets to develop this interface. Figure 3.5.6.1.1 shows this web interface after superuser logged in
system.




                                                                                                     30
                               Figure 3.5.7.1.1 HSS Web Interface after superuser logged in

       Superuser is able to create new users and reconfigure home mode (Figure 3.5.7.1.2). To
create a new user, he gives a new username and password to system for each user and assigns rights
that he wants them to have (Figure 3.5.7.1.3).




                                                                                                31
                               Figure 3.5.7.1.2 Reconfigure Home Mode

Web interface lets users


       -Watch the camera views
       -Switch to different views
       -See the status of sensors (whether they are detecting at current time)
       -See the temperature of the room
       -Change the system mode
       -Create new users only if logged in user is “superuser”.




                                                                                 32
                                            Figure 3.5.7.1.3 Create New User




         3.5.6.2 WAP Interface

         The HSS provides users to access and direct the system from wap-enabled mobile phone.
This part, explains about the wap interface between user and the system. To develop this interface
we used Openwave SDK 6.2.
With this WAP interface the user is able to change the system mode and get information about
sensor current status. To achieve those activities:
         -The user connects to wap server of the HSS (Figure 3.5.7.2.1)
         -The user logs in to system with his username and password (Figure 3.5.7.2.2)
         To get information about current status of the sensors in the system, the user selects Sensor
Info from main menu (Figure 3.5.6.2.3), then current status of sensor shown on phone screen by the
system


                                                                                                   33
          Figure 3.5.7.2.1 Connect HSS WAP Server     Figure 3.5.7.2.2 Login to HSS WAP Server



       (Figure 3.5.7.2.4).In this figure, we see gas and aqua sensors are not detecting, so there is no
such problem in home. However, windows are not OK, means somebody opened it and PIR sensor
on this window start detecting.




                                                                                                     34
Figure 3.1.7.3 Main Menu   Figure 3.1.7.3 Main Menu   Figure 3.1.7.5 Sensor Status




                                                                                     35

				
DOCUMENT INFO