Controlling PC via cell phone SRS documentation

Controlling Computer Through Cell phone SRS

Table of Contents

1) Introduction……………………………………………………21.1) Purpose of SRS………………………………………….21.2) Scope of Product………………………………………...31.3) Definitions, Acronyms, and Abbreviations……………..31.4) References……………………………………………….41.5) SRS Document Overview……………………………….4

2) General Description……………………………………………52.1) Product Perspective (System Model)……………………52.2) System Functionality…………………………………….52.3) User Characteristics……………………………………..62.4) General Constraints………………………………………72.5) Assumptions and Dependencies…………………………7

3) Specific Requirements…………………………………………73.1) Functional Requirements…………………………………8

3.3.1) Use case Specifications……………………….93.2) External Interface Requirements…………………………10

3.2.1) User Interfaces……….………….……………103.2.2) Hardware Interfaces………………………….103.2.3) Software Interfaces……………………….….10

3.3) Non-Functional Requirements……………………………10

4) Progress………………………………………………………….10

5) Background Study………………………………………………14

6) Discussion & Conclusion……………………………………….15

1


1. Introduction

This application provides control of computer via cell phone. The main objective of this project is to view computer desktop screen from cell phone and access it via cell phone. Our application will have two modules:

Computer module

In this module computer system will act as a receiver and sender. Computer will share screen and send update of screen to cell phone. Computer module will be able to receive the data, process it and will response as directed by cell phone application. Cell phone module

Cell phone module will provide interface to user. The interface includes the desktop graphical user interface (GUI) of computer with which cell phone phone is paired. User can give input; Cell phone application will extract the input and will transfer to computer module.

Figure 1 System diagram

1.1 Purpose of SRS

This is the software requirements specification for Control Pc through cell phone. This document is primarily intended to provide detailed specifications of the functional requirements and non functional requirements of product. The

2


requirements are illustrated with the help of Uml diagrams and images. The SRS will facilitate everyone who wants to proceed our work or want to research on remote desktop sharing, controlling devices remotely or using Bluetooth technology.

1.2 Scope of Product

This project is named as “Controlling Pc through Cell Phone”. The project is limited to two devices having Bluetooth technology at both end for sending and receiving. The project includes work on Advance GUI (Graphical User Interface) Programming for cell phone application and computer application, network programming.

The application should able to share desktop of computer on cell phone. The user can provide input from cell phone. The computer and cell phone will be paired using Bluetooth. Bluetooth device will be built-in available in computer and cell phone. In case of desktop computer separate Bluetooth device can be used.

1.3 Definitions

Graphical User Interface

A user interface based on graphics (icons and pictures and menus) instead of text; uses a mouse as well as a keyboard as an input device.

Symbian Operating System

Symbian OS is an operating system (OS) designed for cell phone devices and smartphones, with associated libraries, user interface, frameworks and reference implementations of common tools, originally developed by Symbian Ltd.

Personal Data Assistants

A lightweight consumer electronic device that looks like a hand-held computer but instead performs specific tasks; can serve as a diary or a personal database or a telephone or an alarm clock etc.

3


1.3.1 Abbreviations

GUI – Graphical User Interface

PAN- Personal Area Networks

ISM- Industrial Scientific & Medical band

SOS – Symbian Operating System

J2ME- JAVA 2 Micro Edition

PADs- Personal Data Assistants

PC- Personal Computer

JVM- Java to Virtual Machine

1.4 References

[1]. http://en.wikipedia.org/wiki/Bluetooth

[2] http://en.wikipedia.org/wiki/Symbian_OS

[3] http://java.sun.com/developer/technicalArticles/javame/javafxcell phone- javame/

[4] http://www.cse.iitm.ac.in/~ragav/SE_LAB_2007/Group_17/docs/SRS.pdf

1.5 SRS Document Overview

In this document we are trying to discuss the detail requirements of the application. Although the importance of SRS can’t be underestimated. It is the first milestone which establishes the basis between customer and supplier. The document is divided in three parts to discuss application in detail.

General description: In this chapter all the functionality and behavior of application is discussed. How the system will behave with external world or user. The way it will get input from user, also in this phase constrains that could be occur. It includes hardware constraints as well as software constrains.

4

http://www.cse.iitm.ac.in/~ragav/SE_LAB_2007/Group_17/docs/SRS.pdf

http://java.sun.com/developer/technicalArticles/javame/javafxcell%20phone-%20%20%20%20%20%20%20%20%20%20%20%20%20%20javame/

http://java.sun.com/developer/technicalArticles/javame/javafxcell%20phone-%20%20%20%20%20%20%20%20%20%20%20%20%20%20javame/

http://en.wikipedia.org/wiki/Symbian_OS

http://en.wikipedia.org/wiki/Bluetooth


Introduction: In introduction purpose of SRS will be discussed. The need of project and the background of project will be discussed. A list of abbreviations will be mentioned. Also the definitions that is useful for readers. Simply the helping material and introduction of project will be provided in this particular section of SRS.

Specification Requirements: This section includes the functional and nonfunctional requirements. All the information regarding to functionality of product, the interface provided to user, the interaction of software with hardware etc. The requirement will be extract by using background study of project, as product is a generic application.

2 General Description

The application is based on communication of pc and cell phone using Bluetooth technology. The application will be capable of sharing pc screen on cell phone. The pc will be controlled by cell phone; almost all tasks can be performed via cell phone.

According to background study the GUI used for such application was complex. Our goal is to reduce the complexity of interface and user can use it more easily as compare to previous applications.

2.1 Product Perspective (System Model)

The system model consists of a computer and a cell phone; it provides GUI for both applications. Both the devices are J2ME enabled and cell phone can support the symbian operating system. Users will interact with this product in a manner similar to the normal GUI interfaces.

The instruction sent between computer and cell phone is make compatible with each other so that they can be translated into high level and low level language. For this JVM (Java Virtual Machine) is used as a middleware for both modules.

2.2 System Functionality

The users of this product are expected to know the basic operation of the Pc & cell phone. They should have a basic idea to use a GUI familiarity with navigating menus. Using tabs, buttons and other control interfaces is also necessary because pc can be controlled by cell phone joy stick & all the actions are controlled from cell phone. The cell phone will be simple Nokia cell phone containing symbian operating system having built-in Bluetooth device.

5


The functionality can be clear by swim lane diagram which is mentioned below in figure 2.

Fig 2 Swim lane diagram

The diagram shows communication between two modules the connection between them is required. For establishing connection the cell phone module

6


generate s and send request to Pc, the pc have two conditions in this phase. One, if Pc accepts the request then connection is established, if rejects than connection will redirected to initial state to discover devices again. When connection is created then Pc will capture screen and will map the snap shots and send them to cell phone. The cell phone receives snap shots, resize them and display on screen. Then it waits for user inputs, when user performs any action on interface, the action will be forwarded to computer module. Computer will perform according to instruction. The screen of cell phone will be updated according to new status of pc screen. The updating will perform after checking the connection status, if found connected than update screen otherwise not.

2.3 User Characteristics

Analyzing user characteristics is an important part of any project. It allows the team to clearly define and focus on who the end users are for the project to ensure the team is still writing the product for correct users.Users will have no access to source code of the project; they also don’t need to limit the size and complexity of application. The user must know how to deal with windows GUI, familiar with cell phone interface and have little knowledge about Bluetooth usage.

2.4 General Constraints

The system should allow the dynamic addition of new items .This means that the user can add new items to cell phone screen through the interface and the system should be able to handle them without requiring the software to be restarted each time. Another important issue is that the settings of the software should not change between successive runs of the software. Each time when new snap shot is accessed than its screen is updated to cell phone screen but this action does not occur rapidly.

Speed: Bluetooth is not designed for high-speed data transfers.

Compatibility: Some devices do not have profiles compatible with the devices that want to connect with.

Coverage: Bluetooth only has an amount of range about 30 ft.

Scalability: Bluetooth based network is not so scalable it can only support 8 devices at a time.

Snapshots: Screen will be slowly updated on cell phone because of Bluetooth data rate and limited cell phone capabilities.

7


Screen Size: The screen size of computer is larger than screen of cell phone so the snap of the computer screen has to resize.

2.5 Assumptions and Dependencies

PC( Personal Computer ) compatible running Windows

128MB RAM or more is recommended.

Graphics card 128 or more.

Processor 1.0 GHz.

Cell phone Phone with symbian operating system.

3 Specific Requirements

The specific requirements include:

3.1 Functional Requirements

The functional requirement is to provide a robust and manageable system. A system should provide a complete control of Pc via cell phone. The Pc screen should be displayed on the cell phone screen. The user control Pc through the snapshots which are displayed on the cell phone screen.

The use case diagram shown below describes the functional requirements. The user needs to discover devices which are present around.

8


9


Among many devices user should be able to sent request to anyone particular device. The pair should be made if other device accepts the paring request. As it is mentioned in introduction that the application will have two modules, one is Pc side module and other is cell phone. Now Pc module will capture the snapshot of Pc screen and will sent to cell phone module. Also the mapping of picture will be performing. Mapping will transform certain area of screen into icons, simply mapping will differentiate the icons, once image is received by cell phone module it will resize it and will display on cell phone screen. Cell phone screen will extract input from user and will sent instructions to Pc module. Pc module will act as directed in instructions carrying form cell phone module. Screen of cell phone will update every time after any action is performed on Pc.

3.1.1 Use case Specifications

Cell phone module will search for devices. The Pc module should run and accepts the request of cell phone. List of Bluetooth devices will be shown on cell phone screen. User will select one among all the discovered devices. Pc module can accept or deny the received request. After the paring between both cell phone and Pc is completed than

communication can proceed. Pc module will create snapshots of its screen. The snapshots will be mapped and compress for fast and reliable

exchange. Pc module will check the Bluetooth connection if it is not active, it

will alert the user. The snapshots will be transmitted on Bluetooth channel, as it is

specified in Bluetooth stack IEEE 802.15. The snapshots will be received by cell phone module.

10


Cell phone module will receive the snapshots according to screen of cell phone. Although the different cell phone have different screen sizes.

After receiving snapshot, it is ready to display on screen. Cell phone module will display it on cell screen.

User can input instructions via snapshot. Actually snapshot will be the current state of Pc, as the state of Pc screen changes the snapshot will be update.

The input extracted from user (instruction) has to send to Pc module suing Bluetooth.

Pc will receive the snapshot. It will read the instruction then user desire action will be performed.

When Pc module will perform the user desire action, the Pc’s screen will be changed. As a result new uploaded state of screen will be forwarded to cell phone. This process will be repeated until connection I established and user perform action.

3.2 External Interface Requirements

The external interface requirements include:

3.2.1) User Interfaces

The user interface is that part of a program that interacts with the user of the program. The interface can be accessed primarily using a mouse (joy stick) of the cell phone. The interface of the pc is available on the cell phone screen. User can perform his desire action and the snap shots will be updated on cell phone as screen of computer changes. Cell phone provides full remote control activities for a pc.

3.2.2 Hardware Interfaces

The user has to deal with two hardware, cell phone and Pc. The interface between both hardware and the medium use to exchange data is Bluetooth. The data will be received and sent by creating ports on Pc side. Once the ports are created the hardware (cell phone and Pc) can share and exchange data.On a cell phone side, built-in Bluetooth features will be used to establish connection and exchange data.

3.2.3 Software Interfaces

11


For Pc module there can be any version of windows which supports Bluetooth protocol stack while cell phone should have symbian operating system. No third party application is required for product.

3.3 Non-Functional Requirements

The GUI of product will be interactive and simple so the layman can use it easily. No complex GUI is displayed, the user inter face will be as simple as he can understand it easily. The interface includes light and attractive colors, background and animations so user will not get bored while using this product and feel more comfort to achieve services in easy way. Every time when screen is updated a beep is use as alert. Every time when connection breaks or reconfigured, a message will be displayed as alert.

4. Progress

The work was achieved in 2 phases. The 1st phase is documentation & the

2nd is implementation. The documentation was divided into three modules i-e

i. Proposalii. Feasibility Report

iii. Software Requirement Specification

In proposal, the basic idea of project is discussed, scope is defined, and

stake holders are identified. Project boundaries’ are illustrated. Need of project is

properly addressed. Functionalities are defined that how it can work, in which en-

vironment & which things are necessary to achieve this service. What are the bene-

fits of this application; how it is more beneficial for users, what are the necessary

requirements for the working of this application etc all things are properly ad-

dressed.

In feasibility report, the constraints of project are identified and defined,

the objective is properly addressed that why such an application is created, how it

make the work of user more comfortable & easier, how user can use it, for which

purpose it is used, what its usability is? Hardware & software requirements are de-

fined. Time is addressed to achieve things and so on.

In software requirement specification, document is primarily intended to provide detailed specifications of the functional requirements and non functional

12


requirements of product. The requirements are illustrated with the help of Uml, activity diagrams and images. The SRS will facilitate everyone who wants to precede our work or want to research on remote desktop sharing, controlling devices remotely or using Bluetooth technology.

The implementation phase is achieved by

i. IDE Java IDE adds CORBA (Common Object Request Broker

Architecture) capability to the Java platform, providing standards-based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP (Internet Inter-ORB Protocol).

ii. Personal Profile

Interfaces for Symbian Operating System Series 80 Platform SDKs for Symbian OS, for Java

Series 80 Developer Platform 2.0 SDK For Symbian OS - Personal Profile is the software development kit for developers creating Personal Profile Java applications for Nokia Platform compliant phones. The product consists of a phone emulator, application programming interfaces (API's) & documentations.

iii. AWT

The Java programming language class library provides a user interface toolkit called the Abstract Windowing Toolkit, or the AWT. The AWT is both powerful and flexible. The Abstract Window Toolkit (AWT) is Java's original platform-independent windowing, graphics, and user-interface widget toolkit. The AWT is now part of the Java Foundation Classes (JFC) — the standard API for providing a graphical user interface (GUI) for a Java program.

The user interface is that part of a program that interacts with the user of the program. User interfaces take many forms. These forms range in complexity from simple command-line interfaces to the point-and-click graphical user interfaces provided by many modern applications.

At the lowest level, the operating system transmits information from the mouse and keyboard to the program as input, and provides pixels for program output. The AWT provides a well-designed object-oriented interface to low-level services and resources. The Java programming

13


language is platform-independent; the AWT must also be platform-independent. The AWT was designed to provide a common set of tools for graphical user interface design that work on a variety of platforms. The user interface elements provided by the AWT are implemented using each platform's native GUI toolkit, thereby preserving the look and feel of each platform. This is one of the AWT's strongest points.

The disadvantage of such an approach is the fact that a graphical user interface designed on one platform may look different when displayed on another platform.

The AWT provides two levels of APIs:

A general interface between Java and the native system, used for windowing, events, layout managers. This API is at the core of Java GUI programming. It contains:

The interface between the native windowing system and the Java application; The core of the GUI event subsystem; Several layout managers; The interface to input devices such as mouse and keyboard; and A java.awt. data transfer package for use with the Clipboard and Drag and Drop.

A basic set of GUI widgets such as buttons, text boxes, and menus. It also provides the AWT Native Interface, which enables rendering libraries compiled to native code to draw directly to an AWT Canvas object drawing surface. AWT is also the GUI toolkit for a number of Java ME profiles. The figure of AWT is mentioned below in figure number 3.

14


(Figure 3)

Components and containers

A graphical user interface is built of graphical elements called components. Typical components include such items as buttons, scrollbars, and text fields. Components allow the user to interact with the program and provide the user with visual feedback about the state of the program. In the AWT, all user interface components are instances of class Component or one of its subtypes.

Components do not stand alone, but rather are found within containers. Containers contain and control the layout of components. Containers are themselves components, and can thus be placed inside other containers. In the AWT, all containers are instances of class Container or one of its subtypes.

iv. API The Java APIs for Bluetooth is a Java ME specification for APIs that

allow Java midlets to use Bluetooth on supporting devices. The specification was developed under the Java Community Process as JSR 82. The API for Bluetooth is Bluetooth JSR82 API package. Java APIs described in the JSR-82 interface for following Bluetooth Protocols/Profiles:

15


SDAP - Service Discovery Application Profile RFCOMM - Serial Cable Emulation Protocol L2CAP - Logical Link Control and Adaptation Protocol GOEP - Generic Object Exchange (OBEX) Profile

The most famous wireless technologies are infrared, Bluetooth, WiFi, and Zigbee. Infrared is the technology that y can see in TV remote controls or air conditioner remotes where the communication should be pointed to the target device. WiFi technology is used for strong and wide area communication where wireless communication can be made. Zigbee is the most recent technology; it's cheaper than all the other wireless media. Bluetooth technology is the most used temporary communication technology, especially inside mobile devices, palm tops, pocket PCs, and so forth. It can be used to exchange objects, packets, or a simple stream.

Bluetooth Communication Types

There are three types of communication protocols defined inside Bluetooth technology:

i. OBEX: The "Object Exchange" communication protocol is used to exchange physical data such as files, images, and so on in binary format.

ii. L2CAP: The "Logical Link Control and Adaptation Protocol" used to send packets between host and client.

iii. RFCOMM: The "Radio Frequency Communications" is very easy and uncomplicated; it is used to stream simple data.

Java Bluetooth API

Sun Java has introduced the Bluetooth JSR82 API package. The JSR82 API has capability to provide all three kinds of communications: Obex, L2CAP, or RFCOMM. This article will focus on the simplest protocol, RFCOMM, and send only string data between the devices.

16


Bluetooth and J2ME MIDP

The above figure illustrates the relationship between the Java APIs for Bluetooth and the J2ME platform, using the Mobile Information Device Profile (MIDP) and Connected Limited Device Configuration (CLDC) stack. At the bot-tom of the stack are the hardware, operating system, and Bluetooth stack.

Bluetooth API

Client and Server

17


The technique to communicate any device will follow the good old-fashioned rule of Client and Server. You will open the Server and then wait for the client to connect; after that, the server and client both can communicate with each other easily. In Bluetooth, you have to do the same technique; the application must allow the user to select it as either the server or client.

5. Background Study A lot of work on this project has been done by different developers. Some

work of them are illustrated below.

Mobilewitch Bluetooth Remote Control is a free utility that lets to control computer from a distance through cell phone. Now user can easily remote control his PC just like remote control for TV. Now cell phone becomes a universal PC remote control. This is for everyone-the professionals and non professionals, for business use as well as for enjoyment purpose as shown in figure below.

PTvncS will allow controlling PC from Smartphone via GPRS or wireless network across the Internet. Provide full control of Windows PC. Includes file transfer to and from. Left and Right mouse button support including click-and-drag. Compatible with all Windows 95/98 and NT/2000/XP operating systems.

JM2PC is application to remotely access PC or laptop from mobile phones. It works with Bluetooth & client server technology. Need to install JM2PC server on PC or laptop then install client application on cell phone. Just it, then user have access

18


and edit files, start and stop applications, control mouse, keyboard and other devices. JM2PC only support java platform.

6. Discussion & Conclusion

Alhamdulillah we have finished with our documentation phase which includes Proposal, Feasibility report and SRS. All the required data of develop this application has been extracted & our vision towards functional and non-functional requirements, purpose of project is clear.

As it concern with implementation, a platform for coding our application is set, required interfaces & APIs has been imported. The complete documentation of IDE (which we selected for our application i-e Net been) has been studied by us. So we are satisfied from IDE that it will work for us to specific project & is suitable option for implementation. It has many built-in libraries & APIs through which this project is possible.

As our documentation is completed on time so we are hopeful for complete the implementation phase in next four months & our project will provide all the functional & non-functional requirements Inshallah.

19

Controlling PC via cell phone SRS documentation

Documents