Rekomendasi Kasus Penggunaan Berdasarkan Skenario Naratif Menggunakan Teknologi Semantik OLEH : REZA FAUZAN (5112201001) PEMBIMBING : DANIEL ORANOVA SIAHAAN, S.KOM, M.SC, PD.ENG NURUL FAJRIN ARIYANI, S.KOM, M.SC
Latar Belakang (1/3) Pembangunan
sebuah diagram kasus penggunaan (use case diagram) merupakan teknik yang populer digunakan dalam rekayasa kebutuhan (Regnell, 1995).
Diagram
kasus penggunaan adalah deskripsi dari sebuah sistem yang dilihat dari sudut pandang pengguna (Munawar, 2005).
Latar Belakang (2/3) Skenario
merupakan dokumen narasi yang menjelaskan alur cerita dari suatu sistem (Siahaan, 2012)
Dokumen
skenario tertuliskan siapa saja aktor yang berperan di dalamnya dan apa saja hal yang dilakukan oleh aktor itu sendiri.
Latar Belakang (3/3) Dalam
penelitian sebelumnya, mengidentifikasi skenario menjadi diagram kasus penggunaan menghasilkan hasil yang dapat menyatakan bahwa skenario dan kasus penggunaan berhubungan erat (Kim, Park, & Sugumaran, 2006).
Masalah Pada
penelitian sebelumnya mengharuskan seorang analis membuat skenario sesuai dengan aturan.
Kontribusi Membuat
model metadata skenario serta langkah kerja untuk merekomendasikan kasus penggunaan dari skenario tersebut.
Batasan Masalah Dokumen
skenario yang dimasukkan berupa sebuah dokumen yang berbahasa Inggris. Dokumen skenario yang akan diproses hanya berbentuk teks.
Kajian Pustaka (Contoh Skenario) One day, Budi, a young executive at surabaya, got a call from his wife that phone bill, water bill, and electricity bill have not been paid this month, while there is no left money on his hand. On the phone call, his wife threats him that he won't be able to have a dinner at home before this issue is resolved. Budi realized he still has money of approximately 150,000 rupiahs. Unfortunately, he had some appointment to some clients in different place. So he did not have any time to go to the Bank and pay the bills to each counter. When he saw the window, he saw an 'inova' ATM machine. Before he went to the ATM machines, he sent a message to the machine to make sure whether the machine can be operated or is being broken. A few later, he received a reply message from the machine. The message told the machine is in a good condition and can be used.
Perancangan Sistem
Ekstraksi Metadata Skenario (1/3) (Identifikasi Profesi dan objek)
Ekstraksi Metadata Skenario (2/3) (Identifikasi Profesi dan objek) Pola-pola yang dapat diidentifikasi : 1. [nama]NNP + is + DT + ... + [profesi]NN 2. [nama]NNP + is + ... + [profesi]NN 3. PRP + is + DT + ... + [profesi]NN 4. PRP + is + ... + [profesi]NN 5. [nama]NNP + , + DT + ... + [profesi]NN
6. [nama]NNP + as + DT + ... + [profesi]NN 7. DT + ... + [profesi]NN + named + [nama]NNP 8. [nama]NNP + who + worked + as + ... + [profesi]NN Ket : ... = hanya dapat diisi dengan kata sifat (JJ) atau dikosongkan Jika terdapat kata sifat sebelum kata benda, maka keduanya akan menjadi profesi.
Hasil Identifikasi Profesi (3/3) One day, Budi, a young executive at surabaya, got a phone from his wife told him that phone, water, and electricity bills this month had not been paid, while the allowance for this month had already run out.
Ekstraksi Metadata Skenario (2/3) (Ekstraksi Kata Penting) Input :
One day, Budi, a young executive in Surabaya, got a phone from his wife told him that phone, water, and electricity bills this month had not been paid, while the allowance for this month had already run out.
Ekstraksi Metadata Skenario (3/3) (Ekstraksi Kata Penting) Output : [num(day-2, One-1), nsubj(got-12, day-2), appos(day-2, Budi-4), det(executive-8, a-6), amod(executive-8, young-7), appos(day-2, executive-8), prep_in(executive-8, Surabaya-10), root(ROOT-0, got-12), det(phone-14, a-13), nsubj(told-18, phone-14), poss(wife-17, his-16), prep_from(phone-14, wife-17), ccomp(got-12, told-18), dobj(told-18, him-19), mark(paid-33, that-20), nsubjpass(paid-33, phone-21), conj_and(phone-21, water-23), nsubjpass(paid-33, water-23), nn(bills27, electricity-26), conj_and(phone-21, bills-27), nsubjpass(paid-33, bills-27), det(month-29, this-28), dep(bills-27, month-29), aux(paid-33, had-30), neg(paid-33, not-31), auxpass(paid-33, been-32), ccomp(told-18, paid-33), mark(run-43, while-35), det(allowance-37, the-36), nsubj(run-43, allowance-37), det(month-40, this-39), prep_for(allowance-37, month-40), aux(run-43, had-41), advmod(run43, already-42), advcl(paid-33, run-43), prt(run-43, out-44)]
Pemodelan Metadata Skenario
Pemodelan Repositori (1/4) Pada
setiap actor, action, dan object dalam setiap kasus penggunaan pada repositori, dicari kesamaannya menggunakan SUMO yang memiliki relasi “equivalent mapping”
Pemodelan Repositori (2/4)
Ontologi SUMO terlalu besar, sehingga harus dilakukan penyaringan dengan hanya mencari kata yang memiliki relasi equivalentMapping.
data yang disediakan SUMO (.kif) dilatih menjadi sebuah ontologi (.owl) menggunakan kakas bantu Sigma. Setelah mendapatkan berkas ontologi, penulis hanya mendapatkan relasi subClassOf pada ontologi yang dihasilkan.
Penggunaaan ontologi SUMO versi mini yang telah tersedia dari SUMO, penulis mendapatkan relasi tersebut tetapi hanya beberapa kata saja.
SUMO lebih cocok untuk menggabungkan dua ontologi, sedangkan dalam penelitian ini hanya menggunakan satu ontologi.
Pemodelan Repositori (3/4)
Domain Ontologi :
Pemodelan Repositori (4/4)
Pencarian Repositori
Perhitungan Kemiripan (1/3) Bobot (Fauzan & Pramono, 2013) : Actor = 0.1 Action = 0.5 Object = 0.4
Sim(kata _ 1, kata _ 2)
1 dis tan ce(kata _ 1, kata _ 2)
Perhitungan Kemiripan (2/3) Metadata Skenario :
Executive (actor), sent (action), SMS (object) Metadata Repositori : -
Executive (actor), sent (action), SMS (object)
-
Executive (actor), checked (action), balance (object)
Perhitungan Kemiripan (3/3) S = (simActor x bobotActor) + (simAction x bobotAction) + (simObject x bobotObject) Executive executive, sent sent, SMS SMS S = 1 x 0,1 + 1 x 0,5 + 1 x 0,4 = 1
Executive executive, sent checked, SMS balance S = 1 x 0,1 + 0,4285714 x 0,5 + 0,5 x 0,4 = 0,5142857
Pengujian
Menggunakan Kappa
Best case worst case
Nilai Indeks Kappa
Proporsi Kesepakatan
<0
Rendah (less than chance agreement)
0.01 – 0.20
Sedikit (slight agreement)
0.21 – 0.40
Cukup (fair agreement)
0.41 – 0.60
Sedang (moderate agreement)
0.61 – 0.80
Banyak (substansial agreement)
0.81 – 1.00
Hampir Sempurna (almost perfect agrement)
Skenario yang Diujikan Terdapat 10 Skenario yang diujikan dengan kriteria : 1.
Skenario 1 sampai skenario 5 adalah skenario yang benar-benar ada di dalam repositori.
2.
Skenario 6, 8, dan 9 adalah skenario yang kasusnya mirip dengan kasus yang ada pada repositori.
3.
Skenario 7 dan 10 adalah skenario yang sama sekali tidak mirip dalam kasus yang ada pada repositori.
Pengujian Pertama (1/3) GRAFIK NILAI KAPPA AMBANG BATAS 0,1 SAMPAI 1,0 Treshold 0,1
Treshold 0,2
Treshold 0,3
Treshold 0,4
Treshold 0,5
Treshold 0,6
Treshold 0,7
Treshold 0,8
Treshold 0,9
Treshold 1
1,200
1,000
NILAI KAPPA
0,800
0,600
0,400
0,200
0,000 SCE1
SCE2
SCE3
SCE4
SCE5
SCE6
SKENARIO
SCE7
SCE8
SCE9
SCE10
Pengujian Pertama (2/3) Nilai Kappa
Ambang Batas
Sce1
Sce2
Sce3
Sce4
Sce5
Sce6
Sce7
Sce8
Sce9
Sce10
0,1
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,2
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,000
0,3
0,000
0,001
0,001
0,001
0,000
0,000
0,000
0,002
0,000
0,000
0,4
0,001
0,005
0,006
0,004
0,002
0,001
0,000
0,001
0,006
0,000
0,5
0,006
0,009
0,012
0,015
0,005
0,003
0,000
0,005
0,011
0,000
0,6
0,021
0,024
0,038
0,033
0,020
0,009
0,000
0,026
0,033
0,000
0,7
0,060
0,095
0,078
0,119
0,046
0,043
0,000
0,078
0,078
0,000
0,8
0,218
0,265
0,335
0,558
0,158
0,166
0,000
0,475
0,298
0,000
0,9
0,883
0,917
0,883
1,000
0,646
0,662
0,000
0,852
0,883
0,000
1,0
1,000
0,903
0,657
1,000
1,000
0,000
0,000
0,000
0,657
0,000
Pengujian Pertama (3/3)
Pengujian Kedua (1/3) NILAI KAPPA AMBANG BATAS 0,85 SAMPAI 0,95 Treshold 0,85
Treshold 0,86
Treshold 0,87
Treshold 0,88
Treshold 0,89
Treshold 0,91
Treshold 0,92
Treshold 0,93
Treshold 0,94
Treshold 0,95
Treshold 0,90
1,2
1
NILAI KAPPA
0,8
0,6
0,4
0,2
0 SCE1
SCE2
SCE3
SCE4
SCE5
SCE6
SKENARIO
SCE7
SCE8
SCE9
SCE10
Pengujian Kedua (2/3) Nilai Kappa
Ambang Batas
Sce1
Sce2
Sce3
Sce4
Sce5
Sce6
Sce7
Sce8
Sce9
Sce10
0,85
0,405
0,423
0,883
0,795
0,335
0,662
0,000
0,739
0,693
0,000
0,86
0,466
0,471
0,883
1,000
0,433
0,662
0,000
0,852
0,789
0,000
0,87
0,466
0,560
0,883
1,000
0,591
0,662
0,000
0,852
0,883
0,000
0,88
0,466
0,846
0,883
1,000
0,591
0,662
0,000
0,852
0,883
0,000
0,89
0,711
0,917
0,883
1,000
0,591
0,662
0,000
0,852
1,000
0,000
0,90
0,883
0,917
0,883
1,000
0,646
0,662
0,000
0,852
0,883
0,000
0,91
0,883
0,903
0,852
1,000
0,711
1,000
0,000
0,492
1,000
0,000
0,92
0,883
0,903
0,657
1,000
0,711
1,000
0,000
0,492
1,000
0,000
0,93
0,883
0,903
0,657
1,000
0,711
1,000
0,000
0,492
0,852
0,000
0,94
0,884
0,903
0,657
1,000
0,711
0,000
0,000
0,000
0,852
0,000
0,95
1,000
0,903
0,657
1,000
0,789
0,000
0,000
0,000
0,852
0,000
Pengujian Kedua (3/3)
Analisa Pengujian (1/5) Dari
pengujian, sistem menghasilkan nilai treshold terbaik sebesar 0,91 dengan nilai kappa sebesar 0,684169593.
Dari
nilai kappa terbaik, terdapat 0,315830407 ketidaksesuaian antara pakar dengan sistem.
Analisa Pengujian (2/5) Penyebab ketidaksesuaian pakar dengan sistem : a.
Sistem berbasiskan ambang batas.
b.
Sistem tidak dapat merekomendasikan kasus penggunaan yang didapatkan dari kesimpulan beberapa kalimat.
c.
Ekstraksi kata penting menggunakan Stanford Dependency Parser belum optimal.
Analisa Pengujian (3/5) Sistem berbasiskan ambang batas : Sistem
Pakar
customer --> send_message
customer send_message
customer --> check_cash
customer check_cash
employee --> check_salary
customer pay_bill
customer --> pay_bill customer --> withdraw_cash
customer withdraw_cash
Analisa Pengujian (4/5) Sistem tidak dapat merekomendasikan kasus penggunaan yang didapatkan dari kesimpulan beberapa kalimat : “In system, it would record about the patient’s illness record to make a report about the illness that had been suffered by the patient. In the prescription that was wrote manually by the doctor, this prescription would be given to the pharmacist. The pharmacist would match the prescription with the medicine on pharmacy. Pharmacist also checked the medicine inventory on the pharmacy. Pharmacist would also record the medicine’s prescription data for every patient to report every patient that came to the hospital.” Sistem
Pakar
casheer --> register_member
casheer register_member
doctor --> add_medical_record
doctor add_medical_record
pharmacies --> search_medicine
administrative officer insert medical record pharmacies search_medicine
Analisa Pengujian (5/5) Sistem
user --> view_information
Pakar
user view_article guest view_article user view_information
Ekstraksi kata penting menggunakan Stanford Dependency Parser belum optimal : “After he entered the wikiminipedia.com website, he would enter the HOME menu, at first he was confused because he could only read but could not add other articles.” Hanya metadata he,add,other_articles yang ditemukan.
Kesimpulan
Berdasarkan hasil pengujian, nilai kappa yang didapatkan menginterpretasikan bahwa sistem memiliki proporsi kesepakatan yang substansial. Hal tersebut dibuktikan dengan nilai kappa optimal yang dihasilkan adalah 0,684169593 pada ambang batas 0,91.
Ketidaksesuaian pakar dengan sistem disebabkan oleh : 1.
Sistem berbasiskan ambang batas.
2.
Sistem tidak dapat merekomendasikan kasus penggunaan yang didapatkan dari kesimpulan beberapa kalimat.
3.
Ekstraksi kata penting menggunakan Stanford Dependency Parser belum optimal.
Saran
Setelah sistem mendapatkan luaran kasus penggunaan, sistem harus ditambahkan mekanisme mencari kemiripan antar kasus penggunaan dan mencari kasus penggunaan terbaik.
Mekanisme pengambilan fakta baru dari beberapa kalimat dibutuhkan untuk mancari kasus penggunaan yang tersirat di dalam beberapa kalimat.
Mekanisme ekstraksi kata penting dari Stanford Dependency Parser harus lebih dioptimalkan.
Terima Kasih
