septian_airpanaswebsite/activity-diagram.md

20 KiB

Activity Diagram - Sistem Tiket & Booking Banyu Biru

Daftar Isi

  1. Overview
  2. Activity Diagram 1: Proses Pembelian Tiket
  3. Activity Diagram 2: Proses Verifikasi Pembayaran Tiket
  4. Activity Diagram 3: Proses Booking Tempat
  5. Activity Diagram 4: Proses Verifikasi Tiket dengan QR Code
  6. Activity Diagram 5: Proses Login
  7. 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

  1. User - Pengguna yang membeli tiket
  2. System - Sistem aplikasi
  3. 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

  1. Login berhasil? - Validasi email dan password
  2. Tanggal valid? - Cek apakah tanggal >= hari ini
  3. 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

  1. Admin - Administrator yang memverifikasi
  2. System - Sistem aplikasi
  3. 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

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

  1. User - Pengguna yang booking
  2. 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

  1. Login berhasil? - Validasi kredensial
  2. Tanggal tersedia? - Cek di database apakah sudah dibooking
  3. Tanggal >= hari ini? - Validasi tanggal tidak boleh masa lalu
  4. Data valid? - Validasi form input
  5. 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

  1. Admin/Petugas - Petugas di pintu masuk
  2. System - Sistem aplikasi
  3. 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

  1. Metode verifikasi? - Scan QR atau input manual
  2. Tiket ditemukan? - Cek keberadaan kode di database
  3. Order sudah dikonfirmasi? - Cek status pembayaran
  4. Tiket sudah dipakai? - Cek status penggunaan
  5. 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

  1. User/Admin - Pengguna yang login
  2. System - Sistem aplikasi
  3. 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

  1. Format email valid? - Validasi format email
  2. Password terisi? - Validasi password tidak kosong
  3. User ditemukan? - Cek keberadaan email di database
  4. Password cocok? - Verifikasi hash password
  5. 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

  1. Buka draw.io
  2. Pilih "Blank Diagram"
  3. Aktifkan library "UML" dari menu More Shapes
  4. Set ukuran canvas: A4 Portrait atau Landscape

Langkah 2: Buat Swimlanes

  1. Drag "Swimlane" dari library UML
  2. Buat 2-3 swimlanes sesuai kebutuhan:
    • Vertical Swimlanes untuk actor yang berbeda
    • Contoh: User | System | Admin
  3. Beri label pada setiap swimlane
  4. Atur lebar swimlane agar proporsional

Langkah 3: Tambahkan Initial Node

  1. Drag "Initial Node" (lingkaran hitam penuh)
  2. Letakkan di bagian atas swimlane pertama
  3. Ini adalah titik awal aktivitas

Langkah 4: Tambahkan Activities

  1. Drag "Activity" (rounded rectangle) dari library
  2. Buat activity untuk setiap langkah:
    • Gunakan verb + object (contoh: "Pilih tanggal", "Validasi data")
    • Letakkan di swimlane yang sesuai
  3. Hubungkan dengan arrow (Control Flow)

Langkah 5: Tambahkan Decision Nodes

  1. Drag "Decision" (diamond/rhombus)
  2. Gunakan untuk percabangan kondisi
  3. Beri label kondisi pada setiap arrow keluar:
    • [YES] atau [NO]
    • [Valid] atau [Invalid]
  4. Merge kembali dengan "Merge Node" jika perlu

Langkah 6: Tambahkan Fork/Join (Opsional)

  1. Drag "Fork" (horizontal bar) untuk aktivitas paralel
  2. Gunakan "Join" untuk menggabungkan kembali
  3. Contoh: Generate QR code untuk multiple tiket secara bersamaan

Langkah 7: Tambahkan Final Node

  1. Drag "Final Node" (lingkaran dengan lingkaran dalam)
  2. Letakkan di akhir alur
  3. Bisa ada multiple final nodes untuk berbagai ending

Langkah 8: Hubungkan dengan Control Flow

  1. Gunakan arrow untuk menghubungkan nodes
  2. Pastikan arah flow jelas (top to bottom)
  3. 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

  1. Konsistensi:

    • Gunakan ukuran yang sama untuk semua activity nodes
    • Gunakan spacing yang konsisten
    • Align nodes menggunakan grid
  2. Clarity:

    • Gunakan label yang jelas dan singkat
    • Hindari terlalu banyak crossing lines
    • Gunakan warna untuk membedakan jenis aktivitas
  3. Flow Direction:

    • Utamakan top-to-bottom flow
    • Gunakan left-to-right untuk swimlanes
    • Loop back dengan arrow yang jelas
  4. Decision Nodes:

    • Selalu beri label pada setiap branch
    • Gunakan [YES]/[NO] atau [Valid]/[Invalid]
    • Pastikan semua branch memiliki ending
  5. 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

  1. Proses Pembelian Tiket - 3 swimlanes, ~25 activities
  2. Proses Verifikasi Pembayaran Tiket - 3 swimlanes, ~15 activities
  3. Proses Booking Tempat - 2 swimlanes, ~30 activities
  4. Proses Verifikasi Tiket dengan QR Code - 3 swimlanes, ~25 activities
  5. 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