Mengukur Kualitas Rancangan Object Oriented Dengan JDepend


Beberapa mahasiswa yang punya rasa ingin tahu yang besar pasti akan bertanya bagaimana merancang sistem dengan baik.   Sejujurnya, saya sendiri tidak tahu apa jawabannya.   Tapi satu hal yang pasti: untuk mencari tahu jawabannya, saya perlu mengetahui apa itu definisi rancangan sistem yang “baik” (ideal).   Definisi ini sebaiknya bisa diukur dalam bentuk angka, misalnya seperti pada penelitian Object-Oriented Design Quality Metrics (2004) oleh Andersson & Vestergren.

JDepend adalah sebuah tools yang dapat dipakai untuk mengukur metric yang menentukan kualitas rancangan dengan menganalisa class-class Java yang ada.   JDepend akan mengukur tingkat extensibility, reusability, dan maintainability dari sebuah rancangan (berdasarkan class-class yang ada dalam rancangan tersebut!) .  Tapi nilai metric yang ada tidak dapat langsung menjadi patokan penilaian baik dan buruk; masih dibutuhkan banyak penelitian untuk memperoleh hasil yang konsisten mengenai definisi rancangan yang “baik” secara kuantitatif (dalam bentuk angka).

JDepend dapat di-download di http://www.clarkware.com/software/jdepend-2.9.1.zip. Setelah download, extract isi folder ke sebuah folder, misalnya ke lokasi C:\Programs.   Pada versi distribusinya, saya tidak menemukan cara singkat untuk memanggil JDepend. Oleh sebab itu, saya membuat sebuah batch file dengan nama run.bat di C:\Programs\jdepend-2.9.1. Isi dari batch file tersebut adalah:

@set CLASSPATH=%CLASSPATH%;%CD%\lib\jdepend-2.9.1.jar;%CD%
@set /p lokasi=Masukkan lokasi folder berisi class yang akan diproses: 
java jdepend.swingui.JDepend %lokasi% %*

Selain itu, pada folder yang sama, saya membuat sebuah file dengan nama jdepend.properties yang isinya seperti berikut ini:

ignore.java=java.*,javax.*
ignore.sun=sun.*,com.sun.*
ignore.frameworks=org.*,com.mysema.*,com.itext.*,com.itextpdf.*

Package yang didefinisikan pada file di atas akan diabaikan.   Hal ini saya lakukan karena package di atas berisi class yang dipakai tetapi bukan hasil rancangan yang akan diuji.

Berikutnya, saya dapat menjalankan JDepend dengan memberikan perintah seperti berikut ini:

C:>cd C:\Programs\jdepend-2.9.1

C:\Programs\jdepend-2.9.1>run
Masukkan lokasi folder berisi class yang akan diproses: C:\projects\target\class

Tampilan GUI JDepend akan muncul beserta hasil analisa, seperti yang terlihat pada gambar berikut ini:

Contoh Tampilan JDepend

Contoh Tampilan JDepend

Bagaimana cara membaca hasil analisa tersebut? Nilai metric yang ada diambil dari buku Agile Software Development: Principles, Patterns, and Practices karangan Robert Cecil Martin.   Informasi lebih lanjut ada di artikel Wikipedia http://en.wikipedia.org/wiki/Software_package_metrics.

Sebagai contoh, pada domain model yang saya rancang, diperoleh nilai metric seperti berikut ini:

  • CC (Concrete Class Count) = 17
    Jumlah class yang dapat dibuat instance-nya secara langsung.
  • AC (Abstract Class Count) =  3
    Jumlah class abstract & interface.
  • Ca (Afferent Couplings) = 7
    Jumlah package lain yang memakai package ini.
  • Ce (Efferent Couplings) = 0
    Jumlah package lain yang dipakai oleh package ini.
  • A (Abstractness) = 0,15
    Rasio class abstract & interface; nilai A=0 menunjukkan package ini sepenuhnya konkrit dan nilai A=1 menunjukkan package ini sepenuhnya abstract.
  • I (Instability) = 0
    Menunjukkan seberapa stabil package ini terhadap perubahan; nilai I=0 menunjukkan package sepenuhnya stabil dan nilai I=1 menunjukkan package sepenuhnya tidak stabil.
  • D (Distance from the Main Sequence) = 0,85
    Nilai ini menunjukkan keseimbangan antara abstraksi dan stabilitas; range nilai ini dari 0 hingga 1 dimana nilai ideal adalah 0.
  • V (Volatility) = 1
    Nilai ini dapat diatur melalui jdepend.properties; nilai V=0 menunjukkan package tidak akan pernah diubah dan nilai V=1 menunjukkan bahwa package dapat berubah suatu saat nanti. Secara default, nilai V dianggap 1.

Nilai yang penting disini adalah nilai D (Distance from the Main Sequence). Apa itu Main Sequence?  Sebuah rancangan yang ideal dianggap memiliki salah satu sifat berikut ini:

  • Rancangan yang sangat stabil (I=0) dan sangat abstrak (A=1), atau
  • Rancangan yang sangat tidak stabil (I=1) dan sangat konkret (A=0).

Bila nilai D mendekati 0, maka hasil rancangan saya mendekati rancangan ideal.   Sebaliknya, bila nilai D semakin jauh dari 0 (hingga maksimal 1), maka hasil rancangan semakin jauh dari ideal.

Dari hasil rancangan saya, bila diurutkan berdasarkan nilai D, saya akan memperoleh urutan seperti berikut ini:

  1. web.controller (D = 0,08)
  2. service (D = 0,25)
  3. web.view (D = 0,3)
  4. repository (D = 0,33)
  5. util.formatter (D = 0,33)
  6. util.validator (D = 0,43)
  7. security (D = 0,6)
  8. web (D = 0,67)
  9. domain (D = 0,85)
  10. web.form (D = 1)
  11. web.jackson (D = 1)

Wow, saya sudah merancang berdasarkan saran terbaik dari para pakar ditambah pengalaman pribadi, tapi kenapa masih ada nilai D=1?   Bukankah nilai D=1 adalah nilai yang paling buruk?

Isi package web.form dan web.jackson adalah class yang dipakai untuk konversi dari/ke JSON untuk keperluan AJAX, misalnya data tabel beserta informasi halaman untuk jqGrid.   Bila class yang ada disini berubah, saya harus mengubah view dan parameter POST dan GET yang dilewatkan di kode program JavaScript jQuery, dan lainnya.   Oleh sebab itu, saya selalu berusaha agar class disini tidak berubah (nilai perlu atur nilai V=0?)

Nilai D terjelek berikutnya adalah domain model (D=0,85). Domain model mewakili elemen dalam proses bisnis sehingga saya selalu berusaha sebisa mungkin agar domain model tidak berubah! Kenapa? Karena perubahan besar pada domain model berarti harus merombak service layer, controller dan view!!! Kata kuncinya adalah selalu analisa yang matang.   Well, mungkin nilai 0,85 memang pantas saya dapatkan untuk rancangan yang tidak agile.

Beruntungnya, seluruh layer yang sering berubah seperti controller dan service layer memiliki nilai D yang bagus. Yup! Itu sebabnya saya senang sekali perubahan seperti “tolong ubah ini supaya bisa dihapus” atau “saya ingin ini bisa otomatis”.

Dengan metrik kualitatif seperti ini, saya bisa mengetahui bagian dari rancangan yang harus diperbaiki atau ditingkatkan. Saya pun menjadi semakin memahami kelebihan dan kekurangan hasil rancangan sendiri.

Perihal Solid Snake
I'm nothing...

Apa komentar Anda?

Please log in using one of these methods to post your comment:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: