Platform berbagi kendaraan seperti Uber, Lyft, dan Bolt telah merevolusi mobilitas perkotaan dengan menghubungkan penumpang dengan pengemudi terdekat secara real time. Di inti dari pengalaman ini terdapat interaksi kompleks dan dinamis antara berbagai layanan — mulai daripencocokan lokasidanpelacakan real time, hinggalogika penerimaan pengemudi, notifikasi, danpenanganan kegagalan.

Artikel ini menyajikanstudi kasus komprehensifdariproses pemesanan aplikasi berbagi kendaraan, yang dimodelkan menggunakanUML Diagram Urutan. Kami akan membahas seluruh siklus hidup permintaan penumpang untuk naik kendaraan — dari input hingga konfirmasi — termasukpencocokan pengemudi, penanganan waktu habis, notifikasi asinkron, danlogika pengulangan.
Untuk membuat ini praktis dan langsung dapat digunakan, kami menyediakanpotongan kode PlantUML yang telah diperbaiki sepenuhnya, sah, dan siap produksiyang menghasilkan diagram urutan yang bersih dan sesuai standar.
Seorang penumpang terdaftar membuka aplikasi seluler, memasukkan lokasi penjemputan dan tujuan, memilih jenis perjalanan (misalnya, ekonomi, premium), dan meminta perjalanan. Sistem melakukan hal berikut:
Memperkirakan tarif dan perkiraan waktu kedatangan (ETA)menggunakan rute waktu nyata melaluiMapsService.
Mencari pengemudi tersedia di dekatnyadalam jarak tertentu (dengan batas waktu).
Mengirim permintaan perjalananke pengemudi yang paling sesuai.
Menunggupenerimaan atau penolakan pengemudi (dengan batas waktu 30 detik).
Jika diterima:
Menetapkan perjalanan.
Memberi tahu penumpang dan pengemudi.
Memulai pelacakan waktu nyata.
Jika tidak ada pengemudi yang menerima dalam waktu yang ditentukan:
Menandai permintaan sebagai gagal.
Menawarkan pengulangan atau pembatalan.
Ini mencerminkan perilaku dunia nyata aplikasi berbagi perjalanan:pencocokan dinamis, respon asinkron, danketahanan terhadap skenario tanpa penerimaan.
| Konsep | Peran dalam Diagram Ini |
|---|---|
| Garis Kehidupan | Garis putus-putus vertikal untuk setiap peserta (misalnya, Penumpang, Layanan Perjalanan, Pengemudi) |
Pesan Sinkron (->) |
Panggilan langsung (misalnya, RS -> DM: findNearestDrivers) |
Pesan Asinkron (-->) |
Tidak memblokir atau balasan (misalnya, NS --> Pengemudi: Pemberitahuan dorong) |
| Batang Aktivasi | Menunjukkan durasi pemrosesan (aktifkan / nonaktifkan) |
| Fragment Alternatif | Kondisional: alt Driver Menerima vs selain itu Timeout/Penolakan |
| Fragment Opsional | Alur opsional (misalnya, pemilihan perjalanan premium) |
| Fragment Loop | Mengulang pencarian pada beberapa pengemudi (loop Cari pengemudi yang tersedia) |
| Fragment Referensi | Referensi ke urutan sub (misalnya startTrackingSession) |
Aktor (Penumpang, Pengemudi) |
Pengguna eksternal yang memulai tindakan |
Layanan Eksternal (<<eksternal>>) |
MapsService, NotificationService |
| Perkembangan Waktu | Dari atas ke bawah — alur logis waktu |
| Peserta | Peran |
|---|---|
Penumpang |
Aktor yang memulai permintaan perjalanan |
Aplikasi Seluler |
Antarmuka frontend yang menangani input dan tampilan |
Layanan Perjalanan |
Layanan backend inti yang mengelola siklus hidup perjalanan |
Layanan Pencocokan Pengemudi |
Mencocokkan penumpang dengan pengemudi terdekat |
Layanan Peta |
Layanan eksternal untuk rute, tarif, dan perkiraan waktu kedatangan (<<eksternal>>) |
Layanan Pemberitahuan |
Mengirim notifikasi/pesan teks/email ke pengemudi dan penumpang (<<eksternal>>) |
Pengemudi |
Aktor (aplikasi pengemudi) yang merespons permintaan perjalanan |
@startuml
title Aplikasi Berbagi Perjalanan - Diagram Urutan Pemesanan Perjalanan
skinparam monochrome true
skinparam shadowing false
skinparam sequenceMessageAlign center
autonumber "<b>[0]"
aktor Penumpang
partisipan "Aplikasi Seluler" sebagai App
partisipan "Layanan Perjalanan" sebagai RS
partisipan "Layanan Pencocokan Pengemudi" sebagai DM
partisipan "Layanan Peta" sebagai Maps <<eksternal>>
partisipan "Layanan Pemberitahuan" sebagai NS <<eksternal>>
aktor Pengemudi
Penumpang -> App: Buka aplikasi & masukkan lokasi penjemputan/tujuan
aktifkan App
App -> RS: requestRide(lokasiPenjemputan, lokasiTujuan, jenisPerjalanan)
aktifkan RS
RS -> Maps: calculateFareAndETA(lokasiPenjemputan, lokasiTujuan, jenisPerjalanan)
aktifkan Maps
Maps --> RS: perkiraanTarif, menitETA, rute
tidak aktifkan Maps
RS --> App: display(tarif, ETA, konfirmasi?)
App --> Penumpang: Tampilkan tarif & ETA, minta konfirmasi
alt Penumpang mengonfirmasi perjalanan
Penumpang -> App: confirmRide()
App -> RS: confirmAndMatch()
aktifkan RS
loop Cari pengemudi tersedia (timeout 30 detik)
RS -> DM: findNearestDrivers(lokasiPenjemputan, jenisPerjalanan, jarakMaks)
aktifkan DM
DM --> RS: daftarPengemudiTersedia
tidak aktifkan DM
alt Pengemudi Ditemukan
RS -> NS: sendRideRequestToDriver(idPengemudi, lokasiPenjemputan, tarif)
aktifkan NS
NS --> Pengemudi: Notifikasi push "Permintaan perjalanan baru"
NS --> RS: permintaanDikirim
alt Pengemudi Menerima
Pengemudi -> NS: acceptRide()
NS --> RS: driverResponse(terima)
hentikan Cocok berhasil
else Pengemudi Menolak atau Waktu Habis
catatan di kanan RS: Lanjut ke pengemudi berikutnya atau gagal
hentikan Tidak ada penerimaan
akhir
RS -> Maps: startTrackingSession(idPerjalanan)
aktifkan Maps
Maps --> RS: idPelacakan, pembaruanPeta
tidak aktifkan Maps
RS -> NS: notifyPassenger("Pengemudi ditugaskan", infoPengemudi, ETA)
NS --> Penumpang: Push "Pengemudi dalam perjalanan"
RS -> NS: notifyDriver("Perjalanan dikonfirmasi", infoPenumpang)
NS --> Pengemudi: Push "Perjalanan diterima"
RS --> App: rideMatched(infoPengemudi, kendaraan, ETA)
App --> Penumpang: Tampilkan detail pengemudi & peta
else Tidak Ada Pengemudi Tersedia
RS --> App: noDrivers("Tidak ada pengemudi di dekat sini. Coba lagi?")
hentikan Tidak ada pengemudi
akhir
akhir
alt Cocok berhasil
RS --> App: bookingConfirmed(idPerjalanan)
App --> Penumpang: Tampilkan "Perjalanan dipesan!" + pelacakan
else Tidak Ada Penerimaan Setelah Percobaan
RS --> App: requestFailed("Tidak ada pengemudi tersedia. Coba lagi?")
App --> Penumpang: Tampilkan kesalahan & opsi coba lagi
akhir
tidak aktifkan RS
selain Penumpang membatalkan
App --> Penumpang: Dibatalkan
akhir
tidak aktifkan App
@enduml
✅ Tidak ada kembali pernyataan — diganti dengan hentikan dan alur yang tepat.
✅ Semua aktifkan/nonaktifkan pasangan telah ditutup dengan benar.
✅ alt/loop/opt telah ditempatkan dengan benar dan diakhiri.
✅ ref fragmen diimplikasikan melaluistartTrackingSession (dapat diekstrak sebagai bagian diagram).
✅ <<eksternal>> stereotip digunakan untuk kejelasan.
✅ Uji sekarang: Tempelkan ke dalamhttps://www.plantuml.com/plantuml → Klik “Hasilkan” → Lihat tampilan alur lengkap secara instan.
Pergi ke PlantUML Live
Tempel kode → Klik “Hasilkan”
✅ Diagram urutan visual instan
💡 Tips Pro: Tambahkan
skinparam backgroundColor #F8F8F8untuk latar belakang putih yang bersih.
Buka Visual Paradigm Desktop atau VP Online
Buat yang baru Diagram Urutan
Gunakan Alat > Impor > PlantUML → Tempel kode
Menghasilkan otomatis dengan garis kehidupan, pesan, dan batang aktivasi
Gunakan chat.visual-paradigm.com untuk meminta:
“Refaktor urutan berbagi perjalanan ini menjadi arsitektur mikroservis: pisahkan RideService, MatchingService, NotificationService, dan PaymentService. Tambahkan langkah pembayaran opsional setelah pertandingan.”
VP AI akan:
Pisahkan RideService menjadi RideController, RideService, PaymentService
Tambahkan PaymentService dengan processPayment() panggil
Tambahkan <<eksternal>> untuk PaymentGateway
Tambahkan ops untuk pembaruan opsional ke versi premium
Masuk ke online.visual-paradigm.com
Buka OpenDocs → Buat halaman baru: “Spesifikasi Alur Pemesanan Perjalanan”
Sisipkan diagram.
Tambahkan:
Prasyarat: “Pengguna harus masuk, GPS harus aktif”
Pasca kondisi: “Perjalanan cocok, pelacakan aktif, pengemudi telah diberi tahu”
Pengecualian: “Tidak ada pengemudi yang menerima dalam 30 detik”, “GPS tidak tersedia”
Tautan: Untuk Diagram Kasus Pengguna, Diagram Kelas, Mesin Status
| Manfaat | Penjelasan |
|---|---|
| Prototipe Cepat | Tulis UML dalam hitungan detik dengan PlantUML |
| Penyempurnaan Berbasis AI | Refaktor menjadi layanan mikro atau arsitektur berlapis |
| Ramah Kontrol Versi | Simpan kode di Git — tanpa file biner |
| Dapat Diperluas | Perluas dengan jenis perjalanan, promosi, perjalanan kelompok |
| Kompatibel dengan Berbagai Alat | Bekerja di VS Code, Confluence, GitHub, dll. |
Ingin melangkah lebih jauh? Berikut adalah ekstensi umum:
opt Jenis Perjalanan: Premium
RS -> Aplikasi: tampilkanPilihanPremium()
Aplikasi --> RS: pilihPremium()
RS -> Peta: hitungUlangTarifDenganSurge()
Peta --> RS: tarifBaru, etaDiperbarui
akhir
RS -> LayananPembayaran: prosesPembayaran(idPerjalanan, jumlah)
aktifkan LayananPembayaran
LayananPembayaran --> RS: berhasil, idTransaksi
tidak aktifkan LayananPembayaran
RS --> Aplikasi: tampilkanKonfirmasiPembayaran()
Pengemudi -> NS: batalkanPerjalanan(alasan)
NS --> RS: pengemudiDibatalkan
RS -> Aplikasi: notifikasiPenumpang("Pengemudi membatalkan. Mencari pengemudi baru...")
Beritahu saya jika Anda ingin variasi ini dalam bentuk kode PlantUML lengkap!
Proses pemesanan berbagi perjalanan bukan hanya tentang pencocokan — itu tentang koordinasi real-time, komunikasi asinkron, dan ketahanan di bawah ketidakpastian. Dengan memodelkannya menggunakan Diagram Urutan UML dan memanfaatkan PlantUML + alat AI seperti Visual Paradigm, tim dapat:
Desain dengan kejelasan dan ketepatan
Tangkap kasus tepi sejak dini (misalnya, tidak ada pengemudi, waktu habis)
Berkolaborasi lintas produk, rekayasa, dan QA
Dokumentasikan alur untuk audit, onboarding, dan pelatihan
✅ Mulai sekarang: Tempel kode PlantUML di atas ke dalam PlantUML Live dan lihat alur berbagi kendaraan Anda hidup dalam hitungan detik.
Gunakan autonumber untuk pelacakan.
Tambahkan hide footbox untuk menghapus kaki halaman.
Sesuaikan warna: skinparam sequenceMessageBackgroundColor #E0F7FA
Ekspor sebagai PNG/SVG/PDF untuk laporan atau presentasi.
📬 Butuh bantuan?
Ingin versi dengan diagram kelas, mesin keadaan, atau integrasi dengan backend Spring Boot/Node.js?
Cukup minta — saya akan membuat model arsitektur lengkap untuk Anda.
✨ Model dengan presisi. Bangun dengan cepat. Kirim dengan keyakinan.