BSE-Final Project Report

1. CyberGIS
ECY6489 Group Project
(Final report)
Department of Electrical & Computer Engineering
Faculty of Engineering Technology
The Open University of Sri Lanka
September 2011

2. CyberGIS
Undergraduate Final project Report
Submitted in partial fulfillment of
the requirements for the
Degree of Bachelor of Software Engineering
in
Department of Electrical & Computer Engineering
The Open University of Sri Lanka
Supervisors Project Group
Dr. L.S.K Udugama M.S.R Perera<209087374>
Dr. Uditha Ratnayake D.S Kulasuriya<709087412>
Mr.Chaminda Anandasiri W.M.DJeewantha<509087436>
September 2011

3. Acknowledgement
We would like to thank our head of department Dr.L.S.K Udugama and our project
supervisor Dr. (Mrs.) Uditha Rathnayake for their valuable guidance & advice. Also we
would like to thank our parents for their support, encouragement and belief. We highly
appreciate the support given by our employers and project heads by providing the
industry exposure and study leaves. Finally we would like to thank all other parties for
their support at least by an encouraging word.
i

4. Abstract
The main purpose of this project was to fulfill the credit requirement of ECY6489
module under the Bachelor of Software Engineering Degree. The goal of this project was
to take the existing GIS based solution to the next level by providing more features and
make more beneficial for potential geographically distributed domains. In this CyberGIS
system we achieved this goal by introducing customizable domain maps, reporting and
analysis features, and mobile based capabilities.
ii

5. Table of Contents
CHAPTER NO. TITLE PAGE NO.
acknowledgement I
abstract II
list of tables VI
list of figures VII
list of abbreviations VIII
1. INTRODUCTION 1
2. LITERATURE SURVEY 2
2.1 Similar Systems 2
2.2 Theoretical Background 3
2.3 Required Components 3
3. PROPOSED METHOD 4
3.1 Introduction 4
3.2 System Requirements 4
3.3 Main Components and Flow 7
3.4 Project Plan and Approach 8
4. DESIGN OF SOFTWARE 11
5. FABRICATION OF SOFTWARE 23
6. TESTING AND IMPLEMENTATION 25
7. RESULTS 35
8. CONCLUSION AND FUTURE WORK 36
8.1 CyberGIS GUI Module. 36
8.2 CyberGIS Mobile Component. 37
8.3 CyberGIS Service Module. 37
9. PROJECT CONTRIBUTIONS 38
9.1 Project Contribution by: M.S.R Perera <209087374> 38
9.2 Contribution by: D.S Kulasuriya<709087412> 39
9.3 Contribution by: W.M.D.R Jeewantha<509087436> 40
REFERENCES 41
iii

6. APPENDIX 42
Appendix A – Use case Diagrams 42
Appendix A1 – CyberGIS Admin User Use Case Diagram 42
Appendix A2 – CyberGIS Operative User Use Case Diagram 43
Appendix B – Class Diagrams 44
Appendix B1 –CyberGIS Mobile Component Class Diagrams 44
Appendix B1.i GUI Package 44
Appendix B1.ii Service Package 45
Appendix B1.iii . Core Package 46
Appendix B1.iv . Constants And Param Package 47
Appendix B2 – CyberGIS Service Module Class Diagrams 48
AppendixB2.i:The RMI DTO Package 48
Appendix B2.ii Service DTO Package 49
Appendix B2.iii Business Logic Package 50
Appendix B2.iv. JPA Package 51
Appendix B2.v .Web Service Package 52
Appendix B2.vi . Utility Package 53
Appendix B3 – CyberGIS GUI Module Class Diagrams 54
Appendix B3.i . Logic Package 54
Appendix B3.ii Service Package 55
Appendix B3.iii. Param Package. 56
Appendix B3.iv . MDB package 56
Appendix B3.v . Filter Package 56
Appendix B3.vi Utility Package. 57
Appendix B3.vii . Test Package 58
Appendix C – Sequence Diagrams. 59
Appendix C1: Add Domain Map Marker 59
Appendix C2: Close Domain Map Marker 60
Appendix C3: Create Snap shot 61
Appendix C4: Generate CyberGIS Report 62
Appendix C5: Send Operative Location Update 63
Appendix C6: Send Operative Message 64
Appendix C7: View Operative Message History 65
Appendix C8: Send Operative Message Notification 65
Appendix C9: View Current Operative Location On Map 66
Appendix C10: Timeout CyberGIS Operative Message 67
Appendix C11: Add Domain User 68
Appendix C12: Login CyberGIS User 69
Appendix D – Activity Diagram 70
Appendix D1: Load Main Console 70
iv

7. Appendix D2: Display Operative location 70
Appendix D3: Add New Map Marker 71
Appendix D4: Close Map Marker 71
Appendix D5: Edit Map Marker 72
Appendix D6: Send Operative Message 72
Appendix D7: Load Main Console 73
Appendix D8: Add New User 73
Appendix E – ER Diagram 74
Appendix F –Screen Designs 75
Appendix F1: CyberGIS Main Console 75
Appendix F2: CyberGIS Login Dialog 75
Appendix F3: CyberGIS New Marker Dialog 76
Appendix F4: CyberGIS New User Dialog 76
Appendix F5: CyberGIS Map Marker Panel 77
Appendix F6 : CyberGIS Report Wizard Dialog 77
Appendix F7: CyberGIS Operative Message Dialog 78
Appendix F8: CyberGIS Operative Message History Dialog 78
Appendix F9: CyberGIS Mobile Login 79
Appendix F10: CyberGIS Mobile Main Screen 79
Appendix F11: CyberGIS Mobile Task List 80
Appendix F12: CyberGIS Mobile Task Details 80
Appendix F13: CyberGIS Mobile Task Notification 81
Appendix F14: CyberGIS Mobile Task Status Update 81
Appendix G : Test Cases 82
v

8. List of Tables
Table ID Table Description Page No.
Table 3.1 Functional Requirements 5
Table 3.2 Project Deliverables 9
Table 3.3 Actual vs. Planned 10
Table 6.1 Severity Classification 27
vi

9. List of Figures
Figure ID Figure Description Page No.
Figure 3.1 CyberGIS System 7
Figure 4.1 General Architecture 11
Figure 4.2 CyberGIS Service Module High Level Design 12
Figure 4.3 CyberGIS GUI Module High Level Design 17
Figure 4.4 CyberGIS Mobile Module High Level Design 20
Figure 6.1 Test Deliverables 26
vii

10. List of Abbreviations
Abbreviations Description
AJAX Asynchronous JavaScript And XML
API Application Programming Interface
DB Data Base
GIS Geographic Information System
GUI Graphical User Interface
IDE Integrated Development Environment
J2ME Java 2 Mobile Edition
JMS Java Messaging Services
JPA Java Persistent API
JSF Java Server Faces
mbps Mega Bits per Second
ORM Object Relational Mapping
OS Operating System
QA Quality Assurance
RMI Remote Method Invocation
SRS System Requirement Specification
UI User Interface
URL Universal Resource Locator
WTK Wireless Tool Kit
XML Extensible Markup Language
viii

11. CHAPTER 01
INTRODUCTION
The CyberGIS system is designed based on the vision “make use of existing GIS data
providers and expand that technology into new levels, that the society can make more use
of it in their domains.” So we proposed and developed a web based system that users of
this system can tag their geographically distributed domain entities on a map, customize
these entity details and, store and share them only among other required and authorized
parties within the domain.
At the time when we were proposing the CyberGIS system there were GIS Systems either
that required high GIS and mapping knowledge which bit complex (ESRI ArcGIS) or
very simple with few functionalities (Google Map). Very Complex GIS Systems avoided
the wide and general use by many potential domains as high costs, requirement of GIS
professional and less usability. On the other hand very simple GIS Systems did the same
thing by not providing authorized and secure data access, less customizability and no
reporting and analysis features.
As a solution to this problem we developed the CyberGIS system with capabilities as
mapping entities, manipulating entity data, mobile operative command, reporting and
analysis while ensuring customizability, usability, security and performance.
So we would like to believe the CyberGIS is a concept rather than a system that will
grow into higher levels that will help potential geographically distributed domain to store,
track and coordinate their distributed entities and facts. Also this concept will assist
decision making and planning by providing reporting and analysis capabilities.
1

12. CHAPTER 02
LITERATURE SURVEY
A GIS is a system that incorporates software, hardware, and data for collecting,
managing, analyzing, and portraying geographically referenced information. It allows the
user to view, understand, manipulate, and visualize data to reveal relationships and
patterns that solve problems. The user can then present the data in easily understood and
disseminated forms, such as maps, reports, or charts (http://www.gis.com/content/what-
gis, 2011).
2.1 Similar Systems
During our literature survey of similar systems we studied about Google Maps
(maps.google.com, 2010) and ESRI ArcGIS (http://www.esri.com/, 2010).
Google Maps is a web based GIS system that built on HTML and Java scripts. They use
spatial map data and satellite imagery that is provided by various authorities such as
NASA, Tele Atlas, Map Link, Europa Technologies, etc… They provide mapping data
free for web based non commercial use, but charged for commercial use. When we
compare CyberGIS system with Google maps, CyberGIS is also developed on Google
Maps API and then inherited the features of it. But in the CyberGIS we tried to overcome
the Google Maps disadvantages by providing features such as private and authenticated
data domains, map data customization, storage and manipulation of offline map data,
time series analysis and reporting of stored map data. But in the CyberGIS we have left to
implement map data search and route finding features which is drawbacks form Google
Maps (http://code.google.com/apis/maps/documentation/javascript/, 2010).
ESRI ArcGIS from the other hand is a complete desktop based GIS suite that provides
very complex functionalities. They also provide private and secure data access,
customization of domains, data analysis and reporting. But ArcGIS has its disadvantage
by been a very high rated license product and required specialized GIS professionals to
map data in to the system and design and customize the system for private domain use.
2

13. But it has advantages over the CyberGIS by having a high feature set, engineering and
architect level standards and its offline map storage (ESRI, 2002).
But the CyberGIS system introduces a new level of features by providing mobile
operative command and feedback, and real time mobile operative tracking which makes
this a unique product.
2.2 Theoretical Background
During the literature survey of the theoretical background we did look into mainly two
GIS information providers and they are:
1. Open Street Map: http://www.openstreetmap.org/
2. Google Maps: http://maps.google.com/
After reviewing the above two external GIS providers we decided to go with Google Map
V3 API due to their reliability, quality of map imagery /choices of different map image
types as : hybrid ,satellite and their array of functions provided by them Free or charge
(http://code.google.com/apis/maps/documentation/javascript/, 2010).
We studied time series analysis techniques used in Statistics for the implementation of
the CyberGIS analysis features (SPIEGEL, 1961).
2.3 Required Components
During the literature survey of the required software components of the project we‟ve
decided to choose the spring framework as our base enterprise we framework for building
our business logic on. Other than spring we will be using the Java Persistence API (JPA)
and Oracle (toplink) ORM for database access and database manipulation. For the mobile
operative end user component of the CyberGIS system we‟ve used the Java J2ME
technology. Also we used Primefaces API to use with JSF because of its easy and high
end look and feel UI component set (www.Primeface.org, 2010). Also in combination
with that we used Java managed beans to implement the CyberGIS GUI module
3

14. CHAPTER 03
PROPOSED METHOD
3.1 Introduction
The CyberGIS system is basically provides the GIS solution with extended
functionalities. The system will provide customizable web based domain maps. The
system creates domains for separate users which are working with controlled and highly
secured access to the CyberGIS web service. So a particular user can only access to their
domain and view maps for their domain. Users can manage their domains as they want
using granted access rights and customized capabilities. As any other GIS system,
CyberGIS will provide the basic map operations like Search for locations, Find location
using latitude and longitude, Zoom In and Zoom Out, Scroll the map, View location
names and tags, Show Roads and Railways. Other than to these, users can create any
tags, markers and locations as related to their business requirements. Those remarks are
only visible to those particular domain users only. Past records are kept with the system
for each user and can be retrieved as statistics in any situation. Those details are highly
secured and provide controlled access. Those statistics are available to management
decision making and planning processes of the clients.
3.2 System Requirements
System requirements for the CyberGIS system basically divided into two categories as
functional requirements and non functional requirements. More details can be found in
CyberGIS System Requirements Specification document.
4

15. Functional requirements:-
Title Description
System Customization. User of the CyberGIS system will have
private domains. So the users should be able
to customize these domains as they want by
defining data within it.
Provide Map Information. CyberGIS system should provide basic map
information as map details, marker details.
Live and Updated Information. CyberGIS system should display live data
feed by the domain users and mobile
operatives as well as updates from map data
providers.
Statistics and Historical Data Analysis. CyberGIS system should support statistical
analysis of stored data in the domain
databases.
Data Archival and Retention. Data input by the domain users as well as
mobile operatives should be stored within the
domain databases. Also transaction history
should keep in the DB.
User Profiles, Roles and Privileges. Domain user should be divided into several
access levels on their roles and privilege.
These access levels should be authenticated in
order to access to the system.
Reporting. CyberGIS system should support generation
of reports based on stored data in the domain
databases.
Mobile Operative Command CyberGIS system should be capable of
communicating with mobile operative using
CyberGIS mobile component via internet.
5

16. This includes sending messages with map
data to the operatives as well as gets
feedbacks from them.
Real-time Operative Tracking. CyberGIS system should be capable of
tracking mobile operatives using built-in GPS
devices on their mobiles.
Table 3.1 – Functional Requirements
Non Functional Requirements:-
Non functional requirements are discussed under following categories. Please refer
CyberGIS System Requirements Specification document.
 Performance and Load Requirements.
 Compatibility Requirements.
 External Interface Requirements.
 User Interfaces Requirements.
 Communications Interfaces Requirements.
 Security and Authentication requirements.
 Quality Assurance Requirements
 Development Requirements.
 Deployment Requirements
 Special Documentation Requirements
 Applicable Standards Requirements.
 Usability Requirements.
6

17. 3.3 Main Components and Flow
 The work flow of the CyberGIS system is illustrated in the following Figure 3.1.
According to that there are main two components of the system.
1. Main console.
2. Mobile Device.
 The main console will get the map data by an existing map data provider like Google
Maps. Those map data are displayed on the main console. Users can add customized
domain markers on the map by specifying marker details. Those markers represent
some domain entity or fact and marker data are saved on a database.
So users can view saved markers on the map, manipulate marker details, generate
historic trend reports and pattern analysis using stored data.
 There are registered domain operatives with the system and as they login with their
mobile devices main console users can retrieve details of those operatives on the main
map. This also allows the users to send messages to a selected operative via web with
map instructions. So operatives can view those messages and send response
feedbacks to main console that can be view by the users.
Main WEB Mobile
DB GPS Device
Console Device
User Operative
GIS Map
provider
Figure 3.1 – CyberGIS System
7

18. 3.4 Project Plan and Approach
The project approach is based on the agile methodology and MSF (Microsoft
Framework) and it allows requirement, environment and technological changes to reflect
within product releases.
CyberGIS is developed using the various tools chose by us and we consider free and open
source software and tools. These tools include Eclipse and NetBeans IDEs for
development, Tomcat server technology for deployment, MySQL for DB deployment and
various 3rd party java tools, plug-ins and web services as required. Also JAVA and JSF
with Primefaces API are used as the programming technologies. Then Google Map API
and services are used for GIS manipulation. Also SVN is used for release management
and version control. The project team consists of 3 members with initial roles but all were
working on each role as required.
Project plan consists all the project activities, schedule and deliverables of the project.
Project activities are basically encapsulated as project deliverables and delivered in
several phases. Also project plan is subdivided into several sub plans for each category.
More details on this topic can be found in CyberGIS Master Project Plan document.
 Development Plan.
 Test Plan.
 Communication plan.
 Deployment plan.
 Training plan.
 Support plan.
 Purchasing & Facilities Plan.
 Budget plan.
8

19. Code Deliverable Phase
CG1.1.1 Vision document Envision
CG1.1.2 Project structure document „‟
CG1.1.3 Milestone review report „‟
CG1.2.1 Master project plan Plan
CG1.2.2 Functional specification „‟
CG1.2.3 Deployment plan „‟
CG1.2.4 Test plan „‟
CG1.2.5 Test specification „‟
CG1.3.1 Develop internal releases Build
CG1.3.2 Traceability Audit document „‟
CG1.4.1 Functional testing Stabilize
CG1.4.2 UI stabilizing „‟
CG1.4.3 System testing „‟
CG1.4.4 Pre-production testing „‟
CG1.4.5 Release candidates „‟
CG1.4.6 User acceptance testing „‟
CG1.4.7 Testing and Bug Report „‟
CG1.5.1 Project Close-Out Report Close out
Table 3.2 – Project Deliverables
9

20. Code Deliverable Planned Actual Variance
(hr.) (hr.) (hr.)
CG1.1.1 Vision document 5 6 +1
CG1.1.2 Project structure document 15 13 -2
CG1.1.3 Milestone review report 5 6 +1
CG1.2.1 Master project plan 15 14 -1
CG1.2.2 Functional specification 120 100 -20
CG1.2.3 Deployment plan 10 8 -2
CG1.2.4 Test plan 5 4 -1
CG1.2.5 Test specification 40 44 +4
CG1.3.1 Develop internal releases 520 535 +15
CG1.3.2 Traceability Audit document 15 13 -2
CG1.4.1 Functional testing 40 43 +3
CG1.4.2 UI stabilizing 30 38 +8
CG1.4.3 System testing 40 29 -11
CG1.4.6 User acceptance testing 5 3 -2
CG1.4.7 Testing and Bug Report 20 16 -4
CG1.5.1 Project Close-Out Report 10 31 +21
Totals 895 903 +8
Table 3.3 – Actual vs. Planned
10

21. CHAPTER 04
DESIGN OF SOFTWARE
Figure 4.1 – General Architecture
Overview of the CyberGIS General Architecture
When designing the CyberGIS System we‟ve decided to choose the spring framework as
our base enterprise we framework for building our business logic on. Other than spring
we will be using the Java Persistence API (JPA) and Oracle (toplink) ORM for database
access and database manipulation. For the mobile operative end user component of the
CyberGIS system we‟ve used the Java J2ME technology. The two web modules of the
Cybergis GUI module and the CyberGIS service module will be hosted in the Apache
Tomcat server 7.0.12 and the J2ME application will be run (for the development phase)
on the sun java j2me standard development kit version 3.0. If the take the individual
components of the cybergis system they could be mainly divided into 03 major modules.
They are:
11

22. 1. CyberGIS Service Module.
2. CyberGIS GUI Module.
3. CyberGIS Mobile Component.
CyberGIS Service Module – High Level Design
Figure 4.2 – CyberGIS Service Module High Level Design.
The CyberGIS Service Module is the Heart or the Central Hub of the entire cybergis
application. It contains all the business logic classess, the JPA layer classes used to
perform database operations using the ORM framework and manages the three JMS
messages queues. The CyberGIS Service Module exposes it‟s methods to be called by
other modules by using Java RMI and SOAP based Document+Literal Style web
services.
12

23. If we take a closer look at the CyberGIS Web Service Module It Consist of several
packages and each of those packages consist of several classes. Therefore for us to be
able to explain the entire system in a simple manner we‟ve divided the class diagrams by
their packages and presented below using their class names. For detailed information of
each of the classes in the packages mentioned below please refer the appropriate
appendix mentioned beside the classes.
i. The RMI DTO Package
These are the DTO classes that are responsible for transporting data via Java RMI
between the CyberGIS GUI module and the CyberGIS Service Module. These classes are
all serializable classes that support sending data through the wire/network in distributed
applications. For a detailed inside look at these classes please refer to the diagram on
Appendix B2.i.
13

24. ii. Service DTO Package
This set of classes is the DTO classes that are used to transfer data between the CyberGIS
Service module and the CyberGIS mobile component using DOCUMENT+LITERAL
style web services. These classes are all serializable classes that support sending data
through the wire/network in distributed applications. For a detailed inside look at these
classes please refer to the diagram on Appendix B2-ii.
iii. Business Logic Package
The Classes in this package are responsible for implementing the business logic of the
CyberGIS system. The following diagrams show those classes with their respective
hierarchies. For a detailed inside look at these classes please refer to the diagram on
Appendix B2-iii.
14

25. iv. JPA Package.
These are the classes responsible for performing the database related operations using the
JPA through the toplink ORM framework. Each of the following classes represent a
single database table in the cybergis system. For a detailed inside look at these classes
please refer to the diagram on Appendix B2-iv.
v. Web Service Package
These are the set of classes responsible for implementing the web service component of
the CyberGIS service module. This service module is mainly responsible for operations
that occur between the cybergis mobile client and the cybergis web service module. For a
detailed inside look at these classes please refer to the diagram on Appendix B2-v.
15

26. vi. Servlet Package.
This is the package where the servlet responsible for retrieving the messages in the
message queue by the mobile client. Due to the limitations in the J2ME web services api
the J2ME mobile component of the cybergis system used this servlet to retrieve the
messages in the cybergis operator message queue in xml format.
vii. Utility Package
This is the package where all the utility classes responsible for all the cybergis operations
are found. These classes are centrally defined in the utility package as the functionality of
the classes are universally accessed by almost all the other classes in the cybergis service
module packages. For a detailed inside look at these classes please refer to the diagram
on Appendix B2.vi.
16

27. Figure 4.3 – CyberGIS GUI Module High Level Design.
CyberGIS GUI Module – High Level Design
This module provides the HTTP web interface of the cybergis system. This module
allows the cybergis administrative user to centrally administer the cybergis system using
a web based gui interface. As depicted in the above diagram the CyberGIS GUI module
has its own business logic calling/processing classes for the GUI level rendering and
calling the business logic in the CyberGIS Service module via RMI. The CyberGIS GUI
module also has the receiving ends of two JMS messaging queues to receive CyberGIS
Operative Location updates and CyberGIS Message Status Updating JMS Queues.
If we take a closer look at the CyberGIS GUI Module It Consist of several packages and
each of those packages consist of several classes. Therefore for us to be able to explain
the entire system in a simple manner we‟ve divided the class diagrams by their packages
and presented below using their class names. For detailed information of each of the
classes in the packages mentioned below please refer the appropriate appendix mentioned
beside the classes.
17

28. i. Logic Package
This package contains cybergis business logic that has no database interaction what so
ever and have been implemented on the GUI side in order to reduce the response time
due to RMI call delays. For a detailed inside look at these classes please refer to the
diagram on Appendix B3-i.
ii. Service Package
This package consist of the CyberGIS GUI module classes that are used to communicate
with the service module and call the business logic method of the cybergis service
module via RMI calls. For a detailed inside look at these classes please refer to the
diagram on Appendix B2-ii.
iii. Param Package.
This package consists of the parameter classes used in the cybergis gui module. For a
detailed inside look at these classes please refer to the diagram on Appendix B3-iii.
18

29. iv. MDB package
This package consists of the JMS message queue front end classes that receive messages
from the JMS queues and process them. For a detailed inside look at these classes please
refer to the diagram on Appendix B2-iv.
v.Filter Package
This package consists of the classes that are used for user authentication and
authorization filtering done throughout the application. For a detailed inside look at these
classes please refer to the diagram on Appendix B3-v.
vi. Utility Package.
This package contains the classes with the utility functions that are used throughout the
cybergis gui application. For a detailed inside look at these classes please refer to the
diagram on Appendix B3-vi.
vii. Test Package.
This package consists of the unit testing classes used for unit testing the CyberGIS GUI
module level business logic implementations. For a detailed inside look at these classes
please refer to the diagram on Appendix B2-vii.
19

30. CyberGIS Mobile Component – High Level Flow
Figure 4.4 CyberGIS Mobile Module High Level Design
This is the natively running J2ME application component of the CyberGIS System. The above
diagram shows the basic flow of this mobile application. This component will communicate with
the Cybergis service module using the HTTP and via DOCUMENT+LITERAL Style web service
calls. If we take a closer look at the CyberGIS Mobile Componet It Consist of several packages
and each of those packages consist of several classes. Therefore for us to be able to explain the
entire system in a simple manner we‟ve divided the class diagrams by their packages and
presented below using their class names. For detailed information of each of the classes in the
packages mentioned below please refer the appropriate appendix mentioned beside the classes.
20

31. i. GUI Package.
This package contains the main GUI design class of the Mobile Application. For a
detailed inside look at these classes please refer to the diagram on Appendix B1.i.
ii. Service Package
This package consists of the classes that the CyberGIS mobile component uses to
communicate with the CyberGIS web service via web service and HTTP calls. For a
detailed inside look at these classes please refer to the diagram on Appendix B1-ii.
iii. Core Package
This package consists of the core business logic classes that implement the business logic
inside of the CyberGIS mobile component. For a detailed inside look at these classes
please refer to the diagram on Appendix B1-iii.
21

32. iv. Constants Package.
This package consists of the constants class used right throughout the cybergis mobile
application component. . For a detailed inside look at these classes please refer to the
diagram on Appendix B1.iv.
v. Param Package
This package consists of the parameter classes used by the CyberGIS Mobile application
component. . For a detailed inside look at these classes please refer to the diagram on
Appendix B1.iv.
22

33. CHAPTER 05
FABRICATION OF SOFTWARE
For the development of the software we‟ve used java as the core development language.
All the components & technology frameworks used are mainly core java based
implementations.
When writing the software the 03 main software components of the system we‟re used
the following technologies and software to come up with a distributed web based
cybergis software solution.
Client Browser
We could use any type of latest client browser like google chrome or IE7 to use the
administrative web component of the cybergis system.
HTTP/HTTPS Network
The CyberGIS system is currently available via both HTTP network. And in the future it
will support HTTPS based networking.
Web Application Server
The web application server used in developing the CyberGIS system is the apache tomcat
7.0.12 web application server. For our system we‟ve configured this application server to
have ActiveMQ embedded inside the application server.
Database Server
The Database server used in the CyberGIS system is the mysql database server.
Integrated Development Environments
The Intergrated Development Environments.NetBeans with J2ME development plugn &
Eclipse have been for developing the cybergis system.
Web Framework
The Web framework used is the Spring Web framework to develop this system.
23

34. GUI Development Framework
The GUI development framework used in the CyberGIS is called the primefaces
(www.primefaces.org). This is a is a lightweight open source component suite for Java
Server Faces 2.0 featuring 100+ rich set of JSF components.
ORM Framework
The ORM framework used in developing the CyberGIS System is the toplink oracle orm
with the Java JPA framework.
24

35. CHAPTER 06
TESTING AND IMPLEMENTATION
Test Objectives
A primary objective of testing the system is to assure that the system meets the full requirements,
including quality requirements (Non-functional requirements) and fit metrics for each quality
requirement and satisfies the use case scenarios and maintain the quality of the product. At the
end of the project development cycle, the user should find that the project has met or exceeded all
of their expectations as detailed in the requirements.
Any changes, additions, or deletions to the requirements document, Functional Specification, or
Design Specification will be documented and tested at the highest level of quality allowed within
the remaining time of the project and within the ability of the test team.
The secondary objective of testing the system will be to identify and expose all issues and
associated risks, communicate all known issues to the project team, and ensure that all issues are
addressed in an appropriate matter before release. As an objective, this requires careful and
methodical testing of the application to first ensure all areas of the system are scrutinized and,
consequently, all issues (bugs) found are dealt with appropriately.
Assumptions for the Test Execution
 For User Acceptance testing, the Developer team has completed unit, system and
integration testing and met all the Requirement‟s (including quality requirements) based
on Requirement Traceability Matrix.
 User Acceptance testing will be conducted by End-users
 Test results will be reported on daily basis using reports.
 Failed scripts and defect list from reports with evidence will be sent to Developer
directly.
 Use cases have been developed by Adopters for User Acceptance testing.
 Use cases are approved by test lead.
 Test scripts are developed and approved.
25

36.  Test Team will support and provide appropriate guidance to Adopters and Developers to
conduct testing
 Major dependencies should be reported immediately after the testing kickoff meeting.
Test Deliverables
Testing will provide specific deliverables during the project. These deliverables fall into three
basic categories: Documents, Test Cases / Bug Write-ups, and Reports. Here is a diagram
indicating the dependencies of the various deliverables:
Require- Test Case Bug
ments [PM] Results Results
Project Plan Test Plan Test Spec. Test Bugs
[PM] / Outline Cases
Detailed
Functional Design
Spec [PM] TC Coverage Bug Reports
[Dev]
Reports
Figure 6.1 Test Deliverables
As the diagram above shows, there is a progression from one deliverable to the next. Each
deliverable has its own dependencies, without which it is not possible to fully complete the
deliverable.
Bug Classification Strategy
Bug Severity and Priority fields are both very important for categorizing bugs and prioritizing if
and when the bugs will be fixed. The bug Severity and Priority levels will be defined as outlined
in the following tables below. Testing will assign a severity level to all bugs. The Test Lead will
be responsible to see that a correct severity level is assigned to each bug.
26

37. The Test Lead, Development Lead and Program Manager will participate in bug review meetings
to assign the priority of all currently active bugs. This meeting will be known as “Bug Triage
Meetings”. The Test Lead is responsible for setting up these meetings on a routine basis to
address the current set of new and existing but unresolved bugs.
Severity Severity Severity Description
ID Level
1 Critical The module/product crashes or the bug causes non-recoverable
conditions. System crashes, GUI Faults, or database or file corruption,
or potential data loss, program hangs requiring reboot are all examples
of a Severity. 1 bug.
2 High Major system component unusable due to failure or incorrect
functionality. Severity. 2 bugs cause serious problems such as a lack
of functionality, or insufficient or unclear error messages that can have
a major impact to the user, prevents other areas of the app from being
tested, etc. Severity. 2 bugs can have a work around, but the work
around is inconvenient or difficult.
3 Medium Incorrect functionality of component or process. There is a simple
work around for the bug if it is Severity. 3.
4 Minor Documentation errors or signed off severity 3 bugs.
Table 6.1 – Severity Classification
Test Coverage
Unit Test
Unit testing was carried out for each component in the CyberGIS GUI application and
Mobile Client Application and for each service module in the web service.
27

38. Regression Test
Regression testing was carried out to verify that any changes done as a bug fix will not
affect the functionalities of the working components. Every time when we make bug fix
we did the regression testing to all the system components.
System Test
The System tests will focus on the behavior of the CyberGIS system. User scenarios will
be executed against the system as well as screen mapping and error message testing.
Overall, the system tests will test the integrated system and verify that it meets the
requirements defined in the requirements document.
Performance Test
Performance test will be conducted to ensure that the CyberGIS system‟s response time
meet the user expectations and does not exceed the specified performance criteria. During
these tests, response times will be measured under heavy stress and/or volume.
Compatibility Test
Compatibility testing was carried out to check the application compatibility with the
browsers since the application is fully web based and check other software and hardware
compatibility constraints.
Stress and Volume Test
We will subject the CyberGIS system to high input conditions and a high volume of data
during the peak times. The System will be stress tested using twice (5 users) the number
of expected users.
Security Test
Security tests will determine how secure the new CyberGIS system is. The tests will
verify that unauthorized user access to confidential data is prevented.
28

39. Test cases are written and executed manually for the GUI and Mobile applications and
automated test cases are used to test the service module. As results of the testing phase
we generated the Test Case documents with the results and identified bugs.
Implementation of the system mainly focuses on database implementation and
application implementation. We used MySQL server as our database engine. So we need
to implement the database in either the application server or a separate server.
Application server needs tomcat server service to implement the Cyber GIS application.
For the mobile clients we provide a separate executable .jar file to install in to the mobile
device which may implement the CyberGIS application in the devices. When the tomcat
server which contains the application and web service started, Users are imposed to the
CyberGIS application. They can access the application console through any web browser
through a provided URL. (i.e. http:// 127.0.0.1:8080/gis-app/)
System Performance
In software engineering, performance testing is testing that is performed, to determine
how fast some aspect of a system performs under a particular workload. It can also serve
to validate and verify other quality attributes of the system, such as scalability, reliability
and resource usage. With related to performance testing there are few other types of tests
which are correlated with it.
Load Testing
Load testing is the simplest form of performance testing. A load test is usually conducted
to understand the behavior of the application under a specific expected load. This load
can be the expected concurrent number of users on the application performing a specific
number of transactions within the set duration. This test will give out the response times
of all the important business critical transactions. If the database and application server
are also monitored, then this simple test can itself point towards any bottlenecks in the
application software.
29

40. Stress Testing
Stress testing is normally used to understand the upper limits of capacity within the
application landscape. This kind of test is done to determine the application's robustness
in terms of extreme load and helps application administrators to determine if the
application will perform sufficiently if the current load goes well above the expected
maximum.
Endurance Testing (Soak Testing)
Endurance testing is usually done to determine if the application can sustain the
continuous expected load. During endurance tests, memory utilization is monitored to
detect potential leaks. Also important, but often overlooked is performance degradation.
That is, to ensure that the throughput and/or response times after some long period of
sustained activity are as good as or better than at the beginning of the test. It essentially
involves applying a significant load to a system for an extended, significant period of
time. The goal is to discover how the system behaves under sustained use.
Spike Testing
Spike testing, as the name suggests is done by spiking the number of users and
understanding the behavior of the application; whether performance will suffer, the
application will fail, or it will be able to handle dramatic changes in load.
Performance Measures
 Concurrency/Throughput
 Server response time
 Render response time
 Performance specifications
30

41. Performance Testing Methodology
We have followed the following activities to conduct the performance testing:
 Identify the Test Environment.
We have to identify our test environment first. We haven‟t hosted the site in a real
time application server. So we are unable to test some parts of the application
with real working environment. So need to use simulators to simulate the system
and test those components. Apache tomcat 7.0.12 is our application server.
CyberGIS GUI module and web service modules are deployed on apache tomcat
server. To test the CyberGIS mobile client we have used Remote Device Access
provided by Nokia Developers as the simulator for mobile device.
(http://www.developer.nokia.com/Devices/Remote_device_access/ ) As the
network connection, mobile broadband connection is used with 3.2 mbps
bandwidth. All types of web browsers available are taken as software. We used
the available resources up to maximum level for testing.
Having a thorough understanding of the entire test environment at the outset
enables more efficient test design and planning and helps you identify testing
challenges early in the project. In some situations, this process must be revisited
periodically throughout the project‟s life cycle.
 Identify Performance Acceptance Criteria.
The acceptance criteria for the CyberGIS are to provide a response time less than
30 seconds for any operation of functionality, allow concurrency access to the
system for 100 mobile users and 10 administrative users. Message queue should
capable of handling 1000 messages in the queue till message delivery. Expected
throughput for the mobile operative message sending should be delivering 30
messages per minute. Zero down time should be maintained to provide efficient
performance.
31

42.  Plan and Design Tests.
Tests should design to check the following:
- Check the loading time of any web page
- Allow concurrency access of 10 administrative users and 100 mobile users
- Send operative messages to the concurrent users within 30 seconds
- Check the network delays
- Stress handle In message queue
- Hardware or software failure handling
- Load balancing
For the above tests we defined the test data with 12 operative users, 36 mobile
users, 840 map markers, 8 snap shots and 1290 operative messages with 210
responses. All administrative users and mobile operative users are going to use
the system concurrently, 840 markers to be located in the map, 1290 operative
messages to be delivered to mobile users and 910 feedbacks to be received during
tests. There should be metrics to collect the responses for the page loading time,
operative message delivery time, operative response receiving time, network
delays and load and stress measures.
 Configure the Test Environment.
To prepare the test environment, first we have to start the Apache tomcat
application server and start the CyberGIS web module, GUI module and mobile
client module. Then we need to start the web browsers and navigate to the
application. Meanwhile the simulator should be started to test the mobile client.
To measure the response time and other measurements we have to equipped with
timers and calculators. Also other required resources should be properly allocated
before executing the tests.
32

43.  Implement the Test Design.
To measure the system performance we need to carry out the above mentioned
Load testing, Stress testing, Soak testing and Spike testing. The goal is to identify
the performance measures by conducting tests and measuring results and response
times. We need to write a proper set of test cases to execute while testing. There is
a set of manually written test cases and automated test cases (implemented using
JUnit component) designed to test the system performance. Refer Appendix F for
details.
 Execute the Test.
We start the Apache tomcat server and deploy all three modules and create the
test environment first. Administrative user login function for 12 users was carried
out through several web browser instances. For mobile operative user login
function, remote device access simulator was used provided by Nokia developers.
Using several simulator instances we create 36 concurrent operative user logins.
The logged in administrative users are assigned to add 840 map markers to make
a huge load, stress and network traffic. Administrative users need to login again
and load the added map makers. That is to check the page loading time. Also
report generation wizard used to test the web page loading time. More
administrative users are logged in to system and load the main panel at the same
time to test the load balancing. 1290 operative messages were sent to 36 logged in
mobile operative users by 12 administrative users consecutively within minutes.
That is related to spike testing and stress testing. To check the response time
mobile users are instructed to accept the messages and send responses.
While running the above test items we monitor outcomes and following results
are observed:
- It is possible to concurrently use the system for more administrative users
and operative users than expected.
- Simultaneous operations done by the administrative users were holds the
maximum network bandwidth.
33

44. - Same operation by multiple users at the same time (more than 10
occurrences) will cause to network delays exceeding 30 seconds.
- Web page load gives immediate response within 08 seconds and takes 40
seconds to finish loading all components of the map. (840 map markers)
- Report generating wizard takes 24 seconds to respond with such amount
of markers and 12 concurrent requests.
- While increasing the concurrent users than the expected level, page load
time increases than performance specifications. (Load balancing takes
place)
- Operative message takes 05 seconds to reach the destination.
- Responses for the operative messages received in 03 seconds.
- Message queue was able to handle 15 messages per minute when it
exceeds expected queue length.
- Messages without accepted by mobile users are waiting in the queue more
than 15 minutes and holds the resources.
- Throughput for browsing a web page with concurrent access is around 25
seconds.
- Failure in application software (web browser) will lose all non saved data
with it.
 Analyze Results, Tune, and Retest.
After collecting results for the tests, we have to analyze them and make some
adjustments to improve the performance of some sections. Obviously we have to
do a code change since we are unable to go beyond the recommended hardware or
software configurations. To provide a response within 30 seconds, we changed
the map zoom level in 12 as default. We have to timeout the mobile operative
messages in the message queue if they are not accepted by mobile operators. This
is to maintain the throughput. Providing a faster internet connection will keep the
response time reduced. After doing changes we have to retest the functionality to
check the improvements.
34

45. CHAPTER 07
RESULTS
As the results, we include the test results here.
In all the test cases conducted through the testing phase about 85% of the tests are
succeeded and only 15% of the tests come up with bugs. Please refer the table in
Appendix F for details. Expected results of the test cases are appeared as the actual
results. So the status of the test is „Pass‟. Out of the bugs found, we have immediately
fixed 80% of bugs which are highly related to functional and performance indices of the
application. We are more focused on test results which are in „Fail‟ status with having
high test priority when resolving the bugs immediately. There are few things remained
found as minor issues and we need to address those as future works since those are
currently not affected to the system performance and functionalities.
At the end we found that all Unit testing, System Testing, Regression Testing,
Performance Testing, Compatibility Testing and Security Testing which we have
completed are succeeded. With the test results we can come to a conclusion that system‟s
functional and non functional requirements are addressed properly.
35

46. CHAPTER 08
CONCLUSION AND FUTURE WORK
8.1 CyberGIS GUI Module.
The following features and functionalities have been identified as future works under the
CyberGIS GUI module.
 Marker Proximity Ruler and Alerter :-
By the "Ruler" feature CyberGIS main console users will be able to measure the
distance to each marker (including mobile markers) from a specified central origin
point. So CyberGIS main console users will be able to specify the central point and
get updated proximity measurement according to that. By the "Alerter" feature
CyberGIS main console users will be able to view the details of markers, within a
specified proximity circle from a specified central origin point. Both these features
will work as a single unit.
 Automatic Real Time Operative Tracking :-
Currently operative tracking is not fully automated and the CyberGIS main console
users have to refresh the operative location in order to get the update location. By this
proposed feature operative tracking will be fully automated and updated locations
will be refreshed on the CyberGIS main console map in a specified time intervals.
 Hardware Sensor Based Real Time Telemetry :-
By this functionality it is proposed to gather various data required by domain users
through hardware sensors, attached to CyberGIS Mobile component and send them to
the CyberGIS main console for real time monitoring. So the CyberGIS GUI module
will include a dashboard component in order to support this feature.
36

47. 8.2 CyberGIS Mobile Component.
In the future the system is expended to be expanded by porting the J2ME client software
to newly available high end mobile phone operating systems like: Android & iPhone.
Currently it supports all Symbian OS based mobile phones like S40 6th Edition & S60 3rd
Edition Phones. Other than this we wish to expand the service end by adding a
dashboard for live monitoring services where the user will be able to monitor live
statistics about the current functionality of the system.
8.3 CyberGIS Service Module.
As a conclusion we can say that, CyberGIS Service Module maintains the connectivity
between Cyber GIS application and database. All user requests and operations are
addressed through service methods provided in this module.
Code optimization and further expansions of the available services can be done as the
future works. The objective of this is to reduce the resources usage by the application
during the execution. More code level validations can be implemented to provide
additional security to the system.
We are focusing to make the system available with live statistics with the use of service
module improvements.
37

48. CHAPTER 09
PROJECT CONTRIBUTIONS
9.1 Project Contribution by: M.S.R Perera <209087374>
As the architect of the entire project I‟ve contributed to the CyberGIS project in doing the
following:
1. Using the business scenarios /requirements given by Roshan (The person playing
the project manager role) come up with a suitable architecture for the entire
system.
2. Decide a suitable Java Based Technology stack for the CyberGIS system.
3. Create the initial 03 projects using the decided technology stacks by
configurations and ensure the Spring based web flow between the initially created
03 projects. (i.e.: As the project is distributed system with 03 modules to make
sure the request response flow works correctly via RMI & Web service interfaces
between the modules)
4. Contributed in designing and implementing the CyberGIS Mobile Client Software
from ground up.
5. Contributed in designing and implementing the GUI parts related to sending
CyberGIS operative messages and receiving responses.
6. Contributed in writing all the Web Service Methods and exposing them via
correct document + literal style web services to be called by the mobile client.
7. Provided Technical support and guidance for the team members (Roshan &
Sanjeewa) in configuring the application server, implementing various business
logic related GUI/Service parts & technical advice on the used Java Related
technology stack.
8. Documented the CyberGIS project related architecture design diagrams (general
architecture, ER-diagrams & Class diagrams).
38

49. 9. Did Integration testing & bug fixing on all 03 modules upon various commits on
different modules by the other two team members & ensured that the system was
working smoothly as a whole
10. Facilitated the stream line distributed development process by creating the project
in the Google SVN and providing software and support for the team to work with
the SVN.
11. Prepared necessary project documents under the software architect role for each
milestone.
9.2 Contribution by: D.S Kulasuriya<709087412>
I have contributed to the CyberGIS project as the QA lead for my main role in the project
and as a developer in following areas.
1. Contributed to develop the Login, password resetting and User Administration
parts of the CyberGIS GUI module.
2. Design and implement the changes done to the basic database according to the
Project Architecture‟s requests and generate RMI objects to which are used to
maintain the communication between Web Service and other modules.
3. Implement the service methods according to the requests of the GUI and Mobile
Client developers. Services are developed on demand separately to access the
database and feed or retrieve data according to the user request or operation.
4. Implement test cases to unit test each service methods to verify the operation
results before releasing the service method for use by developers.
5. Improve the session tracking mechanism developed by Shehan, to maintain user
login and domain details. Use the same session tracking mechanism to allow
direct access the password reset component.
6. Completed the project documents related to QA. (Test Plan, Test Specification)
Also contributed to document the SRS document, Functional Specification and
Deployment Plan.
7. Test all the components of the CyberGIS GUI module for unit testing, security
testing, & performance testing and includes the results as the Test Case
39

50. Document. All the service methods in the CyberGIS Service module are gone
through unit testing before release for use.
8. Contribute to system development and bug fixing activities with Project
Manager‟s request.
9.3 Contribution by: W.M.D.R Jeewantha<509087436>
As the Project Manager I‟ve contributed to the CyberGIS project in doing the following:
1. Played the Project manager role.
2. Proposed the main concept of the CyberGIS system.
3. Developed the vision and goals that the CyberGIS system based on.
4. Designed the conceptual level components and the main workflow of the
CyberGIS system and refined it with system architect‟s technical opinions.
5. Designed GUI Interfaces for both CyberGIS mobile and CyberGIS main console
(CyberGIS GUI module) components and fine-tuned the all GUI
implementations.
6. Developed CyberGIS main console (CyberGIS GUI module) GUI framework
using JSF (Java Server Faces) with Primefaces component library.
7. Implemented the map and marker manipulation functionalities, and reporting and
analysis functionalities on CyberGIS main console as Java Backing Beans and
helper classes.
8. Developed Unit Test cases and performed unit testing for CyberGIS GUI module
class methods using JUnit.
9. Implemented RMI Service module methods for reporting functionalities.
10. Developed Test cases and performed unit testing for RMI Service module
methods for reporting functionalities using JUnit.
11. Prepared necessary project documents under the project manager role for each
milestone.
40

51. REFERENCES
ESRI. 2010. ESRI home page. [Online]. Available at: http://www.esri.com/ [Accessed 10
October 2010].
Google Maps. 2010. Google Maps home page. [Online]. Available at: http://
maps.google.com/ [Accessed 05 October 2010].
Google Maps API. 2010. Google Maps API home page. [Online]. Available at:
http://code.google.com/apis/maps/documentation/javascript/ [Accessed 20 October
2010].
Wikipedia. 2011. Tracking Analyst and Tracking Server. [Online]. Available at:
http://en.wikipedia.org/wiki/Geographic_Information_Systems_in_Geospatial_Intelligen
ce#Tracking_Analyst_and_Tracking_Server.
GIS.COM. 2011. What is GIS?. [Online]. Available at: http://www.gis.com/content/what-
gis [Accessed 15 August 2011].
Open Street Map. 2010. Open Street Map home page [Online]. Available at:
http://www.openstreetmap.org/ [Accessed 05 October 2010].
Open Street Map. 2010. Open Street Map home page [Online]. Available at:
http://www.Primeface.org [Accessed 15 December 2010].
Spiegel, M.R, 1961.Theory and Problems of Statistics. McGraw-Hill.
41

52. APPENDIX
Appendix A – Use case Diagrams
Appendix A1 – CyberGIS Admin User Use Case Diagram
42

53. Appendix A2 – CyberGIS Operative User Use Case Diagram
43

54. Appendix B – Class Diagrams
Appendix B1 –CyberGIS Mobile Component Class Diagrams
Appendix B1.i GUI Package
44

55. Appendix B1.ii Service Package
45

56. Appendix B1.iii . Core Package
46

57. Appendix B1.iv . Constants And Param Package
47

58. Appendix B2 – CyberGIS Service Module Class Diagrams
AppendixB2.i:The RMI DTO Package
48

59. Appendix B2.ii Service DTO Package
49

60. Appendix B2.iii Business Logic Package
50

61. Appendix B2.iv. JPA Package
51

62. Appendix B2.v .Web Service Package
52

63. Appendix B2.vi . Utility Package
53

64. Appendix B3 – CyberGIS GUI Module Class Diagrams
Appendix B3.i . Logic Package
54

65. Appendix B3.ii Service Package
55

66. Appendix B3.iii. Param Package.
Appendix B3.iv . MDB package
Appendix B3.v . Filter Package
56

67. Appendix B3.vi Utility Package.
57

68. Appendix B3.vii . Test Package
58

69. Appendix C – Sequence Diagrams.
Appendix C1: Add Domain Map Marker
59

70. Appendix C2: Close Domain Map Marker
60

71. Appendix C3: Create Snap shot
61

72. Appendix C4: Generate CyberGIS Report
62

73. Appendix C5: Send Operative Location Update
63

74. Appendix C6: Send Operative Message
64

75. Appendix C7: View Operative Message History
Appendix C8: Send Operative Message Notification
65

76. Appendix C9: View Current Operative Location On Map
66

77. Appendix C10: Timeout CyberGIS Operative Message
67

78. Appendix C11: Add Domain User
68

79. Appendix C12: Login CyberGIS User
69

80. Appendix D – Activity Diagram
Appendix D1: Load Main Console
Appendix D2: Display Operative location
70

81. Appendix D3: Add New Map Marker
Appendix D4: Close Map Marker
71

82. Appendix D5: Edit Map Marker
Appendix D6: Send Operative Message
72

83. Appendix D7: Load Main Console
Appendix D8: Add New User
73

84. Appendix E – ER Diagram
74

85. Appendix F –Screen Designs
Appendix F1: CyberGIS Main Console
Appendix F2: CyberGIS Login Dialog
75

86. Appendix F3: CyberGIS New Marker Dialog
Appendix F4: CyberGIS New User Dialog
76

87. Appendix F5: CyberGIS Map Marker Panel
Appendix F6 : CyberGIS Report Wizard Dialog
77

88. Appendix F7: CyberGIS Operative Message Dialog
Appendix F8: CyberGIS Operative Message History Dialog
78

89. Appendix F9: CyberGIS Mobile Login
Appendix F10: CyberGIS Mobile Main Screen
79

90. Appendix F11: CyberGIS Mobile Task List
Appendix F12: CyberGIS Mobile Task Details
80

91. Appendix F13: CyberGIS Mobile Task Notification
Appendix F14: CyberGIS Mobile Task Status Update
81

92. Appendix G : Test Cases
Test Test steps
Test Case Test Case
Case
Name Description step Expected Result Actual Result
Id
01 Login to System Test Login 1. Visit Login Page Auto Navigation to Auto Navigation to
With Correct Component with 2. Enter Username & Main Panel Main Panel
Data providing Correct Password
User Name & 3. Click Login
Password
02 Login to System Test Login 1. Visit Login Page Message indicating Message saying
With Incorrect Component with 2. Enter Username & Login Failed „Incorrect User
Data providing Incorrect Password Name and/or
User Name or 3. Click Login Password. Login
Password Failed. Please try
again.‟
03 Login to System Test Login 1. Visit Login Page Message indicating Separate Messages
With Blank Component with 2. Click Login Values Required. for all blank fields
Password providing blank indicating Values
User Name or Required.
Password
04 Login Details Test Login Page 1. Visit Login Page Clear Username & Clear Username &
Resetting Reset Component 2. Enter Username &/or Password Password
Password Fields. Field Values.
3. Click Login
05 Test Forgot Test Forgot 1. Visit Login Page Navigation to Reset Navigation to Reset
Password Link Password Link 2. Click Forgot Password Page. Password Page
navigates to the Password? Link
Reset Password page
06-a Password Reset Test the Forgot 1. Visit Login Page Prompt a Link to Message appears as
with Correct Password 2. Click Forgot Navigate to Login Internal Error
Data component with Password? Link Page again. Occurs.
providing correct 3. Enter Username,
Username, Email Email , New Password
and Password & Repeat New
Password
4. Click Submit
06-b Password Reset Test the Forgot 1. Visit Login Page Prompt a Link to Link appears to
with Correct Password 2. Click Forgot Navigate to Login Navigate to Login
Data component with Password? Link Page again. page
providing correct 3. Enter Username,
Username, Email Email, New Password
and Password & Repeat New
Password
4. Click Submit
82

93. 07 Test Password Test the Forgot 1. Visit Login Page Message indicating Message appears
Reset New Password 2. Click Forgot Password Mismatch. indicating „Password
Password not component with Password? Link Mismatch. Please
correctly providing correct 3. Enter Username, enter new
Repeated Username, Email. Email, New Password Password.‟
But new password is & Repeat New
incorrectly repeated Password
4. Click Submit
08 Test Password Test the Forgot 1. Visit Login Page Message indicating Message appears
Reset with Password 2. Click Forgot Incorrect Username/ indicating „Either
Correct component with Password? Link Email. you have entered an
Username and/or providing incorrect 3. Enter Username, invalid User Name
Email Username and/or Email, New Password or invalid E-Mail
Email. But new & Repeat New address .‟
password is Password
correctly repeated. 4. Click Submit
09 Test Password Test the Forgot 1. Visit Login Page Message indicating Separate Messages
Reset with blank Password 2. Click Forgot Values Required. for all blank fields
details. component with Password? Link indicating Values
providing blank 3. Click Submit Required.
Username, Email,
New Password, and
Repeat Password.
10 Test Forgot Test the Forgot 1. Visit Login Page Clear all Fields. Clear Username,
Password Password 2. Click Forgot Email, New
Component component Cancel Password? Link Password & Repeat
Cancel Button Button 3. Enter Username, New Password
Functionality. Email, New Password Field Values.
& Repeat New
Password
4. Click Cancel
11-a Test Password Test the link used to 1. Visit Password Reset Navigation to the Session Expired
Reset Message navigate to the Page login page. Message appears.
Link Login Page, appears 2. Enter correct details.
after Password 3. Click Submit
Reset. 4. Click Cyber-GIS
link in appeared page.
11-b Test Password Test the link used to 1. Visit Password Reset Navigation to the User Login Page
Reset Message navigate to the Page login page. Appears.
Link Login Page, appears 2. Enter correct details.
after Password 3. Click Submit
Reset. 4. Click Cyber-GIS
link in appeared page.
83

94. 12 Create New User Test Add New User 1. Visit Domain Message indicating Message appears
with Correct Functionality with Administration Panel Successfully saved. Indicating
Data providing all 2. Click Add Domain Successfully saved.
requested data User
3. Enter User Name,
Email, Contact Mobile,
Contact Telephone,
Company, Access
Level, Password and
Repeat Password.
4. Click OK
13 Create New User Test Add New User 1. Visit Administration Message indicating Separate Messages
with blank Functionality with Panel Values Required. for all blank fields
details. providing one or 2. Click Add New User indicating Values
more blank field 3. Click OK without Required.
values for User providing values for all
Name, Email, fields.
Contact Mobile,
Contact Telephone,
Company, Access
Level, Password and
Repeat fields.
14 Test Create New Test Create New 1. Visit Administration Clear all Fields. Clear User Name,
User Component User component‟s Panel Email, Contact
Cancel Button Cancel Button 2. Click Add New User Mobile, Contact
Functionality. 3. Enter User Name, Telephone,
Email, Contact Mobile, Company, Access
Contact Telephone, Level, Password and
Company, Access Repeat Password
Level, Password and Field Values.
Repeat Password.
4. Click Cancel
15 Test Home Page Test the Navigation 1. Visit Main Console Loading Main Load the Main
Link Button to Go to 2. Go Inside to panels. Console Page. Console Page.
Home Page 3. Click Home Button
16 Test Sign-out Test the Navigation 1. Visit Main Console Navigate to Login Load the User Login
Confirmation Button used to Sign 2.Click Signout Button page Page.
Response Out from the system 3. Confirm the Logout
with User response decision.
Confirm.
17 Test Sign-out Test the Navigation 1. Visit Main Console Remain unchanged in No Change to the
Cancel Response Button used to Sign 2.Click Signout Button Main Console. Current page.
Out from the system 3. Cancel the Logout
with User response decision.
Cancel.
18 Test Map Data Test Map Data Panel 1. Visit Main Console Update new Details Zoom Level, Center
Panel for updating with 2. Zoom or Change map in Map Data Display Longitude and
map changes view Tab Center Latitude
Updated in Map
Data Display
Section
84

95. 19 Test Save Snap Test the 1. Visit Main Console Save Snap shot data New record added to
Shot Button functionality of Save 2. Visit Map Data in to Database the Snapshot Table
Snap Shot Button in Panel with the details of
Map Data Panel 3. Click Save Snapshot Center Longitude &
Button Latitude, Zoom level
and makers
20 Add New Test Add New 1. Visit Main Console Dialog Panel will Data saved in
Marker Location Functionality in Map 2. Click New in Close. Save Data in Marker Location
with Data Markers Section Map Markers Section to Database and View Table in Database
with Providing all 3. Enter Marker Title, Marker in the Map. and New Icon
data. Marker Address, Added to the map
Longitude, Latitude, view.
Type, Status and Info
values in the Dialog
Panel Appeared
4. Click OK.
21 Add New Test Add New 1. Visit Main Console Message indicating Separate Messages
Marker Location Functionality in Map 2. Click New in Values Required. for all blank fields
without Markers Section Map Markers Section indicating Values
Providing Data without providing all 3. Click OK. Required.
data.
22 Test Add New Test Cancel Button 1. Visit Main Console Dialog Box will Add New Marker
Marker Location Functionality of 2. Click New in Disappear. Location Dialog
Component Add New Marker Map Markers Section closed and Data
Cancel Button Location 3. Enter Marker Title, entered are cleared
Component. Marker Address, without saving.
Longitude, Latitude,
Type, Status and Info
values
4. Click Cancel.
23 Edit Map Test Edit 1. Visit Main Console Dialog Panel will Data Updated in
Markers with Functionality in Map 2. Double Click on a Close and Save Data Marker Location
Data Markers Section for Marker Icon in the map in to Database. Table in Database
a selected marker. view. Update the Marker and Marker Icon
3. Click Edit in Icon according to changed if type
Map Markers Section Change. changed.
4. Modify relevant
details in the Dialog
Panel Appeared
5. Click Save.
24 Edit Map Test Edit 1. Visit Main Console Message indicating Separate Messages
Markers with Functionality in Map 2. Double Click on a Values Required for all blank fields
Blank Field Data Markers Section for Marker Icon in the map except Address Field. indicating Values
a selected marker view. Required except
providing Blank 3. Click Edit in Address Field.
Data. Map Markers Section
4. Clear field details in
the Dialog Panel
Appeared
5. Click Save.
85

96. 25 Test Edit Test Cancel Button 1. Visit Main Console Dialog Box will Edit Marker
Marker Functionality of 2. Double Click on a Disappear. Location Dialog
Component Edit Map Markers Marker Icon in the map closed and Data
Cancel Button Component view. entered are cleared
3. Click Edit in without saving.
Map Markers Section
4. Modify relevant
details in the Dialog
Panel Appeared
5. Click Cancel.
26 Test Focus in Test the Focus 1. Visit Main Console Map will focus to the Map focused to the
Map Markers Functionality in Map 2. Double Click on a Maker. given Marker by
Markers Section. Marker Icon in the map setting the marker
view. longitude and
3. Visit latitude as the
Map Markers Section center.
4. Click Focus.
27 Test Close Test Close Marker 1. Visit Main Console Status of the selected Selected marker
Marker Button Button Functionality 2. Double Click on a marker will change to status changed to
in Marker Icon in the map „Closed‟ and Marker „Closed‟
view. will remove from the (Need to refresh
3. Visit Map the page to remove
Map Markers Section the marker from
4. Click Close Marker the Map)
28 Message Mobile Test the Send 1. Visit Main Console Message will send to Message sent to the
Operatives Message 2. Double Click on a the mobile device of queue of the mobile
Component Send Functionality to the Marker Icon in the map the selected operators client to send to the
Message to selected operators of view. operators and saved
selected users. Message Mobile 3. Visit the message in the
Operatives Tasks and Alerts Panel Database.
Component 4. Click Message
Mobile Operatives
5. Enter Message
Header and Content
6. Select operatives
from the available list to
send the message
7. Click Send Message
29 Message Mobile Test the View 1. Visit Main Console Display details of the Message details
Operatives Message History 2. Double Click on a Sent Messages to the (Status, Time,
Component Functionality of Marker Icon in the map selected operators in Header, Operator)
View History Message Mobile view. a Dialog Panel are listed in to a grid
Button Test Operatives 3. Visit which are sent to the
Component Tasks and Alerts Panel selected operators.
4. Click Message
Mobile Operatives
5. Select operatives
from the available list
7. Click View History
86