Metrik kode - Kopling kelas

Kopling kelas juga dikenal dengan nama Coupling Between Objects (CBO) seperti yang awalnya didefinisikan oleh CK94. Pada dasarnya, kopling kelas adalah ukuran seberapa banyak kelas yang digunakan oleh satu kelas. Angka tinggi buruk dan angka rendah biasanya baik dengan metrik ini. Konektor kelas telah terbukti sebagai prediktor kegagalan perangkat lunak yang akurat dan studi terbaru telah menunjukkan bahwa nilai batas atas 9 adalah S2010 yang paling efisien.

Menurut dokumentasi Microsoft, pengaitan kelas "mengukur pengaitan ke kelas unik melalui parameter, variabel lokal, tipe pengembalian, panggilan metode, instansiasi generik atau template, kelas dasar, implementasi antarmuka, bidang yang didefinisikan pada tipe eksternal, dan dekorasi atribut. Desain perangkat lunak yang baik menentukan bahwa jenis dan metode harus memiliki kohesi tinggi dan konektor rendah. Kopling tinggi menunjukkan desain yang sulit digunakan kembali dan dipertahankan karena banyak saling ketergantungan pada jenis lain."

Konsep kopling dan kohesi jelas terkait. Untuk menjaga diskusi ini tentang topik, kita tidak akan mendalami kohesi selain memberikan definisi singkat dari KKLS2000:

"Kohesi modul diperkenalkan oleh Yourdon dan Constantine sebagai 'seberapa erat atau terkait elemen internal modul satu sama lain' YC79. Modul memiliki kohesi yang kuat jika mewakili tepat satu tugas [...], dan semua elemennya berkontribusi pada satu tugas ini. Mereka menggambarkan kohesi sebagai atribut desain, bukan kode, dan atribut yang dapat digunakan untuk memprediksi penggunaan kembali, pemeliharaan, dan perubahan."

Contoh Kopling Kelas

Mari kita lihat class coupling dalam praktik. Pertama, buat aplikasi konsol baru dan buat kelas baru yang disebut Orang dengan beberapa properti di dalamnya kemudian segera hitung metrik kode:

Perhatikan bahwa kopling kelas adalah 0 karena kelas ini tidak menggunakan kelas lain. Sekarang buat kelas lain yang disebut PersonStuff dengan metode yang membuat objek dari kelas Person dan menetapkan nilai properti. Hitung metrik kode lagi:

Lihat bagaimana nilai tautan antar kelas meningkat? Perhatikan juga bahwa, tidak peduli berapa pun jumlah properti yang Anda tetapkan, nilai keterhubungan kelas hanya naik sebesar 1 dan bukan dengan nilai lain. Kopling kelas mengukur setiap kelas untuk metrik ini hanya sekali, tidak peduli seberapa sering ia digunakan. Selain itu, dapatkah Anda melihat bahwa DoSomething() memiliki 1 tetapi konstruktor, PersonStuff(), memiliki 0 untuk nilainya? Saat ini tidak ada kode di konstruktor yang menggunakan kelas lain.

Bagaimana jika Anda menempatkan kode di konstruktor yang menggunakan kelas lain? Berikut adalah apa yang Anda dapatkan:

Sekarang konstruktor dengan jelas memiliki kode yang menggunakan kelas lain dan metrik konektor kelas menunjukkan fakta ini. Sekali lagi, Anda dapat melihat kopling kelas keseluruhan untuk PersonStuff() adalah 1 dan DoSomething() juga 1 untuk menunjukkan bahwa hanya satu kelas eksternal yang digunakan, tidak peduli seberapa banyak kode internal yang Anda miliki yang menggunakan kelas tersebut.

Selanjutnya, buat kelas baru lainnya. Beri nama kelas ini dan buat beberapa properti di dalamnya:

Sekarang gunakan kelas dalam metode kami DoSomething() dalam PersonStuff kelas dan hitung metrik kode lagi:

Seperti yang Anda lihat, keterhubungan kelas untuk kelas PersonStuff naik menjadi 2 dan, jika Anda menelusuri lebih dalam kelas tersebut, Anda dapat melihat bahwa metode DoSomething() memiliki keterhubungan terbanyak di dalamnya tetapi konstruktor tetap hanya menggunakan 1 kelas. Dengan menggunakan metrik ini, Anda dapat melihat jumlah maks keseluruhan untuk kelas tertentu dan menelusuri detail berdasarkan per anggota.

Angka Ajaib

Seperti halnya kompleksitas siklomatik, tidak ada batasan yang sesuai dengan semua organisasi. Namun, S2010 memang menunjukkan bahwa batas 9 optimal:

"Oleh karena itu, kami mempertimbangkan nilai ambang [...] sebagai yang paling efektif. Nilai ambang batas ini (untuk satu anggota) adalah CBO = 9[...]." (penekanan ditambahkan)

Analisis Kode

Analisis kode mencakup kategori aturan Keberlanjutan. Untuk informasi selengkapnya, lihat aturan pemeliharaan . Saat menggunakan analisis kode warisan, seperangkat aturan Extended Design Guideline berisi area pemeliharaan:

Di dalam area pemeliharaan terdapat aturan untuk keterkaitan kelas:

Aturan ini mengeluarkan peringatan ketika penggandengan kelas berlebihan. Untuk informasi selengkapnya, lihat CA1506: Hindari keterhubungan kelas yang berlebihan.

Kutipan

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Rangkaian Metrik untuk Desain Berorientasi Objek (Transaksi IEEE pada Rekayasa Perangkat Lunak, Vol. 20, No. 6). Diakses tanggal May 14, 2011, dari situs web University of Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., dan Saint-Denis, G. (2000). Class Cohesion Revisited: Studi Empiris tentang Sistem Industri (Prosiding Lokakarya tentang Pendekatan Kuantitatif dalam Rekayasa Perangkat Lunak Berorientasi Objek). Diakses tanggal 20 Mei 2011, dari situs web Université de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). Analisis Empiris Metrik CK untuk Kesulitan Desain Berorientasi-Objek: Dampaknya terhadap Cacat Perangkat Lunak (Jurnal IEEE Transactions on Software Engineering, Vol. 29, No. 4).

S2010

Shatnawi, R. (2010). Investigasi Kuantitatif Tingkat Risiko metrik Object-Oriented yang Dapat Diterima dalam Sistem Open-Source (Transaksi IEEE pada Rekayasa Perangkat Lunak, Vol. 36, No. 2).

YC79

Edward Yourdon dan Larry L. Constantine. Desain Terstruktur. Prentice Hall, Englewood Cliffs, N.J., 1979.