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