DEVELOPMENT OF REMOTE ACCESS TOOL IN JAVA

FOR ACCESSING ANDROID DEVICE VIA SHORT

MESSAGING SERVICE

MUHAMMAD ASAD
MM-BSCS-199-016
SIBGHA BATOOL
MM-BSCS-199-048

BACHELOR OF SCIENCE
IN
COMPUTER SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

FACULTY OF SCIENCE AND TECHNOLOGY

TIMES INSTITUTE, MULTAN

PAKISTAN
2023

i
 DEVELOPMENT OF REMOTE ACCESS TOOL IN JAVA
FOR ACCESSING ANDROID DEVICE VIA SHORT
MESSAGING SERVICE

MUHAMMAD ASAD
MM-BSCS-199-016
SIBGHA BATOOL
MM-BSCS-199-048

A Project Report submitted in partial fulfillment of the requirement for

the degree of

BACHELOR OF SCIENCE
IN
COMPUTER SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

FACULTY OF SCIENCE AND TECHNOLOGY

TIMES INSTITUTE, MULTAN

PAKISTAN
2023

ii
 DECLARATION

I hereby declare that the contents of the project report, “Development of Remote
Access Tool in Java for Accessing Android via Short Messaging Service”
are product of my own research and no part has been copied from any published
source (except the references, standard mathematical of genetic models/
equations/ formulae/ protocols etc.). I further declare that this work has not been
submitted for award of any other diploma/degree in any other institute/university.
The Institute may take action if the information provided is found incorrect at any
stage.

_______________
Muhammad Asad

_______________
Sibgha Batool

iii
CERTIFICATE BY THE PROJECT SUPERVISOR

This is to certify that the final year project of BS(CS) RAD (Remotely access Android
Device) was developed by Muhammad Asad and Sibgha Batool supervised by Mr.
Faheem Khan and that in his opinion it is fully adequate, for the degree of BS Computer
Science.

Internal Examiner

Name: _____________________

Signature: __________________

External Examiner

Name: _____________________

Signature: ___________________

iv
 PLAGIARISM UNDERTAKING

I solemnly declare that the research work presented in project report titled,
“Development of Remote Access Tool in Java for Accessing Android Device via
Short Messaging Service” is exclusively and solely my research work without any
significant contribution from any other person. Any small contribution, wherever
taken, has been duly acknowledged. I apprehend the zero-tolerance policy of the
HEC and TIMES Institute, Multan, towards Plagiarism. So, we as an author of this
project report state that no portion of my project report has been plagiarized and
that every material used from any source has been properly acknowledged, cited,
and referenced. I agree to that if I am found guilty of plagiarism in the above titled
project report, even after the award of BS degree, the Institution has the right to
cancel my degree. The Higher Education Commission of Pakistan and the TIMES
Institute, Multan, have the right to publish my name on the HEC/Institution website
for submitting a plagiarized project report.

_________________
Muhammad Asad

_________________
Sibgha Batool

_________________
Date

v
vi
The Controller of Examinations
Times Institute,
Multan.
We hereby certify that the contents and form of thesis submitted by Muhammad
Asad (MM-BSCS-199-016) and Sibgha Batool (MM-BSCS-199-048) has been
found satisfactory for the evaluation in the format approved by the Times
Institute. It is therefore recommended that further necessary action may kindly be
taken for the final award of the degree of BS.
(Computer Science).

Board of Examiners
External Examiner: _______________
Name
Designation
Affiliation

Supervisor: _______________
Name
Designation
Affiliation

Co-Supervisor: ________________
Name
Designation
Affiliation

HoD /Coordinator: _________________

Name
Designation
Affiliation

vii
 ACKNOWLEDGMENT

We are gratified to Almighty Allah (S.W.T) who is the most Beneficent and most

Merciful, blessed us strength to accomplish the project.

We would like to express our gratitude to our Supervisor Mr. Faheem Khan for

his guidance and support, and his continuous encouragement throughout the

project.

We are very thankful to Mr. Asim Ali Rao for his worthy discussions, reassurance

and for keen interest in our project, and correcting us during the various phase of

the project.

We are thankful to Mr. Arsalan Iftikhar for his encouragement, healthy comments,

hard questions and his guidance in preparation of presentation.

We are also thankful to our worthy Chairman, Mr. Muhammad Sarfraz Muzaffar

and Executive director Ms. Warda Naseem for providing and maintaining

conductive and healthy environment including lab facility.

Last but not the least, we would express our sincere thanks to parents and

friends, it would not be possible without their support.

viii
 Abstract

In the fast-paced nature of our professional lives, it is common for us to

inadvertently leave our smartphones behind in various locations such as offices,
colleges, outdoors, or even at home. Compounding the issue, these misplaced
phones are often disconnected from the internet, making it challenging to track
their whereabouts. The fear of someone else finding the phone and potentially
misusing the personal data, contacts, or messages stored within it amplifies the
anxiety associated with losing a smartphone.
To address this problem, there is a need for a tool that can access and control key
functionalities of an Android smartphone remotely. Such control over the phone's
settings could prove instrumental in locating the device by enabling features like
activating the sound profile to ring the phone, retrieving its geo-location, or play
sound for desired time, among other actions.
This project introduces the tool for remotely accessing an Android smartphone via
SMS, which can be sent from any trusted mobile phone worldwide. The idea entails
designing an Android-based application that facilitates a secure and controlled
remote access between the user and their smartphone. Through this application,
users would be able to control essential settings of their Android devices, thereby
providing a reliable and secure environment for remote access.

ix
 Table of Contents
Abstract ix
CHAPTER-1 1
INTRODUCTION 1
1.1 Introduction 2
1.2 Background 3
1.3 Problem Statement 4
1.4 Purpose 4
1.5 Scope 4
1.6 Objective 5
1.7 Intended Audience 6
CHAPTER-2 7
SOFTWARE REQUIREMENT AND SPECIFICATION 7
2.1 Overall Description 8
2.1.1 Product Perspectives 8
2.1.2 Product Features 8
2.1.2.1 Modules Name and Description 9
2.1.4 Assumption and Dependency 10
2.1.4.1 Assumptions 10
2.1.4.2 Dependencies 10
2.2 System Features 10
2.2.1 System Feature 10
2.2.1.1 Response Sequence 11
2.2.2 Functional Requirements 11
2.3 External Interface Requirements 11
2.3.1 User Interfaces 11
2.3.2 Hardware Interfaces 12
2.3.3 Software Interfaces 12
2.3.4 Communications Interfaces 12
2.4 Other Nonfunctional Requirements 12
2.4.1 Performance Requirements 12
2.4.2 Safety Requirements 13
2.4.3 Security Requirements 13

x
 2.4.4 Software Quality Attributes 13
2.4.4.1 Availability: 13
2.4.4.2 Security: 13
2.4.4.3 Reliability: 14
2.4.4.4 Compatibility: 14
CHAPTER-3 15
ANALYSIS (USE CASE MODEL) 15
3.1Identifying Actors and Use Cases 12
3.1.1 Android Device Owner: 12
3.1.2 Remote User: 12
3.2 Use Case Diagram 12
3.2.1 Android Device Owner: 12
3.3 Describe the Events Flow for Use Case 14
3.3.1 Android Device Owner: 14
3.3.2 Remote User: 15
CHAPTER-4 16
DESIGN 16
4.1Architecture Diagram 17
4.1.1 Four+1 View Model 17
4.2 ERD with Data Dictionary 19
4.2.1 Entity 20
4.2.2 Attribute 20
4.2.3 Relationship 20
4.3 Data Flow Diagram (Level 0, Level 1 and Level 2) 22
4.3.1 Level 0: 24
4.3.2 Level 1: 25
4.3.3 Level 2: 26
4.3.3.1 Android User 26
4.3.3.2 Remote User: 27
4.4 Class Diagram 29
4.5 Object Diagram 32
4.5.1 Notations Used in Object Diagrams – 32
4.5.1.1. Objects: 32
4.5.1.2. Links: 32

xi
 4.6 Sequence Diagram 33
4.6.1 Android User: 35
4.6.2 Remote User: 36
4.7.1 Android User: 39
4.7.2 Remote User 40
4.8 Collaboration Diagram 40
Notations of a Collaboration Diagram 41
4.8.1 Android User: 43
4.8.2 Remote User: 44
4.9 State Transition Diagram 44
Notations of a State Transition Diagram 45
4.9.1 Android User: 46
4.9.2 Remote User: 47
CHAPTER 5 18
IMPLEMENTATION 18
5.1 Component Diagram 19
5. 2 Deployment Diagram 20
5.2.1. The Purpose of Deployment Diagram 21
CHAPTER-6 23
TESTING (SOFTWARE QUALITY ATTRIBUTES) 23
6.1Test Case Specification 70
6.2 Black Box Test Cases: 70
6.2.1 Boundary Value Analysis 71
6.2.1.1 SMS Receiver Test Case: 71
6.2.1.1.1 Start: 72
6.2.1.1.2 Stop: 72
6.2.2 Equivalence Class Partitioning 72
6.2.2.1 Test Case: 73
6.2.3 State Transition Testing 73
6.2.4 Decision Table Testing 75
6.2.5 Graph Based Testing 76
6.3 White Box Testing: 77
6.3.1 Statement Coverage 78
6.3.2 Branch Coverage 78

xii
 6.3.3 Path Coverage 79
CHAPTER-7 80
TOOLS AND TECHNOLOGIES 80
7.1Programming Languages 77
7.2 Operating Environment 77
7.4 TOOLS AND TECHNIQUES: 77
7.4.1 BACK END: - 77
7.4.1.1 JAVA: 77
7.4.1.2 XML: Error! Bookmark not defined.
7.4.1.3 Android: 77
7.4.1.3.1 Activity: 78
7.4.1.3.2 Service 78
7.4.1.3.3 Content Providers 78
7.4.1.3.4 Broadcast Receivers 79
7.4.1.4 Android Studio: 80
7.4.1.5 SMS 80
7.4.1.6 GPS 80
7.4.1.7 Wi-Fi 81
7.4.1.8 Bluetooth 81
7.4.1.9 Regular Expression 81
7.4.2 FRONT END: - 82
7.4.2.1 XML: 82
7.4.2.2 Java: 83
Appendix A: User documentation 84
7.5 Appendix A 84
7.5.1 User documentation 84
7.5.2 USER MANUAL 84
References 14

xiii
 CHAPTER-1
INTRODUCTION

1
1.1 Introduction
Smartphones have become an indispensable part of our lives, impacting various
aspects of our daily routines. From basic tasks to complex activities, our
dependence on smartphones is undeniable. However, along with this reliance
comes a prevalent fear known as nomophobia, or the fear of being without a mobile
phone. This phobia is experienced by many individuals who feel a sense of unease
or anxiety when they misplace their smartphones, even for a brief moment.
In the fast-paced nature of our professional lives, it is common for us to
inadvertently leave our smartphones behind in various locations such as offices,
colleges, outdoors, or even at home. Compounding the issue, these misplaced
phones are often disconnected from the internet, making it challenging to track
their whereabouts. The fear of someone else finding the phone and potentially
misusing the personal data, contacts, or messages stored within it amplifies the
anxiety associated with losing a smartphone.
To address this problem, there is a need for a tool that can access and control key
functionalities of an Android smartphone remotely. Such control over the phone's
settings could prove instrumental in locating the device by enabling features like
activating the sound profile to ring the phone, retrieving its geo-location, or
establishing an internet connection, among other actions.
One potential solution to this problem is the development of an Android application
that grants users remote access to their misplaced smartphones, allowing them to
perform specific changes or actions on the device using SMS (Short Message
Service). This application would require users to send SMS commands from any
phone. By leveraging SMS, the application can establish a remote connection with
the lost Android smartphone, even in the absence of an internet connection.
This project introduces the tool for remotely accessing an Android smartphone via
SMS, which can be sent from any trusted mobile phone worldwide. The idea entails
designing an Android-based application that facilitates a secure and controlled
remote access between the user and their smartphone. Through this application,
users would be able to control essential settings of their Android devices, thereby
providing a reliable and secure environment for remote access.

2
1.2 Background
Back in the old days we were not able to know the whereabouts of our android
devices. As a result, there was an immense need for a tool that can tell us about
the location of our device. Since then, many android apps have been developed.
In 2008, Life360 made its debut on Google Play. Life360 Inc., an American
information technology company headquartered in San Francisco, California,
offers location-based services worldwide, specializing in sharing and notifications
for consumers. Their flagship product, also named Life360, is a family social
networking application launched in 2008. The primary purpose of the app is to
facilitate the sharing of location among friends and family members. According to
Bloomberg Businessweek, Life360 is considered a "family-oriented private social
network." Unlike other platforms like Find My Friends and LinkedIn, Life360
focuses exclusively on connecting families rather than peer groups or professional
networks. Among its key features are location sharing, group messaging, and the
option to request roadside assistance. Through the app, users can instantly view
the whereabouts of other members within their circles and have the flexibility to
choose when and with whom to share their location information.
In 2009, the development of "Where's My Droid" took place. This app was
specifically created to assist users in locating their misplaced phones and is
available for free. Unlike the conventional method of calling the lost phone,
Where's My Droid offers more comprehensive features. Calling the phone may not
be effective if it is set to vibrate mode or located far away from your hearing range.
To overcome these limitations, the app utilizes a different approach. Users can
send a text containing a secret "attention" word or phrase to their phone. This
action triggers the app's find-me mode, causing the phone to switch from vibrate
to ringer mode, increase the volume, and ring for a duration of 30 seconds. This
innovative approach increases the chances of finding the lost phone even in
situations where calling would be ineffective.
In 2010, spy was launched. In 2011, AirDroid was built. In 2013, Google
Find My Device was released. All these apps were helpful but there were some

3
limitations. Some worked only when there was an internet connection, others
required the phone to be logged in to a Google account.

1.3 Problem Statement

All the Android users were using the internet to remotely access their
smartphones. There arises a need for a tool which can help android users to
remotely access their smartphones without an internet connection.

1.4 Purpose
This Android app serves the primary purpose of offering users a convenient
and efficient method to manage their Android devices using SMS commands,
eliminating the necessity for an internet connection. The app aims to simplify the
process of managing various device functions remotely, allowing users to perform
tasks such as adjusting volume levels, checking battery status, controlling
connectivity options, and modifying display settings through simple SMS
interactions. By offering this functionality, the app seeks to empower users with
greater flexibility and control over their Android devices, enabling them to
customize and manage their device settings conveniently, even in situations where
internet access may be limited or unavailable. The purpose of the app is to
enhance user experience, streamline device management, and provide a reliable
solution for controlling Android devices through SMS communication.

1.5 Scope
The main scope of the project is to build an app that will allow android users
to remotely access some features of smartphones without an internet connection.
These features include:
1. accessing the location of the device
2. Playing sound on the remote device for a specified time.
3. Getting audio volume of different audio types (ring, music, alarm,
notification, system, phone call).

4
 4. Setting the audio volume of different audio types (ring, music, alarm,
notification, system, phone call).
5. Checking whether the Wi-Fi is enabled or disabled.
6. Checking whether the Bluetooth is enabled or disabled.
7. Enabling and disabling Bluetooth.
8. checking the device battery level
9. checking whether the device is charging or not.
10. getting brightness level of device
11. setting brightness level of device
12. getting display off timeout.
13. setting display off timeout
14. turning off display
15. checking whether the Wi-Fi hotspot is enabled of disabled.
16. Enabling or disabling the Wi-Fi hotspot. (API Level 29)

1.6 Objective

● To build an Android app to provide users with a simple and reliable method
of controlling their devices using SMS commands, even without an internet
connection.
● Enabling users to send specific SMS commands to their devices from a
designated mobile number, to remotely control various device functions.
● The app seeks to streamline tasks such as adjusting audio volume,
checking device status, managing connectivity options, and controlling
display settings. With an intuitive user interface and efficient command
validation,
● To enhance user convenience, allowing them to interact with their Android
devices effortlessly via SMS communication.
● To offer a practical and accessible solution for users to manage and control
their Android devices remotely, providing them with greater flexibility and
ease of use in their daily device interactions.

5
1.7 Intended Audience
The intended audience for this Android app includes Android device users
who seek a convenient and efficient way to control their devices using SMS
commands. This app caters to individuals who may have limited or no access to
an internet connection but still want to manage and manipulate various functions
of their Android devices remotely. It is designed for users who prefer the simplicity
of SMS communication and desire the ability to perform actions such as adjusting
volume levels, checking battery status, controlling Wi-Fi and Bluetooth
connectivity, and managing device settings through a straightforward and
accessible interface. The app aims to provide a seamless and intuitive user
experience for Android users, empowering them with convenient control over their
devices via SMS interactions.

6
 CHAPTER-2
SOFTWARE REQUIREMENT AND SPECIFICATION

7
2.1 Overall Description
2.1.1 Product Perspectives
This project introduces the tool for remotely accessing an Android smartphone via
SMS, which can be sent from any trusted mobile phone worldwide. The idea entails
designing an Android-based application that facilitates a secure and controlled
remote access between the user and their smartphone. Through this application,
users would be able to control essential settings of their Android devices, thereby
providing a reliable and secure environment for remote access.
2.1.2 Product Features
The project specifies an app that will allow android users to remotely access some
features of smartphones without an internet connection.
The features of Application include:
1. Accessing the location of the device
2. Playing sound on the remote device for a specified time.
3. Getting audio volume of different audio types (ring, music, alarm,
notification, system, phone call).
4. Setting the audio volume of different audio types (ring, music, alarm,
notification, system, phone call).
5. Checking whether the Wi-Fi is enabled or disabled.
6. Checking whether the Bluetooth is enabled or disabled.
7. Enabling and disabling Bluetooth.
8. Checking the device battery level
9. Checking whether the device is charging or not.
10. Getting brightness level of device
11. Setting brightness level of device
12. Getting display off timeout.
13. Setting display off timeout
14. Turning off display
15. Checking whether the Wi-Fi hotspot is enabled of disabled.
16. Enabling or disabling the Wi-Fi hotspot. (API Level 29)

8
2.1.2.1 Modules Name and Description
Audio
Manage volume of ringtone, music and more.
Battery
Get the level of the device's battery and check if it is charging.
Bluetooth
Turn Bluetooth on and off, Check if Bluetooth is enabled.
Display
Manage the display’s brightness and state (on or off). Set time, after which
the display is turned off when the user is not interacting with the phone.
Grant Phone Remotely
Grant a phone number access remotely. The phone number sending the
grant command will be added to the list of granted phones for the specified module
(or all modules when using the all keyword). If access is no longer necessary
afterwards, you can remove the phone number from the list of granted phones in
the relevant module(s).
Location
Get location of the device.
Play Sound
Play ringtone for a specific duration.
Wi-Fi
Change the state of Wi-Fi on or off. Check if Wi-Fi is enabled.
Wi-Fi Hotspot
Turn hotspot on and off. Check if hotspot is enabled. The hotspot must be
pre-configured in the system.

2.1.3 Design and Implementation Constraints

During the programming of the app, different challenges are faced. The
main challenge is the deprecation of the API from Google in latest Android versions
which affects the functionalities of the app and constrains its domains of features.

9
2.1.4 Assumption and Dependency

2.1.4.1 Assumptions
● The coding should be error free.
● The application must be user friendly so that it is easy for the user to use it.
● Valid information of the user must be stored in the app that is used to
operate the app.
● Users should have their correct phone numbers and grant passwords to
remotely access and do action.

2.1.4.2 Dependencies

● The specific operating system which is an Android and Android level 4.0
and above is required on which the app will run.
● On the basis of listing requirements specification, the app will be developed
and run.
● The user should completely understand the app.
● Any update regarding the app, and any other update is to be stored to the
database and the data entered should be correct.

2.2 System Features

2.2.1 System Feature
This Android-based application that facilitates a secure and controlled
remote access between the user and their smartphone, it is a tool for remotely
accessing an Android smartphone via SMS, which can be sent from any trusted
mobile phone number that is registered by the android user. Through this
application, users would be able to control essential settings of their Android
devices, thereby providing a reliable and secure environment for remote access.
These are some features of RAD android application:
● Maintain registered phone numbers.
● Maintain Grant Password
● Accurate command handling

10
 ● Maintain student admission.
● Save the time and cost.
● Reduce manpower.
● To manage the college records efficiently.
● To provide data security as it ensures that students & staff member’s
personal data remain protected from unauthorized access.

2.2.1.1 Response Sequence

Once a trusted mobile phone number is entered in the app, it is then
saved. If permission of module is not permitted then app prompts, asking the user
to enable the specific module permission for the app.
2.2.2 Functional Requirements
It is the list of services that the application must provide to the user. It's a
term that refers to a software system or its components. The following are the
functional requirements for our software.
● Start/stop SMS receiver.
● Add phone numbers.
● Enable/disable module.
● Set grant password.
● Get location of device
● Get and set Wi-Fi state.
● Get and set Bluetooth state.
● Play ringtone for specified time.
● Get and set Wi-Fi Hotspot

2.3 External Interface Requirements

2.3.1 User Interfaces

GUI is one of the most important and easy to use for any user to interact
with any kind of device application, because this helps to manage or control the
system easily by using some icons and some other buttons. A first-time user of the

11
app should see the help tour dialogue box. If the user is not a first-time user, should
be able to see the main screen of the app which contains different modules like
audio, location, display, etc.

2.3.2 Hardware Interfaces

We require an active GSM connection for sending and receiving SMS to

interact with the app. The phone uses Short Message Peer to Peer (SMPP)
protocol to communicate with telephone operators’ gateways. SMPP is used to
send and receive messages from and to GSM, UMTS, iDEN, CDMA, and TDMA
cell phones. The app runs on all the android devices above Android 4.

2.3.3 Software Interfaces

We use Java for writing the code for the project. Java and XML for creating
the menus, main screen and other designs. Android studio was used to code the
app.

2.3.4 Communications Interfaces

This product requires a GSM connection that covers the entire world,
enabling users to interact with Android devices. The app utilizes the SMPP (Short
Message Peer-to-Peer) protocol to provide facility of sending and receiving of SMS
messages. This ensures seamless communication between the user and their
Android devices, regardless of their location.

2.4 Other Nonfunctional Requirements

2.4.1 Performance Requirements

The technology is suitable for quick responses. This project will be operated
entirely offline. In approximately 2-3 seconds, the user will be able to receive
responses to their queries. It maintains all records regarding commands and

12
responses in the app and shows them in the notification panel. The project involves
retrieving information from the android device via a GSM connection through SMS.

2.4.2 Safety Requirements

The user should not disclose its Grant Password. The user should only add
the phone numbers of trusted contacts. The app does not store any information of
the user online; all the data is stored in the phone.

2.4.3 Security Requirements

Phone numbers that are registered in the app by the user will be able to
interact with Android devices by sending valid commands. Will be able to send
SMS to Android users having the app. The app is fully secured. No one can access
anyone’s android device through this app if he does not know the Grant Password.
Device owners will have access to the save mobile numbers. Only the app user
will have the rights for modifications such as changing the phone number of trusted
contacts. Access to the various subsystems will be accessed by the user.

2.4.4 Software Quality Attributes

2.4.4.1 Availability:

It is dependent on the android smartphone’s GSM connection to

communicate, and ability other user permissions to function properly. The RAD
app will be working 24 hours a day in the background once started by the user. If
the smartphone is reliable and functions properly, the app’s functions will be
available at all times.

2.4.4.2 Security:

1. The password that is generated or approved is encrypted and kept in a

device.
2. Each of the phone numbers must be correct.

13
 3. Each module has its own list with its own granted phone numbers.
4. The remote user has limited access, which is granted by the app’s user.
5. No one can access the user's device through the App unless they are an
authentic individual.

2.4.4.3 Reliability:

According to recent research, participants have demonstrated that apps

offer the benefit of constant availability and accessibility. Specifically, Android apps
are known for their reliability, providing users with a stable and dependable
experience. The widespread availability of the GSM network across the globe is a
critical component of our app's functionality.

One of the key features of our project is its ability to continuously share
information over SMS for extended periods. Despite this continuous operation, the
app consumes a minimal amount of battery. In fact, extensive testing has shown
that the app only utilizes 1% of the battery while operating for a duration of 4 days.
This energy efficiency ensures that users can rely on the app for extended periods
without significant battery drain.

2.4.4.4 Compatibility:

Our app is meticulously designed to ensure high compatibility, delivering a

smooth and seamless user experience across a diverse range of devices and
Android versions. Whether you are utilizing a smartphone or a tablet, our app
effortlessly adapts to various screen sizes, resolutions, and aspect ratios. Its
optimization extends to both older and newer Android operating systems, assuring
that you can fully enjoy all the features and functionalities of our app, irrespective
of the device you possess.

14
 CHAPTER-3
ANALYSIS (USE CASE MODEL)

15
3.1 Identifying Actors and Use Cases

3.1.1 Android Device Owner:

Remote users will be added by the allowance of administrative personnel.

Administrator has the power to enable, delete, and change items.

The following are some of the administratively controlled activities by owner:

1. Enable and Disable Modules.

2. Allow device Permissions for the app.

3. Adding or removing remote user’s phone numbers.

4. Set Password for grant access.

5. Set whether the app runs on startup or not.

3.1.2 Remote User:

The remote user will be able to communicate with the device by using any SMS
client app through SMTP. Many features are available on the dashboard, including:

1. Details about the fee can be found here.

2. View the attendance list.

3. View the result.

3.2 Use Case Diagram

3.2.1 Android Device Owner:

12
 Figure 3.1 Android Device Owner

Explanation:

A user is the owner of the device on an android device who has complete and
unlimited access to the app and its modules, create, delete, and edit phone
numbers. An Android user can make changes to the app, such as:

● On the app, adding or removing phone numbers.

● Enabling and disabling modules.

● Changing grant password.

13
3.2.2 Remote User

Figure 3.2 Remote User

Explanation:

The Remote user will send SMS from his android device. The SMS will consist
of the commands. The valid commands will be accepted by the SMS receiver
and in return it will give a response back. Remote user will send the commands
related to:

● Get location of device

● Get and set Wi-Fi state.
● Get and set Bluetooth state.
● Play ringtone for specified time.
● Get and set Wi-Fi Hotspot

3.3 Describe the Events Flow for Use Case

3.3.1 Android Device Owner:

The following are some of the activities controlled by the owner of android
device:

14
 1. Add/remove phone numbers.

2. Start/stop SMS receiver.

3. Enable/disable modules.

4. Set Grant password.

3.3.2 Remote User:

The following are some of the activities performed by remote user by

sending valid commands through SMS:

● Get location of device

● Get and set Wi-Fi state.
● Get and set Bluetooth state.
● Play ringtone for specified time.
● Get and set Wi-Fi Hotspot

15
CHAPTER-4
DESIGN

16
4.1 Architecture Diagram

System designers and developers can utilize a basic architecture diagram

(UML) to visually represent the high-level structure of the application. This diagram
helps to identify patterns that emerge in the design, which can be described using
the phrase "a model." A model serves as a comprehensive, foundational, and concise
representation of the software architecture, incorporating multiple viewpoints from
specific angles or perspectives.

Exactly, a view in the context of software architecture is a representation of the

entire system from a particular set of interconnected concerns. These views are used
to explain the system's various aspects and functionalities from the perspectives of
testers, project managers, developers, and end users. Each view provides a focused
and targeted understanding of the system, catering to the specific needs and
interests of the involved stakeholders. This approach helps in effectively
communicating and addressing the diverse requirements and concerns of the
project's various participants.

4.1.1 Four+1 View Model

Philippe Kruchten is credited with creating the 4+1 View Model, which is a
comprehensive approach to explaining the structure of a software system through
the utilization of multiple concurrent views. This model considers various system
features and concerns, presenting a holistic picture of the system's architecture.

It allows all stakeholders to easily understand the design, thanks to the

standardization of the software design documentation. By employing this technique,
architectural designs are thoroughly examined and recorded, addressing every
aspect of software architecture for all involved parties. This verification process
ensures that the architectural decisions are well-documented, accessible, and
comprehensible to all relevant stakeholders, fostering effective communication and
collaboration throughout the development process.

17
It provides four important views:

● The conceptual view: object model is described in this view.

● The process view: all activities of the system, and concurrency of the app.
● The physical view: All mappings and relations of entities in application onto
hardware.
● The development view: It describes the structure of the application in its
development.

The 4+1 view model can be expanded by adding a further view known as a
use case view for application system end-users. As a "plus one" view, or 4+1 view
model, it is connected with the previous four views and is used to explain the design
of the application. The application architecture using five concurrent views (4+1)
models is shown in the following diagram.

18
 Send
Commands
Ma Get
Android nag App Info Remote
User e User
Dat

Hardware

Enable/Disable
Android User

Enable/Disable Adding/Removing
SMS
Receiver

Modules Phone
Numbers

Figure 4 Architecture Diagram

4.2 ERD with Data Dictionary

An entity relationship diagram (ERD), also known as an entity relationship

model (ER model), is a visual representation of the relationships between various
objects, concepts, and events within an information technology (IT) system. It serves
as a graphic depiction of the data items and their relationships in a high-level manner,
defining the conceptual design of the database for a specific system. The ER model
creates a clear and straightforward view of the data, allowing for a comprehensive
understanding of the database structure.

19
4.2.1 Entity

In an Entity-Relationship Diagram (ERD), entities are used to represent any

item, class, person, or location that is of interest in the system being modeled.
Essentially, entities represent real-world objects or concepts that have distinct
attributes.

Rectangles are commonly employed in ER diagrams to visually represent

entities. Each rectangle corresponds to a specific entity and typically contains the
name of the entity along with its attributes listed within the rectangle.

For example:

Teachers, Students, Admin etc. can be taken as an entity.

4.2.2 Attribute

In ER diagrams, attributes are essential for defining the structure and properties
of entities, contributing to a comprehensive representation of the data model. They
help to identify and categorize the data, allowing for a more meaningful understanding
of the system's information.

For example:

If we have an entity called "Person," some of its attributes could include "Name,"
"Age," "Address," and "Email." These attributes provide specific details about each
person entity in the system.

4.2.3 Relationship

The association or connection between two or more entities is represented by

a relationship. It explains the connections between entities in the system being
modelled.

20
 For example:

Driver Drives Car

Name Mobile Name Mobile

Number Number

Android User Remote User

Use Sen
s d

RAD App

SMS Phone
receiver numbers
Modules

Figure 4.1 ER Diagram

21
4.3 Data Flow Diagram (Level 0, Level 1 and Level 2)

A data flow diagram shows how data moves through a process or system. It
displays data inputs, outputs, storage locations, and pathways between each
destination using preset symbols such as rectangles, circles, and arrows as well as
brief text labels. A data flow diagram (DFD) is a common visual representation of how
information flows through a system. The right amount of the system demand can be
graphically represented by a neat and clear DFD. Either manually, mechanically, or
both can carry it out.

The key elements in a Data Flow Diagram are given below:

Circle (Bubble): It represents a process that changes data inputs into data outputs.

Curved Line (Data Flow): It shows the movement of data into or out of a process.

Parallel Lines (Data Store): It indicates a location for storing data items, which can
be accessed by different processes at different times.

Source or Sink: It represents an external entity that acts as the source of system
inputs or the sink of system outputs.

DFDs can be used to demonstrate how information enters and exits a system, how
data is modified, and where information is saved. The primary goal of a DFD is to
outline the boundaries and scope of a system, and it serves as a communication tool
between system analysts and various stakeholders during system redesign.

Levels of Data Flow Diagrams (DFD)

Data Flow Diagrams (DFDs) can be used to represent any level of abstraction
for a system or software. They provide a structured and hierarchical approach to
analyzing and understanding the information flow and functional aspects of a system.
DFDs are divided into different levels, denoted by numbers 0, 1, 2, and so on,
indicating the level of detail and complexity.
22
Zero-level DFD

The initial level of the Data Flow Diagram (DFD) is called the context diagram
or Zero-level DFD. In this diagram, the complete software system is represented by a
single bubble, providing an overview of the system's functionalities and interactions
with external entities. The input data and output data are depicted with incoming and
outgoing arrows, showing the data flows between the system and its external
environment. The system is then decomposed into more detailed processes or
bubbles in the 1-level DFD, where each bubble represents a major function or
process. This decomposition can continue further into the 2-level DFD, breaking down
each process into more detailed sub-processes or tasks. This iterative process can
be repeated as necessary to achieve a comprehensive understanding of the system.
It is important to maintain consistency in the number of outputs and inputs between
the different levels, a concept known as "leveling," which helps ensure a thorough
documentation of the system's design and information flow. The context diagram for
the outcome management system is an example of the Zero-level DFD.

One-level DFD

At this level, the context diagram is decomposed into more detailed processes
or bubbles, breaking down the major functions of the system into their sub-functions.
The 1-level DFD focuses on the primary processes and their interactions, showing
how data flows between them and the external entities.

Two-Level DFD

Further decomposition of the 1-level DFD leads to the 2-level DFD, which
provides even more detailed information about the processes and data flows. This
process of decomposition can be continued to achieve finer granularity and a deeper
understanding of the system's inner workings. There can be additional levels beyond
2-level DFDs if needed, depending on the complexity and requirements of the system.

23
4.3.1 Level 0:

Location
Android
SMS
Receiver User

Play
Grant
Sound
Phone
Remotely

Remote Remotely
User Access Audio
Device

Wi-Fi
Wi-
Hotspot
Fi___33

Display
Battery
Bluetooth

Figure 4.2 Level 0

24
4.3.2 Level 1:

SMS Receiver

Can enable and

disable modules.

Add and remove

Phone numbers.

Audio
Android
User
Bluetooth

Remotely
Access Display
Device
(RAD)
Grant Remote Access

Remote Location
User

Play sound.

Wi-Fi

Wi-Fi Hotspot

Figure 4.3 Level 1

25
4.3.3 Level 2:

4.3.3.1 Android User

Manage
Grant
Android Open Password
Check
User the App
Module

Enable
Modules

Disable
Modules
Start SMS
Receiver Manage
Module

Manage
Phone
Numbers

Manage
Device
Permissions

Figure 4.4 Figure Android User Level 2

26
4.3.3.2 Remote User:

Open
Remote any SMS Receive
User Client Response
App

Send
Commands

Figure 4.5 Remote User Level

27
4.4 Class Diagram

It is a static structural UML diagram that represents a system by illustrating its

classes, operations, properties and interaction between objects. It is a fundamental
tool in object-oriented methodologies and serves as the foundation of every object-
oriented programming (OOP) system.

In a class diagram, you can display classes, relationships, interfaces,

associations, and collaborations. The diagram adheres to UML standards, providing
a standardized way to represent the elements and relationships within an object-
oriented system.

The class diagram is well-suited for depicting classes, inheritance,

relationships, and other essential components of object-oriented programming. As
classes form the basis of an OOP-based program, the class diagram effectively
describes the various object types and their static relationships in the system. It is a
valuable tool for understanding the structure of the system and how its components
are organized and interconnected.

Some key features of class diagrams are:

● They are the only UML that can correctly show various aspects of the
Object-Oriented Programming’s concept.
● They facilitate quicker and more efficient design and analysis of
applications.
● Class diagrams serve as the foundation for deployment and component
diagrams.

In a class diagram, each class is shown by using a rectangle that is divided into
three sections: name, attributes, and operations. Three types of modifiers are used to
determine the visibility of attributes and operations:
29
 ● "+" denotes public accessibility (accessible to everyone).
● "#" represents protected visibility (accessible to the same class and
derived classes).
● "-" signifies private visibility (accessible only within the class).

Efficiently making or editing the model can be achieved using several diagram
components, including:

● Interface
● Relationships (such as inheritance, association, and generalization)
● Class (with name, attributes, and methods)
● Associations (bidirectional and unidirectional)
● Objects

30
Figure 4.7 Class Diagram
31
4.5 Object Diagram

It shows specific instances of a system at a given point in time. Its main purpose
is to depict the behavior of the real system accurately, showing the system in a static
state. The object diagram displays instances in the system and the relationships
between them, offering insights into the system's behavior when objects are
instantiated.

By presenting a snapshot of the system's structure at a particular moment,

object diagrams enable us to investigate the system's behavior under specific
conditions. They are essential for representing and understanding the functional
requirements of the software.

In summary, an object diagram in the Unified Modeling Language (UML)

provides a complete or partial view of the structure of a modeled system at a specific
time, allowing us to examine the system's behavior and interactions at that instant.

4.5.1 Notations Used in Object Diagrams –

4.5.1.1. Objects:

Objects in an object diagram represent existing entities in the system. They

depict specific instances and how items change over time through instance
specifications. Each object is represented by a rectangle in the object diagram, and
these objects are typically interconnected to show their relationships within the
system. Object diagrams provide a visual depiction of instances and their interactions,
capturing snapshots of the system's behavior at different points in time.

4.5.1.2. Links:

Links in a diagram act as metaphors for relationships. The end of each link
represents the total number of users involved. When a connection exists between two
classifiers, it is referred to as an association. The relationship between two objects is
32
described by a “link”. In graphical representation, a straight line is used to depict the
connection between two items.

A: android_user R: remote_user

#Name= “User1” #Name: “User2”

#Phone_Num: #Phone_Num:
“03123456789” “03223456789”

+display Start Receiver

button() -display location()
-view contact numbers() -display Wi-Fi()
-display module button() -display Bluetooth()
-view grant password() -display Wi-Fi Hotspot()

Figure 4.8 Object Diagram

4.6 Sequence Diagram

In a sequence diagram, the order of message delivery between objects is

depicted, as well as control structures between items. For example, in a college
scenario, lifelines can be used to represent an administration, a teacher, and a
student.

Sequence diagrams serve the purpose of illustrating the components in a

system or sequential interactions between objects. It also shows the specific order in
which these interactions take place. These diagrams present the actions taken by

33
various components of the system in a chronological manner. In order to understand
the requirements of both existing and new systems, they are used for documentation
by software developers. Sequence diagrams help in visualizing the flow of
communication and behavior among different elements of the system, making them
valuable tools for system design and analysis.

Sequence Diagram Notations:

Actors – Theses are external entities that interact with the system being
modeled. They represent specific roles or users that communicate with the system's
objects but are considered external to the system's boundaries. Actors are depicted
as stick figures and are located outside the boundary of the system on the diagram.

Actors play a crucial role in illustrating the system's interactions with external
entities, helping to clarify the system's boundaries and the communication between
the system and its users or external components. They provide a way to identify the
external actors involved in the system's processes and highlight the interactions
between these actors and the system's objects.

Lifelines – Lifelines in a sequence diagram represent specific participants or

instances involved in the interactions within the diagram. Each lifeline corresponds to
a particular occurrence or entity in the sequence diagram. Lifelines are positioned at
the top of the sequence diagram.

34
 To name a lifeline according to the UML standard, the format used is "Class
Name: Instance Name." This notation helps in identifying the class to which the lifeline
belongs and the specific instance or object it represents. By using lifelines, the
sequence diagram showcases the different entities and their interactions in a
chronological order, enabling a clear visualization of the sequence of events in the
system's processes.

4.6.1 Android User:

Figure 4.9 Android User Sequence Diagram

35
4.6.2 Remote User:

Figure 4.10 Remote User Sequence Diagram

4.7 Activity Diagram:

It is a type of behavioral diagram in UML that demonstrates how a system

behaves. From a start point to an end point it highlights the different decision paths

36
that are available and also illustrates the flow of control during the execution of the
activity.

The steps taken in a use case for the execution are also represented through
these diagrams. They are versatile and can model both sequential and concurrent
activities, making them suitable for visualizing workflows. These diagrams focus on
the flow and order of activities, allowing us to explain and depict the events leading up
to specific outcomes.

Overall, an activity diagram is a powerful tool for representing the control flow
and decision points in the execution of activities, providing valuable insights into the
system's behavior and processes.

Notations used in activity diagram are:

1. Initial State - The initial state represents the starting condition before an activity
takes place.

In the absence of nested activities, a process can have only one initial state. It
is depicted by a black-filled circle, symbolizing the state of an object upon its
creation. The Initial State in the UML Activity Diagram serves as both the entry
point and the first Activity State.

2. Action or Activity State - An action or activity state in the diagram signifies

the execution of an action on or by objects. It is depicted as a rectangle with
rounded corners, representing an activity. The activity state visually represents
any action or event that occurs within the system, providing a depiction of the
actions or operations executed during a process or behavior in the system.
3. Action Flow or Control Flows - Action flows and control flows are terms used
interchangeably to illustrate the paths or edges between activity states in the

37
 diagram. They visually depict the transitions from one activity state to another
within the system.

These flows illustrate the sequence of actions or activities and the control logic
that governs the flow of the process. By connecting the activity states with these
flows,

The diagram shows the progression of the system's behavior from one state to
another, offering a clear visualization of the process's execution and control
flow.

4. Decision node and Branching – The decision node is used in diagrams to

handle decision-making points where the control flow needs to be determined
based on certain conditions. It is represented as a diamond shape, and
conditions can be written on the arrows that leave the decision node. The
decision node always has two or more output arrows, signifying the different
possible branches or paths that the control flow may take depending on the
conditions evaluated at that point. This mechanism allows for branching in the
system's behavior, enabling different paths to be followed based on the
outcomes of the decision evaluation.
5. Fork – Fork nodes enable simultaneous operations. When utilizing a fork node,
two activities run concurrently, with no decision made before splitting the
activity into two parts. Both parts must be executed in the case of a fork
statement.
6. Join – Join nodes are used to merge multiple concurrent processes into one.
For join notations, there are two or more incoming edges and one outgoing
edge.
7. Final State or End State – The Final State or End State refers to the state that
the system reaches when a specific operation or action is completed. A system
or process may have various end states.

38
4.7.1 Android User:

Figure 4.11 Activity Diagram for Android user

39
4.7.2 Remote User

Figure 4.12 Activity Diagram for Remote user

4.8 Collaboration Diagram

A collaboration diagram, also referred to as a communication diagram, is a

graphical depiction of the connections and interactions among software objects in the
Unified Modeling Language (UML). These diagrams aid in understanding the roles

40
and functions of each object and demonstrate the dynamic behavior within a particular
use case.

The collaboration diagram displays the relationships between objects in a

system. It presents the data in a distinct manner compared to sequence diagrams, as
its main emphasis is on the structure and relationships of the objects within the system
rather than the flow of messages. Each object possesses various attributes, and the
collaboration diagram illustrates how these objects are interconnected with each
other. It provides a clear view of the object's architecture within the system,
highlighting their interactions and cooperation.

Overall, collaboration diagrams are valuable tools in object-oriented

programming, offering insights into the relationships between objects and helping to
understand the dynamic behavior and structure of the system. They complement
sequence diagrams by providing a different perspective on the interactions and
collaborations among software objects.

Notations of a Collaboration Diagram

1. Objects: Represented with an object symbol containing its name and class
separated by a colon. The name and class of the object are specified to identify
it.
2. Actors: Actors take a prominent role in the collaboration diagram as they
initiate the conversation. Each actor has a name and a part that pertains to
them.
3. Links: They represent instances of associations and establish relationships
between objects and actors. They depict connections used to transmit
messages and are represented by solid lines. Links facilitate navigation to other
objects and enable communication between objects. It also enables message
flows.
4. Messages: Messages are a form of communication between objects that
convey data and a sequence number to enable actions. They are symbolized
41
by labeled arrows placed next to links, indicating the flow of messages between
objects.

42
4.8.1 Android User:

Figure 4.14 Android User

43
 4.8.2 Remote User:

Figure 4.15 Remote User

4.9 State Transition Diagram

It displays all the potential states of an entity and the occasions when those
states can change (transitions), along with the conditions required for a transition to
occur. It is also known as a state diagram.

The state diagram is a behavioral diagram used to depict the status of a system
or its components at specific points in time. It uses state transitions to illustrate the
behavior of the system or component. State chart diagrams and State machines are
the terms used interchangeably with state diagrams.

44
 In essence, a state diagram represents how a class or entity behaves
dynamically over time in response to changing external stimuli. Typically, state
diagrams are preferred for modeling classes with three or more distinct states. These
diagrams are useful for understanding and visualizing the dynamic behavior of a
system or component, especially when it involves complex states and state
transitions.

Notations of a State Transition Diagram

1. Initial state: It is represented by a filled black circle; it denotes the starting

class or the state of the system.

2. Transition: Indicated by a solid arrow, it signifies the change of control or

transition from one state to another. The arrow's label describes the event
that triggered the state change.
3. State: Depicted as a rounded rectangle, it represents the conditions or
circumstances of a class or object at a specific point in time.
4. Final state: It is represented by a black colored circle within a circle, it
shows the end state of a state diagram. It denotes the completion of a
process or the termination of the system's behavior.

45
4.9.1 Android User:

Start

Main Activity
View Modules and Settings

SMS Receiver
Start SMS Receiver

Modules
Manage Modules

Phone Numbers
Manage Phone Numbers

Exit

Figure 4.16 Android User

46
4.9.2 Remote User:

Start

SMS app
Sends Commands

SMS Receiver
Command to app

Modules
Valid Command

Execution
Execute the syntax

Exit

Figure 4.17 Remote User

47
 CHAPTER 5
IMPLEMENTATION

18
5.1 Component Diagram

A UML component diagram provides a visual representation of how

physical components are organized and interconnected in a system. These
diagrams are commonly used to illustrate implementation details and ensure
comprehensive coverage of system functions during the planned development
process.

By breaking down a complex object-oriented program into smaller components, it

also enhances comprehensibility of the system. It draws the physical view of the
system, including internal components such as libraries, files and executables. The
diagram explains the connections and hierarchies that exist between the various
nodes or components, helping to create an operational system.

A component in the diagram refers to an individual, replaceable, and executable

system unit. Its implementation details are hidden, and it requires an interface to
perform its function. Essentially, a component acts as a "black box," with the
provided and required interfaces defining its behavior and interactions with other
components. Component diagrams are valuable tools for understanding the
relationships of physical nodes in a system and facilitating the design and
development process.

Notation of a Component Diagram

a) A component

19
 b) A node

Figure 5.1 Component Diagram

5. 2 Deployment Diagram

It illustrates the execution architecture of a system, including components

or nodes representing software or hardware execution systems, as well as
middleware that is providing the connection between them. These diagrams

20
describe the software and hardware components of a system.

It visually presents the hardware components that will be used to properly run the
application. It provides a static view of the system's deployment, showing the
nodes and the connections between them.

One of the main purposes of these diagrams is to determine how software is

deployed onto the hardware. Communication channels are used to depict the
connections between nodes, as multiple nodes are typically involved in the
deployment process.

Overall, a deployment diagram is a valuable tool for understanding the physical

execution architecture of a system, ensuring smooth deployment of software
components, and visualizing the relationships between hardware and software
elements in the system.

5.2.1. The Purpose of Deployment Diagram

The main purpose of the deployment diagram is to illustrate how software

components are installed and interact with hardware components to execute the
system. It focuses on showing the actual deployment of system components on
the hardware and the manner in which software interacts with the hardware during
its execution.

The hardware topology and the arrangement of hardware components are

the main focus of the deployment diagram. It helps in understanding how the
software components are allocated and executed on different hardware nodes,
showcasing the actual physical distribution and connection between hardware and
software elements in the system.

Following are the purposes of deployment diagram enlisted below:

1. Show the hardware topology of the system: The deployment diagram provides
a visual representation of the physical arrangement and configuration of

21
 hardware components in the system. It allows stakeholders to understand the
distribution of hardware nodes and their interconnections.

2. Represent the hardware components for software installation: The diagram

showcases the specific hardware components on which the software
components are installed and executed. It helps in visualizing how software is
deployed on various hardware nodes.

3. Describe the processing of components at runtime: The deployment diagram

illustrates the runtime behavior of the system's nodes. It shows how nodes
interact with each other during the execution of the software, providing insights
into the dynamic behavior of the system.

Figure 5.2 Deployment Diagram

22
 CHAPTER-6
TESTING (SOFTWARE QUALITY ATTRIBUTES)

23
6.1 Test Case Specification

The entire system has been tested, and every part functions both successfully
on its own and as a whole. The app is running without encountering any errors.

6.2 Black Box Test Cases:

Software testing, known as "black box testing," is a testing method of verifying

the functionalities of software without having access to the internal coding, how its
implemented, or internal data flow. In this method, the tester is only concerned with
the software's external behavior, and the testing process is solely driven by software
requirements and specifications.

The primary focus of this testing method is on the output and input of software.
Testers design test cases based on the expected inputs and expected outputs as
defined in the software requirements. They do not consider how the software
achieves its functionality but rather validate whether it behaves correctly based on
the specified requirements.

Black box testing is also sometimes called behavioral testing, as it emphasizes

testing the software's behavior in response to various inputs and scenarios. By
treating the software as a "black box," testers can evaluate its functionalities from an
end-user perspective and identify potential issues or discrepancies between
expected and actual behavior. This type of testing is particularly valuable for ensuring
that the software meets the intended requirements and functions as expected from a
user's standpoint.

70
 Figure 6.1 Black Box Testing

The following categories of errors are targeted by this method:

1. Jobs that are invalid or missing.

2. Data structure errors or external access to data.
3. Errors in behavior or performance.

6.2.1 Boundary Value Analysis

BVA (Boundary Value Analysis) is a black box testing method used to detect
errors that may occur at the edges of an input node. Test cases are designed to
assess the software's behavior when inputs are at the lower and upper boundaries,
as well as just outside those limits. The goal is to identify potential issues related to
handling boundary conditions and ensure the software's reliability and accuracy. BVA
focuses on critical points near the boundaries where errors are more likely to occur,
rather than within the valid range of inputs.

6.2.1.1 SMS Receiver Test Case:

SMS Receiver can be turned off and on by tapping on the start and stop
button.

Start = Starts the SMS receiver service. Starts the time and displays for how
long the SMS Receiver is working. Timer starts from zero and goes on until
stopped. The button changes to a stop sign.

Stop = Stops the SMS receiver service. Stops the timer and displays “not
running”. Timer goes back to zero. The button changes to a stop sign.

71
6.2.1.1.1 Start:

Table 6 Email

Button Timer Message

Service for receiving

Changes Starts
SMS Commands Started

6.2.1.1.2 Stop:
Table 6.1 Password

Button Timer Message

Receiver service
Changes Starts
stopped

6.2.2 Equivalence Class Partitioning

Equivalence Class Partitioning is a testing technique that involves evaluating

different equivalence classes for a given set of input conditions. When testing a
system, the input conditions are analyzed to identify different types of inputs. Each
type of input condition is then represented by an equivalence class, which defines a
set of valid or invalid states for that specific input condition. This approach helps in
reducing the number of test cases required for testing as only representative inputs
from each equivalence class need to be tested, instead of testing every possible input.
By selecting test cases from different equivalence classes, the testing process
becomes more efficient and effective in covering a wide range of scenarios.

72
 6.2.2.1 Test Case:

If input is the range of values, we have minimum 1 characters and maximum

255 characters for password. So, we have 2 invalid cases and one valid case as if we
enter 0 or 256 characters it would be invalid and if it is greater than 1 character and
less than or equal to 255 characters it will be valid.

Example:

Min 1 character & max 255 character

Password:
Test Case

1>=255
1 256 (Valid)
(Invalid) (Invalid)

Figure 6.1 Test Case Example

6.2.3 State Transition Testing

State Transition Testing is a software testing method that assesses how the
application's state changes when different inputs are provided. It involves modifying
input conditions and observing the corresponding state changes. The objective is to
ensure that the application transitions between states accurately and as intended.
State transition testing helps identify issues related to state changes and verifies the
application's behavior as it moves through different states in response to user inputs
or system events. This technique validates the application's logic and functionality
during state transitions.

73
 S3
Send
Command

S1
Reject

Valid
Command

S2 S4

Valid Execution
Phone Successfu
Number l

Figure 6.2 State Transition Diagram

Table 6.4 State Transition

State Command Validation Redirected

S1 1st Try Valid S2

S1 1st Try Invalid Failed

S2 2nd Try Valid S4

S2 2nd Try Invalid Failed

74
6.2.4 Decision Table Testing
It is a software testing method that is used to test the behavior of a system for
various inputs given to the system. Decision Table Testing follows a systematic
approach of documenting the different input combinations and their output in a tabular
form.

Table 6.5 Decision Table Testing

Phone Expected
Scenario Command Module Results
Number Outcome

Will not
Remote Not
Incorrect off execute no response
access Registered
command

Will not
Not
Incorrect on execute no response
Registered
command

Will not
Incorrect Registered off execute no response
command

Will not
Incorrect Registered on execute no response
command

Will not
Not Execution
Correct off execute
Registered Failed
command

Not Will execute Execution

Correct on
Registered the command Failed

Correct Registered off Will not Execution

75
 execute Failed
command

Will execute Execution

Correct Registered on
the command Successful

6.2.5 Graph Based Testing

It is a testing approach that involves creating a graph model for the program being
tested and then focusing on covering specific elements within that graph model.
Graphs are commonly used for abstraction in this technique and are considered
fundamental data structures in computer science.

Example:

Remote user access:

1. Remote user writes the SMS with the correct syntax and sends it from a valid
phone number that is registered in the app.
2. System check validation whether the command is correct or not correct.
3. Verification by module the phone number is stored in the module.
4. Final success/failure of the command execution.

76
 Remote
User Tries Command Phone Command
to Send Verificatio Verificatio Execution
Command n n Success
s

Accessing the
App Phone No
Registered

Invalid Command

Reject

Figure 6.3 Remote User Accessing

6.3 White Box Testing:

It is a form of testing in which the person who is testing completely aware of the
system's internal structure. The tester chooses the input for which the methods in the
code will be applied, and then determines the proper results. Information about the
system and how it is used is critical. From the end to the preceding amount, this is
done and checked for each field entry (Database). It is completed at the planning
stage. There are necessary improvements made to ensure that the modules in the
system perform efficiently in terms of the expected module departure.

All of the choices were thoroughly examined. The White Box exam is more
user-friendly and focuses on the system's details. This method is named after the
software system's resemblance to a white / visible box in the eyes of the tester; within
which one can clearly see.
77
6.3.1 Statement Coverage

It is a white box testing method that aims to execute all the lines in the source
code at least once. It is the measure of the percentage of code lines that have been
executed during testing. The goal is to ensure that every line of code is exercised
during the testing process.

By analyzing statement coverage, testers can determine the extent of code

execution and identify any parts of the source code that have not been exercised. This
information is valuable for assessing the completeness of testing and identifying areas
that may need additional test cases.

Achieving high statement coverage is important as it helps in uncovering

potential bugs and improving the overall quality of the software. However, it's essential
to complement statement coverage with other testing techniques, such as branch
coverage or path coverage, to ensure a comprehensive and effective testing strategy.

𝑁𝑢𝑚𝑏𝑒𝑟 𝑂𝑓 𝐸𝑥𝑒𝑐𝑢𝑡𝑒𝑑 𝑆𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡𝑠

Statement Coverage = × 100
𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡𝑠

271
Statement Coverage = × 100
271

Statement Coverage = 1 × 100

Statement Coverage = 100%

6.3.2 Branch Coverage

Branch coverage is a testing approach that ensures each possible branch

from decision points in the code is executed at least once. The objective is to
validate all reachable code and test both true and false branches for each decision.
This helps to ensure that the application behaves correctly under different conditions
and prevents any unexpected behavior. Achieving high branch coverage is crucial

78
for verifying code correctness and improving the application's reliability. However, it
should be complemented with other testing techniques for comprehensive test
coverage.

6.3.3 Path Coverage

It is a testing methodology in which test cases are created to execute all linearly
independent paths in the program at least once. A linearly independent path is defined
based on the control flow graph of the application.

By focusing on path coverage, testers aim to traverse all possible execution

paths within the program. This approach helps ensure that various combinations of
statements are tested, and potential defects or issues are identified across different
program paths.

Achieving path coverage is valuable in revealing complex logic errors and

providing a thorough assessment of the software's behavior under different scenarios.
It complements other testing techniques like statement and branch coverage to
achieve a comprehensive testing strategy for the application.

79
 CHAPTER-7
TOOLS AND TECHNOLOGIES

80
7.1 Programming Languages

Java, XML

7.2 Operating Environment

All Android Versions above android 4 can

7.4 TOOLS AND TECHNIQUES:

7.4.1 BACK END:

7.4.1.1 JAVA:

Java, a programming language, which was initially introduced by Sun Microsystems

in 1995. Over the years, it has undergone significant development and has become a
dominant force in the digital world, serving as a dependable platform for numerous
services and applications. Today, a substantial portion of the digital landscape relies
on Java as the foundation for building reliable and robust solutions. As the technology
landscape evolves, Java continues to be a pivotal player, supporting the creation of
cutting-edge products and digital services designed for the future.
Java's popularity remains unwavering, as it is extensively used for developing a wide
range of applications, including mobile apps, web apps, desktop apps, and games,
among many others. Its versatility and robustness make it a preferred choice for
developers across various domains and industries.

7.4.1.2 Android:

Android, a Google-launched open-source operating system, is built upon the

Linux kernel. In contrast to PC operating systems, mobile phone operating systems
face limitations due to hardware constraints, storage capacity, power consumption,
and mobility requirements. Consequently, applications developed for mobile phone
operating systems exhibit unique characteristics when compared to those developed
for PCs.
77
One prominent aspect of Android is its ability to allow one application to utilize
component elements owned by another application, provided that permission is
granted. To facilitate this functionality, the Android system launches the application
whenever any part of it is requested, and it instantiates the requested Java objects.
Unlike typical operating systems, Android applications lack a single-entry point (e.g.,
a main () function) for the entire application.

Android applications consist of four different types of application components, each

serving a specific purpose and adhering to a distinct lifecycle that governs its creation
and termination.

7.4.1.2.1 Activity:

An "Activity" in Android is a self-contained screen that displays a user interface and

handles user interactions. It represents a single window with a specific purpose, such
as showing content or receiving input. Activities manage their lifecycle, responding to
events like creation, pausing, and destruction. They enable seamless navigation
between different app screens and contribute to creating interactive and user-friendly
Android applications.

7.4.1.2.2 Service

A "Service" is a component that runs in the background without a user interface. It

performs tasks independently of the app's active user interface, such as handling
background operations, network requests, or playing music. Services are used to
execute long-running operations without disrupting the user experience and can run
even if the app is not in the foreground.

7.4.1.2.3 Content Providers

Content providers in Android offer a mechanism for sharing data among different
applications. The data that can be shared includes files, SQLite databases, or any
other data stored in a persistent location accessible by an application. To implement
a content provider, developers create a subclass of the Content Provider class. This
78
subclass defines the supported data format and provides a set of methods that allow
other applications to query or modify the data.

When an application needs to access the data provided by a content provider, it does
not directly call the content provider's methods. Instead, it uses an object called
Content Resolver to communicate with the content provider. The Content Resolver
acts as an intermediary and facilitates inter-process communication (IPC) while
sharing data with the content provider. This way, the Content Resolver collaborates
with the Content Provider to manage the sharing of data among different applications.

7.4.1.2.4 Broadcast Receivers

Broadcast receivers in Android are responsible for receiving system-wide broadcasts

and responding to the information transmitted by the broadcast. These broadcasts
can originate from the system itself, such as notifications for screen off or low battery
events, or they can be initiated by applications. Each broadcast receiver is
implemented as a subclass of Broadcast-Receiver.

While broadcast receivers do not have a user interface, they can create status bar
notifications to alert the user when a broadcast event occurs. However, their main
purpose is often to act as a "gateway" to other components and perform minimal
tasks.

In Android, there are four types of components: activities, services, broadcast

receivers, and content providers. Activities, services, and broadcast receivers are
activated by an asynchronous message called an intent. Intents allow individual
components to be bound to each other at runtime, even if they belong to different
applications. Intents can be created using an Intent object, which specifies the
messages to activate either a specific component or a specific type of component.

For activities and services, an intent defines the action to perform and may include the
URI of the data to act upon. In the case of broadcast receivers, the intent simply
specifies the announcement being broadcast. However, content providers are not
79
activated by intents. Instead, they are activated when targeted by a request from a
Content Resolver.

7.4.1.3 Android Studio:

Android Studio is a feature-rich integrated development environment (IDE)

specially tailored for creating Android applications. It offers developers an extensive
array of tools and resources to streamline the app development process. The user-
friendly interface ensures a smooth development experience, allowing efficient writing,
testing, and debugging of code. Advanced code editing features like code completion
and refactoring aid in producing clean and error-free code. The IDE also provides a
visual layout editor for easy customization of user interfaces. By seamlessly
integrating with the Android SDK, developers gain access to a vast array of libraries,
APIs, and resources, empowering them to build feature-rich and high-performance
Android applications. Whether you are a beginner or a seasoned developer, Android
Studio proves to be an indispensable tool in the Android app development journey.

7.4.1.4 SMS

SMS (Short Message Service), also known as "text messaging," is a

convenient service that enables users to send short messages of up to 160 characters
to mobile devices, such as cell phones and smartphones. This messaging system
functions similar to paging, but with the advantage that SMS messages do not require
the recipient's mobile phone to be active and within range at the time of sending.
Instead, the messages are stored and delivered once the phone becomes active and
within reach, ensuring that important communications are not missed even if the
recipient's device is temporarily unavailable.

7.4.1.5 GPS

The Global Positioning System (GPS) is a utility owned by the U.S. that offers
positioning, navigation, and timing (PNT) services to users. This system is composed

80
of three segments: the space segment, the control segment, and the user segment.
The user segment includes GPS receiver equipment, which receives signals from the
GPS satellites and utilizes the transmitted data to calculate the user's three-
dimensional position and time. By combining signals from multiple satellites, GPS
receivers can accurately determine the user's location, making it a valuable tool for
navigation and various applications.

7.4.1.6 Wi-Fi

Wi-Fi, short for Wireless Fidelity, is a wireless networking technology that

allows devices to connect to the internet and communicate with each other using radio
waves. It provides high-speed internet access without the need for wired connections.
Wi-Fi is based on the IEEE 802.11x standards, and it has become a widely used
technology for connecting laptops, smartphones, tablets, and other devices to the
internet in homes, offices, public places, and various other settings.

7.4.1.7 Bluetooth
Bluetooth is a wireless technology that enables data sharing over short
distances without the need for wires. It uses radio frequencies to establish connections
between devices and allows them to communicate and exchange data. Bluetooth is
commonly used in mobile devices to share files, connect with other Bluetooth-enabled
devices such as headphones or speakers, and facilitate data transfer between devices
in a convenient and cable-free manner.

7.4.1.8 Regular Expression

Regular expressions are a notation used to describe sets of character strings.

When a particular string belongs to the set described by a regular expression, it is
said to match the expression. The most basic regular expression consists of a single
literal character.

This project proposes incorporating regular expression pattern matching as a

fundamental feature in programming languages for manipulating XML and similar tree-
81
structured data formats. It enhances conventional pattern-matching capabilities by
introducing regular expression operators like repetition (*) and alternation (|) that can
match complex sequences of subtrees, allowing for efficient data extraction from
intricate structures.

Regular expressions have a rich history in computer science, showcasing how sound
theoretical concepts can lead to effective programs. Originally developed as a simple
computational model by theorists, Ken Thompson introduced them to programmers
through his implementation of the text editor QED for CTSS.

7.4.2 FRONT END:

7.4.2.1 XML:

XML (Extensible Markup Language) is a widely used markup language that

serves as a standard for structuring and organizing data. It is designed to be both
human-readable and machine-readable, making it ideal for storing and exchanging
information. In XML, data is stored in a hierarchical format using tags to define
elements and attributes to provide additional information about those elements. This
structured approach allows for the efficient organization, validation, and sharing of
data across different systems and platforms. XML is not tied to any specific
programming language or platform, making it highly versatile and compatible. It is
commonly used in various domains, including web development, data storage,
configuration files, and interoperability between different systems. With its simplicity
and flexibility, XML continues to be a fundamental technology for data representation
and exchange in the digital age.

XML is a markup language used for structuring and organizing data, including
the representation of hierarchical data and metadata.

In the context of Android app development, XML is commonly used for defining
the layout and structure of user interfaces through XML layout files. These XML files
describe the arrangement and properties of UI elements (views) within an activity or
82
fragment. XML is used as a declarative markup language to define the visual
hierarchy, attributes, and properties of UI elements.

While XML is not a programming language itself, it plays a crucial role in front-
end development for Android apps by providing a descriptive way to define the user
interface and its properties. The XML layout files are then inflated and rendered by the
Android framework at runtime to create the actual user interface.

7.4.2.2 Java:

Java is widely regarded as the front-end language for Android app

development. In the Android ecosystem, Java is used to implement the user interface
components that form the visual and interactive elements of an app. Activities and
fragments, which represent screens and windows, are written in Java and contain the
front-end logic for initializing and managing the UI. Java classes are also utilized to
create and customize UI elements such as buttons, text fields, images, and lists
programmatically. XML layout files define the structure and appearance of these UI
elements, and Java code is responsible for inflating and interacting with them. Java
handles event handling by attaching event listeners to UI components and
implementing methods to respond to user interactions. Furthermore, Java can be
combined with Android's data binding library to seamlessly integrate data with the
front-end UI. Overall, Java's versatility and integration with the Android platform make
it a popular choice for developing the front-end of Android apps.

83
 Appendix A: User documentation

7.5 Appendix A

7.5.1 User documentation

In our user manual, we aim to provide comprehensive information about our

product in a way that is easily understandable for new users. Whether someone is
using our product offline or online, we will offer clear and detailed guidance to ensure
that it becomes a valuable tool for any user. Our help section will provide step-by-step
instructions to assist users in navigating through the product and making the most of
its features. Our goal is to make the learning process smooth and enjoyable, enabling
users to utilize our product efficiently and effectively.

RAD or Remotely Access Device is an android application that allows the user to
remotely access and control android devices using SMS.

7.5.2 USER MANUAL

7.5.2.1 Home Screen

Home Screen is the main screen that welcomes the user. It shows all the
functionalities the app provides and interface to configure each functionality.

At the top of the screen there is a button to the right of the “Sms Receiver”, which
enables or disables the SMS Receiver service for the app. Once the SMS Receiver
is started you will be able to control the Android device remotely through SMS.
Turning on the SMS Receiver also enables a timer that shows for how long the
SMS Receiver has been working.

To the right corner of the app there appears the three vertical dots icon for options.
It allows the user to make configurations to the app, inspect the RAD’s history by
looking at logs and check for dangerous behavior. Help tour will guide you about
the app and how it works. You can also learn how to control the Android device by
sending the commands through SMS.

84
Figure 7.1 Home Screen

2
7.5.2.2 SMS Receiver

The receiver is listening for incoming text messages and executing the received
commands. It can be started and stopped manually by clicking the right next to it.

Below the SMS Receiver there is the list of all available modules that the RAD
provides. The User can configure each module separately. It can enable and
disable modules of its choice. Each module allows the user to add, remove or edit
the phone numbers.

Figure 7.2 SMS Receiver

3
7.5.2.3 Modules

The control functions are grouped into modules. Each module contains one or
multiple commands (e.g., enable hotspot, disable hotspot). All the enabled
modules are represented with a green tick and disabled modules are represented
with a gray dash.

Figure 7.3 Modules

4
7.5.2.4 Audio Module

The audio module works with the audio of the android phone. It manages the
volume of the ringtone, music and more.

Figure 7.4 Audio Module

5
7.5.2.5 Battery Module

This module allows the user to get the battery percentage of the device and check
whether it is charging or not.

Figure 7.5 Battery Module

6
7.5.2.6 Bluetooth Module

Bluetooth Module allows the user to turn Bluetooth ON and OFF of the remote
android device.

Figure 7.6 Bluetooth Module

7
7.5.2.7 Display Module

It is used to manage the display’s brightness and state ON or OFF. It is also used
to set the time after which the display will be turned off when the user is not
interacting with the device.

Figure 7.7 Display Module

8
7.5.2.8 Grant Phone Remotely Module

It grants a phone number access to the device remotely. The phone number
sending the grant command will be added to the list of granted phones for the
specified module (or all modules when using the all keyword). If access is no longer
necessary afterwards, the android user can remove the phone number from the
list of granted phones in the relevant module(s).

Figure 7.8 Grant Phone Remotely Module

9
7.5.2.9 Location Module

It is used to get the location of the android device.

Figure 7.9 Location Module

10
7.5.2.10 Play Sound Module

It is used to play the ringtone for a specified time duration.

Figure 7.10 Play Sound Module

11
7.5.2.11 Wi-Fi Module
It is used to turn Wi-Fi ON and OFF and to know whether the Wi-Fi is turned ON
or OFF.

Figure 7.11 Wi-Fi Module

12
7.5.2.12 Wi-Fi Hotspot Module
It is used to turn Wi-Fi Hotspot ON and OFF and to know whether the Wi-Fi Hotspot
is turned ON or OFF. The hotspot must be pre-configured in the system settings.

Figure 7.12 Wi-Fi Hotspot Module

13
References
1. Advanced Wireless Planet, SMS Text Mode. Accessed 27.04.2014.
http://www.gsm-modem.de/sms-text-mode.html/
2. Advanced Wireless Planet, SMS PDU Mode. Accessed 27.04.2014.
http://www.gsm-modem.de/sms-pdu-mode.html/
3. ARC Electronics, RS232 Tutorial on Data Interface and cables. Accessed
21.02.2014. http://www.arcelect.com/rs232.htm/
4. DS18S20 Datasheet.
http://www.maximintegrated.com/en/products/analog/sensors-and-
sensorinterface/DS18S20.html
5. 4G Americas, GSM Global System for Mobile Communications. Accessed
22.03.2014.
http://www.4gamericas.org/index.cfm?fuseaction=page§ionid=242
6. GSM Intelligence, Definitive data and analysis for the mobile industry.
Accessed 22.03.2014. https://gsmaintelligence.com/
7. GSM 07.07 document.
http://www.etsi.org/deliver/etsi_gts/07/0707/05.00.00_60/gsmts_0707v050000p.p
df
8. MZ2P10AE Datasheet.
http://www.carlogavazzisales.com/pdfs/switchingprod/Mz2p10ae.pdf
9. Osborne, A. 1980. An Introduction to Microcomputers. Volume 1: Basic
Concepts (2nd Ed.). Berkeley, California: Osborne-McGraw Hill
10. Jianye Liu, Jiankun Yu. Research on Development of Android Applications
11. OL. Google Android Developers, Android Developer Guide,
http://developer.android.com/guide/topics/fundamentals.html
12. Haruo Hosoya, Benjamin Pierce, Regular Expression Pattern Matching for
XML
13. Russ Cox, Regular Expression Matching Can Be simple and Fast (but is slow
in Java, Perl, PHP, Python, Ruby,)
14. Extensible markup language (XMLTM). http://w3.org/XML/

14
15. XML Schema Part 0: Primer, W3C Working Draft.
http://www.w3.org/TR/xmlschema-0/ , 2000
16. Nils Klarlund, Anders M¢ller, and Michael I. Schwartzbach. DSD: A schema
language for XML. http://www.brics.dk/DSD/
17. RELAX (REgular LAnguage description for XML). http://www.xml.gr.jp/relax/
18. https://www.java.com/en/download/help/whatis_java.html

15