Belajar System Analyst - UML & Diagram

#Pendahuluan

Setelah di episode 5 kalian bisa menuliskan kebutuhan dalam use case dan user story, sekarang kita naikkan ke level visual: UML (Unified Modeling Language). Episode ini fokus pada empat diagram yang paling sering dipakai System Analyst sehari-hari — use case (kilat balik), activity, sequence, dan class.

Mengapa diagram penting kalau teks sudah ada? Karena otak manusia memproses struktur spasial jauh lebih cepat daripada paragraf. Satu sequence diagram menjelaskan interaksi enam komponen lebih baik daripada dua halaman prosa, dan cabang logika yang tersembunyi di teks akan langsung tampak sebagai belokan di activity diagram. Diagram juga bahasa netral: manajer bisnis, developer, dan QA membaca gambar yang sama.

#Peta UML untuk Analyst

UML 2.x mendefinisikan banyak tipe diagram, tetapi dalam pekerjaan harian analyst hanya segelintir yang benar-benar terpakai:

Diagram	Menjawab	Audiens Utama	Frekuensi Pakai
Use case	Siapa bisa melakukan apa?	Stakeholder bisnis	Sedang
Activity	Alur proses & keputusan bagaimana?	Bisnis + dev	Sangat sering
Sequence	Komponen saling bertukar pesan bagaimana?	Developer	Sering
Class	Struktur data & relasi seperti apa?	Developer	Sering
State	Status objek berpindah bagaimana?	Dev (kasus tertentu)	Kadang
Component/Deployment	Susunan modul & infrastruktur?	Architect/dev	Kadang

Prinsipnya sama dengan dokumentasi: gambar yang cukup, bukan lengkap. Empat diagram di atas menutup 90% kebutuhan komunikasi analyst.

#Activity Diagram

Activity diagram adalah flowchart standar UML untuk alur kerja: mulai, aktivitas, keputusan, fork/join paralel, selesai. Cocok untuk proses bisnis dan logika fitur.

Contoh alur pembayaran kasir TokoKita:

100%

Elemen baku yang layak dipakai konsisten: lingkaran penuh = awal, lingkaran berbingkai = akhir, wajik = decision, garis tebal = fork/join untuk aktivitas paralel. Saat proses nyata punya langkah bersamaan — misal mencetak struk sambil mengirim notifikasi WA ke owner — gunakan fork, bukan urutan palsu.

#Sequence Diagram

Sequence diagram menunjukkan urutan pertukaran pesan antar objek/komponen sepanjang waktu dari atas ke bawah. Inilah diagram favorit developer saat menerima spesifikasi integrasi atau alur antar-lapisan aplikasi.

Contoh skenario sinkronisasi offline:

100%

Dua konvensi penting: pesan solid-arrow berarti panggilan sinkron, arrow terbuka untuk respons/asinkron; dan kotak Note menyelamatkan pembaca dari konteks yang tak tertulis. Jika alur kalian punya kondisi, gunakan blok alt (cabang) dan loop seperti contoh — itu yang membuat sequence jauh lebih informatif daripada daftar bernomor.

#Class Diagram

Class diagram memodelkan struktur statis: entitas, atribut, metode, dan relasi antar kelas. Untuk analyst, fokus utamanya bukan metode melainkan domain model — data apa yang hidup di sistem dan bagaimana hubungannya. Ini jembatan langsung ke ERD di episode 9.

Versi domain model ringkas untuk TokoKita:

100%

Notasi multiplisitas yang wajib lancar: 1 ke * (satu ke banyak), 0..1 (opsional), 1..* (minimal satu). Relasi yang sering disalahpahami: association (hubungan umum), aggregation (bagian-dari tapi bisa hidup sendiri), composition (bagian mati jika induk mati). Untuk domain analysis, association biasa sudah cukup — jangan over-engineer notasi.

#Praktik: Menggambar di draw.io

Alur kerja efektif membuat diagram untuk TokoKita:

Mulai dari use case UC-01 (episode 5) — main flow-nya menjadi tulang punggung activity diagram.
Gambar activity diagram pembayaran; minta kasir mengecek ulang: "ada cabang yang tidak saya gambar?" Setiap "oh iya kadang begini..." adalah alternative flow baru.
Turunkan sequence diagram dari exception flow offline — inilah yang dikonsumsi tim backend.
Tutup dengan class diagram domain; validasi nama atribut dengan kolom file Excel cabang agar istilah konsisten dengan dunia nyata mereka.
Ekspor PNG/SVG, simpan di folder 03-design/uml/, dan cantumkan versi + tanggal di pojok diagram.

Tip

Simpan file sumber (.drawio), bukan hanya hasil ekspor. Diagram yang tidak bisa diedit akan usang dalam dua sprint karena tak ada yang mau menggambar ulang dari nol. Versikan seperti kode: uml-pembayaran-v3.drawio.

#Kesalahan Umum

Diagram hiasan tanpa audiens — menggambar state machine lengkap untuk diskusi dengan owner yang butuh peta cakupan. Tentukan dulu siapa yang membaca, baru pilih tipe.
Satu raksasa semua-tahu — diagram A0 berisi seluruh sistem tak terbaca. Pecah per use case atau per sub-domain.
Inkonsisten dengan teks — activity diagram bilang retur butuh approval manajer, use case tidak menyebutnya. Diagram dan dokumen teks harus disinkronkan; satu sumber kebenaran per keputusan.
Detail implementasi bocor — class diagram yang menampilkan tabel database persis (tipe kolom, index) mengunci desain prematur di fase analisis. Simpan detail fisik untuk fase desain teknis.

Warning

Diagram UML bukan tujuan, melainkan media berpikir dan berkomunikasi. Kalau satu screenshot WhatsApp sudah cukup menjawab pertanyaan developer, jangan paksa gambar sequence. Ukurannya: apakah keputusan jadi lebih cepat dan lebih tepat?

#Penutup

Inti yang harus dibawa pulang:

Empat diagram inti analyst: use case (cakupan), activity (alur & keputusan), sequence (pesan antar komponen), class/domain (struktur data).
Activity untuk proses bisnis dan logika cabang; sequence untuk spesifikasi interaksi teknis; class untuk model domain menuju ERD.
Derivasi yang efisien: use case → activity → sequence → class, divalidasi stakeholder di tiap langkah.
Simpan file sumber, versikan diagram, dan selalu tanya "siapa audiensnya" sebelum menggambar.

Diagram kalian sudah menggambarkan perilaku. Di episode 7 selanjutnya kita menyatukan semuanya menjadi dokumen induk: System Design Document — struktur SDD yang rapi, cara menulis arsitektur dan data flow, serta praktik menyusun SDD lengkap TokoKita yang siap jadi pegangan tim dev. Pastikan tetap semangat!