Aditya Ideawan#1, Siti Rochimah#2
Teknik Informatika, Institut Teknologi Sepuluh Nopember
Jl. Teknik Kimia, Gedung Teknik Informatika, Kampus ITS Sukolilo, Surabaya, 60111 1ideawan11@mhs.if.its.ac.id
2siti@its-sby.edu
Abstract — Transitions between versions of software libraries
that change their API become a problem for developers who use it. Solutions that are available to date either challenge library developer or user developer. Both solutions have strengths and weaknesses. On this paper, both library and user solutions were combined and were carried out by a third party called repository. This repository mediated the library and user developers. The source codes were stored and analyzed to compare the difference in the repository. As a result of the analysis, changelogs are stored and queried based on user requests. Results from the experiment showed that this solution produces more evolution detection and processes faster than the previous solution.
Keywords — code refactor, repository, software evolution
I. PENDAHULUAN
Perpindahan versi pustaka perangkat lunak yang menyertakan perubahan pada application programming interface (API) pustaka menyebabkan pengguna pustaka enggan untuk berpindah versi. Pengguna pustaka diharuskan untuk merubah kode sumber sesuai dengan perubahan pada pustaka yang dipindah. Sampai saat ini perpindahan dilakukan secara manual dan perubahan-perubahannya harus ditangani langsung oleh programmer.
Penelitian-penelitian mengenai solusi otomatis untuk mengatasi perpindahan evolusi API sampai saat ini[1][2][3] masih membebankan pengembang pustaka atau pengguna pustaka. Solusi dari pengembang pustaka, menggunakan berkas perubahan yang disertakan pada pustakanya untuk direfaktor lewat integrated development environment (IDE).
Solusi dari pengguna pustaka, berkas-berkas kode sumber dari dua versi pustaka dianalisis untuk mengetahui bagian- bagian yang berubah dan diambil yang relevan untuk direfaktor.
Solusi dari pengembang pustaka memiliki keuntungan yaitu pengguna pustaka mendapatkan berkas analisis perubahan tanpa perlu menganalisis. Kelemahannya adalah perubahan versi tergantung yang disediakan oleh pengembang pustaka sehingga perubahan versi yang terlalu jauh menyulitkan pengguna pustaka karena diharuskan untuk menerapkan perubahan berulang-ulang sejumlah perbedaan versi pustakanya.
Solusi dari pengguna pustaka memiliki keuntungan yaitu pengembang pustaka tidak harus melakukan analisis dan versi kode sumber tidak terbatas dari versi yang disediakan. Kelemahannya adalah pengguna pustaka harus melakukan analisis terhadap kode sumber untuk dilakukan refaktor. Analisis pada pengembang pengguna pustaka biasanya membutuhkan waktu yang lebih dibandingkan dari pengembang pustaka.
Kedua solusi tersebut dipadukan menjadi solusi baru yang diharapkan dapat menutupi kekurangan dari masing- masing solusi dan mengambil kelebihannya. Solusi baru tersebut menggunakan repositori pustaka perangkat lunak sebagai pihak ketiga antara pengembang pustaka dan pengembang pengguna pustaka sekaligus penyedia pustaka perangkat lunak. Solusi ini diharapkan dapat membantu meringankan pengembang pengguna pustaka sehingga mau memperbaharui versi pustaka perangkat lunak yang digunakannya yang pada akhirnya meningkatkan kinerja dari program yang dibuatnya.
II. SOLUSI EVOLUSI API
Sampai saat ini, solusi otomatisasi perubahan pada API pustaka perangkat lunak masih membebankan dua pihak, yaitu pihak pengembang pustaka [2][3] atau pihak pengguna pustaka [1]. Solusi pihak pengembang pustaka menggunakan berkas perubahan yang dihasilkan dari pengembang pustaka, sedangkan solusi pihak pengguna pustaka menggunakan berkas perubahan yang dihasilkan dari analisis antara dua versi kode sumber pustaka. Kedua solusi menggunakan berkas perubahan untuk direfaktor ke dalam berkas kode sumber penggunanya.
A. Solusi Pengembang Pustaka
Solusi dari pengembang pustaka dilakukan dengan mengirimkan berkas perubahan bersamaan dengan pembaharuan versi pustakanya. Berkas perubahan berisikan perubahan-perubahan yang terjadi dengan versi sebelumnya. Berkas ini mirip dengan catatan perubahan (changelog) hanya saja berkas ditujukan untuk penyolok (plugin) IDE yang merefaktor kode sumber penggunanya.
Solusi ini dimulai dari pengembang pustaka yang merubah kode sumber untuk meningkatkan versi
pustakanya. Pada solusi [2], pengembang menggunakan penyolok IDE untuk merekam perubahan dari kode sumber ke dalam berkas perubahan. Berkas perubahan ini dikirimkan bersamaan dengan pustaka biner atau kode sumber pustaka. Pengguna pustaka merubah kode sumbernya berdasarkan berkas perubahan lewat IDE dengan penyolok khusus untuk membaca dan merefaktor berkas perubahan. Perubahan versi pustaka yang lebih dari satu versi akan dilakukan berulang sesuai dengan jumlah beda versi yang ada berkas perubahannya. Ilustrasi dari solusi pengembang pustaka dapat dilihat pada Gambar 1.
versi A rekam versi B versi C evolusi
rekam evolusi
evo A-B evo B-C
versi x.1 terapkan versi x.2
evo
terapkan evo temp
Gambar 1 Ilustrasi solusi pengembang pustaka
Kelebihan dari solusi ini akurat dalam mendeteksi perubahan API karena berkas perubahan diambil dari hasil rekaman perubahan yang dilakukan oleh pengembang pustakanya sendiri. Solusi ini memiliki kekurangan, yaitu perubahan yang dapat diaplikasikan hanya berdasarkan versi ke versi yang disediakan oleh pengembangnya. Solusi ini tidak dapat digunakan apabila versi yang digunakan oleh pengguna pustaka tidak terdapat catatan perubahan karena pengembang tidak menggunakan solusi ini dari versi awal hingga versi terakhir. Perpindahan antara versi berjauhan juga merepotkan pengguna pustaka karena pengguna diharuskan untuk melakukan refaktor secara berulang.
B. Solusi Pengguna Pustaka
Solusi ini dimulai dari pengguna pustaka yang ingin memperbaharui pustakanya. Pada solusi [1], kode sumber pustaka versi terbaru dianalisis perubahannya dengan kode sumber yang dimiliki oleh pengguna pustaka. Hasil analisis tersebut digunakan untuk refaktor sama seperti solusi pengembang pustaka. Ilustrasi solusi pengguna pustaka terdapat pada Gambar 2.
versi A versi B versi C
versi x.1 versi x.2 cari evolusi terapkan evo versi A versi C
Gambar 2 Ilustrasi solusi pengguna pustaka
Analisis perubahan kode sumber sangat dipengaruhi oleh penggunaan teknik deteksi evolusinya. Penelitian-penelitian mengenai solusi pihak pengguna pustaka [1][6] maupun penelitian-penelitian tentang teknik deteksi perubahan [4][5] menggunakan tingkat presisi dan tarik kembali (recall), karena solusi ini menggunakan prediksi untuk mendapatkan pasangan-pasangan evolusi API dimana alat untuk analisis tidak mengetahui alur program pustakanya.
Pendekatan ini memiliki keuntungan yaitu tidak terbatas seberapa jauh versi yang dipakai oleh pengguna pustaka selama kode sumbernya dapat dimiliki oleh pengguna pustaka. Kekurangan dari solusi ini antara lain: Pertama, solusi ini memakan waktu lebih lama dibandingkan solusi pihak pengembang pustaka karena solusi ini membutuhkan analisis kode sumber sebelum melakukan refaktor. Kedua, pencarian perubahan berdasarkan prediksi sehingga memiliki kemungkinan untuk dideteksi berubah namun tidak (false positive) atau dideteksi tidak berubah namun berubah (true negative). Ketiga, solusi ini memerlukan kode sumber dimana tidak semua pustaka menyertakan kode sumber karena lisensi. Kekurangan lain, walau tidak berhubungan langsung antara pihak pengguna pustaka dengan pengembang pustaka, hasil analisis perubahan tidak dapat digunakan lagi oleh pengguna pustaka lain walaupun versi pustaka yang digunakan sebelum ataupun sesudah sama.
C. Perbandingan Solusi
Kedua solusi memiliki kelebihan dan kekurangan yang dapat saling melengkapi satu sama lain. Solusi pengembang pustaka, catatan perubahan lebih akurat dan lebih menghemat waktu untuk satu kali refaktor. Solusi pengguna pustaka dapat digunakan untuk perbedaan versi yang kebih dari satu dan dapat digunakan selama kode sumber pustakanya dimiliki oleh pengguna pustaka. Ringkasan perbandingan kelebihan-kelebihan yang dimiliki dari kedua solusi dapat dilihat pada Tabel I.
TABELI
PERBANDINGAN PENDEKATAN PENGEMBANG PUSTAKA (LIB)DENGAN PENDEKATAN PENGGUNA PUSTAKA (USR)
Kelebihan Pihak
lib usr
Catatan perubahan akurat v -
Pengguna membutuhkan sedikit usaha v -
Refaktor dari catatan digunakan untuk perbedaan
lebih dari satu versi - v
Dapat dicari analisis perbedaan berdasarkan
kebutuhan pengguna - v
III. SOLUSI PIHAK REPOSITORI
Solusi pihak repositori adalah solusi yang menggunakan perantara untuk menggabungkan analisis pencarian catatan evolusi dari modifikasi solusi pihak pengguna, penyimpanan catatan evolusi, penggalian (query) catatan evolusi dan
merefaktor kode sumber milik pengguna dengan catatan evolusi. Solusi ini mempermudah pengembang pustaka karena pengembang cukup memberikan kode sumber ke
Deteksi Otomatis Perubahan Pustaka API dengan Solusi Sistem Repositori Kode Sumber dan Revisi API Pustaka Perangkat
Aditya Ideawan, Siti Rochimah
pihak repositori dan pihak repositori yang menganalisis dan menyimpan catatan evolusi. Solusi ini juga mempermudah pengembang pengguna karena pengembang cukup meminta catatan evolusi dari versi ke versi yang dibutuhkan. Ilustrasi solusi repositori terdapat pada Gambar 3.
versi A versi B versi C
versi x.1 terapkan versi x.2 evo
versi A cari versi B versi C evolusi cari evolusi DB evolusi query A-C
Gambar 3 Ilustrasi solusi repositori
IV. ANALISIS DETEKSI PERUBAHAN
Analisis deteksi perubahan API dari versi satu ke lainnya (sebut A ke B) menggunakan metode dari penelitian [1]. Berkas kode sumber dari versi A dan B dicari perubahan- perubahannya. Hasil dari analisis ini selanjutnya disimpan ke basis data perubahan.
A. Analisis Sintetik
Analisis sintetik digunakan untuk mencari pasangan dua kelas dari A dan B. Berkas kode sumber dikonversi menjadi pohon sintak abstrak objek informasi fakta. Hasil konversi, sebut SA dan SB untuk masing-masing berkas A dan B,
dihitung kemiripannya berdasarkan: (1) kesamaan nama untuk nama paket, kelas dan metode dan bila tidak sama maka (2) dihitung rata-rata kesamaan isi metode SA terhadap
SB dan SB terhadap SA sesuai dengan batas ambang yang
ditentukan.
Pada penelitian ini batas ambang untuk cara nomor (2) yang digunakan untuk menentukan mirip atau tidak adalah 0,5. Penjelasan metode lebih detail untuk cara nomor (2) dapat merujuk penelitian [1].
1. Objek Informasi Fakta
Objek informasi fakta ada dua jenis, informasi tentang kelas dan informasi tentang metode. Informasi tentang kelas terdiri dari informasi nama pustaka, versi, nama paket, nama kelas, jenis kelas, aksesibilitas kelas dan daftar objek informasi metode. Informasi tentang metode terdiri dari nama metode, aksesibilitas metode, tipe kembalian, daftar parameter dan daftar ekspresi dan deklarasi program. Daftar ekspresi pada informasi metode yang dijadikan pembandingan untuk metode yang tidak memiliki pasangan.
2. Analisis Kemiripan
Analisis kemiripan pada pasangan kelas menghitung kemiripan berdasarkan kesamaan nama paket, nama kelas, cakupan kelas dan metode-metode yang ada pada kelas tersebut. Analisis kemiripan pada pasangan metode menghitung kemiripan berdasarkan kemiripan kelas, nama metode, cakupan metode, parameter-parameter metode, tipe data kembalian dan ekspresi program yang terdapat didalam metode. Kedua analisis kemiripan dilakukan terpisah karena hasil analisis untuk kelas tidak berpengaruh dengan hasil analisis untuk metode.
3. Calon Pasangan Evolusi
Evolusi terjadi apabila ada perubahan pada versi yang dianalisis. Evolusi API pada bahasa pemrograman berbasis objek hanya terjadi apabila sebuah metode atau kelas dengan cakupan publik mengalami perubahan. Calon pasangan evolusi pada evolusi API hanya terjadi pada kelas dan metode yang berbeda. Pada penelitian ini, ditentukan bahwa perubahan pada kelas berbeda dengan perubahan pada metode. Dua objek informasi fakta dianalisis kemiripan untuk memperoleh pasangan evolusi. Pasangan evolusi dapat diterima apabila pasangan dari versi A ke B memiliki tingkat kemiripan yang paling besar. Analisis dilakukan dari A ke B dan B ke A untuk memastikan bahwa satu pasangan paling besar kemiripannya. Apabila sebuah objek tidak memiliki pasangan maka objek tersebut dipasangkan dengan nilai kosong dengan kemiripan sama dengan batas ambang.
Pasangan-pasangan evolusi dengan tingkat kemiripan 1, dimana sama persis tidak mengalami perubahan dihapus dari calon pasangan evolusi karena pasangan yang persis dianggap tidak terjadi evolusi. Pasangan-pasangan evolusi lain yang kedua objek informasinya memiliki aksesibilitas non-publik juga dihapus karena tidak relevan dengan evolusi API. Pasangan yang tersisa dibawa untuk analisis berikutnya.
B. Analisis Semantik
Pasangan-pasangan hasil analisis sintetik dicari jenis evolusinya. Analisis semantik yang diambil dari [1] terdiri dari: ganti nama paket (RP), ganti nama kelas (RC), ganti nama metode (RM), mengangkat metode (PU), menurunkan metode (PD), memindahkan metode (MM), mengganti parameter dari method (RPM), menghapus kelas (DC), menghapus metode (DM), menambahkan kelas (AC) dan menambahkan metode (AM). Pengolahan analisis semantik menghasilkan tiga solusi untuk kelas dan metode: tambah, ganti dan hapus.
Tambah merupakan hasil dari analisis semantik yang pasangan evolusi yang versi A nilai kosong. Tambah ekivalen untuk AC dan AM. Ganti merupakan hasil dari analisis semantik yang versi A dan B ada. Ganti ekivalen untuk RP, RC, RM, PU, PD, MM dan RPM. Hapus merupakan hasil dari versi B nilai kosong. Hapus ekivalen dengan DM dan DC.
V. PENYIMPANAN DAN PEMBUATAN LOG PERUBAHAN
Penyimpanan hasil analisis perubahan terpisah dari berkas kode sumber atau pustaka binernya. Penyimpanan dilakukan dengan menggunakan tabel basis data, bukan dengan berkas. Penggunaan basis data memudahkan repositori untuk menggali ulang untuk pembuatan berkas catatan perubahan.
A. Tabel Penyimpanan Informasi
Tabel penyimpanan untuk informasi kelas berbeda dengan informasi metode. Tabel untuk informasi kelas hanya menyimpan nama sebelum dan nama sesudahnya. Nama pada kelas termasuk dengan nama paket yang dimiliki. Ilustrasi tabel penyimpanan kelas terlihat pada Tabel II.
TABELII
TABEL PENYIMPANAN EVO API KELAS Nama Kolom Tipe Data
id Int api_name varchar version_start varchar version_end varchar code_start text code_end text
Tabel penyimpanan untuk informasi metode menyimpan pasangan sebelum dan sesudah untuk nama, tipe kembalian, parameter-parameter dan kelas yang memiliki metode tersebut. Ilustrasi tabel penyimpanan metode terlihat pada Tabel III.
B. Penyimpanan Berkas Refaktor
Hasil analisis tambah semua kolom dengan akhiran _start
diisi dengan nilai kosong (null). Hasil analisis ganti semua
kolom diisi tanpa nilai kosong. Hasil analisis hapus semua kolom akhiran _end diisi dengan nilai kosong. Parameter yang kosong diisi dengan string kosong, bukan nilai kosong. Analisis perubahan yang disimpan berdasarkan versi A ke B. Apabila ada versi lebih baru (sebut C), maka analisis perubahan yang disimpan berdasarkan versi B ke C. Analisis perubahan versi A ke C maka pihak repositori membuatkan versi perubahannya dari A ke B dan B ke C.
TABELIII
TABEL PENYIMPANAN EVO API METODE Nama Kolom Tipe Data
id int
api_name varchar
version_start varchar
version_end varchar
name_start text
name _end text
type_start text type_end text parameter_start text parameter_end text class_start text class_end text
C. Pembuatan Berkas Catatan Perubahan
Format berkas perubahan mengikuti mirip dengan yang ada pada penelitian [2]. Pembuatan berkas refaktor dibuat berdasarkan permintaan pengguna. Permintaan A ke C berarti membuat berkas refaktor berdasarkan hasil analisis A ke B dan B ke C. Pada proses ini terjadi penyederhanaan hasil analisis. Penambahan dari B ke C diikutsertakan dalam perubahan A ke C. Penggantian dari versi A ke B yang hasilnya berubah dari versi B ke C, maka berkas refaktor langsung menuliskan perubahan nama dari A ke C. Penghapusan dari A ke B diikutsertakan dalam perubahan A ke C.
VI. REFAKTOR PENGGUNA
Berkas kode sumber pengguna dirubah menggunakan tool dengan menggunakan berkas perubahan yang diambil dari pihak repositori. Tool merubah reverensi API dari pustaka yang bersesuaian dengan perubahannya. Tool metodenya dapat mengikuti metode dari penelitian [2].
Langkah pertama dari refaktor pengguna adalah dari impor paket (import package). Impor paket menunjukkan penggunaan pustaka yang digunakan dari sebuah kode sumber. Berkas dibaca impor paket, apabila ditemukan paket yang bersesuaian dengan refaktor API maka berkas dimasukkan kedalam antrian perubahan.
Langkah berikutnya, berkas dianalisis penggunaan kelas yang terdapat pada API. Nama untuk impor paket, kelas dan metode disesuaikan dengan nama yang baru apabila terjadi perubahan nama. Penghapusan impor paket, kelas dan metode ditangani secara khusus karena dapat menyebabkan kesalahan saat kompilasi kode. Penanganan yang dilakukan sementara dengan membuat baris perintah menjadi baris komentar.
Perubahan dari parameter metode juga ditangani secara khusus. Perubahan parameter metode yang menambahkan jumlah parameter dilakukan dengan memberi nilai gagal (default) untuk metode-metode yang mengakses API.
Deteksi Otomatis Perubahan Pustaka API dengan Solusi Sistem Repositori Kode Sumber dan Revisi API Pustaka Perangkat
Aditya Ideawan, Siti Rochimah
Perubahan yang mengurangi dilakukan dengan mengurangi langsung parameternya. Perubahan jenis parameter dengan merubah langsung nilai parameter dengan nilai gagal.
Perubahan pengangkatan atau penurunan metode dilakukan mirip dengan perubahan nama, perbedaannya impor paket dan kelas yang lama tidak diganti, namun ditambahkan impor paket dan kelas yang baru, beserta deklarasinya apabila penggunaan kelas dilakukan secara global. Variabel baru untuk kelas yang baru dibuat dan variabel lama yang memanggil kelas tersebut diganti dengan variabel baru yang dibuat.
VII. IMPLEMENTASI DAN PENGUJIAN
Implementasi dan pengujian pada penelitian ini masih tahap preeliminari, dimana implementasi hanya sampai pembuatan berkas refaktor. Hal ini dilakukan karena asumsi proses refaktor pengguna yang menggunakan solusi yang ada sama. Pengujian dilakukan dengan membandingkan berkas refaktor dari solusi pihak repositori dengan solusi pengguna pustaka.
Pengujian dilakukan dengan implementasi sebuah prototipe aplikasi server pihak repositori secara offline. Pengujian dilakukan secara lokal dengan data kode sumber pustaka diuji dengan komputer lokal. Hasil analisis disimpan dalam basis data lokal. Aplikasi antarmuka menggunakan aplikasi desktop.
A. Sumber data
Kode sumber proyek pustaka berbasis sumber terbuka (OSS). Proyek pustaka yang digunakan ada 3 yaitu: jChart (0.2 sampai 0.7), json-lib (2.0 sampai 2.4) dan jDatepicker (1.0.0 sampai 1.3.2). jChart diambil sebagai sampel pustaka yang banyak perubahan dari versi ke versi. Json-lib diambil sebagai sampel pustaka yang stabil, sedikit mengalami
perubahan. jDatepicker diambil sebagai sampel yang perubahannya moderat.
B. Benchmark
Asumsi bahwa metode pendeteksian dari pihak repositori dan pihak pengguna sama, maka pengujian mengukur jumlah pasang perubahan, bobot pasang perubahan dan waktu eksekusi. Bobot untuk pasangan berubah lebih besar dua kali dibandingkan dengan penambahan dan pengurangan karena deteksi perubahan apabila gagal karena kurang dari batas ambang menjadi penambahan dan pengurangan. Akurasi presisi dan panggil kembali diuji untuk penelitian lebih lanjut.
C. Skenario
Skenario pengujian menguji solusi pihak repositori ketika pengguna migrasi versi pustaka awal ke versi pustaka akhir. Pengujian solusi pihak repositori dibandingkan dengan pihak pengguna untuk mendapatkan jumlah pasangan evolusi yang berhasil dideteksi dan banyaknya waktu yang diperlukan untuk mendapatkan pasangan evolusi. Khusus untuk jumlah pasangan evolusi, didapatkan juga nilai bobot pasangan.
D. Hasil Pengujian
Hasil pengujian menghasilkan data-data sebagai berikut:
Hasil pembandingan antara pihak pengguna dengan pihak repositori didapatkan jumlah pasangan evolusi lebih besar untuk pihak repositori dibandingkan dengan pihak pengguna, kecuali untuk jdatepicker dengan 44% lebih banyak untuk tertinggi dan -3% untuk terendah. Data lengkap untuk jumlah pasangan evolusi dapat dilihat pada Tabel IV.
TABELIV
HASIL PERBANDINGAN JUMLAH PASANGAN EVOLUSI SOLUSI PIHAK PENGGUNA (A)DENGAN PIHAK KETIGA (B)
Library Version
Direct Detection (A) Chaining Query (B)
Gain Class Pair Method Pair Class Pair Method Pair
start end class method total
jchart 0.2 0.7 62 377 68 564 10% 50% 44%
json-lib 2.0 2.4 19 154 19 156 0% 1% 1%
jdatepicker 1.0.0 1.3.2 17 141 15 138 -12% -2% -3%
TABELV
HASIL PERBANDINGAN WAKTU EKSEKUSI SOLUSI PIHAK PENGGUNA (A)DENGAN PIHAK KETIGA (B)
Library Version Direct Detection (DD) Chaining Query Compare start end Detection Total (DT) Query (Q) DD vs Q
jchart 0.2 0.7 3047 24267 217 -93%
json-lib 2.0 2.4 8782 67007 20 -99%
TABELVI
HASIL PERBANDINGAN JUMLAH BOBOT PASANGAN SOLUSI PIHAK PENGGUNA (A)DENGAN PIHAK KETIGA (B)
Library Version Direct Detection (A) Chaining Query (B) Gain
start end Class Method Total Class Method Total Class Method Total
jchart 0.2 0.7 65 391 456 68 575 643 5% 47% 41%
json-lib 2.0 2.4 19 157 176 19 157 176 0% 0% 0%
jdatepicker 1.0.0 1.3.2 19 155 174 19 157 176 0% 1% 1%
Waktu eksekusi apabila disimulasikan pengguna menganalisis langsung dibandingkan dengan menggali dari basis data jauh lebih cepat menggali dibandingkan menganalisis langsung. Waktu yang dipangkas mencapai 90% sampai 99% lebih untuk semua kasus. Data lengkap untuk perbandingan waktu eksekusi dapat dilihat pada Tabel V.
Perbandingan bobot dimana penggunaan pihak repositori mencapai tertinggi 41% dan terendah 0% atau sama dengan pihak pengguna. Data lengkap untuk perbandingan bobot pasangan dapat dilihat pada Tabel VI.
VIII. SIMPULAN
Berdasarkan pengujian awal ditemukan bahwa secara penggunaan, solusi pihak repositori mengungguli pengguna pustaka dalam memperoleh hasil analisis perubahan lebih cepat dengan waktu yang dapat dipangkas mencapai 90%. Jumlah evolusi hasil analisis perulangan penggalian lebih banyak dibandingkan menganalisis langsung dengan skor tertinggi 44% dan terendah -3%, sementara untuk bobot hasil evolusi skor tertinggi 41% dan terendah 0%. Akurasi dan ketepatan mungkin juga menjadi keunggulan solusi ini walaupun belum dilakukan pengujiannya.
IX. ANCAMAN KEABSAHAN
Pengujian hanya menunjukkan seberapa cepat eksekusi penggalian basis data dibandingkan dengan analisis langsung tanpa memberi bukti keakuratan dan ketepatan dari kedua metode. Hal ini terjadi karena diasumsikan bahwa metode deteksi beserta parameter-parameter yang
menyertai kedua solusi reposori dengan solusi pengguna adalah sama. Kenyataannya hasil pengujian mendapatkan perbedaan jumlah perubahan API yang dideteksi.
Pekerjaan yang datang untuk memperbaiki permasalahan ini adalah memasukkan poin keakuratan dan ketepatan untuk membandingkan dengan pihak pengguna. Keakuratan dan ketepatan akan dihitung dari jumlah kesalahan kompilasi.
X. PEKERJAAN AKAN DATANG
Penelitian berikutnya membuktikan keakuratan dan ketepatan dari metode pihak repositori dibandingkan baik antara pihak pengembang dengan pengguna secara jumlah kesalahan kompilasi maupun usaha dari berkas perubahan yang dimuat bersamaan dengan pustaka dari pengembangnya.
DAFTAR PUSTAKA
[1] D. Dig, C. Comertoglu, D. Marinov & R. Johnson, “Automated Detection of Refactorings in Evolving Components,” Proceeding ECOOP'06, 2006, p. 404-428.
[2] J. Henkel & A. Diwan, “CatchUp! Capturing and Replaying Refactorings to Support API Evolution,” Proceeding ICSE'05, 2005, p. 274-283.
[3] Y. Padioleau, J. Lawall, R. R. Hansen & G. Muller, “Documenting and Automating Collateral Evolutions in Linux Device Drivers,” Proceeding EuroSys'08, 2008, p. 247-260.
[4] P. Weissgerber & S. Diehl, “Identifying Refactorings from Source- Code Changes,” Proceedings ASE '06, 2006, p. 231-240.