Rancangan Sistem

33

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. Nama Proses Input Proses Output

1 Proses

pemesanan taksi

Data

pelanggan.

1) Pelanggan menelepon

perusahaan taksi dan

memberikan data

pelanggan.

2) Operator menyimpan

data pelanggan di berkas

dokumen pesanan.

Dokumen

pemesan taksi

2 Proses

broadcast

pesanan

Dokumen

pemesan

taksi, data

1) Operator melakukan

broadcast data pesanan ke

seluruh taksi.

Dokumen

pesanan taksi

34

No. Nama Proses Input Proses Output

taksi. 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. Nama Proses Aktor Dokumen

1. Proses

pemesanan taksi

Operator,

Pelanggan

Dokumen pemesan taksi

2. Proses

broadcast

pesanan taksi

Operator, Sopir

Taksi

Dokumen 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 Actor Action System Response

Normal Step 1.

Pelanggan menekan nomor

telepon operator untuk

menghubungi penyedia

jasa taksi.

Step 3.

Operator menanyakan

informasi pelanggan dan

lokasinya.

Step 4.

Pelanggan memberikan

informasi dirinya dan

lokasinya.

Step 5.

Operator mencatat data

pelanggan yang memesan

taksi pada sistem / berkas

penyimpanan data.

Step 2.

Sistem menyambungkan

pelanggan taksi dengan

operator melalui jaringan

telepon.

Alternate - -

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


Normal Step 1.

Operator mengaktifkan

perangkat radio untuk

melakukan broadcast data

pelanggan yang memesan

jasa taksi.

Step 3.

Sopir taksi menerima data

pelanggan dan

mengaktifkan perangkat

radio untuk mengambil

pesanan yang disebar oleh

operator taksi.

Step 2.

Sistem mengirimkan sinyal

data melalui gelombang

radio ke perangkat radio di

armada taksi dalam

jangkauan gelombang radio.

Step 4.

Sistem mengirimkan sinyal

data melalui gelombang

radio dari perangkat radio di

armada taksi ke perangkat

radio operator.

39


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. Nama Proses Masalah Verifikasi Studi Literatur

1. Proses

pemesanan taksi

Masalah 1.

Posisi pelanggan dan

taksi-taksi terdekat

dengan pelanggan

tidak diketahui.

Masalah 2.

Operator yang sibuk

sehingga ada

pelanggan yang harus

menunggu dilayani

bahkan tidak sempat

terlayani.

Dibutuhkan dua titik dengan bujur

dan lintang pada permukaan bumi

untuk mendapatkan jarak lingkaran

besar (Veness, 2009).

Pelanggan harus dapat menghubungi

orang yang dapat melaksanakan

keinginannya dengan cepat dan

mudah. Masalah pelanggan, yang

sudah menelepon atau menulis surat

dan tahu bahwa ia sedang melakukan

kontak, harus diambil alih secara

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

broadcast

pesanan taksi

Masalah 3.

Faktor manusia yang

memungkinkan

operator menyebarkan

Kesalahan manusia (human error)

adalah perilaku yang secara

keseluruhan diharapkan untuk

membuat hasil yang diinginkan,

41

No. Nama Proses Masalah Verifikasi Studi Literatur

informasi yang salah

ke taksi dan

memasukkan informasi

yang salah ke sistem /

berkas penyimpanan

data.

namun perilaku itu pada

kenyataannya tidak membuat hasil

yang diinginkan itu (Marguglio,

2009)

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 Permasalahan Aktor Evaluasi Dari

1 Operator sibuk pada

saat pelanggan

Pelanggan Kuesioner pertanyaan 1,

wawancara terhadap operator.

46

No Permasalahan Aktor Evaluasi Dari

menelepon

2 Pelanggan merasa taksi

membutuhkan waktu

lama untuk sampai ke

pelanggan

Pelanggan Kuesioner pertanyaan 2 dan 3

3 Kesalahan pemberian

informasi pelanggan

kepada taksi yang dapat

menyebabkan taksi

tidak sampai pada

pelanggan

Pelanggan Kuesioner pertanyaan 4,

wawancara terhadap sopir taksi.

4 Pelanggan

membutuhkan

informasi tentang taksi

yang akan

menjemputnya

Pelanggan Kuesioner pertanyaan 5.

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.

48

Tabel 3.9. Rangkuman Masalah Teridentifikasi Pada Proses Bisnis Berjalan

No Permasalahan Teridentifikasi Sumber Identifikasi Landasan Teori

1 Posisi pelanggan dan taksi-

taksi di sekitarnya tidak

diketahui sehingga sistem tidak

bisa mencarikan taksi-taksi

terdekat

Pengamatan lapangan Masalah milik pelanggan yang sudah menelepon atau menulis

surat dan tahu bahwa ia sedang melakukan kontak harus diambil

alih secara cepat dan efisien (Armistead, et al., 1996)

Dibutuhkan dua titik dengan bujur dan lintang pada permukaan

bumi untuk mendapatkan jarak lingkaran besar (Veness, 2009)


informasi pelanggan kepada

taksi yang dapat menyebabkan

taksi tidak sampai pada

pelanggan

Pengamatan lapangan,

wawancara dengan sopir

taksi, dan kuesioner

Kesalahan manusia (human error) adalah perilaku yang secara

keseluruhan diharapkan untuk membuat hasil yang diinginkan,

namun perilaku itu pada kenyataannya tidak membuat hasil yang

diinginkan itu. (Marguglio, 2009)

3 Operator yang sibuk sehingga

ada pelanggan yang harus

menunggu dilayani bahkan

Pengamatan lapangan dan

kuesioner

Pelanggan harus dapat menghubungi orang yang dapat

melaksanakan keinginannya dengan cepat dan mudah.

(Armistead, et al., 1996).

49

No Permasalahan Teridentifikasi Sumber Identifikasi Landasan Teori

tidak sempat terlayani.

4 Pelanggan membutuhkan

informasi tentang taksi yang

menjemput

Kuesioner Pelanggan harus segera tahu bahwa mereka tidak lagi

menghadapi masalah, karena masalah itu sudah ditanggulangi

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 Permasalahan Teridentifikasi Solusi Landasan Teori

1 Posisi pelanggan dan taksi-

taksi di sekitarnya tidak

GPS pada taksi dan

perangkat BlackBerry.

GPS merupakan suatu kumpulan satelit dan sistem kontrol yang

memungkinkan sebuah penerima GPS untuk mendapatkan

50


diketahui sehingga sistem tidak

bisa mencarikan taksi-taksi

terdekat

Pengembangan LBS

untuk mencari taksi-taksi

terdekat berdasarkan

posisi pelanggan yang

dikirim dengan

menggunakan rumus

haversine.

lokasinya di permukaan bumi 24 jam sehari (Heywood, et al.,

2002).

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

layanan informasi yang mengutilisasi kemampuan untuk

menggunakan informasi lokasi dari perangkat bergerak dan dapat

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 bola (Bumi) berdasarkan bujur dan lintang.

Penggunaan rumus ini mengasumsikan pengabaian efek

ellipsoidal, cukup akurat untuk sebagian besar perhitungan, juga

pengabaian ketinggian bukit dan kedalaman lembah di

permukaan bumi (Veness, 2009).

51



informasi pelanggan kepada

taksi menyebabkan taksi tidak

sampai pada pelanggan.

Pengembangan aplikasi

pemesanan taksi di


Pengembangan aplikasi

registrasi yang mampu

menyimpan data

pelanggan (termasuk foto

pelanggan)

BlackBerry merupakan perangkat bergerak pintar yang

menggabungkan sejumlah fungsi termasuk surat elektronik,

penjelajahan web, pesan teks, pengelolaan jadwal, dan telepon

seluler ke dalam suatu perangkat portabel

(BusinessDictionary.com).

Basis data adalah satuan, tempat penyimpanan data yang besar

yang bisa digunakan bersama oleh satu maupun banyak

pengguna. Selain data yang ada tidak akan berulang, semua data

akan diintegrasi dengan jumlah duplikasi yang minimum

(Connolly, et al., 2002).

4 Operator yang sibuk sehingga

ada pelanggan yang harus

menunggu dilayani bahkan

tidak sempat terlayani.

Pengembangan web

service untuk melayani

pelanggan

Web service adalah sebuah komponen aplikasi yang bisa

diprogram dan diakses lewat protokol web standar (Peiris, et al.,

2007).

52


5 Pelanggan membutuhkan

informasi tentang taksi yang

menjemput.

Implementasi teknologi

basis data dan push pada

sistem yang akan

dibangun. Informasi

tentang taksi yang akan

menjemput akan disimpan

dalam basis data dan

dikirimkan lewat layanan

push. Basis data

digunakan untuk

menyimpan data

pelanggan, taksi, dan

pesanan untuk digunakan

sistem.

Salah satu kelebihan teknologi push BlackBerry adalah

kemampuannya untuk mengirimkan informasi dengan instan.

Teknologi push BlackBerry adalah metode komunikasi di internet

yang berbeda dengan teknologi pull yang biasa digunakan, di

mana pada teknologi ini, yang melakukan permintaan komunikasi

adalah server, bukan klien. Pada konteks pengembangan aplikasi

BlackBerry, teknologi ini merujuk pada kemampuan infrastruktur

BlackBerry untuk mengirim data berdasarkan pada sebuah

pemicu ke perangkat BlackBerry (Research in Motion, 2006).

Basis data adalah satuan, tempat penyimpanan data yang besar

yang bisa digunakan bersama oleh satu maupun banyak

pengguna. Selain data yang ada tidak akan berulang, semua data

akan diintegrasi dengan jumlah duplikasi yang minimum

(Connolly, et al., 2002).

53

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 Tujuan Solusi Ditujukan

Untuk

Informasi Yang Akan

Diberikan Kepada Aktor

Keuntungan Bagi Pengguna

1. Menemukan taksi-

taksi terdekat

dengan posisi

pelanggan

Pelanggan Koordinat posisi taksi

dan posisi pelanggan

1. Pelanggan mengetahui taksi mana yang akan menjemput

sehingga tidak salah naik taksi

2. Pelanggan mengetahui posisi terakhir dari taksi yang akan

menjemput mereka

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

pelanggan, dan alamat

1. Taksi sampai ke lokasi pelanggan yang tepat dan tidak

menjemput pelanggan yang salah.

54

No Tujuan Solusi Ditujukan

Untuk

Informasi Yang Akan

Diberikan Kepada Aktor

Keuntungan Bagi Pengguna

pelanggan yang

tepat kepada sopir

taksi

pelanggan.

3. Memberikan

pelanggan

informasi yang

tepat tentang taksi

yang menjemput

Pelanggan Nomor kendaraan taksi,

posisi taksi

1. Pelanggan mendapatkan informasi yang tepat tentang taksi

mana yang akan menjemputnya, sehingga pelanggan tidak naik

pada taksi yang salah.

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..

55

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

pelanggan dan taksi-

taksi terdekat dengan

posisi pelanggan.

Proses 1: Proses pemesanan taksi

Input: ID pelanggan, lokasi pelanggan, koordinat

posisi pelanggan, ID taksi, lokasi taksi

Proses:

- Kalkulasi jarak terdekat antara taksi dan

pelanggan dengan rumus haversine

- Penyimpanan hasil kalkulasi dalam basis data

Output: Data pesanan tersimpan dalam basis data

Proses 1: Proses pemesanan taksi

Menu: Menu pemesanan pada layar pemesanan

2. Menyampaikan

informasi pelanggan

yang tepat kepada

sopir taksi

Proses 1: Proses registrasi pelanggan

Input: Nama, lokasi, nomor telepon pelanggan,

foto diri pelanggan, dan BlackBerry PIN

Proses:

Proses 1: Proses registrasi pelanggan

Menu: Menu registrasi pelanggan baru, menu

update profil pelanggan, menu login, dan menu

deregistrasi pelanggan

56



- Proses upload foto diri pelanggan dan

penyimpanan data pelanggan pada basis data

Output: Pelanggan mendapatkan ID pelanggan dan

data pelanggan tersimpan pada basis data

Proses 2: Proses login pelanggan

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.

Proses 2: Proses login pelanggan

Menu: - (dilakukan secara otomatis oleh aplikasi)

Proses 3: Proses pengambilan daftar pelanggan

Menu: - (dilakukan secara otomatis oleh aplikasi)

57



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

58



aplikasi taksi.

Output: Daftar pelanggan terdekat tampil di layar.

3. Memberikan

pelanggan informasi

tentang taksi yang

menjemput

Proses 1: Proses pemilihan pelanggan yang akan

dijemput

Input: Daftar pelanggan terdekat dengan taksi, data

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.

Proses 1: Proses pemilihan pelanggan yang akan

dijemput.

Menu: Menu pemilihan pelanggan yang akan dijemput.

59



Output: Pelanggan menerima data tentang taksi

yang akan menjemput. Detail pelanggan, termasuk

foto pelanggan, tampil di layar aplikasi taksi.

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

Aplikasi Administator

Buat, lihat, dan hapus data taksi.Lihat data pelanggan

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).

Database

PelangganServis Web

Pesan taksi

Push

dat

a ta

ksi

Kirim permintaan Push

Mendapatkan lokasi dengan GPS

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

BlackBerryApplication Subsystem

Order Taxi

Retry Order

Cancel Order

Confirm Order

Customer

View Map

Login

extends

Gambar 3.15. Use Case Diagram Subsistem Aplikasi BlackBerry

Tabel 3.13. Deskripsi Use Case Login

Name Login

Actors Customer (Pelanggan)


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


Normal Step 1.

Pelanggan membuka

aplikasi pemesanan taksi di


Step 2.

Aplikasi menghubungkan

diri dengan web service,

mengirimkan BlackBerry

PIN sebagai otentikasi

pelanggan.

Step 3.

Aplikasi menerima nama,

alamat, dan posisi

pelanggan dari web service.

Step 4.

Aplikasi mengambil

informasi 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


untuk mendaftar terlebih

dulu.

Tabel 3.15. Deskripsi Use Case Order Taxi

Name Order Taxi



taksi

Precondition Pelanggan sudah melakukan use case Login

Postcondition Data pesanan pelanggan tertulis di basis data.

Tabel 3.16. Aliran Use Case Order Taxi


Normal Step 1.

Pelanggan mengganti

alamat bila diperlukan dan

menekan tombol

ORDER.

Step 3.



mengirimkan data

pelanggan ke web service.

Step 4.

Web service mencari taksi-

taksi terdekat dengan rumus

haversine.

75


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


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 taksi menjadi

SERVICING

Tabel 3.18. Aliran Use Case Confirm Order

76


Normal Step 1.

Pelanggan menekan

tombol OK di layar

konfirmasi.

Step 2.

Aplikasi

menghubungkan diri

dengan web service, lalu

mengirimkan data

konfirmasi.

Step 3.

Web service memperbarui

isi basis data.

Step 4.

Aplikasi taksi mengecek

konfirmasi pesanan dan

mengubah status

ketersediaan taksi menjadi

SERVICING.

Alternate - -

Tabel 3.19. Deskripsi Use Case View Map

Name View Map


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


Normal - Step 1.

Aplikasi menginisiasi

BlackBerry Maps dengan

mengirimkan data posisi

taksi dan posisi pelanggan.

Step 2

Aplikasi memanggil

BlackBerry Maps untuk

menampilkan peta.

Alternate - -

Tabel 3.21. Deskripsi Use Case Cancel Order

Name Cancel Order


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


Normal Step 1.

Pelanggan menekan

tombol Cancel di layar

konfirmasi.

Step 2.

Aplikasi

menghubungkan diri

dengan web service, lalu

mengirimkan data

konfirmasi. Web service lalu

memperbarui isi basis data.

Step 3.

Aplikasi taksi mengecek

konfirmasi pesanan dan

mengubah status

ketersediaan taksi menjadi

AVAILABLE.

Step 4.

Aplikasi menutup dirinya

79


sendiri.

Alternate - -

Tabel 3.23. Deskripsi Use Case Retry Order

Name Retry Order


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


Normal Step 1.

Pelanggan menekan

tombol RETRY di layar

konfirmasi.

Step 2.



mengirimkan data

80


pelanggan ke web service.

Web service mencari taksi-

taksi terdekat dengan rumus

haversine.

Step 3.

Aplikasi menunggu push

data dari server .


Pengguna menekan tombol

QUIT untuk menutup

aplikasi (tidak memesan

ulang).

ALT Step 3.

Jika aplikasi kembali tidak

menerima push data dalam

90 detik, maka aplikasi akan

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 administrator

menambahkan data taksi baru ke basis data.

Precondition Aplikasi terhubung dengan basis data.

Postcondition Data taksi baru telah dimasukkan ke basis data.

83

Tabel 3.26. Aliran Use Case Add New Taxi


Normal Step 1.

Administrator menekan

tombol ADD NEW di

antarmuka aplikasi.

Step 3.

Administrator mengisi data

taksi baru dan menekan

tombol OK

Step 2.

Aplikasi menampilkan dialog

untuk memasukkan data taksi

baru.

Step 4.

Aplikasi memasukkan data

taksi baru ke basis data.


Administrator dapat menekan

CANCEL untuk

membatalkan penambahan

data taksi baru.

Tabel 3.27. Deskripsi Use Case View Taxi List

Name View Taxi List


Description Use case menggambarkan bagaimana aplikasi menampilkan

data taksi dari basis data.


Postcondition Daftar seluruh taksi tampil di layar.

84

Tabel 3.28. Aliran Use Case View Taxi List


Normal - 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


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


Normal Step 1.

Administrator memilih salah

satu taksi dari daftar taksi dan

menekan tombol UPDATE.

Step 3.

Administrator mengisi data

baru untuk taksi terpilih dan

menekan OK

Step 2.

Aplikasi menampilkan dialog

untuk mengubah data taksi.

Step 4.

Aplikasi mengubah data taksi

terpilih di basis data dan

menampilkan data yang baru.


Administrator dapat menekan

CANCEL untuk

membatalkan pengubahan.

Tabel 3.31. Deskripsi Use Case Delete Taxi

Name Delete Taxi


Description Use case menggambarkan bagaimana administrator

menghapus data taksi tertentu.


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


Normal Step 1.


satu taksi dari daftar taksi dan

menekan tombol DELETE.

Step 2.

Aplikasi menghapus data

taksi terpilih di basis data.

Alternate - -

Tabel 3.33. Deskripsi Use Case View Taxi Info

Name View Taxi Info


Description Use case menggambarkan bagaimana administrator melihat

informasi taksi tertentu.


Aplikasi menyimpan dan menampilkan daftar taksi yang ada.

Ada data pesanan di basis data.

Postcondition Data taksi terpilih ditampilkan.

Daftar pelanggan yang dapat dilayani taksi terpilih

ditampilkan.

87

Tabel 3.34. Aliran Use Case View Taxi Info


Normal Step 1.


satu taksi dari daftar taksi.

Step 2.

Aplikasi menampilkan data

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


Description Use case menggambarkan bagaimana aplikasi melihat daftar

pelanggan.


Postcondition Daftar pelanggan ditampilkan.

88

Tabel 3.36. Aliran Use Case View Customers List


Normal Step 1.

Administrator menekan

tombol SHOW ALL

CUSTOMERS.

Step 2.

Aplikasi mengambil daftar

pelanggan dari basis data dan

menampilkannya.

Alternate - -

Tabel 3.37. Deskripsi Use Case View Customer Info

Name View Customer Info


Description Use case menggambarkan bagaimana administrator melihat

informasi pelanggan tertentu.


Postcondition Data pelanggan terpilih ditampilkan

Tabel 3.38. Aliran Use Case View Customer Info


Normal Step 1.


satu pelanggan dari daftar

pelanggan yang ada

Step 2.

Aplikasi menampilkan data

pelanggan terpilih

89


Alternate - -


Name View Map



posisi taksi dan pelanggan (bila ada) di peta di layar.

Precondition -

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

di layar.



Normal - 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


taksi terpilih dan

menampilkannya. Aplikasi

juga akan 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

Choose Customer

View Customers List

Taxi Driver

Set TaxiAvailability

View Map

Login

extends

extends

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.



Normal Step 1.

Sopir taksi membuka aplikasi

dan memasukkan nomor

polisi taksi.

Step 1.

Aplikasi menghubungkan diri

dengan web service untuk

mengecek nomor polisi taksi.

Step 2.

Aplikasi memanggil web

service untuk 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


Alternate - -

Tabel 3.43. Deskripsi Use Case Set Taxi Availability

Name Set Taxi Availability


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


Normal Step 1.

Sopir taksi menekan tombol

AVAILABLE atau

UNAVAILABLE.

Step 2.


dengan web service untuk

mengubah status ketersediaan

taksi dalam basis data, sesuai

dengan tombol yang ditekan

sopir taksi.

Step 3.

94


Aplikasi mengubah status

tombol pengubah status

ketersediaan. Jika yang

ditekan AVAILABLE,

maka tombol AVAILABLE

tidak bisa ditekan dan tombol

UNAVAILABLE bisa

ditekan. Begitu pula

sebaliknya.

Alternate - -

Tabel 3.45. Deskripsi Use Case View Customer List

Name View Customer List



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


Normal - Step 1.


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 akan

mengembalikan 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


mengembalikan apa-apa.

Alt Step 3.

Jika tidak ada pelanggan

tersedia, aplikasi tidak

menampilkan daftar

pelanggan.

Tabel 3.47. Deskripsi Use Case Choose Customer

Name Choose Customer


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


Normal Step 1.

Sopir memilih salah satu

pelanggan dengan menekan

Step 2.


dengan web service dan

97


tombol yang tersedia. mengirim ID pesanan,

pelanggan dan taksi.

Step 3.

Web service lalu akan

mengubah record pesanan

yang ditentukan, lalu

mengirimkan request ke BES

untuk push data ke aplikasi

Blackberry.

Step 4.

Aplikasi BlackBerry

menerima push data,

mengurai push 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


pelanggan dan detail

pelanggan lainnya dari web

service dan menampilkannya

di layar.

Alternate - -


Name View Map



posisi taksi dan pelanggan (bila ada) di peta di layar.

Precondition -

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

di layar.



Normal - Step 1.

Aplikasi mengambil data

posisi bujur dan lintang dari

99


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


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


102


Normal Step 1.

Pelanggan membuka website

pendaftaran, mengisi field

pendaftaran yang tersedia

pada form, memilih foto

untuk diupload, dan menekan

tombol REGISTER.

Step 2.

Sistem membaca data yang

diinput pelanggan dan

menambahkan data baru

tersebut ke basis data.

Step 3.

Sistem menampilkan

konfirmasi suksesnya

registrasi pelanggan dan ID

pelanggan.

Alternate - -

Tabel 3.53. Deskripsi Use Case Deregister

Name Deregister



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


Normal Step 1.

Pelanggan menekan tombol

Unsubscribe di layar update

profil.

Step 2.

Sistem menghapus data

pelanggan dari basis data.

Step 3.

Sistem menampilkan layar

login dan memberi tahu

bahwa pelanggan telah sukses

di-deregistrasi.

Alternate - -


Name Login



login ke dalam sistem.

Precondition Data pelanggan terdaftar di dalam basis data.

Postcondition Pelanggan telah login ke dalam sistem.

104



Normal Step 1.

Pelanggan mengisi ID

pelanggan dan BlackBerry

PIN

Step 2.

Sistem melakukan validasi

terhadap 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



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


Normal Step 1.

Pelanggan mengubah data

pelanggan yang ada di form

profil dan menekan tombol

Update

Step 2.

Sistem mengubah data

pelanggan di basis data

berdasarkan input pelanggan.

Step 3.

Sistem menampilkan status

update profil.

Alternate - -

Tabel 3.59. Deskripsi Use Case Logout

Name Logout



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


Normal Step 1. Step 2.

106


Pelanggan menekan tombol

Logout di layar update

profil.

Sistem menghapus sesi

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.

107

Gambar 3.19. Class Diagram Sistem Solusi

108

Tabel 3.61. Daftar Dan Deskripsi Kelas

Nama Kelas Deskripsi Subsistem Asosiasi

OrderApplication Kelas aplikasi pemesanan pada subsistem aplikasi

BlackBerry

Aplikasi

BlackBerry

OrderScreen

OrderScreen Kelas yang menampilkan menampilkan form pemesanan

taksi.

Aplikasi

BlackBerry

OrderApplication, GPS,

CustomerData,

WebServiceConnection,

ConfirmationScreen.

ConfirmationScreen Kelas untuk menampilkan dialog konfirmasi, dialog

pemesanan ulang dan informasi taksi yang akan menjemput

pelanggan

BlackBerry OrderApplication,

WebServiceConnection,

CustomerData,

BlackberryMaps

WebServiceConnection Kelas yang digunakan untuk komunikasi antara subsistem

aplikasi BlackBerry dengan subsistem aplikasi server

Aplikasi

BlackBerry

OrderScreen,

ConfirmationScreen

109


GPS Kelas yang digunakan untuk mendapatkan posisi bujur dan

lintang pelanggan

Aplikasi

BlackBerry

OrderScreen

CustomerData Kelas yang digunakan untuk menyimpan data pelanggan

(posisi, nama, alamat, ID)

Aplikasi

BlackBerry

OrderScreen,

ConfirmationScreen,

BlackBerryMaps

BlackBerryMaps Kelas yang digunakan untuk menampilkan posisi taksi dan

pelanggan di aplikasi BlackBerry Maps

Aplikasi

BlackBerry

ConfirmationScreen,

CustomerData

OracleXEClient Kelas untuk melakukan operasi DML pada basis data Oracle

XE

Aplikasi

server,

aplikasi

administrator

Service,

SmartTaxiAdministrator

Service Kelas yang menangani proses bisnis sistem pada penelitian

seperti perhitungan jarak terdekat, pendaftaran pelanggan,

pemesanan taksi, dan konfirmasi taksi

Aplikasi

server

OracleXEClient,

SmartTaxiClient

110


Maps Kelas untuk menampilkan gambar peta dan indikator posisi

taksi dan pelanggan

Aplikasi

administrator,

aplikasi taksi

SmartTaxiAdministrator,

SmartTaxiClient

SmartTaxiAdministrator Kelas aplikasi ditujukan bagi administrator untuk memantau

data taksi dan pelanggan

Aplikasi

administrator

OracleXEClient, Maps

SmartTaxiClient Kelas aplikasi ditujukan bagi taksi untuk menampilkan

informasi pelanggan, peta, dan status taksi

Aplikasi taksi Maps, Service

STRegistration_Default Kelas dibalik halaman web yang memproses registrasi

pelanggan baru ke dalam basis data dan login pelanggan

Registrasi OracleXEClient

STRegistration_Home Kelas dibalik halaman web yang memproses tampilan,

pengubahan, dan penghapusan informasi pelanggan yang

terdaftar dalam basis data

Registrasi OracleXEClient

3.3. Perancangan Aplikasi

3.3.1. Entity Relationship Diagram

Berdasarkan perancangan yang telah dilakukan sebelumnya, dapat dibuat entitas-

entitas sebagai representasi data yang akan disimpan dalam basis data. Entitas-entitas

hasil analisis ini terdapat pada Gambar 3.20.

TAXISCUSTOMERS BOARDS

ORDERS

1 Has 0..*0..* Has 1

Has

1

1

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 Tipe Data Deskripsi

CUST_ID NUMBER ID pelanggan unik


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

1 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

2 OZAWA JL. JLN 5 -6.95 101.8 +626879 2a009d5f 1/5/2010

9:58:27

3 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


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



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

1 B 1234 ABC -6.19 106.6 A

2 B 5678 DEF -6.96 101.7 U

3 B 9012 GHI -6.21 106.4 W

4 B 3456 JKL -6.94 101.5 S

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


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 1 1 A 1/5/2010 3:31:54

BOARD_ID TAXI_ID CUST_ID STATUS EXPIRED

2 1 2 U 1/5/2010 3:32:08

3 2 1 U 1/5/2010 3:32:12

4 2 2 C 1/5/2010 3:32:04

Nama Entitas : ORDERS

Deskripsi : Menyimpan informasi 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


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 1 Y 1/5/2010 3:31:54

2 4 X 1/5/2010 3:32:08

3 9 N 1/5/2010 3:32:12

4 15 Y 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


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

t

t

a

a

p

b

d

d

a

t

3.3.2.2.Ranc

Ranc

taksi dan pe

taksi baru, m

ada. Setiap

akan ditamp

pada saat itu

Adm

berhubungan

daftar pelan

dengan men

aplikasi adm

tertera pada

cangan Lay

cangan layar

elanggan. Pa

mengubah da

kali admini

pilkan pada p

u.

ministrator b

n (dapat dila

nggan yang

nekan tomb

ministrator t

Tabel 3.72.

Gambar

Tabel 3.72.

yar Subsiste

r ini diguna

ada layar in

ata taksi yan

istrator mena

panel peta be

bisa memil

ayani) deng

ada (seluruh

bol untuk m

tergambar p

r 3.23. Ranc

Komponen R

em Aplikasi

akan oleh ad

ni, administr

ng sudah ad

ampilkan in

erikut posisi

lih untuk

an taksi yan

h pelanggan

menampilka

pada Gamba

cangan Layar

Rancangan L

Administra

dministrator

rator dapat m

da, dan meng

nformasi seb

pelanggan y

menampilka

ng dipilih sa

n yang suda

an semua p

ar 3.23. Ran

r Aplikasi A

Layar Aplika

ator

untuk meng

melakukan p

ghapus data

buah taksi, m

yang dapat d

an daftar

aja atau men

ah terdaftar

pelanggan. R

ncangan kom

Administrator

asi Administ

gawasi infor

penambahan

taksi yang s

maka posisi

dilayani oleh

pelanggan

nampilkan s

pada basis

Rancangan

mponen lay

r

trator

rmasi

n data

sudah

taksi

h taksi

yang

semua

data)

layar

arnya


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


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.

Gammbar 3.24. RRancangan LLayar Aplikaasi Taksi

Gambar 3. 25. Rancangan Layar Aplikasi Taksi: Tampil Foto Pelanggan

Tabel 3.73. Komponen Rancangan Layar Aplikasi Taksi


PanelCust 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


CustomerNameLabel 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.

T

T

T

T

B

Nama Kom

TextName

TextAddress

TextPhone

TextBBPin

ButtonRegis

Gambar

Tabel 3.74. K

mponen

F

s F

F

F

ster T

r 3.26. Ranc

Komponen R

Field teks unt

Field teks unt

Field teks unt

Field teks unt

Tombol untuk

cangan Layar

Rancangan L

tuk mengisi

tuk mengisi

tuk mengisi

tuk mengisi

k melakukan

r Pendaftara

Layar Penda

Deskrips

nama lengka

alamat pelan

nomor telep

BlackBerry

n registrasi p

an Dan Login

aftaran Dan L

si

ap pelanggan

nggan baru

pon pelangga

PIN pelangg

pelanggan ba

n

Login

n baru

an baru

gan baru

aru

T

T

B

m

P

T

Nama Kom

TextCustId

TextPasswo

ButtonLogin

Ranc

Laya

mereka. Lay

PIN pelangg

Tabel 3.75.

mponen

F

rd F

n T

cangan Lay

ar ini digun

yar ini memp

gan seperti d

Ga

Field teks unt

Field teks unt

Tombol untuk

yar Update P

nakan sebag

punyai form

digambarkan

ambar 3.27. R

tuk mengisi

t

Rancangan Sistem

Documents

Transcript of Rancangan Sistem