Rancangan Sistem

BAB 3
ANALISIS DAN PERANCANGAN SISTEM
3.1.
Analisis Permasalahan
3.1.1. Identifikasi Proses Bisnis Berjalan

Pada umumnya, sistem pemesanan taksi terdiri dari dua proses bisnis besar, yaitu
proses pemesanan itu sendiri dan proses penyebaran pesanan. Tabel 3.1 berisi daftar
proses bisnis yang teridentifkasi. Aktor yang berperan dalam proses bisnis teridentifikasi
ini ada tiga, yakni pelanggan, operator, dan sopir taksi. Daftar aktor dan proses bisnis
yang berhubungan dengan aktor tersebut terdapat pada Tabel 3.2.
Tabel 3.1. Daftar Proses Bisnis Berjalan

No.
1
Nama Proses
Input
Proses
Output
Proses
Data
1) Pelanggan menelepon
Dokumen
pemesanan taksi
pelanggan.
perusahaan taksi dan
pemesan taksi
memberikan data
pelanggan.
2) Operator menyimpan
data pelanggan di berkas
dokumen pesanan.
2
Proses
Dokumen
1) Operator melakukan
Dokumen
broadcast
pemesan
broadcast data pesanan ke
pesanan taksi
pesanan
taksi, data
seluruh taksi.
33
34
No.
Nama Proses
Input
taksi.
Proses
Output
2) Sopir taksi merespon

untuk mengambil pesanan
tersebut.
3) Operator menyimpan
data sopir taksi yang lebih
dulu merespon terhadap
pesanan dalam dokumen
pesanan.
Tabel 3.2. Daftar Proses Bisnis Beserta Aktor

No.
1.
2.
Nama Proses
Aktor
Proses
Operator,
pemesanan taksi
Pelanggan
Proses
Operator,
broadcast
Taksi
Dokumen
Dokumen pemesan taksi
Sopir Dokumen pesanan taksi
pesanan taksi
Untuk lebih memperjelas hubungan aktor dan proses bisnis yang teridentifikasi, lihat
document flow diagram pada Gambar 3.1 dan use case diagram yang menggambarkan
sistem pada Gambar 3.2.
35
Gambar 3.1. Document Flow Diagram Sistem Konvensional
36
Gambar 3.2. Use Case Diagram Sistem Konvensional
Deskripsi dan aliran use case pada Gambar 3.2 terdaftar pada Tabel 3.3, Tabel
3.4, Tabel 3.5, dan Tabel 3.6.
Tabel 3.3. Deskripsi Use Case Order Taxi
Name
Order Taxi
Actors
Customer (Pelanggan), Operator
Description
Use case menggambarkan bagaimana pelanggan memesan

taksi
Precondition
Pesanan belum dilakukan
Postcondition
Data pelanggan tercatat
37
Tabel 3.4. Aliran Use Case Order Taxi
Flow
Normal
Actor Action
System Response
Step 1.
Step 2.
Pelanggan menekan nomor Sistem

telepon
operator
menghubungi
untuk pelanggan
telepon.
Step 3.
menanyakan
informasi pelanggan dan

lokasinya.
Step 4.
Pelanggan
informasi
memberikan
dirinya
dan
mencatat
data
lokasinya.
Step 5.
Operator
pelanggan yang memesan

taksi pada sistem / berkas
penyimpanan data.
Alternate
taksi
dengan
penyedia operator melalui jaringan
jasa taksi.
Operator
menyambungkan
38
Tabel 3.5. Deskripsi Use Case Broadcast Order Request
Name
Broadcast Order Request
Actors
Customer (Pelanggan), Operator
Description
Use case menggambarkan bagaimana penyedia jasa taksi

mengkonfirmasi pesanan taksi ke pelanggan
Precondition
Pesanan telah dilakukan
Postcondition
Pelanggan mendapatkan satu taksi yang akan menjemput
Tabel 3.6. Aliran Use Case Broadcast Order Request

Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Operator
mengaktifkan Sistem mengirimkan sinyal
perangkat
radio
untuk data
melalui
gelombang
melakukan broadcast data radio ke perangkat radio di

pelanggan yang memesan armada
taksi
dalam
jasa taksi.
jangkauan gelombang radio.
Step 3.
Step 4.
Sopir taksi menerima data Sistem mengirimkan sinyal

pelanggan
mengaktifkan
radio
untuk
dan data
melalui
perangkat radio dari perangkat radio di

mengambil armada taksi ke perangkat
pesanan yang disebar oleh radio operator.

operator taksi.
gelombang
39
Flow
Actor Action
System Response
Step 5.
Operator meng-input data
pelanggan dan taksi yang
melayaninya pada sistem /
berkas penyimpanan data.
Alternate
Berdasarkan observasi, permasalahan pertama yang teridentifikasi adalah posisi

pelanggan dan taksi-taksi terdekat tidak diketahui. Jika ada pelanggan yang memesan
taksi, maka pesanan taksi tersebut dilelang ke seluruh armada taksi oleh operator. Pada
sistem pemesanan taksi konvensional, operator tidak memilihkan taksi-taksi terdekat
untuk pelanggan tersebut karena tidak mengetahui posisi masing-masing taksi.
Permasalahan yang kedua adalah satu operator hanya bisa melayani satu
pelanggan pada suatu waktu. Ada kemungkinan jika pelanggan menelepon untuk
memesan taksi, tidak satu pun operator dari perusahaan taksi yang bisa melayani.
Terakhir, operator adalah manusia yang mungkin melakukan kesalahan, dalam hal ini,
kesalahan dalam mengingat atau memroses informasi yang diberikan pelanggan dan
kesalahan dalam menyampaikannya ke sopir taksi. Daftar permasalahan teridentifikasi
pada proses bisnis berjalan terdapat pada Tabel 3.7.
.
40
Tabel 3.7. Daftar Masalah Teridentifikasi Pada Proses Bisnis Berjalan
No.
1.
Nama Proses
Masalah
Verifikasi Studi Literatur
Proses
Masalah 1.
pemesanan taksi
Posisi pelanggan dan dan lintang pada permukaan bumi

taksi-taksi
dengan
Dibutuhkan dua titik dengan bujur
terdekat untuk mendapatkan jarak lingkaran

pelanggan besar (Veness, 2009).
tidak diketahui.
Pelanggan harus dapat menghubungi
Masalah 2.
orang yang dapat melaksanakan
Operator yang sibuk keinginannya

sehingga
dengan
cepat
dan
ada mudah. Masalah pelanggan, yang
pelanggan yang harus sudah menelepon atau menulis surat

menunggu
dilayani dan tahu bahwa ia sedang melakukan
bahkan tidak sempat kontak, harus diambil alih secara

terlayani.
cepat dan efisien. Dengan kata lain,

pelanggan harus segera tahu bahwa
mereka
tidak
lagi
menghadapi
masalah, karena masalah itu sudah

ditanggulangi sistem (Armistead, et
al., 1996).
2.
Proses
Masalah 3.
Kesalahan manusia (human error)
broadcast
Faktor manusia yang adalah
pesanan taksi
memungkinkan
perilaku
keseluruhan
yang
secara
diharapkan
untuk
operator menyebarkan membuat hasil yang diinginkan,
41
No.
Nama Proses
Masalah
Verifikasi Studi Literatur
informasi yang salah namun

ke
taksi
perilaku
itu
pada
dan kenyataannya tidak membuat hasil
memasukkan informasi yang diinginkan itu (Marguglio,

yang salah ke sistem / 2009)
berkas
penyimpanan
data.
3.1.2. Analisis Wawancara dan Kuesioner

Survei
dengan
menggunakan
kuesioner
dibuat
untuk
mengkonfirmasi
permasalahan teridentifikasi dari observasi pada proses bisnis berjalan atau untuk
menemukan apakah ada masalah lain yang terjadi dalam proses bisnis berjalan. Survei
ini ditujukan untuk pelanggan taksi yang berada di Jakarta yang menggunakan telepon
untuk memesan taksi. Survei dilakukan dengan mengambil 50 orang pelanggan taksi
sebagai sampel pada Januari 2010. Daftar pertanyaan pada kuesioner ini terdapat pada
Tabel L6.
Selain survey, juga dilakukan wawancara terhadap dua orang sopir taksi dan dua
operator taksi. Wawancara terhadap sopir taksi dilakukan untuk mengkonfirmasi
permasalahan khususnya masalah ketiga (human error pada operator). Tabel L4 berisi
daftar pertanyaan wawancara terhadap sopir taksi. Wawancara terhadap operator
dilakukan untuk mengkonfirmasi permasalahan khususnya permasalahan kedua. Tabel
L5 berisi daftar pertanyaan wawancara terhadap operator.
42
Setelah survei dilakukan, ditemukan fakta sebagai berikut. Dari pertanyaan
pertama, 48% responden menyatakan pernah menemukan operator taksi sibuk ketika
mereka menelepon. 52% sisanya menyatakan tidak pernah menemukan operator taksi
sibuk. Persentase jawaban responden digambarkan pada Gambar 3.3.
Gambar 3.3. Respons Pelanggan Terhadap Survey Pertanyaan 1
Dari pertanyaan kedua, 58% responden menyatakan bahwa mereka menunggu

taksi selama 10-20 menit. 32% responden menyatakan bahwa mereka menunggu taksi
selama lebih dari 20 menit. 10% sisanya menyatakan bahwa mereka menunggu kurang
dari 10 menit. Persentase jawaban responden digambarkan pada Gambar 3.4.
43
Dari pertanyaan ketiga, 66% responden menyatakan bahwa waktu tunggu taksi
adalah masalah untuk mereka. 34% sisanya menyatakan bahwa hal tersebut bukanlah
masalah. Persentase jawaban responden digambarkan pada Gambar 3.5.
Dari pertanyaan keempat, 58% responden menyatakan bahwa mereka pernah

memesan taksi dan taksi yang dipesan tidak datang. 42% sisanya sebaliknya. Persentase
jawaban responden digambarkan pada Gambar 3.6.
44
Dari pertanyaan kelima, 90% responden menyatakan informasi tentang taksi

yang akan menjemput mereka itu penting. 10% sisanya menyatakan sebaliknya.
Persentase jawaban responden digambarkan pada Gambar 3.7.
Dari pertanyaan keenam, diketahui bahwa 22% pemesan taksi mempunyai

perangkat BlackBerry. Persentase jawaban responden digambarkan pada Gambar 3.8.
45
Dari wawancara terhadap sopir taksi, ditemukan bahwa memang ada

permasalahan pada faktor human error pada operator. Sopir taksi mengaku pernah
terjadi kesalahan lokasi penjemputan pelanggan karena salahnya informasi dari operator.
Dari wawancara terhadap operator, ditemukan bahwa jumlah operator yang
beroperasi hanya dua pada suatu waktu. Jumlah ini belum cukup untuk melayani
panggilan masuk dari pelanggan pada satu waktu. Hal ini menyebabkan sering sibuknya
operator dalam melayani panggilan pelanggan.
Berdasarkan jawaban para responden atas pertanyaan-pertanyaan di kuesioner
dan wawancara, permasalahan-permasalahan yang dilihat pada saat observasi dapat
dikonfirmasi. Daftar permasalahan tersebut ada pada Tabel 3.8.
Tabel 3.8. Daftar Permasalahan Dari Hasil Kuesioner dan Wawancara

No
1
Permasalahan
Operator
saat
sibuk
Aktor
pada Pelanggan
pelanggan
Evaluasi Dari
Kuesioner pertanyaan 1,
wawancara terhadap operator.
46
No
Permasalahan
Aktor
Evaluasi Dari
menelepon
2
Pelanggan merasa taksi Pelanggan

membutuhkan
Kuesioner pertanyaan 2 dan 3
waktu
lama untuk sampai ke

pelanggan
3
Kesalahan
pemberian Pelanggan
Kuesioner pertanyaan 4,
informasi
pelanggan
wawancara terhadap sopir taksi.
kepada taksi yang dapat

menyebabkan
taksi
tidak
pada
sampai
pelanggan
4
Pelanggan
Pelanggan
Kuesioner pertanyaan 5.
membutuhkan
informasi tentang taksi
yang
akan
menjemputnya
3.1.3. Analisis Permasalahan

Berdasarkan daftar permasalahan pada Tabel 3.7 yang didapatkan dari observasi
terhadap proses bisnis yang sedang berjalan dan berdasarkan daftar permasalahan hasil
survei dan wawancara pada Tabel 3.8, akar masalah yang terjadi pada sistem pemesanan
47
taksi adalah tidak diketahuinya posisi pelanggan dan taksi-taksi di sekitarnya. Jika posisi
taksi dan pelanggan tidak diketahui, sistem tidak bisa mencarikan taksi-taksi terdekat
untu pelanggan.
Kenapa sistem harus mampu mencarikan taksi-taksi terdekat untuk pelanggan?
Sesuai dengan pernyataan Daft yang tertulis pada teori layanan di subbab 2.8, suatu
layanan harus ditempatkan dekat secara geografis dengan pelanggan untuk mempercepat
dan memudahkan pelanggan untuk mengakses layanan tersebut.
Pernyataan di atas sesuai dengan masalah yang ditemukan dari kuesioner, yaitu
pelanggan merasa taksi membutuhkan waktu lama untuk sampai ke lokasi pelanggan.
Hal ini bertentangan dengan pernyataan Daft, yaitu, Sebuah layanan harus bisa segera
disediakan ketika pelanggan menginginkan dan membutuhkannya. Hal ini juga
bertentangan dengan pernyataan Armistead, yaitu, Masalah milik pelanggan yang
sudah menelepon atau menulis surat dan tahu bahwa ia sedang melakukan kontak harus
diambil alih secara cepat dan efisien.
Jika posisi pelanggan dan taksi-taksi di sekitarnya diketahui, sistem bisa
mencarikan beberapa taksi-taksi terdekat, dan tentunya yang tidak sedang mengantarkan
pelanggan lain atau sopirnya sedang istirahat, untuk kemudian menyebarkan pesanan
pelanggan ke taksi-taksi terdekat itu saja.
Selain itu, masalah lain yang teridentifikasi adalah sibuknya operator, kesalahan
penyampaian informasi oleh operator, dan kebutuhan pelanggan akan informasi taksi
yang akan menjemputnya. Masalah sibuknya operator terjadi karena sedikitnya jumlah
operator yang bekerja pada satu waktu. Permasalahan kesalahan penyampaian informasi
oleh operator dianggap sebagai masalah berdasarkan wawancara terhadap sopir taksi.
Tabel 3.9. Rangkuman Masalah Teridentifikasi Pada Proses Bisnis Berjalan

No
1
Permasalahan Teridentifikasi
Sumber Identifikasi
Posisi pelanggan dan taksi- Pengamatan lapangan
Masalah milik pelanggan yang sudah menelepon atau menulis
taksi
surat dan tahu bahwa ia sedang melakukan kontak harus diambil
di
sekitarnya
tidak
diketahui sehingga sistem tidak
alih secara cepat dan efisien (Armistead, et al., 1996)
bisa
Dibutuhkan dua titik dengan bujur dan lintang pada permukaan
mencarikan
taksi-taksi
terdekat
2
Landasan Teori
bumi untuk mendapatkan jarak lingkaran besar (Veness, 2009)
Kesalahan
pemberian Pengamatan
lapangan, Kesalahan manusia (human error) adalah perilaku yang secara
informasi pelanggan kepada wawancara dengan sopir keseluruhan diharapkan untuk membuat hasil yang diinginkan,
taksi yang dapat menyebabkan taksi, dan kuesioner
namun perilaku itu pada kenyataannya tidak membuat hasil yang
taksi
diinginkan itu. (Marguglio, 2009)
tidak
sampai
pada
pelanggan
3
Operator yang sibuk sehingga Pengamatan lapangan dan Pelanggan

ada
pelanggan
menunggu
yang
dilayani
harus kuesioner
bahkan
harus
melaksanakan
dapat
menghubungi
keinginannya
dengan
orang
cepat
yang
dan
dapat
mudah.
(Armistead, et al., 1996).
48
No
Sumber Identifikasi
Landasan Teori
tidak sempat terlayani.

4
Pelanggan
membutuhkan Kuesioner
Pelanggan harus segera tahu bahwa mereka tidak lagi
informasi tentang taksi yang
menghadapi masalah, karena masalah itu sudah ditanggulangi
menjemput
sistem (Armistead, et al., 1996)
3.1.4. Analisis Pemecahan Masalah

Berdasarkan rangkuman permasalahan yang teridentifikasi dari pengamatan lapangan dan kuesioner yang tertera pada Tabel
3.9, ada beberapa teknologi yang dapat menjadi solusi dari permasalahan-permasalahan tersebut. Teknologi tersebut antara lain GPS,
LBS, rumus haversine, web service, dan teknologi push BlackBerry. Daftar solusi terhadap permasalahan ini terdapat pada Tabel 3.10.
Tabel 3.10. Solusi Yang Diusulkan

No
1
Posisi pelanggan dan taksi- GPS
taksi
di
sekitarnya
Solusi
pada
tidak perangkat
taksi
Landasan Teori
dan GPS merupakan suatu kumpulan satelit dan sistem kontrol yang
BlackBerry. memungkinkan sebuah penerima GPS untuk mendapatkan
49
No
Solusi
diketahui sehingga sistem tidak Pengembangan

bisa
mencarikan
terdekat
Landasan Teori
LBS lokasinya di permukaan bumi 24 jam sehari (Heywood, et al.,
taksi-taksi untuk mencari taksi-taksi 2002).

terdekat
posisi
berdasarkan Layanan Berbasis Lokasi (Location-Based Services / LBS) adalah

pelanggan
dikirim
menggunakan
haversine.
yang layanan
informasi
yang
mengutilisasi
kemampuan
untuk
dengan menggunakan informasi lokasi dari perangkat bergerak dan dapat

rumus diakses
dengan
perangkat
bergerak
melalui
jaringan
telekomunikasi bergerak (Steiniger, et al., 2006).

Rumus haversine adalah persamaan yang penting pada navigasi,
memberikan jarak lingkaran besar antara dua titik pada
permukaan
Penggunaan
bola
(Bumi)
rumus
ini
berdasarkan
bujur
mengasumsikan
dan
lintang.
pengabaian
efek
ellipsoidal, cukup akurat untuk sebagian besar perhitungan, juga

pengabaian
ketinggian
bukit
dan
kedalaman
lembah
di
permukaan bumi (Veness, 2009).
50
No
3
Kesalahan
Solusi
pemberian Pengembangan
informasi pelanggan kepada pemesanan
Landasan Teori
aplikasi BlackBerry
taksi
aplikasi seluler
registrasi
mampu (BusinessDictionary.com).
menyimpan
bergerak
pintar
yang
penjelajahan web, pesan teks, pengelolaan jadwal, dan telepon
Pengembangan
yang
perangkat
di menggabungkan sejumlah fungsi termasuk surat elektronik,
taksi menyebabkan taksi tidak perangkat BlackBerry.

sampai pada pelanggan.
merupakan
ke
dalam
suatu
perangkat
portabel
data Basis data adalah satuan, tempat penyimpanan data yang besar
pelanggan (termasuk foto yang bisa digunakan bersama oleh satu maupun banyak
pelanggan)
pengguna. Selain data yang ada tidak akan berulang, semua data
akan diintegrasi dengan jumlah duplikasi yang minimum
(Connolly, et al., 2002).
Operator yang sibuk sehingga Pengembangan

ada
pelanggan
menunggu
yang
dilayani
web Web service adalah sebuah komponen aplikasi yang bisa
harus service untuk melayani diprogram dan diakses lewat protokol web standar (Peiris, et al.,
bahkan pelanggan
2007).
tidak sempat terlayani.
51
No
5
Pelanggan
Solusi
membutuhkan Implementasi
Landasan Teori
teknologi Salah satu kelebihan teknologi push BlackBerry adalah
informasi tentang taksi yang basis data dan push pada kemampuannya untuk mengirimkan informasi dengan instan.
menjemput.
sistem
yang
dibangun.
akan Teknologi push BlackBerry adalah metode komunikasi di internet

Informasi yang berbeda dengan teknologi pull yang biasa digunakan, di
tentang taksi yang akan mana pada teknologi ini, yang melakukan permintaan komunikasi
menjemput akan disimpan adalah server, bukan klien. Pada konteks pengembangan aplikasi
dalam
basis
data
dan BlackBerry, teknologi ini merujuk pada kemampuan infrastruktur
dikirimkan lewat layanan BlackBerry untuk mengirim data berdasarkan pada sebuah
push.
Basis
digunakan
untuk Basis data adalah satuan, tempat penyimpanan data yang besar
menyimpan
pelanggan,
data pemicu ke perangkat BlackBerry (Research in Motion, 2006).
data yang bisa digunakan bersama oleh satu maupun banyak

taksi,
dan pengguna. Selain data yang ada tidak akan berulang, semua data
pesanan untuk digunakan akan diintegrasi dengan jumlah duplikasi yang minimum
sistem.
(Connolly, et al., 2002).
52
Berdasarkan solusi yang terangkum, dapat disimpulkan beberapa tujuan solusi yang terdaftar pada Tabel 3.11.
Tabel 3.11. Tujuan Dari Solusi Yang Akan Dibangun

No
1.
Tujuan Solusi
Ditujukan
Informasi Yang Akan
Untuk
Diberikan Kepada Aktor
Menemukan taksi- Pelanggan
Koordinat
taksi
dan posisi pelanggan
dengan
terdekat
posisi
posisi
Keuntungan Bagi Pengguna
taksi 1. Pelanggan mengetahui taksi mana yang akan menjemput

sehingga tidak salah naik taksi
2. Pelanggan mengetahui posisi terakhir dari taksi yang akan
menjemput mereka
pelanggan
3. Sopir taksi mengetahui posisi pelanggan yang akan dijemput.

4. Diharapkan taksi relatif bisa lebih cepat untuk sampai ke
lokasi pelanggan
2.
Menyampaikan
informasi
Sopir taksi
Posisi pelanggan, foto 1.
Taksi sampai ke lokasi pelanggan yang tepat dan tidak
pelanggan, dan alamat menjemput pelanggan yang salah.
53
No
Tujuan Solusi
pelanggan
Ditujukan
Informasi Yang Akan
Untuk
Diberikan Kepada Aktor
yang
Keuntungan Bagi Pengguna
pelanggan.
tepat kepada sopir

taksi
3.
Memberikan
Pelanggan
pelanggan
informasi
Nomor kendaraan taksi, 1. Pelanggan mendapatkan informasi yang tepat tentang taksi
posisi taksi
yang
mana yang akan menjemputnya, sehingga pelanggan tidak naik

pada taksi yang salah.
tepat tentang taksi

yang menjemput
3.2.
Perancangan Sistem Solusi

Setelah tujuan solusi-solusi yang akan menjawab permasalahan terangkum pada Tabel 3.10, proses-proses bisnis apa saja yang
dibutuhkan untuk mewujudkan tujuan solusi tersebut dianalisis. Proses-proses bisnis yang tertera pada Tabel 3.12 ini akan
digabungkan ke dalam suatu sistem pemesanan taksi baru yang digambarkan pada Gambar 3.9..
54
Tabel 3.12. Proses Bisnis Digunakan Untuk Mewujudkan Tujuan Solusi.

No
Tujuan Solusi
Proses Bisnis Yang Akan Digunakan
Menu dan Informasi Yang Akan

Terdapat Dalam Proses Bisnis
1.
Menemukan
posisi Proses 1: Proses pemesanan taksi
Proses 1: Proses pemesanan taksi
pelanggan dan taksi- Input: ID pelanggan, lokasi pelanggan, koordinat Menu: Menu pemesanan pada layar pemesanan
taksi terdekat dengan posisi pelanggan, ID taksi, lokasi taksi
posisi pelanggan.
Proses:
- Kalkulasi jarak terdekat antara taksi dan
pelanggan dengan rumus haversine
- Penyimpanan hasil kalkulasi dalam basis data
Output: Data pesanan tersimpan dalam basis data
2.
Menyampaikan
Proses 1: Proses registrasi pelanggan
Proses 1: Proses registrasi pelanggan
informasi pelanggan Input: Nama, lokasi, nomor telepon pelanggan, Menu: Menu registrasi pelanggan baru, menu
yang tepat kepada foto diri pelanggan, dan BlackBerry PIN
update profil pelanggan, menu login, dan menu
sopir taksi
deregistrasi pelanggan
Proses:
55
No
Tujuan Solusi

Proses
upload
foto
diri
pelanggan
dan
penyimpanan data pelanggan pada basis data
Proses 2: Proses login pelanggan
Output: Pelanggan mendapatkan ID pelanggan dan Menu: - (dilakukan secara otomatis oleh aplikasi)
data pelanggan tersimpan pada basis data
Proses 3: Proses pengambilan daftar pelanggan
Proses 2: Proses login pelanggan
Menu: - (dilakukan secara otomatis oleh aplikasi)
Input: BlackBerry PIN

Proses:
-
Proses pengiriman BlackBerry PIN ke web
service untuk mendapatkan ID pelanggan, nama

pelanggan, lokasi pelanggan, dan koordinat posisi
pelanggan untuk digunakan oleh aplikasi pada
perangkat BlackBerry untuk proses pemesanan.
56
No
Tujuan Solusi

Output: ID, nama, lokasi, dan koordinat posisi

pelanggan tersimpan di aplikasi pada perangkat
BlackBerry.
Proses 3: Proses pengambilan daftar pelanggan.

Input: Data pesanan yang berisi daftar dari ID,
nama, lokasi, dan koordinat posisi pelanggan
terdekat untuk ID taksi tertentu.
Proses:
- Proses pemanggilan web service oleh aplikasi
taksi untuk mendapatkan daftar pelanggan terdekat
yang memesan taksi.
- Proses penampilan daftar pelanggan di layar
57
No
Tujuan Solusi

aplikasi taksi.
Output: Daftar pelanggan terdekat tampil di layar.
3.
Memberikan
Proses 1: Proses pemilihan pelanggan yang akan Proses 1: Proses pemilihan pelanggan yang akan
pelanggan informasi dijemput
dijemput.
tentang taksi yang Input: Daftar pelanggan terdekat dengan taksi, data Menu: Menu pemilihan pelanggan yang akan
dijemput.
menjemput
taksi.
Proses:
- Proses pengiriman ID pelanggan, taksi dan
pesanan ke web service.
- Proses pemanggilan fungsi push pada BES.
- Proses konfirmasi pesanan.
- Proses penampilan peta pada aplikasi pemesanan
dan detail pelanggan pada aplikasi taksi.
58
No
Tujuan Solusi

Output: Pelanggan menerima data tentang taksi

yang akan menjemput. Detail pelanggan, termasuk
foto pelanggan, tampil di layar aplikasi taksi.
59
60
3.2.1. Use Case Diagram
Untuk memperjelas solusi yang diusulkan, berikut narasi cara kerja solusi secara
umum seperti tergambar pada Gambar 3.9.
1. Pelanggan taksi melakukan registrasi pada sistem melalui antarmuka web. Pada
registrasi, pelanggan akan diminta nama Pelanggan yang telah melakukan
registrasi akan mendapatkan ID pelanggan unik untuk digunakan selanjutnya.
2. Pelanggan yang terregistrasi melakukan pemesanan taksi dengan mengirimkan
informasi lokasi pemesanan. Informasi pelanggan beserta posisi yang dicari oleh
GPS tertanam akan dikirmkan ke server sistem.
3. Server akan mencari taksi terdekat untuk pelanggan yang memesan taksi.
Pencarian taksi terdekat dilakukan dengan perhitungan jarak terdekat antara
posisi pelanggan yang dikirimkan dan posisi taksi yang berada pada jangkauan
pencarian taksi disekitar posisi pelanggan.
4. Aplikasi pada kendaraan taksi akan menampilkan posisi taksi pada peta dan akan
me-request posisinya lewat perangkat GPS setiap periode tertentu dan akan
mengirimkan posisinya ke server. Server akan merespons dengan daftar
pelanggan yang tersedia untuk taksi tersebut, dengan syarat taksi tersebut sedang
dalam keadaan tersedia (tidak melayani pelanggan). Aplikasi taksi akan
menampilkan daftar pelanggan yang diterima untuk dipilih salah satunya.
5. Ketika taksi memilih salah satu pelanggan yang bisa dilayaninya, maka aplikasi
akan mengirimkan informasi pelanggan yang terpilih ke server melalui jaringan
internet. Aplikasi taksi juga akan menampilkan foto pelanggan yang memesan
untuk membantu sopir taksi mengidentifikasi pelanggan. Pada saat ini taksi
61
sedang dalam kondisi menunggu konfirmasi pelanggan dan tidak bisa memilih
pelanggan lainnya.
6. Kiriman informasi dari aplikasi taksi pada server akan diproses. Kemudian
informasi taksi yang akan melayani pelanggan akan dikirimkan ke pelanggan
melalui teknologi push BlackBerry. Pengiriman dilakukan lewat server milik
BlackBerry, yaitu BlackBerry Enterprise Server (BES) yang akan diteruskan
langsung ke perangkat BlackBerry milik pemesan taksi.
7. Aplikasi BlackBerry akan menerima informasi push yang terkirim, dan aplikasi
akan meminta konfirmasi pelanggan dan mengirimkan konfirmasi tersebut ke
server.
8. Aplikasi taksi yang sedang dalam keadaan menunggu konfirmasi pelanggan
mengecek secara periodik ke server. Begitu ada informasi konfirmasi pelanggan
yang direspons oleh server, maka aplikasi taksi akan mengubah kondisi menjadi
sedang melayani pelanggan. Aplikasi taksi juga akan menampilkan posisi
pelanggan pada peta untuk mempermudah taksi mencapai lokasi pelanggan.
62
Gambar 3.9. Gambaran Sistem Secara Umum
Dari gambaran sistem secara umum di atas, solusi sistem yang diusulkan dapat
dibagi menjadi lima subsistem, yakni subsistem aplikasi taksi, subsistem aplikasi
BlackBerry, subsistem aplikasi administrator, subsistem aplikasi server, dan subsistem
registrasi. Gambaran masing-masing bagian dijelaskan di bagian berikut.
63
Gambaran Subsistem Aplikasi Taksi
Cara kerja subsistem aplikasi taksi dideskripsikan sebagai berikut, seperti pada
Gambar 3.10.
1. Pertama kali aplikasi taksi dibuka, maka aplikasi akan membuka dialog input
untuk menanyakan nomor kendaraan taksi. Nomor tersebut akan dikirimkan ke
server lewat koneksi internet. Server akan merespons dengan nomor ID taksi
yang akan disimpan oleh aplikasi untuk selanjutnya.
2. Aplikasi akan menampilkan peta dan penunjuk posisi kendaraan taksi. Sambil
setiap periode tertentu aplikasi me-request posisi kendaraan lewat perangkat
GPS. Posisi tersebut akan disimpan dan aplikasi secara otomatis meng-update
indikator posisi taksi pada peta.
3. Aplikasi taksi mempunyai dengan empat kondisi, kondisi awal saat aplikasi
mulai dibuka adalah kondisi tersedia, di mana kondisi tersebut berarti taksi
sedang dalam keadaan kosong, sopir taksi dapat melayani pelanggan. Dalam
kondisi ini aplikasi akan secara periodik mengirimkan posisinya ke server. Bila
ada pelanggan tersedia untuk taksi tersebut, server akan merespons dengan daftar
pelanggan taksi yang dapat dilayani oleh taksi tersebut (daftar pelanggan tersebut
sudah diproses oleh server, yang merupakan pelanggan dengan jarak terdekat
dengan kendaraan taksi). Daftar pelanggan tersebut akan ditampilkan pada
aplikasi agar bisa dipilih oleh sopir taksi.
4. Kondisi kedua dari aplikasi taksi adalah tidak tersedia, yang berarti taksi sedang
tidak beroperasi. Dalam kondisi ini, aplikasi akan tetap mengirimkan posisi taksi
untuk di-update pada server, tetapi server tidak merespons dengan daftar
pelanggan yang mungkin dilayani oleh taksi.
64
5. Kondisi ketiga dari aplikasi taksi adalah menunggu konfirmasi pelanggan.
Kondisi ini dimulai ketika taksi memilih salah satu dari beberapa pelanggan yang
ditampilkan aplikasi. Pada kondisi ini, aplikasi secara periodik mengirimkan
posisi taksi ke server dan server akan memberi tahu aplikasi taksi jika pelanggan
taksi yang dipilih memberikan konfirmasi pemesanan. Aplikasi akan
menampilkan foto pelanggan yang dipilih untuk membantu sopir taksi
mengidentifikasi pelanggan. Selain itu, aplikasi juga akan menampilkan
indikator posisi pelanggan pada peta untuk mempermudah navigasi sopir taksi ke
lokasi pelanggan. Aplikasi tidak akan menampilkan daftar pelanggan lainnya
dalam kondisi ini.
6. Kondisi keempat dari aplikasi taksi adalah sedang melayani pelanggan. Kondisi
ini terjadi ketika taksi menerima respons konfirmasi. Pada kondisi ini aplikasi
akan tetap mengirimkan posisi taksi ke server secara periodik. Untuk mengakhiri
kondisi keempat ini, pengguna aplikasi harus mengubah kondisinya menjadi
tersedia denga cara menekan tombol yang disediakan.
7. Aplikasi memungkinkan sopir taksi secara proaktif mengubah status ketersediaan
taksi menjadi tersedia atau tidak tersedia. Ketika sopir taksi memilih salah satu
kondisi tersebut secara proaktif (menekan salah satu tombol pengubah kondisi)
atau ketika aplikasi secara implisit mengubah kondisinya, maka informasi
kondisi akan dikirimkan ke server untuk mengubah kondisi taksi pada basis data.
65
Gambar 3.10. Gambaran Subsistem Aplikasi Taksi
Gambaran Subsistem Aplikasi Administrator

Cara kerja subsistem aplikasi administrator yang tergambar pada Gambar 3.11
dideskripsikan sebagai berikut.
1. Aplikasi terhubung langsung ke basis data. Saat pertama kali aplikasi dijalankan,
daftar taksi dan pelanggan yang ada akan ditampilkan pada tabel. Setiap periode
tertentu, daftar taksi dan pelanggan yang ada akan di-update dari basis data.
2. Pengguna aplikasi dapat melihat informasi taksi dengan memilih salah satu dari
beberapa taksi yang ada pada daftar taksi. Informasi yang ada meliputi nomor
66
kendaraan, posisi, dan kondisi operasional taksi. Pada saat ini daftar pelanggan
yang ditampilkan hanya pelanggan yang mungkin dilayani oleh taksi (hasil
pemrosesan pelanggan terdekat dengan kendaraan taksi). Penunjuk posisi taksi
dan penunjuk posisi-posisi pelanggan yang mungkin dilayani akan ditampilkan
pada peta.
3. Pengguna aplikasi dapat melihat informasi pelanggan dengan memilih salah satu
dari beberapa pelanggan yang ada pada daftar pelanggan. Informasi yang
ditampilkan meliputi data diri pelanggan dan posisi pelanggan.
4. Pengguna aplikasi dapat menambahkan data taksi baru, mengubah data taksi
yang sudah ada, dan menghapus data taksi yang sudah ada. Dialog input untuk
mengisi data taksi akan ditampilkan ketika pengguna ingin menambah atau
mengubah data taksi.
Database
Buat, lihat, dan hapus data taksi.

Lihat data pelanggan
Aplikasi Administator
Gambar 3.11. Gambaran Subsistem Aplikasi Administrator
67
Gambaran Subsistem Aplikasi BlackBerry
Seperti pada Gambar 3.12, cara kerja subsistem aplikasi BlackBerry
dideskripsikan sebagai berikut.
1. Ketika dibuka pertama kali, Aplikasi akan terhubung ke subsistem aplikasi server
dan akan meng-query data pelanggan yang terregistrasi untuk proses pemesanan.
Aplikasi akan memberitahukan pengguna yang belum melakukan registrasi untuk
meregistrasikan diri ke website yang disediakan.
2. Aplikasi akan menyimpan dan menampilkan alamat pemesanan terakhir untuk
memudahkan pelanggan jika ingin memesan di lokasi yang sama. Jika pelanggan
ingin memesan di lokasi yang berbeda, pelanggan dapat memasukkan informasi
lokasi yang baru dan aplikasi akan mengambil posisi pelanggan lewat GPS
tertanam dari perangkat BlackBerry. Informasi lokasi pemesanan akan
dikirimkan oleh aplikasi ke server sistem melalui internet di perangkat
BlackBerry.
3. Aplikasi akan menampilkan pesan kepada pengguna untuk menunggu respons
dari server. Pada saat ini aplikasi mulai membuka push listener agar bisa
menerima respons dari BES. Server akan merespons dengan informasi taksi yang
akan melayani pengguna lewat teknologi push BlackBerry. Informasi tersebut
ditangkap oleh listener dan aplikasi akan menampilkan informasi taksi,
kemudian menanyakan konfirmasi kepada pengguna apakah pengguna akan
menggunakan jasa taksi dengan informasi taksi yang dikirim atau membatalkan
pemesanan. Konfirmasi tersebut akan dikirimkan kembali ke server sistem
melalui koneksi internet.
68
4. Jika pengguna memilih untuk menggunakan jasa taksi yang informasinya
ditampilkan, maka aplikasi akan menampilkan peta posisi pengguna dan posisi
taksi yang akan menjemput pengguna, dari kondisi ini pengguna dapat secara
proaktif mengakhiri aplikasi (selesai).
Mendapatkan lokasi dengan GPS
Database
Pesan taksi
Servis Web
Pelanggan
Ki
sh
Pu
sh
Pu
an
ta
da
ta
tak
in
rm
pe
si
rim
Gambar 3.12. Gambaran Subsistem Aplikasi BlackBerry
Gambaran Subsistem Aplikasi Server

Seperti pada Gambar 3.13, cara kerja subsistem aplikasi server dideskripsikan
sebagai berikut.
69
1. Aplikasi server pada sistem berupa web service. Web service ini terhubung
langsung ke basis data untuk melakukan operasi manipulasi data. Subsistem
aplikasi taksi dan aplikasi BlackBerry akan berhubungan dengan web service ini.
2. Aplikasi server dapat meminta BES untuk mengirimkan informasi ke perangkat
BlackBerry milik pelanggan lewat teknologi push BlackBerry.
3. Aplikasi server akan melakukan perhitungan jarak tanpa rute menggunakan
persamaan haversine yang tertera pada Persamaan 2.
Gambar 3.13. Gambaran Subsistem Aplikasi Server
70
Gambaran Subsistem Registrasi
Cara kerja subsistem registrasi adalah seperti digambarkan pada Gambar 3.14
adalah sebagai berikut.
1. Pelanggan baru yang belum terdaftar dapat mendaftarkan perangkat BlackBerry
nya pada sistem registrasi berbasis web. Pelanggan yang telah melakukan
registrasi akan mendapatkan ID pelanggan.
2. Pelanggan yang sudah terdaftar dapat melakukan login menggunakan ID
pelanggan dan BlackBerry PIN untuk masuk ke halaman profil.
3. Pada halaman profil, pelanggan dapat mengubah informasi registrasinya,
menghapus keanggotaan, dan logout untuk kembali ke halaman utama.
Gambar 3.14. Gambaran Subsistem Registrasi
71
3.2.2. Use Case Diagram
Berdasarkan dari gambaran sistem yang ada, proses-proses yang berhubungan
dengan aktor dapat digambarkan dengan use case diagram. Use case diagram sistem
dibagi menjadi empat use case diagram subsistem agar
perancangan sistem lebih
mudah dipahami.
3.2.2.1.Use Case Diagram Subsistem Aplikasi BlackBerry

Dalam subsistem aplikasi BlackBerry, yang menjadi aktor adalah pelanggan
(atau customer dalam use case diagram pada Gambar 3.15). Seorang pelanggan dapat:
1. Login (use case Login. Deskripsi tertera pada Tabel 3.13, dan alirannya
dijelaskan pada Tabel 3.14).
2. Memesan taksi (use case Order Taxi. Deskripsi tertera pada Tabel 3.15, dan
alirannya dijelaskan pada Tabel 3.16).
3. Mengkonfirmasi pesanan (use case Confirm Order. Deskripsinya tertera pada
Tabel 3.17, dan alirannya dijelaskan pada Tabel 3.18).
4. Melihat indikator posisi taksi dan pelanggan pada peta (use case View Map.
Deskripsinya tertera pada Tabel 3.19, dan alirannya dijelaskan pada Tabel 3.20).
5. Mengulangi pesanan (use case Retry Order. Deskripsinya tertera pada Tabel
3.23, dan alirannya dijelaskan pada Tabel 3.24).
6. Membatalkan pemesanan (use case Cancel Order. Deskripsinya tertera pada
Tabel 3.21, dan alirannya dijelaskan pada Tabel 3.22).
72
BlackBerry
Application Subsystem
Order Taxi
Login
Retry Order
View Map
Cancel Order
extends
Customer
Confirm Order
Gambar 3.15. Use Case Diagram Subsistem Aplikasi BlackBerry
Tabel 3.13. Deskripsi Use Case Login

Name
Login
Actors
Customer (Pelanggan)
Description

taksi
Precondition
Postcondition
Data pelanggan diterima aplikasi

Pelanggan mendapatkan posisi dari GPS
Form pemesanan taksi ditampilkan aplikasi
73
Tabel 3.14. Aliran Use Case Login
Flow
Normal
Actor Action
Step 1.
Pelanggan
System Response
Step 2.
membuka Aplikasi
menghubungkan
aplikasi pemesanan taksi di diri dengan web service,

perangkat BlackBerry.
mengirimkan
PIN
BlackBerry
sebagai
otentikasi
pelanggan.
Step 3.
Aplikasi menerima nama,
alamat,
dan
posisi
pelanggan dari web service.

Step 4.
Aplikasi
informasi
mengambil
posisi
dari
perangkat GPS.
Step 5.
Aplikasi menampilkan form
pemesanan.
Alternate
Alt Step 3.
Apabila pelanggan belum
terdaftar di basis data, maka
pelanggan akan diberitahu
74
Flow
Actor Action
System Response
untuk
mendaftar
terlebih
dulu.
Tabel 3.15. Deskripsi Use Case Order Taxi

Name
Order Taxi
Actors
Description

taksi
Precondition
Pelanggan sudah melakukan use case Login
Postcondition
Data pesanan pelanggan tertulis di basis data.
Tabel 3.16. Aliran Use Case Order Taxi

Flow
Normal
Actor Action
Step 1.
Pelanggan
System Response
Step 3.
mengganti Aplikasi
menghubungkan
alamat bila diperlukan dan diri dengan web service,

menekan
ORDER.
tombol mengirimkan
data
pelanggan ke web service.

Step 4.
Web service mencari taksitaksi terdekat dengan rumus
haversine.
75
Flow
Actor Action
System Response
Step 5.
Aplikasi menunggu push
data dari server
Alternate
ALT Step 5.
Jika
aplikasi
tidak
menerima push data dalam

90 detik, maka aplikasi akan
menampilkan
dialog
pemesanan ulang
Tabel 3.17. Deskripsi Use Case Confirm Order

Name
Confirm Order
Actors
Description
Use
case
menggambarkan
bagaimana
pelanggan
mengkonfirmasi pesanan taksi

Precondition
Pelanggan telah melakukan pemesanan taksi

Aplikasi telah mendapatkan push data
Postcondition
Data pesanan terbarui di basis data

Status
ketersediaan
di
aplikasi
SERVICING
Tabel 3.18. Aliran Use Case Confirm Order
taksi
menjadi
76
Flow
Normal
Actor Action
Step 1.
Step 2.
Pelanggan
tombol
System Response
OK
menekan Aplikasi
di
konfirmasi.
layar menghubungkan
diri
dengan web service, lalu

mengirimkan
data
konfirmasi.
Step 3.
Web service memperbarui
isi basis data.
Step 4.
Aplikasi
konfirmasi
taksi
mengecek
pesanan
mengubah
dan
status
ketersediaan taksi menjadi

SERVICING.
Alternate
Tabel 3.19. Deskripsi Use Case View Map

Name
View Map
Actors
77
Description
Use
case
menggambarkan
bagaimana
aplikasi
menampilkan BlackBerry Maps.

Precondition
Pelanggan telah melakukan konfirmasi pemesanan taksi

(dengan use case Confirm Order).
Postcondition
BlackBerry Maps terbuka.
Tabel 3.20. Aliran Use Case View Map

Flow
Normal
Actor Action
-
System Response
Step 1.
Aplikasi
menginisiasi
BlackBerry Maps dengan

mengirimkan
data
posisi
taksi dan posisi pelanggan.

Step 2
Aplikasi
BlackBerry
memanggil
Maps
menampilkan peta.
Alternate
Tabel 3.21. Deskripsi Use Case Cancel Order

Name
Cancel Order
Actors
untuk
78
Description
Use
case
menggambarkan
bagaimana
pelanggan
membatalkan pesanan taksi.

Precondition
Pelanggan telah melakukan pemesanan taksi.

Data taksi telah diterima pelanggan.
Postcondition
Data pesanan terbaharui di basis data.
Tabel 3.22. Aliran Use Case Cancel Order

Flow
Normal
Actor Action
Step 1.
Pelanggan
System Response
Step 2.
menekan Aplikasi
tombol Cancel di layar menghubungkan

konfirmasi.
diri
dengan web service, lalu

mengirimkan
data
konfirmasi. Web service lalu

memperbarui isi basis data.
Step 3.
Aplikasi
konfirmasi
taksi
mengecek
pesanan
mengubah
dan
status
ketersediaan taksi menjadi

AVAILABLE.
Step 4.
Aplikasi menutup dirinya
79
Flow
Actor Action
System Response
sendiri.
Alternate
Tabel 3.23. Deskripsi Use Case Retry Order

Name
Retry Order
Actors
Description
Use case menggambarkan bagaimana Pelanggan mencoba

memesan taksi kembali.
Precondition
Pelanggan telah melakukan pemesanan taksi

Data pesanan untuk pelanggan ini telah ada di basis data,
namun aplikasi belum menerima data taksi setelah 90
detik
Postcondition
Data pesanan terbarui di basis data.

Data pesanan baru telah diterima aplikasi.
Tabel 3.24. Aliran Use Case Retry Order

Flow
Normal
Actor Action
Step 1.
Pelanggan
System Response
Step 2.
menekan Aplikasi
menghubungkan
tombol RETRY di layar diri dengan web service,

konfirmasi.
mengirimkan
data
80
Flow
Actor Action
System Response
pelanggan ke web service.
Web service mencari taksitaksi terdekat dengan rumus
haversine.
Step 3.
Aplikasi menunggu push
data dari server .
Alternate
ALT Step 1.
ALT Step 3.
Pengguna menekan tombol Jika aplikasi kembali tidak

QUIT
untuk
menutup menerima push data dalam
aplikasi (tidak memesan 90 detik, maka aplikasi akan

ulang).
menampilkan
dialog
pemesanan ulang.
3.2.2.2.Use Case Diagram Subsistem Aplikasi Administrator

Dalam
subsistem
aplikasi
administrator,
yang
menjadi
aktor
adalah
administrator. Use case diagram subsistem ini tergambar pada Gambar 3.16. Seorang
administrator dapat:
1. Memasukkan data taksi baru (use case Add New Taxi. Deskripsinya tertera pada
Tabel 3.25, dan alirannya dijelaskan pada Tabel 3.26),
2. Melihat daftar seluruh taksi (use case View Taxi List. Deskripsinya tertera pada
Tabel 3.27, dan alirannya dijelaskan pada Tabel 3.28) ,
81
3. Mengubah informasi taksi dari basis data (use case Update Taxi Info.
Deskripsinya tertera pada Tabel 3.29, dan alirannya dijelaskan pada Tabel 3.30),
4. Menghapus informasi taksi dari basis data (use case Delete Taxi Deskripsinya
tertera pada Tabel 3.31, dan alirannya dijelaskan pada Tabel 3.32), dan
5. Melihat detail informasi suatu taksi (use case View Taxi Info. Deskripsinya
tertera pada Tabel 3.33, dan alirannya dijelaskan pada Tabel 3.34).
6. Melihat daftar seluruh pelanggan di basis data (use case View Customer List.
7. Melihat detail informasi suatu pelanggan (use case View Customer Info.
8. Melihat indikator posisi taksi dan pelanggan pada peta (use case View Map.
Gambar 3.16. Use Case Diagram Subsistem Aplikasi Administrator
82
Tabel 3.25. Deskripsi Use Case Add New Taxi
Name
Add New Taxi
Actors
Administrator
Description
Use
case
menggambarkan
bagaimana
menambahkan data taksi baru ke basis data.

Precondition
Aplikasi terhubung dengan basis data.
Postcondition
Data taksi baru telah dimasukkan ke basis data.
administrator
83
Tabel 3.26. Aliran Use Case Add New Taxi
Flow
Normal
Actor Action
System Response
Step 1.
Step 2.
menekan Aplikasi menampilkan dialog
Administrator
tombol
ADD
NEW
di untuk memasukkan data taksi
antarmuka aplikasi.
baru.
Step 3.
Step 4.
Administrator mengisi data Aplikasi memasukkan data

taksi
baru
dan
menekan taksi baru ke basis data.
tombol OK
Alternate
ALT Step 3.
Administrator dapat menekan
CANCEL
membatalkan
untuk
penambahan
data taksi baru.
Tabel 3.27. Deskripsi Use Case View Taxi List

Name
View Taxi List
Actors
Administrator
Description
Use case menggambarkan bagaimana aplikasi menampilkan

data taksi dari basis data.
Precondition
Postcondition
Daftar seluruh taksi tampil di layar.
84
Tabel 3.28. Aliran Use Case View Taxi List
Flow
Normal
Actor Action
-
System Response
Step 1.
Aplikasi mengambil semua
data taksi dari basis data dan
menampilkan daftar taksi di
layar.
Alternate
Tabel 3.29. Deskripsi Use Case Update Taxi Info

Name
Update Taxi Info
Actors
Administrator
Description
Use
case
menggambarkan
bagaimana
Administrator
mengubah data taksi tertentu

Precondition
Aplikasi terhubung dengan basis data

Aplikasi menyimpan dan menampilkan daftar taksi yang ada
Postcondition
Data taksi terpilih telah diubah di basis data

Data taksi terpilih ditampilkan
85
Tabel 3.30. Aliran Use Case Update Taxi Info
Flow
Normal
Actor Action
System Response
Step 1.
Step 2.
Administrator memilih salah Aplikasi menampilkan dialog

satu taksi dari daftar taksi dan untuk mengubah data taksi.
menekan tombol UPDATE.
Step 4.
Step 3.
Aplikasi mengubah data taksi
Administrator mengisi data terpilih di basis data dan

baru untuk taksi terpilih dan menampilkan data yang baru.
menekan OK
Alternate
ALT Step 3.
Administrator dapat menekan
CANCEL
untuk
membatalkan pengubahan.
Tabel 3.31. Deskripsi Use Case Delete Taxi

Name
Delete Taxi
Actors
Administrator
Description
Use
case
menggambarkan
bagaimana
administrator
menghapus data taksi tertentu.

Precondition

Aplikasi menyimpan dan menampilkan daftar taksi yang ada
Postcondition
Data taksi terpilih telah dihapus di basis data.
86
Tabel 3.32. Aliran Use Case Delete Taxi

Flow
Normal
Actor Action
System Response
Step 1.
Step 2.
Administrator memilih salah Aplikasi
menghapus
data
satu taksi dari daftar taksi dan taksi terpilih di basis data.
menekan tombol DELETE.
Alternate
Tabel 3.33. Deskripsi Use Case View Taxi Info

Name
View Taxi Info
Actors
Administrator
Description
Use case menggambarkan bagaimana administrator melihat

informasi taksi tertentu.
Precondition

Aplikasi menyimpan dan menampilkan daftar taksi yang ada.
Ada data pesanan di basis data.
Postcondition
Data taksi terpilih ditampilkan.

Daftar
pelanggan
ditampilkan.
yang
dapat
dilayani
taksi
terpilih
87
Tabel 3.34. Aliran Use Case View Taxi Info
Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Administrator memilih salah Aplikasi menampilkan data

satu taksi dari daftar taksi.
taksi terpilih.
Step 3.
Aplikasi mengambil daftar
pelanggan
yang
dapat
dilayani taksi terpilih dari

basis
data
dan
menampilkannya.
Alternate
Tabel 3.35. Deskripsi Use Case View Customers List

Name
View Customers List
Actors
Administrator
Description
Use case menggambarkan bagaimana aplikasi melihat daftar

pelanggan.
Precondition
Postcondition
Daftar pelanggan ditampilkan.
88
Tabel 3.36. Aliran Use Case View Customers List
Flow
Normal
Actor Action
System Response
Step 1.
Step 2.
Administrator
tombol
Alternate
menekan Aplikasi mengambil daftar
SHOW
ALL pelanggan dari basis data dan
CUSTOMERS.
menampilkannya.
Tabel 3.37. Deskripsi Use Case View Customer Info

Name
View Customer Info
Actors
Administrator
Description
Use case menggambarkan bagaimana administrator melihat

informasi pelanggan tertentu.
Precondition
Postcondition
Data pelanggan terpilih ditampilkan
Tabel 3.38. Aliran Use Case View Customer Info

Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Administrator memilih salah Aplikasi menampilkan data

satu pelanggan dari daftar pelanggan terpilih
pelanggan yang ada
89
Flow
Alternate
Actor Action
System Response
-

Name
View Map
Actors
Administrator
Description

posisi taksi dan pelanggan (bila ada) di peta di layar.
Precondition
Postcondition
Indikator posisi taksi dan pelanggan (bila ada) tampil di peta

di layar.

Flow
Normal
Actor Action
-
System Response
Step 1.
Aplikasi membuat indikator
posisi taksi terpilih di tengah
kanvas peta
Step 2.
Aplikasi
mencari
berkas
gambar bagian peta utama

yang sesuai dengan posisi
90
Flow
Actor Action
System Response
taksi
terpilih
menampilkannya.
juga
akan
dan
Aplikasi
menampilkan
seluruh pelanggan yang dapat

dilayani, jika ada
Step 3.
Jika gambar peta utama tidak
memenuhi
kanvas
peta,
aplikasi akan mencari berkas

gambar bagian peta yang
bersebelahan terhadap peta
utama
Alternate
3.2.2.3.Use Case Diagram Subsistem Aplikasi Taksi

Dalam subsistem aplikasi taksi, yang menjadi aktor adalah sopir taksi (Taxi
Driver pada Gambar 3.17). Seorang sopir taksi dapat:
1. Melakukan login (use case Login. Deskripsinya tertera pada Tabel 3.41,
alirannya dijelaskan pada Tabel 3.42)
2. Mengubah status ketersediaan taksi (use case Set Taxi Availability. Deskripsinya
tertera pada Tabel 3.43, dan alirannya dijelaskan pada Tabel 3.44),
91
3. Melihat daftar pelanggan yang dipilih server untuk taksi (use case View
Customers List. Deskripsinya tertera pada Tabel 3.45, alirannya tertera pada
Tabel 3.46)
4. Memilih pelanggan dari daftar pelanggan yang ada. (use case Choose Customer.
Deskripsinya tertera pada Tabel 3.47, alirannya tertera pada Tabel 3.48)
5. Melihat indikator posisi taksi dan pelanggan di peta. (use case View Map.
Deskripsinya tertera pada Tabel 3.49, alirannya tertera pada Tabel 3.50)
Taxi Application Subsystem
Set Taxi
Availability
View Customers List

extends
Login
View Map
extends
Taxi Driver
Choose Customer
Gambar 3.17. Use Case Diagram Subsistem Aplikasi Taksi

Name
Login
Actors
Taxi Driver (Sopir Taksi)
Description
Use case menggambarkan bagaimana sopir taksi melakukan

login ke dalam sistem.
92
Precondition
Aplikasi taksi belum terhubung ke web service.

Data taksi terdapat di basis data.
Postcondition
Aplikasi terhubung dengan web service.

Aplikasi menyimpan nilai ID Taksi.

Flow
Normal
Actor Action
Step 1.
System Response
Step 1.
Sopir taksi membuka aplikasi Aplikasi menghubungkan diri

dan
memasukkan
polisi taksi.
nomor dengan web service untuk

mengecek nomor polisi taksi.
Step 2.
Aplikasi
service
memanggil
untuk
web
mengubah
status taksi di basis data

menjadi tersedia.
Step 3.
Web
service
akan
mengembalikan ID taksi.
Step 4.
Aplikasi menyimpan ID taksi
untuk dipakai di proses lain.
93
Flow
Alternate
Actor Action
System Response
-
Tabel 3.43. Deskripsi Use Case Set Taxi Availability

Name
Set Taxi Availability
Actors
Description
Use case menggambarkan bagaimana sopir taksi dapat

mengubah status ketersediaan taksi.
Precondition
Aplikasi taksi terhubung ke web service.
Postcondition
Status ketersediaan taksi di basis data berubah.

Tampilan tombol pengubah status ketersediaan berubah.
Tabel 3.44. Aliran Use Case Set Taxi Availability

Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Sopir taksi menekan tombol Aplikasi menghubungkan diri

AVAILABLE
UNAVAILABLE.
atau dengan web service untuk

mengubah status ketersediaan
taksi dalam basis data, sesuai
dengan tombol yang ditekan
sopir taksi.
Step 3.
94
Flow
Actor Action
System Response
Aplikasi
mengubah
status
tombol
pengubah
status
ketersediaan.
ditekan
Jika
yang
AVAILABLE,
maka tombol AVAILABLE

tidak bisa ditekan dan tombol
UNAVAILABLE
bisa
ditekan.
pula
Begitu
sebaliknya.
Alternate
Tabel 3.45. Deskripsi Use Case View Customer List

Name
View Customer List
Actors
Description

daftar pelanggan yang tersedia untuk taksi.
Precondition
Aplikasi taksi terhubung ke web service.
Postcondition
Aplikasi menyimpan dan menampilkan daftar pelanggan.
95
Tabel 3.46. Aliran Use Case View Customer List
Flow
Normal
Actor Action
-
System Response
Step 1.
Aplikasi menghubungkan diri
dengan
web
service
dan
mengirimkan nomor taksi dan

posisi bujur dan lintang taksi.
Step 2.
Aplikasi meminta web service
untuk mengecek ketersediaan
pelanggan berada di dekat
taksi pada basis data. Jika
ada,
web
service
mengembalikan
akan
daftar
pelanggan yang ada.

Step 3.
Aplikasi lalu menampilkan
daftar
pelanggan
yang
didapat.
Alternate Flow
Alt Step 2.
Jika tidak ada pelanggan
berada di dekat taksi, maka
web
service
tidak
96
Flow
Actor Action
System Response
mengembalikan apa-apa.
Alt Step 3.
Jika tidak ada pelanggan
tersedia,
aplikasi
menampilkan
tidak
daftar
pelanggan.
Tabel 3.47. Deskripsi Use Case Choose Customer

Name
Choose Customer
Actors
Description
Use case menggambarkan bagaimana sopir taksi memilih

salah satu pelanggan yang tersedia.
Precondition
Aplikasi menyimpan dan menampilkan daftar pelanggan.

Ada data pesanan di basis data.
Postcondition
Status ketersediaan taksi di basis data berubah.

Data pesanan di basis data berubah.
Tabel 3.48. Aliran Use Case Choose Customer

Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Sopir memilih salah satu Aplikasi menghubungkan diri

pelanggan dengan menekan dengan
web
service
dan
97
Flow
Actor Action
tombol yang tersedia.
System Response
mengirim
ID
pesanan,
pelanggan dan taksi.

Step 3.
Web
lalu
service
mengubah
yang
record
akan
pesanan
ditentukan,
lalu
mengirimkan request ke BES

untuk push data ke aplikasi
Blackberry.
Step 4.
Aplikasi
BlackBerry
menerima
mengurai
push
push
data,
data,
dan
menampilkan informasi taksi

di layar konfirmasi.
Step 5.
Aplikasi meminta web service
untuk
mengubah
status
ketersediaan taksi di basis

data menjadi WAITING.
Step 6.
Aplikasi
mengambil
foto
98
Flow
Actor Action
System Response
pelanggan
dan
detail
pelanggan lainnya dari web

service dan menampilkannya
di layar.
Alternate

Name
View Map
Actors
Description

posisi taksi dan pelanggan (bila ada) di peta di layar.
Precondition
Postcondition
Indikator posisi taksi dan pelanggan (bila ada) tampil di peta

di layar.

Flow
Normal
Actor Action
-
System Response
Step 1.
Aplikasi
mengambil
data
posisi bujur dan lintang dari
99
Flow
Actor Action
System Response
GPS.
Step 2.
Aplikasi membuat indikator
posisi taksi di tengah kanvas
peta posisi pelanggan (bila
ada).
Step 3.
Aplikasi
mencari
berkas
gambar bagian peta utama

yang sesuai dengan posisi
taksi dan menampilkannya .
Step 4.
Jika gambar peta utama tidak
memenuhi
kanvas
peta,
aplikasi akan mencari berkas

gambar bagian peta yang
bersebelahan terhadap peta
utama.
Alternate
100
3.2.2.4.Use Case Diagram Subsistem Registrasi
Dalam subsistem registrasi, seperti tergambar pada Gambar 3.18, yang menjadi
aktor adalah pelanggan. Seorang pelanggan dapat:
1. Melakukan registrasi (use case Register. Deskripsinya tertera pada Tabel 3.51,
alirannya dijelaskan pada Tabel 3.52),
2. Melakukan deregistrasi (use case Deregister. Deskripsinya tertera pada Tabel
3.53, alirannya dijelaskan pada Tabel 3.54),
3. Melakukan login ke dalam sistem (use case Login. Deskripsinya tertera pada
Tabel 3.55, alirannya dijelaskan pada Tabel 3.56),
4. Melakukan update profil (use case Update Profile. Deskripsinya tertera pada
Tabel 3.57, alirannya dijelaskan pada Tabel 3.58),
5. Melakukan logout dari sistem (use case Logout. Deskripsinya tertera pada Tabel
3.59, alirannya dijelaskan pada Tabel 3.60).
101
Gambar 3.18. Use Case Diagram Subsistem Registrasi
Tabel 3.51. Deskripsi Use Case Register

Name
Register
Actors
Description
Use case menggambarkan bagaimana pelanggan melakukan

registrasi terhadap layanan pemesanan taksi.
Precondition
Data pelanggan belum terdapat di basis data.
Postcondition
Data pelanggan tersimpan di basis data.
Tabel 3.52. Aliran Use Case Register

Flow
Actor Action
System Response
102
Flow
Normal
Actor Action
System Response
Step 1.
Step 2.
Pelanggan membuka website Sistem membaca data yang

pendaftaran,
mengisi
pendaftaran
yang
pada
memilih
form,
field diinput
pelanggan
tersedia menambahkan
data
dan
baru
foto tersebut ke basis data.
untuk diupload, dan menekan Step 3.

tombol REGISTER.
Sistem
konfirmasi
menampilkan
suksesnya
registrasi pelanggan dan ID

pelanggan.
Alternate
Tabel 3.53. Deskripsi Use Case Deregister

Name
Deregister
Actors
Description

deregistrasi terhadap layanan pemesanan taksi.
Precondition
Pelanggan telah login ke dalam sistem.
Postcondition
Pelanggan ter-deregistrasi dari sistem.
Tabel 3.54. Aliran Use Case Deregister
103
Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Pelanggan menekan tombol Sistem
menghapus
data
Unsubscribe di layar update pelanggan dari basis data.

profil.
Step 3.
Sistem menampilkan layar
login
dan
memberi
tahu
bahwa pelanggan telah sukses

di-deregistrasi.
Alternate

Name
Login
Actors
Description

login ke dalam sistem.
Precondition
Data pelanggan terdaftar di dalam basis data.
Postcondition
Pelanggan telah login ke dalam sistem.
104
Flow
Normal
Actor Action
Step 1.
Pelanggan
System Response
Step 2.
mengisi
ID Sistem melakukan validasi
pelanggan dan BlackBerry terhadap

PIN
input
pelanggan
berdasarkan data dari basis

data
dan
memberikan
pelanggan sesi login

Step 3.
Sistem
mengambil
data
pelanggan dari basis data dan

menampilkannya layar update
profil
Alternate
Tabel 3.57. Deskripsi Use Case Update Profile

Name
Update Profile
Actors
Description

login ke dalam sistem
Precondition
Pelanggan telah login ke dalam sistem
Postcondition
Data pelanggan di basis data ter-update
105
Tabel 3.58. Aliran Use Case Update Profile
Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
Pelanggan
mengubah
data Sistem
pelanggan yang ada di form pelanggan
mengubah
di
basis
data
data
profil dan menekan tombol berdasarkan input pelanggan.

Update
Step 3.
Sistem menampilkan status
update profil.
Alternate
Tabel 3.59. Deskripsi Use Case Logout

Name
Logout
Actors
Description

login ke dalam sistem
Precondition
Pelanggan telah login ke dalam sistem
Postcondition
Data pelanggan di basis data terupdate
Tabel 3.60. Aliran Use Case Logout

Flow
Normal
Actor Action
Step 1.
System Response
Step 2.
106
Flow
Actor Action
System Response
Pelanggan menekan tombol Sistem

Logout
profil.
di
layar
menghapus
sesi
update pelanggan
Step 3.
Sistem menampilkan layar
login
Alternate
3.2.3. Class Diagram

Berdasarkan use case yang telah dibuat dan pembagian sistem, dapat dirancang
kebutuhan kelas pada sistem. Pada subsistem aplikasi BlackBerry dibutuhkan kelas
untuk GPS, kelas untuk mengakses web service, kelas aplikasi BlackBerry, dan kelas
untuk tampilan layar pemesanan dan konfirmasi, kelas untuk memanggil BlackBerry
Maps, dan kelas untuk menyimpan data pelanggan yang telah login.
Pada subsistem aplikasi administrator, dibutuhkan kelas layar aplikasi, kelas
untuk menampilkan peta, kelas koneksi ke basis data dan kelas aplikasi administrator.
Pada subsistem aplikasi taksi, dibutuhkan kelas untuk mengakses GPS, kelas layar
aplikasi, dan kelas aplikasi taksi. Pada subsistem aplikasi server, dibutuhkan kelas web
service, kelas koneksi ke basis data. Pada subsistem registrasi, dibutuhkan kelas layar
login, registrasi, dan update profil. Kelas-kelas tersebut tergambar pada Gambar 3.19
dan terdaftar pada Tabel 3.61.
Gambar 3.19. Class Diagram Sistem Solusi
107
Tabel 3.61. Daftar Dan Deskripsi Kelas

Nama Kelas
OrderApplication
OrderScreen
Deskripsi
Subsistem
Asosiasi
Kelas aplikasi pemesanan pada subsistem aplikasi
Aplikasi
OrderScreen
BlackBerry
BlackBerry
Kelas yang menampilkan menampilkan form pemesanan
Aplikasi
OrderApplication, GPS,
taksi.
BlackBerry
CustomerData,
WebServiceConnection,
ConfirmationScreen.
ConfirmationScreen
Kelas untuk menampilkan dialog konfirmasi, dialog
BlackBerry
OrderApplication,
pemesanan ulang dan informasi taksi yang akan menjemput
WebServiceConnection,
pelanggan
CustomerData,
BlackberryMaps
WebServiceConnection
Kelas yang digunakan untuk komunikasi antara subsistem
Aplikasi
OrderScreen,
aplikasi BlackBerry dengan subsistem aplikasi server
BlackBerry
ConfirmationScreen
108
Nama Kelas
GPS
CustomerData
Deskripsi
Subsistem
Asosiasi
Kelas yang digunakan untuk mendapatkan posisi bujur dan
Aplikasi
OrderScreen
lintang pelanggan
BlackBerry
Kelas yang digunakan untuk menyimpan data pelanggan
Aplikasi
OrderScreen,
(posisi, nama, alamat, ID)
BlackBerry
ConfirmationScreen,
BlackBerryMaps
BlackBerryMaps
OracleXEClient
Kelas yang digunakan untuk menampilkan posisi taksi dan
Aplikasi
ConfirmationScreen,
pelanggan di aplikasi BlackBerry Maps
BlackBerry
CustomerData
Kelas untuk melakukan operasi DML pada basis data Oracle Aplikasi
Service,
XE
SmartTaxiAdministrator
server,
aplikasi
administrator
Service
Kelas yang menangani proses bisnis sistem pada penelitian Aplikasi
OracleXEClient,
seperti perhitungan jarak terdekat, pendaftaran pelanggan, server
SmartTaxiClient
pemesanan taksi, dan konfirmasi taksi
109
Nama Kelas
Maps
Deskripsi
Subsistem
Asosiasi
Kelas untuk menampilkan gambar peta dan indikator posisi Aplikasi
SmartTaxiAdministrator,
taksi dan pelanggan
SmartTaxiClient
administrator,
aplikasi taksi
Kelas aplikasi ditujukan bagi administrator untuk memantau Aplikasi

data taksi dan pelanggan
SmartTaxiClient
OracleXEClient, Maps
administrator
Kelas aplikasi ditujukan bagi taksi untuk menampilkan Aplikasi taksi
Maps, Service
informasi pelanggan, peta, dan status taksi

STRegistration_Default
Kelas dibalik halaman web yang memproses registrasi Registrasi
OracleXEClient
pelanggan baru ke dalam basis data dan login pelanggan

STRegistration_Home
Kelas dibalik halaman web yang memproses tampilan, Registrasi
OracleXEClient
pengubahan, dan penghapusan informasi pelanggan yang

terdaftar dalam basis data
110
3.3.
Perancangan Aplikasi
3.3.1. Entity Relationship Diagram

Berdasarkan perancangan yang telah dilakukan sebelumnya, dapat dibuat entitasentitas sebagai representasi data yang akan disimpan dalam basis data. Entitas-entitas
hasil analisis ini terdapat pada Gambar 3.20.
CUSTOMERS
Has
0..*
BOARDS
0..*
Has
TAXIS
1
Has
1
ORDERS
Gambar 3.20. Entity Relationship Diagram Sistem Solusi
Nama Entitas
: CUSTOMERS
Deskripsi
: Menyimpan informasi pelanggan taksi meliputi ID pelanggan, nama,

alamat, posisi bujur, posisi lintang, nomor telepon, PIN BlackBerry,
dan waktu mulai pemesanan taksi. Daftar atribut entitas ini dapat
dilihat pada Tabel 3.62 Contoh isi tabel dapat dilihat pada Tabel 3.63.
Primary Key
: CUST_ID
Tabel 3.62. Daftar Atribut Pada Entitas CUSTOMERS

Atribut
CUST_ID
Tipe Data
NUMBER
Deskripsi
ID pelanggan unik
Atribut
Tipe Data
Deskripsi
NAME
VARCHAR(25)
Nama pelanggan
ADDRESS
VARCHAR(25)
Alamat lokasi pelanggan
LONGITUDE
NUMBER
Posisi bujur pelanggan dalam satuan derajat.

Jika bernilai positif maka masuk ke bujur
timur. Jika bernilai negatif maka masuk ke
bujur barat
LATITUDE
NUMBER
Posisi
lintang
pelanggan
dalam
satuan
derajat. Jika bernilai positif maka masuk ke

lintang utara. Jika bernilai negatif maka
masuk ke lintang selatan
PHONE
CHAR(15)
Nomor telepon pelanggan
BB_PIN
CHAR(10)
PIN BlackBerry pelanggan untuk push data
IMAGE_UPLOAD
BLOB
Foto diri pelanggan untuk ditampilkan di

layar aplikasi taksi.
ORDER_START
TIMESTAMP
Waktu
mulai
pemesanan
taksi
oleh
pelanggan
Tabel 3.63. Contoh Data Pada Entitas CUSTOMERS

CUST_ID
NAME
ADDRESS LONG LAT
PHONE
BB_PIN
ORDER_
START
MARIA
JL. JPG 9
-6.20
106.7 +621234 21090abc 1/5/2010

3:23:58
CUST_ID
NAME
ADDRESS LONG LAT
PHONE
BB_PIN
ORDER_
START
OZAWA JL. JLN 5
-6.95
101.8 +626879 2a009d5f
1/5/2010
9:58:27
BIYAN
JL. U 37
-6.19
106.5 +620012 3g630g7i
1/5/2010
3:20:58
Nama Entitas
: TAXIS
Deskripsi
: Menyimpan informasi kendaraan taksi meliputi ID taksi, nomor

polisi kendaraan, posisi bujur, posisi lintang, dan status ketersediaan
taksi. Daftar atribut entitas ini dapat dilihat pada Tabel 3.64, dan
contoh isi entitas ini pada Tabel 3.65.
Primary Key
: TAXI_ID
Tabel 3.64. Daftar Atribut Pada Entitas TAXIS

Atribut
Tipe Data
Deskripsi
TAXI_ID
NUMBER
ID kendaraan taksi unik
CARPLATE
CHAR(10)
Nomor polisi kendaraan taksi
LONGITUDE
NUMBER
Posisi bujur kendaraan taksi dalam satuan

Bujur Timur. Jika bernilai negatif maka masuk
ke Bujur Barat
LATITUDE
NUMBER
Posisi lintang kendaraan taksi dalam satuan
Atribut
Tipe Data
Deskripsi
Lintang Utara. Jika bernilai negatif maka
masuk ke Lintang Selatan
STATUS
CHAR(1)
Status ketersediaan taksi dengan kode berikut.

A (Available) = Tersedia
U (Unavailable) = Tidak tersedia
W (Waiting) = Menunggu konfirmasi
pemesanan
S (Servicing) = Melayani pelanggan
Tabel 3.65. Contoh Data Pada Entitas TAXIS

TAXI_ID
CARPLATE LONGITUDE LATITUDE STATUS
B 1234 ABC -6.19
106.6
B 5678 DEF
-6.96
101.7
B 9012 GHI
-6.21
106.4
B 3456 JKL
-6.94
101.5
Nama Entitas
: BOARDS
Deskripsi
: Menyimpan informasi daftar pelanggan dengan posisi yang

berdekatan dengan taksi untuk dipilih oleh taksi. Informasi yang
disimpan meliputi ID pengumuman, ID taksi, ID pelanggan, status
ketersediaan pengumuman, dan batas waktu akhir berlakunya
pengumuman. Daftar atribut entitas ini dapat dilihat pada Tabel 3.66,
dan contoh isi entitas ini pada Tabel 3.67.
Primary Key
: BOARD_ID
Foreign Key
: TAXI_ID (TAXIS), CUST_ID (CUSTOMERS)
Tabel 3.66. Daftar Atribut Pada Entitas BOARDS

Atribut
Tipe Data
Deskripsi
BOARD_ID
NUMBER
ID pengumuman unik
TAXI_ID
NUMBER
ID taksi yang mereferensi ke entitas TAXIS
CUST_ID
NUMBER
ID pelanggan yang mereferensi ke entitas

CUSTOMERS
STATUS
CHAR(1)
Status ketersediaan pengumuman dengan

kode berikut.
A (Available) = Tersedia
C (Chosen) = Terpilih oleh taksi
U (Unavailable) = Tidak tersedia
EXPIRED
TIMESTAMP
Batas waktu akhir berlakunya pengumuman.

Secara default diberi nilai +1 menit dari
waktu dibuatnya pengumuman
Tabel 3.67. Contoh Data Pada Entitas BOARDS

BOARD_ID TAXI_ID
CUST_ID
STATUS
EXPIRED
1/5/2010 3:31:54
BOARD_ID TAXI_ID
CUST_ID
STATUS
1/5/2010 3:32:08
1/5/2010 3:32:12
1/5/2010 3:32:04
Nama Entitas
: ORDERS
Deskripsi
Menyimpan
informasi
EXPIRED
konfirmasi
pemesanan
meliputi
ID
pemesanan, ID pengumuman, status konfirmasi pemesanan, waktu

pemilihan pelanggan yang akan dilayani oleh taksi, dan waktu
konfirmasi pemesanan oleh pelanggan. Daftar atribut entitas ini dapat
dilihat pada Tabel 3.68, dan contoh isi entitas ini pada Tabel 3.69.
Primary Key
: ORDER_ID
Foreign Key
: BOARD_ID (BOARDS)
Tabel 3.68. Daftar Atribut Pada Entitas ORDERS

Atribut
Tipe Data
Deskripsi
ORDER_ID
NUMBER
ID pemesanan unik
BOARD_ID
NUMBER
ID pengumuman yang mereferensi ke entitas

BOARDS
STATUS
CHAR(1)
Status konfirmasi pemesanan dengan kode

berikut.
X (Unconfirmed) = Belum dikonfirmasi
Y (Yes) = Konfirmasi jadi pesan
N (No) = Konfirmasi batal pesan

CREATED
TIMESTAMP
Waktu
pemilihan
pelanggan
yang
akan
dilayani oleh taksi

CONFIRMED
TIMESTAMP
Waktu konfirmasi pemesanan taksi oleh

pelanggan
Tabel 3.69. Contoh Data Pada Entitas ORDERS

ORDER_ID BOARD_ID
STATUS
CONFIRMED
1/5/2010 3:31:54
1/5/2010 3:32:08
1/5/2010 3:32:12
15
1/5/2010 3:32:04
3.3.2. Rancangan Layar

3.3.2.1.Rancangan Layar Subsistem Aplikasi BlackBerry
Rancangan Layar Pemesanan
Layar pemesanan merupakan layar yang pertama kali ditampilkan begitu aplikasi
dibuka. Ketika layar ini terbuka, aplikasi akan langsung melakukan login ke dalam
sistem dan juga memerintahkan GPS untuk mengambil posisi bujur dan lintang
pelanggan saat itu. Layar ini menampilkan form yang bisa pelanggan isi dengan alamat
pemesanan, seperti pada Gambar 3.21. Semua proses pemesanan akan dilakukan setelah
pelanggan menekan tombol ORDER. Daftar rancangan komponen layar ini ditulis
pada Tabel 3.70.
Gambar 3.21. Rancangan Layar Pemesanan
Tabel 3.70. Komponen Rancangan Layar Pemesanan

Nama Komponen
Deskripsi
titleField
Judul layar pemesanan
orderInfo
Informasi tentang pemesanan.
inputAddress
Tempat input alamat pelanggan
orderButton
Tombol yang bila ditekan akan menjalankan fungsi pemesanan

taksi
statusField
Informasi status GPS dan koneksi ke web service
Rancangan Layar Konfirmasi

Layar konfirmasi merupakan layar yang menampilkan status pemesanan, dialog
konfirmasi, dan dialog pemesanan ulang. Dialog konfirmasi akan muncul apabila ada
push data dari BES. Dialog pemesanan ulang akan muncul apabila tidak ada push data
dari BES dalam kurun waktu tertentu.
Dari layar ini, aplikasi akan menampilkan peta dengan BlackBerry Maps apabila
pelanggan telah melakukan konfirmasi. Peta akan menampilkan indikator posisi taksi
dan pelanggan. Pelanggan bisa melakukan pembesaran atau pengecilan peta. Selain itu,
pelanggan juga bisa melihat detail taksi dengan memilih indikator taksi. Gambar
rancangan layar konfirmasi tertera pada Gambar 3.22. Rancangan komponen penyusun
layar ini dapat dilihat pada Tabel 3.71.
Gambar 3.22. Rancangan Layar Konfirmasi
Tabel 3.71. Komponen Rancangan Layar Konfirmasi

Nama Komponen
Deskripsi
TitleField
Judul layar konfirmasi
InfoField
Informasi status pemesanan, dapat berisi pertanyaan konfirmasi

pesanan atau pertanyaan pesanan ulang
ConfirmButton
Tempat input nama pelanggan
CancelButton
Tombol untuk membatalkan pesanan
RetryButton
Tombol untuk mengirim pesanan ulang, ditampilkan apabila

tidak ada push data hingga 90 detik
QuitButton
Tombol untuk keluar dari aplikasi. Ditampilkan bersamaan

dengan tombol RetryButton
BlackBerryMaps
Objek BlackBerry Maps untuk menampilkan peta
3
3.3.2.2.Ranc
cangan Layyar Subsisteem Aplikasi Administraator
Ranccangan layarr ini digunaakan oleh addministrator untuk menggawasi inforrmasi
t
taksi
dan peelanggan. Paada layar inni, administrrator dapat melakukan
m
p
penambahan
n data
t
taksi
baru, mengubah
m
daata taksi yanng sudah adda, dan mengghapus data taksi yang sudah
s
a
ada.
Setiap kali adminiistrator menaampilkan innformasi sebbuah taksi, maka
m
posisi taksi
a
akan
ditamp
pilkan pada panel
p
peta beerikut posisi pelanggan yang
y
dapat dilayani
d
olehh taksi
p
pada
saat itu
u.
Adm
ministrator bisa
b
memillih untuk menampilkaan daftar pelanggan yang
b
berhubungan
n (dapat dilaayani) dengan taksi yanng dipilih saaja atau mennampilkan semua
s
d
daftar
pelan
nggan yang ada (seluruhh pelanggann yang sudaah terdaftar pada basis data)
layar
d
dengan
men
nekan tombbol untuk menampilka
m
an semua pelanggan.
p
R
Rancangan
a
aplikasi
adm
ministrator tergambar
t
p
pada
Gambaar 3.23. Ranncangan kom
mponen layarnya
t
tertera
pada Tabel 3.72.
Gambarr 3.23. Ranccangan Layarr Aplikasi Administrator

A
r
Tabel 3.72. Komponen Rancangan

R
L
Layar
Aplikaasi Administtrator
Nama Komponen
Deskripsi
GroupTaxi
Bingkai yang mengelompokkan informasi taksi
TaxiID
Label field untuk menampilkan ID taksi
TaxiCarPlate
Label field untuk menampilkan nomor polisi kendaraan taksi
TaxiStatus
Label field untuk menampilkan status taksi
TaxiLatitude
Label field untuk menampilkan posisi lintang taksi
TaxiLongitude
Label field untuk menampilkan posisi bujur taksi
DataGridViewTaxi
Tabel data untuk menampilkan daftar taksi yang ada
ButtonAdd
Tombol untuk menambahkan data taksi baru ke basis data
ButtonEdit
Tombol untuk mengubah data taksi yang sudah ada dari basis data
(tampil pada DataGridViewTaxi)
ButtonDelete
Tombol untuk menghapus data taksi yang sudah ada dari basis
data (tampil pada DataGridViewTaxi)
MapCanvas
Kanvas untuk menampilkan peta dan penunjuk posisi dari taksi

tertentu beserta pelanggan yang mungkin dilayani (yang dipilih
dari DataGridViewTaxi)
GroupCustomer
Bingkai yang mengelompokkan informasi pelanggan
CustID
Label field untuk menampilkan ID pelanggan
CustName
Label field untuk menampilkan nama pelanggan
CustAddress
Label field untuk menampilkan alamat pelanggan
CustPhone
Label field untuk menampilkan nomor telepon pelanggan
CustBBPIN
Label field untuk menampilkan BlackBerry PIN pelanggan
CustLatitude
Label field untuk menampilkan posisi lintang pelanggan
Nama Komponen
Deskripsi
CustLongitude
Label field untuk menampilkan posisi bujur pelanggan
CustOrderStart
Label field untuk menampilkan waktu mulai pemesanan taksi oleh

pelanggan
CustDistance
Label field untuk menampilkan jarak hasil perhitungan antara

posisi pelanggan dan posisi taksi terdekat
CustMethod
Label field untuk menampilkan metode perhitungan yang

digunakan untuk perhitungan jarak terdekat
CustView
Label field untuk menampilkan keterangan daftar pelanggan yang

ditampilkan, ada dua yaitu semua pelanggan dan pelanggan
berdasarkan taksi yang dipilih
DataGridViewCust
Tabel data untuk menampilkan daftar pelanggan yang ada
ButtonAllCust
Tombol untuk menampilkan daftar semua pelanggan yang ada
3.3.2.3.Rancangan Layar Subsistem Aplikasi Taksi

Rancangan layar ini digunakan oleh taksi untuk menampilkan daftar pelanggan
dengan posisi terdekat dengan taksi yang berupa tombol untuk tiap pelanggan dan bisa
dipilih oleh taksi nantinya. Seperti digambarkan Gambar 3.24, pada panel peta akan
ditampilkan indikator posisi taksi pada peta sesuai bujur dan lintang taksi. Status dan
identitas taksi juga akan ditampilkan dan taksi dapat mengubah statusnya lewat dua
tombol status yang ada. Komponen rancangan layar ini terdaftar di Tabel 3.73.
Gam
mbar 3.24. Rancangan Layar Aplikaasi Taksi
Gambar 3. 25. Rancangan Layar Aplikasi Taksi: Tampil Foto Pelanggan
Tabel 3.73. Komponen Rancangan Layar Aplikasi Taksi

Nama Komponen
PanelCust
Deskripsi
Panel untuk menampilkan daftar pelanggan dengan posisi
terdekat terhadap posisi taksi
MapCanvas
Kanvas untuk menampilkan peta dan penunjuk posisi dari

taksi tertentu beserta pelanggan yang akan dilayani (yang
dipilih dari PanelCust)
CustomerPhoto
Tempat untuk menampilkan foto pelanggan yang dipilih sopir

taksi
Nama Komponen
CustomerNameLabel
Deskripsi
Label field untuk menampilkan nama pelanggan yang dipilih
sopir taksi
CustomerAddressLabel Label field untuk menampilkan alamat pemesanan pelanggan

OrderNoLabel
Label field untuk menampilkan foto pelanggan yang dipilih

sopir taksi
ButtonAvailable
Tombol untuk mengubah status taksi menjadi tersedia (aktif)
ButtonUnavailable
Tombol untuk mengubah status taksi menjadi tidak tersedia

(non-aktif)
LabelLongitude
Label field untuk menampilkan posisi bujur taksi
LabelLatitude
Label field untuk menampilkan posisi lintang taksi
LabelTaxiID
Label field untuk menampilkan ID taksi
LabelTaxiState
Label field (dengan kode warna) untuk menampilkan status

taksi
3.3.2.4.Rancangan Layar Subsistem Registrasi

Rancangan Layar Pendaftaran dan Login
Layar ini digunakan sebagai antarmuka pelanggan untuk mendaftarkan perangkat
BlackBerry mereka ke dalam sistem dan untuk login. Layar yang digambarkan pada
Gambar 3.26 ini terdiri dari dua form, yaitu form pendaftaran dan form login. Jika
pelanggan telah mendaftarkan perangkat BlackBerry mereka (yang teridentifikasi
dengan BlackBerry PIN), maka pelanggan sudah bisa melakukan login. Komponen
rancangan layar ini terdapat pada Tabel 3.74.
Gambarr 3.26. Ranccangan Layarr Pendaftaraan Dan Loginn
Tabel 3.74. Komponen

K
R
Rancangan
L
Layar
Pendaaftaran Dan Login
L
Nama Kom
mponen
Deskripssi
T
TextName
F
Field
teks unttuk mengisi nama lengkaap pelanggann baru
T
TextAddress
s
F
Field
teks unttuk mengisi alamat pelannggan baru
T
TextPhone
F
Field
teks unttuk mengisi nomor teleppon pelanggaan baru
T
TextBBPin
F
Field
teks unttuk mengisi BlackBerry PIN pelangggan baru
B
ButtonRegis
ster
T
Tombol
untukk melakukann registrasi pelanggan
p
baaru
Nama Kom
mponen
Deskripssi
T
TextCustId
F
Field
teks unttuk mengisi ID pelanggaan
T
TextPasswo
rd
F
Field
teks unttuk mengisi BlackBerry PIN
B
ButtonLogin
n
T
Tombol
untukk melakukann login ke haalaman profiil
Ranccangan Layyar Update Profil

P
Layaar ini digunnakan sebaggai antarmuuka pelangggan untuk mengubah
m
p
profil
m
mereka.
Lay
yar ini memppunyai form
m untuk menggubah namaa, alamat, noo telepon, daan BB
P pelangg
PIN
gan seperti digambarkan
d
n pada Gam
mbar 3.27 dann rancangann komponen pada
T
Tabel
3.75.
Gaambar 3.27. Rancangan

R
L
Layar
Updatte Profil
Tabel 3.75. Komponen Rancangan Layar Update Profil

Nama Komponen
Deskripsi
TextName
Field teks untuk mengisi nama lengkap pelanggan baru
TextAddress
Field teks untuk mengisi alamat pelanggan baru
TextPhone
Field teks untuk mengisi nomor telepon pelanggan baru
TextBBPin
Field teks untuk mengisi BlackBerry PIN pelanggan baru
ButtonRegister
Tombol untuk melakukan registrasi pelanggan baru
ButtonUnsubscribe
Field teks untuk mengisi ID pelanggan
Logout
Field teks untuk mengisi BlackBerry PIN
3.3.3. Sequence Diagram

Berdasarkan use case diagram dan class diagram yang telah dirancang, urutanurutan proses bisnis dan kelas-kelas yang saling berkolaborasi dapat diidentifikasi
dengan bantuan sequence diagram.
3.3.3.1.Sequence Diagram Subsistem Aplikasi BlackBerry

Sequence Diagram Untuk Use Case Login
Gambar 3.28 menggambarkan sequence diagram untuk proses login pelanggan.
Kelas-kelas yang terpakai pada diagram ini adalah kelas OrderScreen untuk antarmuka
pelanggan, GPS untuk mendapatkan posisi, CustomerData untuk menyimpan data
pelanggan, WebServiceConnection untuk menghubungkan aplikasi BlackBerry dengan
web service, Service yang berupa web service, OracleXE untuk akses ke basis data.
Gambar 3.28. Sequence Diagram Untuk Use Case Login
Sequence Diagram Untuk Use Case Order Taxi

Gambar 3.29 menggambarkan sequence diagram untuk proses pemesanan taksi.
Kelas-kelas yang berada pada diagram ini adalah OrderScreen, WebServiceConnection,
ConfirmationScreen, Service, OracleXE.
Gambar 3.29. Sequence Diagram Untuk Use Case Order Taxi
131
132
Sequence Diagram untuk Use Case Confirm Order
Gambar 3.30 menggambarkan sequence diagram untuk proses konfirmasi
pesanan taksi. Kelas-kelas yang berada pada diagram ini adalah ConfirmationScreen,
WebServiceConnection, Service, OracleXE, SmartTaxiClient.
Gambar 3.30. Sequence Diagram Untuk Use Case Confirm Order
Sequence Diagram untuk Use Case Cancel Order

Gambar 3.31 menggambarkan sequence diagram untuk proses pembatalan
pesanan taksi. Kelas-kelas yang berada pada diagram ini adalah ConfirmationScreen,
WebServiceConnection, Service, OracleXE, SmartTaxiClient dari subsistem aplikasi
taksi untuk update antarmuka dan status taksi.
133
Gambar 3.31. Sequence Diagram Untuk Use Case Cancel Order
Sequence Diagram untuk Use Case View Map

Gambar 3.32 menggambarkan sequence diagram untuk proses penampilan
indikator taksi dan pelanggan di BlackBerry Maps. Kelas-kelas yang berada pada
diagram ini adalah ConfirmationScreen, CustomerData, dan Blackberry Maps.
Gambar 3.32. Sequence Diagram Untuk Use Case View Map
Sequence Diagram untuk Use Case Retry Order

Gambar 3.33 menggambarkan sequence diagram untuk proses pemesanan ulang. Kelas-kelas yang berhubungan dalam
diagram ini adalah ConfirmationScreen, CustomerData, WebServiceConnection, Service, OracleXE.
Gambar 3.33. Sequence Diagram Untuk Use Case Retry Order
134
135
3.3.3.2.Sequence Diagram Subsistem Aplikasi Administrator
Sequence Diagram untuk Use Case Add New Taxi
Gambar 3.34 menggambarkan sequence diagram untuk proses penambahan taksi
baru pada subsistem aplikasi administrator. Kelas-kelas yang berada pada diagram ini
adalah SmartTaxiAdministrator dan OracleXE.
Gambar 3.34. Sequence Diagram Untuk Use Case Add New Taxi
Sequence Diagram untuk Use Case Update Taxi Info

Gambar 3.35 menggambarkan sequence diagram untuk proses pengubahan data
taksi pada basis data. Kelas-kelas yang berada pada diagram ini adalah
SmartTaxiAdministrator dan OracleXE.
Gambar 3.35. Sequence Diagram Untuk Use Case Update Taxi Info
136
Sequence Diagram untuk Use Case Delete Taxi
Gambar 3.36 menggambarkan sequence diagram untuk proses penghapusan data
taksi pada basis data. Kelas-kelas yang berada pada diagram ini adalah
Gambar 3.36. Sequence Diagram Untuk Use Case Delete Taxi
Sequence Diagram untuk Use Case View Taxi List

Gambar 3.37 menggambarkan sequence diagram untuk proses pengambilan dan
penampilan daftar seluruh taksi. Kelas-kelas yang berada pada diagram ini adalah
Gambar 3.37. Sequence Diagram Untuk Use Case View Taxi List
137
Sequence Diagram untuk Use Case View Taxi Info
informasi taksi tertentu (yang terpilih dari daftar). Kelas-kelas yang berada pada diagram
ini adalah SmartTaxiAdministrator dan OracleXE.
OracleXE
Select a Taxi
Taxi Info
Select
Customer Data
Administrator
Customer List
Gambar 3.38. Sequence Diagram Untuk Use Case View Taxi Info
Sequence Diagram untuk Use Case View Customers List

Gambar 3.39 menggambarkan sequence diagram untuk proses pengambilan
daftar
pelanggan.
Kelas-kelas
yang
berada
pada
diagram
ini
Gambar 3.39. Sequence Diagram Untuk Use Case View Customers List
adalah
138
Sequence Diagram untuk Use Case View Customers Info
informasi pelanggan yang terpilih dari daftar. Kelas-kelas yang berada pada diagram ini
adalah SmartTaxiAdministrator.
Gambar 3.40. Sequence Diagram Untuk Use Case View Customers Info

indikator pelanggan dan taksi di kanvas peta. Kelas-kelas yang berada pada diagram ini
adalah SmartTaxiAdministrator dan Maps.
139
3.3.3.3.Sequence Diagram Subsistem Aplikasi Taksi
Sequence Diagram untuk Use Case Login
Gambar 3.42 menggambarkan sequence diagram untuk proses login taksi. Kelaskelas yang berada pada diagram ini adalah SmartTaxiClient, Service, dan OracleXE.
Gambar 3.42. Sequence Diagram Untuk Use Case Login
Sequence Diagram untuk Use Case Set Taxi Availability

Gambar 3.43 menggambarkan sequence diagram untuk proses pengubahan status
ketersediaan taksi. Kelas-kelas yang berada pada diagram ini adalah SmartTaxiClient,
Service, dan OracleXE.
140
SmartTaxiClient
Service
OracleXE
Click Availability Button

SetTaxiStatus()
Update
Taxi Driver
New Availability Status
Gambar 3.43. Sequence Diagram Untuk Use Case Set Taxi Availability
Sequence Diagram untuk Use Case View Customers List

Gambar 3.44 menggambarkan sequence diagram untuk proses pengambilan
daftar pelanggan terpilih untuk taksi dari basis data. Kelas-kelas yang berada pada
diagram ini adalah SmartTaxiClient, Service, dan OracleXE.
Gambar 3.44. Sequence Diagram Untuk Use Case View Customers List
Sequence Diagram untuk Use Case Choose Customer

Gambar 3.45 menggambarkan sequence diagram untuk proses pemilihan
pelanggan untuk dilayani taksi. Kelas-kelas yang berada pada diagram ini adalah
SmartTaxiClient, Service, OrderApplication dari subsistem aplikasi BlackBerry, dan
141
OracleXE.
BES
di
diagram
ini
hanya
merupakan
entitas
eksternal
untuk
menggambarkan proses push.
Gambar 3.45. Sequence Diagram Untuk Use Case Choose Customer

indikator taksi dan pelanggan di kanvas peta. Kelas-kelas yang berada pada diagram ini
adalah SmartTaxiClient, Service, dan OracleXE.
Maps
SmartTaxiClient
DrawMaps()
Map Object
Map with Taxi Indicator
DrawCustomerPosition()
Taxi Driver
Updated Map Object

Customer Indicator on Map
142
3.3.3.4.Sequence Diagram Subsistem Registrasi

Sequence Diagram untuk Use Case Register
Gambar 3.47 menggambarkan sequence diagram untuk proses registrasi
pelanggan di subsistem registrasi. Kelas-kelas yang berada pada diagram ini adalah
STRegistration_Default, dan OracleXE.
Gambar 3.47. Data Flow Diagram Untuk Use Case Register
Sequence Diagram untuk Use Case Deregister

Gambar 3.48 menggambarkan sequence diagram untuk proses deregistrasi
STRegistration_Default, STRegistration_Home, dan OracleXE.
Gambar 3.48. Data Flow Diagram Untuk Use Case Deregister
143
Sequence Diagram untuk Use Case Deregister

Gambar 3.49 menggambarkan sequence diagram untuk proses login pelanggan
di subsistem registrasi. Kelas-kelas yang berada pada diagram ini adalah
STRegistration_Default, STRegistration_Home, dan OracleXE.
STRegistration_Default
STRegistration_Home
OracleXEClient
Fill Form
LoginCustomer()
Select
Customer Data
Customer
LoadCustomerData()
Select
Customer Data
Profile Screen
Gambar 3.49. Data Flow Diagram Untuk Use Case Login
144
Sequence Diagram untuk Use Case Update Profile
Gambar 3.50 menggambarkan sequence diagram untuk proses update profil
STRegistration_Home, dan OracleXE.
Gambar 3.50. Data Flow Diagram Untuk Use Case Update Profile
Sequence Diagram untuk Use Case Update Profile

Gambar 3.51 menggambarkan sequence diagram untuk proses logout pelanggan
di subsistem registrasi. Kelas-kelas yang berada pada diagram ini adalah
STRegistration_Default, dan STRegistration_Home.
Gambar 3.51. Data Flow Diagram Untuk Use Case Logout
145
3.3.4. Perancangan Spesifikasi Proses
3.3.4.1.Algoritma Subsistem Aplikasi BlackBerry
Modul Login Pelanggan
Modul ini berfungsi sebagai proses otentikasi user ke dalam sistem dengan
mengirimkan BlackBerry PIN ke web service. Algoritma dari modul ini dapat dilihat
pada Algoritma 1 dan dipakai untuk memenuhi use case pada Tabel 3.14.
PANGGIL MODUL: GPS
Buat objek koneksi ke Web service
Masukkan BlackBerry PIN ke objek koneksi ke Web service
PANGGIL MODUL: Web service: Daftar Pelanggan pada thread terpisah
JIKA koneksi ke Web service berhasil MAKA
Urai nilai return
Masukkan nilai-nilai hasil penguraian ke CustomerData
Update layar pemesanan
AKHIR JIKA
Algoritma 1. Modul Login Pelanggan
Modul Pemesanan
Modul ini berfungsi sebagai proses utama pemesanan taksi melalui BlackBerry.
Algoritma dari modul ini dapat dilihat pada Algoritma 2 dan dipakai untuk memenuhi
use case pada Tabel 3.16.
Buat objek koneksi ke Web Service
Masukkan data pelanggan ke objek koneksi ke Web service
PANGGIL MODUL: Web Service: Daftar Pelanggan pada thread terpisah
JIKA koneksi ke Web Service berhasil MAKA
Buat objek layar konfirmasi
Pindahkan data pelanggan ke objek layar konfirmasi
PANGGIL MODUL: Pemrosesan Pesanan
Tampilkan layar konfirmasi
146
AKHIR JIKA
Algoritma 2. Modul Pemesanan
Modul GPS
Modul ini berfungsi untuk mengambil informasi lokasi dari GPS tertanam pada
perangkat BlackBerry. Algoritma dari modul ini dapat dilihat pada Algoritma 3 dan
dipakai untuk memenuhi use case pada Tabel 3.14.
Set nilai longitude dan latitude ke nilai default
Inisialisasi kriteria GPS
COBA
Ambil informasi lokasi berdasarkan criteria
PENGECUALIAN
Tampilkan pesan error
AKHIR COBA
Ambil nilai bujur dari informasi lokasi
Ambil nilai lintang dari informasi lokasi
Algoritma 3. Modul GPS
Modul Pemrosesan Pesanan

Modul ini berfungsi sebagai proses menunggu informasi pemesanan yang
dilakukan, apakah ada taksi terdekat yang bisa melayani atau tidak. Algoritma dari
modul ini dapat dilihat pada Algoritma 4 dan dipakai untuk memenuhi use case pada
Tabel 3.16.
JIKA ditemukan taksi terdekat MAKA
Ubah status teks di layar menjadi Waiting for Push Data
PANGGIL MODUL: Terima Push Data dalam thread terpisah
PANGGIL MODUL: Urai Push Data dalam thread terpisah
LAINNYA JIKA tidak ditemukan taksi terdekat MAKA
Tampilkan tombol pemesanan ulang
147
AKHIR JIKA
Algoritma 4. Modul Pemrosesan Pesanan
Modul Urai Push Data

Modul ini berfungsi untuk menguraikan push data yang dikirim dari BES dan
menampilkan informasi tersebut. Algoritma dari modul ini dapat dilihat pada Algoritma
5 dan dipakai untuk memenuhi use case pada Tabel 3.48.
Tunggu data dari modul Terima Push Data maksimum 90 detik
JIKA data telah diterima sebelum 90 detik MAKA
COBA
Urai data yang diterima menjadi nomor polisi taksi, bujur
dan lintang taksi, dan jarak antara taksi dan pelanggan
PENGECUALIAN
AKHIR COBA
Tampilkan nomor taksi yang akan menjemput
Tampilkan tombol konfirmasi pesanan
LAINNYA JIKA data belum diterima sampai 90 detik MAKA
AKHIR JIKA
Algoritma 5. Modul Urai Push Data
Modul Terima Push Data

Modul ini berfungsi untuk menangkap push data yang dikirim oleh BES.
COBA
Buka koneksi pada port 4321 untuk menerima Push Data
PENGECUALIAN
AKHIR COBA
148
Buat variabel penampung data stream
SELAMA masih ada data yang bisa dibaca dari data stream
ULANGI
Pindahkan data dari data stream ke variable penampung
AKHIR SELAMA
Ubah data yang diterima menjadi String
Kirim sinyal notifikasi ke modul Urai Push Data
Algoritma 6. Modul Terima Push Data
Modul Konfirmasi Pesanan

Modul ini berfungsi sebagai proses konfirmasi pesanan taksi. Algoritma dari
Tabel 3.18.
Masukkan data konfirmasi ke objek koneksi ke Web service
PANGGIL MODUL: Web service: Konfirmasi Pesanan pada thread terpisah
Tampilkan posisi taksi dan pelanggan di BlackBerry Maps
LAINNYA JIKA koneksi ke Web service gagal MAKA
AKHIR JIKA
Algoritma 7. Modul Konfirmasi Pesanan
Modul Batalkan Pesanan

Modul ini berfungsi untuk melakukan pembatalan pesanan taksi. Algoritma dari
Tabel 3.22.
Masukkan data pembatalan ke objek koneksi ke Web service
PANGGIL MODUL: Web service: Konfirmasi Pesanan
149
Tutup aplikasi
LAINNYA JIKA koneksi ke Web service gagal MAKA
AKHIR JIKA
Algoritma 8. Modul Batalkan Pesanan
Modul Pesan Ulang

Modul ini berfungsi untuk melakukan pemesanan ulang. Algoritma dari modul
ini dapat dilihat pada Algoritma 9 dan dipakai untuk memenuhi use case pada Tabel
3.24.
Tunggu 30 detik
Masukkan data pelanggan ke objek koneksi ke Web service
PANGGIL MODUL: Web service: Ulangi Pemesanan
PANGGIL MODUL: Pemrosesan Pesanan
AKHIR JIKA
Algoritma 9. Modul Pesan Ulang
Modul Koneksi Web service

Modul ini digunakan untuk membuka koneksi ke web service, menggunakan
fungsi yang tersedia pada web service, dan memproses hasil respons dari web service.
use case pada Tabel 3.14, Tabel 3.16, Tabel 3.18, Tabel 3.22, Tabel 3.24.
Tentukan namespace yang akan digunakan
Tentukan fungsi yang akan dipanggil
Buat objek SOAP
Buat objek Envelope
Buat objek HttpTransport
COBA
150
Panggil fungsi Web service yang telah ditentukan
Set status koneksi menjadi OK
PENGECUALIAN
Set status koneksi menjadi ERROR
AKHIR COBA
Kembalikan nilai status koneksi
Algoritma 10. Modul Koneksi Web service
3.3.4.2.Algoritma Subsistem Aplikasi Administrator

Modul Tampilkan Daftar Taksi dan Pelanggan
Modul ini berfungsi untuk mengambil data taksi dan pelanggan dari basis data
kemudian menampilkannya. Algoritma dari modul ini dapat dilihat pada Algoritma 11
dan dipakai untuk memenuhi use case pada Tabel 3.28 dan Tabel 3.36.
Cari semua record data taksi dari basis data
Tampilkan
kumpulan
record
data
taksi
ke
tampilan
tabel
aplikasi
Cari semua record data pelanggan dari basis data
Tampilkan kumpulan record data pelanggan ke tampilan tabel
aplikasi
Algoritma 11. Modul Tampilkan Daftar Taksi dan Pelanggan
Modul Tampilkan Informasi Taksi

Modul ini berfungsi untuk menampilkan informasi taksi tertentu beserta peta dan
penunjuk posisi taksi, juga daftar pelanggan yang mungkin dilayani oleh taksi tersebut.
Tampilkan data taksi yang dipilih pada field yang tersedia
PANGGIL MODUL: Tampilkan Peta Posisi Taksi
151
Cari kumpulan record data pelanggan yang dapat dilayani oleh taksi dari
basis data
UNTUK SETIAP pelanggan yang dapat dilayani oleh taksi
PANGGIL MODUL: Tampilkan Penanda Posisi Pelanggan
ULANGI
Algoritma 12. Modul Tampilkan Informasi Taksi
Modul Tampilkan Informasi Pelanggan

Modul ini berfungsi untuk menampilkan informasi pelanggan tertentu. Algoritma
dari modul ini dapat dilihat pada Algoritma 13 dan dipakai untuk memenuhi use case
pada Tabel 3.38.
Tampilkan data pelanggan yang dipilih pada field yang tersedia
Algoritma 13. Modul Tampilkan Informasi Pelanggan
Modul Tambah Taksi Baru

Modul ini berfungsi sebagai proses penambahan data taksi baru ke dalam basis
data. Algoritma dari modul ini dapat dilihat pada Algoritma 14 dan dipakai untuk
memenuhi use case pada Tabel 3.26.
Tampilkan dialog input data taksi baru
Masukkan record data taksi baru ke basis data
Algoritma 14. Modul Tambah Taksi Baru
Modul Ubah Data Taksi

Modul ini berfungsi sebagai proses pengubahan data taksi yang telah ada pada
basis data dengan data yang baru. Algoritma dari modul ini dapat dilihat pada Algoritma
Tampilkan dialog input data taksi yang akan diubah
152
Update record data taksi dengan data baru pada basis data
Algoritma 15. Modul Ubah Data Taksi
Modul Hapus Data Taksi

Modul ini berfungsi sebagai proses penghapusan data taksi yang telah ada pada
basis data. Algoritma dari modul ini dapat dilihat pada Algoritma 16 dan dipakai untuk
Tampilkan dialog konfirmasi penghapusan data taksi yang dipilih
Hapus record data taksi yang dipilih pada basis data
Algoritma 16. Modul Hapus Data Taksi
Modul Tampilkan Peta Posisi Taksi

Modul ini berfungsi untuk menampilkan (menggambar) peta dan penunjuk posisi
taksi pada kanvas peta. Algoritma dari modul ini dapat dilihat pada Algoritma 17 dan
Posisikan penanda taksi di tengah kanvas peta
Cari file bagian peta utama yang sesuai dengan posisi taksi
Tampilkan file bagian peta utama pada kanvas peta
JIKA bagian peta utama tidak memenuhi kanvas peta
Cari file bagian peta yang bersebelahan terhadap peta utama
Tampilkan file bagian peta yang bersebelahan pada kanvas peta
AKHIR JIKA
Tampilkan penanda posisi taksi pada kanvas peta
Algoritma 17. Modul Tampilkan Peta Posisi Taksi
Modul Tampilkan Penanda Posisi Pelanggan
153
Modul ini berfungsi untuk menampilkan penunjuk posisi pelanggan pada kanvas
peta. Algoritma dari modul ini dapat dilihat pada Algoritma 18 dan dipakai untuk
Posisikan penanda pelanggan terhadap posisi taksi pada kanvas peta
Tampilkan penanda posisi pelanggan pada kanvas peta
Algoritma 18. Modul Penanda Peta Posisi Pelanggan
3.3.4.3.Algoritma Subsistem Aplikasi Taksi

Modul Dapatkan Posisi GPS
Modul ini berfungsi untuk mengambil informasi posisi dari perangkat penerima
GPS. Algoritma dari modul ini dapat dilihat pada Algoritma 19 dan dipakai untuk
Kirim paket permintaan ke GPS
Dapatkan respons paket posisi dari GPS
Kembalikan posisi bujur dan lintang
Algoritma 19. Modul Dapatkan Posisi GPS
Modul Login
Modul ini berfungsi sebagai proses otentifikasi taksi saat pertama kali aplikasi
dibuka. Algoritma dari modul ini dapat dilihat pada Algoritma 20 dan dipakai untuk
Tampilkan dialog input nomor kendaraan taksi
PANGGIL MODUL: Web service: Ambil ID Taksi
PANGGIL MODUL: Web service: Ubah Status Taksi
Algoritma 20. Modul Login
154
Modul Pilih Pelanggan
Modul ini berfungsi untuk melakukan pemilihan pelanggan yang ada dan
menampilkan penunjuk posisinya pada kanvas peta. Algoritma dari modul ini dapat
dilihat pada Algoritma 21 dan dipakai untuk memenuhi use case pada Tabel 3.48.
PANGGIL MODUL: Web service: Pilih Pelanggan
PANGGIL MODUL: Web service: Ubah Status Taksi
PANGGIL MODUL: Tampilkan Penanda Posisi Pelanggan
Algoritma 21. Modul Pilih Pelanggan
Modul Ubah Posisi Taksi di Peta

Modul ini berfungsi untuk mengambil informasi posisi dari GPS dan
menampilkan posisi taksi pada kanvas peta menggunakan informasi tersebut. Algoritma
pada Tabel 3.50.
PANGGIL MODUL: Dapatkan Posisi GPS
PANGGIL MODUL: Web service: Ubah Posisi Taksi
Algoritma 22. Modul Ubah Posisi Taksi di peta
Modul Tampilkan Peta Posisi Taksi

Modul ini berfungsi untuk menampilkan (menggambar) peta dan penunjuk posisi
taksi pada kanvas peta. Algoritma dari modul ini dapat dilihat pada Algoritma 23 dan
Posisikan penanda taksi di tengah kanvas peta
Cari file bagian peta utama yang sesuai dengan posisi taksi
Tampilkan file bagian peta utama pada kanvas peta
JIKA bagian peta utama tidak memenuhi kanvas peta
155
Cari file bagian peta yang bersebelahan terhadap peta utama
Tampilkan file bagian peta yang bersebelahan pada kanvas peta
AKHIR JIKA
Tampilkan penanda posisi taksi pada kanvas peta
Algoritma 23. Modul Tampilkan Peta Posisi Taksi
Modul Tampilkan Penanda Posisi Pelanggan

Modul ini berfungsi untuk menampilkan penunjuk posisi pelanggan pada kanvas
peta. Algoritma dari modul ini dapat dilihat pada Algoritma 24 dan dipakai untuk
Posisikan penanda pelanggan terhadap posisi taksi pada kanvas peta
Tampilkan penanda posisi pelanggan pada kanvas peta
Algoritma 24. Modul Tampilkan Penanda Posisi Pelanggan
3.3.4.4.Algoritma Subsistem Aplikasi Server

Modul Hitung Jarak
Modul ini berfungsi untuk melakukan perhitungan jarak antara dua posisi
menggunakan metode haversine. Algoritma dari modul ini dapat dilihat pada Algoritma
LAKUKAN
Jangkauan pencarian = Jangkauan sebelumnya + Penambahan jangkauan
Cari taksi dalam jangkauan terhadap posisi pelanggan dari basis
data
SELAMA Jangkauan <= Jangkauan maksimal DAN Jumlah taksi dalam jangkauan
< Jumlah maksimum taksi yang dicari
JIKA Jumlah taksi dalam jangkauan >= 1 MAKA
UNTUK SETIAP taksi dalam jangkauan
Hitung jarak posisi taksi terhadap posisi pelanggan dengan
Haversine
ULANGI
156
Urutkan hasil perhitungan jarak dari terkecil ke terbesar
UNTUK maksimum taksi yang dicari
Masukkan record perhitungan taksi terdekat ke basis data
ULANGI
AKHIR JIKA
Algoritma 25. Modul Hitung Jarak
Modul Ambil ID Taksi

Modul ini berfungsi untuk mengambil ID taksi dari basis data. Algoritma dari
Tabel 3.42.
Cari record dengan ID Taksi tertentu dari basis data
Kembalikan ID Taksi
Algoritma 26. Modul Ambil ID Taksi
Modul Ubah Posisi Taksi

Modul ini berfungsi untuk mengubah posisi taksi pada basis data dengan
informasi posisi yang baru. Algoritma dari modul ini dapat dilihat pada Algoritma 27
dan dipakai untuk memenuhi use case pada Tabel 3.46.
Update record posisi taksi pada basis data
Algoritma 27. Modul Ubah Posisi Taksi
157
Modul Ambil Daftar Pelanggan
Modul ini berfungsi untuk mengambil data pelanggan yang mungkin dilayani
oleh taksi tertentu dari basis data. Algoritma dari modul ini dapat dilihat pada Algoritma
PANGGIL MODUL: Ubah Posisi Taksi
Cari kumpulan record pelanggan untuk taksi tertentu dari basis data
Kembalikan kumpulan record pelanggan untuk taksi tertentu
Algoritma 28. Modul Ambil Daftar Pelanggan
Modul Pilih Pelanggan

Modul
ini
berfungsi
untuk
melakukan
pemilihan
pelanggan
dan
mengkonfirmasikan hasil pemilihan ke perangkat BlackBerry lewat teknologi Push.

Update record status pemilihan pelanggan di tabel pengumuman pada basis
data
JIKA Update basis data berhasil MAKA
Masukkan record transaksi pemesanan ke basis data
PUSH permintaan konfirmasi pemesanan ke pelanggan
AKHIR JIKA
Algoritma 29. Modul Pilih Pelanggan
Modul Cek Konfirmasi Pemesanan

Modul ini berfungsi untuk melakukan pengecekan konfirmasi pemesanan dari
basis data. Algoritma dari modul ini dapat dilihat pada Algoritma 30 dan dipakai untuk
memenuhi use case pada Tabel 3.18 dan Tabel 3.22.
Cari record status konfirmasi pemesanan oleh pelanggan dari basis data
158
Kembalikan status konfirmasi pemesanan oleh pelanggan
Algoritma 30. Modul Cek Konfirmasi Pesanan
Modul Ubah Status Taksi

Modul ini berfungsi untuk melakukan pengubahan status taksi pada basis data.
use case pada Tabel 3.44, Tabel 3.18 dan Tabel 3.22.
Update record status taksi pada basis data
Algoritma 31. Modul Ubah Status Taksi
Modul Pesan Taksi

Modul ini berfungsi sebagai proses pendaftaran pelanggan baru ke dalam basis
data dan memanggil fungsi perhitungan jarak taksi terdekat terhadap posisi pelanggan
baru. Algoritma dari modul ini dapat dilihat pada Algoritma 32 dan dipakai untuk
Masukkan record data pelanggan baru ke basis data
PANGGIL MODUL Hitung jarak
JIKA Jumlah taksi terdekat terhadap posisi pelanggan = 0 MAKA
Notifikasi ke pelanggan untuk konfirmasi menunggu beberapa saat
AKHIR JIKA
Algoritma 32. Modul Daftarkan Pelanggan Baru
Modul Ulangi Pemesanan

Modul ini berfungsi sebagai proses pemesanan ulang oleh pelanggan dan
memanggil fungsi perhitungan jarak taksi terdekat terhadap posisi pelanggan. Algoritma
159
pada Tabel 3.24.
Update record data pelanggan yang sudah memesan sebelumnya pada basis
data
PANGGIL MODUL Hitung jarak
JIKA Jumlah taksi terdekat terhadap posisi pelanggan = 0 MAKA
Notifikasi ke pelanggan untuk konfirmasi menunggu beberapa saat
AKHIR JIKA
Algoritma 33. Modul Ulangi Pemesanan
Modul Konfirmasi Pemesanan

Modul ini berfungsi sebagai proses konfirmasi pemesanan oleh pelanggan.
Update record konfirmasi pemesanan
Kembalikan hasil konfirmasi pemesanan ke pelanggan
Algoritma 34. Modul Konfirmasi Pemesanan
3.3.4.5.Algoritma Subsistem Registrasi

Modul Registrasi Pelanggan
Modul ini berfungsi sebagai proses pendaftaran pelanggan baru ke dalam basis
data. Algoritma dari modul ini dapat dilihat pada Algoritma 35 dan dipakai untuk
JIKA validasi halaman sukses MAKA
Buat koneksi ke basis data
JIKA Proses INSERT Data Pelanggan Baru ke basis data sukses MAKA
Baca ID Pelanggan dari Basis Data
Tampilkan pesan sukses Registrasi dan ID Pelanggan
AKHIR JIKA
160
Tutup Koneksi basis data
AKHIR JIKA
Algoritma 35. Modul Registrasi Pelanggan
Modul Login Pelanggan

Modul ini berfungsi sebagai proses masuk / login pelanggan yang telah terdaftar
ke halaman profil. Algoritma dari modul ini dapat dilihat pada Algoritma 36 dan dipakai
untuk memenuhi use case pada Tabel 3.56.
Buat Koneksi ke Basis data
Cari Record Pelanggan berdasarkan ID Pelanggan dan BB PIN dari
basis data
JIKA Record ditemukan MAKA
Buat Session pelanggan
Redirect pelanggan ke halaman profil
LAINNYA
Tampilkan pesan kesalahan Login
AKHIR JIKA
AKHIR JIKA
Algoritma 36. Modul Login Pelanggan
Modul Tampil Data Pelanggan

Modul ini berfungsi untuk menampilkan data profil pelanggan yang berhasil
Login berdasarkan ID pelanggan. Algoritma dari modul ini dapat dilihat pada Algoritma
JIKA Session pelanggan ditemukan MAKA
JIKA Halaman ditampilkan pertama kalinya MAKA
Buat Koneksi basis data
Baca data pelanggan sesuai ID Pelanggan di Session dari
basis data
161
Tampilkan data pelanggan
AKHIR JIKA
LAINNYA
Redirect pelanggan ke halaman utama (login)
AKHIR JIKA
Algoritma 37. Modul Tampil Data Pelanggan
Modul Ubah Data Pelanggan

Modul ini berfungsi untuk mengubah data profil pelanggan di dalam basis data.
UPDATE Data Pelanggan sesuai ID Pelanggan di Session ke basis
data
Tampilkan pesan berhasil mengubah data profil pelanggan
AKHIR JIKA
Algoritma 38. Modul Ubah Data Pelanggan
Modul Hapus Data Pelanggan

Modul ini berfungsi untuk menghapus data profil pelanggan yang sudah terdaftar
(menghapus keanggotaan pelanggan). Algoritma dari modul ini dapat dilihat pada
Algoritma 39 dan dipakai untuk memenuhi use case pada Tabel 3.54.
JIKA Session pelanggan ditemukan MAKA
DELETE Data Pelanggan sesuai ID Pelanggan di Session dari basis
data
Hapus Session pelanggan
162
AKHIR JIKA
Algoritma 39. Modul Hapus Data Pelanggan
Modul Logout Pelanggan

Modul ini berfungsi sebagai proses keluar / logout pelanggan dari halaman
profil. Algoritma dari modul ini dapat dilihat pada Algoritma 40 dan dipakai untuk
Hapus Session pelanggan
Algoritma 40. Modul Logout Pelanggan

Rancangan Sistem

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rancangan Sistem

Diunggah oleh

Hak Cipta:

Format Tersedia

BAB 3

ANALISIS DAN PERANCANGAN SISTEM

3.1.1. Identifikasi Proses Bisnis Berjalan

Tabel 3.1. Daftar Proses Bisnis Berjalan

perusahaan taksi dan

broadcast data pesanan ke

2) Sopir taksi merespon

Tabel 3.2. Daftar Proses Bisnis Beserta Aktor

Sopir Dokumen pesanan taksi

Gambar 3.1. Document Flow Diagram Sistem Konvensional

Gambar 3.2. Use Case Diagram Sistem Konvensional

Customer (Pelanggan), Operator

Use case menggambarkan bagaimana pelanggan memesan

Pesanan belum dilakukan

Data pelanggan tercatat

Pelanggan menekan nomor Sistem

informasi pelanggan dan

pelanggan yang memesan

penyedia operator melalui jaringan

Broadcast Order Request

Customer (Pelanggan), Operator

Use case menggambarkan bagaimana penyedia jasa taksi

Pesanan telah dilakukan

Pelanggan mendapatkan satu taksi yang akan menjemput

Tabel 3.6. Aliran Use Case Broadcast Order Request

mengaktifkan Sistem mengirimkan sinyal

melakukan broadcast data radio ke perangkat radio di

jangkauan gelombang radio.

Sopir taksi menerima data Sistem mengirimkan sinyal

perangkat radio dari perangkat radio di

pesanan yang disebar oleh radio operator.

Berdasarkan observasi, permasalahan pertama yang teridentifikasi adalah posisi

Verifikasi Studi Literatur

Posisi pelanggan dan dan lintang pada permukaan bumi

Dibutuhkan dua titik dengan bujur

terdekat untuk mendapatkan jarak lingkaran

Pelanggan harus dapat menghubungi

orang yang dapat melaksanakan

Operator yang sibuk keinginannya

ada mudah. Masalah pelanggan, yang

pelanggan yang harus sudah menelepon atau menulis surat

dilayani dan tahu bahwa ia sedang melakukan

bahkan tidak sempat kontak, harus diambil alih secara

cepat dan efisien. Dengan kata lain,

masalah, karena masalah itu sudah

Kesalahan manusia (human error)

Faktor manusia yang adalah

operator menyebarkan membuat hasil yang diinginkan,

Verifikasi Studi Literatur

informasi yang salah namun

dan kenyataannya tidak membuat hasil

memasukkan informasi yang diinginkan itu (Marguglio,

3.1.2. Analisis Wawancara dan Kuesioner

Gambar 3.3. Respons Pelanggan Terhadap Survey Pertanyaan 1

Dari pertanyaan kedua, 58% responden menyatakan bahwa mereka menunggu

Gambar 3.4. Respons Pelanggan Terhadap Survey Pertanyaan 2

Gambar 3.5. Respons Pelanggan Terhadap Survey Pertanyaan 3

Dari pertanyaan keempat, 58% responden menyatakan bahwa mereka pernah

Gambar 3.6. Respons Pelanggan Terhadap Survey Pertanyaan 4

Dari pertanyaan kelima, 90% responden menyatakan informasi tentang taksi

Gambar 3.7. Respons Pelanggan Terhadap Survey Pertanyaan 5

Dari pertanyaan keenam, diketahui bahwa 22% pemesan taksi mempunyai

Gambar 3.8. Respons Pelanggan Terhadap Survey Pertanyaan 6

Dari wawancara terhadap sopir taksi, ditemukan bahwa memang ada