Panduan Lengkap tentang Pemodelan CRC (Kelas Tanggung Jawab Kolaborator)

Berdasarkan prinsip dasar analisis berorientasi objek (OO), panduan ini menjelaskan proses pemodelan CRC. Pemodelan CRC adalah metodologi yang sangat efektif dan sederhana yang dirancang untuk menutup kesenjangan komunikasi antara pengembang dan pengguna, memastikan bahwa kebutuhan bisnis diidentifikasi dan dipahami secara akurat sebelum kode ditulis.

---

1. Konsep Utama: Anatomi Kartu CRC

Pemodelan CRC mengandalkan kartu indeks standar yang dibagi menjadi tiga bagian yang berbeda. Setiap bagian mewakili konsep utama dalam desain berorientasi objek.

A. Kelas (Bagian Atas Kartu)

Kelas mewakili kumpulan objek yang serupa. Sebuah objek dapat berupa orang, tempat, benda, peristiwa, konsep, layar, atau laporan yang relevan terhadap sistem.

• Aturan Penamaan: Gunakan satu atau dua kata tunggal (misalnya Pelanggan, bukan Pelanggan).

• Contoh: Dalam sistem pengiriman/inventaris, kelas-kelas meliputi Item Inventaris, Pesanan, Item Pesanan, Pelanggan, dan Alamat Permukaan.

B. Tanggung Jawab (Kolom Kiri)

Sebuah tanggung jawab adalah segala sesuatu yang dimiliki atau dilakukan oleh sebuah kelas tahu atau lakukan.

• Apa yang diketahui (Data/Atribut): Contoh: Sebuah Pelanggan kelas mengetahui nama, nomor pelanggan, dan nomor teleponnya.

• Apa yang dilakukan (Perilaku/Metode): Contoh: Sebuah Pelanggan kelas dapat memesan produk, membatalkan pesanan, dan melakukan pembayaran.

C. Kolaborator (Kolom Kanan)

Kolaborasi terjadi ketika sebuah kelas membutuhkan informasi atau bantuan dari kelas lain untuk memenuhi tanggung jawabnya.

• Contoh: Sebuah Pesanan objek memiliki tanggung jawab untuk ‘menghitung total.’ Namun, ia tidak mengetahui harga barang atau jumlah pesanan. Oleh karena itu, ia harus kolaborasi dengan Item Pesanan (yang mengetahui jumlahnya) dan Item Persediaan (yang mengetahui harga) untuk menghitung total akhir.

---

2. Tim Pemodelan CRC

Sesi CRC yang sukses membutuhkan peran-peran tertentu untuk memastikan proses berjalan lancar dan secara akurat menangkap logika bisnis.

1. Ahli Bidang Bisnis (BDEs): Pengguna aktual dari sistem (biasanya 4 hingga 5 staf lapangan). Mereka memiliki pengetahuan bisnis sehari-hari. Catatan: Eksekutif umumnya tidak ideal untuk CRC; mereka lebih cocok untuk Use Case tingkat tinggi.

2. Fasilitator: Menjalankan sesi, menjelaskan teknik, mengajukan pertanyaan yang relevan, memastikan kartu diisi dengan benar, dan memimpin pengujian skenario.

3. Pencatat(s): 1 atau 2 orang yang duduk di belakang/samping. Mereka tidak secara aktif memodelkan tetapi mencatat logika bisnis dan aturan rinci yang tidak muat pada kartu indeks kecil.

4. Pengamat: Peserta pelatihan atau pemangku kepentingan yang duduk di belakang dan hanya menonton tanpa ikut serta.

---

3. Proses Pemodelan CRC 6 Langkah

Langkah 1: Kumpulkan Tim

Kumpulkan 4-5 BDE garis depan, seorang fasilitator, dan 1-2 penulis catatan. Pastikan dukungan manajemen agar peserta dapat meluangkan waktu yang diperlukan.

Langkah 2: Atur Ruangan

• Permukaan yang bisa ditulis: Buku flip atau papan tulis untuk brainstorming dan prototipe.

• Meja pemodelan: Meja besar di tengah untuk BDE menempatkan dan memindahkan kartu.

• Stasiun penulis catatan: Meja yang diletakkan di tempat yang tidak mengganggu tetapi tetap memiliki pandangan jelas.

• Perlengkapan: Kartu indeks, spidol, dan sebuah bola lunak dan kenyal (digunakan nanti untuk pengujian skenario).

Langkah 3: Brainstorming

Hasilkan ide tanpa menilainya terlebih dahulu. Fasilitator mengajukan pertanyaan terbuka untuk memahami kebutuhan bisnis.

• Contoh Pertanyaan: “Untuk siapa sistem ini?”, “Kebutuhan bisnis apa yang didukung?”, “Bagaimana kita bisa melakukannya lebih cepat/murah/lebih baik?”, “Apakah ada tugas sederhana yang bisa kita otomatiskan?”

Langkah 4: Jelaskan Tekniknya

Fasilitator menghabiskan waktu 10–15 menit menjelaskan konsep CRC, menampilkan definisi secara mencolok di dinding, dan membimbing tim dalam membuat beberapa kartu contoh.

Langkah 5: Pemodelan CRC Iteratif

BDE berdiri atau duduk di sekitar meja dan secara iteratif membangun model:

• Temukan Kelas: Ikuti alur uang, cari laporan/tampilan, dan identifikasi 3-5 kelas utama segera.

• Temukan Tanggung Jawab: Tanyakan apa yang diketahui dan dilakukan oleh kelas tersebut.

• Tentukan Kolaborator:Tentukan siapa yang memiliki informasi yang hilang yang diperlukan untuk memenuhi suatu tanggung jawab.

• Atur Kartu: Langkah Penting.Kartu-kartu yang sering bekerja sama ditempatkan berdekatan di atas meja. Kartu-kartu ‘sibuk’ ditempatkan di tengah. Memindahkan kartu secara fisik membantu tim memvisualisasikan hubungan dan kaitan antar kartu.

Langkah 6: Pengujian Skenario Use-Case (Latihan ‘Melempar Bola’)

Ini adalah latihan validasi di mana tim ‘menghidupkan’ alur kerja sistem untuk memastikan model akurat.

1. Sebutkan Skenario:Pemandu menjelaskan sebuah use-case (misalnya, ‘Pelanggan memesan pesanan’) dan melempar bola lunak ke BDE yang memegang kartu tanggung jawab awal (misalnya,Pesanan).

2. Tentukan Tanggung Jawab:Kelompok mengonfirmasi bahwa kartu tersebut menangani tugas tersebut. Jika tidak, mereka memperbarui atau membuat kartu baru.

3. Jelaskan Logika:BDE yang memegang bola menjelaskan logika bisnis langkah demi langkah (kode semu) kepada penulis catatan.

4. Berkolaborasi:Jika BDE membutuhkan informasi dari kelas lain (misalnya,Item Persediaan), mereka melempar bola ke BDE yang memegang kartu tersebut. BDE tersebut kemudian menjelaskan bagian logikanya.

5. Kembalikan Bola:Setelah suatu tugas selesai, bola dilempar kembali ke orang sebelumnya, hingga akhirnya kembali ke pemandu untuk memulai skenario berikutnya.

---

4. Bagaimana CRC Masuk ke Dalam SDLC

Pemodelan CRC tidak berdiri sendiri; ia merupakan bagian dari proses pemodelan berbasis objek yang lebih luas yang bersifatserial dalam skala besar (berpindah dari kebutuhan ke desain ke kode) daniteratif dalam skala kecil (bolak-balik antar model).

• Tingkat Rincian:CRC berada di tengah. Anda memulai dengan yang sederhana menggunakanUse Case danPrototipe Antarmuka Pengguna, pindah ke detail sedang dari Model CRC, dan selesaikan dengan detail tinggi dari Diagram Kelas.

• Hasil Kerja Mendorong Hasil Kerja: Diagram use-case didokumentasikan oleh use-case, yang didokumentasikan oleh diagram urutan, yang akhirnya mendorong kode sumber. Model CRC langsung memberi masukan ke dalam pembuatan diagram kelas.

---

5. Praktik Terbaik & Tips Keberhasilan

1. Kirimkan Agenda: Bagikan agenda beberapa hari sebelumnya agar BDE dapat mempersiapkan diri.

2. Tampilkan Definisi: Tempelkan tata letak kartu CRC besar dan definisinya di depan ruangan.

3. Gunakan Terminologi Domain: Hindari istilah teknis; gunakan kata-kata persis yang digunakan BDE dalam pekerjaan sehari-hari mereka.

4. Jaga agar Tetap Rendah Teknologi: Alat untuk CRC bersifat opsional saja. Kartu indeks murah, portabel, dan sangat efektif.

5. Siapkan untuk Membuat Prototipe: Menggambar layar dan laporan pada papan flip-chart selama sesi membantu pengguna membayangkan sistem tersebut.

6. Rencanakan untuk Beberapa Hari: Sistem besar membutuhkan beberapa sesi. Ini normal dan diperlukan.

7. Dapatkan Dukungan Manajemen: Pastikan pimpinan memahami nilai pemodelan sebelum pemrograman.

8. Fokuskan pada Staf Lapangan: CRC sangat detail dan paling efektif digunakan oleh pengguna harian, bukan eksekutif tingkat tinggi.

---

6. Kelebihan dan Kekurangan

Kelebihan

• Ahli melakukan analisis: Orang-orang yang benar-benar melakukan pekerjaan membangun model tersebut.

• Dukungan Pengguna yang Tinggi:Partisipasi aktif meningkatkan kepuasan pengguna dan rasa memiliki.

• Menghancurkan hambatan:Pengguna dan pengembang bekerja berdampingan.

• Sederhana dan Tidak Menakutkan:Ini hanyalah kartu indeks. Pengguna tidak merasa terintimidasi oleh alat perangkat lunak yang rumit, dan mereka tidak merasa pekerjaan mereka diambil alih oleh sebuah ‘mesin’.

• Murah dan Portabel:Harganya beberapa dolar dan muat dalam tas tangan.

• Transisi yang Mulus:Sangat cocok dengan prototipe dan langsung berlanjut ke diagram kelas formal.

Kekurangan

• Mengancam bagi beberapa pengembang:Beberapa pengembang keliru menganggap pengetahuan teknis mereka lebih unggul daripada pengetahuan bisnis pengguna.

• Penjadwalan sulit:Mendapatkan 4-5 pengguna kunci dalam satu ruangan pada waktu yang sama membutuhkan perencanaan terlebih dahulu.

• Kartu terbatas:Tumpukan kartu indeks bukanlah hasil akhir formal yang dapat diterima oleh sebagian besar organisasi. CRC harus dilengkapi dengan kasus penggunaan formal, prototipe, dan diagram kelas.

---

Kesimpulan

Tujuan akhir pengembangan aplikasi adalah untukmenyelesaikan masalah bisnis, bukan untuk memuaskan rasa ingin tahu intelektual pengembang dengan teknologi baru. Pemodelan CRC mendorong pengembang untuk bekerjabersamapengguna, bukan melawan mereka. Dengan memanfaatkan lingkungan yang rendah teknologi dan sangat kolaboratif, tim dapat secara akurat menangkap, memvalidasi, dan menyempurnakan kebutuhan bisnis sebelum satu baris kode pun ditulis.