Dan di bawah ini adalah hasil penilaian berdasarkan metrics level method pada sistem pada paper dan program Character Graphics.

Evaluasi: Paper

RtnCalToNbr
Method yang paling banyak memanggil method lain : pada proyek sableCC sebanyak lebih dari 250 method.
Perlu di split menjadi bagian yang lebih kecil
RtnCalFromNbr
85% method dipanggil antara 0 s/d 5 method lain. Method yang paling banyak dipanggil sebanyak 1829 kali oleh method lain. Semakin sering method tersebut dipanggil, menunjukkan method tersebut penting dan biasanya cukup simpel.
RtnStmExeNbr
90% method yang ada pada sistem yang diujikan memiliki kurang dari 25 baris statement
RtnCndNbr
Method-method yang kompleks dapat ditemui pada proyek Swing dan JavaAST.

Evaluasi: Character Graphics

RtnCalToNbr
Method yang paling banyak memanggil method lain : DrawingPackage.Interact() dan DrawingPackage.ApplyDragTool()
RtnCalFromNbr
Method yang paling banyak dipanggil Screen.DrawPixel()
RtnStmExeNbr
Statement yang paling banyak dalam 1 method: 28 statement yaitu pada method DrawingPackage.ApplyDragTool()
RtnCndNbr
Nilai maksimum adalah 12 Kondisi dapat ditemui pada method DrawingPackage.ApplyDragTool()

Sub-bagian Attribute

Berikut adalah metrics untuk level kelas sub-bagian atributte:

Dan berikut adalah hasil penilaian metrics terhadap sistem pada paper maupun pada Character Graphics

Evaluasi: Paper

• Kelas-kelas dengan nilai ClaAttNbr tinggi:

1. JDK(118); KeyEvent.java; enumerasi, mapping events untuk mengatur keyboard
2. Swing(110);Constant.java; mapping untuk HTML tag
3. JavaAST(245); JavaParser.java; parsing state machine
4. OSS(70); maps data repository

• Tingkat ClaAttHid pada OSS sudah cukup bagus. KFC, CUP, AntLR dan JavaAST memiliki hasil yang rendah.
• Di OSS, ClaAttPubNbr sangat rendah, hanya 129 dari 3435 atribut yang bersifat public, 37% dari atribut bersifat private.
• Untuk ClaAttPriNbr, OSS memiliki 37% dari total atribut yang bersifat private, sedangkan pada KFC bernilai 25%, CUP 28%, AntLR 8,4% dan JavaAST 15,6%
• Rendahnya ClaAttPubNbr dan tingginya ClaAttPriNbr mencerminkan level enkapsulasi sistem yang baik
• Untuk metrik ClaAttStaNbr, 15% atribut di OSS static. Pada sistem berbasis Java, persentase lebih tinggi, JDK(57%), Swing(40%), CUP(65%), dan JavaAST(78%). Kelas dengan jumlah atribut static tinggi biasanya adalah kelas repositori informasi sistem.

Evaluasi: Character Graphics

• Kelas dengan ClaAttProNbr tinggi adalah Cshape.
• Untuk metrik ClaAttStaNbr, hanya 3.9% atribut di Character Graphics berupa atribut static.

Sub-bagian Method

Berikut adalah metrics untuk level kelas sub-bagian method

Berikut adalah hasil penilaian metrics untuk sistem yang ada pada paper dan juga program Character Graphics

Evaluasi: Paper

• Untuk ClaMetNbr, kelas-kelas yang memiliki nilai maksimum tinggi adalah:

1. JavaASR(481); kelas JavaParser; parser dari analyzer source code
2. Swing(420); kelas html32; parser dari file HTML
3. SableCC(315); kelas DepthFirstAdapter

• Untuk ClaMetPubNbr, rata-rata pada semua sistem sudah cukup tinggi. Pengecualian pada JavaAST(40%).
• Untuk metrik ClaMetStaNbr, anomali terdapat pada JavaAST(84% methodnya bersifat static)

Evaluasi: Character Graphics

• Semua method sistem bersifat public, dengan jumlah method terbanyak (15) ada pada kelas Cshape
• Hanya satu dari 61 method yang bersifat static, yaitu method main

Sub-bagian Class

Berikut adalah metrics untuk level kelas sub-bagian method

Berikut adalah hasil penilaian metrics untuk level kelas sub-bagian method pada sistem di paper dan Character Graphics

Evaluasi: Paper

• Untuk ClaMsgNbr, nilai yang tinggi mengindikasikan kelas yang mungkin kompleksitasnya tinggi.

1. JavaAST(726) JavaParser
2. Swing(444) html32
3. SableCC(315) DepthFirstAdapter

• ClaClaNstNbr, pada OSS, hanya ada 8 kemunculan. Anomali pada KFC(45) dan Swing(38).
• Pada KFC nilainya tinggi karena nested class diutilisasi sebagai sebuah callback
• Pada Swing metric ini bernilai tinggi karena memang perlu diperbaiki. (Pada rilis Swing selanjutnya, masalah ini telah diselesaikan)
• Untuk ClaCstrNbr, metrik ini tidak tersedia di OSS karena keterbatasan tool pada pengujian. Tingginya nilai metrik ini mengindikasikan kemungkinan kompleksitas kelas juga tinggi. Contohnya adalah kelas pada KFC(17) dan JDK(13).Untuk ClaNamLen, secara umum >8 karakter sudah dianggap mencukupi. Secara rata-rata, metrik ini lebih tinggi pada sistem-sistem Java dibandingkan di sistem C++

Evaluasi: Character Graphics

• Untuk ClaMsgNbr, nilai tertinggi terdapat pada kelas CShape(19). Tetapi, banyak method di CShape yang hanya berupa abstract yang akan didefinisikan lagi pada kelas turunan, sehingga CShape tidak tergolong kelas yang kompleks.
• Untuk metrik ClaNstNbr, semua kelas bernilai satu karena tiap file hanya berisikan sebuah kelas.
• Begitu juga untuk ClaCstrNbr, tiap kelas hanya memiliki sebuah constructor. Sehingga, kelas-kelas pada Character Graphics bisa digolongkan tidak kompleks
• Untuk metrik ClaNamLen, secara rata-rata penamaan kelas Character Graphics masih kurang baik, kecuali untuk kelas DrawingPackage(14)

Metode penilaian lewat abstraksi source code cocok pada sistem yang sangat besar, dengan dukungan tool otomatis untuk melakukan abstraksi source code. Nilai metrics dan representasi grafis harus diintrepetasikan dengan “judgement” tersendiri, bukan dengan cara membandingkan hasil tersebut dengan panduan yang sudah fix. Jadi diharapkan bahwa penilaian kualitas perangkat lunak tidak berdasar pada suatu rentang angka dari nilai metrics. Janganlah menganggap bahwa jika nilai dari sebuah metric rendah, maka sistem tersebut memiliki kualitas yang buruk, tetapi cobalah gunakan rendahnya nilai metric tersebut untuk penanda bahwa, ada bagian sistem yang mungkin memiliki cacat sehingga bisa diperbaiki.

Pada Level sistem ada beberapa hal yang penting, di antaranya:

• Beberapa tipe perangkat lunak, seperti Parser, harus mempunyai nilai metrics tersendiri. Peran parser sebagai penerjemah kode menjadi bahasa mesin, tentunya memiliki komplesitas yang berbeda dengan perangkat lunak biasa yang menangani tugas-tugas biasa. Di sini bisa kita tanamkan bahwa tiap jenis program atau perangkat lunak seharusnya memiliki metrics yang spesifik untuk jenis tersebut.
• Source code hasil generate otomatis, harus masuk pertimbangan dan sudut pandang yang berbeda dengan source code biasa. Beberapa program bisa dibuat dengan hanya menjalankan suatu program lain untuk membuatnya. Tentunya, perangkat lunak hasil buatan bukan manusia tidak bisa disandingkan dengan perangkat lunak buatan manusia yang lebih fleksibel.
• Metrics seharusnya digunakan sebagai guideline inspeksi, bukan sebagai dasar sistem penilaian. Dengan adanya guideline inspeksi, proses peningkatan kualitas perangkat lunak bisa berjalan lebih cepat, karena pengembang bisa langsung berfokus kepada area yang memang menunjukkan indikasi adanya kemungkinan eror.

Pada Level Kelas, beberapa metrics baru diusulkan untuk membantu mengivestigasi sistem secara spesifik dan efisien. Dengan makin banyaknya aplikasi besar yang dibuat dengan desain berorientasi objek, semakin banyak pula kelas yang harus diinspeksi. Dengan adanya metrics yang khusus untuk level kelas, tentunya beban pengembang bisa lebih dikurangi, karena hanya kelas-kelas yang memiliki anomali bisa diinspeksi dan diberikan tanda sebagai area beresiko. Sehingga, evaluato dan pengembangr bisa bekerja lebih cepat dalam menginvestigasi area beresiko pada sistem yang sangat besar.

Pada Level Method,jika sebuah sistem memiliki persentasi method private tinggi, dimungkinkan untuk mengasumsikan bahwa desain sistem tersebut berfokus pada mengijinkan akses dari luar melalui sejumlah kecil method public, atau Façade system design.

Kesimpulan untuk penilaian program Character Graphics

Penggunaan metrics yang diajukan pada paper ini kurang tepat, karena ditujukan untuk sistem yang sangat besar. Pada sistem character graphics, anomali dari suatu area kurang terlihat karena kurangnya variasi data.
Pada level sistem, metrics ini digunakan hanya untuk melihat gambaran sistem secara keseluruhan, dan membantu evaluasi pada level berikutnya. Sedangkan pada level Kelas, ada beberapa hal harus didalamim yaitu:

• Kelas CShape cenderung memiliki nilai metrik yang mencolok baik dari bagian method atau class, tetapi jika dikaji lebih lanjut, ternyata CShape banyak terdiri dari abstract method yang kompleksitasnya terbagi di kelas turunan dari CShape, yaitu CRect, CCircle, dan Ctext
• Dengan semua method yang bersifat public dan tidak adanya method private, bisa dikatakan bahwa Character Graphics tidak mengadopsi desain sistem Façade.

Pada level Method, dari data penilaian, bisa dilihat bahwa kelas DrawingPackage adalah kelas yang memiliki method yang paling banyak memanggil oleh method lain, yaitu method Interact() dan ApplyDragTool().Secara total, method yang paling banyak dipanggil adalah method DrawPixel(). Hal ini wajar, karena inti dari program Character Graphics adalah menggambar bentuk, sehingga method DrawPixel() tentunya berperan besar dalam program ini.

Sedangkan, hasil dari pengukuran metrics, baik dari sistem yang diteliti dalam paper, maupun program Character Graphics, ada dalam tabel di bawah.

Evaluasi metrics sistem pada paper

ClaInhDirNbr

• Hanya 6% kelas di proyek OSS yang menggunakan multiple inheritance
• Java hanya mengizinkan satu pewarisan, sehingga maksimal selalu 1.

ClaChdDirNbr

• Pada sistem java jumlah parent class umumnya berkisar diantara 0 sampai 4.
• Pada SableCC terdapat dua kelas dengan jumlah anak 36 dan 62, yang merupakan Node dan kelas Token.
• JavaAST dihasilkan dari SableCC
• Swing memiliki 9 buah kelas yang memiliki anak lebih dari 10.
• Pada OSS dan JDK, kelas yang memiliki jumlah anak banyak biasanya kelas yang berhubungan dengan kelas utilitas.

ClaInhIndNbr

• Pada OSS tidak begitu diperlukan karena 94% kelas hanya menggunakan pewarisan tunggal.
• ClaIntChdDirNbr
• Swing dan KFC yang merupakan toolkit user -interface,, menggunakan interface-extension lebih banyak.

ClaInhLvl

• Pada sistem java, mayoritas project memeiliki kelas pewarisan dengan dengan kedalaman satu atau dua tingkat. Kelas pada OSS yang memiliki tingkat pewarisan dengan kedalaman 9 merupakan kelas yang over engineered.

ClaIntLvl

• Rata-rata tingkat kedalaman interface pada sistem java adalah satu atau dua.

Metode yang diusulkan dalam paper bertujuan untuk menemukan dan menandai pada bagian sistem yang mempunyai karakteristik tidak biasa. Dengan diketahuinya bagian-bagian sistem yang memiliki karakterisitik tidak biasa/anomali, pengembang bisa meneliti bagian tersebut lebih lanjut, untuk mengetahui sumber dari anomali, dan memperbaikinya.

Level of Granularity

Untuk mengetahui bagian-bagian yang memiliki anomali, penilaian dikerjakan berdasarkan metrics. Karena sistem-sistem yang diujikan dalam penilaian mengadopsi desain berorientasi objek, maka metric yang diterapkan pun berorientasi objek (Object Oriented Metrics). Dasar dari OO metrics yang diadopsi adalah, level of granularity. Level of granularity berarti tingkat kedetilan dari struktur perangkat lunak. Pada perangkat lunak berorientasi objek, kita bisa memandangnya dari tiga level kedetilan;level system, level class, dan level method. Pada masing-masing level, terdapat metrics tersendiri yang mengeksplorasi sistem dari tingkat kedetilan yang berdasarkan pada level of granularity. Penjelasan lebih lanjut dapat dilihat pada pembahasan tentang masing-masing metrics.

Data dan tool penilaian

Tool yang digunakan adalah Datrix toolset yang dikembangkan sendiri oleh Bell Canada khusus untuk abstraksi source code sistem yang besar. Untuk Sistem yang berbasis Java, digunakan juga java parser yang dibuat dengan menggunakan JavaCC. Abstaksi dari source code memiliki dua tahap. Tahap pertama adalah abstraksi source code menjadi Abstract Syntax Tree (AST). Abstaksi kedua adalah abstraksi dari AST menjadi Intermediate Representation Language (IRL). Dalam bentuk IRL, terkandung cukup informasi yang diperlukan untuk menghitung metrics dan membuat representasi grafis dari sistem. IRL ini menggunakan UML sebagai dasarnya, berikut adalah gambaran dari abstraksi source code yang digunakan.

Penelitian ini menggunakan sembilan sistem beorientasi objek yang berukuran besar. Ditambahkan juga satu sistem sederhana berbasis Java yang merupakan bagian dari tugas Kuliah dari kontributor blog. Berikut adalah tabel yang menjelaskan sistem-sistem yang digunakan sebagai data penilaian.

Bisa dilihat dari besarnya sistem-sistem yang digunakan, maka tool untuk abstraksi source code otomatis mutlak dibutuhkan. Khusus untuk sistem kesepuluh, kontributor melakukan perhitungan manual karena sistem tersebut cukup kecil.

Seiring dengan berkembangnya teknologi informasi, penyerapan penggunaan teknologi informasi ke segala bidang mulai merata. Hampir segala aspek kehidupan manusia modern berkaitan dengan teknologi informasi. Dengan begitu pentingnya teknologi informasi dalam kehidupan, perangkat lunak ,sebagai salah satu pilar utama dari teknologi informasi, juga berkembang. Sistem perangkat lunak modern, kini semakin besar dan dikembangkan oleh sebuah tim, dan dituntut untuk selesai dengan cepat dan dengan eror yang seminimal mungkin. Untuk mengakomodasi tuntutan-tuntutan tersebut, dibutuhkan sebuah penilaian dari kualitas sebuah sistem perangkat lunak. Ada berbagai cara untuk menilai kualitas dari sebuah sistem perangkat lunak, yaitu:

• Mewawancarai arsitek dan desainer dari sistem. Walaupun dengan cara ini dapat menghasilkan informasi berharga tentang struktur dan arsitektur dari sistem, tetapi terkadang hasilnya tidak merepresentasikan kondisi aktual sistem secara objektif. Para arsitek dan desainer sistem juga terkadang cenderung menyembunyikan kelemahan dari sistem rancangan mereka.
• Cara kedua adalah dengan mereview dari life cycle awal sistem, seperti dokumen analisis dan desain. Sama halnya dengan wawancara, cara ini juga dapat memberikan informasi yang bagus dan terperinci mengenai struktur desain sistem. Namun, terkadang, sistem aktual yang telah berjalan tidak selalu mengikuti desain awal seperti pada dokumen. Karena terkadang, pada proses implementasi, developer melakukan berbagai penyesuaian dan perubahan pada desain, namun tidak melakukan juga perubahan pada dokumen analisis dan desain, sehingga, hasil dari penilaian tidak merepresentasikan kondisi aktual sistem.
• Cara ketiga adalah dengan melakukan abstraksi source code. Cara ini memiliki banyak keunggulan dibandingkan cara-cara sebelumnya. Dengan abstraksi source code, kita bisa mendapatkan hasil yang presisi, tidak bias, bisa diotomasi dan dapat diaplikasikan terhadap sistem yang sangat besar dengan tools tertentu.

Penilaian kualitas sistem perangkat lunak yang akan dibahas berdasarkan white-box approach, sehingga penguji diharapkan memiliki pemahaman tentang struktur dari sistem yang dinilai. Pengujian juga dilakukan terfokus pada sistem yang mengadaptasi desain berorientasi objek, dalam kasus ini menggunakan bahasa C++ dan Java. Metode yang diajukan di sini, lebih menekankan untuk menemukan dan menandai pada bagian sistem yang mempunyai karakteristik tidak biasa, bukan untuk memberikan sebuah standar baku yang menggeralisasi kualitas sebuah perangkat lunak dalam sebuah rentang nilai.

Berikut adalah detil dari paper yang menjadi acuan:
Reference Type: Journal Article
Author: Mayrand, Jean
Author: Patenaude, Jean-François
Author: Merlo, Ettore
Author: Dagenais, Michel
Author: Laguë, Bruno
Primary Title: Software assessment using metrics: A comparison across large C++ and Java systems
Journal Name: Annals of Software Engineering
Cover Date: 2000-05-01
Publisher: Springer Netherlands
Issn: 1022-7091
Subject: Computer Science
Start Page: 117
End Page: 141
Volume: 9
Issue: 1
Url: http://dx.doi.org/10.1023/A:1018924724621
Doi: 10.1023/A:1018924724621

Kelas Repositori

Kelas repositori adalah kelas yang berfungsi sebagai penyimpanan informasi dalam suatu sistem. Contoh sederhana dari kelas repositori pada Java adalah kelas Math. Kelas Math memiliki dua atribut, yaitu E (menyimpan basis logaritma natural) dan PI (menyimpan nilai dari π ), dan kedua atribut kelas Math tersebut bersifat static.

Mengapa atribut kelas repositori bersifat static?

Untuk menjawab pertanyaan ini kita perlu mengkaji kegunaan parameter static pada Java. Jika sebuah atribut (ataupun method) dideklarasikan sebagai static, maka atribut tersebut tidak terikat pada suatu objek tertentu, tetapi terikat pada kelas yang diinstansiasikan dalam bentuk objek. Atribut static juga dialokasikan ketika kelas yang bersangkutan di-load, bukan ketika objek dari kelas tersebut dibuat.
Apa perbedaannya? Jadi, jika sebuat objek kelas dengan atribut biasa kita buat, maka nilai dari atribut tersebut akan selalu diberikan nilai baru/default. Lain halnya dengan kelas berisi atribut static, karena terikat kepada kelas, bukan objek, maka ketika kita membuat objek baru, maka nilai dari atribut dari objek tidak mengikuti nilai default, tetapi nilai atribut yang telah ada. Untuk lebih jelasnya bias dilihat dari contoh.

Program contoh:

public class StaticVariable{
static int noOfInstances;
StaticVariable(){
noOfInstances++;
}
public static void main(String[] args){
StaticVariable sv1 = new StaticVariable();
System.out.println("No. of instances for sv1 : " + sv1.noOfInstances);


StaticVariable sv2 = new StaticVariable();
System.out.println("No. of instances for sv1 : " + sv1.noOfInstances);
System.out.println("No. of instances for st2 : " + sv2.noOfInstances);

StaticVariable sv3 = new StaticVariable();
System.out.println("No. of instances for sv1 : " + sv1.noOfInstances);
System.out.println("No. of instances for sv2 : " + sv2.noOfInstances);
System.out.println("No. of instances for sv3 : " + sv3.noOfInstances);

}
}

Output dari program:

C:\java>java StaticVariable
No. of instances for sv1 : 1
No. of instances for sv1 : 2
No. of instances for st2 : 2
No. of instances for sv1 : 3
No. of instances for sv2 : 3
No. of instances for sv3 : 3


Bisa dilihat pada hasil output, bahwa nilai dari atribut StaticVariable tidak mengikuti dari pembuatan objek, tetapi dari pembuatan kelas. Sehingga nilai StaticVariable pada sv1, sv2, dan sv3 selalu sama walaupun mereka adalah objek yang berbeda.

Kesimpulan

Kembali kepada permasalahan awal mengenai kegunaan atribut static pada kelas repositori, dapat diambil kesimpulan bahwa, alasan penggunaan atribut static adalah demi keseragaman nilai dari atribut kelas repositori tersebut, Sehingga, walalupun perubahan nilai atribut dilakukan oleh objek yang telah hilang karena masuk garbage collector, nilai dari atribut kelas tetap ada dan valid.

Mengapa method main pada program Java selalu bersifat static?

Method pada Java

Pada Java, agar sebuah method dapat diakses, harus melewati beberapa prosedur terlebih dahulu. Pertama-tama, method harus merupakan bagian dari sebuah kelas, dan yang kedua agar bisa diakses, maka objek dari kelas yang mengandung method tersebut harus diinstansiasi. Setelah dua tahap ini, maka method tersebut bisa kita akses dengan cara memanggil:

Objek.method(parameter1, parameter2);

Pengecualian untuk method main

Pada method main, hal ini menjadi masalah, karena jika suatu program Java dijalankan, maka yang pertama kali berjalan adalah method main, tanpa ada instansiasi dari objek apapun terlebih dahulu. Hal ini diatasi dengan menjadikan main sebagai method static. Dengan adanya embel-embel static, berarti method main tidak terikat pada suatu objek tertentu untuk diakses, sehingga langkah kedua yang telah disebutkan bisa dilewati.

Sumber:

• Java Static Variable Example, Static Variable in Java
• Why main method in Java always public and static