Diagram Kelas UML untuk Pemodelan Data dengan PlantUML

Sebuah diagram kelas UML menggambarkan struktur dari suatu sistem: hal-hal yang dimodelkannya, sifat-sifatnya, dan bagaimana mereka saling berhubungan. Untuk pemodelan data, diagram ini dapat menangkap konsep domain dan batasan sebelum Anda menetapkan tabel atau kode aplikasi.

PlantUML membuat diagram dapat direproduksi: Anda menulis teks, merendernya, meninjau perubahan dalam kontrol versi, dan memperbaruinya seiring evolusi model. Alat ini melengkapi—bukan menggantikan—skema basis data, migrasi, dan aturan bisnis yang terperinci.

1. Pilih tingkat pemodelan

Diagram pemodelan data yang berguna biasanya berfokus pada satu tingkat pada satu waktu:

• Konseptual: konsep bisnis dan hubungannya, dengan detail teknis minimal. Contoh: Pelanggan melakukan Pesanan.

• Logis: atribut, pengenal, multiplisitas, dan aturan, tanpa mengikat model ke basis data tertentu.

• Fisik: detail implementasi seperti tipe kolom SQL, indeks, dan batasan khusus basis data.

Contoh di bawah ini adalah model domain logis. Tipe seperti UUID, Uang, dan DateTime bersifat ilustratif; tentukan representasi konkretnya saat memilih teknologi.

2. Dasar-dasar PlantUML

Sebuah kelas memiliki nama dan dapat mencantumkan atribut dan operasi:

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Penanda visibilitas adalah petunjuk pemodelan opsional:

• + publik

• - pribadi

• # terlindungi

• ~ visibilitas paket

Untuk diagram domain atau data, atribut paling penting. Sertakan operasi hanya ketika mereka memperjelas perilaku penting; hindari mengubah diagram menjadi daftar kode lengkap.

3. Hubungan dan multiplisitas

Notasi hubungan yang paling berguna untuk pemodelan data adalah:

Label multiplisitas berada di dekat ujung asosiasi:

• 1 — tepat satu

• 0..1 — opsional, paling banyak satu

• * atau 0..* — nol atau lebih

• 1..* — satu atau lebih

• 2..5 — rentang terbatas

Sebagai contoh:

Pelanggan "1" -- "0..*" Pesanan : ditempatkan

Baca label di setiap ujung dengan cermat: satu pelanggan dapat menempatkan nol atau lebih pesanan; setiap pesanan terkait dengan tepat satu pelanggan. Label-label tersebut menggambarkan hubungan, bukan necessarily implementasi kunci asing dari basis data tertentu.

4. Contoh terapan: toko online

Model ini mencakup pelanggan, pesanan, item baris, produk, dan catatan pembayaran. Model ini mendemonstrasikan pengenal, tipe mirip nilai, enum, komposisi, dan multiplisitas.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Customer {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Order {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class OrderLine {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Product {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Payment {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<value object>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  DRAFT
  PLACED
  PAID
  FULFILLED
  CANCELLED
}

enum PaymentStatus {
  PENDING
  AUTHORIZED
  CAPTURED
  FAILED
  REFUNDED
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount

note right of OrderLine
  quantity must be greater than zero
  unitPrice is the price captured
  when the order is placed
end note

note right of Product
  Product.currentPrice may change.
  It does not replace OrderLine.unitPrice.
end note
@enduml

Mengapa memodelkan OrderLine secara eksplisit? Hubungan antara pesanan dan produk memiliki datanya sendiri—jumlah dan harga pada saat pembelian. Hal ini menjadikannya konsep domain, bukan sekadar tautan biasa.

Mengapa komposisi dari Order ke OrderLine? Contoh ini mengasumsikan bahwa baris pesanan milik satu pesanan dan tidak bermakna secara independen. Gunakan komposisi hanya ketika aturan kepemilikan dan siklus hidup tersebut benar dalam domain Anda; notasi UML tidak memaksakannya di basis data.

Mengapa membedakan harga saat ini dan harga historis? Harga produk dapat berubah setelah pesanan ditempatkan. Menyimpan harga pada saat pembelian di baris pesanan menjaga jumlah historis.

5. Keputusan pemodelan yang penting

Pengenal: Tandai pengenal secara konsisten, seperti customerId atau orderId. UML tidak mendefinisikan satu notasi universal tunggal untuk kunci primer, jadi pilihlah sebuah konvensi dan dokumentasikan. Stereotipe atau catatan dapat membuatnya eksplisit:

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Nilai opsional: Gunakan [0..1] untuk atribut opsional jika hal itu jelas bagi pembaca Anda, atau catat aturannya. Misalnya, pembayaran mungkin tidak memiliki paidAt timestamp hingga berhasil.

Objek nilai: Tipe seperti Money atau EmailAddress dapat merepresentasikan sebuah konsep dengan validasi atau semantik tersendiri. Putuskan apakah itu harus muncul sebagai kelas terpisah, tipe atribut, atau struktur database berdasarkan audiens dan tingkat detailnya.

Enum dan nilai terkontrol: Gunakan enum ketika himpunan yang diizinkan kecil dan relatif stabil. Jika nilai memerlukan deskripsi independen, siklus hidup, atau administrasi, modelkan sebagai kelas.

Normalisasi dan implementasi: Diagram kelas mengomunikasikan konsep dan aturan; diagram ini tidak menyelesaikan setiap detail relasional. Misalnya, apakah Money menjadi dua kolom, tabel terpisah, atau tipe khusus database adalah keputusan implementasi.

Jaga agar diagram tetap mudah dibaca: Pecah domain besar menjadi diagram yang berfokus—seperti pemesanan, inventaris, dan identitas—dan gunakan paket untuk mengelompokkan kelas yang terkait. Tampilkan hanya atribut yang relevan dengan pertanyaan yang ingin dijawab oleh diagram tersebut.

6. Bangun model dari persyaratan

1. Ekstrak konsep kandidat dari bahasa domain: kata benda sering menunjukkan kelas; kata kerja sering menunjukkan hubungan atau perilaku.

2. Jelaskan aturan dengan pertanyaan konkret: Dapatkah pesanan ada tanpa pelanggan? Dapatkah pesanan memiliki nol baris? Dapatkah pembayaran dicoba ulang?

3. Pilih tingkat pemodelan dan pertahankan keputusan teknis basis data agar tidak masuk ke dalam diagram konseptual.

4. Tambahkan atribut dan pengenal hanya ketika mereka membantu menjelaskan model.

5. Atur multiplisitas dari aturan bisnis, periksa kedua ujung setiap hubungan.

6. Tinjau kasus tepi: penghapusan, catatan historis, bidang opsional, upaya berulang, dan nilai yang berubah.

7. Render dan tinjau diagram bersama pakar domain dan pengimplementasi. Perlakukan sebagai model yang perlu divalidasi, bukan sekadar gambar yang perlu disetujui.

7. Gunakan VPasCode dan Visual Paradigm

VPasCode adalah editor berbasis browser teks-ke-diagram dengan dukungan PlantUML dan pratinjau langsung. Deskripsi fiturnya juga mencantumkan generasi dan modifikasi kode diagram oleh AI, serta bantuan sintaks. Alur kerja praktis adalah:

1. Buka VPasCode dan pilih atau masukkan PlantUML.

2. Tempel contoh di atas dan periksa diagram yang telah dirender.

3. Iterasi pada sumber PlantUML; pertahankan teks sebagai artefak yang dapat diversi.

4. Gunakan asisten AI, jika tersedia di ruang kerja Anda, untuk membuat draf atau merevisi draf pertama.

5. Verifikasi sendiri setiap kelas, hubungan, multiplisitas, dan aturan bisnis yang dihasilkan.

Alat diagram berbantuan AI Visual Paradigm dapat menghasilkan diagram yang dapat diedit dari deskripsi bahasa alami. Alur kerja yang dipublikasikannya menggambarkan pembuatan diagram kelas dari sebuah perintah, kemudian menyempurnakan elemen dan hubungannya. Perlakukan output AI sebagaidraf: ia mungkin menyimpulkan kepemilikan yang salah, kendala yang hilang, atau kelas yang tidak beralasan. Kebenaran model masih bergantung pada validasinya terhadap persyaratan.

Sebagai contoh, berikan perintah kepada asisten AI dengan:

Buat diagram kelas UML logis untuk toko online. Pelanggan membuat pesanan. Setiap pesanan berisi satu atau lebih baris pesanan. Setiap baris pesanan merujuk pada satu produk dan menyimpan jumlah serta harga satuan pada saat pembelian. Pesanan dapat memiliki beberapa upaya pembayaran. Sertakan pengenal, multiplisitas, dan enumerasi status pesanan dan pembayaran. Keluarkan hanya PlantUML.

Kemudian tinjau output tersebut terhadap persyaratan sebelum menerimanya. Untuk hasil yang lebih baik, nyatakan asumsi secara eksplisit—misalnya, apakah pesanan dapat berupa draf tanpa baris, dan apakah pembayaran dapat dikembalikan.

Visual Paradigm mendeskripsikanVPasCode sebagai editor yang mendukung PlantUML dengan rendering langsung dan pembuatan atau modifikasi yang dibantu AI. Alat dan ketersediaan dapat bervariasi tergantung pada versi produk atau ruang kerja.

8. Daftar periksa ringkas untuk tinjauan

Sebelum membagikan atau mengimplementasikan diagram kelas, periksa:

• Apakah setiap kelas mewakili konsep domain yang bermakna?

• Apakah pengenal dan atribut penting sudah jelas?

• Apakah label relasi dan multiplisitas benar pada kedua ujungnya?

• Apakah komposisi mencerminkan ketergantungan siklus hidup yang nyata?

• Apakah fakta historis dipertahankan di mana nilai saat ini dapat berubah?

• Apakah nilai opsional dan batasan bisnis terlihat?

• Apakah diagram cukup fokus untuk audiensnya?

• Apakah konten yang dihasilkan telah diperiksa terhadap persyaratan yang sebenarnya?

Alur kerja diagram-sebagai-kode terbaik adalah AI untuk draf awal, PlantUML untuk penyuntingan presisi dan riwayat versi, serta tinjauan manusia untuk kebenaran domain.

This post is also available in Deutsch, English, Español, Français, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文.