de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Diagram Urutan UML: Memvisualkan Waktu dan Interaksi

Diagram Urutan UML adalah alat penting untuk memahami perilaku dinamis suatu sistem. Diagram ini memodelkan bagaimana objek saling berinteraksi dan urutan terjadinya interaksi tersebut, menekankan pada aliran pesan yang diurutkan menurut waktu. Sangat penting untuk mendefinisikan kasus penggunaan, mendokumentasikan pemanggilan API, dan melacak alur transaksi yang kompleks.

Tutorial ini akan memandu Anda melalui elemen dasar dan teknik pemodelan dari Diagram Urutan.

Struktur Inti dan Tujuan

Diagram Urutan diatur berdasarkan dua sumbu:

  1. Sumbu Horizontal: Menampilkan partisipan Objek (atau aktor, kelas, dan komponen).
  2. Sumbu Vertikal (Sumbu Waktu): Mewakili aliran waktu, bergerak ke bawah. Pesan yang dikirim lebih rendah pada diagram terjadi lebih akhir dalam urutan.

Axis-of-sequence-diagram

Tujuannya adalah untuk menjawab pertanyaan: “Dalam skenario tertentu (kasus penggunaan ini), dalam urutan apa objek-objek ini bertukar informasi untuk mencapai hasil yang diinginkan?”

Elemen Dasar dari Diagram Urutan

Untuk memodelkan suatu urutan, Anda memerlukan tiga elemen inti: Lifeline, Pesan, dan Batang Aktivitas.

A. Lifeline (Partisipan)

Lifeline mewakili satu partisipan—objek, instans, atau kelas—dalam interaksi.

  • Notasi: Kotak persegi panjang di bagian atas diagram yang berisi nama objek, dengan garis putus-putus vertikal yang menjulur ke bawah.
  • Sintaks:
    • NamaPartisipan (jika objek adalah instans, misalnya pengguna)
    • NamaInstans: NamaKelas (misalnya authService: AuthenticationService)
  • Tujuan: Garis putus-putus menunjukkan keberadaan peserta sepanjang waktu dalam lingkup urutan.

lifeline

B. Pesan (Interaksi)

Pesan adalah panah horizontal yang digambar antara garis hidup. Mereka mewakili komunikasi antar objek, seperti pemanggilan metode, sinyal, atau permintaan API.

Messages-(Interaction)

Jenis Pesan:

Jenis Pesan Notasi Deskripsi
Panggilan Sinkron Garis padat dengan kepala panah yang terisi Pengirim menunggu respons sebelum melanjutkan. Ini memicu Batang Aktivasi pada garis hidup penerima.
Balasan/Kembalian Garis putus-putus dengan kepala panah terbuka Balasan terhadap panggilan sinkron, menunjukkan kembalinya kendali ke pengirim. Ini biasanya menutup Batang Aktivasi.
Pesan Asinkron Garis padat dengan kepala panah terbuka Pengirim tidak menunggu respons dan langsung melanjutkan eksekusi sendiri. Umum digunakan dalam arsitektur berbasis peristiwa.
Panggilan Diri Panah yang melingkar kembali ke garis hidup yang sama Sebuah objek memanggil salah satu metode miliknya sendiri.
Pesan Ditemukan Panah yang dimulai dari suatu titik akhir dan mengenai garis hidup Pengirim pesan tidak diketahui atau berada di luar lingkup diagram (misalnya, pemicu eksternal).

C. Batang Aktivasi (Spesifikasi Eksekusi)

Batang Aktivasi (juga disebut fokus kendali) adalah persegi panjang vertikal tipis yang digambar di atas garis hidup.

  • Notasi: Persegi panjang vertikal padat pada garis hidup.
  • Tujuan: Ini menunjukkan periode saat suatu objek secara aktif melakukan operasi (yaitu, metodenya sedang berjalan) atau menunggu balasan sinkron. Ini dimulai ketika pesan sinkron diterima dan berakhir ketika pesan balasan dikirim.

Pemodelan Logika dan Alur Kontrol

Untuk memodelkan logika bisnis yang kompleks, Anda menggunakan fragmen (atau kotak) untuk mengelilingi bagian-bagian dari diagram.

A. Fragmen Gabungan

Fragmen gabungan memungkinkan Anda memodelkan logika bersyarat, pengulangan, dan langkah opsional. Fragmen yang paling umum meliputi:

  1. Alternatif (alt):Digunakan untuk if-elselogika. Fragmen dibagi oleh garis putus-putus, dan setiap bagian mencakup kondisi (sebuah “pengaman”) dalam tanda kurung siku. Hanya satu jalur yang dapat diambil.
    • Contoh: [jika kredensial pengguna valid] dan [selain itu / kredensial tidak valid].
  2. Opsi (opt):Digunakan untuk ifpernyataan. Interaksi di dalam fragmen bersifat opsional dan hanya dieksekusi jika kondisi (pengaman) benar.
    • Contoh: [jika pengguna memiliki barang di keranjang].
  3. Perulangan (loop):Digunakan untuk pengulangan. Pengaman menentukan kondisi iterasi (misalnya, [untuk setiap item] atau [selama (percobaan < 3)]).
  4. Referensi (ref):Digunakan untuk memodularisasi diagram dengan merujuk pada urutan interaksi yang didefinisikan dalam diagram urutan lain yang terpisah. Ini mencegah diagram menjadi terlalu berantakan.
  5. Kritis (crit): Digunakan untuk menunjukkan bagian yang tidak boleh terganggu, sering digunakan untuk memodelkan proses paralel.

Contoh Pemodelan Langkah demi Langkah

Mari kita modelkan versi yang disederhanakanProses Checkout Pengguna menggunakan elemen inti:

Langkah Aksi Jenis Pesan
1. Pengguna mengklik “Checkout.” Panggilan Sinkron
2. Frontend memvalidasi keranjang. Panggilan Diri (di Frontend)
3. Frontend meminta pemrosesan pembayaran. Panggilan Sinkron
4. Gerbang Pembayaran memeriksa dana. Panggilan Sinkron
5. Gerbang Pembayaran mengembalikan “Sukses.” Pesan Balik
6. Frontend mengirim pesan asinkron ke layanan Inventaris untuk mengurangi stok. Pesan Asinkron
7. Frontend mengirim pesan sinkron ke layanan Pesanan untuk menyelesaikan pesanan. Panggilan Sinkron
8. Layanan Pesanan mengembalikan “ID Pesanan.” Pesan Kembali
9. Frontend menampilkan halaman konfirmasi. Pesan Kembali (ke Pengguna)

Logika Pemodelan (Fragment Alternatif)

Untuk menangani kegagalan, kami menggunakan Alternatif fragment:

  1. Tempatkan Pemeriksaan Gateway Pembayaran (Langkah 4 & 5) di dalam alt fragment.
  2. Bagian pertama dilindungi oleh [Sukses]. Bagian ini berisi Langkah 6, 7, 8, dan 9.
  3. Bagian kedua, dibagi oleh garis putus-putus, dilindungi oleh [Kegagalan]. Bagian ini berisi pesan sinkron baru: paymentService -> frontend: kembalikan "Pembayaran Gagal" dan Frontend menampilkan halaman kesalahan.

Ringkasan Praktik Terbaik Diagram Urutan

  • Jaga Fokusnya: Diagram Urutan tunggal biasanya harus memodelkan satu kasus penggunaan tunggal atau satu operasi atomik (misalnya, “Masuk”, “Tambahkan Barang ke Keranjang”). Gunakan Fragment Referensi untuk sub-proses.
  • Label Pesan dengan Jelas: Gunakan frasa kata kerja untuk pesan, mencerminkan nama metode atau titik akhir API (misalnya, processPayment(jumlah, token)).
  • Identifikasi Peserta dengan Benar: Bedakan antara Aktor (entitas eksternal) dan Objek (komponen sistem internal atau instans).
  • Waktu Mengalir ke Bawah: Pastikan pesan dipesan secara konsisten dari atas ke bawah.
  • Gunakan Fragmen untuk Kontrol: Hindari menggambar simpul keputusan kompleks atau loop di dalam aliran pesan itu sendiri; gunakan alt, opt, dan loop fragmen.

Untuk mendapatkan detail lebih lanjut tentang UML dan metode visualisasi berbasis AI-nya, kunjungi pusat sumber daya UML kamipusat sumber daya UML.

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