Object Oriented Metrics

1
Kriteria Kode Berkualitas Tinggi
• Harus agile, misalnya kode yang ditulis dapat di-
reuse
• Sangat penting kode harus dapat di-maintain
sehingga mudah dipahami dan di-koreksi
• Agar kode dapat di-maintain, maka tidak boleh
terlalu kompleks, misalnya terlalu banyak
predikat, terlalu banyak coupling dan cohesion
diantara obyek-obyek
• Standard software quality model, ISO 9126 (ISO
1991) : Totalitas fitur-fitur dan karakteristik
produk yang memenuhi kebutuhan yang ditulis
atau secara implisit
2
 Definisi[1]
• Pengukuran software berkaitan dengan
menurunkan nilai numerik untuk sebuah atribut
entitas produk atau proses software
• Atribut adalah sifat dari suatu entitas
• Entitas software = produk dan proses
• Berbagai macam tipe pengukuran yang
berhubungan dengan sistem, proses atau
dokumen terkait dalam software
– Lines of code dalam program, banyaknya orang-hari
yang dibutuhkan untuk mengembangkan komponen
• Memungkinkan software dan proses software
untuk dikuantisasi
3
 Definisi[2]
• Software metric dihitung berdasar dua/lebih
ukuran
• Contohnya : sebuah metriks berupa cacat
program per KLOC. Sebuah ukuran adalah hasil
pengukuran langsung(KLOC), dimana sebuah
metriks adalah hasil perhitungan menggunakan
dua/lebih ukuran
• Dalam penggunaan : metric dan measurement
adalah sinonim dan sering digunakan sebaliknya

4
 OO Metric Suite
• Terdapat beberapa peneliti OO Metric
• Chidamber dan Kemerer's metrics suite untuk
desian OO merupakan riset terdalam dalam OO
metric. Mereka mendefiniskan 6 metriks untuk
desain OO
• Chidamber & Kemerer metrics suite yang asli
terdiri atas 6 metriks yang dihitung untuk setiap
class, yakni : WMC, DIT, NOC, CBO, RFC and
LCOM.
• Metric suite yang asli telah diamandemen oleh
RFC´, LCOM*, LCOM** oleh peneliti lainnya

5
 Weighted Methods per Class
(WMC)[1]
• Mendefinisikan kompleksitas sebuah obyek
• Banyaknya method dan kompleksitas method
merupakan indikator berapa banyak waktu dan
usaha yang diperlukan untuk mengembangkan
dan memelihara obyek
• Semakin besar jumlah methos dalam sebuah
obyek, semakin besar dampaknya pada derived
class karena derived class akan menurunkan
semua method dalam obyek
• Semakin banyak methos dapat menyebabkan
sebuah “too application specific object”
sehingga membatasi kemungkinan reuse
6
 Weighted Methods per Class
(WMC)[2]
• Definisi
• Misalnya sebuah class Class1 dengan
methods M1, M2, …Mn. Dengan c1, c2, …
cn adalah kompleksitas statis dari method-
method
• WMC = Σi=1nCi , dimana n adalah jumlah
dari method dalam class
• Jika semua kompleksitas statis dianggap
sama, maka WMC = n
7
 Lack of Cohesion in Methods
(LCOM)
• Cohesion sebuah class adalah karakteristik seberapa
dekat method-method lokal terhubung dengan variabel-
variabel lokal dalam sebuah class. S.R Chidamber and
C.F Kemerer adalah yang pertama mendefiniskan
metriks LCOM pada 1991
• Metriks LCOM adalah nilai ketidaksamaan method-
method dalam sebuah class
• Nilai LCOM yang tinggi dalam sebuah class
mengindikasikan lebih baik jika class tersebut dipecah
menjadi dua atau lebih sub-class. Hal ini karena class
tersebut mungkin terlalu banyak mempunyai tugas untuk
dilakukan sehingga akan lebih baik untuk menggunakan
obyek yang lebih spesifik
8
 Lack of Cohesion in Methods
(LCOM)
• Definisi Chidamber-Kemerer
• Terdapat sebuah class C1 dengan n method M1, M2, …,
Mn. Dengan {Ij} = himpunan variabel instance yang
digunakan oleh method Mi. Terdapat sebanyak n
himpunan {I1}, …, {In}. Dengan P = {(Ii, Ij) | Ii ∩ Ij = ø} dan
Q = {(Ii, Ij) | Ii ∩ Ij ≠ ø}. Jika semua himpunan n {I1}, …,
{In} adalah ø maka kemudian P = ø.
• LCOM = |P| - |Q|, if |P| > |Q|. Otherwise LCOM = 0
• Definisi himpunan yang tidak berisisan yang diusulkan
Chidamber-Kemerer sepertinya ambigu dan kemudian
didefinisikan ulang oleh Li dan Henry

9
 Lack of Cohesion in Methods
(LCOM)*
• Definisi Li-Henry
• LCOM* = banyaknya himpunan tidak
beririsan dari method-method lokal; tidak
ada dua himpunan beririsan; sembarang
dari dua method dalam himpunan yang
sama yang sharing sedikitnya satu lokal
variabel instance; dari 0 sampai N; dimana
N bernilai integer positif

10
 Lack of Cohesion in Methods
(LCOM)**
• Definisi Henderson-Sellers
• LCOM** = (mean(p(f) ) - m ) ÷ (1 – m)
• Dimana m adalah jumlah method yang terdefinisi dalam
sebuah class A. Dengan F adalah himpunan atribut yang
didefinisikan A. Maka dengan p(f) adalah jumlah method-
method yang mengakses atribut f, dimana f adalah
anggota F.
• Pada kasus cohesion sempurna( semua method-method
mengakses semua atribut ) nilai LCOM**=0. Class yang
total tidak cohesive( dimana setiap method hanya
mengakses sebuah variabel tunggal ) menghasilkan
LCOM** = 1

11
 Depth of Inheritance Tree (DIT)
• Inheritance adalah ketika suatu class membagi struktur
dan behaviour yang sama yang didefinisikan pada class
lain. Inheritance melalui class-class meningkatkan
efisiensi dengan mengurangi redudansi. Namun semakin
dalam hirarki inheritance, semakin besar kemungkinan
kompleksitasnya dan sulit untuk diprediksi behaviour-nya
• Untuk mengukur kedalaman hirarki, Shyam R.
Chidamber dan Chris F. Kemerer pada 1991
mengusulkan metriks the depth of inheritance tree
• Definisi Chidamber-Kemerer
• Depth of inheritance dari class adalah metriks DIT untuk
class. Pada kasus multiple inheritance, DIT adalah
panjang maksimum dari node ke root dari tree

12
Depth of Inheritance Tree (DIT)
• W. Li memperkenalkan metriks baru yang
disebut Number of Ancestor Classes (NAC).
Metriks ini adalah altenatif DIT dengan dasar
teori dan sudut pandang yang sama tapi dengan
definisi sbb.
• Definisi Wei Li
• NAC mengukur total jumlah class-class induk
dimana sebuah class menurunkannya dari
hirarki inheritance class

13
 Number of Children (NOC)[1]
• Untuk mengindikasikan level reuse dalam sebuah sistem
karenanya dapat mengindikasikan level dari testing yang
dibutuhkan
• Semakin besar jumlah anak( derived class ) dalam suatu
hirarki inheritance maka semakin besar reuse-nya,
karena inheritance adalah sebuah bentuk reuse. Namun
jika class atau package mempunya anak yang banyak
maka memungkinkan timbulnya kasus sub-clasing yang
salah, karena kemiripan abstraksi yang tidak tepat dari
class induk dan memungkinkan testing yang lebih
terhadap method-method

14
 Number of Children (NOC)[2]
• Chidamber dan Kemerer mengusulkan lebih baik
mempunyai kedalaman daripada kelebaran dalam hirarki
inheritance, DIT tinggi dan NOC rendah. Dalam opini
Sheldon, Jerath dan Chung :
– Premis utama kami berpendapat bahwa semakin dalam pohoh
hirarki inheritance semakin baik reusability, namun semakin
buruk untuk pemeliharaan. Semakin dangkal hirarki,
berkuranglah abstraksi namun semakin mudah dipahami dan
dimodifikasi. Pada sudut pandang pemeliharaan,
direkomendasikan pohon inheritance yang dalam harus dipecah
menjadi sebuah pohon inheritance yang dangkal
• NOC = jumlah subclass yang menjadi subordinat pada
sebuah class pada hirarki class

15
Response For a Class (RFC)[1]
• Jika sebuah class terdiri atas banyak method maka
sepertinya kompleksitas dari class tinggi
• Dan jika banyak method dapat dipanggil untuk
merespons pesan yang diterima oleh sebuah obyek dari
suatu class maka sepertinya pemeliharaan dan testing
menjadi kompleks
• Respons untuk metriks class bertujuan untuk mengukur
banyaknya method lokal dan banyaknya method yang
dipanggil oleh method lokal
• Tidak terdapat nilai threshold spesifik pada metriks RFC.
Namun Chidamber and Kemerer menyarankan semakin
besar nilai RFC, semakin besar level pemahaman yang
diperlukan sebagai bagian dari tester

16
Response For a Class (RFC)[2]
• Definisi
• RFC = |RS| dimana RS adalah himpunan respons untuk class yang
diberikan
• RS = {M} Uall i {Ri}
• dimana {Ri} = himpunan method-method yang dipanggil oleh
method i dan
• {M} = himpunan semua method-method dalam class
• Ilustrasi definisi di atas :
• A::f1() memanggil B::f2()
• A::f2() memanggil C::f1()
• A::f3() memanggil A::f4()
• A::f4() tidak memanggil method lain
• Then RS = {A::f1, A::f2, A::f3, A::f4} U {B::f2} U {C::f1} U {A::f4}
• = {A::f1, A::f2, A::f3, A::f4, B::f2, C::f1} sehingga RFC = 6

17
Coupling Between Objects (CBO)[1]
• Definisi
– CBO sebuah class adalah penjumlahan banyaknya
class-class lain dimana class tersebut di-couple
• Sebuah class di-couple ke yang lain jika method
sebuah class menggunakan method-method
atau atribut-atribut yang lain atau sebaliknya
• Coupling between objects untuk sebuah class
adalah banyaknya class-class lain dimana class
tersebut di-couple

18
Coupling Between Objects (CBO)[2]
• Class-class yang CBO berlebihan akan mengganggu
desain modular dan mencegah reuse. Semakin sebuah
class independen semakin mudah di-reuse dalam
aplikasi lain
• Untuk tujuan meningkatkan modularitas dan mendukung
enkapsulasi, inter-object class coupling seharusnya
dijaga tetap minimum. Semakin banyak couple, semakin
besar sensivitas untuk mengubah di bagian lain dalam
desain sehingga pemeliharaan lebih sulit
• Ukuran coupling berguna untuk menentukan seberapa
kompleks testing berbagai bagian dari desain. Semakin
tinggi inter-object class coupling semakin teliti testing
yang dibutuhkan
19
 Referensi[1]
• Chidamber S.R., Kemerer, C.F.: "A metrics suite for
object-oriented Design", IEEE Transactions on SW
Engineering, Vol. 20, No.6, June 1994
• Fabrizio Riguzzi:"A Survey of Software Metrics",
Università degli Studi di Bologna, July 1996
• Lionel Briand, Khaled El Emam, Sandro Morasca :"On
the Application of Measurement Theory in Software
Engineering",International Software Engineering
Research Network technical report #ISERN-95-04
• Magnus Andersson, Patrik Vestergren : "Object-Oriented
Design Quality Metrics", Uppsala Master’s Theses in
Computer Science 276, 2004-06-07, ISSN 1100-1836,
Information Technology Computing Science Department
Uppsala University Sweden

20
 Referensi[2]
• The Project Manager’s Guide to Software
Engineering’s Best Practice, Mark J. Christensen
and Richard H. Thayer, IEEE Computer Society
Press
• Norman Fenton:"Software Measurement: A Necessary
Scientific Basis", IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING. VOL. 20, NO. 3, MARCH
I994 I99
• Everald E. Mills : “ Software Metrics”, SEI Curriculum
Module SEI-CM-12-1.1, Software Engineering Institute,
Carnegie Mellon University, December 1988
• Goal-Question-Metrics files on the internet

21