Panduan Praktis UML dengan Visual Paradigm dan VPasCode

UML—Unified Modeling Language—adalah cara standar untuk menggambarkan struktur dan perilaku suatu sistem. UML membantu tim mendiskusikan persyaratan, merancang perangkat lunak, dan mendokumentasikan keputusan. UML adalah bahasa pemodelan, bukan bahasa pemrograman: diagram mengkomunikasikan sebuah model, tetapi tidak secara otomatis menjamin bahwa implementasinya sesuai dengan model tersebut.

Panduan ini menggunakan sistem belanja online sebagai contoh yang berkelanjutan. Panduan ini mencakup jenis-jenis diagram UML utama dan alur kerja menggunakan Visual Paradigm untuk pemodelan visual dan VPasCode untuk diagram berbasis teks.

1. Mulailah dengan pertanyaan yang harus dijawab oleh diagram Anda

Sebelum menggambar, tentukan apa yang perlu dipahami oleh pembaca:

• Apa yang dapat dilakukan oleh pengguna? Gunakan diagram kasus penggunaan.

• Apa yang terjadi selama sebuah skenario? Gunakan diagram urutan atau diagram aktivitas.

• Konsep dan hubungan apa yang membentuk domain? Gunakan diagram kelas.

• Bagaimana perangkat lunak dibagi menjadi bagian yang dapat diimplementasikan atau diganti? Gunakan diagram komponen dan diagram penempatan.

• Bagaimana satu objek berubah seiring waktu? Gunakan diagram mesin keadaan.

Diagram yang mencoba menjawab semua pertanyaan sekaligus biasanya menjadi sulit dibaca. Lebih baik gunakan beberapa diagram yang fokus daripada satu gambaran umum yang padat.

2. Keluarga diagram UML

UML 2.x mencakup 14 jenis diagram standar, yang umumnya dikelompokkan menjadi diagram struktural dan diagram perilaku. Diagram interaksi adalah subset dari diagram perilaku.

Anda jarang memerlukan ke-14 diagram untuk sebuah proyek. Untuk banyak desain aplikasi, diagram kasus penggunaan, kelas, urutan, aktivitas, komponen, dan penempatan merupakan set awal yang kuat.

3. Diagram yang paling berguna, dengan contoh e-commerce

Diagram kasus penggunaan: tujuan dan batas sistem

Diagram kasus penggunaan menggambarkan tujuan pengguna, bukan tata letak layar atau kode internal. Untuk toko online, aktor mungkin mencakupPelanggan, Penyedia Pembayaran, danLayanan Gudang. Kasus penggunaan mungkin mencakupJelajahi Produk, Tempatkan Pesanan, Bayar Pesanan, danLacak Pengiriman.

Gunakan<<include>>ketika sebuah kasus penggunaan selalu memanggil perilaku lain yang diperlukan. Gunakan<<extend>>untuk perilaku opsional atau kondisional yang ditambahkan ke kasus penggunaan dasar. Pertahankan batas sistem agar jelas sehingga pembaca dapat membedakan sistem dari aktor eksternal.

Diagram aktivitas: alur kerja dan keputusan

Diagram aktivitas berguna untuk proses yang memiliki cabang atau pekerjaan paralel. Alur pembayaran mungkin berupa:

1. Validasi keranjang dan alamat.

2. Hitung ongkos kirim dan pajak.

3. Buat pesanan dalam status tertunda.

4. Minta otorisasi pembayaran.

5. Jika pembayaran berhasil, konfirmasi pesanan dan beri notifikasi pemenuhan.

6. Jika pembayaran gagal, tampilkan kegagalan dan biarkan pesanan tidak dikonfirmasi.

Gunakan node keputusan dan penggabungan untuk percabangan, node fork dan join untuk pekerjaan paralel, dan jalur renang (swimlanes) ketika tanggung jawab berpindah antara pelanggan, toko, dan penyedia eksternal.

Diagram urutan: satu skenario sepanjang waktu

Diagram urutan menampilkan peserta dan pesan yang mereka tukarkan. Diagram ini sangat berguna untuk memperjelas batas layanan, urutan panggilan, dan kasus kesalahan. Tambahkan jalur alternatif untuk hasil seperti penolakan pembayaran atau stok yang tidak tersedia.

@startuml
actor Pelanggan
participant "Toko Online" sebagai UI
participant "Layanan Pesanan" sebagai Pesanan
participant "Layanan Stok" sebagai Stok
participant "Penyedia Pembayaran" sebagai Pembayaran

Pelanggan -> UI: ajukan pembayaran
UI -> Pesanan: buatPesanan(keranjang, alamat)
Pesanan -> Stok: cadang(item)

alt item tersedia
    Stok --> Pesanan: cadangan dikonfirmasi
    Pesanan -> Pembayaran: otorisasi(total)
    alt pembayaran disetujui
        Pembayaran --> Pesanan: disetujui
        Pesanan --> UI: pesanan dikonfirmasi
        UI --> Pelanggan: tampilkan konfirmasi
    else pembayaran ditolak
        Pembayaran --> Pesanan: ditolak
        Pesanan -> Stok: lepaskan cadangan
        Pesanan --> UI: pembayaran gagal
        UI --> Pelanggan: tampilkan kesalahan pembayaran
    end
else item tidak tersedia
    Stok --> Pesanan: cadangan gagal
    Pesanan --> UI: item tidak tersedia
    UI --> Pelanggan: tampilkan kesalahan ketersediaan
end
@enduml

Contoh ini menggunakan sintaks PlantUML. Ini adalah sketsa perilaku, bukan spesifikasi untuk setiap aturan waktu habis, percobaan ulang, atau keamanan. Tambahkan detail tersebut ketika relevan dengan desain.

Diagram kelas: struktur domain

Diagram kelas menggambarkan tipe dan hubungannya. Model pesanan kecil mungkin berisi:

• Pelanggan

• Pesanan

• Baris Pesanan

• Produk

• Pembayaran

Tampilkan atribut dan operasi ketika membantu menjelaskan tanggung jawab. Gunakan multiplisitas untuk membuat aturan kuantitas menjadi eksplisit: misalnya, satu Pesanan berisi satu atau lebih Baris Pesanan objek, sedangkan setiap Baris Pesanan merujuk pada satu Produk.

Jenis hubungan umum:

• Asosiasi: tautan struktural umum.

• Pewarisan/generalisasi: satu kelas merupakan jenis khusus dari kelas lain.

• Agregasi: hubungan keseluruhan–bagian di mana bagian-bagian dapat eksis secara independen; gunakan secara hemat.

• Komposisi: hubungan keseluruhan–bagian yang kuat di mana siklus hidup bagian terikat pada keseluruhan.

• Ketergantungan: satu elemen menggunakan atau bergantung pada elemen lain.

Untuk model komersial, sebuah BarisPesanan sering dimodelkan sebagai milik dari satu Pesanan, sedangkan sebuah Produk eksis secara independen dari pesanan tertentu manapun. Pilih hubungan yang mencerminkan siklus hidup dan aturan aktual dari domain tersebut.

Diagram mesin keadaan: aturan siklus hidup

Gunakan mesin keadaan ketika transisi yang diizinkan oleh suatu objek penting. Sebuah pesanan mungkin bergerak melalui:

Menunggu → MenungguPembayaran → Dikonfirmasi → Diterima

Pesanan juga dapat beralih ke Dibatalkan atau PembayaranGagal. Berikan label pada transisi dengan peristiwa pemicu atau penjaga, seperti pembayaranDisetujui atau [stokTersedia]. Diagram ini dapat mengungkap transisi yang tidak valid—misalnya, apakah pesanan yang telah dipenuhi dapat dibatalkan.

Diagram komponen dan diagram penempatan: perangkat lunak dan runtime

Sebuah diagram komponenmenunjukkan tanggung jawab dan ketergantungan perangkat lunak, seperti toko daring, layanan pesanan, layanan inventaris, dan adaptor pembayaran. Diagram ini berguna untuk membahas modularitas dan batas integrasi.

Sebuah diagram penempatanmenunjukkan tempat perangkat lunak dijalankan: misalnya, peramban, runtime aplikasi, basis data, dan penyedia pembayaran eksternal. Gunakan diagram ini untuk membahas topologi runtime, bukan konfigurasi jaringan yang mendetail.

4. Buat model dengan baik: konvensi praktis

• Berikan setiap diagram judul yang jelas dan satu tujuan tunggal.

• Gunakan bahasa domain secara konsisten; hindari menciptakan nama yang berbeda untuk konsep yang sama.

• Jaga agar diagram cukup kecil agar dapat dibaca pada ukuran yang dimaksudkan.

• Sertakan hanya detail yang menjawab pertanyaan diagram.

• Berikan label pada asosiasi penting dan aliran pesan.

• Tambahkan multiplisitas pada asosiasi ketika aturan kuantitas menjadi penting.

• Gunakan catatan untuk asumsi, batasan, dan keputusan yang belum terselesaikan.

• Jaga agar nama dan tanggung jawab konsisten di seluruh diagram.

• Bedakan antara apa yang telah dikonfirmasi dengan apa yang diusulkan atau masih belum diketahui.

• Perbarui diagram ketika terdapat keputusan desain penting atau perubahan perilaku.

Anggap UML sebagai alat bantu komunikasi. Sebuah diagram bisa secara sintaksis valid dan tetap menyesatkan jika label, asumsi, atau ruang lingkupnya tidak jelas.

5. Menggunakan Visual Paradigm

Visual Paradigm cocok untuk pemodelan grafis: buat dan atur elemen UML pada kanvas, atur diagram yang terkait, dan perhalus model melalui pengeditan visual. Materi produknya menggambarkan pemodelan UML sebagai bagian dari kemampuan pemodelan visualnya.

Alur kerja praktis:

1. Buat sebuah proyekuntuk sistem atau area terbatas yang sedang Anda modelkan.

2. Mulailah dengan persyaratan dan ruang lingkup.Identifikasi pengguna, sistem eksternal, dan tujuan utama.

3. Buat diagram kasus penggunaanuntuk menetapkan batas dan interaksi utama.

4. Tambahkan diagram perilaku untuk skenario yang memiliki risiko atau ambiguitas paling tinggi.

5. Bangun model kelas di sekitar konsep domain dan aturan-aturannya.

6. Tambahkan tampilan komponen dan penempatan jika arsitektur atau penempatan saat runtime memerlukan pembahasan.

7. Tinjau bersama para pemangku kepentingan. Periksa nama, ruang lingkup, alur alternatif, dan kardinalitas.

8. Ekspor atau bagikan diagram dalam format yang sesuai untuk tinjauan dan dokumentasi.

9. Jaga pemeliharaan model. Tugaskan pemilik dan perbarui diagram ketika keputusan berubah.

Nama menu yang tepat dan fitur yang tersedia dapat bervariasi berdasarkan edisi dan rilis Visual Paradigm, sehingga gunakan dokumentasi antarmuka produk saat ini untuk langkah-langkah khusus edisi.

6. Menggunakan VPasCode

VPasCode adalah editor diagram-sebagai-kode berbasis browser dari Visual Paradigm. Informasi produknya menjelaskan dukungan untuk format diagram berbasis teks termasuk PlantUML dan Mermaid, dengan rendering langsung; produk ini juga mendukung ekspor seperti SVG dan PNG.

Alur kerja sederhana:

1. Buka VPasCode dan pilih bahasa diagram, seperti PlantUML.

2. Tulis atau tempel skrip diagram.

3. Periksa pratinjau yang telah dirender saat Anda mengedit.

4. Sempurnakan nama, hubungan, tata letak, dan jalur kesalahan.

5. Ekspor gambar untuk dokumen atau tinjauan.

6. Simpan skrip sumber bersama proyek jika Anda menginginkan catatan berbasis teks yang dapat ditinjau dan divernsi.

VPasCode sangat cocok untuk draf cepat, diagram dokumentasi, dan tim yang lebih menyukai pengeditan berbasis teks. Model grafis Visual Paradigm berguna ketika Anda ingin memanipulasi elemen model secara visual dan mengatur diagram sebagai bagian dari proyek pemodelan yang lebih besar. Kedua pendekatan ini dapat saling melengkapi, tetapi jangan berasumsi bahwa setiap diagram atau model dapat ditransfer di antara keduanya dengan kesetiaan penuh dalam proses bolak-balik; validasikan setiap konversi dalam alur kerja Anda.

7. Alur kerja end-to-end yang bermanfaat

Untuk fitur checkout, urutan pemodelan ringan dapat berupa:

1. Kasus penggunaan: definisikan siapa yang dapat melakukan pemesanan dan sistem eksternal mana yang terlibat.

2. Aktivitas: peta alur checkout dan keputusannya.

3. Urutan: detailkan interaksi untuk jalur sukses, kegagalan pembayaran, dan stok tidak tersedia.

4. Kelas: mendefinisikan konsep pesanan, item baris, produk, dan pembayaran beserta aturannya.

5. Mesin keadaan: menentukan siklus hidup pesanan yang valid.

6. Komponen: menunjukkan layanan mana yang memikul tanggung jawab tersebut.

7. Penempatan: dokumentasikan penempatan saat runtime jika keputusan infrastruktur relevan.

Gunakan Visual Paradigm ketika tim mendapat manfaat dari pemodelan berbasis kanvas dan model visual yang terkelola. Gunakan VPasCode ketika tim ingin menulis dan merender teks diagram dengan cepat. Pendekatan umum adalah membuat draf skenario di VPasCode, meninjau dan menyempurnakannya bersama tim, lalu memelihara diagram dalam format yang paling sesuai dengan proses dokumentasi dan perubahan proyek.

8. Jebakan umum

• Mencoba membuat diagram seluruh sistem sekaligus: pisahkan berdasarkan kepedulian atau skenario.

• Membingungkan aktivitas dengan urutan: aktivitas menekankan alur kerja; urutan menekankan pesan seiring waktu.

• Membebani diagram kelas: fokus pada konsep domain yang relevan, bukan setiap detail implementasi.

• Menggunakan include dan extend sebagai hiasan: mereka mengekspresikan hubungan spesifik antar kasus penggunaan.

• Melewatkan jalur alternatif: kegagalan dan pembatalan sering kali mengungkapkan persyaratan penting.

• Memperlakukan gambar sebagai spesifikasi: dokumentasikan aturan bisnis, asumsi, dan batasan penting secara eksplisit.

• Membiarkan diagram menjadi usang: diagram yang sudah usang bisa lebih buruk daripada tidak ada diagram karena pembaca mungkin mempercayainya.

Set UML yang kuat bukanlah set terbesar. Itu adalah set diagram terkecil yang memungkinkan pembaca yang dituju memahami sistem, mendiskusikan keputusan, dan mengidentifikasi celah sebelum celah tersebut menjadi mahal.

This post is also available in Deutsch, English, Español, فارسی, Français, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.