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.
21Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
22Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
23Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
24Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
25Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
26Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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)
27Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
28Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
29Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
30Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
31Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
32Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
33Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
Service Lookup
[ No Service Found ]
/ user initiated 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
34Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
sebelumnya telah disimpan pada saat download peta. Berikut adalah diagram aktifitas
penentu lokasi.
Service Lookup
[ No Service Found ]
/ user initiated 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
35Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
menggabungkannya dengan koordinat yang diperoleh tadi. Hasil peta gabungan
tersebut kemudian ditampilkan di layar mobile device.
36Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
37Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
38Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
39Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
40Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
41Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
42Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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-- }
43Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
44Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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,
45Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
46Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
47Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
48Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
49Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
50Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
51Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
52Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
53Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
54Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
55Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
56Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
57Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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
58Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004
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.
59Implementasi location based..., Rikky Wenang Purbojati, FASILKOM UI, 2004