Panduan Lengkap Membuat Diagram Penempatan UML untuk Sistem Pemesanan Makanan Online Sederhana

1. Tujuan Diagram Penempatan UML

Sebuah Diagram Penempatan menunjukkan arsitektur fisik/runtime dari suatu sistem:

  • Node perangkat keras (server, perangkat, instans cloud)
  • Artifak perangkat lunak yang ditempatkan di node-node tersebut
  • Lingkungan eksekusi (wadah, runtime)
  • Jalur komunikasi antar node (protokol, koneksi)

Untuk sebuah Sistem Pemesanan Makanan Online Sederhana, memvisualisasikan bagaimana:

  • Antarmuka web pelanggan dan restoran disajikan
  • Logika bisnis berjalan
  • Data disimpan
  • Layanan eksternal (pembayaran, notifikasi) terintegrasi

Ini membantu pengembang, DevOps, dan pemangku kepentingan memahami topologi penempatan, titik skalabilitas, batas keamanan, dan ketergantungan.

2. Elemen UML Kunci dalam Diagram Penempatan

Elemen Notasi UML (PlantUML) Arti / Kapan Digunakan Contoh stereotip
Node node “Nama” Sumber daya komputasi (fisik atau virtual) yang dapat menampung artefak <<perangkat>>, <<awan>>
Perangkat node “Nama” <<perangkat>> Perangkat keras fisik atau virtual (server, ponsel, router) <<perangkat>>, <<server>>
Lingkungan Eksekusi node “Nama” <<lingkungan eksekusi>> Runtime perangkat lunak/kontainer (Tomcat, Node.js, Docker, JVM) <<lingkungan eksekusi>>, <<kontainer>>
Artifak artifak “filename.war” Unit yang dapat di-deploy (eksekusi, .jar, bundel .js, skema basis data, berkas konfigurasi) <<eksekusi>>, <<berkas>>, <<basis data>>
Komponen komponen “Nama” Unit perangkat lunak logis (opsional dalam diagram penempatan; sering direalisasikan oleh artifak) <<web>>, <<layanan>>
Jalur Komunikasi –, –>, ..> Koneksi jaringan antar node (dapat memiliki label protokol) HTTP/HTTPS, WebSocket, RMI
Ketergantungan / Pemanggilan ..>, –> Penggunaan/ketergantungan (contoh: frontend memanggil backend) <<panggil>>, <<akses>>
Manifestasi / Realisasi ..> dengan <<realisasi>> atau ..> Artifak merealisasikan / dideploy sebagai komponen <<realisasi>>, <<manifestasi>>
Sistem eksternal node “Nama” <<eksternal>> Layanan pihak ketiga di luar kendali Anda <<eksternal>>, <<SaaS>>

3. Praktik Terbaik untuk Diagram Penempatan (terutama untuk sistem web)

  • Jaga agar tetap sederhana & mudah dibaca — hindari kepadatan; satu diagram per lingkungan utama (dev/staging/prod opsional)
  • Gunakan pengelompokan node yang bermaknapengelompokan node (tempatkan node di dalam node) untuk menunjukkan kluster/daerah cloud
  • Lebih baik menggunakannotasi ringkas — tampilkan nama file/konfigurasi hanya jika relevan; lewati stereotip yang berulang
  • Tampilkan dengan jelasbatas-batas — cloud internal vs layanan eksternal
  • Labelprotokol pada jalur (HTTP/HTTPS, WebSocket, TCP, dll.)
  • Gunakanarah kiri ke kanan untuk sistem web (aliran klien → server → DB terasa alami)
  • Bedakanperangkat (perangkat keras) vs lingkungan eksekusi (runtime)
  • Tampilkanrealisasi hanya jika menambah nilai (artefak → komponen)
  • Gunakanskinparam di PlantUML untuk warna yang lebih baik/kemudahan baca
  • Untuk sistem kecil/medium: maksimal 4–8 node

4. Struktur yang Direkomendasikan untuk Sistem Pemesanan Makanan Online Sederhana

Tata letak yang bersih dan modern untuk sistem ini:

  • Sisi klien → Browser (implisit) berbicara dengan Server Web/CDN
  • Server Web/CDN menampung artefak statis + SPA untuk situs pelanggan dan panel restoran
  • Server API (lingkungan eksekusi) menjalankan logika backend
  • Server Basis Data menampung PostgreSQL
  • Eksternal Layanan Pembayaran & Pemberitahuan

Node-node umum:

  1. Server Web / CDN <<perangkat>>
  2. Server API <<lingkungan eksekusi>>
  3. Server Basis Data <<lingkungan eksekusi>>
  4. Gerbang Pembayaran <<eksternal>>
  5. Layanan Pemberitahuan <<eksternal>>

5. Diagram yang Dibuat oleh Chatbot AI Visual Paradigm

Kode PlantUML yang Diperbaiki & Dibersihkan (dengan penjelasan)

@startuml

title Sistem Pemesanan Makanan Online Sederhana - Diagram Deplesi

arah kiri ke kanan

skinparam {
WarnaPanah #424242
WarnaFontPanah #424242
UkuranFontDefault 14
bayangan false
WarnaLatarStereotipC #ADD1B2
WarnaLatarStereotipI #ADD1B2
}

' ── Node ────────────────────────────────────────────────

node "Server Web / CDN" <<perangkat>> sebagai WebServer {
[Website Pelanggan HTML/JS/CSS] #..# (SPA Pelanggan)
[Panel Admin Restoran HTML/JS/CSS] #..# (SPA Restoran)
}

node "Backend Awan" <<perangkat>> sebagai Cloud {
node "Server API" <<lingkungan eksekusi>> sebagai APIServer {
artefak "backend-api.jar / main.exe" sebagai BackendArtifact
}

node "Server PostgreSQL" <<lingkungan eksekusi>> sebagai DBServer {
database "Basis Data PostgreSQL" sebagai Postgres <<basis data>>
}
}

node "Gerbang Pembayaran" <<eksternal>> sebagai Payment {
[API Pembayaran] sebagai PaymentAPI
}

node "Layanan Pemberitahuan" <<eksternal>> sebagai Notification {
[WebSocket / API Push] sebagai NotifyAPI
}

' ── Hubungan ─────────────────────────────────────────

WebServer --> Cloud : HTTPS (panggilan API)

Cloud --> Payment : HTTPS (checkout)

Cloud --> Notification : WebSocket / HTTPS (pembaruan status)

' Artefak → realisasi komponen (opsional tetapi jelas)
(SPA Pelanggan) ..> BackendArtifact : <<memanggil>>
(SPA Restoran) ..> BackendArtifact : <<memanggil>>

BackendArtifact --> Postgres : <<JDBC / SQL>>

BackendArtifact --> PaymentAPI : <<panggilan HTTPS>>

BackendArtifact --> NotifyAPI : <<WebSocket / HTTPS>>

' Opsional: tampilkan protokol pada DB jika diinginkan
' BackendArtifact -kanan-> Postgres : <<JDBC>>

catatan kanan dari Cloud
Konfigurasi kecil/medium umum:
• VM tunggal atau kluster kecil
• API + DB bisa berada di mesin yang sama (untuk kesederhanaan)
atau terpisah untuk skalabilitas yang lebih baik
akhir catatan

@enduml

6. Langkah demi Langkah: Cara Membuat Diagram Deplesi Anda Sendiri

  1. Daftar semua target eksekusi (server, container, layanan eksternal)
  2. Daftar artefak yang dapat dideploy (apa yang benar-benar berjalan: bundel .js, .jar, database)
  3. Kelompokkan menjadi node (kelompokkan jika logis — misalnya API + DB dalam satu node cloud)
  4. Tentukan arah (kiri ke kanan bekerja dengan baik untuk web → API → DB)
  5. Tambahkan jalur komunikasi dengan label protokol
  6. Tambahkan ketergantungan utama (<<memanggil>>, <<mengakses>>)
  7. Terapkan skinparam untuk warna/kenyamanan membaca
  8. Tambahkan catatan untuk keputusan penting (single vs multi-instance, catatan peningkatan skala)
  9. Validasi: Apakah seorang insinyur DevOps dapat memahami di mana setiap bagian harus dideploy?

Ringkasan – Referensi Cepat untuk Penyebaran Pemesanan Makanan Sederhana

Bagian Jenis Node Umum Contoh Artefak Terhubung melalui
Antarmuka Pelanggan Server Web / CDN <<perangkat>> Bundel SPA (HTML/JS) HTTPS → API
Dasbor Restoran Server Web / CDN <<perangkat>> Bundel SPA Admin HTTPS → API
Logika Bisnis Server API <<executionEnv>> backend-api.jar / eksekutable JDBC → DB, HTTPS → eksternal
Penyimpanan Data PostgreSQL <<executionEnv>> File data PostgreSQL + skema
Pembayaran Eksternal <<SaaS>> Titik akhir API pembayaran HTTPS
Pembaruan Real-time Eksternal <<SaaS>> WebSocket / FCM / APNs WebSocket / HTTPS

Struktur ini realistis untuk pengembangan MVP / skala kecil-menengah (1–3 server + database awan + Stripe/PayPal + Firebase/Pusher).

Silakan sesuaikan penetapan, protokol, atau tambahkan catatan skalabilitas (misalnya, load balancer, replika) saat sistem berkembang.

🔗 Daftar Referensi