Unified Modeling Language (UML): Panduan Komprehensif untuk Diagram, Konsep, dan Visual Paradigm

Pendahuluan

Unified Modeling Language (UML) adalah bahasa pemodelan visual terstandarisasi yang digunakan untuk menganalisis, merancang, mendokumentasikan, dan mengomunikasikan struktur dan perilaku sistem perangkat lunak. Bahasa ini menyediakan serangkaian simbol dan teknik diagramming yang membantu pengembang, arsitek, analis bisnis, manajer proyek, dan pemangku kepentingan lainnya memahami cara kerja suatu sistem.

UML bukanlah bahasa pemrograman. Sebaliknya, UML bertindak sebagai cetak biru visual untuk perangkat lunak. Tim dapat menggunakan diagram UML untuk menggambarkan persyaratan, merencanakan arsitektur sistem, memodelkan proses bisnis, mendokumentasikan aplikasi yang sudah ada, dan menjelaskan bagaimana berbagai bagian dalam suatu sistem saling berinteraksi.

Sebagai contoh, aplikasi e-commerce mungkin berisi pengguna, produk, keranjang belanja, pesanan, layanan pembayaran, dan layanan pengiriman. Diagram UML dapat merepresentasikan elemen-elemen ini, menunjukkan hubungan antar elemen, dan mengilustrasikan apa yang terjadi ketika pelanggan melakukan pemesanan.

UML dikelola sebagai standar industri oleh Object Management Group (OMG) dan juga telah diadopsi melalui standar internasional. UML modern umumnya merujuk pada UML 2.x, yang mendefinisikan kumpulan luas diagram struktural dan perilaku. Sebagai contoh, UML 2.2 mendefinisikan 14 jenis diagram yang dibagi secara merata antara pemodelan struktural dan perilaku.

Apa Itu UML?

UML adalah bahasa pemodelan serbaguna untuk sistem yang intensif perangkat lunak. Bahasa ini menyediakan notasi terstandarisasi untuk merepresentasikan:

• Komponen sistem

• Kelas dan objek

• Persyaratan pengguna

• Alur kerja dan proses bisnis

• Pesan yang dipertukarkan antar objek

• Keadaan sistem dan transisi

• Lingkungan penyebaran perangkat lunak

• Ketergantungan antar paket dan komponen

Tujuan UML bukan untuk menggantikan kode sumber. Sebaliknya, UML membantu tim memikirkan dan mengomunikasikan suatu sistem sebelum, selama, dan setelah implementasi.

Model UML dapat dibuat pada berbagai tingkat detail:

• Tingkat konseptual:Menggambarkan konsep bisnis utama tanpa rincian implementasi.

• Tingkat analisis:Menjelajahi persyaratan, tanggung jawab, dan perilaku sistem.

• Tingkat desain:Mendefinisikan kelas, antarmuka, komponen, dan interaksi.

• Tingkat implementasi:Mewakili detail yang sangat sesuai dengan kode sumber dan infrastruktur deployment.

Mengapa UML Penting?

UMLberguna karena sistem perangkat lunak dapat menjadi sulit dipahami ketika hanya dijelaskan melalui kode sumber atau dokumen tertulis yang panjang.

Menyederhanakan sistem kompleks

Diagram memberikan gambaran visual dari sistem besar. Sebagai contoh, diagram kelas dapat menampilkan puluhan kelas dan hubungan antar mereka dengan lebih jelas daripada beberapa halaman teks.

Meningkatkan komunikasi

Pengembang, desainer, arsitek, penguji, analis bisnis, dan pelanggan mungkin memiliki latar belakang teknis yang berbeda. UML memberikan bahasa visual bersama bagi mereka untuk mendiskusikan persyaratan sistem dan keputusan desain.

Mendukung perencanaan

Tim dapat memodelkan alur kerja, kelas, layanan, dan lingkungan deployment sebelum menulis kode. Hal ini dapat mengungkap persyaratan yang hilang, tanggung jawab yang diduplikasi, dan masalah arsitektur pada tahap awal.

Membantu mendokumentasikan perangkat lunak

Diagram UML dapat berfungsi sebagai dokumentasi teknis jangka panjang. Diagram ini membantu pengembang baru memahami sistem yang ada dan membantu tim pemeliharaan ketika perubahan diperlukan.

Mendorong desain yang lebih baik

Membuat model memaksa tim untuk mempertimbangkan pertanyaan seperti:

• Objek mana yang bertanggung jawab atas suatu tugas?

• Bagaimana komponen-komponen terhubung?

• Apa yang terjadi ketika suatu operasi gagal?

• Kelas mana yang saling bergantung?

• Bagaimana sistem merespons berbagai peristiwa?

Konsep Utama UML

Kelas

Kelas adalah cetak biru yang mendefinisikan atribut dan operasi yang dimiliki bersama oleh sekelompok objek.

Sebagai contoh, sebuah Pesanan kelas mungkin berisi:

• Atribut: orderId, orderDate, dan status

• Operasi: calculateTotal() dan cancelOrder()

Objek

Sebuah objek adalah instansi aktual dari sebuah kelas. Jika Pesanan adalah sebuah kelas, order1001 mungkin merupakan objek spesifik yang dibuat dari kelas tersebut.

Atribut

Sebuah atribut merepresentasikan data yang dimiliki oleh sebuah kelas atau objek.

Contoh meliputi:

• nama

• harga

• alamatEmail

• statusPesanan

Operasi

Sebuah operasi merepresentasikan perilaku yang disediakan oleh sebuah kelas. Operasi sering diimplementasikan sebagai metode dalam bahasa pemrograman.

Contoh meliputi:

• addItem()

• submitPayment()

• sendNotification()

Aktor

Sebuah aktor adalah peran eksternal yang berinteraksi dengan sebuah sistem. Sebuah aktor dapat berupa orang, sistem lain, atau perangkat eksternal.

Contoh meliputi:

• Pelanggan

• Administrator

• Gerbang Pembayaran

• Sistem Gudang

Antarmuka

Sebuah antarmuka mendefinisikan serangkaian operasi yang dijanjikan oleh sebuah kelas atau komponen untuk disediakan. Antarmuka membantu mengurangi ketergantungan dan mendukung implementasi yang dapat dipertukarkan.

Hubungan

Sebuah hubungan menggambarkan bagaimana elemen-elemen UML terhubung. Hubungan umum meliputi asosiasi, ketergantungan, generalisasi, agregasi, dan komposisi.

Kardinalitas

Kardinalitas menentukan berapa banyak objek yang dapat berpartisipasi dalam sebuah hubungan.

Contoh umum meliputi:

• 1: Tepat satu

• 0..1: Nol atau satu

• *: Banyak

• 1..*: Satu atau lebih

• 0..*: Nol atau lebih

Sebagai contoh, satu pelanggan dapat menempatkan nol atau banyak pesanan. Hal ini dapat direpresentasikan sebagai:

Pelanggan 1 -------- 0..* Pesanan

Kategori Diagram UML

Diagram UMLumumnya dibagi menjadi dua kategori utama:

1. Diagram Struktural

2. Diagram Perilaku

Diagram struktural menggambarkan apa yang menyusun sebuah sistem. Diagram perilaku menggambarkan apa yang dilakukan sebuah sistem dan bagaimana perilakunya seiring waktu.

---

Diagram UML Struktural

Diagram struktural merepresentasikan organisasi statis dari sebuah sistem. Diagram ini berfokus pada kelas, objek, komponen, paket, node, dan hubungan.

1. Diagram Kelas

Diagram kelas adalah salah satu diagram UML yang paling banyak digunakan. Diagram ini merepresentasikan struktur statis dari sebuah sistem dengan menampilkan:

• Kelas

• Atribut

• Operasi

• Antarmuka

• Relasi

• Visibilitas

• Multiplisitas

Model kelas e-commerce yang disederhanakan mungkin terlihat seperti ini:

Pelanggan
- customerId
- name
+ placeOrder()

Pesanan
- orderId
- orderDate
- status
+ calculateTotal()

Produk
- productId
- name
- price
+ updatePrice()

Relasi yang mungkin meliputi:

Pelanggan 1 -------- 0..* Pesanan
Pesanan 1 -------- 1..* Produk

Dalam desain yang lebih rinci, sebuah ItemPesanan kelas mungkin diperkenalkan antara Pesanan dan Produk.

Diagram kelas berguna untuk:

• Pemodelan domain

• Desain berorientasi objek

• Perencanaan basis data dan aplikasi

• Mengidentifikasi tanggung jawab

• Menjelaskan pewarisan dan antarmuka

Diagram kelas menggambarkan kelas secara umum, sedangkan diagram objek menunjukkan instance spesifik dari kelas-kelas tersebut. Visual Paradigm mendeskripsikan diagram kelas sebagai model kelas, atribut, operasi, dan relasi dalam sistem berorientasi objek.

2. Diagram Objek

Diagram objek menunjukkan snapshot sistem pada momen tertentu. Diagram ini merepresentasikan instance objek yang sebenarnya, bukan kelas secara umum.

Sebagai contoh:

customerA:Pelanggan
name = "Alex"

order1001:Pesanan
status = "Dibayar"

Diagram objek berguna ketika Anda perlu mendemonstrasikan:

• Keadaan objek saat runtime

• Contoh hubungan data

• Skenario tertentu

• Bagaimana instance kelas terhubung

Diagram kelas mungkin menunjukkan bahwa seorang pelanggan dapat melakukan banyak pesanan. Diagram objek dapat menunjukkan bahwa pelangganA saat ini memiliki pesanan1001 dan pesanan1002.

3. Diagram Komponen

Diagram komponen menunjukkan organisasi dan ketergantungan komponen perangkat lunak yang dapat diganti.

Diagram komponen e-commerce dapat mencakup:

• Aplikasi Web

• Layanan Pesanan

• Layanan Produk

• Layanan Pembayaran

• Layanan Notifikasi

• Basis Data

Contoh:

Aplikasi Web --> Layanan Pesanan
Layanan Pesanan --> Layanan Pembayaran
Layanan Pesanan --> Layanan Notifikasi
Layanan Pesanan --> Basis Data Pesanan

Diagram komponen sangat berguna untuk:

• Arsitektur mikro layanan

• Sistem berorientasi layanan

• Desain API

• Arsitektur aplikasi

• Menampilkan batas layanan dan ketergantungan

4. Diagram Penempatan

Diagram penempatan merepresentasikan lingkungan fisik atau virtual tempat perangkat lunak dieksekusi.

Ini mungkin menampilkan:

• Perangkat klien

• Server web

• Server aplikasi

• Server basis data

• Node cloud

• Kontainer

• Koneksi jaringan

• Artefak perangkat lunak yang telah diterapkan

Contoh:

Perangkat Pelanggan
       |
       v
Server Web
       |
       v
Server Aplikasi
       |
       v
Server Basis Data

Diagram penempatan membantu arsitek memahami di mana perangkat lunak berjalan dan bagaimana komponen infrastruktur saling berkomunikasi.

5. Diagram Paket

Diagram paket mengatur elemen model yang terkait ke dalam paket dan menunjukkan ketergantungan antar paket tersebut.

Sebuah proyek mungkin berisi paket seperti:

• pengguna

• katalog

• pesanan

• pembayaran

• notifikasi

Contoh:

pesanan --> pengguna
pesanan --> katalog
pesanan --> pembayaran
pembayaran --> notifikasi

Diagram paket berguna untuk:

• Mengorganisasi model besar

• Menampilkan ketergantungan modul

• Mengidentifikasi lapisan arsitektur

• Mencegah kopling yang tidak diinginkan

6. Diagram Struktur Komposit

Diagram struktur komposit menampilkan struktur internal dari sebuah kelas, komponen, atau pengklasifikasi terstruktur lainnya.

Ini dapat menampilkan:

• Bagian internal

• Port

• Konektor

• Kolaborasi internal

• Hubungan antara elemen internal

Sebagai contoh, sebuah OrderController dapat berisi atau terhubung ke:

• OrderService

• OrderRepository

• PaymentService

• NotificationService

Berbeda dengan diagram komponen yang umumnya berfokus pada komponen tingkat tinggi, diagram struktur komposit berfokus pada organisasi internal dari sebuah classifier.

7. Diagram Profil

Diagram profil memperluas UML untuk domain atau teknologi tertentu. Diagram ini mendefinisikan elemen pemodelan khusus melalui stereotipe, nilai bertanda, dan batasan.

Sebagai contoh, sebuah profil dapat memperkenalkan stereotipe seperti:

<<entity>>
<<controller>>
<<service>>
<<microservice>>

Diagram profil berguna ketika notasi UML standar perlu disesuaikan untuk:

• Aplikasi web

• Arsitektur perusahaan

• Sistem waktu nyata

• Sistem tertanam

• Kerangka kerja pemrograman khusus

• Pemodelan khusus industri

Diagram profil sering diabaikan dalam daftar pengantar, namun termasuk dalam jenis diagram standar UML 2.x. UML 2.x umumnya digambarkan memiliki tujuh jenis diagram struktural dan tujuh jenis diagram perilaku.

---

Diagram UML Perilaku

Diagram perilaku menggambarkan perilaku dinamis dari sebuah sistem. Diagram ini menampilkan alur kerja, peristiwa, interaksi, perubahan keadaan, dan respons.

1. Diagram Use Case

Diagram use case menyajikan persyaratan fungsional sistem dari perspektif aktor eksternal.

Sistem belanja online yang khas mungkin mencakup aktor-aktor berikut:

• Pelanggan

• Administrator

• Gerbang Pembayaran

• Layanan Pengiriman

Kemungkinan kasus penggunaan meliputi:

• Daftarkan Akun

• Masuk

• Jelajahi Produk

• Tambahkan Produk ke Keranjang

• Tempelkan Pesanan

• Lakukan Pembayaran

• Lacak Pengiriman

• Kelola Produk

Diagram kasus penggunaan memberikan pandangan tingkat tinggi tentang apa yang dilakukan sistem tanpa menjelaskan detail implementasi.

Hubungan penting meliputi:

• Asosiasi:Menghubungkan aktor dengan kasus penggunaan.

• Termasuk:Menunjukkan perilaku yang selalu digunakan kembali oleh kasus penggunaan lain.

• Memperluas:Menunjukkan perilaku opsional atau bersyarat.

• Generalisasi:Menunjukkan spesialisasi antara aktor atau kasus penggunaan.

Sebagai contoh, Tempelkan Pesanan dapat termasuk Lakukan Pembayaran, sedangkan Terapkan Diskon dapat memperluas Pesan Pesanan.

2. Diagram Aktivitas

Diagram aktivitas merepresentasikan aliran kendali dalam suatu proses atau kasus penggunaan. Diagram ini berguna untuk memodelkan alur kerja yang berurutan dan konkuren.

Contoh: melakukan pemesanan

Mulai
  |
Jelajahi Produk
  |
Tambah Produk ke Keranjang
  |
Lanjutkan ke Pembayaran
  |
Masukkan Detail Pembayaran
  |
Pembayaran Berhasil?
 /              
Tidak             Ya
|                |
Tampilkan Error  Buat Pesanan
                  |
              Kirim Konfirmasi
                  |
                 Selesai

Diagram aktivitas dapat merepresentasikan:

• Aksi

• Keputusan

• Penggabungan

• Perulangan

• Aktivitas paralel

• Node awal dan akhir

• Jalur renang untuk tanggung jawab

Jalur renang dapat menunjukkan aktor atau komponen sistem mana yang melakukan setiap aksi. Sebagai contoh, satu jalur dapat mewakili pelanggan, jalur lain layanan pemesanan, dan jalur lain gerbang pembayaran.

3. Diagram Urutan

Diagram urutan menunjukkan bagaimana objek atau komponen berkomunikasi dalam urutan yang diurutkan berdasarkan waktu.

Contoh: melakukan pemesanan

Pelanggan -> WebApp: Kirim pesanan
WebApp -> LayananPemesanan: createOrder()
LayananPemesanan -> LayananPembayaran: authorizePayment()
LayananPembayaran --> LayananPemesanan: pembayaranDisetujui
LayananPemesanan -> LayananNotifikasi: sendConfirmation()
LayananPemesanan --> WebApp: pesananDibuat
WebApp --> Pelanggan: Tampilkan konfirmasi

Diagram urutan berisi:

• Peserta

• Garis kehidupan

• Pesan

• Blok aktivasi

• Pesan balasan

• Kondisi

• Perulangan

• Alternatif

• Interaksi paralel

Diagram ini sangat berguna untuk menjelaskan panggilan API, interaksi layanan, alur autentikasi, dan penanganan kesalahan.

4. Diagram Komunikasi

Diagram komunikasi, yang secara historis disebut diagram kolaborasi dalam versi UML yang lebih awal, menekankan hubungan antara objek dan pesan yang dipertukarkan di antara mereka.

Alih-alih berfokus terutama pada garis waktu vertikal seperti diagram urutan, diagram ini berfokus pada:

• Objek

• Tautan antara objek

• Pesan bernomor

• Struktur kolaborasi

Contoh:

1: submitOrder()
Pelanggan ----------------> WebApp

2: createOrder()
WebApp ------------------> OrderService

3: authorizePayment()
OrderService -------------> PaymentService

Diagram komunikasi berguna ketika struktur kolaborasi objek lebih penting daripada garis waktu visual yang tepat.

5. Diagram Mesin Status

Diagram mesin status menunjukkan bagaimana sebuah objek atau sistem mengubah status sebagai respons terhadap peristiwa.

Sebuah pesanan dapat bergerak melalui status berikut:

Baru -> Menunggu Pembayaran -> Dibayar -> Dikirim -> Diterima
                  |
                  v
              Dibatalkan

Transisi dapat diberi label dengan peristiwa atau kondisi:

Menunggu Pembayaran -- pembayaranDisetujui --> Dibayar
Menunggu Pembayaran -- pembayaranGagal --> Pembayaran Gagal

Diagram mesin status berguna untuk:

• Siklus hidup pesanan

• Status akun pengguna

• Status alur kerja

• Perilaku perangkat

• Status koneksi jaringan

• Proses persetujuan

Diagram ini sangat berharga ketika perilaku objek sangat bergantung pada status saat ini.

6. Diagram Waktu

Diagram waktu menggambarkan bagaimana status atau nilai satu atau lebih elemen berubah seiring waktu.

Diagram ini sering digunakan untuk:

• Sistem waktu nyata

• Sistem tertanam

• Protokol komunikasi

• Koordinasi perangkat keras dan perangkat lunak

• Interaksi yang sensitif terhadap kinerja

Sebagai contoh, diagram waktu dapat menunjukkan hubungan antara:

• Sinyal perangkat

• Status pengontrol

• Nilai sensor

• Respons selama interval waktu yang ditentukan

7. Diagram Ikhtisar Interaksi

Diagram ikhtisar interaksi memberikan pandangan tingkat tinggi tentang interaksi dengan menggabungkan alur kontrol bergaya aktivitas dengan diagram interaksi.

Diagram ini dapat menampilkan:

• Urutan interaksi utama

• Keputusan antar fragmen interaksi

• Jalur interaksi paralel

• Referensi ke diagram urutan atau diagram komunikasi

Sebagai contoh, ikhtisar interaksi untuk pesanan online dapat menghubungkan:

1. Otentikasi pelanggan

2. Pemilihan produk

3. Interaksi checkout

4. Otorisasi pembayaran

5. Pemenuhan pesanan

Diagram ini berguna ketika suatu proses terlalu kompleks untuk dijelaskan dengan satu diagram urutan.

---

Hubungan UML

Memahami hubungan UML sangat penting untuk membuat diagram yang bermakna.

Asosiasi

Sebuah asosiasi mewakili koneksi struktural antara dua elemen.

Pelanggan -------- Pesanan

Ini menunjukkan bahwa pelanggan dan pesanan saling terkait.

Asosiasi Terarah

Asosiasi terarah menunjukkan kemampuan navigasi dalam satu arah.

Pesanan ------> Pembayaran

Hal ini menunjukkan bahwa pesanan mengetahui atau menggunakan objek pembayaran, sedangkan sebaliknya mungkin tidak benar.

Generalisasi

Generalisasi mewakili pewarisan atau spesialisasi.

       User
      /    
Pelanggan  Administrator

Di sini, Pelanggan dan Administrator adalah jenis-jenis khusus dari Pengguna.

Ketergantungan

Ketergantungan menunjukkan bahwa satu elemen secara sementara menggunakan atau bergantung pada elemen lain.

OrderService - - - -> PaymentGateway

Perubahan pada gerbang pembayaran dapat memengaruhi layanan pesanan.

Agregasi

Agregasi mewakili hubungan keseluruhan-bagian di mana bagian-bagian dapat eksis secara independen.

Tim ◇------ Pemain

Seorang pemain dapat terus eksis meskipun tim dibubarkan.

Komposisi

Komposisi mewakili hubungan keseluruhan-bagian yang kuat. Bagian-bagian umumnya bergantung pada keseluruhan untuk siklus hidupnya.

Pesanan ◆------ ItemPesanan

Sebuah ItemPesanan dapat dianggap sebagai bagian dari pesanan dan mungkin tidak memiliki makna di luar pesanan tersebut.

Realisasi

Realisasi menunjukkan bahwa sebuah kelas atau komponen mengimplementasikan antarmuka.

PaymentService - - -|> PaymentProcessor

The PaymentService menyediakan perilaku yang didefinisikan oleh “"PaymentProcessor" antarmuka.

Contoh UML: Sistem Belanja Online

Pertimbangkan sebuah aplikasi belanja online.

Aktor utama

• Pelanggan

• Administrator

• Gerbang Pembayaran

• Layanan Pengiriman

Kasus penggunaan utama

• Buat Akun

• Jelajahi Produk

• Tambahkan Item ke Keranjang

• Tempel Pesanan

• Lakukan Pembayaran

• Lacak Pengiriman

• Kelola Inventaris

Kelas yang mungkin

Pelanggan
Produk
KeranjangBelanja
ItemKeranjang
Pesanan
ItemPesanan
Pembayaran
Pengiriman

Komponen layanan yang mungkin

Layanan Pengguna
Layanan Katalog
Layanan Keranjang
Layanan Pesanan
Layanan Pembayaran
Layanan Pengiriman
Layanan Notifikasi

Contoh interaksi

Ketika pelanggan menempel pesanan:

1. Pelanggan menyerahkan keranjang.

2. Aplikasi web mengirimkan permintaan ke layanan pesanan.

3. Layanan pesanan memvalidasi item-item tersebut.

4. Layanan pembayaran mengotorisasi pembayaran.

5. Pesanan disimpan.

6. Layanan pengiriman diberitahu.

7. Layanan notifikasi mengirim email konfirmasi.

Proses bisnis tunggal ini dapat direpresentasikan melalui beberapa diagram UML:

• Diagram kasus penggunaan: Menunjukkan bahwa pelanggan dapat melakukan pemesanan.

• Diagram aktivitas: Menunjukkan alur kerja dan titik keputusan.

• Diagram urutan: Menunjukkan pesan antar layanan.

• Diagram kelas: Menunjukkan Pelanggan, Pesanan, Produk, dan kelas terkait.

• Diagram komponen: Menunjukkan layanan yang terlibat.

• Diagram penempatan: Menunjukkan di mana layanan tersebut dijalankan.

Cara Memilih Diagram UML yang Tepat

Tujuan pemodelan	Diagram UML yang direkomendasikan
Menampilkan kelas dan hubungannya	Diagram kelas
Menampilkan instance objek nyata	Diagram objek
Mendeskripsikan fungsionalitas sistem	Diagram kasus penggunaan
Memodelkan alur kerja bisnis atau sistem	Diagram aktivitas
Menampilkan pesan yang dipertukarkan seiring waktu	Diagram urutan
Menampilkan kolaborasi objek	Diagram komunikasi
Menampilkan siklus hidup dan perubahan keadaan	Diagram mesin keadaan
Menampilkan modul atau layanan perangkat lunak	Diagram komponen
Menampilkan penerapan fisik	Diagram penerapan
Mengorganisir elemen model	Diagram paket
Menampilkan bagian internal dari sebuah pengklasifikasi	Diagram struktur komposit
Menampilkan perubahan seiring waktu	Diagram waktu
Merangkum beberapa interaksi	Diagram ikhtisar interaksi
Memperluas UML untuk domain khusus	Diagram profil

Praktik pemodelan yang baik adalah memilih hanya diagram yang menjawab pertanyaan tertentu. Membuat setiap diagram UML yang mungkin dapat membuat dokumentasi menjadi terlalu kompleks.

UML dan Siklus Hidup Pengembangan Perangkat Lunak

UML dapat mendukung banyak fase pengembangan perangkat lunak.

Analisis persyaratan

Diagram kasus penggunaan membantu mengidentifikasi aktor dan fungsionalitas sistem. Diagram aktivitas dapat memperjelas proses bisnis dan alur kerja.

Analisis sistem

Diagram kelas dapat merepresentasikan konsep domain. Diagram urutan dapat membantu analis memahami bagaimana kasus penggunaan dipenuhi.

Desain arsitektur

Diagram komponen, paket, dan penerapan membantu mendefinisikan struktur aplikasi dan infrastrukturnya.

Desain rinci

Diagram kelas, diagram urutan, diagram mesin keadaan, dan diagram struktur komposit dapat menggambarkan tanggung jawab implementasi dan interaksi objek.

Pengembangan

Pengembang dapat menggunakan model sebagai referensi saat mengimplementasikan kelas, layanan, API, dan struktur basis data.

Pengujian

Penguji dapat menurunkan skenario dari kasus penggunaan, diagram aktivitas, dan diagram urutan. Diagram mesin keadaan dapat membantu mengidentifikasi transisi keadaan yang valid dan tidak valid.

Pemeliharaan

Diagram UML menyediakan dokumentasi untuk sistem yang ada dan membantu tim menilai dampak dari perubahan yang diusulkan.

Membuat Diagram UML dengan Visual Paradigm

Visual Paradigm adalah platform pemodelan visual dan desain perangkat lunak yang mendukung pembuatan diagram UML serta aktivitas pemodelan dan pengembangan lainnya. Kemampuan UML-nya mencakup diagram seperti kelas, urutan, kasus penggunaan, aktivitas, komponen, penempatan, mesin keadaan, paket, objek, dan diagram struktur komposit.

Memulai Proyek UML

Alur kerja praktis di Visual Paradigm adalah:

1. Buat proyek baru.

2. Organisasikan model ke dalam paket seperti Persyaratan, Model Domain, Layanan, dan Penempatan.

3. Buat diagram kasus penggunaan untuk menangkap fungsionalitas sistem.

4. Tambahkan diagram aktivitas atau urutan untuk alur kerja penting.

5. Buat diagram kelas untuk model domain.

6. Tambahkan diagram komponen dan penempatan untuk arsitektur.

7. Tinjau diagram bersama para pemangku kepentingan.

8. Perbarui model seiring berkembangnya sistem.

9. Ekspor diagram atau buat dokumentasi bila diperlukan.

Membuat Diagram Kelas

Untuk membuat diagram kelas:

1. Buat diagram kelas baru.

2. Tambahkan kelas domain utama.

3. Tambahkan atribut dan operasi.

4. Hubungkan kelas menggunakan relasi yang sesuai.

5. Tambahkan multiplisitas.

6. Tunjukkan pewarisan dan antarmuka di mana diperlukan.

7. Atur diagram sehingga kelas-kelas yang terkait mudah diikuti.

8. Validasi model terhadap persyaratan.

Sebagai contoh, diagram kelas untuk toko online mungkin berisi Pelanggan, Pesanan, Produk, Pembayaran, dan Pengiriman.

Membuat diagram kasus penggunaan

Diagram kasus penggunaan dapat dibuat dengan:

1. Mengidentifikasi aktor eksternal.

2. Mencantumkan fungsi utama sistem.

3. Menambahkan batas sistem.

4. Menempatkan kasus penggunaan di dalam batas.

5. Menghubungkan aktor dengan kasus penggunaan yang mereka ikuti.

6. Menambahkan hubungan include atau extend hanya ketika hal tersebut memperjelas penggunaan kembali atau perilaku opsional.

Membuat diagram urutan

Saat membuat diagram urutan:

1. Identifikasi skenario yang dimodelkan.

2. Tambahkan aktor atau komponen pemicu.

3. Tambahkan objek atau layanan yang berpartisipasi.

4. Atur mereka dari kiri ke kanan.

5. Tambahkan pesan secara kronologis.

6. Pemodelan alternatif, perulangan, dan kondisi kesalahan.

7. Periksa bahwa setiap pesan sesuai dengan tanggung jawab yang realistis.

Kolaborasi dan dokumentasi

Visual Paradigm menyediakan kemampuan pemodelan visual, fitur kolaborasi tim, dukungan dokumentasi, dan integrasi yang dirancang untuk menghubungkan pemodelan dengan aktivitas pengembangan perangkat lunak yang lebih luas. Platformnya juga mendukung tinjauan dan komentar diagram secara kolaboratif.

Beberapa edisi dan alur kerja juga mungkin menyediakan fitur seperti rekayasa kode, pemodelan basis data, organisasi model, ekspor diagram, dan generasi dokumentasi. Kapabilitas ini harus dipilih sesuai dengan kebutuhan proyek, bukan ditambahkan secara otomatis ke setiap model.

Praktik Terbaik untuk Pemodelan UML yang Efektif

Buat model dengan tujuan

Setiap diagram harus menjawab pertanyaan yang jelas. Sebagai contoh:

• Bagaimana seorang pelanggan melakukan pemesanan?

• Layanan mana yang bergantung pada layanan pembayaran?

• Keadaan apa saja yang dapat dimasuki oleh sebuah pesanan?

• Kelas mana yang termasuk dalam domain pesanan?

Jaga agar diagram tetap fokus

Hindari menempatkan seluruh sistem dalam satu diagram. Bagi model besar menjadi tampilan yang lebih kecil untuk persyaratan, struktur domain, perilaku, arsitektur, dan penempatan.

Gunakan nama yang konsisten

Gunakan nama yang sama di seluruh diagram. Jika satu diagram menyebut sebuah komponenOrderService, diagram lain tidak boleh menyebutnyaOrderManagerkecuali jika mereka benar-benar merupakan elemen yang berbeda.

Pilih tingkat detail yang tepat

Diagram yang ditujukan untuk pemangku kepentingan biasanya harus mengandung lebih sedikit detail teknis dibandingkan diagram implementasi. Jangan tambahkan tanda tangan metode, bidang basis data, atau detail spesifik kerangka kerja kecuali jika relevan bagi audiens.

Hindari hubungan yang tidak perlu

Menambahkan setiap kemungkinan ketergantungan dapat membuat diagram sulit dibaca. Sertakan hubungan yang mengkomunikasikan informasi desain yang bermakna.

Tampilkan multiplisitas di tempat yang penting

Multiplisitas membantu memperjelas aturan bisnis dan hubungan data. Sebagai contoh, menunjukkan bahwa sebuah pesanan berisi satu atau lebih item pesanan lebih informatif daripada sekadar menghubungkan kedua kelas tersebut.

Validasi diagram terhadap persyaratan

Sebuah model hanya berguna ketika secara akurat merepresentasikan sistem. Bandingkan diagram dengan persyaratan, skenario pengujian, kode sumber, dan umpan balik pemangku kepentingan.

Gunakan diagram sebagai dokumentasi yang hidup

Perbarui diagram UML ketika keputusan desain utama berubah. Diagram yang sudah usang dapat lebih membingungkan daripada tidak memiliki diagram sama sekali.

Gabungkan diagram yang saling melengkapi

Tidak ada satu diagram UML pun yang menjelaskan setiap aspek sistem. Diagram kelas mungkin menunjukkan struktur, sedangkan diagram urutan menjelaskan bagaimana struktur tersebut berperilaku selama skenario tertentu.

Kesalahan Umum yang Harus Dihindari

• Memperlakukan UML sebagai kode sumber

• Membuat diagram tanpa tujuan tertentu

• Mencampur detail konseptual dan implementasi tanpa penjelasan

• Menggunakan pewarisan di mana komposisi akan lebih tepat

• Melewatkan multiplisitas dari hubungan penting

• Menambahkan terlalu banyak elemen ke satu diagram

• Menggunakan hubungan include dan extend yang tidak benar

• Gagal memodelkan alur kesalahan dan alur alternatif

• Membiarkan diagram yang berbeda menggunakan nama yang tidak konsisten

• Mengasumsikan bahwa sebuah diagram benar hanya karena terlihat terorganisir secara visual

UML 2.x dan Jumlah Diagram

Versi awal UML umumnya menggambarkan lebih sedikit jenis diagram.UML 2.xmemperluas bahasa dan memperkenalkan atau meresmikan diagram tambahan, termasuk:

• Diagram struktur komposit

• Diagram komunikasi

• Diagram ikhtisar interaksi

• Diagram waktu

Diagram ini juga mengubah nama diagram statechart menjadi diagram mesin keadaan. Klasifikasi UML 2.x yang umum berisi 14 diagram: tujuh diagram struktural dan tujuh diagram perilaku. Kelompok perilaku mencakup diagram kasus penggunaan, aktivitas, mesin keadaan, urutan, komunikasi, ikhtisar interaksi, dan waktu. Kelompok struktural mencakup diagram kelas, objek, komponen, struktur komposit, penempatan, paket, dan profil.

Oleh karena itu, daftar yang menggambarkan UML 2.x hanya memiliki 13 diagram tidak lengkap di bawah klasifikasi 14 diagram yang umum digunakan.

Kesimpulan

UML menyediakan bahasa visual praktis untuk memahami, merancang, dan mendokumentasikan sistem perangkat lunak. UML membantu tim mengomunikasikan persyaratan, mengeksplorasi arsitektur, memodelkan hubungan objek, menggambarkan alur kerja, dan menjelaskan perilaku saat runtime.

Diagram yang paling sering digunakan biasanya adalah:

• Diagram kasus penggunaan untuk persyaratan fungsional

• Diagram kelas untuk struktur statis

• Diagram aktivitas untuk alur kerja

• Diagram urutan untuk interaksi

• Diagram komponen untuk arsitektur

• Diagram penempatan untuk infrastruktur

• Diagram mesin keadaan untuk perilaku siklus hidup

Visual Paradigm dapat mendukung proses pemodelan ini dengan menyediakan alat untuk membuat diagram UML, mengorganisasi model, berkolaborasi dengan anggota tim, dan menghasilkan dokumentasi teknis. Pendekatan yang paling efektif bukanlah menggunakan setiap diagram UML secara sembarangan, melainkan memilih diagram yang memperjelas pertanyaan desain penting.

Ketika digunakan secara konsisten dan dijaga agar selaras dengan sistem yang sebenarnya, UML menjadi lebih dari sekadar kumpulan simbol: ia menjadi bahasa desain bersama yang menghubungkan persyaratan bisnis, arsitektur perangkat lunak, implementasi, pengujian, dan pemeliharaan jangka panjang.

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