BAB II STUDI LITERATUR Pada Bab ini, akan dibahas hasil studi literatur maupun eksplorasi yang akan dipakai untuk membangun aplikasi pendeteksi plagiarisme yang menggunakan metode structure-based. Studi literatur yang dilakukan terbatas pada cakupan plagiarisme source code program saja. Bab ini diawali dengan pembahasan mengenai perkembangan deteksi plagiarisme otomatis pada source code, kemudian dilanjutkan dengan pembahasan mengenai algoritma pembandingan yang dapat menangani masalah yang dihadapi sistem deteksi plagiarisme otomatis dan sistem-sistem deteksi plagiarisme yang sudah pernah dikembangkan.
2.1 Perkembangan Deteksi Plagiarisme Otomatis pada Source Code Pada Subbab ini diberikan pembahasan mengenai perkembangan deteksi plagiarisme otomatis pada source code, mulai dari keadaan lingkungan pendidikan yang mendorong perkembangan deteksi plagiarisme otomatis sampai dengan metode deteksi plagiarisme otomatis yang telah diterapkan. 2.1.1 Plagiarisme Source Code di Kelas Pemrograman Banyak sekali bentuk-bentuk dari ketidakjujuran ditemukan pada lingkungan pendidikan, khususnya kuliah pemrograman. Plagiarisme di kuliah pemrograman ini terjadi ketika siswa mengumpulkan tugas yang dibuat untuk memenuhi kewajiban akademis, namun mengandung ide atau kata-kata milik orang lain yang diakui sebagai kreasi pribadi, sehingga pengajar atau pemeriksa tidak mengetahui bahwa pekerjaan tersebut mengandung bagian yang disadur dari kreasi orang lain. Bentuk-bentuk plagiarisme pada kelas pemrograman yaitu [JOY99] : a. Mahasiswa yang lemah secara akademik kerja sama dengan teman untuk mengerjakan suatu tugas. Jenis kerja sama di sini berbeda maknanya dengan kerja sama pada pengerjaan tugas kelompok. Dalam tugas-tugas tertentu mahasiswa diharuskan mengumpulkan hasil yang dikerjakan secara individual, namun dengan adanya diskusi, hasil yang dikumpulkan pun akan cenderung sama.
1
II-2 b. Mahasiswa yang lemah secara akademik menyalin kemudian melakukan modifikasi pada source code milik teman dengan berharap bahwa hal tersebut tidak akan diketahui oleh penilai atau pengajar. Kemungkinan besar mahasiswa tidak terlalu mengerti source code yang dimodifikasinya, sehingga kesamaan antara kedua buah source code cenderung besar. c. Mahasiswa yang motivasinya rendah tapi belum tentu lemah secara akademik melakukan plagiarisme dengan maksud agar bobot pekerjaan lebih ringan atau agar waktu pengerjaan lebih singkat. Bisa saja mahasiswa tersebut sangat mengerti topik tugas yang diberikan sehingga modifikasi yang dilakukan cukup rumit. Plagiarisme seperti ini lebih sulit diidentifikasi. Praktek plagiarisme merupakan bentuk kecurangan akademik yang sangat buruk. Pada Pasal 8.1 Peraturan Akademik ITB terdapat larangan untuk melakukan kecurangan akademik, termasuk menggunakan kata-kata atau karya orang lain sebagai kata-kata atau karya sendiri dalam suatu kegiatan akademik tanpa menyebutkan acuan yang dipakai [PPA06]. Setiap mahasiswa layak mendapatkan nilai atau penghargaan berdasarkan suatu hasil nyata yang telah dikerjakannya, yang kemudian akan dipakai untuk menentukan posisi di universitas, seleksi beasiswa, seleksi pekerjaan, dan lainlain. Jika pekerjaan tersebut bukan merupakan hasil kreasi mahasiswa yang bersangkutan, maka sebetulnya mahasiswa tersebut tidak pantas untuk mendapatkan nilai atau penghargaan yang lebih daripada mahasiswa lain yang jujur namun mendapatkan hasil yang lebih buruk. Praktek plagiarisme harus dicegah karena setiap perbuatan plagiat akan mempengaruhi seluruh elemen kehidupan akademik. Plagiarisme di kelas pemrograman sudah sangat umum, dan tidak cukup jika penilai hanya memperingatkan siswa saja. Beberapa siswa akan terus melakukan plagiarisme walaupun pengajar berusaha keras untuk mencegahnya. Oleh karena itu harus ada suatu usaha deteksi plagiarisme dan sistem pemberian hukuman sebagai akibat dari melakukan ketidakjujuran. Deteksi juga tidak hanya ditujukan untuk mendeteksi bagian hasil plagiarisme, tapi juga harus meyakinkan pengguna bahwa bagian tersebut bukan suatu kesamaan yang tidak disengaja. Deteksi manual tidak efektif dan mudah gagal terutama karena jumlah peserta kelas yang biasanya mencapai ratusan, karena itulah kebutuhan akan sistem yang dapat mendeteksi plagiarisme secara otomatis pun meningkat.
II-3 2.1.2 Karakteristik Plagiarisme di Kelas Pemrograman Plagiarisme yang dilakukan oleh mahasiswa kelas pemrograman mempunyai perbedaan mendasar dari plagiarisme lain, yaitu lebih mudah dilakukan dan lebih sulit dideteksi [WAG00]. Biasanya mahasiswa pemrograman bekerja di lingkungan yang sama dan soal yang diberikan pun sama, sehingga program yang dihasilkan pun akan mirip. Output yang dihasilkan dari eksekusi program kemungkinan akan sama, dan mahasiswa bisa menyalin kemudian melakukan modifikasi-modifikasi yang tidak mempengaruhi eksekusi program. Selain itu, suatu source code bisa saja merupakan gabungan hasil penyalinan dari beberapa source code lainnya, atau gabungan dari hasil pengerjaan sendiri dan hasil penyalinan dari orang lain. Hal itu juga meningkatkan kesulitan dalam mendeteksi bagian program yang merupakan hasil plagiarisme. Modifikasi-modifikasi yang biasa dilakukan oleh mahasiswa pemrograman bisa diklasifikasikan sebagai berikut [JOY99] : a. Lexical change Menurut Joy dan Luck [JOY99], lexical change merupakan modifikasi yang bisa dilakukan dengan text editor tanpa memakai pengetahuan pemrograman. Contohcontoh modifikasi yang dapat dilakukan yaitu menghilangkan atau menambah komentar dan mengubah nama identifier. b. Structural change Modifikasi jenis ini membutuhkan pengetahuan lebih mengenai pemrograman yang cukup untuk melakukan parse terhadap program. Modifikasi ini sangat language-dependent. Plagiarisme yang dilakukan dengan melakukan modifikasi seperti ini lebih sulit untuk dideteksi. Contoh-contoh perubahan yang sering dilakukan yaitu : 1) Mengganti jenis iterasi, misalnya dari sintaks do-while menjadi for. 2) Mengganti jenis statement kondisional, misalnya mengganti sintaks if dengan case. 3) Mengganti urutan statement yang tidak menimbulkan perubahan hasil eksekusi program. 4) Prosedur diganti dengan fungsi atau sebaliknya. 5) Pemanggilan prosedur diganti dengan body prosedur tersebut.
II-4 6) Menambah statement yang tidak mempunyai efek yang tidak terlihat ketika program dijalankan, sehingga bagian tertentu dari source code menjadi redundan. 7) Mengganti ekspresi ke bentuk ekuivalen, misalnya x < y menjadi y >= x. Faidhi dan Robinson[FAI87] mengklasifikasikan modifikasi-modifikasi tersebut ke dalam enam level modifikasi program yang digambarkan pada spektrum plagiarisme (lihat Gambar II-1). Semakin tinggi level, semakin sulit untuk mendeteksi dan membuktikan adanya plagiarisme.
Gambar II-1. Spektrum Plagiarisme [FAI87]
2.1.3 Manfaat Sistem Manfaat dari sistem deteksi plagiarisme otomatis adalah untuk membantu deteksi manual dalam hal melakukan pembandingan antara jumlah source code yang banyak dalam waktu yang lebih singkat. Sistem juga tidak boleh tertipu oleh berbagai modifikasi yang dilakukan mahasiswa untuk menyembunyikan praktek plagiarisme. Sistem harus dapat membedakan source code hasil plagiarisme dan source code yang bukan merupakan kasus plagiarisme, sehingga sedapat mungkin meminimalisasi kesalahan hasil deteksi dalam hal menentukan apakah itu hanya kesamaan yang tidak disengaja ataukah merupakan hasil praktek plagiarisme.
II-5 Aspek-aspek utama yang harus diperhatikan dari pembangunan sistem deteksi plagiarisme otomatis yaitu [CLO03] : a. Deskriminator yang cocok untuk menunjukkan adanya plagiarisme. b. Membangun metode yang cocok untuk membandingkan diskriminator tersebut. c. Pengukuran similarity yang sesuai. 2.1.4 Metode Deteksi Plagiarisme Otomatis Dua pendekatan utama yang telah dipakai untuk metode-metode deteksi plagiarisme otomatis yaitu attribute-counting dan structure-based [CLO00]. Pada metode attribute-counting, yang dibandingkan adalah ukuran kuantitatif beberapa metriks program. Sedangkan pada metode structure-based, yang dibandingkan adalah representasi dari struktur program, misalnya representasi linier berupa string, parse tree, data flow, dan lain-lain. Kedua pendekatan tersebut akan dijelaskan pada Subbab 2.1.4.1 dan Subbab 2.1.4.2. 2.1.4.1 Metode Attribute-counting Sistem-sistem deteksi plagiarisme otomatis generasi awal memakai metode ini untuk membandingkan program-program. Setiap program mempunyai suatu angka yang merupakan analisis kuantitatif dari beberapa fitur program (metriks) yang kemudian akan dibandingkan. Contoh metriks yang paling sederhana yaitu ukuran program, misalnya jumlah baris. Kemudian teknik ini terus dikembangkan agar lebih mampu menangani berbagai modifikasi program yang dapat menipu sistem agar dianggap bukan hasil plagiat. Berbagai metode attribute-counting yang menggunakan metriks lain terus bermunculan, misalnya perhitungan jumlah operator dan operands oleh Halstead, metode cyclomatic complexity dari McCabe yang mengukur aliran kontrol program dengan menghitung jumlah execution path, dan metode pengukuran scope number. Pada sistem yang dibangun setelah itu, berbagai metriks dikombinasikan sehingga terdapat beberapa angka yang mewakili setiap program. Program dianggap sama jika hampir semua atau semua angka tersebut sama. Perkembangan selanjutnya untuk tuning sistem tersebut adalah dengan menentukan bobot untuk setiap parameter, sehingga metriks yang lebih penting akan lebih berpengaruh pada tingkat similarity program. Walaupun berbagai tuning sudah dilakukan untuk memperbaiki metode ini,
II-6 sistem-sistem attribute-counting hanya berhasil melakukan deteksi dengan efektif untuk plagiarisme yang dilakukan oleh amatir dengan modifikasi-modifikasi sederhana. Sistem-sistem tersebut masih belum mampu untuk mendeteksi praktek plagiarisme yang lebih kompleks, misalnya plagiarisme parsial yang terjadi ketika hanya sebagian kode saja yang disalin dari kode milik mahasiswa lain. 2.1.4.2 Metode Structure-based Penelitian telah membuktikan bahwa metode attribute-counting tidak bisa menggambarkan struktur program secara baik untuk membedakan source code hasil plagiarisme dan source code yang bukan merupakan kasus plagiarisme [FAI87, WIS92]. Hal inilah yang mendorong dikembangkannya metode berbasis struktur yang lebih rumit daripada attribute-counting dan memerlukan pengetahuan lebih mengenai bahasa pemrograman yang menjadi target deteksi. Metode ini tidak membandingkan representasi kuantitatif dari atribut program seperti pada metode attribute-counting, melainkan membandingkan suatu representasi dari struktur program. Contoh-contoh sistem yang menggunakan metode structure-based yaitu Plague, YAP [WIS92], MOSS [AIK94], SIM, JPlag [LUT00] dan SID [CHE03]. Sistem-sistem tersebut telah digunakan luas dan terbukti efektif dalam mendeteksi plagiarisme. Secara umum proses pendeteksian pada sistem yang menggunakan metode berbasis struktur terbagi menjadi dua tahap sebagai berikut: 1. Tokenization, yaitu parsing kode program menjadi kumpulan token yang disebut token sequence atau profile. Token adalah elemen tunggal dari bahasa pemrograman. Contohnya reserved words, tanda baca, dan operator [TEC06]. Sedangkan parser adalah program yang memecah kode menjadi komponenkomponen fungsional [MIL05]. 2. Membandingkan setiap pasangan profile atau token sequence. Untuk n program yang dikumpulkan aplikasi akan melakukan n*(n–1)/2 pembandingan.
II-7 2.1.5 Penanganan Lebih Dari Satu Bahasa Pemrograman Salah satu kebutuhan yang muncul mengenai sistem deteksi plagiarisme otomatis adalah penanganan lebih dari satu bahasa pemrograman. Sistem deteksi plagiarisme generasi awal seperti Plague membutuhkan banyak waktu dan usaha untuk membuat setiap versi yang menangani bahasa pemrograman yang berbeda, dimulai dari konstruksi parser dan penentuan ulang parameter-parameter program [CLO00]. Sebenarnya pada metode structure-based, hanya proses perubahan source code menjadi representasi program saja yang mempunyai ketergantungan pada bahasa pemrograman. Oleh karena itu, dengan mengenkapsulasi komponen detektor yang bertugas untuk transformasi source code, tidak perlu membangun ulang keseluruhan detektor untuk setiap bahasa pemrograman. Berdasarkan hipotesis tersebut, terdapat dua solusi utama untuk menangani masalah tersebut yang secara umum dipakai oleh sebagian besar sistem yang mendukung deteksi multi-language [ARW06]: 1. Dengan menggunakan parser yang memproduksi token string Token string merupakan representasi dari struktur program, sehingga proses produksi token string tergantung pada bahasa pemrograman source code yang dideteksi. Oleh karena itu jika suatu sistem dirancang untuk menangani lebih dari satu bahasa pemrograman, hanya bagian parser saja yang berbeda untuk setiap versi. Setelah tahap parsing, program akan membandingkan token string yang dihasilkan tersebut. 2. Dengan membandingkan intermediate code yang dihasilkan oleh compiler suite. Compiler suite merupakan compiler yang mendukung lebih dari satu bahasa. Pendekatan yang kedua dapat mendukung lebih banyak bahasa pemrograman daripada pendekatan pertama, namun sangat bergantung pada komponen compiler suite generik yang sudah tersedia.
II-8
2.2 Algoritma Pembandingan pada Sistem Deteksi Plagiarisme Otomatis Bagian paling penting dari metode deteksi plagiarisme otomatis pada source code adalah pada saat pembandingan kode-kode program. Untuk proses tersebut dibutuhkan suatu algoritma pembandingan yang mampu menemukan bagian-bagian yang sama pada kode program yang dibandingkan. Pada Subbab ini, akan dijelaskan mengenai algoritma Greedy String Tiling (GST), kemudian algoritma Tuned Greedy String Tiling yang dikembangkan untuk menurunkan kompleksitas algoritma GST, dan algoritma Running Karp-Rabin Greedy String Tiling [WIS92, WIS93a, WIS93b]. 2.2.1 Algoritma Greedy String Tiling Algoritma Greedy String Tiling (GST) diusulkan dengan tujuan menentukan tingkat kesamaan dua buah token string. GST menggunakan pembandingan one-to-one, dan dapat menangani transformasi subrutin [WIS93a, WIS93b]. Ada beberapa istilah dan definisi yang harus diketahui sebelum algoritma Greedy String Tiling dapat dijelaskan. a. Token, token string, substring dan mark. Token merupakan representasi elemen-elemen source code. Yang dimaksud dengan token string yaitu bukan array of character melainkan array of token, sehingga substring merupakan deretan tokens yang merupakan bagian dari suatu token string. Dua buah token string dikatakan sama persis jika setiap token yang terdapat pada token string yang satu juga terdapat pada token string yang dibandingkan dengannya, dengan syarat bahwa setiap token mempunyai posisi dan urutan yang sama pada kedua token string. Pada Kode II-1, token direpresentasikan sebagai suatu tipe bentukan yang terdiri dari string yang menyimpan isi token dan boolean yang berfungsi sebagai mark. Mark akan bernilai true jika token sudah menjadi bagian dari suatu tile. b. Maximal-match Sebuah maximal-match menyimpan posisi dan panjang sebuah substring yang sama pada kedua token string yang dibandingkan. Cara membentuk maximalmatch yaitu ketika pasangan token yang sama ditemukan, tokens pada posisi berikutnya dibandingkan terus sampai salah satu dari tiga kondisi berikut ini
II-9 ditemui, yaitu jika pasangan token yang tidak cocok ditemukan, atau jika pada salah satu token string ditemukan token yang sudah ditandai (marked), atau jika tidak ada token yang bisa dibandingkan lagi pada salah satu token string (akhir token string dicapai). Notasi maximal-match pada algoritma di Kode II-1 yaitu match(p,t,s), dengan p dan t merupakan posisi token pertama pada masing-
masing token string dan s merupakan jumlah token pada substring tersebut. Maximal-match bersifat temporer dan ada kemungkinan bukan merupakan asosiasi unik, karena substring yang menjadi bagian dari suatu maximal-match bisa saja merupakan bagian dari maximal-match yang lain. c. Tile Sebuah tile menyimpan posisi dan panjang sebuah substring yang sama pada kedua token string yang dibandingkan. Tile dibentuk dari maximal-match. Dalam proses membentuk tile dari sebuah maximal-match, token-token yang merupakan elemen dari maximal-match tersebut ditandai (marked). Bedanya dengan maximalmatch, tile bersifat permanen dan unik, karena substring yang menjadi bagian dari suatu tile tidak boleh menjadi bagian tile yang lain karena sudah ditandai. d. Minimum-match-length Dalam proses pembandingan seringkali muncul maximal-match yang ukurannya pendek. Maximal-match yang berukuran pendek tersebut dapat diabaikan karena dianggap tidak signifikan. Maximal-match dengan panjang satu atau dua token saja tidak akan berarti ketika membandingkan dua buah source code. Karena itu, ditentukan sebuah nilai yang disebut minimum-match-length. Semua maximalmatch yang mempunyai panjang di bawah minimum-match-length tidak akan dibentuk menjadi tile. Nilai minimum-match-length dapat mewakili tingkat sensitivitas deteksi. Biasanya minimum-match-length menjadi parameter program. Objektif dari algoritma ini adalah membentuk tiles dari kedua token string tanpa overlapping dengan memaksimalkan jumlah token yang ditandai. Tanpa overlapping yang dimaksud di sini yaitu sebuah token pada token string hanya merupakan elemen dari sebuah tile saja. Tile yang panjang lebih diutamakan daripada tile yang lebih pendek karena tile yang panjang lebih mencerminkan kecocokan dan kecil kemungkinan bahwa kecocokan tersebut hanyalah kebetulan saja.
II-10 Untuk memenuhi objektif tersebut, digunakan algoritma greedy1 yang melakukan iterasi pada kedua token string. Setiap iterasi mempunyai dua fase sebagai berikut: 1. Fase scanpattern Fase ini bertujuan untuk mengumpulkan maximal-match dengan panjang yang lebih dari atau sama dengan ukuran tertentu. Ukuran ini disebut search length. Pada Kode II-1 search length dinyatakan dengan variabel maxmatch. Di awal fase scanpattern search length selalu diinisialisasi dengan nilai minimum-matchlength. 2. Fase markstrings Pada tahap ini, setiap maximal-match yang telah ditemukan akan diuji untuk mengetahui apakah token-token yang menjadi bagian dari maximal-match tersebut sudah ditandai (marked). Jika sudah ditandai, maka bagian dari maximalmatch tersebut sebenarnya sudah menjadi bagian dari tile yang lain. Jika semua token pada maximal-match belum ditandai, maka sebuah tile akan dibentuk dari maximal-match tersebut. Algoritma Greedy String Tiling dalam notasi algoritmik dapat dilihat di Kode II-1. Algoritma tersebut diadopsi dari pseudocode yang terdapat pada literatur tentang algoritma GST [WIS93a,WIS93b]. Contoh penerapan algoritma GST untuk menemukan substring yang sama pada dua buah token string dapat dilihat pada Lampiran A. Walaupun algoritma GST telah dibuktikan optimal, untuk kasus terburuk algoritma tersebut mempunyai kompleksitas O(n3) [WIS93b]. Oleh sebab itu, dilakukan tuning terhadap algoritma GST (lihat Subbab 2.2.2) untuk memperbaiki kompleksitas ratarata algoritma GST.
1 Algoritma Greedy adalah algoritma apapun yang mengikuti metaheuristik pemecahan masalah yang membuat pilihan optimum lokal pada setiap langkahnya dengan harapan menemukan optimum global [COR01].
II-11 function GreedyStringTiling (P[0..M],T[0..N] : tokenString, minimum_match_length: integer) integer {membandingkan setiap token pada P dan T} {jika ditemukan sederetan token yang bernilai sama dan panjangnya lebih besar dari minimum-match-length, maka token tersebut akan ditandai } {mengembalikan jumlah token yang sudah ditandai} KAMUS length_of_tokens_tiled : integer {jumlah token yang sudah ditandai} maxmatch : integer {search-length} p: integer {posisi token pada pattern string} t: integer {posisi token pada text string} match_list : list of match {List yang berisi maximal-matches} j: integer ALGORITMA length_of_tokens_tiled 0 repeat {mulai fase scanpattern} maxmatch minimum_match_length for p position of first unmarked token in P[0..M] to M do for t position of first unmarked token in T[0..N] to N do j 0 while p+j<M and t+j
maxmatch then maxmatch j {mulai fase markstrings} for each match(p,t,maxmatch) in match_list do if all tokens in match(p,t,maxmatch) are unmarked then for j0 to maxmatch-1 do mark_token(P[p+j]) mark_token(T[t+j]) length_of_tokens_tiled length_of_tokens_tiled + maxmatch until maxmatch = minimum_match_length length_of_tokens_tiled
Kode II-1. Algoritma Greedy String Tiling ([WIS93a,WIS93b])
2.2.2 Tuning Algoritma Greedy String Tiling Untuk mengatasi kompleksitas algoritma GST yang cukup tinggi, dapat diterapkan berbagai teknik tuning untuk menanganinya [WIS93b]. Pada algoritma yang telah dituning ini, kedua buah token string yang dibandingkan dibedakan perlakuannya, masing-masing disebut sebagai pattern string dan text string. Biasanya token string yang dipilih menjadi pattern string adalah token string yang mempunyai jumlah token lebih sedikit. Berikut ini diuraikan beberapa teknik tuning yang diterapkan pada algoritma GST: 1. Pada pattern string, hanya token-token yang belum ditandai saja yang akan dibandingkan. Caranya dengan membuat agar setiap unmarked token (token yang belum ditandai) menunjuk ke unmarked token sebelum dan sesudahnya. Michael
II-12 Wise menyarankan struktur data list dengan pointer ganda (double-linked list) untuk menyimpan unmarked tokens tersebut [WIS93b]. 2. Pada pattern string, jika jarak dari posisi indeks saat itu ke tile berikutnya lebih kecil dari minimum-match-length, maka bagian yang belum ditandai pada pattern string mulai dari posisi indeks akan diabaikan beserta tile yang mengikutinya. Posisi indeks akan bergeser ke token pertama yang belum ditandai yang letaknya setelah tile tersebut. 3. Pada text string juga dibuat agar hanya token-token yang belum ditandai saja yang akan dibandingkan. Tapi berbeda dengan pada pattern string, pada kasus ini dibuat agar unmarked token dengan nilai yang sama dihubungkan. Sehingga pada pembandingan, hanya token-token yang bernilai sama saja yang akan dicoba dibandingkan dengan token yang diberikan dari pattern string. Struktur data yang disarankan Michael Wise adalah array of double-linked list [WIS93b]. Elemenelemen array menunjuk ke elemen-elemen pertama double-linked list yang menyimpan kemunculan pertama setiap nilai token yang memungkinkan. 4. Saat mencari maximal-match yang lebih besar atau sama dengan search length (pada Kode II-2 dinyatakan dengan variabel maxmatch), setelah token yang sama ditemukan pada posisi p pada pattern string dan t pada text string, terdapat posisi pembandingan berikutnya yang lebih baik daripada p+1 dan t+1. Posisi tersebut yaitu pada p+maxmatch-1 dan t+maxmatch-1. Caranya yaitu dengan menghitung nilai hash untuk token-token pada pattern string mulai dari posisi p+1 sampai p+maxmatch-1 dan pada text string mulai dari posisi t+1 sampai t+maxmatch-1. Kemudian pembandingan nilai hash dilakukan pada posisi p+maxmatch-1 dan t+maxmatch-1.
5. Jika pembandingan nilai hash pada p+maxmatch-1 dan t+maxmatch-1 bernilai true, pembandingan token per token dilakukan mundur mulai dari p+maxmatch1 sampai p+1 (pattern string) dan dari t+maxmatch-1 sampai t+1 (text string),
karena kegagalan memasangkan kedua substring seringkali terjadi pada posisi yang jauh dari awal pasangan. Algoritma Greedy String Tiling yang telah di-tuning dalam notasi algoritmik terdapat pada Kode II-2. Algoritma tersebut diadopsi dari pseudocode yang terdapat pada literatur tentang algoritma GST [WIS93a,WIS93b].
II-13 function TunedGreedyStringTiling (P[1..M],T[1..N] : tokenString, minimummatch-length: integer) integer {membandingkan setiap token pada P dan T} {token string P[1..M] merupakan token string yang lebih pendek dibandingkan dengan token string T[1..N]} {jika ditemukan sederetan token yang bernilai sama dan panjangnya lebih besar dari minimum-match-length, maka token tersebut akan ditandai} {mengembalikan jumlah token yang sudah ditandai} KAMUS length_of_tokens_tiled : integer {jumlah token yang sudah ditandai} maxmatch : integer {search-length} p: integer {posisi token pada pattern string} t: integer {posisi token pada text string} match_list : list of match {List yang berisi maximal-matches} j,k : integer ALGORITMA length_of_tokens_tiled 0 repeat {mulai fase scanpattern} {tuning nomor 1} for each unmarked(P[p]) in P[0..M] do if distance from p to next tile ≤ minimum_match_length then p position of first unmarked token after next tile {tuning no 2} else maxmatch minimum_match_length {tuning nomor 3} for each unmarked(T[t]) in T[0..N] do if P[p]=T[t] then if p+maxmatch-1<M and t+maxmatch-1 maxmatch then restart match_list, add match(p,t,k) to match_list maxmatch k for each match(p,t,maxmatch) in match_list do if all tokens in match(p,t,maxmatch) are unmarked then for j0 to maxmatch-1 do markToken(P[p+j]) markToken(T[t+j]) length_of_tokens_tiled length_of_tokens_tiled + maxmatch until maxmatch = minimum-match-length length_of_tokens_tiled
Kode II-2. Algoritma Greedy String Tiling yang Sudah Di-tuning [WIS93a,WIS93b]
2.2.3 Algoritma Running Karp-Rabin Greedy String Tiling Algoritma Running Karp-Rabin Greedy String Tiling pertama kali dipakai pada sistem Neweyes, yaitu sebuah sistem untuk alignment biosequences nukleotida dan asam
amino [WIS93a]. Salah satu masalah yang dihadapi oleh program alignment tersebut yaitu menentukan similarity antara dua buah string. Masalah tersebut sama dengan yang dihadapi oleh sistem deteksi plagiarisme, sehingga Michael Wise juga menerapkan algoritma ini pada YAP3 [WIS96]. Algoritma ini merupakan
II-14 pengembangan lebih lanjut dari algoritma Greedy String Tiling dengan penerapan algoritma Karp-Rabin pada fase scanpattern. Algoritma Karp-Rabin diajukan oleh Richard M. Karp dan Michael O. Rabin dalam literaturnya yang berjudul “Efficient Randomized Pattern-Matching Algorithms” [KAR87]. Algoritma tersebut dapat menangani masalah string matching sebagai berikut: Untuk sebuah set pasangan string {(X(i),Y(i))} terdefinisi, jika memungkinkan, tentukan r yang memenuhi X(r)=Y(r). Pada algoritma yang diajukan Karp dan Rabin, suatu nilai fingerprint dihitung untuk setiap string. Nilai fingerprint tersebut lebih pendek dari string yang bersangkutan. Yang kemudian akan dibandingkan bukanlah string itu sendiri, melainkan nilai fingerprint yang telah dihitung. Perhitungan nilai fingerprint untuk pembandingan itulah yang diterapkan pada algoritma Running Karp-Rabin Greedy String Tiling ini. Penerapan algoritma Karp-Rabin pada fase scanpattern algoritma GST dijelaskan berikut ini. Jika |P| merupakan panjang salah satu substring pada pattern string P, maka nilai hash untuk setiap substring yang panjangnya |P| pada text string akan dibandingkan dengan nilai hash untuk substring dari pattern P tersebut. Jika kedua nilai hash tersebut identik, maka substring dari pattern P dan substring dari text string tersebut akan dibandingkan per elemen. Untuk lebih detilnya, algoritma Running Karp-Rabin diuraikan per tahap sebagai berikut: 1. Untuk setiap substring dari pattern string yang mempunyai panjang s dan belum ditandai, nilai hash dihitung. Misalnya untuk substring P[p..p+s-1], dengan p antara 1 sampai |P|-s. Nilai hash juga dibuat untuk setiap substring yang panjangnya s dan belum ditandai pada text string. 2. Sebuah hashtable digunakan untuk menurunkan cost O(n2) pembandingan. Hashtable tersebut menyimpan nilai hash setiap substring pada text string dan posisi token pertama pada setiap substring tersebut. 3. Setiap nilai hash untuk pattern string dibandingkan dengan nilai hash pada text string. Untuk nilai hash yang sama, terdapat kemungkinan adanya kesamaan antara substring yang bersangkutan. Setelah ditemukan nilai hash yang sama, pembandingan per token dilakukan untuk tokens pada posisi berikutnya seperti
II-15 pada algoritma GST. Pasangan substring yang sama tersebut juga akan dikonversi menjadi maximal-matches seperti pada algoritma GST. 4. Panjang pasangan yang dicari (disebut sebagai search-length s) dikurangi pada setiap akhir iterasi sampai minimum-match-length dicapai. Algoritma fase scanpattern pada RKR-GST mempunyai sebuah parameter yaitu search-length s. Algoritma RKR-GST untuk fase scanpattern dalam notasi algoritmik bisa dilihat pada Kode II-3. Algoritma tersebut diadopsi dari pseudocode yang terdapat pada literatur tentang algoritma RKR-GST [WIS93a,WIS93b]. function scanpattern (P[0..M],T[0..N] : tokenString, s: integer) integer {membandingkan setiap token pada P dan T} {token string P[1..M] merupakan token string yang lebih pendek dibandingkan dengan token string T[1..N]} {mencari pasangan substring yang bernilai sama dan panjangnya lebih besar dari search length s} KAMUS p: integer {posisi token pada pattern string} t: integer {posisi token pada text string} maxmatch_list : double-linked list of queues of match {List berisi maximal-match} hashtable : array of integer {menyimpan nilai hash pattern string} k : integer ALGORITMA for each unmarked(T[t]) in T[0..N] do if distance from t to next tile ≤ s then t position of first unmarked token after next tile else create the Karp-Rabin hash-value(T[t..t+s-1]) add hash-value(T[t..t+s-1]) to hashtable for each unmarked(P[p]) in P[0..M] do if distance from p to next tile ≤ s then p position of first unmarked token after next tile else create the Karp-Rabin hash-value(P[p..p+s-1]) {cek hashtable, cari nilai hash yang sama} for each hashtable entry = hash-value(P[p..p+s-1]) do k s while p+k<M and t+k(2*s) then {maximal-match sangat panjang, tinggalkan scan} {akan di-restart dengan s=k di top-level algorithm} k else add match(p,t,k) to maxmatch_list highest value in maxmatch_list
Kode II-3. Pseudocode Algoritma scanpattern(s) pada RKR-GST (diadopsi dari [WIS93b])
Struktur yang digunakan untuk menyimpan maximal-matches adalah sebuah doublelinked-list of queues (lihat Gambar II-2). Maximal-matches yang panjangnya sama disimpan dalam sebuah queue. List of queues diurutkan berdasarkan panjang maximal-matches yang disimpan dengan urutan mengecil.
II-16
Gambar II-2. Struktur Data Double Linked-list of Queues yang Dipakai Untuk Menyimpan Maximal-matches pada Algoritma Running Karp-Rabin Greedy String Tiling
Salah satu aspek yang penting adalah menentukan nilai yang tepat untuk parameter s yang merupakan search-length. Nilai yang lebih kecil dari setengah panjang P sudah cukup. Alasannya karena maximal-matches yang sangat panjang jarang ditemukan, sehingga secara umum nilai inisialisasi untuk s akan menghasilkan beberapa pass kosong pada scanpattern sampai sebuah match ditemukan. Alasan kedua yaitu jika maximal-match yang panjang (pada [WIS93a, WIS93b] asumsi ukuran maximalmatch yang panjang yaitu lebih besar dari 2*s), penciptaan tile dari string ini akan membutuhkan banyak token dari pattern string dan text string. Karena itu, scan harus dihentikan dan dimulai kembali dengan nilai s yang lebih besar yaitu sama dengan ukuran maximal-match panjang tersebut. Hal ini menunjukkan bahwa nilai s bisa diinisialisasi dengan nilai konstan yang kecil (misalnya s bernilai 20 pada contoh) daripada bergantung pada panjang string. Algoritma untuk fase markstrings sama dengan yang digunakan pada GST yang telah di-tuning (lihat Subbab 2.2.2), namun maximal-match dibaca dari list of queues dan mempunyai parameter search-length s. Semua pasangan yang dihasilkan dari proses hashing akan diuji per elemen sebab kesamaan nilai hash tidak menjamin bahwa substring yang berkorespondensi akan sama. Bisa diamati pada Kode II-3 dan Kode II-4 bahwa pengujian maximal-match ditunda dari fase scanpattern ke markstrings. Hal ini karena sudah diketahui dari hasil pengujian bahwa KR-hashing jarang sekali gagal, sehingga pengujian per komponen akan lebih efisien jika ditempatkan di fase markstrings. Kompleksitas kasus terburuk penggunaan algoritma ini yaitu O(n3) dengan n merupakan panjang string input. Namun telah diuji bahwa kondisi yang dapat menyebabkan kasus terburuk hampir tidak mungkin terjadi [WIS93a]. Dengan minimum-match-length yang bernilai 3, kompleksitas algoritma yang dihitung pada pengujian tersebut yaitu O(n0.90), hampir linier. Secara umum, estimasi kompleksitas algoritma yang sering muncul pada prakteknya adalah antara O(n) sampai O(n2).
II-17
procedure markstrings (P[0..M],T[0..N] : tokenString, s: integer) {membandingkan setiap token pada maximal-matches yang telah didapatkan pada fase scanpattern} {token string P[1..M] merupakan token string yang lebih pendek dibandingkan dengan token string T[1..N]} KAMUS p: integer {posisi token pada pattern string} t: integer {posisi token pada text string} maxmatch_list : double-linked list of queues of match {List berisi maximal-match} L: integer {ukuran maximal-match pada queue di iterasi tersebut} ALGORITMA starting with the first queue in maxmatch_list, while there is a non-empty queue do if the current queue is empty then drop to next queue {maximal-match dengan ukuran lebih kecil} else if all tokens in match(p,t,L) are unmarked then if P[p+j]=T[t+j] for all j0 to s-1 then for j0 to L-1 do mark_token(P[p+j]) mark_token(T[t+j]) length_of_tokens_tiled length_of_tokens_tiled + L else if (L – length of marked tokens in match(p,t,L)) ≥ s then add unmarked portion to maxmatch_list delete match(p,t,L) from queue
Kode II-4. Fungsi markstrings(s) pada Algoritma RKR-GST dengan s Merupakan Search-length [WIS93a,WIS93b] procedure RunningKarpRabinGreedyStringTiling(P[0..M],T[0..N] : tokenString, minimum_match_length : integer) {top-level algorithm untuk Running Karp-Rabin Greedy String Tiling} {token string P[1..M] merupakan token string yang lebih pendek dibandingkan dengan token string T[1..N]} {mencari substring yang bernilai sama dan panjangnya lebih besar dari minimum_match_length} KAMUS s : integer {search-length} stop : boolean Lmax : integer ALGORITMA s 20 {inisialisasi search-length} stop false repeat Lmax scanpattern(s) {the size of largest maximal-matches} {found in this iteration} if Lmax>(2*s) then {Very long string} s Lmax {don’t mark tiles but try again with larger s} else markstrings(s) {Create tiles from matches takes from list of queues} if s>(2*minimum_match_length) then s s div 2 else if s > minimum_match_length then s minimum_match_length else stop true until stop
Kode II-5. Top-level Algorithm untuk RKR-GST [WIS93a,WIS93b]
II-18 Minimum-match-length
merupakan
parameter
yang
dapat
merepresentasikan
sensitivitas algoritma ini. Penjelasan teoritis mengenai parameter minimum-matchlength dapat dilihat di Subbab 2.2.1 mengenai algoritma Greedy String Tiling. Sedangkan analisis mengenai penggunaan parameter minimum-match-length untuk mewakili tingkat sensitivitas deteksi akan dijelaskan pada Subbab 3.2.3.
2.3 Perangkat Lunak Pendeteksi Plagiarisme Otomatis pada Source Code Telah dikembangkan banyak perangkat lunak pendeteksi plagiarisme yang menggunakan pendekatan structure-based. Berikut ini dipaparkan mengenai beberapa perangkat lunak pendeteksi plagiarisme yang paling sering dijadikan referensi untuk penelitian mengenai deteksi plagiarisme, yaitu Plague, YAP dan JPlag. Source code YAP tersedia sebagai open source dan dapat dikembangkan untuk kepentingan
akademik. 2.3.1 Plague Sistem Plague merupakan pengembangan dari pendekatan berbasis struktur dan menggunakan detil struktur program untuk proses pembandingan source code [CLO00]. Plague bekerja dalam 3 tahap :
1. Sebuah sequence of tokens dan list structure metrics diproduksi untuk setiap file. Komponen structure metrics merepresentasikan iterasi, statement selection, dan statement blocks pada kode program. Sequence of tokens dan list structure metrics tersebut kemudian dibentuk menjadi structure profile yang merupakan ringkasan dari struktur di program. 2. Structure profile dibandingkan sebanyak O(n2) fase. Pasangan tetangga terdekat ditentukan menggunakan kombinasi fungsi yang spesifik tergantung pada bahasa pemrograman target. Diharapkan pada akhir fase ini sebagian besar structure profile tidak terpasangkan. Structure profile yang berpasangan akan menjadi input pada tahap ketiga. 3. Sequence token dibandingkan menggunakan variant dari algoritma longest common subsequences, yaitu algoritma Heckel (lihat Subbab 2.3.2.3).
II-19 Hasil deteksi plagiarisme yang dihasilkan Plague cukup akurat, namun ada beberapa kekurangan yang dimiliki sebagai berikut : 1. Untuk menulis versi Plague baru agar dapat menangani bahasa pemrograman lain memerlukan usaha besar dan membutuhkan waktu yang tidak singkat, diawali dengan pembangunan parser untuk bahasa tujuan dan pemilihan distance metrics untuk penggunaan pada fase kedua. 2. Hasil proses deteksi dikembalikan dalam bentuk dua buah list yang diurutkan oleh indices H dan HT yang perlu interpreter. Cara pembacaan ada di manual Plague, namun hal ini menyatakan bahwa hasil tidak bisa dilihat begitu saja oleh pengguna tetapi harus ada pemrosesan lebih lanjut. 3. Ada bagian dari Plague yang ditulis dalam bahasa Pascal, padahal implementasi C yang berkualitas baik lebih umum sementara implementasi Pascal yang berkualitas baik sangatlah langka. Selain itu Plague juga bergantung pada beberapa utility UNIX dan GIVE sehingga menimbulkan masalah portability. 2.3.2 YAP YAP (Yet Another Plague) [WIS92,WIS96] dibangun berdasarkan sistem deteksi
plagiarisme Plague. Michael Wise membuat versi originalnya (YAP1) pada tahun 1992 yang kemudian dioptimasi menjadi YAP2. Pada tahun 1996 Wise memproduksi versi finalnya yaitu YAP3 yang juga bisa mendeteksi plagiarisme pada teks. Tujuan pembuatan YAP adalah membuat suatu sistem deteksi plagiarisme dengan fondasi Plague dan mengatasi masalah-masalah yang dihadapi pengguna ketika menggunakan Plague. Plague dijadikan sebagai fondasi karena perangkat lunak tersebut telah
dibuktikan lebih sukses daripada teknik-teknik attribute-counting dan structure-based sebelumnya. YAP dibuat agar sederhana dan portable walaupun mengorbankan sedikit akurasi dan kecepatan Plague. 2.3.2.1 Persamaan dan Perbedaan Ketiga Versi YAP Ketiga versi YAP mempunyai dua fase dalam operasinya : 1. Fase generation : sebuah file token dihasilkan untuk setiap source code yang dikumpulkan. 2. Fase pembandingan : pasangan file token dibandingkan.
II-20 Token merepresentasikan elemen signifikan dalam bahasa pemrograman yang dipakai, misalnya struktur bahasa atau fungsi built-in. Identifier dan semua konstanta diabaikan. File token umumnya berukuran kecil, yaitu 100-150 token untuk tugas kecil, dan 400-700 token untuk tugas besar. Kesamaan ketiga versi YAP yang telah dikembangkan yaitu pada proses tokenisasi di fase pertama. Proses tokenisasi punya struktur umum sebagai berikut: 1. Preprocess submisi untuk menghilangkan komentar dan print-strings dan translasi huruf besar ke huruf kecil, menghilangkan huruf yang tidak ditemukan di identifier legal, dan membentuk list of token primitif. 2. Mengganti sinonim ke bentuk umum. Contohnya pada LISP, second dan cadr diganti menjadi car dan cdr. Sementara untuk bahasa pemrograman C, strncmp diganti ke strcmp. 3. Mengidentifikasi blok fungsi atau prosedur. Jika telah mengidentifikasi blok fungsi, cetak blok fungsi sesuai urutan pemanggilan. Bentuk "macro-expansion" digunakan, tapi sebuah blok hanya di-expand sekali untuk mencegah agar jumlah token tidak meledak. Pemanggilan subsequent ke fungsi yang sudah di-expand diganti dengan beberapa token yang merepresentasi fungsi itu. 4. Kenali dan cetak token yang merepresentasi bagian dari bahasa target dari vocabulary yang diberikan. Perbedaan ketiga versi YAP yang telah dikembangkan terletak pada fase kedua, yaitu algoritma yang digunakan fase pembandingan setiap token strings. Selain itu ada perbedaan pada teknik implementasi termasuk bahasa pemrograman yang digunakan. 2.3.2.2 YAP1 Pada YAP1, fase generation atau tokenisasi untuk bahasa yang berbeda dilakukan oleh program YAP yang berbeda agar sederhana. Beberapa hal khusus yang dilakukan pada fase tokenisasi YAP1 yaitu [WIS92]: 1. Preprocessing submisi dilakukan menggunakan utility UNIX tr dan sed. Dalam C_YAP, preprocessor cpp digunakan.
2. Untuk mengidentifikasi blok fungsi atau prosedur, tidak ada hal khusus yang harus dilakukan pada LISP_YAP. Pada C_YAP, UNIX utility ctags digunakan bersama awk.
II-21 3. Penggantian pemanggilan subsequent ke fungsi yang sudah di-expand dengan beberapa token yang merepresentasi fungsi dilakukan dengan suatu subprogram YAP yang berukuran kecil (208 baris), sehingga program mudah dikustomisasi
agar dapat menangani bahasa pemrograman lain. 4. Function calls yang diidentifikasi pada tahap sebelumnya diganti menjadi token FUN. Identifier lain diabaikan. Bagian-bagian dari bahasa yang dipilih tidak harus
ada pada vocabulary final. not pada LISP dan ! pada C diabaikan karena mudah untuk mengubah kondisi if menggunakan negasi. Proses ini dilakukan menggunakan utility awk. Setelah itu, sebuah script (Bourne) shell digunakan untuk menggabungkan seluruh bagian menjadi input tahap pembandingan. 5. Tahap pembandingan merupakan tahap yang sama untuk semua implementasi YAP1. Utility UNIX find digunakan untuk mengumpulkan file-file token yang
sudah disiapkan sebelumnya. Dengan mengabaikan duplikasi test, setiap file token dibandingkan dengan file lain menggunakan sdiff. Hasil dari setiap analisis sdiff merupakan nilai antara 0 sampai 100 yang merepresentasikan nilai antara
"no-match" sampai "complete-match". Nilai ini dihasilkan dari formula : Match = (same-diff) / minfile - (maxfile-minfile) / maxfile; PercentMatch = max(0,Match) x 100;
Keterangan : a. Fungsi max mengembalikan nilai maksimum dari kedua argumen yang diterima sebagai input. b. maxfile merupakan file yang berukuran lebih besar di antara kedua file, sementara minfile merupakan file yang berukuran lebih kecil. c. same merupakan jumlah token yang sama pada kedua file masukan. d. diff merupakan jumlah perbedaan baris pada blok token yang berpasangan. e. Nilai percentmatch disimpan di sebuah file misalnya YAP.numbers. Jika nilai untuk sebuah pasangan melebihi nilai yang dispesifikasi oleh pengguna pada command line, pasangan dan nilai percentmatch disimpan di file kedua, yaitu YAP.summary.
Akhirnya,
ketika
semua
pembandingan
telah
dibuat,
YAP.summary diurutkan menurun berdasarkan percentmatch kemudian
sebuah mean dan standar deviasi dikalkukasi dan ditambahkan ke file. Untuk mengukur similarity antara kedua string, YAP1 menggunakan algoritma Longest Common Subsequences (LCS) yang tujuannya menemukan sequence token
II-22 terpanjang yang sama pada kedua string. Sebuah subsequence dari string S dibentuk dengan mengambil tokens secara berurutan dengan mengabaikan tokens sejumlah nol atau lebih sebelum mengambil token berikutnya. Panjang LCS untuk string yang identik sama dengan ukuran sebuah string. Selain membutuhkan waktu yang lama untuk melakukan deteksi, masalah utama YAP adalah pada algoritma LCS yang dijelaskan di atas. Algoritma tersebut mempunyai masalah karena urutan token berpengaruh pada algoritma tersebut. Substring yang diubah urutannya akan dianggap sebagai kumpulan transposisi individual dan bukan perpindahan blok tunggal. Algoritma tersebut hanya dapat berfungsi dengan baik untuk selisih satu token saja dengan mengabaikan elemen tertentu. 2.3.2.3 YAP2 YAP2 ditulis dalam bahasa Perl dan menggunakan program C custom bernama Heckel
[CLO00, WIS92]. Program tersebut mengimplementasikan algoritma Heckel, yang merupakan sebuah algoritma yang diusulkan oleh Paul Heckel untuk mengatasi masalah yang dihadapi algoritma LCS yang dipakai pada YAP1. Algoritma Heckel didesain untuk menangani file teks dan dikembangkan untuk mengatasi masalah algoritma Longest Common Subsequences [WIS92]. Walaupun algoritma Heckel ini membutuhkan beberapa pass, kompleksitas keseluruhannya linier. Selain itu, tidak seperti algoritma LCS pada YAP1, algoritma Heckel dapat menangani perubahan urutan segmen kode pada program. Namun algoritma Heckel ini juga mempunyai kelemahan, yaitu terkadang substring yang lebih panjang tidak diutamakan. Seringkali substring-substring identik yang ditemukan algoritma ini merupakan substringsubstring pendek yang letaknya tersebar, namun sebenarnya tidak lebih berpengaruh dibandingkan substring panjang yang tidak diutamakan. 2.3.2.4 YAP3 Seperti versi-versi sebelumnya, YAP3 juga bekerja melalui 2 fase. Fase generation atau tokenisasi tidak mengalami perubahan besar walaupun tokenizer bekerja dengan lebih baik daripada tokenizer pada versi-versi sebelumnya. Selain itu, token di YAP3 bukan merupakan string melainkan numerik [WIS96]. YAP3 menggunakan algoritma Running Karp-Rabin Greedy String Tiling pada fase pembandingan (lihat Subbab 2.2.3).
II-23 2.3.3 JPlag JPlag dibangun dan di-maintain oleh Guido Malpohl dari Department of Informatics
di Universitas Karlsruhe [LUT00]. Sistem ini dapat mendeteksi kesamaan antara source code yang ditulis dalam bahasa pemrograman Java, C, C++ dan Scheme. JPlag tersedia sebagai web service dan dapat digunakan secara gratis. Program meminta input dari pengguna berupa direktori yang berisi kumpulan program yang akan dibandingkan. Direktori tersebut secara fisik terdiri dari subdirektori-subdirektori yang setiap subdirektorinya dianggap sebagai sebuah program. Setiap subdirektori bisa berisi beberapa file source code sehingga secara keseluruhan kumpulan source code tersebut dianggap sebagai sebuah program. Setelah deteksi dilakukan, hasilnya akan ditampilkan sebagai kumpulan file HTML yang bisa dibuka menggunakan browser standar. Salah satu aspek menjadi kelebihan JPlag adalah user interface untuk menampilkan hasil deteksi. Biasanya sistem-sistem deteksi yang dikembangkan sebelum JPlag hanya menggunakan suatu nilai similarity pasangan program untuk menyatakan hasil deteksi. Padahal hasil dari sistem deteksi tidak bisa langsung digunakan untuk menentukan apakah suatu pekerjaan merupakan hasil praktek plagiarisme atau bukan, misalnya pada kasus nilai similarity sama dengan 40% atau jika soal yang cukup mudah sehingga banyak submisi yang mirip satu sama lain. Kasus-kasus sejenis itu masih membutuhkan analisis dari pemeriksa untuk penentuan keputusan akhir. Karena itulah, JPlag menyediakan user interface yang dapat menampilkan hasil agar dapat dianalisis dengan mudah. Statistik deteksi, distribusi similarity dan pasanganpasangan program yang diduga merupakan hasil plagiarisme ditampilkan di halaman utama. Selain itu, source code pasangan program juga bisa ditampilkan bersebelahan pada sebuah halaman HTML agar pengguna mudah untuk membandingkan ketika menganalisis. Pada halaman utama, terdapat statistik deteksi yang terdiri dari jumlah submisi, bahasa pemrograman, tanggal, dan berbagai parameter lainnya. Kemudian terdapat tabel yang berisi distribusi similarity dengan selisih 10% dan sebuah histogram yang menampilkan nilai-nilai similarity untuk semua pasangan program.
II-24
Gambar II-3. Bagian Atas Contoh Halaman yang Menampilkan Hasil Deteksi JPlag [LUT00]
Pengguna dapat memilih pasangan kode program untuk ditampilkan bersebelahan pada sebuah halaman HTML. Untuk memudahkan pembandingan secara manual, segmen kode yang dianggap serupa pada kedua program ditampilkan dengan warna yang sama. Pada masing-masing program, di samping setiap segmen kode terdapat sebuah panah. Jika pengguna klik panah tersebut maka display program pasangannya akan berubah atau lompat ke segmen kode yang berkorespondensi. Dengan fasilitasfasilitas tersebut maka pengguna dengan mudah dapat menganalisis setiap pasangan program dan juga dapat melihat plagiarisme parsial. User interface sistem deteksi plagiarisme seperti ini baru pertama kali dimiliki oleh JPlag.
II-25
Gambar II-4. Contoh Bagian dari Halaman yang Menampilkan Pasangan Program pada Tampilan Hasil Deteksi JPlag [LUT00]
Setelah menerima input, JPlag melalui dua fase untuk melakukan deteksi plagiarisme. Pada fase pertama, semua program di-parse atau di-scan terlebih dahulu kemudian dikonversi ke token string. Bagian JPlag yang berfungsi untuk melaksanakan tugas ini merupakan satu-satunya bagian yang language-dependent. Untuk mendeteksi plagiarisme dalam source code berbahasa pemrograman C atau C++, sistem hanya membutuhkan scanner. Untuk Java dan Scheme, digunakan parser yang mempunyai keuntungan lebih daripada scanner karena lebih banyak informasi semantik yang dapat direpresentasi pada token string. Token dipilih sedemikian rupa agar merepresentasikan karakteristik inti program yang sulit diubah oleh plagiator. Sebagai contoh, whitespace dan komentar selalu diabaikan karena merupakan bagian-bagian yang paling mudah dipakai untuk menyembunyikan praktek plagiarisme. Jenis-jenis token yang dihasilkan tergantung pada jenis bahasa
II-26 pemrograman pada kumpulan source code input. Setiap token akan dianggap sebagai karakter tunggal pada saat pembandingan.
Gambar II-5. Contoh Source Code Java dan Kumpulan Token yang Mewakili Setiap Barisnya pada JPlag (diambil dari [LUT00])
Pada fase kedua, token string hasil fase pertama dibandingkan secara berpasangan kemudian similarity setiap pasangan dihitung. Algoritma yang dipakai untuk membandingkan setiap pasangan program yaitu algoritma Karp-Rabin Greedy String Tiling yang diperkenalkan oleh Michael Wise (lihat Subbab 2.2.3).
