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

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 Data 1) Pelanggan menelepon Dokumen pemesanan taksi pelanggan. perusahaan taksi dan pemesan taksi memberikan data pelanggan. 2) Operator menyimpan data pelanggan di berkas dokumen pesanan. 2 Proses Dokumen 1) Operator melakukan Dokumen broadcast pemesan broadcast data pesanan ke pesanan taksi pesanan taksi, data seluruh taksi. 33

34 No. Nama Proses Input 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 Operator, Dokumen pemesan taksi pemesanan taksi Pelanggan 2. Proses Operator, Sopir Dokumen pesanan taksi broadcast Taksi pesanan taksi Untuk lebih memperjelas hubungan aktor dan proses bisnis yang teridentifikasi, lihat document flow diagram pada Gambar 3.1 dan use case diagram yang menggambarkan sistem pada Gambar 3.2.

Gambar 3.1. Document Flow Diagram Sistem Konvensional 35

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 Actors Description Order Taxi Customer (Pelanggan), Operator Use case menggambarkan bagaimana pelanggan memesan taksi Precondition Postcondition Pesanan belum dilakukan Data pelanggan tercatat

37 Tabel 3.4. Aliran Use Case Order Taxi Flow Actor Action System Response Normal Step 1. Pelanggan menekan nomor Step 2. Sistem menyambungkan telepon operator untuk pelanggan taksi dengan menghubungi jasa taksi. Step 3. Operator penyedia menanyakan operator melalui jaringan telepon. 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. Alternate - -

38 Tabel 3.5. Deskripsi Use Case Broadcast Order Request Name Actors Description Broadcast Order Request Customer (Pelanggan), Operator Use case menggambarkan bagaimana penyedia jasa taksi mengkonfirmasi pesanan taksi ke pelanggan Precondition Postcondition Pesanan telah dilakukan Pelanggan mendapatkan satu taksi yang akan menjemput Tabel 3.6. Aliran Use Case Broadcast Order Request Flow Actor Action System Response Normal Step 1. Operator mengaktifkan Step 2. Sistem mengirimkan sinyal perangkat radio untuk melakukan broadcast data pelanggan yang memesan jasa taksi. Step 3. Sopir taksi menerima data data melalui gelombang radio ke perangkat radio di armada taksi dalam jangkauan gelombang radio. Step 4. Sistem mengirimkan sinyal pelanggan mengaktifkan dan perangkat data melalui gelombang radio dari perangkat radio di radio untuk mengambil pesanan yang disebar oleh armada taksi ke perangkat radio operator. operator taksi.

39 Flow Actor Action System Response Step 5. Operator meng-input data pelanggan dan taksi yang melayaninya pada sistem / berkas penyimpanan data. Alternate - - Berdasarkan observasi, permasalahan pertama yang teridentifikasi adalah posisi pelanggan dan taksi-taksi terdekat tidak diketahui. Jika ada pelanggan yang memesan taksi, maka pesanan taksi tersebut dilelang ke seluruh armada taksi oleh operator. Pada sistem pemesanan taksi konvensional, operator tidak memilihkan taksi-taksi terdekat untuk pelanggan tersebut karena tidak mengetahui posisi masing-masing taksi. Permasalahan yang kedua adalah satu operator hanya bisa melayani satu pelanggan pada suatu waktu. Ada kemungkinan jika pelanggan menelepon untuk memesan taksi, tidak satu pun operator dari perusahaan taksi yang bisa melayani. Terakhir, operator adalah manusia yang mungkin melakukan kesalahan, dalam hal ini, kesalahan dalam mengingat atau memroses informasi yang diberikan pelanggan dan kesalahan dalam menyampaikannya ke sopir taksi. Daftar permasalahan teridentifikasi pada proses bisnis berjalan terdapat pada Tabel 3.7..

40 Tabel 3.7. Daftar Masalah Teridentifikasi Pada Proses Bisnis Berjalan No. Nama Proses Masalah Verifikasi Studi Literatur 1. Proses pemesanan taksi Masalah 1. Posisi pelanggan dan Dibutuhkan dua titik dengan bujur dan lintang pada permukaan bumi taksi-taksi dengan terdekat pelanggan untuk mendapatkan jarak lingkaran besar (Veness, 2009). tidak diketahui. Masalah 2. Operator yang sibuk Pelanggan harus dapat menghubungi orang yang dapat melaksanakan keinginannya dengan cepat dan sehingga ada mudah. Masalah pelanggan, yang pelanggan yang harus sudah menelepon atau menulis surat menunggu dilayani dan tahu bahwa ia sedang melakukan bahkan tidak sempat terlayani. kontak, harus diambil alih secara cepat dan efisien. Dengan kata lain, 2. Proses broadcast pesanan taksi Masalah 3. Faktor manusia yang memungkinkan operator menyebarkan pelanggan harus segera tahu bahwa mereka tidak lagi menghadapi masalah, karena masalah itu sudah ditanggulangi sistem (Armistead, et al., 1996). 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 / namun perilaku itu pada kenyataannya tidak membuat hasil yang diinginkan itu (Marguglio, 2009) berkas penyimpanan data. 3.1.2. Analisis Wawancara dan Kuesioner Survei dengan menggunakan kuesioner dibuat untuk mengkonfirmasi permasalahan teridentifikasi dari observasi pada proses bisnis berjalan atau untuk menemukan apakah ada masalah lain yang terjadi dalam proses bisnis berjalan. Survei ini ditujukan untuk pelanggan taksi yang berada di Jakarta yang menggunakan telepon untuk memesan taksi. Survei dilakukan dengan mengambil 50 orang pelanggan taksi sebagai sampel pada Januari 2010. Daftar pertanyaan pada kuesioner ini terdapat pada Tabel L6. Selain survey, juga dilakukan wawancara terhadap dua orang sopir taksi dan dua operator taksi. Wawancara terhadap sopir taksi dilakukan untuk mengkonfirmasi permasalahan khususnya masalah ketiga (human error pada operator). Tabel L4 berisi daftar pertanyaan wawancara terhadap sopir taksi. Wawancara terhadap operator dilakukan untuk mengkonfirmasi permasalahan khususnya permasalahan kedua. Tabel L5 berisi daftar pertanyaan wawancara terhadap operator.

42 Setelah survei dilakukan, ditemukan fakta sebagai berikut. Dari pertanyaan pertama, 48% responden menyatakan pernah menemukan operator taksi sibuk ketika mereka menelepon. 52% sisanya menyatakan tidak pernah menemukan operator taksi sibuk. Persentase jawaban responden digambarkan pada Gambar 3.3. Gambar 3.3. Respons Pelanggan Terhadap Survey Pertanyaan 1 Dari pertanyaan kedua, 58% responden menyatakan bahwa mereka menunggu taksi selama 10-20 menit. 32% responden menyatakan bahwa mereka menunggu taksi selama lebih dari 20 menit. 10% sisanya menyatakan bahwa mereka menunggu kurang dari 10 menit. Persentase jawaban responden digambarkan pada Gambar 3.4.

43 Gambar 3.4. Respons Pelanggan Terhadap Survey Pertanyaan 2 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. Gambar 3.5. Respons Pelanggan Terhadap Survey Pertanyaan 3 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 Gambar 3.6. Respons Pelanggan Terhadap Survey Pertanyaan 4 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. Gambar 3.7. Respons Pelanggan Terhadap Survey Pertanyaan 5 Dari pertanyaan keenam, diketahui bahwa 22% pemesan taksi mempunyai perangkat BlackBerry. Persentase jawaban responden digambarkan pada Gambar 3.8.

45 Gambar 3.8. Respons Pelanggan Terhadap Survey Pertanyaan 6 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 Pelanggan Kuesioner pertanyaan 1, saat pelanggan wawancara terhadap operator.

46 No Permasalahan Aktor Evaluasi Dari menelepon 2 Pelanggan merasa taksi Pelanggan Kuesioner pertanyaan 2 dan 3 membutuhkan waktu lama untuk sampai ke pelanggan 3 Kesalahan pemberian Pelanggan Kuesioner pertanyaan 4, informasi pelanggan wawancara terhadap sopir taksi. kepada taksi yang dapat menyebabkan taksi tidak sampai pada pelanggan 4 Pelanggan Pelanggan Kuesioner pertanyaan 5. membutuhkan informasi tentang taksi yang akan menjemputnya 3.1.3. Analisis Permasalahan Berdasarkan daftar permasalahan pada Tabel 3.7 yang didapatkan dari observasi terhadap proses bisnis yang sedang berjalan dan berdasarkan daftar permasalahan hasil survei dan wawancara pada Tabel 3.8, akar masalah yang terjadi pada sistem pemesanan

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

Tabel 3.9. Rangkuman Masalah Teridentifikasi Pada Proses Bisnis Berjalan No Permasalahan Teridentifikasi Sumber Identifikasi Landasan Teori 1 Posisi pelanggan dan taksitaksi 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 Pengamatan lapangan, Kesalahan manusia (human error) adalah perilaku yang secara informasi pelanggan kepada taksi yang dapat menyebabkan taksi tidak sampai pada pelanggan 3 Operator yang sibuk sehingga ada pelanggan yang harus menunggu dilayani bahkan wawancara dengan sopir taksi, dan kuesioner Pengamatan lapangan dan kuesioner keseluruhan diharapkan untuk membuat hasil yang diinginkan, namun perilaku itu pada kenyataannya tidak membuat hasil yang diinginkan itu. (Marguglio, 2009) Pelanggan harus dapat menghubungi orang yang dapat melaksanakan keinginannya dengan cepat dan mudah. (Armistead, et al., 1996). 48

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- GPS pada taksi dan GPS merupakan suatu kumpulan satelit dan sistem kontrol yang taksi di sekitarnya tidak perangkat BlackBerry. memungkinkan sebuah penerima GPS untuk mendapatkan 49

No Permasalahan Teridentifikasi Solusi Landasan Teori diketahui sehingga sistem tidak Pengembangan LBS lokasinya di permukaan bumi 24 jam sehari (Heywood, et al., bisa mencarikan taksi-taksi untuk mencari taksi-taksi 2002). terdekat terdekat berdasarkan Layanan Berbasis Lokasi (Location-Based Services / LBS) adalah posisi pelanggan yang layanan informasi yang mengutilisasi kemampuan untuk dikirim menggunakan haversine. dengan rumus 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). 50

No Permasalahan Teridentifikasi Solusi Landasan Teori 3 Kesalahan pemberian Pengembangan aplikasi BlackBerry merupakan perangkat bergerak pintar yang informasi pelanggan kepada taksi menyebabkan taksi tidak pemesanan taksi di perangkat BlackBerry. menggabungkan sejumlah fungsi termasuk surat elektronik, penjelajahan web, pesan teks, pengelolaan jadwal, dan telepon sampai pada pelanggan. Pengembangan aplikasi seluler ke dalam suatu perangkat portabel registrasi yang mampu (BusinessDictionary.com). menyimpan data Basis data adalah satuan, tempat penyimpanan data yang besar pelanggan (termasuk foto pelanggan) 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 Pengembangan web Web service adalah sebuah komponen aplikasi yang bisa ada pelanggan yang harus menunggu dilayani bahkan tidak sempat terlayani. service untuk melayani pelanggan diprogram dan diakses lewat protokol web standar (Peiris, et al., 2007). 51

No Permasalahan Teridentifikasi Solusi Landasan Teori 5 Pelanggan membutuhkan Implementasi teknologi Salah satu kelebihan teknologi push BlackBerry adalah informasi tentang taksi yang menjemput. basis data dan push pada sistem yang akan kemampuannya untuk mengirimkan informasi dengan instan. Teknologi push BlackBerry adalah metode komunikasi di internet dibangun. Informasi yang berbeda dengan teknologi pull yang biasa digunakan, di tentang taksi yang akan menjemput akan disimpan dalam basis data dan dikirimkan lewat layanan push. Basis data 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). digunakan menyimpan untuk data Basis data adalah satuan, tempat penyimpanan data yang besar yang bisa digunakan bersama oleh satu maupun banyak pelanggan, taksi, dan pesanan untuk digunakan sistem. pengguna. Selain data yang ada tidak akan berulang, semua data akan diintegrasi dengan jumlah duplikasi yang minimum (Connolly, et al., 2002). 52

Berdasarkan solusi yang terangkum, dapat disimpulkan beberapa tujuan solusi yang terdaftar pada Tabel 3.11. Tabel 3.11. Tujuan Dari Solusi Yang Akan Dibangun No Tujuan Solusi Ditujukan Untuk Informasi Yang Akan Diberikan Kepada Aktor Keuntungan Bagi Pengguna 1. Menemukan taksi- Pelanggan Koordinat posisi taksi 1. Pelanggan mengetahui taksi mana yang akan menjemput taksi terdekat dan posisi pelanggan sehingga tidak salah naik taksi dengan posisi 2. Pelanggan mengetahui posisi terakhir dari taksi yang akan pelanggan 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 Sopir taksi Posisi pelanggan, foto 1. Taksi sampai ke lokasi pelanggan yang tepat dan tidak informasi pelanggan, dan alamat menjemput pelanggan yang salah. 53

No Tujuan Solusi Ditujukan Untuk Informasi Yang Akan Diberikan Kepada Aktor Keuntungan Bagi Pengguna pelanggan yang pelanggan. tepat kepada sopir taksi 3. Memberikan pelanggan Pelanggan Nomor kendaraan taksi, posisi taksi 1. Pelanggan mendapatkan informasi yang tepat tentang taksi mana yang akan menjemputnya, sehingga pelanggan tidak naik informasi yang pada taksi yang salah. tepat tentang taksi yang menjemput 3.2. Perancangan Sistem Solusi Setelah tujuan solusi-solusi yang akan menjawab permasalahan terangkum pada Tabel 3.10, proses-proses bisnis apa saja yang dibutuhkan untuk mewujudkan tujuan solusi tersebut dianalisis. Proses-proses bisnis yang tertera pada Tabel 3.12 ini akan digabungkan ke dalam suatu sistem pemesanan taksi baru yang digambarkan pada Gambar 3.9.. 54

Tabel 3.12. Proses Bisnis Digunakan Untuk Mewujudkan Tujuan Solusi. No Tujuan Solusi Proses Bisnis Yang Akan Digunakan Menu dan Informasi Yang Akan Terdapat Dalam Proses Bisnis 1. Menemukan posisi pelanggan dan taksitaksi terdekat dengan posisi pelanggan. 2. Menyampaikan informasi pelanggan yang tepat kepada sopir taksi 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 registrasi pelanggan Input: Nama, lokasi, nomor telepon pelanggan, foto diri pelanggan, dan BlackBerry PIN Proses: Proses 1: Proses pemesanan taksi Menu: Menu pemesanan pada layar pemesanan Proses 1: Proses registrasi pelanggan Menu: Menu registrasi pelanggan baru, menu update profil pelanggan, menu login, dan menu deregistrasi pelanggan 55

No Tujuan Solusi Proses Bisnis Yang Akan Digunakan Menu dan Informasi Yang Akan - Proses upload foto diri pelanggan dan Terdapat Dalam Proses Bisnis penyimpanan data pelanggan pada basis data Output: Pelanggan mendapatkan ID pelanggan dan Proses 2: Proses login pelanggan Menu: - (dilakukan secara otomatis oleh aplikasi) data pelanggan tersimpan pada basis data Proses 3: Proses pengambilan daftar pelanggan Proses 2: Proses login pelanggan Menu: - (dilakukan secara otomatis oleh aplikasi) Input: BlackBerry PIN Proses: - Proses pengiriman BlackBerry PIN ke web service untuk mendapatkan ID pelanggan, nama pelanggan, lokasi pelanggan, dan koordinat posisi pelanggan untuk digunakan oleh aplikasi pada perangkat BlackBerry untuk proses pemesanan. 56

No Tujuan Solusi Proses Bisnis Yang Akan Digunakan Menu dan Informasi Yang Akan 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. - Proses penampilan daftar pelanggan di layar 57

No Tujuan Solusi Proses Bisnis Yang Akan Digunakan Menu dan Informasi Yang Akan 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 dijemput. 58

No Tujuan Solusi Proses Bisnis Yang Akan Digunakan Menu dan Informasi Yang Akan Terdapat Dalam Proses Bisnis Output: Pelanggan menerima data tentang taksi yang akan menjemput. Detail pelanggan, termasuk foto pelanggan, tampil di layar aplikasi taksi. 59

60 3.2.1. Use Case Diagram Untuk memperjelas solusi yang diusulkan, berikut narasi cara kerja solusi secara umum seperti tergambar pada Gambar 3.9. 1. Pelanggan taksi melakukan registrasi pada sistem melalui antarmuka web. Pada registrasi, pelanggan akan diminta nama Pelanggan yang telah melakukan registrasi akan mendapatkan ID pelanggan unik untuk digunakan selanjutnya. 2. Pelanggan yang terregistrasi melakukan pemesanan taksi dengan mengirimkan informasi lokasi pemesanan. Informasi pelanggan beserta posisi yang dicari oleh GPS tertanam akan dikirmkan ke server sistem. 3. Server akan mencari taksi terdekat untuk pelanggan yang memesan taksi. Pencarian taksi terdekat dilakukan dengan perhitungan jarak terdekat antara posisi pelanggan yang dikirimkan dan posisi taksi yang berada pada jangkauan pencarian taksi disekitar posisi pelanggan. 4. Aplikasi pada kendaraan taksi akan menampilkan posisi taksi pada peta dan akan me-request posisinya lewat perangkat GPS setiap periode tertentu dan akan mengirimkan posisinya ke server. Server akan merespons dengan daftar pelanggan yang tersedia untuk taksi tersebut, dengan syarat taksi tersebut sedang dalam keadaan tersedia (tidak melayani pelanggan). Aplikasi taksi akan menampilkan daftar pelanggan yang diterima untuk dipilih salah satunya. 5. Ketika taksi memilih salah satu pelanggan yang bisa dilayaninya, maka aplikasi akan mengirimkan informasi pelanggan yang terpilih ke server melalui jaringan internet. Aplikasi taksi juga akan menampilkan foto pelanggan yang memesan untuk membantu sopir taksi mengidentifikasi pelanggan. Pada saat ini taksi

61 sedang dalam kondisi menunggu konfirmasi pelanggan dan tidak bisa memilih pelanggan lainnya. 6. Kiriman informasi dari aplikasi taksi pada server akan diproses. Kemudian informasi taksi yang akan melayani pelanggan akan dikirimkan ke pelanggan melalui teknologi push BlackBerry. Pengiriman dilakukan lewat server milik BlackBerry, yaitu BlackBerry Enterprise Server (BES) yang akan diteruskan langsung ke perangkat BlackBerry milik pemesan taksi. 7. Aplikasi BlackBerry akan menerima informasi push yang terkirim, dan aplikasi akan meminta konfirmasi pelanggan dan mengirimkan konfirmasi tersebut ke server. 8. Aplikasi taksi yang sedang dalam keadaan menunggu konfirmasi pelanggan mengecek secara periodik ke server. Begitu ada informasi konfirmasi pelanggan yang direspons oleh server, maka aplikasi taksi akan mengubah kondisi menjadi sedang melayani pelanggan. Aplikasi taksi juga akan menampilkan posisi pelanggan pada peta untuk mempermudah taksi mencapai lokasi pelanggan.

62 Gambar 3.9. Gambaran Sistem Secara Umum Dari gambaran sistem secara umum di atas, solusi sistem yang diusulkan dapat dibagi menjadi lima subsistem, yakni subsistem aplikasi taksi, subsistem aplikasi BlackBerry, subsistem aplikasi administrator, subsistem aplikasi server, dan subsistem registrasi. Gambaran masing-masing bagian dijelaskan di bagian berikut.

63 Gambaran Subsistem Aplikasi Taksi Cara kerja subsistem aplikasi taksi dideskripsikan sebagai berikut, seperti pada Gambar 3.10. 1. Pertama kali aplikasi taksi dibuka, maka aplikasi akan membuka dialog input untuk menanyakan nomor kendaraan taksi. Nomor tersebut akan dikirimkan ke server lewat koneksi internet. Server akan merespons dengan nomor ID taksi yang akan disimpan oleh aplikasi untuk selanjutnya. 2. Aplikasi akan menampilkan peta dan penunjuk posisi kendaraan taksi. Sambil setiap periode tertentu aplikasi me-request posisi kendaraan lewat perangkat GPS. Posisi tersebut akan disimpan dan aplikasi secara otomatis meng-update indikator posisi taksi pada peta. 3. Aplikasi taksi mempunyai dengan empat kondisi, kondisi awal saat aplikasi mulai dibuka adalah kondisi tersedia, di mana kondisi tersebut berarti taksi sedang dalam keadaan kosong, sopir taksi dapat melayani pelanggan. Dalam kondisi ini aplikasi akan secara periodik mengirimkan posisinya ke server. Bila ada pelanggan tersedia untuk taksi tersebut, server akan merespons dengan daftar pelanggan taksi yang dapat dilayani oleh taksi tersebut (daftar pelanggan tersebut sudah diproses oleh server, yang merupakan pelanggan dengan jarak terdekat dengan kendaraan taksi). Daftar pelanggan tersebut akan ditampilkan pada aplikasi agar bisa dipilih oleh sopir taksi. 4. Kondisi kedua dari aplikasi taksi adalah tidak tersedia, yang berarti taksi sedang tidak beroperasi. Dalam kondisi ini, aplikasi akan tetap mengirimkan posisi taksi untuk di-update pada server, tetapi server tidak merespons dengan daftar pelanggan yang mungkin dilayani oleh taksi.

64 5. Kondisi ketiga dari aplikasi taksi adalah menunggu konfirmasi pelanggan. Kondisi ini dimulai ketika taksi memilih salah satu dari beberapa pelanggan yang ditampilkan aplikasi. Pada kondisi ini, aplikasi secara periodik mengirimkan posisi taksi ke server dan server akan memberi tahu aplikasi taksi jika pelanggan taksi yang dipilih memberikan konfirmasi pemesanan. Aplikasi akan menampilkan foto pelanggan yang dipilih untuk membantu sopir taksi mengidentifikasi pelanggan. Selain itu, aplikasi juga akan menampilkan indikator posisi pelanggan pada peta untuk mempermudah navigasi sopir taksi ke lokasi pelanggan. Aplikasi tidak akan menampilkan daftar pelanggan lainnya dalam kondisi ini. 6. Kondisi keempat dari aplikasi taksi adalah sedang melayani pelanggan. Kondisi ini terjadi ketika taksi menerima respons konfirmasi. Pada kondisi ini aplikasi akan tetap mengirimkan posisi taksi ke server secara periodik. Untuk mengakhiri kondisi keempat ini, pengguna aplikasi harus mengubah kondisinya menjadi tersedia denga cara menekan tombol yang disediakan. 7. Aplikasi memungkinkan sopir taksi secara proaktif mengubah status ketersediaan taksi menjadi tersedia atau tidak tersedia. Ketika sopir taksi memilih salah satu kondisi tersebut secara proaktif (menekan salah satu tombol pengubah kondisi) atau ketika aplikasi secara implisit mengubah kondisinya, maka informasi kondisi akan dikirimkan ke server untuk mengubah kondisi taksi pada basis data.

65 Gambar 3.10. Gambaran Subsistem Aplikasi Taksi Gambaran Subsistem Aplikasi Administrator Cara kerja subsistem aplikasi administrator yang tergambar pada Gambar 3.11 dideskripsikan sebagai berikut. 1. Aplikasi terhubung langsung ke basis data. Saat pertama kali aplikasi dijalankan, daftar taksi dan pelanggan yang ada akan ditampilkan pada tabel. Setiap periode tertentu, daftar taksi dan pelanggan yang ada akan di-update dari basis data. 2. Pengguna aplikasi dapat melihat informasi taksi dengan memilih salah satu dari beberapa taksi yang ada pada daftar taksi. Informasi yang ada meliputi nomor

66 kendaraan, posisi, dan kondisi operasional taksi. Pada saat ini daftar pelanggan yang ditampilkan hanya pelanggan yang mungkin dilayani oleh taksi (hasil pemrosesan pelanggan terdekat dengan kendaraan taksi). Penunjuk posisi taksi dan penunjuk posisi-posisi pelanggan yang mungkin dilayani akan ditampilkan pada peta. 3. Pengguna aplikasi dapat melihat informasi pelanggan dengan memilih salah satu dari beberapa pelanggan yang ada pada daftar pelanggan. Informasi yang ditampilkan meliputi data diri pelanggan dan posisi pelanggan. 4. Pengguna aplikasi dapat menambahkan data taksi baru, mengubah data taksi yang sudah ada, dan menghapus data taksi yang sudah ada. Dialog input untuk mengisi data taksi akan ditampilkan ketika pengguna ingin menambah atau mengubah data taksi. Database Buat, lihat, dan hapus data taksi. Lihat data pelanggan Aplikasi Administator Gambar 3.11. Gambaran Subsistem Aplikasi Administrator

67 Gambaran Subsistem Aplikasi BlackBerry Seperti pada Gambar 3.12, cara kerja subsistem aplikasi BlackBerry dideskripsikan sebagai berikut. 1. Ketika dibuka pertama kali, Aplikasi akan terhubung ke subsistem aplikasi server dan akan meng-query data pelanggan yang terregistrasi untuk proses pemesanan. Aplikasi akan memberitahukan pengguna yang belum melakukan registrasi untuk meregistrasikan diri ke website yang disediakan. 2. Aplikasi akan menyimpan dan menampilkan alamat pemesanan terakhir untuk memudahkan pelanggan jika ingin memesan di lokasi yang sama. Jika pelanggan ingin memesan di lokasi yang berbeda, pelanggan dapat memasukkan informasi lokasi yang baru dan aplikasi akan mengambil posisi pelanggan lewat GPS tertanam dari perangkat BlackBerry. Informasi lokasi pemesanan akan dikirimkan oleh aplikasi ke server sistem melalui internet di perangkat BlackBerry. 3. Aplikasi akan menampilkan pesan kepada pengguna untuk menunggu respons dari server. Pada saat ini aplikasi mulai membuka push listener agar bisa menerima respons dari BES. Server akan merespons dengan informasi taksi yang akan melayani pengguna lewat teknologi push BlackBerry. Informasi tersebut ditangkap oleh listener dan aplikasi akan menampilkan informasi taksi, kemudian menanyakan konfirmasi kepada pengguna apakah pengguna akan menggunakan jasa taksi dengan informasi taksi yang dikirim atau membatalkan pemesanan. Konfirmasi tersebut akan dikirimkan kembali ke server sistem melalui koneksi internet.

68 4. Jika pengguna memilih untuk menggunakan jasa taksi yang informasinya ditampilkan, maka aplikasi akan menampilkan peta posisi pengguna dan posisi taksi yang akan menjemput pengguna, dari kondisi ini pengguna dapat secara proaktif mengakhiri aplikasi (selesai). Mendapatkan lokasi dengan GPS Database Pesan taksi Servis Web Pelanggan Kirim permintaan Push Push data taksi Gambar 3.12. Gambaran Subsistem Aplikasi BlackBerry Gambaran Subsistem Aplikasi Server Seperti pada Gambar 3.13, cara kerja subsistem aplikasi server dideskripsikan sebagai berikut.

69 1. Aplikasi server pada sistem berupa web service. Web service ini terhubung langsung ke basis data untuk melakukan operasi manipulasi data. Subsistem aplikasi taksi dan aplikasi BlackBerry akan berhubungan dengan web service ini. 2. Aplikasi server dapat meminta BES untuk mengirimkan informasi ke perangkat BlackBerry milik pelanggan lewat teknologi push BlackBerry. 3. Aplikasi server akan melakukan perhitungan jarak tanpa rute menggunakan persamaan haversine yang tertera pada Persamaan 2. Gambar 3.13. Gambaran Subsistem Aplikasi Server

70 Gambaran Subsistem Registrasi Cara kerja subsistem registrasi adalah seperti digambarkan pada Gambar 3.14 adalah sebagai berikut. 1. Pelanggan baru yang belum terdaftar dapat mendaftarkan perangkat BlackBerry nya pada sistem registrasi berbasis web. Pelanggan yang telah melakukan registrasi akan mendapatkan ID pelanggan. 2. Pelanggan yang sudah terdaftar dapat melakukan login menggunakan ID pelanggan dan BlackBerry PIN untuk masuk ke halaman profil. 3. Pada halaman profil, pelanggan dapat mengubah informasi registrasinya, menghapus keanggotaan, dan logout untuk kembali ke halaman utama. Gambar 3.14. Gambaran Subsistem Registrasi

71 3.2.2. Use Case Diagram Berdasarkan dari gambaran sistem yang ada, proses-proses yang berhubungan dengan aktor dapat digambarkan dengan use case diagram. Use case diagram sistem dibagi menjadi empat use case diagram subsistem agar perancangan sistem lebih mudah dipahami. 3.2.2.1.Use Case Diagram Subsistem Aplikasi BlackBerry Dalam subsistem aplikasi BlackBerry, yang menjadi aktor adalah pelanggan (atau customer dalam use case diagram pada Gambar 3.15). Seorang pelanggan dapat: 1. Login (use case Login. Deskripsi tertera pada Tabel 3.13, dan alirannya dijelaskan pada Tabel 3.14). 2. Memesan taksi (use case Order Taxi. Deskripsi tertera pada Tabel 3.15, dan alirannya dijelaskan pada Tabel 3.16). 3. Mengkonfirmasi pesanan (use case Confirm Order. Deskripsinya tertera pada Tabel 3.17, dan alirannya dijelaskan pada Tabel 3.18). 4. Melihat indikator posisi taksi dan pelanggan pada peta (use case View Map. Deskripsinya tertera pada Tabel 3.19, dan alirannya dijelaskan pada Tabel 3.20). 5. Mengulangi pesanan (use case Retry Order. Deskripsinya tertera pada Tabel 3.23, dan alirannya dijelaskan pada Tabel 3.24). 6. Membatalkan pemesanan (use case Cancel Order. Deskripsinya tertera pada Tabel 3.21, dan alirannya dijelaskan pada Tabel 3.22).

72 BlackBerry Application Subsystem Login Order Taxi Retry Order View Map Cancel Order «extends» Customer Confirm Order Gambar 3.15. Use Case Diagram Subsistem Aplikasi BlackBerry Tabel 3.13. Deskripsi Use Case Login Name Actors Description Login Customer (Pelanggan) Use case menggambarkan bagaimana pelanggan memesan Precondition - taksi Postcondition Data pelanggan diterima aplikasi Pelanggan mendapatkan posisi dari GPS Form pemesanan taksi ditampilkan aplikasi

73 Tabel 3.14. Aliran Use Case Login Flow Actor Action System Response Normal Step 1. Step 2. Pelanggan membuka Aplikasi menghubungkan aplikasi pemesanan taksi di diri dengan web service, perangkat BlackBerry. 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 Flow Actor Action System Response untuk mendaftar terlebih dulu. Tabel 3.15. Deskripsi Use Case Order Taxi Name Actors Description Order Taxi Customer (Pelanggan) Use case menggambarkan bagaimana pelanggan memesan taksi Precondition Postcondition Pelanggan sudah melakukan use case Login Data pesanan pelanggan tertulis di basis data. Tabel 3.16. Aliran Use Case Order Taxi Flow Actor Action System Response Normal Step 1. Step 3. Pelanggan mengganti Aplikasi menghubungkan alamat bila diperlukan dan diri dengan web service, menekan tombol mengirimkan data ORDER. pelanggan ke web service. Step 4. Web service mencari taksitaksi terdekat dengan rumus haversine.

75 Flow Actor Action System Response Step 5. Aplikasi menunggu push data dari server Alternate ALT Step 5. Jika aplikasi tidak menerima push data dalam 90 detik, maka aplikasi akan menampilkan dialog pemesanan ulang Tabel 3.17. Deskripsi Use Case Confirm Order Name Actors Confirm Order Customer (Pelanggan) 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 Flow Actor Action System Response Normal Step 1. Pelanggan menekan Step 2. Aplikasi tombol OK di layar menghubungkan diri konfirmasi. 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 Alternate - - ketersediaan taksi menjadi SERVICING. Tabel 3.19. Deskripsi Use Case View Map Name Actors View Map Customer (Pelanggan)

77 Description Use case menggambarkan bagaimana aplikasi menampilkan BlackBerry Maps. Precondition Pelanggan telah melakukan konfirmasi pemesanan taksi (dengan use case Confirm Order). Postcondition BlackBerry Maps terbuka. Tabel 3.20. Aliran Use Case View Map Flow Actor Action System Response Normal - Step 1. Aplikasi menginisiasi BlackBerry Maps dengan mengirimkan data posisi taksi dan posisi pelanggan. Step 2 Aplikasi memanggil Alternate - - BlackBerry Maps untuk menampilkan peta. Tabel 3.21. Deskripsi Use Case Cancel Order Name Actors Cancel Order Customer (Pelanggan)

78 Description Use case menggambarkan bagaimana pelanggan membatalkan pesanan taksi. Precondition Pelanggan telah melakukan pemesanan taksi. Data taksi telah diterima pelanggan. Postcondition Data pesanan terbaharui di basis data. Tabel 3.22. Aliran Use Case Cancel Order Flow Actor Action System Response Normal Step 1. Pelanggan menekan Step 2. Aplikasi tombol Cancel di layar menghubungkan diri konfirmasi. 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 Flow Actor Action System Response Alternate - - sendiri. Tabel 3.23. Deskripsi Use Case Retry Order Name Actors Description Retry Order Customer (Pelanggan) Use case menggambarkan bagaimana Pelanggan mencoba memesan taksi kembali. Precondition Pelanggan telah melakukan pemesanan taksi Data pesanan untuk pelanggan ini telah ada di basis data, namun aplikasi belum menerima data taksi setelah 90 detik Postcondition Data pesanan terbarui di basis data. Data pesanan baru telah diterima aplikasi. Tabel 3.24. Aliran Use Case Retry Order Flow Actor Action System Response Normal Step 1. Step 2. Pelanggan menekan Aplikasi menghubungkan tombol RETRY di layar diri dengan web service, konfirmasi. mengirimkan data

80 Flow Actor Action System Response pelanggan ke web service. Web service mencari taksitaksi terdekat dengan rumus haversine. Step 3. Aplikasi menunggu push data dari server. Alternate ALT Step 1. Pengguna menekan tombol QUIT untuk menutup aplikasi (tidak memesan ALT Step 3. Jika aplikasi kembali tidak menerima push data dalam 90 detik, maka aplikasi akan ulang). menampilkan pemesanan ulang. dialog 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. 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). Gambar 3.16. Use Case Diagram Subsistem Aplikasi Administrator

82 Tabel 3.25. Deskripsi Use Case Add New Taxi Name Actors Add New Taxi Administrator Description Use case menggambarkan bagaimana administrator menambahkan data taksi baru ke basis data. Precondition Postcondition Aplikasi terhubung dengan basis data. Data taksi baru telah dimasukkan ke basis data.

83 Tabel 3.26. Aliran Use Case Add New Taxi Flow Actor Action System Response Normal Step 1. Administrator menekan Step 2. Aplikasi menampilkan dialog tombol ADD NEW di antarmuka aplikasi. Step 3. Administrator mengisi data taksi baru dan menekan untuk memasukkan data taksi baru. Step 4. Aplikasi memasukkan data taksi baru ke basis data. tombol OK Alternate ALT Step 3. Administrator dapat menekan CANCEL membatalkan untuk penambahan data taksi baru. Tabel 3.27. Deskripsi Use Case View Taxi List Name Actors Description View Taxi List Administrator Use case menggambarkan bagaimana aplikasi menampilkan data taksi dari basis data. Precondition Postcondition Aplikasi terhubung dengan basis data. Daftar seluruh taksi tampil di layar.

84 Tabel 3.28. Aliran Use Case View Taxi List Flow Actor Action System Response 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 Actors Update Taxi Info Administrator Description Use case menggambarkan bagaimana Administrator mengubah data taksi tertentu Precondition Aplikasi terhubung dengan basis data Aplikasi menyimpan dan menampilkan daftar taksi yang ada Postcondition Data taksi terpilih telah diubah di basis data Data taksi terpilih ditampilkan

85 Tabel 3.30. Aliran Use Case Update Taxi Info Flow Actor Action System Response 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 Step 2. Aplikasi menampilkan dialog untuk mengubah data taksi. Step 4. Aplikasi mengubah data taksi terpilih di basis data dan menampilkan data yang baru. menekan OK Alternate ALT Step 3. Administrator dapat menekan CANCEL untuk membatalkan pengubahan. Tabel 3.31. Deskripsi Use Case Delete Taxi Name Actors Delete Taxi Administrator 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.

86 Tabel 3.32. Aliran Use Case Delete Taxi Flow Actor Action System Response Normal Step 1. Administrator memilih salah satu taksi dari daftar taksi dan Step 2. Aplikasi menghapus data taksi terpilih di basis data. menekan tombol DELETE. Alternate - - Tabel 3.33. Deskripsi Use Case View Taxi Info Name Actors Description View Taxi Info Administrator 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.

87 Tabel 3.34. Aliran Use Case View Taxi Info Flow Actor Action System Response 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 Actors Description View Customers List Administrator Use case menggambarkan bagaimana aplikasi melihat daftar pelanggan. Precondition Postcondition Aplikasi terhubung dengan basis data. Daftar pelanggan ditampilkan.

88 Tabel 3.36. Aliran Use Case View Customers List Flow Actor Action System Response Normal Step 1. Administrator menekan Step 2. Aplikasi mengambil daftar tombol SHOW ALL CUSTOMERS. pelanggan dari basis data dan menampilkannya. Alternate - - Tabel 3.37. Deskripsi Use Case View Customer Info Name Actors Description View Customer Info Administrator Use case menggambarkan bagaimana administrator melihat informasi pelanggan tertentu. Precondition Postcondition Aplikasi terhubung dengan basis data Data pelanggan terpilih ditampilkan Tabel 3.38. Aliran Use Case View Customer Info Flow Actor Action System Response Normal Step 1. Administrator memilih salah satu pelanggan dari daftar Step 2. Aplikasi menampilkan data pelanggan terpilih pelanggan yang ada

89 Flow Actor Action System Response Alternate - - Tabel 3.39. Deskripsi Use Case View Map Name Actors Description View Map Administrator Use case menggambarkan bagaimana aplikasi menampilkan Precondition - posisi taksi dan pelanggan (bila ada) di peta di layar. Postcondition Indikator posisi taksi dan pelanggan (bila ada) tampil di peta di layar. Tabel 3.40. Aliran Use Case View Map Flow Actor Action System Response 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 Flow Actor Action System Response 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 Set Taxi Availability View Customers List «extends» View Map Login «extends» Taxi Driver Choose Customer Gambar 3.17. Use Case Diagram Subsistem Aplikasi Taksi Tabel 3.41. Deskripsi Use Case Login Name Actors Description Login Taxi Driver (Sopir Taksi) 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. Tabel 3.42. Aliran Use Case Login Flow Actor Action System Response 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 Flow Actor Action System Response Alternate - - Tabel 3.43. Deskripsi Use Case Set Taxi Availability Name Actors Description Set Taxi Availability Taxi Driver (Sopir Taksi) Use case menggambarkan bagaimana sopir taksi dapat mengubah status ketersediaan taksi. Precondition Postcondition Aplikasi taksi terhubung ke web service. Status ketersediaan taksi di basis data berubah. Tampilan tombol pengubah status ketersediaan berubah. Tabel 3.44. Aliran Use Case Set Taxi Availability Flow Actor Action System Response Normal Step 1. Sopir taksi menekan tombol Step 2. Aplikasi menghubungkan diri AVAILABLE UNAVAILABLE. atau dengan web service untuk mengubah status ketersediaan taksi dalam basis data, sesuai dengan tombol yang ditekan sopir taksi. Step 3.

94 Flow Actor Action System Response Aplikasi mengubah status tombol pengubah status ketersediaan. Jika yang ditekan AVAILABLE, maka tombol AVAILABLE tidak bisa ditekan dan tombol UNAVAILABLE bisa Alternate - - ditekan. Begitu pula sebaliknya. Tabel 3.45. Deskripsi Use Case View Customer List Name Actors Description View Customer List Taxi Driver (Sopir Taksi) Use case menggambarkan bagaimana aplikasi menampilkan daftar pelanggan yang tersedia untuk taksi. Precondition Postcondition Aplikasi taksi terhubung ke web service. Aplikasi menyimpan dan menampilkan daftar pelanggan.

95 Tabel 3.46. Aliran Use Case View Customer List Flow Actor Action System Response Normal - Step 1. Aplikasi menghubungkan diri dengan web service dan mengirimkan nomor taksi dan posisi bujur dan lintang taksi. Step 2. Aplikasi meminta web service untuk mengecek ketersediaan pelanggan berada di dekat taksi pada basis data. Jika ada, web service 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