BAB II
LANDASAN TEORI 2.1 Dasar Teori
2.1.1 Sequential Pattern Mining Framework (SPMF)
SPMF adalah sebuah library metode data mining open-source yang ditulis menggunakan bahasa pemrograman Java. Perangkat lunak yang dibuat oleh Philippe Fournier-Viger pada tahun 2008 ini menawarkan implementasi lebih dari 130 algoritma data mining untuk menemukan pola sekuensial, aturan sekuensial, peraturan asosiasi, pola utilitas tinggi,
frequentents itemset, pola periodik, cluster, dan banyak lagi.
Khusus dalam pertambangan pola. Kode sumber setiap algoritma yang tedapat pada SPMF dapat dengan mudah diintegrasikan ke dalam perangkat lunak Java lainnya. Selain itu, SPMF dapat digunakan sebagai program mandiri dengan user interface yang sederhana atau dari command
line. Versi SPMF yang penulis gunakan saat ini yaitu v2.17 yang diris pada
3 juli 2017.
Perangkat lunak SPMF secara native menggunakan file teks sebagai masukan. File input sampel ini dapat didownload dari halaman download (test_files.zip) untuk versi rilis SPMF, dan disertakan dengan kode sumber, untuk versi kode sumber SPMF.
Masukan dari library SPMF berupa file teks, seperti terlihat pada contoh berikut:
1 -1 1 2 3 -1 1 3 -1 4 -1 3 6 -1 -2 1 4 -1 3 -1 2 3 -1 1 5 -1 -2 5 6 -1 1 2 -1 4 6 -1 3 -1 2 -1 -2 5 -1 7 -1 1 6 -1 3 -1 2 -1 3 -1 -2
Keluaran dari library SPMF berupa file teks, seperti terlihat pada contoh di bawah:
-1 #SUP: 4 #SID: 0 1 2 3 3 -1 #SUP: 4 #SID: 0 1 2 3 4 -1 #SUP: 3 #SID: 0 1 2 5 -1 #SUP: 3 #SID: 1 2 3 6 -1 #SUP: 3 #SID: 0 2 3
Arti nilai output yang di hasilkan dari software SPMF. -2 : Akhir dari nilai sebuah urutan / nilai di akhir setiap baris -1 : Akhir dari item set
1 ,2,3,4,5,6 : Sequences / urutan data
#SUP : muncul diikuti oleh sebuah integer yang mengindikasikan dukungan dari pola
#SID : Parameter ini memungkinkan untuk menentukan bahwa id sekuensi urutan yang mengandung pola harus menghasilkan output untuk setiap pola yang ditemukan, kemudian menghasilkan bilangan bulat yang dipisahkan oleh spasi
2.1.2 Netbeans
Netbeans merupakan sebuah aplikasi Integrated Development
Environment (IDE) yang berbasiskan java dari Sun Microsystem yang
berjalan di atas swing. Swing merupakan sebuah teknologi java untuk pengembangan aplikasi desktop yang dapat berjalan pada berbagai macam platformns seperti windows, linux, Mac OS X dan solaris. Sebuah IDE merupakan lingkup pemograman yang diitegrasikan ke dalam suatu aplikasi perangkat lunak yang menyediakan Graphic User
Interface (GUI), suatu kode editor atau text, suatu compiler dan suatu debugger.
2.1.3 GSP (Generalized Sequential Pattern)
GSP adalah algoritma mining yang memakai pendekatan
candidat-and-test, yaitu dengan membangkitkan pola-pola yang kemudian dihitung
jumlah kemunculannya. Apabila melebihi nilai threshold, pola tersebut menjadi sequential pattern, dan bila tidak, pembangkitan pola-pola merupakan supersequence dari pola tersebut tidak akan pernah dilakukan. Hal ini dimaksudkan untuk semakin membatasi pembangkitan kandidat.
GSP juga merupakan format data horizontal berurutan Algoritma penambangan pola. Berdasarkan properti penutupan ke bawah dari pola sekuensial, GSP mengadopsi pendekatan multiple-pass, candidate
generation-and-test di pertambangan berurutan. Algoritma GSP
menciptakan banyak cara dalam database. Salah satu caranya, setiap item atau produk tunggal (urutan pertama) dihitung. Dari item yang sering keluar atau muncul, tercipta sebuah kumpulan kandidat urutan kedua, dan cara lain dibuat untuk melengkapi urutan tersebut. Urutan kedua yang sering keluar digunakan untuk menghasilkan kandidat urutan ketiga.
Struktur dasar algoritma GSP adalah algoritma dapat membuat beberapa data. Pertama menentukan dukungan dari setiap item, yaitu jumlah data yang mencangkup item. Setiap item seperti menghasilkan 1 elemen urutan.
Contoh 1 (GSP) Mengingat urutan database Din Tabel ( ) dan
Min_suppor t = 2, pemindaian pertama GSP, mengumpulkan dukungan
untuk setiap item, dan Menemukan kumpulan item yang sering, yaitu, sering terjadi kemunculan-1 (dalam bentuk "Item: support"): <a>: 4, <b>: 4, <c>: 4, <d>: 3, <e>: 3, <f>: 3, <g>: 1.
Gambar 1 Kandidat, calon generasi, dan pola sekuensial di GSP
Dengan menyaring item yang jarang, kita mendapatkan benih pertama yang ditetapkan L1 ={<a>, <b>, <c>, <d>, <e>, <f>}, dengan setiap anggota di set mewakili elemen-1 Pola berurutan Setiap lulus berikutnya dimulai dengan set benih yang ditemukan di jalur sebelumnya dan menggunakannya untuk menghasilkan pola sekuensial potensial baru, yang disebut kandidat urutan.
ForL1, satu set dari 6 panjang-1 pola sekuensial menghasilkan satu set 6×6+ = 51 urutan kandidat, C2 = {<aa>, <ab>, ...,<af>, <ba>, <bb>, ..., <ff>,<(ab)>, <(ac)>, ..., <(ef)>}.
2.1.4 CM-Spade
CM-Spade Memakai pendekatan berbasis kandidat-and-test, sehingga
algoritma ini perlu melakukan sekali scan terhadap basis data untuk menemukan pola dengan satu elemen yang sering muncul. Untuk membangkitkan kandidat pola dengan dua elemen, dilakukan dengan cara menggabungkan seluruh pola satu elemen pola apabila pola tersebut melebihi nilai threshold dan memiliki identitas sequence yang sama. Hal
ini dilakukan terus menerus hingga tidak ada lagi pembangkitan kandidat pola, yang berarti seluruh sequential pattern telah di temukan.
Spade memetakan database urutan ke dalam format data vertikal yang
mengambil setiap item sebagai pusat pengamatan dan mengambil urutan terkait dan pengidentifikasi acara sebagai kumpulan data. Untuk menemukan urutan panjang-2 item, itu hanya perlu untuk menggabungkan dua item tunggal jika mereka sering dan mereka berbagi pengenal urutan yang sama dan pengenal acara mereka (yang pada dasarnya adalah perangko waktu relatif) mengikuti urutan pemesanan. Demikian pula, SPADE dapat menumbuhkan urutan dari panjang dua sampai tiga, dan seterusnya.
SPADE bergantung pada kisi urutan yang sering dihasilkan dengan
menerapkan teori kisi pada urutan yang sering dan urutannya. Ini juga membusuk Ruang pencarian asli (kisi) menjadi potongan-potongan kecil (sub-kisi) yang disebute quivalence kelas, yang bisa dimuat dan diproses secara mandiri di memori utama. Dua urutan dianggap berada di kelas yang sama jika mereka memiliki panjang k yang sama awalan. Setiap sub-kisi dapat dilalui melalui pencarian baik pertama maupun pertama untuk menghitung urutan yang sering, yang menghitung kemudian dihitung melalui sederhana temporal bergabung (atau persimpangan) on
id-list.
2.1.5 Prefix Span
PrefixSpan (Prefix Sequential Pattern Growth) adalah algoritma yang
memakai pendekatan pengembangan sequence untuk mencari sequential pattern. PrefixSpan akan mencari frequent sequence satu elemen dan kemudiian mengembangkan sequence-sequence tersebut dengan cara menambahkan elemen satu persatu. PrefixSpan dirancang sedemikian rupa sehingga sequence hasil penambahan elemen tersebut tetap
merupakan frequent sequence. Dengan cara ini, tidak diperlukan pembangkit dan pengujian kandidat.
PrefixSpan dibangun di atas konsep FreeSpan namun bukan
memproyeksikan database urutan yang hanya memeriksa awalan dan hanya memproyeksikan proyek mereka. Akhiran sufiks yang sesuai ke dalam database yang diproyeksikan. Dengan cara ini, sekuensial Pola ditanam di setiap database yang diproyeksikan dengan hanya
mengeksplorasi urutan umum lokal. Ide utama dari PrefixSpan adalah
dengan memproyeksi database yang memiliki prefix frequent. Ide ini dikembangkan karena adanya prinsip yang menyatakan bahwa setiap
frequent sequence selalu dapat di hasilkan dari prefix yang frequent.
Perbedaan antara GSP, Prefix Span dan CM-SPADE dapat dilihat di Lampiran A.
2.1.6 Event Log
Pendekatan proses mining bertujuan untuk menemukan model yang tepat. Namun, urutan clustering dapat memberikan wawasan berharga tentang jenis urutan yang sedang dieksekusi. Secara umum, semua proses pendekatan mining mengambil log peristiwa sebagai masukan dan sebagai titik awal untuk penemuan proses yang mendasarinya.
Log peristiwa (juga disebut event log) adalah daftar catatan hasil
eksekusi beberapa proses. Persyaratan pada log, yaitu jenis informasi yang harus dikandungnya, bervariasi sesuai dengan algoritma yang digunakan salah satunya algoritma α, sebuah algoritma yang mampu menciptakan kembali alur kerja Petri-net dari hubungan pemesanan yang ditemukan di log genap. Agar algoritma bekerja, log harus berisi instance
identifier proses (case id) dan harus agak lengkap dalam artian semua
2.1.7 Contoh Event Log
Gambar 2 memperlihatkan model proses yang mendeskripsikan penanganan permintaan kompensasi dalam sebuah perusahaan penerbangan. Pelanggan dapat mengajukan permintaan kompensasi dengan berbagai alasan, misalnya terjadi delay atau pembatalan penerbangan. Proses ini dimulai dengan mendaftarkan permintaan. Aktivitas ini dinamakan dengan register request. Setelah permintaan didaftarkan, maka berikutnya adalah melakukan cek administrative untuk memeriksa apakah pelanggan tersebut berhak mengajukan permintaan kompensasi. Aktivitas ini dinamakan dengan check ticket. salah satu dari dua aktivitas, yaitu (1) jika permintaan dinilai mencurigakan atau kompleks, maka dilakukan pemeriksaan secara mendalam (examine
thoroughly), atau (2) jika permintaan dianggap tidak mencurigakan atau
cukup jelas, maka dilakukan pemeriksaan secukupnya (examine
casually). Hasilnya kemudian diputuskan dalam aktivitas decide. Ada
tiga kemungkinan keputusan, yaitu permintaan kompensasi dipenuhi (pay
compensation), permintaan ditolak (reject request), atau diperlukan
pemrosesan lebih lanjut (reinitiate request). Jika diperlukan pemrosesan lebih lanjut, maka proses kembali ke setelah register request, atau dengan kata lain, tidak diperlukan pendaftaran lagi. Proses akan berakhir ketika kompensasi dibayarkan atau ditolak. Gambar memperlihatkan struktur dari sebuah event log, yaitu:
Sebuah proses terdiri dari banyak case.
Sebuah case terdiri dari banyak event, dimana setiap event terhubung dengan satu case.
Event di dalam case terurut.
Event dapat memiliki atribut, contohnya aktivitas, waktu, biaya,
dan resource.
Gambar 2 Model proses penanganan permintaan kompensasi
Tabel 1 memperlihatkan cuplikan log yang merekam proses penanganan permintaan kompensasi tersebut. Setiap baris mewakili satu event. beberapa event dikelompokkan menjadi sebuah case. Case 1 memiliki lima
event. Event pertama dalam case 1 adalah pelaksanaan aktivitas
mendaftarkan permintaan (register request) oleh Pete pada 30 Desember 2010. Tabel tersebut juga menunjukkan id khusus untuk event ini: 35654423. Id ini digunakan agar dapat mengidentifikasi sebuah event, misalnya untuk membedakan event tersebut dengan event 35654483 yang juga merupakan pelaksanaan aktivitas register request (event pertama dari
case kedua). Tabel tersebut juga menampilkan tanggal dan waktu
(timestamp) untuk setiap event. Ada kemungkinan dalam beberapa event
log, informasi ini tidak diberikan secara detail dan hanya tanggal atau
urutan event yang ada. Namun mungkin juga dalam kasus lain, terdapat informasi waktu yang lebih detil seperti kapan sebuah aktivitas dimulai, kapan selesai, serta kapan hasilnya ditampilkan pada user. Kolom waktu atau timestamp yang ada dalam tabel tersebut menunjukkan waktu selesainya sebuah aktivitas. Dalam event log ini, aktivitas dianggap atomik dan tabel tersebut tidak merekam durasi aktivitas. Dalam tabel tersebut setiap event berhubungan dengan sebuah resource. Dalam beberapa log, mungkin saja informasi ini tidak tersedia. Sedangkan dalam log yang lain, terdapat informasi yang mendetail mengenai resource, misalnya rule atau jabatan dari resource tersebut atau mengenai autorisasi yang terjadi antar
biaya untuk setiap event. Informasi ini merupakan contoh atribut data. Ada banyak atribut data yang lain, seperti outcome atau hasil dari setiap event, atau dalam contoh di tabel, dapat disertakan jumlah kompensasi yang diminta. Atribut ini dapat merupakan atribut dari seluruh case atau disimpan sebagai atribut dari event register request. Tabel 1 memperlihatkan informasi yang biasanya ada dalam sebuah event log. Informasi bagian mana yang digunakan tergantung pada teknik dan pertanyaan yang akan dijawab.
Tabel 1 Cuplikan sebuah event log: setiap baris menunjukkan sebuah event
Case id
Event id
Properties
Timestamp Activity Resource Cost 1 35654423 30-12 2012:11.02 Register request Pete 50
35654424 31-12-2010:10.06 Examine thoroughly
Sue 400
35654425 05-01-2011:15.12 Check ticket Mike 100 35654426 06-01-2011:11.18 Decide Sara 200 35654427 07-01-2011:14.24 Reject request Pete 200
2 35654483 30-12-2010:11.32 Register request Mike 50 35654485 30-12-2010:12.12 Check ticket Mike 100 35654487 30-12-2010:14.16 Examine casually Pete 400 35654488 05-01-2011:11.22 Decide Sara 200 35654489 08-01-2011:12.05 Pay compensation Ellen 200
3 35654521 30-12-2010:14.32 Register request Pete 50 35654522 30-12-2010:15.06 Examine
casually
Mike 400
35654524 30-12-2010:16.34 Check ticket Ellen 100 35654525 06-01-2011:09.18 Decide Sara 200 35654526 06-01-2011:12.18 Reinitiate Sara 200
Case
id Event id
Properties
Timestamp Activity Resource Cost request
35654527 06-01-2011:13.06 Examine
thoroughly Sean 400 35654530 08-01-2011:11.43 Check ticket Pete 100 35654531 09-01-2011:09.55 Decide Sara 200 35654533 15-01-2011:10.45 Pay
compensation Ellen 200
4 35654641 06-01-2011:15.02 Register request Pete 50 35654643 07-01-2011:12.06 Check ticket Mike 100 35654644 08-01-2011:14.43 Examine
thoroughly Sean 400 35654645 09-01-2011:12.02 Decide Sara 200 35654647 12-01-2011:15.44 Reject request Ellen 200
5 35654711 06-01-2011:09.02 Register request Ellen 50 35654712 07-01-2011:10.16
Examine
casually Mike 400
35654714 08-01-2011:11.22 Check ticket Pete 100 35654715 10-01-2011:13.28 Decide Sara 200 35654716 11-01-2011:16.18 Reinitiate reque
st Sara 200
35654718 14-01-2011:14.33 Check ticket Ellen 100 35654719 16-01-2011:15.50 Examine casually Mike 400 35654720 19-01-2011:11.18 Decide Sara 200 35654721 20-01-2011:12.48 Reinitiate request Sara 200 35654722 21-01-2011:09.06 Examine casually Sue 400
35654724 21-01-2011:11.34 Check ticket Sara 100 35654725 23-01-2011:13.12 Decide Sara 200
Case
id Event id
Properties
Timestamp Activity Resource Cost 35654726 24-01-2011:14.56 Reject request Mike 200
6 35654871 06-01-2011:15.02 Register request Mike 50 35654873 06-01-2011:16.06 Examine
casually Ellen 400 35654874 07-01-2011:16.22 Check ticket Mike 100 35654875 07-01-2011:16.52 Decide Sara 200 35654877 16-01-2011:11.47 Pay
compensation
Mike 200
Gambar 3 Struktur sebuah event log
Informasi yang mewakili aturan minimum tersebut adalah “case id” dan “activity” seperti terlihat dalam Tabel 1. Dengan menggunakan kedua informasi tersebut,
maka kita mendapatkan bentuk yang lebih singkat seperti dipelihatkan dalam Tabel 2. Dalam tabel tersebut, setiap case diperlihatkan sebagai urutan aktivitas yang disebut sebagai trace. Untuk mempermudah, setiap nama aktivitas telah diubah menjadi label yang terdiri dari satu huruf, misalnya a melambangkan aktivitas register request. (Aggarwa, 2014).
Tabel 2 Contoh Trace Clustering
Case id Trace 1 <a, b, d, e, h> 2 <a, d, c, e, g> 3 <a, c, d, e, f, b, d, e, g> 4 <a, d, b, e, h> 5 <a, c, d, e, f, d, c, e, f, c, d, e, h> 6 <a, c, d, e, g>
BAB III
ANALISIS DAN PERANCANGAN 3.1 Analisis Sistem
3.1.1 Format Input
Untuk proses analisis data, aplikasi perangkat lunak ini menggunakan
file input dengan format CSV (Comma Separated Values ), format data
tersebut seperti Gambar 4.
Gambar 4 Data event log
Pada format input dengan format excel/csv terdiri dari
1. Case id ialah beberapa event dikelompokkan menjadi sebuah case. 2. Event id digunakan agar dapat mengidentifikasi sebuah event, 3. Activity merupakan aktivitas.
Contohnya seperti 1;35654423;register request, 1 merupakan case id, 35654423 merupakan event id, dan request merupakan aktivitas yang terjadi.
Untuk proses menjalankan metode data mining, aplikasi perangkat lunak ini menggunakan file input dengan format CSV (Comma
Separated Values ), agar output yang dihasilkan berupa activityformat
Gambar 5 Format input untuk menjalankan metode data mining
3.1.2 Format Output
Aplikasi akan menghasilkan output dengan fomat text file. Format
output tersebut seperti di bawah ini: Register request #SUP: 3 #SID: 5,6 Register request, Decide #SUP: 3
Pada format output tersebut terdiri dari : 1. Activity merupakan aktivitas.
2. SUP : Aktivitas minimum support.
3. SID sama dengan Case Id : untuk menentukan id sequence
3.1.3 Analisis spesifikasi kebutuhan software dan hardware 3.1.3.1 Analisis Kebutuhan perangkat keras (Hardware)
Tidak diperlukan hardware khusus, untuk membangun dan menjalankan, hardware yang digunakan untuk membangun aplikasi ini adalah dengan spesifikasi sebagai berikut :
b) Memory 2048Mb RAM d) Mouse
3.1.3.2 Analisis Perangkat Lunak/Software
Spesifikasi perangkat lunak yang dibutuhkan untuk mendukung aplikasi yang akan dibangun adalah sebagai berikut:
a) Sistem Operasi: Microsoft Windows 7 b) Microsoft Office 2010
c) NetBeans IDE 8.2 d) Microsoft Visio 2010 e) StarUML
3.2 Perancangan Sistem
3.2.1 Flowchart
Proses data dalam aplikasi ini ditampilkan menggunakan flowchart pada Gambar 6.
Gambar 6 Flowchart aplikasi SPMS (Sequential Pattern Mining Software
Masing-masing langkah dalam flowchart akan dijelaskan secara detil dalam bab 3.2.3 mengenai algoritma. Algoritma untuk tiap langkah tersebut akan dituliskan menggunakan pseudocode.
3.2.2 Rancangan Kelas
Rancangan kelas untuk aplikasi sequential pattern mining dengan menggunakan metode GSP, Prefix Span, dan CM-Spade dapat dilihat pada Gambar 7.
Gambar 7 Rancangan kelas
3.2.3 Algoritma
1. Algoritma untuk method identifikasi activity
Mengidentifikasi nama-nama activity dalam event log.
Dengan mengindetifikasi urutan dalam event log, sehingga nama activity tersebut yang akan menjadi output dalam pengembangan. Jika di lakukan masukan dengan memanggil
event log dengan format csv, setelah di proses dengan
menggunakan algoritma yang ada maka output yang akan di tampilkan akan berupa nama activity dengan format file teks.
Input : Event log Output : Activity list
For each activity in the event log if not in activity list
append activity to activity list
end end
2. Algoritma untuk method memetakan nama activity menjadi
activity id
Input : Event log, Activity list Output :Event log
3. Algoritma untuk method memetakan trace
Memetakan trace dalam event log menjadi format masukan
library, Trace yang berisi data event log dengan menggunakan
format file teks, yang akan di dijadikan format masukan di dalam library yang di gunakan.
Input: event log Output: trace
4. Menjalankan metode data mining menggunakan library. Menjalankan metode data mining (GSP,Prefix Span dan
CM-Spade) menggunakan library pada perangkat lunak SPMF. a. Input :Trace
Output : Sequence
for each activity do
if activity = activity in activity list append activity id
end
end
for each activity
If case id identical Append to trace end
Algoritma : GSP ( Trace ) b. Input :Trace
Output :Sequence
Algoritma : Prefix Span ( Trace ) c. Input : Trace
Output :Sequence
Algoritma : CM-Spade ( Trace )
5. Algoritma memetakan output library menjadi nama activity dalam event log.
Dengan memasukkan input yang berupa data event log yang terdiri dari event id dan activity, di lakukan trace, kemudian akan mendapatkan hasil yang berupa pattern activity dari data
event log tersebut. Input : event log
Output :Urutan nama activity
3.3 Rancangan Antar Muka
Aplikasi ini akan dibangun sedemikian rupa dengan perancangan antarmuka. Terdapat 7 perancangan antarmuka dari aplikasi yang akan dibangun.
for each id in the sequence
If id equals activity id then Append activity to trace end
3.3.1 Antarmuka Beranda
Gambar 8 Rancangan antarmuka beranda
Pada gambar 8 rancangan antarmuka beranda dirancang sederhana agar pengguna dapat dengan mudah menggunakan aplikasi tersebut. Tombol untuk meng-import data berada di samping agar lebih praktis.
3.3.2 Antarmuka Data Event Log
Gambar 9 Rancangan antarmuka data event log
Pada gambar 9 dibuat untuk menampilkan seluruh data yang telah di masukkan ke dalam aplikasi, kemudian terdapat tombol activitylist, dimana tombol tersebut akan menghubungkan ke antarmuka activitylist.
3.3.3 Antarmuka Activity List
Gambar 10 Rancangan antarmuka activity list
Pada gambar 10 dibuat untuk mecari jumlah activity yang sama dari seluruh data di eventlog,
3.3.4 Antarmuka Trace Activity
Pada gambar 11 dibuat setelah antarmuka activity list, dimana antarmuka ini akan bekerja untuk mengelompokkan activity berdasarkan ID sesuai dengan data
activitylist. -1 menandakan akhir dari setiap item, sedanglan -2 menandakan akhir
dari sebuah urutan.
3.3.5 Antarmuka Save Trace
Gambar 12 Rancangan antarmuka save trace
Gambar 12 dibuat untuk melakukan penyimpanan data berupa urutan activity yang merupakan masukan dari SPMS.
3.3.6 Antarmuka SPMS
Gambar 13 Rancangan antarmuka metode data mining
Gambar 13 dibuat untuk menjalankan metode data mining yaitu GSP, Prefix Span dan CM-Spade untuk mencari urutan activity yang sering muncul dari data
eventlog.
3.4 Rancangan Pengujian
Untuk membuktikan bahwa aplikasi dapat melakukan Sequential Pattern Mining dengan menggunakan metode GSP, Prefix Span dan CM-Spade dilakukan pengujian dengan rancangan sebagai berikut.
3.4.1 Data Uji
Data uji diambil dari buku karya Wil van der Aalst berjudul "Process Mining:
Data Science in Action." terbitan Springer Berlin Heidelberg (2016) halaman 3-23.
Gambar 14 Contoh data uji
Pada data uji ini terdiri dari :
1. Case id merupakan sebuah angka yang digunakan untuk memberi atau mengidentifikasi sebuah event
2. Event id digunakan agar dapat mengidentifikasi sebuah event,
3. Timestamp (dd-MM-yyyy:HH.mm) menunjukkan waktu sebuah aktivitas, 4. Activity merupakan rangakaian kegiatan,
5. Resource merupakan nama-nama orang yang bertanggung jawab dalam pelaksanaan dalam suatu kegiatan,
6. Costs harga dalam sebuah event
7. Outcome merupakan hasil dari setiap event
3.4.2 Deskripsi Pengujian
Pengujian dilakukan 2 kali dengan 3 metode, yaitu GSP, Prefix Span dan
CM-Spade, 100 data , 200 data, 300 data, 400 data, 500 data, 600 data, 700 data, 800
masing-masing data uji tersebut, dimasukkan data dengan jumlah Event, Jumlah
Case dan jumlah Activity yang berbeda, untuk setiap pengujian terdapat waktu
dimana waktu tersebut menunjukkan lamanya proses pengurutan data yang sering muncul dari eventlog, lama waktu saat melakukan pengurutan data berbeda-beda karena tergantung kondisi lingkungan sistem saat mengurutkan data.
BAB IV
HASIL DAN PEMBAHASAN
Setelah melakukan tahap perancangan maka tahap selanjutnya adalah implementasi dan pengujian terhadap produk. Implementasi dari tahap perancangan tersebut adalah sebagai berikut:
4.1 Implementasi Antarmuka
4.1.1 Halaman Beranda
Pada halaman beranda terdapat tombol untuk meng-import data event log ke dalam aplikasi dalam format csv.
Gambar 15 Implementasi antarmuka beranda
Pada gambar 14 dibuat sederhana namun tetap memiliki keindahan dan seni dari segi tampilannya. Terdapat enam tombol utama untuk memproses data, di sebelah kiri ditempatkan khusus untuk meng-import data. Enam tombol utama di buat berurut yang dimulai dari kiri tombol “Event Log” hingga tombol “Delete All
Data” agar memudahkan penggunaan yang sesuai dengan alur proses yang di tetapkan.
4.1.2 Halaman Antarmuka Data Event Log
Gambar 16 Implementasi antarmuka data event log
Pada gambar 15 dibuat untuk menampilkan seluruh data yang telah di masukkan ke dalam aplikasi, kemudian terdapat tombol activitylist, dimana tombol tersebut akan menghubungkan ke antarmuka activitylist
4.1.3 Halaman Antarmuka Activitylist
Gambar 17 Implementasi antarmuka activity list
Pada gambar 16 ini dibuat untuk mecari jumlah activity yang sama dari seluruh data di eventlog,
4.1.4 Halaman Antarmuka Trace Activity
Pada gambar 17 dibuat setelah antarmuka activity list, dimana antarmuka ini akan