20 KiB
Activity Diagram - Sistem Tiket & Booking Banyu Biru
Daftar Isi
- Overview
- Activity Diagram 1: Proses Pembelian Tiket
- Activity Diagram 2: Proses Verifikasi Pembayaran Tiket
- Activity Diagram 3: Proses Booking Tempat
- Activity Diagram 4: Proses Verifikasi Tiket dengan QR Code
- Activity Diagram 5: Proses Login
- Panduan Membuat Diagram di Draw.io
Overview
Activity diagram menggambarkan alur aktivitas dalam sistem dari awal hingga akhir. Dokumen ini menyediakan 5 activity diagram utama yang mencakup proses bisnis penting dalam sistem.
Notasi yang Digunakan:
- Initial Node (●): Titik awal aktivitas
- Activity (Rounded Rectangle): Aktivitas/aksi yang dilakukan
- Decision (◇): Percabangan keputusan
- Fork/Join (Bar): Aktivitas paralel
- Final Node (◎): Titik akhir aktivitas
- Swimlane: Pembagian tanggung jawab (User, System, Admin)
Activity Diagram 1: Proses Pembelian Tiket
Deskripsi
Menggambarkan alur lengkap pembelian tiket dari user mulai dari memilih tiket hingga upload bukti pembayaran.
Swimlanes
- User - Pengguna yang membeli tiket
- System - Sistem aplikasi
- Payment Gateway - Sistem pembayaran (eksternal)
Alur Aktivitas
[START]
│
├─ User: Login ke sistem
│
├─ System: Validasi kredensial
│
├─ Decision: Login berhasil?
│ ├─ [NO] → Tampilkan error → [END]
│ └─ [YES] ↓
│
├─ System: Tampilkan halaman pembelian tiket
│
├─ User: Pilih tanggal kunjungan
│
├─ System: Validasi tanggal
│
├─ Decision: Tanggal valid?
│ ├─ [NO] → Tampilkan error tanggal → Kembali ke pilih tanggal
│ └─ [YES] ↓
│
├─ User: Pilih jenis tiket
│
├─ User: Tentukan jumlah tiket
│
├─ System: Hitung total harga
│
├─ System: Tampilkan ringkasan pesanan
│
├─ User: Konfirmasi pesanan
│
├─ System: Generate kode order unik (AT-XXXXX)
│
├─ System: Generate QR code untuk setiap tiket
│
├─ System: Simpan data order dengan status "pending"
│
├─ System: Tampilkan halaman pembayaran
│
├─ System: Tampilkan nomor rekening bank
│
├─ User: Melakukan transfer ke rekening
│
├─ User: Upload bukti pembayaran
│
├─ System: Validasi file bukti pembayaran
│
├─ Decision: File valid?
│ ├─ [NO] → Tampilkan error format → Kembali ke upload
│ └─ [YES] ↓
│
├─ System: Simpan bukti pembayaran
│
├─ System: Update status order tetap "pending"
│
├─ System: Tampilkan halaman download tiket
│
├─ System: Tampilkan pesan "Menunggu verifikasi admin"
│
└─ [END]
Decision Points
- Login berhasil? - Validasi email dan password
- Tanggal valid? - Cek apakah tanggal >= hari ini
- File valid? - Cek format dan ukuran file
Catatan
- QR code di-generate untuk setiap item tiket
- User bisa download tiket tapi tombol disabled sampai dikonfirmasi
- Status order: pending → menunggu verifikasi admin
Activity Diagram 2: Proses Verifikasi Pembayaran Tiket
Deskripsi
Menggambarkan alur verifikasi pembayaran tiket oleh admin.
Swimlanes
- Admin - Administrator yang memverifikasi
- System - Sistem aplikasi
- User - Pemilik tiket (menerima notifikasi)
Alur Aktivitas
[START]
│
├─ Admin: Login ke dashboard admin
│
├─ System: Tampilkan dashboard
│
├─ Admin: Akses menu "Pesanan Tiket"
│
├─ System: Tampilkan daftar pesanan tiket
│
├─ System: Tampilkan filter status (pending/confirmed/rejected)
│
├─ Admin: Filter pesanan dengan status "pending"
│
├─ System: Tampilkan pesanan pending
│
├─ Admin: Pilih pesanan yang akan diverifikasi
│
├─ System: Tampilkan detail pesanan
│
├─ System: Tampilkan bukti pembayaran
│
├─ System: Tampilkan data user dan tiket
│
├─ Admin: Periksa bukti pembayaran
│
├─ Admin: Periksa kesesuaian nominal
│
├─ Decision: Pembayaran valid?
│ │
│ ├─ [YES] → Admin: Klik tombol "Konfirmasi"
│ │ │
│ │ ├─ System: Update status order menjadi "confirmed"
│ │ │
│ │ ├─ System: Simpan waktu konfirmasi (confirmed_at)
│ │ │
│ │ ├─ System: Simpan ID admin yang konfirmasi (confirmed_by)
│ │ │
│ │ ├─ System: Hitung ke total pendapatan
│ │ │
│ │ ├─ System: Aktifkan tombol download tiket untuk user
│ │ │
│ │ ├─ System: Tampilkan notifikasi sukses
│ │ │
│ │ └─ [END]
│ │
│ └─ [NO] → Admin: Klik tombol "Tolak"
│ │
│ ├─ System: Tampilkan form alasan penolakan
│ │
│ ├─ Admin: Isi alasan penolakan
│ │
│ ├─ Admin: Konfirmasi penolakan
│ │
│ ├─ System: Update status order menjadi "rejected"
│ │
│ ├─ System: Simpan alasan penolakan (rejection_note)
│ │
│ ├─ System: Tampilkan notifikasi penolakan
│ │
│ ├─ System: User bisa upload ulang bukti pembayaran
│ │
│ └─ [END]
Decision Points
- Pembayaran valid? - Admin memutuskan berdasarkan bukti transfer
Catatan
- Admin bisa konfirmasi atau tolak pembayaran
- Jika ditolak, user bisa upload ulang bukti
- Hanya pesanan "confirmed" yang masuk ke laporan pendapatan
Activity Diagram 3: Proses Booking Tempat
Deskripsi
Menggambarkan alur booking tempat (pendopo) oleh user.
Swimlanes
- User - Pengguna yang booking
- System - Sistem aplikasi
Alur Aktivitas
[START]
│
├─ User: Login ke sistem
│
├─ System: Validasi kredensial
│
├─ Decision: Login berhasil?
│ ├─ [NO] → Tampilkan error → [END]
│ └─ [YES] ↓
│
├─ System: Tampilkan halaman booking
│
├─ System: Tampilkan informasi tempat (Pendopo)
│
├─ System: Tampilkan harga per hari
│
├─ User: Pilih tanggal booking
│
├─ System: Cek ketersediaan tanggal
│
├─ System: Query database untuk tanggal tersebut
│
├─ Decision: Tanggal tersedia?
│ ├─ [NO] → System: Tampilkan pesan "Tanggal sudah dibooking"
│ │ └─ Kembali ke pilih tanggal
│ └─ [YES] ↓
│
├─ Decision: Tanggal >= hari ini?
│ ├─ [NO] → System: Tampilkan error "Tanggal sudah lewat"
│ │ └─ Kembali ke pilih tanggal
│ └─ [YES] ↓
│
├─ User: Isi nama pengunjung
│
├─ User: Isi nomor telepon
│
├─ User: Isi alamat
│
├─ User: Isi catatan (opsional)
│
├─ System: Validasi data input
│
├─ Decision: Data valid?
│ ├─ [NO] → Tampilkan error validasi → Kembali ke form
│ └─ [YES] ↓
│
├─ System: Hitung total harga
│
├─ System: Tampilkan ringkasan booking
│
├─ User: Konfirmasi booking
│
├─ System: Generate kode booking unik (AB-XXXXX)
│
├─ System: Simpan data booking dengan status "pending"
│
├─ System: Block tanggal untuk booking lain
│
├─ System: Tampilkan halaman pembayaran
│
├─ System: Tampilkan nomor rekening bank
│
├─ User: Melakukan transfer
│
├─ User: Upload bukti pembayaran
│
├─ System: Validasi file
│
├─ Decision: File valid?
│ ├─ [NO] → Tampilkan error → Kembali ke upload
│ └─ [YES] ↓
│
├─ System: Simpan bukti pembayaran
│
├─ System: Tampilkan halaman status booking
│
├─ System: Tampilkan pesan "Menunggu verifikasi admin"
│
└─ [END]
Decision Points
- Login berhasil? - Validasi kredensial
- Tanggal tersedia? - Cek di database apakah sudah dibooking
- Tanggal >= hari ini? - Validasi tanggal tidak boleh masa lalu
- Data valid? - Validasi form input
- File valid? - Validasi bukti pembayaran
Catatan
- Satu tempat hanya bisa dibooking 1x per tanggal
- Tanggal otomatis ter-block setelah booking dibuat
- Status awal selalu "pending"
Activity Diagram 4: Proses Verifikasi Tiket dengan QR Code
Deskripsi
Menggambarkan alur verifikasi tiket menggunakan QR code scanner di pintu masuk.
Swimlanes
- Admin/Petugas - Petugas di pintu masuk
- System - Sistem aplikasi
- User - Pengunjung dengan tiket
Alur Aktivitas
[START]
│
├─ User: Datang ke pintu masuk dengan tiket
│
├─ Admin: Login ke sistem verifikasi
│
├─ System: Tampilkan halaman verifikasi tiket
│
├─ System: Tampilkan pilihan metode verifikasi
│
├─ Decision: Metode verifikasi?
│ │
│ ├─ [Scan QR] → System: Aktifkan kamera
│ │ │
│ │ ├─ System: Tampilkan scanner QR
│ │ │
│ │ ├─ Admin: Arahkan kamera ke QR code tiket
│ │ │
│ │ ├─ System: Baca QR code
│ │ │
│ │ ├─ System: Ekstrak kode tiket dari QR
│ │ │
│ │ └─ [Lanjut ke Validasi]
│ │
│ └─ [Input Manual] → Admin: Ketik kode tiket
│ │
│ ├─ System: Terima input kode
│ │
│ └─ [Lanjut ke Validasi]
│
├─ [Validasi]
│
├─ System: Cari tiket berdasarkan kode
│
├─ Decision: Tiket ditemukan?
│ ├─ [NO] → System: Tampilkan error "Tiket tidak ditemukan"
│ │ └─ [END]
│ └─ [YES] ↓
│
├─ System: Ambil data tiket dari database
│
├─ System: Cek status order tiket
│
├─ Decision: Order sudah dikonfirmasi?
│ ├─ [NO] → System: Tampilkan pesan "Pembayaran belum dikonfirmasi"
│ │ │
│ │ ├─ System: Tampilkan status "Pending"
│ │ │
│ │ └─ [END]
│ └─ [YES] ↓
│
├─ System: Cek status penggunaan tiket
│
├─ Decision: Tiket sudah dipakai?
│ ├─ [YES] → System: Tampilkan peringatan "Tiket sudah digunakan"
│ │ │
│ │ ├─ System: Tampilkan waktu penggunaan
│ │ │
│ │ ├─ System: Tampilkan badge merah "Sudah Dipakai"
│ │ │
│ │ └─ [END]
│ └─ [NO] ↓
│
├─ System: Tampilkan detail tiket
│
├─ System: Tampilkan data pengunjung
│
├─ System: Tampilkan tanggal kunjungan
│
├─ System: Tampilkan badge hijau "Valid"
│
├─ Admin: Verifikasi data pengunjung
│
├─ Decision: Data sesuai?
│ ├─ [NO] → Admin: Tolak masuk
│ │ └─ [END]
│ └─ [YES] ↓
│
├─ Admin: Klik tombol "Tandai Sebagai Dipakai"
│
├─ System: Update field is_used = true
│
├─ System: Simpan waktu penggunaan (used_at)
│
├─ System: Tampilkan notifikasi sukses
│
├─ System: Hide kamera scanner
│
├─ System: Tampilkan tombol "Scan Lagi"
│
├─ Admin: Izinkan pengunjung masuk
│
└─ [END]
Decision Points
- Metode verifikasi? - Scan QR atau input manual
- Tiket ditemukan? - Cek keberadaan kode di database
- Order sudah dikonfirmasi? - Cek status pembayaran
- Tiket sudah dipakai? - Cek status penggunaan
- Data sesuai? - Admin verifikasi manual
Catatan
- Tiket hanya bisa dipakai 1x
- Sistem otomatis hide kamera setelah scan berhasil
- Admin bisa scan lagi dengan klik tombol "Scan Lagi"
Activity Diagram 5: Proses Login
Deskripsi
Menggambarkan alur login user dan admin ke sistem.
Swimlanes
- User/Admin - Pengguna yang login
- System - Sistem aplikasi
- Database - Database sistem
Alur Aktivitas
[START]
│
├─ User: Akses halaman login
│
├─ System: Tampilkan form login
│
├─ User: Masukkan email
│
├─ User: Masukkan password
│
├─ User: Klik tombol "Login"
│
├─ System: Validasi format email
│
├─ Decision: Format email valid?
│ ├─ [NO] → System: Tampilkan error "Format email salah"
│ │ └─ Kembali ke form login
│ └─ [YES] ↓
│
├─ System: Validasi password tidak kosong
│
├─ Decision: Password terisi?
│ ├─ [NO] → System: Tampilkan error "Password wajib diisi"
│ │ └─ Kembali ke form login
│ └─ [YES] ↓
│
├─ System: Query database untuk email
│
├─ Database: Cari user berdasarkan email
│
├─ Decision: User ditemukan?
│ ├─ [NO] → System: Tampilkan error "Email tidak terdaftar"
│ │ └─ Kembali ke form login
│ └─ [YES] ↓
│
├─ System: Ambil data user dari database
│
├─ System: Verifikasi password (hash comparison)
│
├─ Decision: Password cocok?
│ ├─ [NO] → System: Tampilkan error "Password salah"
│ │ └─ Kembali ke form login
│ └─ [YES] ↓
│
├─ System: Buat session untuk user
│
├─ System: Simpan data user ke session
│
├─ System: Cek role user
│
├─ Decision: Role user?
│ │
│ ├─ [Admin] → System: Redirect ke dashboard admin
│ │ │
│ │ ├─ System: Tampilkan statistik
│ │ │
│ │ ├─ System: Tampilkan grafik
│ │ │
│ │ └─ [END]
│ │
│ └─ [User] → System: Redirect ke halaman beranda
│ │
│ ├─ System: Tampilkan menu tiket & booking
│ │
│ ├─ System: Tampilkan dropdown user
│ │
│ └─ [END]
Decision Points
- Format email valid? - Validasi format email
- Password terisi? - Validasi password tidak kosong
- User ditemukan? - Cek keberadaan email di database
- Password cocok? - Verifikasi hash password
- Role user? - Tentukan redirect berdasarkan role
Catatan
- Password di-hash menggunakan bcrypt
- Session disimpan untuk maintain login state
- Redirect berbeda untuk admin dan user
Panduan Membuat Diagram di Draw.io
Langkah 1: Setup Canvas
- Buka draw.io
- Pilih "Blank Diagram"
- Aktifkan library "UML" dari menu More Shapes
- Set ukuran canvas: A4 Portrait atau Landscape
Langkah 2: Buat Swimlanes
- Drag "Swimlane" dari library UML
- Buat 2-3 swimlanes sesuai kebutuhan:
- Vertical Swimlanes untuk actor yang berbeda
- Contoh: User | System | Admin
- Beri label pada setiap swimlane
- Atur lebar swimlane agar proporsional
Langkah 3: Tambahkan Initial Node
- Drag "Initial Node" (lingkaran hitam penuh)
- Letakkan di bagian atas swimlane pertama
- Ini adalah titik awal aktivitas
Langkah 4: Tambahkan Activities
- Drag "Activity" (rounded rectangle) dari library
- Buat activity untuk setiap langkah:
- Gunakan verb + object (contoh: "Pilih tanggal", "Validasi data")
- Letakkan di swimlane yang sesuai
- Hubungkan dengan arrow (Control Flow)
Langkah 5: Tambahkan Decision Nodes
- Drag "Decision" (diamond/rhombus)
- Gunakan untuk percabangan kondisi
- Beri label kondisi pada setiap arrow keluar:
- [YES] atau [NO]
- [Valid] atau [Invalid]
- Merge kembali dengan "Merge Node" jika perlu
Langkah 6: Tambahkan Fork/Join (Opsional)
- Drag "Fork" (horizontal bar) untuk aktivitas paralel
- Gunakan "Join" untuk menggabungkan kembali
- Contoh: Generate QR code untuk multiple tiket secara bersamaan
Langkah 7: Tambahkan Final Node
- Drag "Final Node" (lingkaran dengan lingkaran dalam)
- Letakkan di akhir alur
- Bisa ada multiple final nodes untuk berbagai ending
Langkah 8: Hubungkan dengan Control Flow
- Gunakan arrow untuk menghubungkan nodes
- Pastikan arah flow jelas (top to bottom)
- Hindari crossing lines jika memungkinkan
Tips Styling
Warna Swimlanes
- User/Admin: Biru muda (#E3F2FD)
- System: Hijau muda (#E8F5E9)
- Database: Abu-abu muda (#F5F5F5)
- External: Kuning muda (#FFF9C4)
Warna Activities
- Normal Activity: Putih dengan border hitam
- Important Activity: Hijau teal (#14B8A6)
- Error/Reject: Merah muda (#FFCDD2)
- Success: Hijau muda (#C8E6C9)
Warna Decision
- Decision Node: Kuning (#FFF59D)
- Merge Node: Abu-abu (#E0E0E0)
Font
- Activity Label: Arial, 11pt, Bold
- Decision Label: Arial, 10pt, Italic
- Swimlane Label: Arial, 12pt, Bold
Best Practices
-
Konsistensi:
- Gunakan ukuran yang sama untuk semua activity nodes
- Gunakan spacing yang konsisten
- Align nodes menggunakan grid
-
Clarity:
- Gunakan label yang jelas dan singkat
- Hindari terlalu banyak crossing lines
- Gunakan warna untuk membedakan jenis aktivitas
-
Flow Direction:
- Utamakan top-to-bottom flow
- Gunakan left-to-right untuk swimlanes
- Loop back dengan arrow yang jelas
-
Decision Nodes:
- Selalu beri label pada setiap branch
- Gunakan [YES]/[NO] atau [Valid]/[Invalid]
- Pastikan semua branch memiliki ending
-
Swimlanes:
- Letakkan aktivitas di swimlane yang tepat
- Crossing swimlane menunjukkan interaksi
- Jangan terlalu banyak swimlanes (max 4)
Contoh Layout
┌─────────────┬──────────────┬─────────────┐
│ User │ System │ Admin │
├─────────────┼──────────────┼─────────────┤
│ │ │ │
│ (●) │ │ │
│ │ │ │ │
│ ▼ │ │ │
│ ┌─────┐ │ │ │
│ │Login│────┼──────────────┼────────────▶│
│ └─────┘ │ │ │
│ │ ┌──────┐ │ │
│ │ │Validasi │ │
│ │ └──────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ◇Valid? │ │
│ │ / \ │ │
│ │ NO YES │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │Error Success│ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ (◎) (◎) │ │
└─────────────┴──────────────┴─────────────┘
Checklist Sebelum Finalisasi
- Semua aktivitas memiliki label yang jelas
- Semua decision nodes memiliki label kondisi
- Flow direction konsisten (top-to-bottom)
- Tidak ada aktivitas yang "menggantung" (tanpa input/output)
- Swimlanes sudah sesuai dengan actor
- Warna sudah konsisten
- Initial dan Final nodes sudah ada
- Spacing dan alignment rapi
- Tidak terlalu banyak crossing lines
- Diagram mudah dibaca dan dipahami
Summary
Total Activity Diagrams: 5
- Proses Pembelian Tiket - 3 swimlanes, ~25 activities
- Proses Verifikasi Pembayaran Tiket - 3 swimlanes, ~15 activities
- Proses Booking Tempat - 2 swimlanes, ~30 activities
- Proses Verifikasi Tiket dengan QR Code - 3 swimlanes, ~25 activities
- Proses Login - 3 swimlanes, ~15 activities
Total Activities: ~110 activities Total Decision Points: ~20 decisions Total Swimlanes: 8 (across all diagrams)
Dibuat: 25 Februari 2026
Versi: 1.0
Sistem: Banyu Biru Ticketing & Booking System