\n
![\"Lembar](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195e127973c.png\")
<\/p>\n
Bagian 1: Blok Bangunan (Sintaks & Legenda)<\/h2>\n
Sebelum menyelami studi kasus, kita harus menetapkan kosakata yang digunakan dalam diagram UML.<\/p>\n
1. Struktur Kelas & Visibilitas<\/h3>\n
Sebuah kelas direpresentasikan oleh persegi panjang yang dibagi menjadi tiga kompartemen:<\/p>\n
- \n
- \n
Atas:<\/strong>\u00a0Nama Kelas (misalnya,
PemesananPenerbangan<\/code>).<\/p>\n<\/li>\n- \n
Tengah:<\/strong>\u00a0Properti\/Atribut (misalnya,
+ namaProperti: String<\/code>).<\/p>\n<\/li>\n- \n
Bawah:<\/strong>\u00a0Metode\/Operasi (misalnya,
+ isActive(): boolean<\/code>).<\/p>\n<\/li>\n<\/ul>\nModifikator Visibilitas:<\/strong><\/p>\n
- \n
- \n
+<\/code>\u00a0Publik:<\/strong>Dapat diakses oleh kelas lain manapun.<\/p>\n<\/li>\n- \n
-<\/code>\u00a0Privat:<\/strong>Dapat diakses hanya di dalam kelas tersebut.<\/p>\n<\/li>\n- \n
#<\/code>\u00a0Protected:<\/strong>\u00a0Dapat diakses dalam kelas dan subkelasnya.<\/p>\n<\/li>\n- \n
~<\/code>\u00a0Package:<\/strong>\u00a0Dapat diakses hanya dalam paket yang sama.<\/p>\n<\/li>\n<\/ul>\n2. Jenis Kelas Khusus<\/h3>\n
- \n
- \n
Antarmuka (
<<interface>><\/code>):<\/strong>\u00a0Kontrak yang mendefinisikan metode tanpa implementasi. Diwakili oleh kotak hijau (dalam ringkasan ini) atau notasi standar.<\/p>\n- \n
- \n
Contoh:<\/em>\u00a0
UserRepo<\/code>\u00a0dengan\u00a0+ method(): void<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Kelas Abstrak (
<<abstract>><\/code>):<\/strong>\u00a0Kelas dasar yang tidak dapat diinstansiasi secara langsung. Mereka mungkin berisi metode abstrak.<\/p>\n- \n
- \n
Contoh:<\/em>\u00a0
Component<\/code>\u00a0dengan\u00a0+ render(): void \/\/ abstrak<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Enumerasi:<\/strong>\u00a0Himpunan konstanta bernama.<\/p>\n
- \n
- \n
Contoh:<\/em>\u00a0
JobStatus<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nContoh Diagram Kelas Sistem Pemesanan<\/h2>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195f79a1fa7.png\")
<\/p>\n\u00a0<\/p>\n
@startuml
\nskinparam classAttributeIconSize 0
\nskinparam shadowing false<\/p>\n\u2018 \u2014 ANTARMUKA \u2014
\ninterface PaymentGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 KELAS ABSTRAK \u2014
\nabstract class Order {
\n# orderId: String
\n# totalAmount: double
\n+ {abstract} calculateTax(): double
\n+ getSummary(): String
\n}<\/p>\n\u2018 \u2014 KELAS \u2014
\nclass PhysicalOrder {
\n\u2013 shippingWeight: double
\n+ calculateTax(): double
\n}<\/p>\nclass DigitalOrder {
\n\u2013 downloadLink: String
\n+ calculateTax(): double
\n}<\/p>\nclass OrderItem {
\n\u2013 productName: String
\n\u2013 price: double
\n\u2013 quantity: int
\n}<\/p>\nclass PayPalGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 HUBUNGAN \u2014’
\nOrder <|\u2013 PhysicalOrder
\nOrder <|\u2013 DigitalOrder<\/p>\nOrder *\u2013 \u201c1..*\u201d OrderItem : mengandung
\nOrder ..> PaymentGateway : menggunakan<\/p>\nPaymentGateway <|.. PayPalGateway<\/p>\n
@enduml<\/p>\n
\nBagian 2: Hubungan & Multiplisitas<\/h2>\n
Garis yang menghubungkan kelas mendefinisikan bagaimana mereka berinteraksi.<\/p>\n
1. Jenis Asosiasi<\/h3>\n
- \n
- \n
Pewarisan (Generalisasi):<\/strong>Garis solid dengan segitiga berongga. Hubungan \u201cadalah-a\u201d.<\/p>\n
- \n
- \n
Contoh:<\/em>\u00a0
Mobil<\/code>\u00a0dan\u00a0Sepeda Motor<\/code>\u00a0mewarisi dari\u00a0Kendaraan<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Implementasi:<\/strong>Garis putus-putus dengan segitiga berongga. Sebuah kelas memenuhi kontrak antarmuka.<\/p>\n
- \n
- \n
Contoh:<\/em>\u00a0
Mobil<\/code>\u00a0mengimplementasikan\u00a0Dapat Dikendarai<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Komposisi (Kepemilikan Kuat):<\/strong>Garis solid dengan\u00a0berlian terisi<\/strong>. \u201cBagian\u201d tidak dapat ada tanpa \u201ckeseluruhan.\u201d<\/p>\n
- \n
- \n
Contoh:<\/em>\u00a0
Restoran<\/code> (Keseluruhan) memilikiMenu<\/code> (Bagian). Jika restoran tutup, menu pun hilang.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Agregasi:<\/strong> Garis solid dengan berlian kosong<\/strong>. Hubungan \u201cmemiliki\u201d di mana bagian-bagian dapat ada secara mandiri.<\/p>\n
- \n
- \n
Contoh:<\/em>\u00a0
Pesanan<\/code> mengagregasiRestoran<\/code> (Restoran tetap ada meskipun pesanan dihapus).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Legenda Multiplisitas<\/h3>\n
Angka di ujung garis menunjukkan kardinalitas:<\/p>\n
- \n
- \n
1<\/code>: Tepat satu.<\/p>\n<\/li>\n- \n
0..1<\/code>: Nol atau satu (Opsional).<\/p>\n<\/li>\n- \n
1..*<\/code>: Satu atau lebih (Daftar wajib).<\/p>\n<\/li>\n- \n
*<\/code>: Banyak (Nol atau lebih).<\/p>\n<\/li>\n<\/ul>\nKonsep pewarisan, implementasi, komposisi, dan agregasi Contoh<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a19600180d6b.png\")
<\/p>\n\n@startuml<\/div>\n\u2018 Antarmuka dan Kelas Dasar<\/div>\ninterface Drivable {<\/div>\n+ drive()<\/div>\n}<\/div>\nkelas abstrak Vehicle {<\/div>\n+ startEngine()<\/div>\n}<\/div>\n\u2018 Kelas<\/div>\nclass Car {<\/div>\n}<\/div>\nclass Motorcycle {<\/div>\n}<\/div>\nclass Restaurant {<\/div>\n\u2013 name: String<\/div>\n}<\/div>\nclass Menu {<\/div>\n}<\/div>\nclass Order {<\/div>\n}<\/div>\n\u2018 Relasi<\/div>\n\u2018 1. Pewarisan (Generalisasi)<\/div>\nVehicle <|\u2013 Car<\/div>\nVehicle <|\u2013 Motorcycle<\/div>\n\u2018 2. Implementasi<\/div>\nDrivable <|.. Car<\/div>\n\u2018 3. Komposisi (Kepemilikan Kuat)<\/div>\nRestaurant *\u2013 Menu : memiliki<\/div>\n\u2018 4. Agregasi<\/div>\nOrder o\u2013 Restaurant : melibatkan<\/div>\n\u2018 Contoh Multiplisitas<\/div>\n\u2018 Restaurant memiliki satu atau banyak Menu (1..*)<\/div>\n\u2018 Order melibatkan nol atau satu Restaurant (0..1)<\/div>\nRestaurant \u201c1\u201d *\u2013 \u201c1..*\u201d Menu<\/div>\nPesanan “1” o\u2013 “0..1” Restoran<\/div>\n@enduml<\/div>\n<\/div>\n
\nBagian 3: Studi Kasus Dunia Nyata: Platform Pengiriman Makanan Terpadu<\/h2>\n
Bagian ini menganalisis diagram pusat dari lembar ringkasan, dengan menguraikan arsitektur aplikasi pengiriman makanan.<\/p>\n
1. Hierarki Pengguna (Pewarisan & Komposisi)<\/h3>\n
Sistem dimulai dengan kelas umum Pengguna<\/strong> kelas, ditandai sebagai Abstrak<\/strong>. Ini memastikan tidak ada objek “Pengguna” umum yang dibuat, hanya tipe spesifik.<\/p>\n
- \n
- \n
Pewarisan:<\/strong>\u00a0
Pelanggan<\/code> danPengemudi<\/code> mewarisiPengguna<\/code>.<\/p>\n<\/li>\n- \n
Komposisi:<\/strong><\/p>\n
- \n
- \n
Pelanggan<\/code> memilikiAlamat Pengiriman<\/code> (Kepemilikan Kuat).<\/p>\n<\/li>\n- \n
Pengemudi<\/code> memilikiDetail Kendaraan<\/code> (Kepemilikan Kuat).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Ekosistem Restoran & Menu<\/h3>\n
Bagian ini mendemonstrasikan pengelompokan bersarang dalam dan koleksi.<\/p>\n
- \n
- \n
Implementasi Antarmuka:<\/strong>\u00a0
Restoran<\/code> mengimplementasikan<<interface>> DapatDilokasikan<\/code>, memastikan setiap restoran memiliki data lokasi.<\/p>\n<\/li>\n- \n
Rantai Komposisi:<\/strong><\/p>\n
- \n
- \n
Restoran<\/code> (1) memiliki secara kuatMenu<\/code>\u00a0(1).<\/p>\n<\/li>\n- \n
Menu<\/code> berisiKategoriMenu<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
KategoriMenu<\/code> berisiItemMenu<\/code>\u00a0(*).<\/p>\n<\/li>\n- \n
Catatan:<\/em> Struktur ini memastikan bahwa ItemMenu tidak dapat ada tanpa Kategori, yang tidak dapat ada tanpa Menu.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
3. Pemrosesan Pesanan & Pembayaran<\/h3>\n
- \n
- \n
Struktur Pesanan:<\/strong><\/p>\n
- \n
- \n
Pesanan<\/code> memiliki hubungan denganRestoran<\/code> (Agregasi).<\/p>\n<\/li>\n- \n
Pesanan<\/code> memiliki secara kuatItemBarisPesanan<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Pesanan<\/code> memilikiPembayaran<\/code> (0..1), menunjukkan bahwa pembayaran bersifat opsional selama fase pembuatan awal.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Strategi Pembayaran (Polimorfisme):<\/strong><\/p>\n
- \n
- \n
Sistem menggunakan sebuah antarmuka
<<interface>> PaymentProcessor<\/code>.<\/p>\n<\/li>\n- \n
Kelas konkret
StripeProcessor<\/code> danPayPalProcessor<\/code> mengimplementasikan antarmuka ini. Hal ini memungkinkan sistem untuk beralih gerbang pembayaran tanpa mengubah intiPesanan<\/code> logika.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n4. Kelas Abstrak vs. Antarmuka (Contoh Kendaraan)<\/h3>\n
Bagian kanan atas lembar bantuan mengklarifikasi kebingungan umum:<\/p>\n
- \n
- \n
Kelas Abstrak (
Kendaraan<\/code>):<\/strong>\u00a0Mobil<\/code> danSepeda Motor<\/code> mewarisi dariKendaraan<\/code>. Ini menyiratkan bahwa mereka berbagi data\/struktur inti (misalnya,tipeMesin<\/code>,\u00a0roda<\/code>).<\/p>\n<\/li>\n- \n
Antarmuka (
DapatDikendarai<\/code>):<\/strong>\u00a0Mobil<\/code> mengimplementasikanDapat Dikendarai<\/code>. Ini menyiratkanMobil<\/code> memiliki perilaku spesifik (drive()<\/code>) yangSepeda Motor<\/code> mungkin tidak memilikinya (atau mungkin mengimplementasikannya secara berbeda).<\/p>\n<\/li>\n<\/ul>\n
\nBagian 4: Visualisasi dengan PlantUML<\/h2>\n
Di bawah ini adalah kode PlantUML untuk menghasilkan struktur inti dari “Platform Pengiriman Makanan Terpadu” yang dijelaskan dalam studi kasus. Anda dapat menyalin ini ke editor PlantUML apa pun untuk melihat diagramnya.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195d5d056af.png\")
<\/p>\n\n\nPlantUML<\/span> - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n