BAB 3 ANALISIS DAN PERANCANGAN SISTEM. proses pemesanan itu sendiri dan proses penyebaran pesanan. Tabel 3.1 berisi daftar

(1)

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

(2)

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.

(3)

(4)

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

(5)

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.

(6)

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.

(7)

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.

(8)

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,

(9)

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.

(10)

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.

(11)

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.

(12)

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.

(13)

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.

(14)

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

(15)

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.

(16)

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)

2 Kesalahan pemberian

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

(17)

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

(18)

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

(19)

51

3 Kesalahan pemberian

informasi pelanggan kepada taksi menyebabkan taksi tidak sampai pada pelanggan.

Pengembangan aplikasi pemesanan taksi di perangkat BlackBerry.

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

(20)

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

(21)

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.

(22)

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

(23)

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

(24)

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

Terdapat Dalam Proses Bisnis - 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)

(25)

Terdapat Dalam Proses Bisnis

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.

(26)

Terdapat Dalam Proses Bisnis 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

(27)

Terdapat Dalam Proses Bisnis

Output: Pelanggan menerima data tentang taksi

yang akan menjemput. Detail pelanggan, termasuk foto pelanggan, tampil di layar aplikasi taksi.

(28)

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

(29)

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.

(30)

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.

(31)

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.

(32)

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.

(33)

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

(34)

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

(35)

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.

(36)

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 Pelanggan Servis Web Pesan taksi Pus h da ta ta ksi Kir im pe rm in ta an _Pu sh

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.

(37)

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.

(38)

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

(39)

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

(40)

BlackBerry Application 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)

Precondition -

Postcondition Data pelanggan diterima aplikasi

Pelanggan mendapatkan posisi dari GPS Form pemesanan taksi ditampilkan aplikasi

(41)

Tabel 3.14. Aliran Use Case Login

Normal Step 1.

Pelanggan membuka aplikasi pemesanan taksi di perangkat BlackBerry.

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

(42)

untuk mendaftar terlebih dulu.

Tabel 3.15. Deskripsi Use Case Order Taxi

Name Order Taxi

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.

Aplikasi menghubungkan diri dengan web service,

mengirimkan data pelanggan ke web service.

Step 4.

Web service mencari taksi-taksi terdekat dengan rumus haversine.

(43)

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

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”

(44)

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

(45)

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

(46)

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.

(47)

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

Aplikasi menghubungkan diri dengan web service,

(48)

Flow Actor Action System Response 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) ,

(49)

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. Deskripsinya tertera pada Tabel 3.35, dan alirannya dijelaskan pada Tabel 3.36). 7. Melihat detail informasi suatu pelanggan (use case View Customer Info.

Deskripsinya tertera pada Tabel 3.37, dan alirannya dijelaskan pada Tabel 3.38). 8. Melihat indikator posisi taksi dan pelanggan pada peta (use case View Map.

Deskripsinya tertera pada Tabel 3.39, dan alirannya dijelaskan pada Tabel 3.40).

(50)

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.

(51)

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.

Precondition Aplikasi terhubung dengan basis data. Postcondition Daftar seluruh taksi tampil di layar.

(52)

Tabel 3.28. Aliran Use Case View Taxi List

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

(53)

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.

Alternate ALT Step 3.

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.

Precondition Aplikasi terhubung dengan basis data

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

(54)

Tabel 3.32. Aliran Use Case Delete Taxi

Normal Step 1.

Administrator memilih salah 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.

Precondition Aplikasi terhubung dengan basis data.

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.

(55)

Tabel 3.34. Aliran Use Case View Taxi Info

Normal Step 1.

Administrator memilih salah 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.

Precondition Aplikasi terhubung dengan basis data. Postcondition Daftar pelanggan ditampilkan.

(56)

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.

Precondition Aplikasi terhubung dengan basis data Postcondition Data pelanggan terpilih ditampilkan

Tabel 3.38. Aliran Use Case View Customer Info

Normal Step 1.

Administrator memilih salah satu pelanggan dari daftar pelanggan yang ada

Step 2.

Aplikasi menampilkan data pelanggan terpilih

(57)

Alternate - -

Name View Map

Description Use case menggambarkan bagaimana aplikasi menampilkan posisi taksi dan pelanggan (bila ada) di peta di layar.

Precondition -

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

Aplikasi membuat indikator posisi taksi terpilih di tengah kanvas peta

Step 2.

Aplikasi mencari berkas gambar bagian peta utama yang sesuai dengan posisi

(58)

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

(59)

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

(60)

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.

(61)

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.

Aplikasi menghubungkan diri dengan web service untuk mengubah status ketersediaan taksi dalam basis data, sesuai dengan tombol yang ditekan sopir taksi.

(62)

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

Description Use case menggambarkan bagaimana aplikasi menampilkan daftar pelanggan yang tersedia untuk taksi.

Precondition Aplikasi taksi terhubung ke web service.

(63)

Tabel 3.46. Aliran Use Case View Customer List

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

(64)

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

Aplikasi menghubungkan diri dengan web service dan

(65)

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

(66)

pelanggan dan detail pelanggan lainnya dari web service dan menampilkannya di layar.

Alternate - -

Name View Map

Description Use case menggambarkan bagaimana aplikasi menampilkan posisi taksi dan pelanggan (bila ada) di peta di layar.

Precondition -

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

Aplikasi mengambil data posisi bujur dan lintang dari

(67)

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.

(68)

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

(69)

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

(70)

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

Description Use case menggambarkan bagaimana pelanggan melakukan deregistrasi terhadap layanan pemesanan taksi.

Precondition Pelanggan telah login ke dalam sistem. Postcondition Pelanggan ter-deregistrasi dari sistem.

(71)

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

Description Use case menggambarkan bagaimana pelanggan melakukan login ke dalam sistem.

Precondition Data pelanggan terdaftar di dalam basis data. Postcondition Pelanggan telah login ke dalam sistem.

(72)

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

Description Use case menggambarkan bagaimana pelanggan melakukan login ke dalam sistem

Precondition Pelanggan telah login ke dalam sistem Postcondition Data pelanggan di basis data ter-update

(73)

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

Description Use case menggambarkan bagaimana pelanggan melakukan 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

(74)

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

(75)

107 Gambar 3.19. Class Diagram Sistem Solusi

(76)

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,

(77)

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

(78)

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

(79)

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-entitas hasil analisis ini terdapat pada Gambar 3.20.

TAXIS CUSTOMERS 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