Debre Berhan University: College of Computing Department of Computer Science

DEBRE BERHAN UNIVERSITY
COLLEGE OF COMPUTING
DEPARTMENT OF COMPUTER SCIENCE
TITLE: - ANDROID BASED MOBILE ANTI-THEFT SYSTEM
Prepared By:
Name:ID no.
1) ABIE CHECKOL COMPR/004/04
2) FIKRTE TEFERA COMPR/014/04
3) GETAHUN TADESSE COMPR/018/04
4) SOLOMON GETACHEW COMPR/044/04
5) YIBEKAL ALMIRAW COMPR/051/04
FINAL PROJECT SUBMITED TO DEPARTMENT OF computer science IN PARTIAL

FULFILLEMENT OF THE REQUIREMENTS FOR THE DEGREE OF BACHELOR OF SCIENCE
IN computer science
JUN,10 , 2015
DEBRE BERHAN ETHIOPIA

Certificate of Approval
This is to certify that the work contained in this project entitled as, “Android Based
Mobile Anti-Theft System” was carried out by
AbieCheckol,FikrteTefera,GetahunTadesse,SolomonGetachew and YibekalAlamirew under
the supervision of Instructor Yitayal(MSc), at DebreBerhan University College of
Computing, department of computer science. It is fully adequate, in scope and in quality, for
degree of B.A In Computer Science.
Advisor: -------------------------
Yitayal Abate (MSc)
Examiner I: ---------------------------
______________________
Examiner II: ---------------------------
______________________
Examiner III: ---------------------------
______________________
Examiner IV: ---------------------------
______________________
Head of Department: ----------------------------
Yimer Mohammed (MSc)
Dept. of Computer science
DebreBerhan University College of Computing

Table of content
Contents Page
List of Tables…………………………………………………………………………………VI
List of Figurers…………………………………………...…………….…………………… VI
Abbreviation and acronyms……………………………………………………………….. VII
Abstract………………………………………………………………………….... VIII
CHAPTER ONE ................................................................................................................... 1
SYSTEM PLANNING .......................................................................................................... 1
1.0 Introduction ..................................................................................................................... 1
1.1 Background ..................................................................................................................... 1
1.2 Statement of the Problem ................................................................................................ 2
1.2.1 Problem Definition ........................................................................................................................ 2
1.2.2 Problem Explanation...................................................................................................................... 2
1.3 Motivation .................................................................................................................. 2
1.4 Objectives of the project .................................................................................................. 2
1.4.1General Objective ........................................................................................................................... 2
1.4.2 Specific objective ........................................................................................................................... 3
1.5 Scope .............................................................................................................................. 3
Limitation ............................................................................................................................. 3
1.6Significant of the project .................................................................................................. 4
1.7Feasibility study of the new system .................................................................................. 4
1.7.1 Economic feasibility ...................................................................................................................... 4
1.7.2 Operational feasibility.................................................................................................................... 4
1.8Methodology .................................................................................................................... 4
1.8.1 Fact finding Techniques ................................................................................................................. 4
1.8.2 System Analysis and Design Techniques ...................................................................................... 5
Object Oriented Analysis (OOA)....................................................................................... 5
Object Oriented Design (OOD) ......................................................................................... 5
1.8.3 Tools and technologies .................................................................................................................. 5
1.9Resources ......................................................................................................................... 6
I
1.10 Risk ............................................................................................................................... 6
CHAPTER TWO .................................................................................................................. 8
SYSTEM ANALYSIS .......................................................................................................... 8
2.1 Introduction ..................................................................................................................... 8
2.2 Existing system description ............................................................................................. 8
2.3 Problems of the existing systems ..................................................................................... 8
Time consuming ................................................................................................................... 8
GPS dependent...................................................................................................................... 8
2.4 The proposed system ....................................................................................................... 8
2.4.1 Functional Requirements ............................................................................................................... 9
2.4.2 Nonfunctional requirement ............................................................................................................ 9
2.5 Overview of Data Requirements ....................................................................................... 9
2.6 Use Case Modeling ......................................................................................................... 9
2.6.1 Use case description..................................................................................................................... 10
2.7 Analysis of Class Modeling ........................................................................................... 15
2.8 Sequence Modeling ....................................................................................................... 16
2.9Activity Modeling .......................................................................................................... 21
2.10 Collaboration Modeling ............................................................................................... 25
2.11 State chart Modeling ................................................................................................... 29
CHAPTER THREE............................................................................................................. 31
SYSTEM DESIGN ............................................................................................................. 31
3.1 Introduction ................................................................................................................... 31
3.2 Design goals and objectives........................................................................................... 31
3.3 System architecture ....................................................................................................... 32
3.3.1 Architectural Design .................................................................................................................... 32
3.4 System Decomposition .................................................................................................. 34
3.5 Class mapping ............................................................................................................... 37
Description of class mapping .............................................................................................. 37
3.6 Data base design............................................................................................................ 39
CHAPTER FOUR ............................................................................................................... 40
IMPLEMENTATION DELIVERABLE OF THE NEW SYSTEM ..................................... 40
4.1 Introduction ................................................................................................................... 40
4.2 Component diagram ...................................................................................................... 40
II
4.3 Deployment diagram ..................................................................................................... 41
4.4user interface design ....................................................................................................... 42
CHAPTER FIVE ................................................................................................................ 50
Prototype Development ....................................................................................................... 50
CHAPTER SIX ................................................................................................................... 71
Testing ................................................................................................................................ 71
6.1 Introduction ................................................................................................................... 71
CHAPTER SEVEN............................................................................................................. 74
Conclusions and recommendation ....................................................................................... 74
7.1 Conclusions................................................................................................................... 74
III
List of Tables
Table 3.1: Data Base Design ............................................................................................................ 45
List of Figures
Figure 2.1: Use case Modeling ……………………………………………………………………………………………………15
Figure 2.2: Analysis class Modeling for mobile Anti-theft system………………….…...….16
Figure 2.3: Login Sequence Modeling ........................................... Error! Bookmark not defined.17
Figure 2.4 : Register detail in the database Sequence Modeling ............................................... 17
Figure 2.5: Re-register detail in the database Sequence Modeling ............................................ 18
Figure 2.6: Retrieve detail from database Sequence Modeling .................................................. 19
Figure 2.7: Receive SMS Sequence Modeling .............................................................................. 20
Figure 2.8: Retrieve GPS co-ordinate Sequence Modeling ......................................................... 21
Figure 2.9: Activity Modeling for login ......................................................................................... 22
Figure 2.10: Activity Modeling for Register detail in the database ........................................... 23
Figure 2.11: Activity Modeling for Re-register detail in the database ...................................... 24
Figure 2.12: Activity Modeling for Retrive detail in the database ............................................. 24
Figure 2.13: Activity Modeling for Receive SMS........................................................................ 25
Figure 2.14: Login Collaboration Modeling .................................................................................. 26
Figure 2.15: Register detail in the database Collaboration Modeling ........................................ 26
Figure 2.16: Re-register detail in the database Collaboration Modeling ................................... 27
Figure 2.17: Retrieve detail from database Collaboration Modeling ......................................... 27
Figure 2.18: Recive SMS Collaboration Modeling ...................................................................... 28
Figure 2.19: Retrieve GPS co-ordinate Collaboration Modeling ............................................... 28
Figure 2.20: Login state chart Modeling ........................................................................................ 29
Figure 2.21: Re-register detail in the database state chart Modeling ......................................... 30
Figure 2.22 Register detail in the database state chart Modeling ............................................... 30
Figure 3.1: Illustration of 3-Tier Architecture with Modeling .................................................... 42
Figure.3.2: System Architecture ....................................................................................................... 43
Figure 3.3: System Decomposition .................................................................................................. 45
Figure 3.4: Design Class diagram .................................................................................................... 46
Figure 4.1 Component Modeling .................................................................................................... 49
Figure 4.2 Deployment Modeling ................................................................................................... 50
Figure 4. 3Registrations Window of the system ............................................................................ 52
IV
Figure 4.4: Login window of the system…………………………………………………………………………………….53
Figure 4.5: Main window of the system………………………………………………………………………….…………54
Figure 4.6: Status window of the system……………………………………………………………………………….……55
Figure 4.7: Update window of the system…………………………………………………………………………….…….56
Figure 4.8: Uninstall Security window of the ystem………………………………………….…………….……...57
Figure 4.9: Help window of the system……………………………………………………………………………………...58
V
Acknowledgment
First of all we give praise for God of heaven, who brought us to Accomplishment our job and
who has given us success, helping us to pass safely through many difficulties Following this
we have no enough word to express our deepest gratitude and profound thanks to our advisor
Mr. Yitayal Abate for his technical guidance, constant Encouragement and specially
providing the necessary materials to complete this Documentation. We have no hesitation to
say that without his grateful help this work may have not been completed.
Last but not the least; we would like to thank all of our group members who contribute their
full effort & cooperation and our family members for their moral and financial support to
achieve all success in our life.
VI
Abbreviation and acronyms
UC Use case
UI User Interface
SDK Software Development Kit
GPS Global Positioning System
SMS Short Message Service
OS Operating System
SIM Subscriber Identity Module
API Application Programming Interface
IDE Integrated Development Environment
SQL Structured Query Language
MATS Mobile Anti-Theft System
OOA Object oriented analysis
OOD Object oriented design
UML unified modeling language
DFD data flow Modeling
DAL data access layer
DB Data base
DBMS data base management system
GSM Global system for mobile communication
OOSD object oriented system development methodology
ATS Anti-theft system
IMSI International Mobile Subscriber Identity
ABMATS Android Based Mobile Anti-Theft System
VII
Abstract
Mobile Anti-Theft system is an application based on Android used for tracing back
stolen or lost mobile. Once our system is installed onto android mobile phone and an
alternate number is fed into the software (ABMATS).
The owners SIM serial number gets registered in the file. Whenever phone is rebooted ATS is
invoked in stealth mode and verifies whether if the SIM card present in mobile phone is of
owner. If the SIM belongs to owner (registered in file), the software doesn’t do any
activity. If SIM is been changed and that SIM is not registered in the file then, ATS sends
a message to the alternative mobile number(friends / relatives number which is registered
by the owner of the android based mobile phone) in stealth mode and starts listening for
incoming SMS messages.
VIII
ANDROID BASED MOBILE ANTI-THEFT SYSTEM
CHAPTER ONE
SYSTEM PLANNING
1.0 Introduction
In today’s world cell phones play a very important role in every one’s life? It provides
multiple options like voice and video conversation, GPS tracking system, multimedia and
internet usage. Radio signals are constantly being broadcasted by cell phones and hence can
trace a lost mobile. Mobile phone tracking system technology can be deployed in any GSM
supported handsets. All cell phones constantly send signals to its nearest towers hence it is
been possible to track a lost phone accurately.
Mobile Anti- Theft System (ABMATS) is a project which is based on GPS satellite tracking
system which is been used by cars and road transport industry from years. GSM phone
tracking is likely to show the radius in which the phone is located but not the exact place and
even accuracy depends on factors like network coverage, landscape and weather conditions
also. When we couple GPS with Google maps the postal address of the lost mobile can be
found accurately [1].
1.1 Background
With the increasing of the mobile thefts, many tend to build interactive application for the
purpose of recover the lost mobile phone. But as the mobile technology developed, mobile
based application became increasingly popular among the people. Mobile phones are now
mini-computers which senses the environment through which they travel they gather and
generate data which can be Easley attached and abused yielding more intelligent aware
system. Newer mobile applications are leveraging the popularity of the social web revolution
and in particular system in which encourage users to generate and share content online to
enhance social mobile application.
Although there are many applications developed to recover the lost smart mobile phone in the
world but there is no any applications which work in smart phone which has Android OS
which doesn’t support GPS.
DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 1

1.2 Statement of the Problem
Android Baseed Mobile anti theft system is a project which helps us to recover the lost
smart phone.It consists of an Android client application which will automatically sendSMS.
when SIM cardis changed. Position tracker works on GPS (Global Positioning System) .
Even if a number of existing Mobile anti thef tandroid application are available in the world
they are not working in the smart phone which their android OS not support GPS.
1.2.1 Problem Definition

When the mobile user loses his mobile phone, in Ethiopia as well as in many parts of
world the mechanism to recover the mobile phone is difficult. Here in we propose to
develop a system which is autonomous and intimates with the owner via SMS when it
detects SIM change.
1.2.2 Problem Explanation

As soon as the thief steals the mobile phone he tries to change the SIM card. This means he
has to switch off the phone and change it then reboot it. On boot completion the system has
to detect SIM card change and intimate the owner (relative) about it. When the
relative receives SMS intimating him about the SIM change he precedes with further
action whether to inform law enforcement authorities or extract the location of the
mobile where it is present currently.
1.3 Motivation
Almost every owner of a costly mobile handset fears the nightmare of losing his
mobile phone. We have come across many middle class people losing costly mobiles
and unable to get back the same even with the help of police officers And in Ethiopia
there is no system in place to help such people.
1.4 Objectives of the project
Mobile anti-theft system is a project which helps us to track the location of the lost smart
phones. It consists of Android client application which will automatically send SMS
when SIM card is changed. Position tracker works on GPS (Global Positioning System).
1.4.1General Objective
The general objective of this project is to recover stolen or lost smart mobile phones.

1.4.2 Specific objective
Studying and analyzing the existing system.

Identifying problems of the Existing System.
Specifying Functional and Non-Functional requirements of the proposed System
Analysis the proposed System.
Design the proposed System
Design a user Interface for the proposed system.
Developing Registration sub system.
Developing SMS sending subsystem.
Developing location tracking subsystem using Google map.
Implementing the proposed system.
Testing the proposed system.
1.5 Scope
Even if there are many people’s that require information about the thieves of their smart
phone in the world, The scope of the project is to model and design an application for most
well-known smart phones which support Google android operating system.
Owner can view detail from database
Owner can add uninstall security
Owner can change status of the system
Owner can register detail to database
Relative can retrieve GPS co-ordinate from Google map
System Send SMS to relative automatically
Limitation:
It depends on smart phones which support Google Android OS.

1.6 Significant of the project

Since throughout the world even in our country Ethiopia there are a huge number of smart
phone users and this huge number of smart phone users are suffer by thieves. Then in order to
overcome this system enables smart phone users:-
To track the location of the lost android mobiles phone

To recover stolen or lost smart mobile phones.
To reduce the time and cost of finding that they spent to get lost smart phone.
1.7 Feasibility study of the new system

The feasibility study is the preliminary study that determines whether a proposed system
project is financially ,technically and operationally viable .The alternative analysis usually
include as part of the feasibility study, identifies viable alternatives for the system design and
development.
1.7.1 Economic feasibility

Since this type of Application’s are new in our country the people acceptance toward this
system will be high and also there will be very less computation in the market due to this
reason's and other causes the project benefits will outweigh the expected cost.
1.7.2 Operational feasibility

The new system will solve the problems of the owner of smart mobile phone .This
application will be used by all types of users without further introduction about its
functionality.
1.8Methodology
Methodology describes how the project team is going to implement the proposed system. In
order to do that first of all the project team have identified the main parts of the system
basically the project will be on developing a suitable mobile anti-theft system for the owner
of smart phone. And In order to do that we use the following methods.
1.8.1 Fact finding Techniques

The Method and techniques used to analyze the requirements to develop the applications and
designing electronic system includes, consulting the police office of Addis Ababa and
DebreBerhan, document analysis and practical observation these methods will help us to
gather the required data, to analyze our project

1.8.2 System Analysis and Design Techniques

In this project the team will use object oriented system development methodology (OOSD)
and it has two phases.
Object Oriented Analysis (OOA)

During this phase the team used to model the function of the system (use case modeling), find
and identify the business objects, organize the objects and identify the relationship between
them and finally model the behavior of the objects.
Object Oriented Design (OOD)

During this phase the team uses rational rose software to refine the use case model, and to
reflect the implantation environment, model object interactions and behavior that support the
use case scenario and finally update object model to reflect the implementation environment.
1.8.3 Tools and technologies

In this section we have described the tools and technology that we are going to use for
developing our proposed application.
Tools
The programming tools that the project concentrates are the following:
Software requirements:
Android SDK
ADT Plug-in
Eclipse [see Appendix A]
MS word 2007: for documentation and MS power point for presentation.
Paint: for editing
Window 7 Operating system
Edraw, MS Visio, Visual paradigm and Rational Rose.
Hardware requirements:
Printer: for printing document
Paper, pencil, pen, computer, projector, etc.

Technologies
Android SDK: It includes a mobile device emulator, a virtual device emulator that runs
directly on computer. With the help of this emulator we will prototype, develop and test our
application without having a physical device (when one was not available) [2]
1.9Resources
Based on the project plan above this project will need the following recourse's to meet our
objective. If fewer resources are available, the plan must be changed accordingly.
Expertise from mobile application android system developers this is crucial because
the whole application and project will relay on it. The amount of information we gather
will have direct effect on the application.
Time must be spent on studying how android application will work, UI design,
coding/implementation and reporting.
User: the project will need some user/friends to test our application and receive their
feedback to evaluate the overall of project quality in the end.
Hardware the project development must be based on a real Android phone so that the
scenario can be simulated, design and implementation can be better tested [1].
1.10 Risk
The main risks that we are going to face are:-
Difficulties for us to build an application for an Android phone because our lack of
knowledge and coding experience for a mobile. We will certainly make mistakes and
following the philosophy of learning by doing. We will address the issue by devoting
more time on study of android programming.
Our lack of knowledge about android system.
Lack of resources about mobile applications in general in this university.
Power fluctuation problem.
Damage on the computers that we work on.
Risk Assessment & Management

The project cannot be developed as it is initially planned. This is due to the fact that risk may
happen in the process of project development. We assume the following risks can encounter:

The unavailability of data source (information gathering) on time may extend the
project completion time. We managed this problem using different methodology.
Damage on the computers that we work on, it is managed by using backup.
Lack of reference books. We managed this problem by using other methods
such as internet.
Shortage of Time. We managed such problem by using additional time from
our rest time.
Virus can attack our project. We used updated antivirus to manage this
problem.
Power fluctuation problem. It is using laptop that have high power pack ups
are used.
Team organization
The project team composed of 5 members, one team leader, one deputy leader, one
secretary, and 2 members .Problem solving is group activity. Decision on problem and
approach are made by group agreement, which is much better than individual decision.

CHAPTER TWO
SYSTEM ANALYSIS
2.1 Introduction
It is necessary to know the existing system of mobile anti-theft system or service to develop a
better system .The target area of this project is to develop a system that help the owner of
smart phone to recover his/her smart mobile phone by providing certain information about
the thieves. The system that we are going to develop is used for all smart phone users around
the world. In this section we are going to discusses about the existing system of mobile anti-
theft system in the world, the system that we are going to develop, functional requirements
for our system and also non-functional requirements about our system.
2.2 Existing system description

Even if a number of mobile anti-theft android application are available in the world they are
not working in the smart phone which their android OS not support GPS.
2.3 Problems of the existing systems

There are various problems that the user faced while using the current system and some of the
problems that the user have faced are listed below:
Time consuming
When the SIM card changes the application require more time to get the GPS location of the
lost mobile phone due to connection and other problem.
GPS dependent
Until GPS is work properly the current system is doesn’t send any information about the
thieves even if the lost mobile is rebooted.
2.4 The proposed system

The system that we are going to develop can solve different problems that we mention in the
existing system. Mobile Anti-Theft System is project which helps us to track the location of
the mobiles. It consists of an android client application which will automatically send an
SMS when SIM card is changed and rebooted. The position tracker works on GPS (Global
Positioning System).

2.4.1 Functional Requirements
Input requirement is a Mobile with GPS facility. It should be a Google Android OS

mobile. The mobile will have software installed in it. On SIM change it shall alert the
alternate number via SMS.
System Send SMS to relative when the phone is rebooted and SIM card is changed
System should not uninstall when uninstall security is ACTIVATED.
System should not send SMS when the system status OFF.
2.4.2 Nonfunctional requirement

These constraints are the user visible aspect of the system.
That includes:
Performance Requirements:
Application must respond within 5 seconds excluding GPS enabling time. The user must use
the required option to get the information of the users.
Portability:
The project is built using JAVA [see Appendix A] and can be run on any device which uses
android OS.
Maintainability:
Since we are using JAVA software to support our application no maintenance is very easy
and economical.
2.5 Overview of Data Requirements

MATS has to be feed with IMSI number , alternate phone number and password so that
whenever the phone is rebooted it checks with the one present in the file which present.
If it’s different from the actual present then number of steps involved.
2.6 Use Case Modeling

The Use Case Modeling is the first that designers will work with when starting a project.
This Modeling allows for the specification of high level user goals that the system must carry
out A use case Modeling is an excellent way to communicate to management, customers, and
other non-development people what a system will do when it is completed [7].
Purpose:
Purpose the main purpose of a use case Modeling is to show who interacts with our system,
and the main goals they achieve with it. Its purpose is to present a graphical overview of the
functionality provided by a system in terms of actors, their goals (represented as use cases),
and any dependencies between those use cases and to document the interaction between the
users and the system using supporting use case descriptions. Use case Modeling s are used to
show the behavior of the system we are developing [3]
Figure 2.1 Use case Modeling
2.6.1 Use case description
Use case name: - Login
Identification: - UC01.
Description: - This use case describes how the Owner logs into the android based mobile
Anti-thief System.
Actor: - Owner.
Precondition: none.

Post condition: - If the use case was successful, the actor is now logged into the system. If
not the system state is unchanged.
Basic Flow
This use case starts when an actor wishes to log into the mobile Anti-thief System.
1. The owner opens the application

2. The system requests that the actor to enter his/her password and user name.
3. The actor enters his/her password and user name.
4. The system checks the entered password and username and logs the actor into the
system.
5. The main window will display.
6. End of use case.
Alternative Flows
Invalid Name/Password
If in the Basic Flow the actor enters an invalid password; the system displays an error
message. The actor can choose to either return to the beginning of the Basic Flow or cancel
the login, at which point the use case ends.
Use case name: -Register detail in the database
Description: - The Owner has the ability to join the system.
Actor: - Owner
Preconditions
1. Owner has a relative phone number
Post conditions
1. The system active to send an SMS

Basic Flow
This use case starts when an actor wishes to open mobile Anti-thief System for the first time.

1. The owner opens the application
2. The owner is shown a screen where the owner can register the password, username and
the relative phone number of the application
3. The owner must add his password (mandatory), username (mandatory) and a relative
phone number (mandatory)
4. The owner presses "OK"
5. The system active to send an SMS whenever the phone is rebooted
6. End of use case.
Use case name: -Re-register detail in the database
Description: - to update existing information.
Actor: - Owner.
Precondition: - The owner must have all the necessary information to be updated and login
in to the application installed in their mobile phone.
Post condition: - The information on the data base will be updated.
Basic Flow
1. The owner opens the application.

2. The login window will be displayed.
3. The owner enters the correct password and username.
4. Main window will be displayed.
5. The click the update button.
6. The system displays update window.
7. The user updated the information and click update button.
8. The Information in the database will be updated.
9. End of use case.
Use case name: - Retrieve detail from database.

Description: - Owner can view information from database.
Actor: - Owner.
Precondition: - the owner must have login in to the application installed in their mobile
phones.
Post condition: - The owner accesses the information from the database.
Basic Flow
1. The owner opens the application.

2. The login window will be displayed.
3. The owner enters the correct password and username.
5. The click the view button.
6. The system displays view window.
7. The owner views the information and click ok button.
9. End of use case
Use case name: - Receive SMS.
Description: - Owner can view information from database.
Actor: - Relative.
Precondition: - The phone must have the application installed in it and rebooted.
Post condition: - The relative get the GPS co-ordinate, SIM serial number and phone
number.
Basic Flow
1. The SIM card is change by thief or other person.

2. The thief or owner will reboot the phone.
3. The system automatically sends an SMS to the alternative number.
4. End of use case.
Use case name: - Retrieve GPS co-ordinate.

Description: - Relative can view the location of the lost mobile phone.
Actor: - Relative.
Precondition: - The application must send the SMS when the SIM card changed.
Post condition: - The alternative can tell the location of lost mobile phone to the owner so
they can recover that of lost mobile phone.
Basic Flow
1. The SIM card is change by thief or other person.

2. The thief or owner will reboot the phone.
3. The system automatically sends an SMS to the alternative number.
4. The alternative gets the GPS co-ordinate, SIM serial number and phone number
5. The alternative enter the latitude and longitude into the Google map
6. The Google map will generate the current location of the lost mobile phone.
7. End of use case.
Use case name: - Change SIM and phone reboot.
Description: - The thief changes the SIM card of his phone when he\she stole the phone.
Actor: - Owner and Thief.
Precondition: - none.
Post condition: - The system initiated to send SMS.
Basic Flow
1. The SIM card will be changed by thief or owner.

2. The system initiates to send SMS.
3. End of use case.

2.7 Analysis of Class Modeling

Class Modeling shows the static structure of data and the operations that act on the data, i.e. it
shows the static structure of an object-oriented model the object class, their internal structure
and the relationships in which they participate [7].
Classes modeling describe the structure of the system in terms of classes and objects. Classes
are abstractions that specify the attributes and behavior of a set of objects. Objects are entities
that encapsulate state and behavior. Each object has an identity.
In software engineering, a class Modeling in the Unified Modeling Language (UML) is a

type of static structure Modeling that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among
objects.
In the Modeling, classes are represented with boxes which contain three parts:
• The top part contains the name of the class

• The middle part contains the attributes of the class
• The bottom part gives the methods or operations the class can take or undertake
Figure 2.2: Analysis class modeling for mobile Anti-theft system

2.8 Sequence Modeling
Sequence Modeling is dynamic model of use cases, showing the interaction among classes
during a specified time period. Sequences modeling graphically document the use case by
showing the classes, the messages, & the timing of the messages [7].
The interaction proceeds from top to bottom a vertical timeline, while the horizontal arrows
represent messages from one object to another.
Sequence Modeling is used to model the logic contained in usage scenarios. A usage scenario
is the description of the way a potential use case is used.
A sequence modeling in our system is used to formalize the behavior of the system and to
visualize the communication among objects. It helped us to identify additional objects and
participate in the use case. This phase of the document ties use cases with objects and shows
the behavior of a use case is distributed among its participating objects.
Sequence Modeling for Login use case
Application LginWindow MainWindow Database

Owner
Sequence
Diagram for
1.Open()
Login
usecase#1
2.Display login window()
3.Enter username and password
4.clickOk()
5.check()
6.Display()
Figure 2.3: Login Sequence Modeling

Sequence Modeling for Register detail in the database
Sequence
diagram for Application RegistrationWindow Registration MainWindow Database
Register detail in Owner
Controller
the database
use case 1.open()
2.Display()
3.FillForm
4.Ok() 5.Validate
6.continue()
Display()
Figure 2.4: Register detail in the database Sequence Modeling

Sequence Modeling for Re-registration use case
Application Login Main Window Update Update Control Database

Sequence : Owner
Window Window
Diagrams for Re-
register usecase 1. Open()
#3
2.Display()
3.Enter Username and password
4. Ok()
5. Check()
6. Display Window()
7. Click Update()
8. Display Update Window()
9. Fill Fields()
10. Ok()
11. Validate Phone Number()
12. continue()
13.Display update Notification()
Figure 2.5: Re-register detail in the database Sequence Modeling

Sequence Modeling for Retrieve detail from database
III) sequence
diagrams for Application Login window View window Main window Database
Owner
Retri...
1.Open()
2.Display()
3.Enter username and password
4.Ok()
5.Check()
6.Display()
7.ClikView Button
8.Ok()
9.Display()
Figure 2.6: Retrieve detail from database Sequence Modeling

Sequence Modeling to Receive SMS use case
Figure 2.7: Receive SMS Sequence Modeling

Sequence Modeling for Retrieve GPS co-ordinate
Figure 2.8: Retrieve GPS co-ordinate Sequence Modeling

2.9Activity Modeling
Is one of the components of UML .It highlights the activities performed in the system? Each
activity is represented by a narrow and more oval shape. The processing with in an activity
goes to completion and then an automatic transition to the next activity occurs an arrow
represents the transition from one activity to the next. The starting point of an activity
Modeling is represented by a filled-in circle and an end point represented by bull’s eye [7].
Activity Modeling is used to document the logic of a single operation/method, a single use
case, or flow of logic of business operation. In many ways activity Modeling are the object
oriented equivalent of flow charts and data flow Modeling s (DFD) from structured

development. This part of the project documentation consists of an activity Modeling that
shows the flow of action in main use cases [8].
Figure 2.9: Activity modeling for login

Figure 2.10: Activity Modeling for Register detail in the database

Figure 2.11: Activity Modeling for Re-register details in the database
Figure 2.12: Activity Modeling for Retrieve detail from database

Figure 2.13: Activity Modeling for Receive SMS
2.10 Collaboration Modeling

Like sequence Modeling, the collaboration Modeling shows how objects interact. It shows
the objects along with the messages that travel from one to another. The sequence Modeling
emphasizes the time ordering of interaction.
But, the collaboration Modeling emphasizes the context and the overall organization of the
objects that interact. It shows the message the object sends in addition to the association
among objects. Moreover it arranged according to space whereas sequence Modeling is
arranged according to time. To represent a message, you draw an arrow near the association
line between two objects. The arrow points to the receiving object. A label near the arrow
shows what the message is. The message typically tells the receiving object to execute one of
its operations.

1: 1.Open()
Applicati
on
3: 3.Enter username and password

: Owner
5: 5.check()
2: 2.Display login window()
4: 4.clickOk()
LginWind
Database ow
6: 6.Display()
MainWin
dow
Figure 2.14: Login Collaboration Modeling
3: 3.FillForm
RegistrationWi
ndow
2: 2.Display()
: owner
1:
7: Display()
4: 4.Ok()
MainWind
ow
Applicati
on
5: 5.Validate
6: 6.continue()
Registration Database
Controller
Figure 2.15: Register detail in the database Collaboration Modeling

Applicati
on
1: 1. Open()
Login
3: 3.Enter Username and password
Window
2: 2.Display()
9: 9. Fill Fields()
: Owner
8: 8. Display Update Window()

Update
Window
6: 6. Display Window()
10: 10. Ok()
7: 7. Click Update() 4: 4. Ok()
13: 13.Display update Notification()
11: 11. Validate Phone Number()

5: 5. Check()
Main
Window
Update
Control
Database
12: 12. continue()
Figure 2.16: Re-register detail in the database Collaboration Modeling
Applicati
1: 1.Open() on
3: 3.Enter username and password
Login
window
2: 2.Display()
: Owner
7: 7.ClikView Button
8: 8.Ok()
4: 4.Ok()
6: 6.Display()
9: 9.Display()
View
window
5: 5.Check()
Main Database
window
Figure 2.17: Retrieve detail from database Collaboration Modeling

3: compare sim serial number()
1: reboot mobile phone()

Mobile Applicati
phone on
4: Send SMS()
: :Relative 2: select the alternative phone number()
Database
Figure 2.18: Receive SMS Collaboration Modeling
Mobile
phone Database
1: reboot mobile phone() 2: select the relative phone number()
3: compare sim serial number()
Applicati
on
5: Enter latitude and longitude()

Google
4: Send SMS() map
6: Retrive mobile location()
: :Relative
Figure 2.19: Retrieve GPS co-ordinate Collaboration Modeling

2.11 State chart Modeling

State chart Modeling is one of the five UML Modeling s used to model dynamic nature of a
system. They define different states of an object during its lifetime. And these states are
changed by events. So State chart Modeling s are useful to model reactive systems, Reactive
systems can be defined as a system that responds to external or internal events [6].
State chart Modeling describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
So the most important purpose of State chart Modeling is to model life time of an object from
creation to termination [7].
State chart Modeling are also used for forward and reverse engineering of a system. But the
main purpose is to model reactive system.
Following are the main purposes of using State chart Modeling:
• To model dynamic aspect of a system.

• To model life time of a reactive system.
• To describe different states of an object during its life time.
• To define a state machine to model states of an object.
invalid password or username
Idle Activate Enter username

and password
Initial State
Valid
Login
succsses
Complet State
Figure 2.20: Login state chart Modeling

Idle Activate Login Choose Fil The Update

option Window
Initial State
UNnormal Exit Normal Exit
Complet State
Figure 2.21: Re-register detail in the database state chart Modeling
Idle Activate Fill Registration Validate

Window
Initial State
UnNormal Exit
Confrim
Registration
Normal Exit
Complet State
Figure 2.22: Register detail in the database state chart Modeling

CHAPTER THREE
SYSTEM DESIGN
3.1 Introduction
System design is the solution to the creation of a new system. This phase is composed of
several systems. This phase focuses on the detailed implementation of the feasible system. It
emphasis on translating design specifications to performance specification is system design.
System design has two phases of development logical and physical design.
During logical design phase the analyst describes inputs (sources), outputs (destinations),
databases (data stores) and procedures (data flows) all in a format that meats the user’s
requirements. The analyst also specifies the user needs and at a level that virtually determines
the information flow into and out of the system and the data resources. Here the logical
design is done through data flow diagram s and database design [5].
The physical design is followed by physical design or coding. Physical design produces the
working system by defining the design specifications, which tell the programmers exactly
what the candidate system must do. The programmers write the necessary programs that
accept input from the user, perform necessary processing on accepted data through call and
produce the required report on a hard copy or display it on the screen.
3.2 Design goals and objectives

The objectives of designing are to model a system with high quality. Implementing of high
quality system depends on the nature of the design created by the designer .If one wants to
make changes to the system after it has been put in to operation depends on the quality of the
system design. So if the system is designed perfectly, it will be easy to make changes to it.
The goal of the system design is to manage complexity by dividing the system in to
manageable pieces.

Some of the goals are listed below.
Response time: It has less response time. That is active in short period of time.
Modifiability: The system should be modifiable to modify different services
depending on the need of the user.
Flexibility: The system should be changeable to suit new condition or situation.
Efficiency: The system must do what it supposed to do efficiently without the
problem.
Availability: Discusses the ability of an application to be present and ready for use
Portability: the system is portable from one cell phone platform in to other platforms
easily, i.e. the system primarily designed to be used in many plat forms.
End User Criteria: It has good user friendly relation and simple button term.
Security: our system is secure due to having strong password which contains letters,
numbers and special characters with user name.
3.3 System architecture
3.3.1 Architectural Design
3-Tier architecture is also called layered architecture. Some people called it n-tier
architecture. Layer architectures are essentially objects and work in object oriented
environment. 3-tier architecture is a very well-known architecture in the world of software
development, it doesn't matter whether you are developing web based application or desktop
based, it is the best architecture to use.
3-Tier architecture consists of

1) UI or Presentation Layer
2) Business Access Layer or Business Logic Layer
3) Data Access Layer
Presentation Layer:
Presentation layer consists of pages like .java or desktop based form where data is presented
to users or getting input from users.

Business Logic layer or Business Access Layer
Business logic layer contains all of the business logic. Its responsibility is to validate the
business rules of the component and communicating with the Data Access Layer. Business
Logic Layer is the class in which we write functions that get data from Presentation Layer
and send that data to database through Data Access Layer.
Data Access Layer:
Data Access Layer is also the class that contains methods to enable business logic layer to
connect the data and perform desired actions. These desired actions can be selecting,
inserting, updating and deleting the data. DAL accepts the data from BAL and sends it to the
database or DAL gets the data from the database and sends it to the business layer. In short,
its responsibility is to communicate with the backend structure.
Figure 3.1: Illustration of 3-Tier Architecture with diagram

Figure 3.2: System Architecture
3.4 System Decomposition
Generally speaking, Decomposition is the process of breaking complex entities (processes,

technology, business problems, business needs) into smaller sub-parts, and then breaking
those smaller parts down even more, until the complex entity has been broken down into
more discreet components with a more understandable structure.
It is a common analytical technique, and business analysts use it frequently. Among the
things business analysts commonly decompose are:
• Systems – into processes, functions, rules, and decisions

• Processes – into steps, actors, and decisions
• Goals – into sub-goals and objectives
• Requirements – into functional requirements, non-functional requirements, business rules,
decisions, and constraints
Decomposition is perhaps the single most-practiced technique in business analysis. A

common output of decomposition is a hierarchical Modeling of some sort, such as the

Functional Decomposition Modeling. This is similar to a number of other Business Analysis

techniques, including Organizational Analysis, Feature Tree’s, Work Breakdown Structures,
and Mind Mapping. The key difference between decomposition and those other analysis
techniques is that the sub-components (the “children”) of something that is decomposed
should completely describe the component (the “parent”) that has been decomposed. This
may not be true of something like an Org Chart (which may not show all sub-units).
Each subsystem has its own function and there is also communication among them to
exchange information. The system is decomposed according to the specialized task it
performs to ensure high coherence. The level of coupling is relatively low because the
interactions between subsystems are only exchange of data
SMS Sending subsystem

This subsystem is responsible for providing the process of sending information about the
Thief to the Owners Relative (target environment).
Registration subsystem
This subsystem deals with the registration facilities of the system. It involves the information
that registers on the phone the Owner’s Relative about the phone details (phone No, name…).
There for this subsystem contains all information that we need to register to access thief’s
information.
Security subsystem
This subsystem controls the thief of the smart phone when he/she try to uninstall the
application.

Registration
Register detail in the database
Login
Re-register detail in the database
SMS Sending
Change SIM and phone reboot

DB
Receive SMS
Retrieve GPS co-ordinate
Security
Login
Add uninstall security
Figure 3.3: System Decomposition

3.5 Class mapping

Class modeling used to describe the structure of this system. Classes are abstractions that
specify the common structure and behavior of a set of objects in the new system. In this
modeling the team’s members have design the system in terms of objects, classes, attributes,
operations and their association.
Figure 3.4: Design class Modeling

Description of class mapping
Class Name: SIM exchange Service
Attributes:
Filename:
It Identify name of the file
It has string data type
It has max-size 45
Mobile no
It has unique value
Class Name: login
Attributes:
User Name

It has max-size 25
It Identify username of the application
Password
It has max-size 32
It can maintain Numbers, text digits, special characters etc.
Class Name: Registration
Attributes:
User name
It Identify name of use
It Identify username of the application
Password
It has max-size 32
It can maintain Numbers, text digits, special characters etc.
Relative phone No
It has unique phone No
Max-size 10
Class Name: GPS tracker
Attributes
Location
It describes the place where the lost phone found
It has Boolean data type
It depends on Google map
It shows the latitude & longitude of the phone position
Class Name: Boot complete
Attributes:

SIM serial number

It enables to compare serials within the system and
It decides sending SMS or not
3.6 Data base design

Database Design is the database structure that will be used as plan to Store and manage the
data. The database management system (DBMS) is the software used to implement a
database design. Modern database and applications development software is so easy to use
that many people can quickly learn to implement a simple database and Develop simple
applications within a week or so, without giving design [5].
Much thought, as data and reporting requirements become more complex, those same people
will simply and produce the required data by incorrectly adding more columns of tables to the
database.
Table 3.1: Data Base Design

CHAPTER FOUR
IMPLEMENTATION DELIVERABLE OF THE NEW
SYSTEM
4.1 Introduction
Implementation refers to the Coding of the all documents gathered starting from
requirement analysis to Design phase. So now the team is in a position of converting
all documents gathered and designed into the code so that the system will be
implemented for the user to be used for the purpose it developed. To implement it the
user must have smart phones which have an android operating system.
4.2 Component diagram

The component Modeling s describe software components and their dependencies to each
others. Which includes layout [7], Interfce,ports, conectors and usage dependencies etc.[6]
In this Modeling components of the system will be wired showing that there is relation
among components, management of the system, database and operations performed on
databases such security issue. This in some extent shows which component or objects will be
accessed by whom and what type of security infrastructures it is using. The Modeling is
simulated below.

Figure 4.1: Component Modeling
4.3 Deployment diagram

A Deployment Modeling shows the conFigureuration of run-time processing elements and
the software components, processes, and objects [6]. Deployment modeling shows the
physical conFigureurations of software and hardware.
Android is a software stack for mobile devices that includes an operating system,
middleware and key applications. Android relies on Linux OS for core system services such
as security, memory management, process management, network stack, and driver model.
The Linux kernel also acts as an abstraction layer between the hardware and the rest of the
software stack [9].
Android applications are written in Java. Android SDK tools compile and package the code
along with any required data and resource files into Android application archive file having
.apk suffix. The .apk file represents one Android application to be deployed to the Android-
enabled mobile devices [1].

Figure 4.2: Deployment Modeling
4.4user interface design

User interface (UI) prototyping is an iterative analysis technique in which users are actively
involved in the mocking-up of the UI for a system. UI prototypes have several purposes [4].
As an analysis artifact that enables you to explore the problem space with your
stakeholders.
As a requirements artifact to initially envision the system.
As a design artifact that enables you to explore the solution space of your system.
A vehicle for you to communicate the possible UI design(s) of your system.
A potential foundation from which to continue developing the system (if you intend to
throw the prototype away and start over from scratch then you don’t need to invest the
time writing quality code for your prototype) the following Figure 3.4 shows
interface prototype for our system .
In this system users will communicate with the system through the following user interfaces.

Registration Window: This form appears on the first form of the application in which the system
deployed is opened two buttons named save and cancel.
Figure 4.3 Registration Window of the system.

Figure 4.4 Login Window of the system.

Figure 4.5 Main Window of the system.

Figure 4.6 Status Window of the system.

Figure 4.7 Update Window of the system.

Figure 4.8 Uninstall Security Window of the system.

Figure 4.9 Help Window of the system.

CHAPTER FIVE
Prototype Development
Prototype development can be defined it is the sample code of the given project.
These are some of the sample codes that we have done.
Java class for Registration window.
Package com.example.sim_card_tracking_ant_theft;
import java.io.FileOutputStream;
import com.example.sim_card_tracking_ant_theft.VivzDatabaseAdapter.VivzHelper;
import android.app.Activity;
import android.content.Context;
import android.content.Intent;
import android.graphics.Color;
import android.os.Bundle;
import android.telephony.SmsManager;
import android.telephony.TelephonyManager;
import android.view.Menu;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.Toast;
public class MainActivity extends Activity {
Intent i=null;
String FILENAME = "old_file.txt";
int simstatus;
String simNo;

Button btn1,btn2;
String pass11;
EditText txt1,txt2,txt3,txt4,txt5,pass;
VivzDatabaseAdapter vivzhelper;
VivzHelper v;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
v=new VivzHelper(this);
v.getWritableDatabase();
vivzhelper=new VivzDatabaseAdapter(this);
String s2= vivzhelper.getAllData();
if(s2==null||s2=="")
TelephonyManager tManager = (TelephonyManager)

getSystemService(Context.TELEPHONY_SERVICE);
simstatus=tManager.getSimState();
if (simstatus != TelephonyManager.SIM_STATE_ABSENT)
System.out.println("--------SIM Present:" + simstatus);
simNo = tManager.getSimSerialNumber();//getSimSerialNumber();
FileOutputStream fos;
try {
fos = openFileOutput(FILENAME, Context.MODE_PRIVATE);
fos.write(simNo.getBytes());
System.out.println("---------Data written to files is:"

+ simNo);
fos.close();
} catch (Exception e) {
e.printStackTrace();
setContentView(R.layout.activity_boot_complete);
else
setContentView(R.layout.register);
txt1=(EditText)findViewById(R.id.name);
txt2=(EditText)findViewById(R.id.phone1);
txt3=(EditText)findViewById(R.id.phone2);
txt4=(EditText)findViewById(R.id.password);
txt5=(EditText)findViewById(R.id.password1);
public void insert(View v)
String owner=txt1.getText().toString();
String pno1=txt2.getText().toString();
String pno2=txt3.getText().toString();
String pass=txt4.getText().toString();
String pass1=txt5.getText().toString();

if(owner==null||owner==""||!owner.matches("[A-Za-z]+"))
txt1.setText("");
txt1.setFocusable(true);
txt1.setBackgroundColor(Color.RED);
show("Please Enter Correct Name.");
else if(pno1==null||pno1==""||pno1.length()<10||!pno1.matches("[0-
9]+"))
txt2.setText("");
show("Please Enter Valid mobile number with country code..");
else if(pno2==null||pno2==""||!pno2.matches("[0-9]+"))
txt3.setText("");
show("Please Enter Valid mobile number with country code.");
else if(pass==null||pass==""||pass.length()<6)

txt4.setText("");
show("Please Enter Strong Password.");
else if(!(pass.equals(pass1)))
txt4.setText("");
txt5.setText("");
show("Password not match");
else
long id = vivzhelper.insertData(owner, pno1, pno2, pass);
if(id<0)
Message.message(this, "Unsuccessful");
else
Message.message(this, "Sucssesful insert a Row");
txt1.setText("");
txt2.setText("");

txt3.setText("");
txt4.setText("");
txt5.setText("");
i=new Intent(this,Main.class);
startActivity(i);
public void show(String str)
Toast.makeText(this, str, Toast.LENGTH_LONG).show();
public void getAll(View v)
System.exit(1);
public void login(View v)
pass=(EditText)findViewById(R.id.passwordLogin);
pass11=pass.getText().toString();
String sol= vivzhelper.getpassword();
if(pass11.equals(sol))
i=new Intent(this,Main.class);

startActivity(i);
else
Message.message(this, "Password Not Correct");
public void recover(View v)
try {
String s2= vivzhelper.getphone1().toString();
String s3=vivzhelper.getpassword().toString();
SmsManagersmsManager = SmsManager.getDefault();
smsManager.sendTextMessage(s2, null, s3, null, null);
Toast.makeText(getApplicationContext(), "SMS Sent!",
Toast.LENGTH_LONG).show();
catch (Exception e) {
Toast.makeText(getApplicationContext(),
"SMS faild, please try again later!",
Toast.LENGTH_LONG).show();
e.printStackTrace();
@Override
publicbooleanonCreateOptionsMenu(Menu menu) {

// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.activity_boot_complete, menu);
return true;
Xml file for Registration window

<?xmlversion="1.0"encoding="utf-8"?>
<ScrollViewxmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:background="#000000"
>
<LinearLayout
android:id="@+id/LinearLayout1"
android:background="@drawable/images"
android:orientation="vertical"
android:padding="15dp"
android:paddingBottom="10dp"
android:paddingLeft="10dp"
android:paddingTop="10dp">
<TextView
android:id="@+id/txt1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:gravity="center"
android:text="@string/top"
android:textAppearance="?android:attr/textAppearanceLarge"
android:textColor="#ffffff"
android:textSize="24sp"
android:textStyle="normal|bold"/>
<EditText
android:id="@+id/name"
android:layout_width="280dp"
android:layout_height="50dp"
android:background="#ffffff"
android:ems="10"
android:inputType="textPersonName"
android:paddingTop="3dp"
android:focusable="true">
<requestFocus/>
</EditText>
<TextView
android:text="@string/top1"
<EditText
android:id="@+id/phone1"
android:background="#FFFFFF"
android:ems="10"
android:inputType="phone"
android:maxLength="13"
/>
<TextView
<EditText
android:id="@+id/phone2"
android:ems="10"
android:inputType="phone"
android:maxLength="13"
/>
<TextView
android:id="@+id/TextView01"

<EditText
android:id="@+id/password"
android:ems="10"
android:inputType="textPassword"
android:paddingTop="3dp"/>
<TextView
android:id="@+id/TextView02"
<EditText
android:id="@+id/password1"
android:ems="10"
android:inputType="textPassword"
<LinearLayout
android:orientation="horizontal"
android:paddingTop="10dp">
<Button
android:id="@+id/save"
android:layout_weight="2"
android:background="@drawable/save66"
android:onClick="insert"/>
<Button
android:id="@+id/cancel"
android:layout_weight="2"
android:background="@drawable/cancel"
android:onClick="getAll"
</LinearLayout>

</LinearLayout>
</ScrollView>
Java class for database
package com.example.sim_card_tracking_ant_theft;
importandroid.content.ContentValues;
import android.content.Context;
importandroid.database.Cursor;
importandroid.database.SQLException;
importandroid.database.sqlite.SQLiteDatabase;
importandroid.database.sqlite.SQLiteOpenHelper;
import android.widget.Toast;
public class VivzDatabaseAdapter {
VivzHelper helper;
String phhh,phhh1;
public VivzDatabaseAdapter(Context context){
helper=new VivzHelper(context);
public long insertData (String name,String phone1,String phone2,String pass ){
SQLiteDatabase db=helper.getWritableDatabase();
ContentValuescontentValues =new ContentValues();
/*int id1=3;
contentValues.put(VivzHelper.UID, id1);*/

contentValues.put(VivzHelper.NAME, name);
contentValues.put(VivzHelper.PHONENUMBER1, phone1);
contentValues.put(VivzHelper.PASSWORD, pass);
contentValues.put(VivzHelper.STATUS, "ON");
contentValues.put(VivzHelper.UNINISTAL_SECURITY,
"DEACTIVATE");
long id=db.insert(VivzHelper.TABLE_NAME, null, contentValues);
return id;
public String getAllData()
String[]
columon={VivzHelper.UID,VivzHelper.NAME,VivzHelper.PHONENUMBER1,Viv
zHelper.PHONENUMBER2,VivzHelper.PASSWORD,VivzHelper.STATUS,VivzHel
per.UNINISTAL_SECURITY};
Cursor cursor=db.query(VivzHelper.TABLE_NAME, columon,

VivzHelper.UID+" = '1'", null, null, null,null);
StringBuffer buffer=new StringBuffer();
while(cursor.moveToNext())
intcid=cursor.getInt(0);
String name1=cursor.getString(1);
String ph1=cursor.getString(2);
String phass=cursor.getString(4);

String status=cursor.getString(5);
String security=cursor.getString(6);
buffer.append(cid+" "+name1+" " +ph1+" "+ph2+" "+phass+" "

+status+" "+security+"\n");
returnbuffer.toString();
public String getphone1()
String[]


phhh=ph1;
returnphhh;
public String getphone2()
String[]


phhh=ph2;

returnphhh;
public String getname1()
String[]


phhh1=name1;
return phhh1;

public String getpassword()
String[]


phhh1=phass;
return phhh1;
public String status1()

String[]


phhh1=status;
return phhh1;
public String security_status()
String[]


phhh1=security;
return phhh1;
publicboolean update(String name,String phone1,String phone2,String pass )
int id=1;
String where=VivzHelper.UID+"="+id;
contentValues.put(VivzHelper.NAME, name);
contentValues.put(VivzHelper.PASSWORD, pass);
returndb.update(VivzHelper.TABLE_NAME, contentValues,
where,null )!=0;
publicintupdate_status(String cursta,String id)
contentValues.put(VivzHelper.STATUS, cursta);
String[] where={id};
int m=db.update(VivzHelper.TABLE_NAME,
contentValues,VivzHelper.UID+"=?",where);
return m;
publicintupdate_security(String cursta,String id)
contentValues.put(VivzHelper.UNINISTAL_SECURITY, cursta);
String[] where={id};
int m=db.update(VivzHelper.TABLE_NAME,
contentValues,VivzHelper.UID+"=?",where);
return m;
static class VivzHelper extends SQLiteOpenHelper{

private static final String DATABASE_NAME="ABMATSdatabase";
private static final String TABLE_NAME="ABMATStable";
private static final int DATABASE_VERSION=2;
private static final String UID="_id";
private static final String NAME="Name";
private static final String PHONENUMBER1="PhoneNo1";
private static final String PHONENUMBER2="PhoneNo2";
private static final String PASSWORD="Password";
private static final String STATUS="status";
private static final String UNINISTAL_SECURITY="u_security";
private static final String CREATE_TEBLE="CREATE TABLE

"+TABLE_NAME+" ("+UID+" INTEGER PRIMARY KEY
AUTOINCREMENT,"+NAME+" VARCHAR(15),"+PHONENUMBER1+"
VARCHAR(15),"+PHONENUMBER2+" VARCHAR(15),"+PASSWORD+"
VARCHAR(32),"+STATUS+" VARCHAR(3),"+UNINISTAL_SECURITY+"
VARCHAR(15));";
private static final String DROP_TABLE="DROP TABLE IF EXISTS

"+TABLE_NAME;
private Context context;
public VivzHelper(Context context){
super(context,DATABASE_NAME,null,DATABASE_VERSION);
this.context=context;
//Message.message(context, "Constructor Called" );
@Override
public void onCreate(SQLiteDatabase db) {

// TODO Auto-generated method stub
try {
db.execSQL(CREATE_TEBLE);
//Message.message(context, "onCreate Called" );
} catch (SQLException e) {
// TODO Auto-generated catch block
Message.message(context, "" +e);
@Override
public void onUpgrade(SQLiteDatabasedb, intoldv, int newv) {
// TODO Auto-generated method stub
try {
Message.message(context, "onUpgrade Called" );
db.execSQL(DROP_TABLE);
onCreate(db);
} catch (SQLException e) {
// TODO Auto-generated catch block
Message.message(context, "" +e);

CHAPTER SIX
Testing
6.1 Introduction
System Testing
Software testing is the process of evaluation a software item to detect differences between
given input and expected output. Also to assess the feature of A software item. Testing
assesses the quality of the product. Software testing is a process that should be done during
the development process. In other words software testing is a verification and validation
process [10].
Verification
Verification is the process to make sure the product satisfies the conditions imposed at the
start of the development phase. In other words, to make sure the product behaves the way we
want it to [10].
Validation
Validation is the process to make sure the product satisfies the specified requirements at the
end of the development phase. In other words, to make sure the product is built as per
customer requirements [10].
Basics of System testing
There are two basics of software testing: black box testing and white box testing.
Black box Testing
Black box testing is a testing technique that ignores the internal mechanism of the system and
focuses on the output generated against any input and execution of the system. It is also
called functional testing [10].

White box Testing
White box testing is a testing technique that takes into account the internal mechanism of a
system. It is also called structural testing and glass box testing.
Black box testing is often used for validation and white box testing is often used for
verification [10]. There are many types of testing like:
Unit Testing
Unit testing is the testing of an individual unit or group of related units. It falls under the class
of white box testing. It is often done by the programmer to test that the unit he/she has
implemented is producing expected output against given input [10].
Integration Testing
Integration testing is testing in which a group of components are combined to produce output.
Also, the interaction between software and hardware is tested in integration testing if
software and hardware components have any relation. It may fall under both white box
testing and black box testing [10].
Functional Testing
Functional testing is the testing to ensure that the specified functionality required in the
system requirements works. It falls under the class of black box testing [10].
System Testing
System testing is the testing to ensure that by putting the software in different environments
(e.g., Operating Systems) it still works. System testing is done with full system
implementation and environment. It falls under the class of black box testing [10].
Performance Testing
Performance testing is the testing to assess the speed and effectiveness of the system and to
make sure it is generating results within a specified time as in performance requirements. It
falls under the class of black box testing [10].

Usability Testing
Usability testing is performed to the perspective of the client, to evaluate how the GUI is
user-friendly? How easily can the client learn? After learning how to use, how proficiently
can the client perform? How pleasing is it to use its design? This falls under the class of black
box testing [10].
Acceptance Testing
Acceptance testing is often done by the customer to ensure that the delivered product meets
the requirements and works as the customer expected. It falls under the class of black box
testing [10].
Finally we conclude that black box testing is more appropriate than white box testing,
because black box testing takes an external perspective of the test object to derive test cases.
These tests can be functional or non-functional, though usually functional. The test designer
selects valid and invalid input and determines the correct output. There is no knowledge of
the test object's internal structure.

CHAPTER SEVEN
Conclusions and recommendation
7.1 Conclusions
This is a system development project with two phases; the first phase deals with the analysis
phase and the next phase addresses the Design phase. As the end of the first phase, we need
to review that we have covered in accordance with what we have planned at the beginning.
We began our work by identifying the significance of creating a mobile application that can
guide user to recover their lost android smart phone. This involved defining the system
development methodology, identifying resource and cost requirements, and setting the
deliverable and scheduled for the project.
The Analysis phase helps the team to truly understand the major functional areas and
processes of the system. Through this we evaluate the existing system weakness and strength.
After that, we performed requirements identification to discover user and system
requirements. This phase consisted of drawing the functional as well as non-functional
requirements of the system. Then we have undertaken a major phase in system development
process: object oriented Analysis. In this phase, we tried to model the new system we
proposed using UML Modeling s: Use case, sequence, and activity and class Modeling s
Also, we designed the new system user interface prototype.
7.2 Recommendation
The system that we are trying to develop is not a fully executed system. Because we were
new to the system we missed out some parts which should be included in the system.
Future work of the system can perform the following functionalities. The developed
and previously tested functionalities can be modified later with more user-friendly functions
to make the system more useful.
Now the application is working for Device application.Maintainingshare pricedetails as
a localized system and accessing the details anywhere in the world. Later we can
implement some telecom concepts, so that the user will get the information about the
activities of the company in a mobile device. As technology and requirements are changing
day by day, we can add more functionality and we can implement the system with new
requirements. The system is designed in such a way that it is flexible to change any further
requirements Prescribed by the user.

Debre Berhan University: College of Computing Department of Computer Science

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Debre Berhan University: College of Computing Department of Computer Science

Uploaded by

Copyright:

Available Formats

DEBRE BERHAN UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE

TITLE: - ANDROID BASED MOBILE ANTI-THEFT SYSTEM

1) ABIE CHECKOL COMPR/004/04

2) FIKRTE TEFERA COMPR/014/04

3) GETAHUN TADESSE COMPR/018/04

4) SOLOMON GETACHEW COMPR/044/04

5) YIBEKAL ALMIRAW COMPR/051/04

FINAL PROJECT SUBMITED TO DEPARTMENT OF computer science IN PARTIAL

DEBRE BERHAN ETHIOPIA

Yitayal Abate (MSc)

Examiner II: ---------------------------

Examiner III: ---------------------------

Examiner IV: ---------------------------

Head of Department: ----------------------------

Yimer Mohammed (MSc)

Dept. of Computer science

DebreBerhan University College of Computing

Abbreviation and acronyms……………………………………………………………….. VII

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 1

1.2 Statement of the Problem

1.2.1 Problem Definition

1.2.2 Problem Explanation

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 2

1.4.2 Specific objective

Studying and analyzing the existing system.

Owner can view detail from database

Owner can add uninstall security

Owner can change status of the system

Owner can register detail to database

Relative can retrieve GPS co-ordinate from Google map

System Send SMS to relative automatically

It depends on smart phones which support Google Android OS.

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 3

1.6 Significant of the project

To track the location of the lost android mobiles phone

1.7 Feasibility study of the new system

1.7.1 Economic feasibility

1.7.2 Operational feasibility

1.8.1 Fact finding Techniques

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 4

1.8.2 System Analysis and Design Techniques

Object Oriented Analysis (OOA)

Object Oriented Design (OOD)

1.8.3 Tools and technologies

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 5

Risk Assessment & Management

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 6

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 7

2.2 Existing system description

2.3 Problems of the existing systems

2.4 The proposed system

DBU DEP’T OF COMPUTER SCIENCE FINAL PROJECT 2007 E.C Page 8

2.4.1 Functional Requirements

Input requirement is a Mobile with GPS facility. It should be a Google Android OS

System should not uninstall when uninstall security is ACTIVATED.

2.4.2 Nonfunctional requirement

2.5 Overview of Data Requirements

2.6 Use Case Modeling

Figure 2.1 Use case Modeling

2.6.1 Use case description

Use case name: - Login