coba coba

BAB III

ANALISA DAN PERANCANGAN SISTEM

Bab ini akan membahas mengenai analisa dan perancangan sistem. Analisa dilakukan

untuk merumuskan mengenai spesifikasi sistem yang akan dibuat dan hasil dari

analisa tersebut akan diterjemahkan menjadi sebuah desain / rancangan yang bisa

langsung diimplementasikan secara fisik.

3.1. Analisa Permasalahan

Tahapan analisa ini dilakukan untuk mengetahui requirement yang dibutuhkan untuk

merancang sebuah sistem LBS ini. Requirement yang dihasilkan dapat berupa sebuah

gambaran besar mengenai bagaimana sistem ingin dipergunakan, dan kemudian

mengidentifikasikan komponen-komponen yang dibutuhkan.

Sistem LBS yang akan ditawarkan adalah sebuah sistem LBS yang mampu bekerja

dalam ruangan. Sistem ini mampu mengidentifikasikan lokasi seseorang berdasarkan

mobile device yang dimilikinya. Teknik location sensing yang digunakan dalam

sistem ini adalah teknik proximity. Teknik ini dipilih karena kompleksitasnya lebih

rendah dibandingkan teknik lain dan diperkirakan lebih handal untuk digunakan

dalam ruangan.

Sarana yang dipergunakan untuk melakukan pelacakan akan keberadaan mobile

device tersebut adalah teknologi nirkabel Bluetooth. Teknologi Bluetooth dipilih

karena harganya relatif murah jika dibandingkan teknologi wireless lainnya, praktis

untuk digunakan, dan banyak tersedia di ponsel-ponsel yang beredar di pasaran.

Sebagai sarana middleware yang digunakan untuk melakukan komunikasi antara

Bluetooth dan server pusat adalah web service. Web service dipilih karena memiliki

tingkat kompleksitas yang rendah, selain itu teknologi web service merupakan

20Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004

teknologi middleware yang paling banyak didukung oleh vendor-vendor software

karena sifatnya yang open / terbuka.

Stand C

Stand A Stand B

Stand D

Stand E Stand F

Mobile Client

Bluetooth Access Point

Web Service

LBS Server

Service Gateway

Gambar 3.1. Implementasi Sistem LBS pada Pameran

Gambar diatas menunjukkan sebuah sistem LBS yang diimplementasikan pada

sebuah pameran. Dari gambar tersebut ada 3 buah komponen yang patut diperhatikan,

yaitu Bluetooth access point, LBS server, dan mobile client.

Bluetooth access point digunakan sebagai sensor dan sarana pertukaran data tersebar

dengan merata agar melingkupi seluruh area pameran. Bluetooth access point

memiliki bagian bernama service gateway yang berfungsi untuk melakukan

komunikasi dengan server. Seluruh Bluetooth access point terkoneksi ke sebuah

jaringan internal. Melalui jaringan ini service gateway dapat mengakses web service

untuk meminta layanan-layanan informasi kepada LBS Server.


3.2. Perancangan Sistem Tahapan desain ini merupakan tahapan dimana seluruh hasil kegiatan analisa dan riset

dipilih dan dirancang agar membentuk sebuah solusi sistem LBS yang bisa

diterapkan.

3.2.1 Arsitektur Sistem

Skema arsitektur sistem LBS yang diperoleh dari gambar analisa dapat dilihat pada

gambar 3.2.

Gambar 3.2 Arsitektur Sederhana Sistem LBS

Dari gambar 3.2. sistem LBS dapat dibagi menjadi 3 bagian utama, yaitu LBS server,

service gateway, dan klien. Berikut adalah penjelasan dari ketiga bagian tersebut :

LBS server merupakan bagian pemrosesan data dan operasi layanan informasi. Bagian ini terdiri dari application server sebagai pemrosesan

business logic, web server sebagai penyedia layanan informasi, dan server

basis data sebagai pusat penyimpanan data.


Service gateway merupakan bagian pemrosesan dari sebuah Bluetooth access point. Fungsi dari bagian ini adalah perantara antara klien dan server. Fungsi

utamanya adalah melakukan hubungan wireless dengan klien dan meneruskan

permintaan atau perintah dari klien ke server untuk kemudian diterjemahkan.

Subsistem service gateway ini terintegrasi ke dalam Bluetooth access point

atau dapat dijadikan sebuah dedicated server yang tersambung ke banyak

dongle Bluetooth.

Mobile Client merupakan konsumen dari layanan informasi. Klien merupakan mobile device (PDA/HP) yang dilengkapi Bluetooth dan MIDP, sehingga bisa

menjalankan aplikasi mobile client. Pada dasarnya aplikasi klien ini bersifat

sebagai presentation layer, yaitu hanya menampilkan informasi dan

mengirimkan permintaan kepada service gateway, sedangkan seluruh

pemrosesan yang diperlukan dilakukan di sisi server.

Ketika klien berada di jangkauan gateway, aplikasi klien melakukan discovery lookup

terhadap gateway tersebut dan membentuk sebuah sambungan nirkabel sementara.

Sambungan nirkabel sementara dimaksudkan bahwa sambungan yang telah terjalin

akan diputuskan begitu proses pertukaran data telah selesai. Aplikasi klien kemudian

akan mengambil seluruh informasi layanan yang disediakan dan menampilkannya di

mobile device. Jika pengguna memilih sebuah layanan informasi, permintaan tersebut

akan diteruskan ke server oleh gateway dan kemudian diproses untuk memperoleh

hasilnya. Hasil eksekusi ini kemudian diberikan ke gateway dan diteruskan ke klien.

3.2.2. Asumsi

Pada perancangan sistem ini dirumuskan asumsi-asumsi berkaitan dengan

keterbatasan sarana dan prasarana pada tahap pengembangan sistem LBS.

Prototipe sistem ini akan menggunakan satu buah server sebagai web server, application server, dan basis data server.


Sistem ini tidak membuat aplikasi yang berhubungan dengan layanan informasi secara penuh. Layanan informasi yang ditampilkan adalah berupa

simulasi sesuai dengan studi kasus.

Service gateway diimplementasikan pada sebuah komputer dengan sebuah dongle Bluetooth. Implementasi pada Bluetooth access point akan memakan

biaya yang cukup besar sehingga tidak dapat disediakan pada pembuatan

sistem ini. Karena keterbatasan sumber daya komputer yang digunakan adalah

juga yang berfungsi sebagai LBS Server.

3.2.3 Perancangan LBS Server

3.2.3.1. Use case LBS server

LBS server merupakan pusat pemrosesan informasi di sistem LBS ini. Fungsi

utamanya adalah menerima permintaan dari access point, memproses permintaan

tersebut dan kemudian mengirimkan informasi yang diminta. Sebagai contoh

informasi yang dikirimkan mencakup gambar peta, koordinat sebuah access point,

dan data teks biasa.

Perancangan arsitektur server harus mengikuti spesifikasi yang telah disebutkan pada

bab sebelumnya agar sistem yang lama dapat digunakan dengan sistem LBS ini.

Untuk memenuhi kompatibilitas dengan sistem yang lama, maka seluruh fungsi dari

server ini akan diimplementasikan dengan menggunakan web service. Dengan web

service, fungsi-fungsi yang ada akan diimplementasikan menjadi method-method

yang bisa dipanggil secara atomik oleh access point.

Desain utama dari subsistem ini dapat digambarkan berdasarkan fungsi-fungsi utama

yang dipunyainya dengan menggunakan sebuah use case. Use case tersebut dapat

dilihat pada gambar 3.3.


Retrieve Map

Retrieve Bluetooth Access Point Coordinate

Retrieve Service List

Bluetooth AP

Process Service Request

Gambar 3.3 Use case LBS Server

Use case pada gambar diatas menunjukkan 4 buah fungsi utama yang hasil prosesnya

dapat dirasakan langsung oleh penggunanya. Dari gambar diatas pengguna / aktor

yang berperan dalam subsistem ini adalah Bluetooth access point. Aktor merupakan

pihak di luar sistem yang berhubungan langsung dengan sistem. Aktor dapat

melakukan fungsi-fungsi yang terdapat pada use case untuk kepentingannya sendiri.

Dalam hal ini Bluetooth AP (access point) akan menggunakan use case-use case ini

untuk menanggapi request / permintaan service dari mobile client. Berikut adalah

penjelasan dari masing-masing use case yang dimiliki oleh subsistem LBS server.

Retrieve map, adalah use case server yang memberikan data gambar peta dalam bentuk SVG (scalable vector graphics) kepada access point yang

memintanya.

Retrieve Bluetooth AP coordinate, adalah use case server yang memberikan data koordinat dari sebuah Bluetooth access point relatif terhadap peta yang

digunakan oleh sistem.

Retrieve Service List, adalah use case server yang memberikan daftar service yang dapat diakses berdasarkan lokasi sebuah Bluetooth access point.

Process Service Request, adalah use case server yang berfungsi untuk melakukan eksekusi dari sebuah service yang diminta. Hasilnya akan

dikirimkan kembali ke peminta dalam format XML.


3.2.3.2. Database Model Diagram

Basis data digunakan di sistem ini untuk menyimpan data-data yang diperlukan agar

sistem LBS berjalan. Dalam basis data ini disimpan data-data Bluetooth access point

yang tersebar sampai dengan layanan informasi apa saja yang dapat diakses melalui

access point tersebut. Gambar 3.4 adalah database model diagram dari LBS Server.

BluetoothDB

PK BTId

BTAddressLocation

FK1 MapId

MapDB

PK MapId

MapNameMapData

ServiceListDB

PK ListId

FK1 BTIdServiceList

ServiceDB

PK id

CategoryVendorServiceReturnTypeDataWsdlUrl

FK1 ListId

Gambar 3.4 Database Model Diagram

Basis data di atas bukan merupakan rancangan yang ideal sesuai dengan teori yang

ada. Terdapat beberapa bagian yang masih dapat disempurnakan dan dipisahkan

sehingga membentuk sebuah basis data yang sesuai dengan teori. Namun rancangan

diatas dibuat dengan memperhatikan cost yang diperlukan agar operasi query basis

data tidak memakan biaya komputasi yang banyak. Beberapa field digabungkan

seperti pada ServiceDB agar eksekusi bisa dilakukan dengan sekali query. Jika

menurut teori ideal seluruh field dalam table ServiceDB, seperti Category, Vendor,

Service, dipisah menjadi tabel tersendiri, maka eksekusi akan membutuhkan 4 kali

query. Penjelasan lebih rinci mengenai field-field basis data diatas terdapat di tabel

berikut.


MapDB

MapId Integer Id dari peta.

MapName Varchar (50) Nama dari peta.

MapData LongText Data SVG yang menggambarkan peta.

BluetoothDB

BTId Integer Id dari Bluetooth access point.

BTAddress Varchar (50) Alamat perangkat Bluetooth.

Location Varchar (10) Lokasi dari access point relatif terhadap

peta (x,y).

ServiceListDB

ListId Integer Id dari daftar layanan.

ServiceList LongText Daftar dari layanan yang tersedia.

Daftar ini berada dalam format XML.

ServiceDB

Id Integer Id dari layanan

Category Varchar (100) Kategori dari layanan informasi.

Vendor Varchar (100) Vendor pemilik layanan informasi.

Service Varchar (100) Nama layanan informasi.

ReturnType Char(10) Tipe data dari layanan informasi.

Data LongText Data hasil eksekusi layanan informasi.

WsdlUrl Text Alamat wsdl dari web service untuk

mengeksekusi layanan informasi

(optional)


5.4. Perancangan Service gateway

5.4.1. Use case service gateway

Bagian Service gateway merupakan bagian yang bertanggung jawab terhadap

komunikasi nirkabel layanan informasi. Service gateway ini akan diimplementasikan

di Bluetooth access point. Dikarenakan memory space yang sangat terbatas di access

point, maka program ini memiliki keharusan untuk menggunakan memori seminimal

mungkin. Akibatnya fungsi yang diimplementasikan harus sesederhana mungkin.

Fungsi utama dari service gateway adalah menunggu koneksi dari klien dan

meneruskan permintaan klien agar diproses oleh server. Berdasarkan fungsi utamanya

yaitu menangani permintaan layanan dari klien, desain utama dari bagian atau modul

ini dapat digambarkan dengan use case yang sederhana. Use case dari sistem ini dapat

dilihat pada gambar 3.5.

Mobile Client Handle Request Server

Gambar 3.5. Use case Service gateway

Use case menggambarkan fungsi-fungsi utama dari sistem yang dapat dilihat hasilnya

secara nyata oleh pengguna sistem. Pada kasus sistem service gateway ini fungsi

utamanya adalah handle request. Aktor yang berperan dalam use case service

gateway ini adalah mobile client dan server. Mobile client adalah pengguna sistem

yang menggunakan mobile device untuk mengakses layanan LBS, sedangkan server

adalah LBS server utama yang berfungsi untuk memproses request. Berikut adalah

penjelasan dari use case ini.

Handle request, use case ini memiliki tanggung jawab untuk menerima segala permintaan layanan yang masuk melalui saluran Bluetooth lalu kemudian

meneruskannya ke LBS server untuk diproses lebih lanjut. Setelah pesan


diterima kembali, service gateway kemudian mengirimkannya kembali

kepada mobile client.

5.4.2. Activity diagram service gateway

Activity diagram menggambarkan aliran sistem dari sebuah aktivitas ke aktivitas

lainnya. Setiap aktivitas yang tercakup dalam diagram ini akan menghasilkan aksi,

dimana aksi ini dapat menghasilkan perubahan state atau kondisi pada sistem atau

menghasilkan sebuah nilai [MAR97]. Diagram ini dibutuhkan untuk menggambarkan

bagaimana cara sistem service gateway berfungsi dalam hal menangani permintaan

dari klien. Activity diagram dari sistem service gateway digambarkan pada gambar

3.6.

Waiting Connection

Accept Request

Parse Request Send Request to Server

Send Response to Mobile Client

Break Connection

Connection Accepted

Start

Shutdown

Gambar 3.6. Activity Diagram Service gateway

Berdasarkan diagram pada gambar 3.5, ketika dijalankan sistem service gateway akan

langsung menunggu koneksi dari klien. Terdapat potensi masalah yang terjadi jika

sebuah koneksi melakukan block terhadap koneksi lain. Hal ini dapat diatasi dengan

cara membuat thread untuk setiap koneksi yang terjadi. Sehingga tiap koneksi akan

independen dengan koneksi lainnya. Jika koneksi diterima maka isi dari permintaan

klien (request) akan diperiksa dan ditangani sesuai dengan isinya. Penanganan isi


permintaan dilakukan pada aktifitas parse request. Seperti yang telah disebutkan pada

bagian arsitektur server, semua fungsi server diimplementasikan dengan web service.

Web service dapat diibaratkan method yang dapat dipanggil secara remote oleh

aplikasi gateway. Aktifitas parse request adalah untuk memetakan request ke method

web service yang harus dipanggil. Ketika web service dipanggil, maka server akan

memrosesnya sesuai dengan parameter-parameter yang dimasukkan dan akan

langsung dikirimkan ke gateway. Setelah menerima hasil dari LBS Server, service

gateway akan mengirim jawaban (response) yang telah terbungkus dalam format

XML kepada klien, dan kemudian akan memutuskan koneksi Bluetooth.

Dokumentasi-dokumentasi sistem lainnya yang lebih lengkap seperti use case

specification, detailed class diagram dan sequence diagram terdapat di lampiran.

5.5. Perancangan Mobile Client

5.5.1. Use case mobile client

Mobile Client adalah aplikasi konsumen layanan informasi yang berada di mobile

device pengguna. Fungsi utamanya adalah seperti layaknya browser, yaitu sebagai

presentation layer. Karena berfungsi sebagai presentation layer, maka tidak ada

business logic atau business process yang berjalan di sisi klien ini. Keuntungan yang

diperoleh adalah jika sebuah layanan informasi berubah pada sisi server maka aplikasi

di sisi klien tidak harus mengalami perubahan. Use case dari aplikasi mobile client

digambarkan pada gambar 3.7.


View User LocationView Map

Inquire Service

Mobile User

Inquire Text Service

Inquire Map Service

Gambar 3.7. Use case Mobile Client

Pada use case diagram di gambar 3.7, terdapat 5 buah use case yang

menggambarkan fungsi-fungsi utama dari aplikasi di sisi mobile client. Berikut

adalah penjelasan dari masing-masing use case.

View map, use case ini merupakan fungsi untuk menampilkan gambar peta pada mobile device. Gambar peta yang ditampilkan memiliki format SVG

(scalable vector graphics) yang merupakan data XML. Karena sifat format

SVG yang berupa gambar vector, maka aplikasi ini dapat melakukan

transformasi gambar seperti pan, tilt, zoom tanpa mengalami kerusakan

resolusi. Seluruh kegiatan transformasi gambar (pan,tilt,zoom) tergolong

sebagai use case yang terpisah, namun untuk alasan kesederhanaan tidak

dimasukkan menjadi use case tersendiri. Use case view map ini termasuk

fungsi dasar yang akan dipakai pada use case-use case lainnya.

View user location, use case ini adalah use case view map yang mengalami perubahan di beberapa bagian. Use case tidak hanya

menampilkan peta namun memproses data koordinat yang disediakan dan

kemudian menggambarkannya pada peta SVG. Peta yang dihasilkan akan

menunjukkan lokasi sementara pada peta dari mobile client.


Inquire service, use case ini memiliki fungsi untuk meminta layanan informasi kepada access point. Use case ini bersifat abstrak, dalam artian

use case ini merupakan use case yang sangat umum dan akan dirincikan

kembali oleh dua buah use case lainnya, yaitu inquire map service dan

inquire text service.

Inquire map service, use case ini meminta peta daerah tertentu kepada access point yang mungkin tidak berhubungan dengan lokasi

keberadaannya sekarang. Use case ini menggunakan use case view map

untuk menampilkan peta tersebut pada mobile device.

Inquire text service, use case ini meminta layanan informasi yang berupa informasi teks biasa kepada access point.

5.5.2. Activity diagram mobile client

Activity diagram pada aplikasi client mengambarkan alur kegiatan yang terjadi ketika

seorang pengguna hendak memperoleh layanan informasi di suatu tempat tertentu.

Gambar 3.8 menampilkan activity diagram dari aplikasi client.


Service Lookup

/ user initiated lookup

[ No Service Found ]

Request Service List

[ Discover Services ]

Build Request Menu

Show Category Selection

Show Vendor Selection

Show Service Selection

Send Service Selection to Access Point

Receive Response

Show Result

/ Select Category

/ Select Vendor

/ Select Service

Gambar 3.8. Activity Diagram Service Request

Diagram ini menunjukkan aktifitas aplikasi ketika pengguna memulai pencarian

layanan yang tersedia. Aplikasi klien pertama kali akan berusaha mencari layanan

informasi atau access point yang berada di sekitar pengguna. Ketika berhasil

menemukan sebuah access point atau layanan informasi, maka aplikasi client akan

mengirimkan permintaan daftar service yang tersedia. Daftar ini berisi data-data

layanan dalam 3 tingkat hirearki, yaitu kategori layanan, vendor layanan, dan layanan

yang dapat dipilih. Dari daftar service ini, mobile device akan membuat sebuah user

interface bertingkat. Pilihan ini akan lebih menghemat komunikasi IO yang terjadi

antara client dan access point jika dibandingkan dengan meminta 1 hirearki setiap

waktunya. Setelah pengguna memilih layanan yang diinginkan, aplikasi akan

mengirim request tersebut ke access point. Setelah menerima hasil dari layanan,

aplikasi akan menampilkannya ke layar mobile device sesuai dengan tipe data yang

diterima (teks, SVG dll.). Berikut adalah activity diagram yang menggambarkan

kegiatan aplikasi client ketika mengambil data peta dari access point.


Service Lookup



Send Map Request

[ Found Services ]

Save Map in Application

Show Map

Map Received

Gambar 3.9. Activity Diagram Download Map

Diagram di atas menunjukkan aktifitas ketika pengguna mengambil peta dari access

point. Pertama aplikasi akan mencari layanan yang paling terdekat dari mobile device.

Jika access point berhasil ditemukan maka aplikasi akan mengirimkan permintaan

peta ke access point tersebut. Access point akan mengirimkan peta kembali ke

aplikasi client dalam bentuk XML. Setelah aplikasi client menerima data peta,

aplikasi tersebut akan menyimpan peta di memori dan menampilkannya ke layar

mobile device.

Satu lagi aktifitas yang penting bagi mobile client adalah menentukan lokasi dari

mobile client. Aktifitas ini baru dapat dilakukan setelah aktifitas download peta

dilakukan. Hal ini dikarenakan aktifitas penentu lokasi memerlukan data peta yang


sebelumnya telah disimpan pada saat download peta. Berikut adalah diagram aktifitas

penentu lokasi.

Service Lookup



Send Coordinate Request

[ Found Services ]

Check Map Signature

[ Signature Unmatched ]

Retrieve Stored Map

[ Matched Signature ]

Draw Coodinate in Map

Show Map

Gambar 3.10. Activity Diagram Download Coordinate

Aktifitas di gambar atas menunjukkan aktifitas ketika aplikasi menunjukkan posisi

mobile client relatif terhadap access point yang diaksesnya. Aktifitas dimulai oleh

pengguna dan mencari layanan informasi terdekat. Jika ditemukan, aplikasi akan

mengirimkan permintaan koordinat lokasi access point yang diakses. Server lalu akan

mengirim data koordinat ke access point. Data koordinat ini terdiri atas koordinat

relatif terhadap peta SVG dan map signature. Map signature adalah data untuk

mencocokkan apakah peta yang dimiliki oleh client masih valid untuk digunakan. Hal

ini berguna dalam kasus pengguna pindah ke daerah lain yang menggunakan peta

berbeda. Setelah menerima data koordinat, aplikasi akan mencocokkan map signature

yang didapat dengan yang dipunya. Jika tidak cocok maka aplikasi harus men-

download peta baru dari acces point. Namun jika cocok, aplikasi akan mengambil

data peta yang tersimpan dalam memori mobile device dan kemudian


menggabungkannya dengan koordinat yang diperoleh tadi. Hasil peta gabungan

tersebut kemudian ditampilkan di layar mobile device.


BAB IV

IMPLEMENTASI

Pada bab ini akan dibahas mengenai tahap implementasi dari sistem LBS. Tahap

implementasi adalah proses penerjemahan desain yang telah dirancang pada tahap

sebelumnya menjadi program secara fisik. Dalam proses ini tidak semua desain secara

ideal dapat diterapkan mengingat keterbatasan sumber daya yang tersedia. Sebagai

contoh adalah seperti yang telah disebutkan pada asumsi di tahap desain,

implementasi gateway tidak dilakukan di sebuah access point namun disimulasikan

dengan sebuah komputer dan dongle Bluetooth. Berikut adalah gambaran hardware

tempat sistem LBS ini diimplementasikan.

BluetoothDongle

Bluetooth Dongle

Nokia 6600HUB

`

PC 1

`

PC 2

Gambar 4.1 LBS Server Test System

Gambar di atas menunjukkan test system dimana sistem LBS diimplementasikan.

Mobile client yang digunakan adalah ponsel Nokia 6600. Service gateway

diimplementasikan di kedua buah PC yang masing-masing memiliki dongle

Bluetooth. Sedangkan server diimplementasikan di PC 1. PC 2 dapat mengakses

server PC1 untuk memroses request melalui jaringan LAN.


4.1. Implementasi LBS Server

LBS Server diimplementasikan pada sebuah PC yang memiliki dongle Bluetooth. PC

yang digunakan memiliki spesifikasi sebagai berikut.

Hardware Software

IBM PC Compatible AMD Athlon 2600+ RAM 384 MB Ethernet Card 10/100

OS : Mandrake Linux 9.2, kernel 2.6.3

Web Server : Apache Tomcat 4.1 Web service Container : Apache

Axis 1.1

DBMS : MySQL 4.0 Tabel 4.1. Spesifikasi Sistem LBS Server

Komponen yang memegang peranan penting pada server ini adalah web service

container, yaitu Apache Axis. Apache Axis berfungsi untuk menyediakan

kemampuan web service pada web server Apache Tomcat. Dalam implementasinya

container ini akan mengakses basis data untuk memperoleh data-data atau informasi

yang akan dikirimkan ke access point.

Web ServiceGetMapData

Web ServiceGetCoordinate

Web ServiceGetMenuService

Web ServiceExecuteService

Apache Axis

Apache Tomcat Web Server

DBMSMySQL

Gambar 4.2 Skema Web service LBS Server

Gambar di atas menggambarkan skema hubungan antara web service, web service

container, web server dan basis data dalam sistem LBS Server. Keempat web service


tersebut adalah implementasi dari fungsi-fungsi utama seperti yang dirancang pada

tahap desain.

GetMapData, merupakan implementasi use case retrieve map yang berfungsi mengambil data peta dari sistem dan memberikannya ke access point.

GetCoordinate, merupakan implementasi use case retrieve Bluetooth access point coordinate yang berfungsi mengambil data koordinat dari sebuah access

point.

GetMenuService, merupakan implementasi use case Retrieve Service List yang berfungsi mengambil daftar layanan informasi yang tersedia untuk

sebuah access point tertentu.

Execute Service, merupakan implementasi use case process service Request yang berfungsi melakukan eksekusi dari layanan informasi yang diminta oleh

access point.

Seluruh web service diimplementasikan di Apache Axis dengan menggunakan metode

Java Web service (jws), yang sangat sederhana untuk diimplementasikan. Seluruh

kode dari web service dimasukkan ke dalam sebuah file yang memiliki extension .jws.

Kemudian web service container secara langsung akan membuat file WSDL agar

dapat diakses oleh aplikasi access point.


Gambar 4.3. WSDL LBS Server

4.2. Implementasi Service gateway

Sebuah service gateway idealnya diimplementasikan pada sebuah Bluetooth access

point, namun untuk prototipe ini service gateway akan diimplementasikan di sebuah

PC yang terhubung pada sebuah dongle Bluetooth. Spesifikasi dari PC yang

digunakan dalam pengujian adalah sebagai berikut.

Hardware Software

IBM PC Compatible AMD Athlon 2600+ RAM 384 MB Ethernet Card 10/100 Billionton Dongle Bluetooth

10 m

OS : Mandrake Linux 9.2, kernel 2.6.3

Java : J2SE 1.4.0 Stack Bluetooth : Bluez Java Bluetooth API : Rococosoft

Impronto 1.1

Dynamic Web service Invoker : Apache WSIF


Tabel 4.2 Spesifikasi Sistem Service gateway Dongle Bluetooth merek Billionton yang memiliki jangkauan 10 meter dipilih untuk

memperoleh jarak yang tepat agar dapat dijangkau oleh ponsel yang memiliki

jangkauan Bluetooth 10 meter.

Stack Bluetooth adalah library yang diperlukan oleh sebuah operating system agar

dapat berinteraksi dengan sebuah dongle Bluetooth. Stack Bluetooth yang dipilih

adalah Bluez dari Sourceforge (bluez.sourceforge.com). Stack ini dipilih karena

paling berkembang dibandingkan dengan stack lainnya dan baru-baru ini telah

dimasukkan ke dalam paket linux sebagai stack Bluetooth native dari linux.

Stack Bluez menggunakan bahasa C sebagai bahasa pemrograman aslinya. Untuk

mempermudah pemrograman maka diperlukan sebuah middleware agar stack ini bisa

digunakan pada bahasa pemrograman lain. Di sinilah Impronto dari Rococosoft

memiliki peran yang sangat penting. Library ini memungkinkan stack bluez

dipergunakan dalam bahasa Java. Walaupun tidak semua fungsionalitas

diimplementasikan oleh Impronto, namun fungsi-fungsi dasarnya sudah cukup untuk

mengimplementasikan service gateway pada mesin PC berbasis Linux.


Bluetooth

Impronto Library

Service Gateway Daemon

Apache WSIF

Web Service

LBS Server

Service Gateway

Gambar 4.4 Service gateway Application Stack

Selain Impronto, aplikasi service gateway ini juga menggunakan library Apache

WSIF yang berfungsi untuk memanggil web service secara dinamis. Terdapat 2 buah

cara untuk memanggil web service, yaitu statis dan dinamis. Pemanggilan secara statis

mengharuskan aplikasi pemanggil memiliki file wsdl dari web service yang akan

dipanggil. File wsdl tersebut kemudian di-compile menjadi sebuah file yang berisi

object proxy dari web service tadi. Dalam implementasinya untuk memanggil web

service, aplikasi menggunakan object proxy sebagai perantara. Seolah-olah apikasi

mengeksekusi object proxy, namun object tersebut meneruskannya ke server tempat

web service berada. Kelemahan dari metode ini adalah bahwa metode ini tidak praktis

jika diterapkan di lingkungan yang berjalan secara real-time. Setiap perubahan terjadi

maka seluruh aplikasi yang menggunakan web service harus melakukan kompilasi

ulang atas file wsdl dari web service tersebut. Hal ini akan sangat tidak praktis jika

aplikasi yang menggunakan web service tersebut, dalam hal ini access point,

berjumlah puluhan.

Pemanggilan secara dinamis merupakan cara yang lebih praktis. Kompilasi file wsdl

dilakukan secara real-time setiap kali web service tersebut digunakan. Hal ini

menyebabkan aplikasi tidak bergantung terhadap perubahan di sisi web service.


Kelemahan dari metode ini terletak pada sisi kompilasi wsdl secara real-time. Proses

kompilasi ini memiliki overhead proses dibandingkan dengan pemanggilan secara

statis. Overhead yang dihasilkan dapat mengakibatkan response time yang lebih lama

dibandingkan cara statis. Namun jika dibandingkan dengan ketidakpraktisan untuk

setiap kali melakukan kompilasi ulang wsdl, cara dinamis lebih dapat diterima karena

bisa diatasi dengan hardware yang lebih cepat. Oleh sebab itu, aplikasi service

gateway menggunakan library dari Apache WSIF (web service invocation

framework) untuk melakukan pemanggilan web service secara dinamis.

Bagian utama dari aplikasi service gateway ini adalah service gateway daemon yang

mengatur koordinasi antara Bluetooth dan web service. Fungsinya adalah menangani

request yang masuk yang berasal dari Bluetooth dan menangani isinya. Daemon ini

memetakan Web service yang harus dipanggil berdasarkan isi request tersebut. Untuk

memanggil web service tersebut, daemon ini menggunakan library dari Apache

WSIF.

void main() { init_Bluetooth_device() while (true) { wait_connection() if(connection_accepted) { request = read_request() response = send_request(request) int limit = 400 int begin = 0 int end = 0 int part_num = (response.length / limit)+1 while(part_num > 1) { end = begin + limit String part = response.substring(begin,end) send_response(part) sleep(200) begin = end interval-- }


String leftover = response.substring(begin,response.length) send_response(leftover) close_connection() } } }

Tabel 4.3. Service gateway Daemon PseudoCode

Pseudocode diatas merupakan penyederhanaan dari kode asli service gateway

daemon. Untuk memenuhi fungsinya sebagai pendengar bagi request yang masuk,

aplikasi daemon ini diimplementasikan dengan menggunakan thread.

Bagian yang harus diperhatikan dari tahap implementasi daemon ini adalah bahwa

library Impronto tidak mengizinkan aplikasi untuk mengirimkan data yang sangat

besar sekaligus melalui koneksi Bluetooth. Dari uji coba yang dilakukan, batas yang

diperbolehkan oleh Impronto adalah data dengan besar 500-600 karakter ASCII untuk

sekali kirim. Ukuran karakter ASCII dipergunakan disini karena semua data yang

dipertukarkan pada sistem LBS merupakan data karakter string. Untuk mengatasi hal

tersebut, implementasi harus dimodifikasi agar melakukan pengiriman dengan data

yang telah dipotong berkali-kali. Untuk implementasi ini digunakan ukuran buffer

sebesar 400 karakter. Sebuah data yang sangat besar dipotong menjadi bagian-bagian

sebesar 400 karakter, kemudian dikirim secara terpisah ke mobile device tujuannya.

Di mobile device itu data-data yang terpotong akan disatukan kembali. Algoritma

untuk melakukan pemotongan ini tergambar pada pseudocode tabel diatas.

Pertukaran data antara service gateway dengan mobile device dilakukan dengan

menggunakan format XML. Format ini dipergunakan untuk mempermudah

pengembangan. Aplikasi service gateway daemon ini mempergunakan kemampuan

native dari Java untuk melakukan parsing XML. Data yang dipertukarkan memiliki 2

jenis, yaitu request dan response. Request merupakan data xml yang dikirimkan oleh

mobile device ke access point untuk memperoleh layanan informasi. Tabel 4.4 adalah

contoh dari data request.


Universitas

UI

Show Location

Tabel 4.4. Contoh Data Request

Data request di atas merupakan data yang dikirimkan oleh mobile device ke access

point untuk meminta eksekusi layanan informasi dengan kategori Universitas, vendor

UI , dan service Show Location. Atribut type yang terdapat pada element request

menunjukkan jenis permintaan. Nomor 8 berarti permintaan peta, nomor 9

menunjukkan permintaan koordinat, nomor 10 menunjukkan permintaan daftar

service, dan nomor 7 menunjukkan permintaan eksekusi service yang terdapat pada

elemen lainnya.

Data response adalah data yang diberikan access point kepada mobile device berisi

jawaban atas permintaan layanan informasi. Tabel 4.5 adalah contoh dari data

response.

10

Hello World

Tabel 4.5. Contoh Data Response

Data response memiliki struktur yang hampir sama dengan data request.

Perbedaannya terletak pada elemen di dalam elemen response. Atribut type

menunjukkan tipe dari response yang diberikan. Nomor 8 seperti pada contoh

menunjukkan response adalah hasil eksekusi layanan informasi. Data type

menunjukkan tipe data dari jawaban, hal ini akan memudahkan apliaksi mobile client

untuk menangani data jawaban. Tipe yang mungkin dikirim adalah string, svg,


koordinat. Sedangkan data berisi data jawaban dari permintaan layanan informasi

sebelumnya.

4.3. Implementasi Mobile Client

Pilihan hardware yang digunakan sebagai basis pengembangan mobile client untuk

sistem LBS ini adalah ponsel merk Nokia 6600. Ponsel ini dipilih karena mempunyai

spesifikasi MIDP 2.0.

Platform pengembangan di Nokia 6600 adalah J2ME (Java 2 Micro Edition). Dengan

menggunakan J2ME untuk mengembangkan aplikasi mobile client, kebutuhan akan

aplikasi yang portable untuk macam-macam jenis ponsel dapat dipenuhi. Sebuah

aplikasi yang dikembangkan dengan J2ME dapat dijalankan di ponsel atau mobile

device manapun tanpa perubahan kode selama mobile device yang dituju mendukung

J2ME juga.

Dalam pengembangan aplikasi mobile client ini tidak semua library yang dibutuhkan

disediakan oleh J2ME, terdapat beberapa fungsionalitas yang masih harus disediakan

oleh pihak ketiga. Library yang tidak disediakan oleh J2ME adalah kemampuan untuk

melakukan parsing data XML dan kemampuan untuk menampilkan gambar SVG di

layar ponsel.

Library yang digunakan untuk menambah kemampuan melakukan parsing di J2ME

adalah KXML. KXML adalah library yang berfungsi untuk melakukan parsing XML

menurut aturan SAX dan DOM di lingkungan pengembangan yang memiliki memory

space terbatas. Terdapat beberapa alternatif lain seperti nanoXML, namun KXML

digunakan karena syntax dan rule-nya mirip dengan pengembangan XML dengan

menggunakan library XML dari J2SE.

Kemampuan untuk menampilkan gambar pada J2ME sangat terbatas. Untuk saat ini

format yang bisa ditampilkan adalah gambar yang memiliki format PNG. Format-

format lain seperti JPEG, GIF, BMP tidak bisa ditampilkan di layar ponsel dengan

J2ME. Dengan pilihan yang terbatas ini, sistem LBS mengharuskan mobile client


untuk dapat menampilkan gambar peta secara interaktif di layarnya. Gambar peta

yang interaktif berarti gambar tersebut dapat ditransformasi (geser, zoom) tanpa

mengorbankan kualitas gambar. Dengan format PNG, spesifikasi transformasi tidak

dapat dipenuhi. Gambar PNG akan mengalami subsampling ketika dilakukan

transformasi zoom sehingga gambar akan terlihat seperti pecah. Untuk mengatasi ini

diperlukan gambar PNG dengan resolusi yang sangat tinggi. Namun solusi tersebut

membutuhkan memory space yang sangat besar, dalam hal ini solusi tersebut tidak

dapat diterapkan.

Untuk mengatasi permasalahan gambar tersebut diperlukan sebuah format gambar

yang memiliki besar file yang kecil namun dapat ditransformasi dengan bebas tanpa

mengalami kerusakan gambar. Format yang bisa dipakai adalah gambar dengan

format vector. Gambar vector terdiri dari elemen-elemen gambar sederhana seperti

garis, kotak, lingkaran dsb. Perpaduan dari elemen-elemen ini akan membentuk

sebuah gambar yang lebih kompleks. Isi dari file gambar vector berupa susunan-

susunan gambar yang diekspresikan dalam bentuk XML. Format gambar vector yang

dipakai luas di industri adalah format SVG (scalable vector graphics). Format

tersebut hanya berisi spesifikasi elemen-elemen yang harus digambar. Tugas

penggambaran diserahkan kepada aplikasi yang menampilkan gambar ini. Hal ini

berarti memunculkan overhead bagi aplikasi untuk memproses gambar SVG. Namun

kelemahan ini bisa diterima jika dibandingkan dengan menggunakan gambar raster

(JPG, GIF, PNG) yang menggunakan memory space besar.

Library yang digunakan untuk menampilkan gambar dengan format SVG adalah

Tinyline SVG 1.6. Library ini bebas untuk digunakan dan dimodifikasi. Dengan

library ini seluruh fungsi transformasi gambar dapat diimplementasikan dengan

mudah. Berikut ini adalah gambar skema dari seluruh software dan library yang

digunakan untuk sistem LBS.


Bluetooth Library

(JSR-82)TinyLine KXML

J2ME

Aplikasi Client

Bluetooth

Bluez Bluetooth Stack

Impronto Apache WSIF Library

Aplikasi Service Gateway

J2SE

Bluetooth

Web Service

Apache AXIS

Apache Tomcat

MySQL

Mobile Client

Service Gateway

LBS Server

XML

XML

Gambar 4.5 Susunan Library dan Software LBS

4.4. Studi Kasus Sistem LBS Studi kasus yang digunakan untuk sistem LBS ini adalah pameran pendidikan. Studi

kasus diperlukan sebagai contoh dari sistem ketika diaplikasikan ke dunia nyata.

Pameran pendidikan ini diasumsikan diadakan di sebuah gedung yang memiliki satu

lantai dan memiliki banyak bilik-bilik stan. Gambar 4.6 adalah gambar peta dari

gedung tersebut.


Gambar 4.6. Peta Pameran

Pameran tersebut memiliki 18 stan yang berisi vendor-vendor dari berbagai jenis

institusi. Berikut adalah daftar layanan yang tersedia dari pameran tersebut.

Category Vendor Service

Show Location Universitas Indonesia

Admission Info

ITB Show Location

UGM Show Location

UNJ Show Location

ITENAS Show Location

Bina Nusantara Show Location

Universitas

Pelita Harapan Show Location

Depdiknas Show Location Institusi Pemerintah

MenKominfo Show Location

Conference Hall Show Location

Telecom Center Show Location

WC Show Location

Information Show Location

Lain-lain

Car Call Show Location Tabel 4.7. Daftar Layanan Informasi Pameran


Seluruh layanan yang tersedia menampilkan layanan lokasi tempat sebuah stan

berada. Layanan show location adalah layanan yang menampilkan lokasi dari stan

institusi tersebut, sedangkan admission info merupakan layanan berbasis teks yang

berisi informasi cara pendaftaran UI.

4.5. Uji Coba

Untuk menguji bagaimana mobile client mengakses layanan informasi tersebut pada

studi kasus ini, akan ditampilkan beberapa skenario yang memperlihatkan fungsi-

fungsi utama dari sistem LBS ini. Skenario tersebut adalah skenario download peta,

skenario lokasi mobile client, dan skenario layanan informasi.

4.5.1. Skenario Download Peta Skenario download peta akan menunjukkan bagaimana memunculkan sebuah peta

lokasi tempat keberadaan pengguna. Peta yang akan dimunculkan harus di-download

dari access point terdekat ketika pertama kali hendak menggunakan sistem LBS di

sebuah bangunan atau ruangan tertutup.

Gambar 4.7. Skenario Download Peta

Untuk men-download sebuah peta, di menu utama pengguna harus memilih menu Get

Map. Mobile client kemudian akan melakukan inquiry atau pencarian terhadap access

point yang paling dekat. Setelah sebuah access point terdekat ditemukan, mobile

client akan mengirimkan permintaan layanan peta ke access point tersebut. Peta


ruangan / gedung tersebut kemudian dikirimkan secara nirkabel ke mobile client dan

secara otomatis akan menampilkannya ke layar seperti terlihat pada gambar 4.7.

Skenario ini dilakukan dengan test system LBS yang spesifikasinya telah disebutkan

di tabel 4.1. Uji coba ini berhasil mengirimkan gambar peta ke mobile client tanpa

kehilangan informasi. Data peta yang dikirim adalah peta ruangan dalam format SVG

sebesar 20,6 Kilobyte. Response time yang ditunjukkan oleh aplikasi mobile client

adalah 21,43 detik.

4.5.2. Skenario Lokasi Mobile Client Skenario yang kedua adalah skenario lokasi mobile client. Skenario ini akan

menunjukkan bagaimana sistem LBS ini dapat menunjukkan lokasi keberadaan dari

pengguna mobile client relatif terhadap posisi access point terdekat.

Gambar 4.8. Skenario Lokasi Mobile Client

Pada menu utama, pengguna harus memilih menu current location untuk

memperlihatkan lokasi keberadaan pengguna. Mobile client kemudian akan

melakukan inquiry kembali ke access point yang paling dekat, dan kemudian

mengirimkan permintaan akan data koordinat access point tersebut. Jawaban dari

access point yang berupa data koordinat akan dikombinasikan dengan peta yang

sebelumnya telah di-download dan kemudian ditampilkan di layar mobile device

seperti gambar 4.8. Data koordinat yang dikirimkan berupa teks dalam format (x,y).

Response time dari aplikasi mobile client adalah sebesar 19,3 detik.


4.5.3. Skenario Layanan Informasi Skenario yang ketiga adalah skenario layanan informasi. Skenario ini akan

menunjukkan langkah untuk mengakses layanan informasi yang berbasis gambar atau

teks.

Gambar 4.9. Skenario Layanan Informasi (1)

Untuk mengakses layanan informasi yang disediakan oleh sistem LBS ini, pengguna

harus memilih menu find services. Setelah memilih menu tersebut, mobile client akan

mencari access point terdekat dan mengirim permintaan daftar layanan yang tersedia.

Jawaban dari access point adalah sebuah daftar layanan informasi yang tersedia dalam

bentuk XML. Daftar ini kemudian akan diterjemahkan sehingga dapat dinavigasikan

dengan mudah melalui mobile device. Pilihan pertama yang dimunculkan adalah

pilihan kategori. Pilihan kategori mengelompokkan sebuah layanan informasi sesuai

dengan kategorinya. Contoh dari pilihan kategori ini adalah institusi pemerintah,

universitas, layanan umum, rumah makan, dll. Setelah sebuah kategori dipilih, sistem

akan memunculkan pilihan vendor. Pilihan ini menampilkan daftar daftar vendor

yang tersedia sesuai dengan kategori yang dipilih. Contoh pada gambar 4.9

menampilkan UI, ITB, UGM, dan BINUS sebagai vendor dengan kategori

Universitas.


Gambar 4.10 Skenario Layanan Informasi (2)

Setelah sebuah vendor dipilih, mobile client akan menampilkan layanan apa saja yang

tersedia sesuai dengan yang ditawarkan vendor tersebut. Untuk kasus pada gambar

4.10, vendor Universitas Indonesia memunculkan layanan show location dan

admission form. Layanan show location memunculkan gambar peta dari stan UI,

sedangkan layanan admission form memunculkan informasi mengenai bagaimana

cara melamar masuk UI. Hasil dari eksekusi layanan-layanan tersebut terlihat pada

gambar 4.10. Hasil pengukuran yang dilakukan menunjukkan hasil response time dari

layanan informasi berbasis teks sebesar 19,63 detik, sedangkan dari layanan informasi

berbasis gambar sebesar 23,12 detik.


BAB V

EKSPERIMEN Bab ini akan membahas mengenai eksperimen yang dilakukan pada sistem LBS.

Eksperimen dilakukan untuk menguji kesiapan sistem LBS ini diterapkan di

lingkungan nyata yang berada di dalam ruangan. Diharapkan hasil dari eksperimen ini

akan menjadi acuan yang bisa dipergunakan untuk memperbaiki kelemahan ataupun

melakukan implementasi sistem LBS di lingkungan nyata.

Berikut adalah eksperimen-eksperimen yang akan dilakukan dengan sistem LBS.

1. Ekperimen korelasi jarak device-sensor dan response time dari aplikasi client

2. Eksperimen korelasi jumlah request yang aktif pada saat yang bersamaan

dengan response time dari aplikasi client

5.1. Korelasi Jarak Device-Sensor dan Response Time

Eksperimen ini dilakukan untuk memperlihatkan hubungan antara jarak antar mobile

device dan sensor Bluetooth gateway dengan waktu response aplikasi client untuk

melakukan request ke sensor tersebut. Dari eksperimen ini diharapkan dapat diketahui

pada jarak berapa mobile device akan mengalami penurunan response time sebagai

akibat dari peningkatan jarak tersebut.

5.1.1. Desain Eksperimen

Eksperimen dilakukan dengan satu dongle Bluetooth dan satu mobile device yang

memiliki aplikasi mobile client LBS. Awal dari percobaan akan menempatkan device

pada jarak 1 meter dari sensor, kemudian aplikasi mobile client akan dijalankan untuk

mengirimkan request ke sensor tersebut. Bersamaan dengan pengiriman request

tersebut, akan dicatat waktu yang dibutuhkan oleh aplikasi sampai dengan request

tersebut diperoses dan dikirim kembali ke device. Selanjutnya akan dilakukan


pencatatan yang sama dengan interval 0.5 meter sampai dengan jarak 10 meter dari

sensor Bluetooth.

5.1.2 Hasil Eksperimen

Setelah dilakukan eksperimen dan pengukuran, diperoleh hasil sebagai berikut :

# Eksperimen

Jarak (M) 1 2 3 4 5 AVG

1 20.39 21.95 21.4 20.97 20.4 21.022

2 21.66 20.46 21.56 21.96 20.36 21.2

3 21.48 20.88 20.36 21.89 20.4 21.002

4 21.76 20.31 21.66 21.77 21.76 21.452

5 20.39 21.7 21.66 20.56 21.86 21.234

6 20.5 20.61 20.56 21.06 20.87 20.72

7 22.26 20.87 20.77 21.68 21.66 21.448

8 20.95 21.06 22.06 21.5 20.87 21.288

9 21.88 21.99 20.91 22.18 20.96 21.584

10 21.86 20.68 22.28 22.36 21.06 21.648

Tabel 5.1 Data Eksperimen Jarak - Response Time

Data Eksperimen

1919.5

2020.5

2121.5

2222.5

23

1 2 3 4 5

# Eksperimen

REsp

onse

Tim

e

1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M

Gambar 5.1. Data Eksperimen Jarak - Response Time


Mean Data Eksperimen

20.220.420.620.8

2121.221.421.621.8

1 2 3 4 5 6 7 8 9 10

Jarak (M)

Res

pons

e Ti

me

(s)

Series1

Gambar 5.2. Mean Data Eksperimen Jarak - Response Time

5.1.3 Analisa Eksperimen

Eksperimen pertama ini menghasilkan data-data yang terlihat di grafik 1 dan 2. Grafik

1 menunjukkan data-data response time dari aplikasi ketika diujikan pada jarak 1

sampai 10 meter. Pada tiap-tiap jarak yang dicobakan, dilakukan 5 kali pengukuran

response time aplikasi. Sedangkan grafik 2 merupakan hasil rata-rata dari data mentah

pada grafik 1. Setiap jarak akan memiliki nilai rata-rata response time yang diperoleh

dari percobaan sebelumnya. Dari grafik tersebut dapat dilihat bahwa secara umum

seiring dengan penambahan jarak terdapat penurunan response time pula. Pada jarak 1

meter, response time yang dihasilkan adalah 21 detik. Dan pada jarak 10 meter,

response time yang dihasilkan adalah 21.6 detik. Sebuah anomali terdapat pada jarak

6 meter dimana terjadi penurunan waktu response time menjadi 20.72 detik. Hal ini

kemungkinan disebabkan karena memang jarak 6 meter merupakan jarak yang paling

optimal untuk pertukaran data antara sensor Bluetooth dan mobile device.

Dari analisa yang dilakukan pada eksperimen tersebut dapat disimpulkan bahwa

semakin jauh jarak mobile device dari sensor Bluetooth maka akan terjadi penurunan

response time dari aplikasi client. Sedangkan berdasarkan eksperimen tersebut

diketahui bahwa jarak 6 meter adalah jarak yang optimal agar sensor dan mobile

device dapat berkomunikasi dengan cepat.


5.2. Korelasi Jumlah Request ke Sensor dengan Response Time

Eksperimen ini dilakukan untuk mengukur tingkat response time dari aplikasi client

jika pada saat yang bersamaan sensor Bluetooth juga menerima request dari device

yang lain. Dari eksperimen ini diharapkan dapat diperoleh hasil yang menunjukkan

apakah dengan diterimanya 2 buah request dari device yang berbeda dapat memiliki

pengaruh terhadap response time aplikasi client.

5.2.1 Desain Eksperimen

Eksperimen dilakukan dengan satu buah sensor Bluetooth dan 2 buah mobile device. 2

buah mobile device akan dirancang agar mengirimkan request masing-masing ke

sensor Bluetooth pada saat yang bersamaan. Kemudian setelah request terkirim akan

dilakukan pencatatan waktu yang dibutuhkan sampai request itu diproses oleh server

dan dikirim kembali. Eksperimen ini akan dilakukan sebanyak 10 kali dan hasilnya

akan dirata-ratakan untuk mengetahui pengaruh banyak request terhadap reponse time

aplikasi.

5.2.2. Hasil Eksperimen

Setelah dilakukan eksperimen dan pengukuran, diperoleh hasil sebagai berikut :

# Eksperimen Device A Device B

1 27.3 23.25

2 27.17 21.79

3 27.87 27.01

4 40.43 44.64

5 25.87 22.35

6 34.15 40.31

7 23.7 34.53

8 21.12 43.7

9 28.28 26.64

10 27.67 21.32

Mean 28.356 30.554

Table 5.2. Data Eksperimen Jumlah Device - Response Time


Data Eksperimen

0

10

20

30

40

50

1 2 3 4 5 6 7 8 9 10

# Eksperimen

Resp

onse

Tim

e (s

)

Device ADevice B

Gambar 5.3. Data Eksperimen Response Time - Jumlah Device

Device A Device B

Kontrol 21 21.4

Mean 28.356 30.554

Tabel 5.3. Data Kontrol - Data Eksperimen

0

5

10

15

20

25

30

35

Device A Device B

Resp

onse

Tim

e (s

)

Single RequestConcurrent Request

Gambar 5.4. Perbandingan Kontrol dan Eksperimen

5.2.3 Analisa Eksperimen

Eksperimen dilakukan sebanyak 10 kali pada jarak 4,5 meter dari sensor Bluetooth.

Dan dari eksperimen yang dilakukan, diperoleh data-data yang terdapat di tabel 2 dan

grafik 2. Data-data tersebut merupakan response time dari 2 buah device, yaitu device


A dan device B, yang melakukan request ke sensor Bluetooth pada saat yang

bersamaan. Untuk memperoleh perbandingan yang objektif, eksperimen ini harus

memiliki data kontrol yang berupa response time dari device tunggal. Tabel 3

merupakan perbandingan antara data kontrol dari kedua buah device dengan rata-rata

data yang diperoleh pada saat eksperimen. Dari tabel tersebut dapat dilihat bahwa

terdapat kenaikan sebesar 7 detik pada device A dan sebesar 9 detik pada device B.

Hal ini kemungkinan disebabkan oleh waktu yang dibutuhkan server untuk

memproses dua buah request secara bersamaan.

Dari eksperimen yang dilakukan dapat disimpulkan bahwa request yang diberikan

oleh banyak device secara bersamaan kepada sensor Bluetooth akan menyebabkan

penurunan response time dari aplikasi klien.


coba coba

Documents